![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Опердень и undo
А вот скажите мне, как истинные оперденьщики, модно ли сейчас делать в оперденях функцию "откатить изменения в паре сотен документов на неделю назад, потому что пользователи сошли с ума и сделали что-то не то"?
Возникает такая потребность нечасто, поэтому я обхожусь старой копией БД и экспортом-импортом из нее в текущую БД, но может быть, это рукожопиеза которое положено быть запсенным кахесом и давно все делают иммутабельные БД со всеми версиями происходящего и дичайшими алгоритмами отката части графа документов на предыдущую версию?
Возникает такая потребность нечасто, поэтому я обхожусь старой копией БД и экспортом-импортом из нее в текущую БД, но может быть, это рукожопие
no subject
no subject
no subject
ГрибовИммутабельности? Входные контроли пройдены - всё, до свидания.no subject
no subject
no subject
no subject
no subject
no subject
no subject
С кнопочкой у Главного Пользователя и подтверждением у еще более Главного Пользователя.
А резервную копию нельзя - она за подписью DBA хранится в сейфе у безопасников, которые будут неделю согласовывать доступ к ней :)
no subject
Вроде, работает до сих пор.
no subject
no subject
особенно когда справочник отдается отдельным сервисом, который черный ящик
no subject
Вам и иммутабельность, и версионность и пауки.
PS appendonly еще очень можно и инстаграмно.
no subject
no subject
Когда-то билинговые системы на RCS делали, пора на более современные технологии переходить!
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
Просто "заносятся в главную книгу" в рамках моих представлений звучит странно, как "заносятся в sql-запрос" или "заносятся в предикат".
Основная проблема в том, что данные хранящиеся в БД можно назвать "промежуточными данными" и менять их как душе угодно, до тех пор, пока их не отразили в официальной отчетности.
Причем вопросов больше с налоговым учетом - в первую очередь фиксируют его, а уже потом манипулируют проводками.
no subject
Я начинаю понимать, почему в РБ так популярны кастомизированные и писаные на заказ системы бухучёта.
no subject
no subject
no subject
no subject
no subject
было какое-то время когда возможность пересчета при изменении исходных данных была одим из сертификациооных требований телекоммуникационных биллингов (ну
это отдалеьная область там своий законы) но сейчас законодательство гармонизировано с ISO и странности типа регенерацию счета без сторнирования - убрали.
no subject
doc_id, date_of_change, old_version). С индексом по дате.Есть два варианта отката: иногда нужно, чтобы документ откатился назад, но стал «новой версией» (откат на две недели от версии 20 к версии 3 создает не версию 3, но версию 21 с содержимым 3), а иногда можно просто «вернуться к бэкапу».
Соседняя база никак не влияет на работоспособность системы без нее, пурджится по крону и позволяет элегантно откатиться куда угодно. От оригинальной базы нужен один несложный триггер со слабым приоритетом.
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?