Здравствуйте Sinclair, Вы писали:

S>Это уже интереснее. Обработка откатов, по-моему, вообще одна из самых интересных проблем автоматизации бизнеса. Обычна ситуация, когда некий документ "вводится" в систему числом различной степени задности.
S>Вообще говоря, состояние счетов однозначно определяется историей проводок. Тонкость в том, что сами проводки, вообще говоря, зависят от состояния счетов на момент проведения операции.
Напрашивается такое решение:
S>1. Хранить журнал операций в дополнение к журналу проводок. То есть, мы всегда можем убить список проводок и "запустить" этот журнал на выполнение, и он нам все восстановит. В широком смысле этот журнал — это последовательность тех действий, которые выполняли операторы системы.

S>2. Когда нам надо провести некое исправление, мы откатываем журнал проводок до даты Т, модифицируем журнал операций на дату Т, проводим его от даты Т до сегодняшнего дня. Громоздко, но надежно. Итак, rollback-correct-rollforward.
S>Проблемы — огромные затраты на проведение исправлений. Они растут в лучшем случае линейно от "степени задности числа".
Проблемы еще более общирны: что делать если проводки после даты Т не укладываются после добавления новой проводки N.
Например было на складе 6 единиц. В поле даты Т все 6 единиц ушли со склада.
Мы добавляем проводку N: ушла еще одна единица.
При "укладовании" проводок обратно непонятно где взять 6 единиц, когда их на складе 5 осталось?.
Результат:
1. посылаем в.. все проводки поле даты Т
2. полным перебором пытаемся уложить оставшиеся проводки
3. посылаем в.. юзера с идеей проводки N
4.

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