![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Опердень и undo
А вот скажите мне, как истинные оперденьщики, модно ли сейчас делать в оперденях функцию "откатить изменения в паре сотен документов на неделю назад, потому что пользователи сошли с ума и сделали что-то не то"?
Возникает такая потребность нечасто, поэтому я обхожусь старой копией БД и экспортом-импортом из нее в текущую БД, но может быть, это рукожопиеза которое положено быть запсенным кахесом и давно все делают иммутабельные БД со всеми версиями происходящего и дичайшими алгоритмами отката части графа документов на предыдущую версию?
Возникает такая потребность нечасто, поэтому я обхожусь старой копией БД и экспортом-импортом из нее в текущую БД, но может быть, это рукожопие
no subject
no subject
no subject
no subject
С кнопочкой у Главного Пользователя и подтверждением у еще более Главного Пользователя.
А резервную копию нельзя - она за подписью DBA хранится в сейфе у безопасников, которые будут неделю согласовывать доступ к ней :)
no subject
ГрибовИммутабельности? Входные контроли пройдены - всё, до свидания.no subject
Вам и иммутабельность, и версионность и пауки.
PS appendonly еще очень можно и инстаграмно.
no subject
Вроде, работает до сих пор.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Правильные записи:
01.01 А - приход + 1 000 000.00
10.01 Б - корректура - 900 000.00
Записи за которые могут посадить:
01.01 А - приход + 100 000
Потому как не А, не 01.01 и в промежутке могло много чего произойти.
no subject
no subject
no subject
no subject
Когда-то билинговые системы на RCS делали, пора на более современные технологии переходить!
no subject
особенно когда справочник отдается отдельным сервисом, который черный ящик
no subject
было какое-то время когда возможность пересчета при изменении исходных данных была одим из сертификациооных требований телекоммуникационных биллингов (ну
это отдалеьная область там своий законы) но сейчас законодательство гармонизировано с ISO и странности типа регенерацию счета без сторнирования - убрали.
no subject
doc_id, date_of_change, old_version). С индексом по дате.Есть два варианта отката: иногда нужно, чтобы документ откатился назад, но стал «новой версией» (откат на две недели от версии 20 к версии 3 создает не версию 3, но версию 21 с содержимым 3), а иногда можно просто «вернуться к бэкапу».
Соседняя база никак не влияет на работоспособность системы без нее, пурджится по крону и позволяет элегантно откатиться куда угодно. От оригинальной базы нужен один несложный триггер со слабым приоритетом.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
У меня главные книги (общая и по счетам) являются отчетами (кросс-таблицей), которые создаются из проводок.
Проводки можно менять, до закрытия периода целиком, или по отдельным счетам. Т.е. пока период не закрыт - можно исправлять, после этого - сторнирование, уже в другом отчетном периоде.
История изменений проводок, само собой хранится, но неотъемлемой частью учета не является.
Вполне возможно, что это странные особенности учета у моих клиентов, где периодически бывают заморочки вида "меняем данные за январь прошлого года в марте текущего".
no subject
Введенные документы хранятся в журналах. Там их можно править. Потом они заносятся в главную книгу. Распихиваются по счетам, грубо. После этого - документ нерушим. Как правило закрытие периода и есть моментом внесения записей в главную книгу.
Отчёты в любом случае - вторичны. Первичны - проводки.
А меняем данные - это пиздец. Есть "Закон о бухгалтерском учёте...", где подробно расписано, что можно, а что нельзя.
no subject
Просто "заносятся в главную книгу" в рамках моих представлений звучит странно, как "заносятся в sql-запрос" или "заносятся в предикат".
Основная проблема в том, что данные хранящиеся в БД можно назвать "промежуточными данными" и менять их как душе угодно, до тех пор, пока их не отразили в официальной отчетности.
Причем вопросов больше с налоговым учетом - в первую очередь фиксируют его, а уже потом манипулируют проводками.
no subject
Я начинаю понимать, почему в РБ так популярны кастомизированные и писаные на заказ системы бухучёта.
no subject
Откатываем до резервной копии за нужный день, потом по журналу транзакций смотрим что было до нужного нам момента.
В 1С есть кстати версионирование объектов, то есть можно узнать какая сволочь поменяла дебет с кредитом.
no subject
http://www.postgresql.org/docs/8.3/static/contrib-spi.html#AEN107671
no subject
FileNet?
IBM Content Manager?