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

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

VD>>Мужик! Вся страна уже восемь лет так работает. И без твоих алгоритмов, а ты только проснулся.
T>Да нет, я имел ввиду автоматизацию процесса...

VD>>Если на базе базы . Посчитан и сддан баланс, то менять ничего нельзя. Это я тебе говорю как практик сдававший балансы, а потом матерясь искал, что я там наизменял задним числом. Не мелочь разную (аналитику, коментании и т.п.) менять конечно можно, но радости от этого никакой. А если ты баланс не сдал, то меняй что хош. Нужно знаьб кто что менял? Ну, дык создай таблицу в которой лог изменений записываться будет (как в твоем любимом MSSQL7). А пересчитывать в соверменной системе (созданной на современный средствах) ничего не нужно. Просто забудь о спец таблицах с закешированными расчетами. Как при этом жить? А выбрасить нахрен MSSQL7 и поставить MSSQL2k или Оракл. В них есть индексированные/материализованные view, которые пересчитываются автоматом (и очень быстро).

T>Но я же писал об УЧЕТНЫХ системе а не о бухгалтерской. Сейчас рулит понятие управленческого учета когда хозяева компаний хотят видеть реальное положение вещей в компании. То что когда сдан в налоговую баланс и в этом периоде изменять ничего нельзя это как бы очевидно. Но вот например представим себе многофилиальную компанию (например торговую сеть) да еще ведущую многовалютный учет с использованием 7-12 аналитик (разрезы по валюте, по филиалу, по отделам, регионам, товарам, группам товаров, ... ) если нужно ввести исправление (а стороно не подходит) да еще если компания имеет аффилированых лиц кучу, которые сами в свою очередь имееют клиентов а нам нужен агрегированный баланс, причем некоторые из аффилированных лиц например оффшорные компании, причем зарубежные со своими планами счетов. Это уже не бухучет. Подобные системы нужны поскольку бух. и налоговый учет (кстати понятия тоже разные) настолько убоги (и не надо прибавлять что у нас в стране. В GAAP еще все более размыто. Наш бухучет более формален ИМХО)что не могут отражать реальное положение дел. Если бы просто нужно было сделать бух систему то все было бы проще. А в разветвленной системе в случае отката ручками все не перебъешь... . Кстати зря так насчет алгоритмов. Алгоритм и вправду получается интересный. Т.е. превичные документы в случае изменения их задним числом порождают целую цепную реакцию изменений. Тут ксати явно пахнет математической теорией. Интересно же!!!


T>
Это уже интереснее. Обработка откатов, по-моему, вообще одна из самых интересных проблем автоматизации бизнеса. Обычна ситуация, когда некий документ "вводится" в систему числом различной степени задности.
Вообще говоря, состояние счетов однозначно определяется историей проводок. Тонкость в том, что сами проводки, вообще говоря, зависят от состояния счетов на момент проведения операции. Напрашивается такое решение:
1. Хранить журнал операций в дополнение к журналу проводок. То есть, мы всегда можем убить список проводок и "запустить" этот журнал на выполнение, и он нам все восстановит. В широком смысле этот журнал — это последовательность тех действий, которые выполняли операторы системы.
2. Когда нам надо провести некое исправление, мы откатываем журнал проводок до даты Т, модифицируем журнал операций на дату Т, проводим его от даты Т до сегодняшнего дня. Громоздко, но надежно. Итак, rollback-correct-rollforward.
Проблемы — огромные затраты на проведение исправлений. Они растут в лучшем случае линейно от "степени задности числа".
С другой стороны, исправления задним числом все равно надо считать исключением. Бизнес, построенный только на них, неэффективен. В первую очередь потому, что задержка проведения документов в среднем на Т приводит к неопределенности состояния бизнеса. То есть, если у нас типичный срок внесения исправлений — две недели, то какие бы то ни было отчеты будут иметь смысл только при условии, что они показывают состояние двухнедельной и более давности.
Поэтому надо подходить с двух концов:
1. Оптимизация rb-cr-rf процесса: разделять независимые операции и откатывать только те, на которые могло повлиять проводимое исправление.
2. Оптимизация бизнес-процесса. Если у вас экспедиторы не сдают накладные по неделе — дайте им по нотебуку с модемом, чтобы они отчитывались в реальном времени. Поставьте на склад систему считывания штрихкодов. Сделайте кассу цифровой. Это облегчит жизнь не только программистам, но всему управляющему персоналу.