Основы. Работа без "проведения" документов. : ФинСофт:КупецЪ

Данная тема, наверно, будет интересна специалистам, занимающимся технической поддержкой торговых систем.

Одно время я плотно занимался разработкой и поддержкой конфигураций
на одной очень распространенной платформе. В последствии, анализируя накопленный опыт, я пришел к выводу, что источником львиной доли проблем был механизм "проведения" документов. Документы после сохранения проводились, в результате чего в различные служебные таблицы заливались дополнительные записи, на основании которых в дальнейшем строились отчеты. Трудности начинались при последующих корректировках документов или изменениях расчетных алгоритмов.

Поэтому при разработке проекта КупецЪ изначально было принято решение пойти по другому пути. Механизм утверждения документов в Купце внешне напоминает проведение, но это всего лишь отметка, что документ надо учитывать в финансовых и товарных отчетах.

Рассмотрим типичную ситуацию с учетом движения товаров. В системе с проведением документов делаются записи в регистр, имеющий индекс типа товар-дата-время операции. Используя этот индекс, программа может быстро выбрать все движения по товару за заданный период времени, читая минимум информации из базы данных.
Мы хотим получить аналогичный результат, но обойтись без дополнительной таблицы регистра. Сложность в том, что дата и время хранятся в заголовке накладной, а ссылка на товары - в строках. Чтобы получить желаемый индекс, мы используем денормализацию и сохраняем дату и время в строках накладной.
В обычной ситуации вначале создается заголовок накладной, затем добавляются строки. Для каждой новой строки просто присваиваем дату и время из заголовка. Но может возникнуть ситуация, когда надо изменить дату или время у существующей накладной.
Для этого случая был введен термин "критичные реквизиты документа". При их изменении запускается специальная обработка, которая синхронизирует нужные значения в заголовке документа и в его строках. На приведенном ниже скриншоте критичными реквизитами документа являются поля ввода даты и времени, кнопка выбора даты из календаря.



Описанная технология дает огромный эффект. В базе нет дополнительного слоя информации. Имея механизм быстрого доступа к данным, мы можем выполнять все расчеты "на лету". Ничего не надо перепроводить, все отчеты всегда выводят актуальные результаты.
А это, в свою очередь, снимает много головной боли при сопровождении программы.

Небольшой ролик, в котором показана типовая ситуация. Оприходовали товар с некоторой ценой закупки, отгрузили его, получили наценку. Затем задним числом меняем цену закупки в приходной накладной. Результат в отчетах остается актуальным.

https://storage.olegon.ru/supermag/F...s/q_noprov.swf

??? Не могу полностью принять данный подход

Скажу более - его практиковал до создания "прародителей" УС Лэнд. Достоинства его Вы описали, а недостатки? Скажу "по себе" - все документы имеют статус "простой бумажки" пока не будут "распределены" (проведены), а точнее порождена хозяйственная операция с записью в таблицу истории. Причины:

1. В своё время "умаялся" рисовать отчеты, в которых задействованы множества видов документов, а это в основном "анализ фин.хоз. деятельности". Сейчас, как удобно - сканируется единственная таблица из которой получается "любая" аналитика;

2. "Принцип двойной записи". Сейчас каждая "операция" присутствует в документе и в истории, т.е. при наличии "сбоев" всегда на программном уровне можно сличить инфу в этих источниках и "восстановить" "историю" или документ... Не имея этого инструмент диагностики "потери информации" - это "ручное" сравнение с отчетами прошлых периодов;

3. "Виртуальные документы/операции". У меня - те, что не распределены, т.е. не изменили картину финансов или остатков, но которые также являются объектами для анализа (или подтасовки отчетности), например в них сохраняется понятие "товаров в пути", "предварительные заказы" (торговля несуществующими товарами)...

Да Вы упростили схему храниения инфы, ускорили построение ряда отчетов, но (на досуге) подумайте, а что же Вы при этом потеряли? Отмечу, что для пользователей структура хранения инфы "по барабану" и это касается лишь разработчика

Андрей,

1. На самом деле это не проще. При проведении нужно в каждом документе закодировать, какие записи он создает в общем журнале операций. В Купце слой документов накрывается слоем бизнес-функций. В соответствующей бизнес-функции прописывается обработка разных документов и в зависимости от режима вызова формируется итоговая выборка (таблица в оперативной памяти). Отчеты обычно используют вызовы бизнес-функций, зачастую ничего не зная о документах. То есть в случае с общим журналом операций логика использования документов определяется для каждого документа, в другом варианте она собрана в бизнес-функции.

2. В Купце изначально используется протоколирование работы с базой данных. Я хотел написать об этом чуть позже. Там можно не только посмотреть, что, кто и когда изменял, но и, например, посмотреть накладную на какой-то момент времени или вывести, что изменилось в ее строках за заданный период времени. Есть отчет об изменениях строк накладных задним числом и т.п.

3. Аналогично, можно использовать неутвержденные документы. Все в конечном счете определяется хранимой в них информацией.

Для пользователей, как и для службы техподдержки, важно, чтобы программа работала стабильно и без лишних вопросов. Убирая второй слой данных, мы в принципе уходим от проблем с некорректностью его содержания, вызванного какими-либо оперциями с нарушением хронологии или программно-аппаратными сбоями. А при развитии функционала проще внести изменения в код бизнес-функции и раздать его пользователям, чем копаться в содержимом базы данных у каждого пользователя.

Другой момент связан с производительностью. Если в Купце нужно изменить, скажем, строку в накладной, то это комариный укус, доли секунды для системы, и никаких блокировок для читателей. Совсем другая ситуация, когда документ перепроводится. Нужно обеспечить целостность транзакции, либо блокируя базу, либо используя версионность. А это все поджирает ресурсы, особенно при росте базы данных.

В УС Лэнд каждый объект, в частности "документ" имеет уникальный код, прописываемый в таблицу "история", т.е. из истории имеем быстрый доступ к документу и наоборот. Ты считаешь, что введение понятий "бизнес слоёв" и иже с ними "проще", чем консолидированная таблица?

Как когда-то нами обсуждалось и в УС "это" имеется в виде журнала операций и файла статистики... но я говорил не о "том", а об разрушении данных в результате аппаратых сбоев и возможной частичной при этом потере информации... где ни какие логи не помогут

Не возражаю

а об этом "изменения в код бизнес-функции", если можно поподробнее?

В принципе не возражаю, но разделяя "определение документа" и его "проведение", где просто пополнение таблицы так же не сильно деградирует скорость. Что по выборке информации в УС, в оперативных отчетах сканируются "документы", что весьма быстро, а для анализа фин.хоз.деятельности таблица истории, что проще мне реализовать...

Но "мир большой и разнообразный" и любые подходы имеют право на существование

Да.
В Купце есть транзакционный лог и событийный лог. У них разное назначение. Я писал про транзакционный лог, в котором фиксируются все изменения в базе данных. Этот лог используется одновременно и для аудиторского следа, и для восстановления данных при сбоях. Сбои очень редки, как правило, могут возникнуть при жестком выключении питания у сервера, когда операционная система скидывает данные из кэша на жесткий диск. В этом случая файл с испорченной таблицей восстанавливается из последней архивной копии, затем накатываются изменения из лога. Затем для проверки запускается тестирование базы данных. При создании резервной копии содержимое лога переливается в архив, поэтому оперативный лог имеет маленький размер.
Если используется система с проведением документов, то в регистрах сохраняются результаты промежуточных расчетов. Когда мы добавляем какой-то новый функционал, то использование его в прошедших периодах может потребовать в том или ином виде перепроведения документов. В системе без проведения новые расчеты прописываются в бизнес-функции (или добавляется новая бизнес-функция), компилируются в dll и обновляются у пользователей. Содержимое базы данных трогать обычно не надо.
Систем с проведением документов достаточно много. Я думаю, в основном это объясняется стремлением к универсальности и делегированием технической поддержки и доработки третьим лицам.