S>Проблемы еще более общирны: что делать если проводки после даты Т не укладываются после добавления новой проводки N.
S>Например было на складе 6 единиц. В поле даты Т все 6 единиц ушли со склада.
S>Мы добавляем проводку N: ушла еще одна единица.
S>При "укладовании" проводок обратно непонятно где взять 6 единиц, когда их на складе 5 осталось?.
S>Результат:
S>1. посылаем в.. все проводки поле даты Т
S>2. полным перебором пытаемся уложить оставшиеся проводки
S>3. посылаем в.. юзера с идеей проводки N
S>4.
1. Светик, мысли реально Ну откуда у тебя возьмется накладных на 6 единиц??? Склад же не может выдавать товары в минус.
2. Если это не склад, а некая другая сущность, типа счета в бухгалтерии, то у нас получается перерасход. Т.е. система не должна была позволить провести какие-то документы, а она позволила. Вполне реальная ситуация.
Итак, теперь мы имеем а) одно "правильное" действие(которое было потеряно) , и N "неправильных". Вообще говоря, в этом случае мы отменяем отмену с соответствующим результатом. Вариант — попытаться игнорировать недопустимую операцию и продолжать все остальные. Я бы реализовывал так: пытаться роллфорвардить все действия, писать ошибки в лог, если весь журнал прошел успешно, то делать коммит, иначе отменять отмену. Затем ответственный человек думает, как разрулить экстремальные ситуации. Это как раз и есть то, чем занимаются бухгалтера — у меня мама работала главбухом, и основное время съедало последовательное перебалансирование счетов из-за всяких мудаков, которые в зднем кармане документы по месяцу носят. Это решение — всего лишь автоматизация бизнесс-процесса.

S>>С другой стороны, исправления задним числом все равно надо считать исключением. Бизнес, построенный только на них, неэффективен.
S>>2. Оптимизация бизнес-процесса. Если у вас экспедиторы не сдают накладные по неделе — дайте им по нотебуку с модемом, чтобы они отчитывались в реальном времени.
S>Даешь каждой доярке по ноуту!.