31 янв. 2011 г.

Бухгалтерские проводки как функция, а не данные

У нас документы хранятся отдельно от проводок. Как уже упоминалось в этом блоге, проводки (т.е. записи в таблицы ac_entry и ac_record) формируются алгоритмами типовых проводок. В результате получаем две огромные таблицы большая часть информации в которых дублирует gd_document и данные из соответствующих документов.

Если вместо формирования VBScript-а типовой проводки формировать код selectable процедуры, которая на основании данных документов сформирует список проводок, то:
  1. Избавляемся от таблиц ac_entry и ac_record.
  2. Избавляемся от таблицы gd_document (на вскидку, три указанные таблицы с индексами занимают не менее четверти объема любой базы данных).
  3. Избавляемся от ограничения на количество аналитических признаков. Так как проводки являются просто отображением таблицы с документами, то любое поле этой таблицы сразу становится аналитическим признаком. Более того, поле ссылка? Тогда каждое поле указываемой таблицы может быть аналитикой и так до бесконечности. Журнал ордер по продажам с группировкой не по самим клиентам, а по областям/районам можно будет построить всего за несколько кликов мышкой.
  4. Избавляемся от системы количественных показателей в проводках. При необходимости вести учет одновременно в нескольких единицах измерения следует определить функцию пересчета (отображения) основной единицы в дополнительные.
  5. Избавляемся от проблемы рассинхронизации данных документов и соответствующих им проводок. Никаких больше "перепровести проводки".
  6. Ускоряем запись и изменение документов.
  7. Избавляемся от бизнес-объектов типа Проводка, которые бизнес-объектами в полном смысле этого слова не являются.
  8. Возможно, упрощается репликация данных.
Придется переделать систему бухгалтерских остатков в общую систему обновляемых агрегатных показателей по произвольным полям и таблицам (функциональность OLAP).

Firebird 3.0 как сервер приложения?

Алгоритмы формирования типовых хозяйственных операций и проводок у нас хранятся в двоичном виде как последовательность программных блоков. Данная последовательность преобразуется в код на VBScript перед выполнением (или при сохранении, что не столь важно). Что, если мы будем преобразовывать двоичный код в текст триггера Firebird на события AFTER INSERT и AFTER UPDATE для таблицы документа?

Получаем профит ввиде разгрузки клиента и перемещения логики приложения на сервер. Единственная проблема с блоками произвольного кода, где настройщик мог вставить обращения к объектам платформы и бизнес-объектам. Для таких случаев можно развить механизм, чтобы он в зависимости от ситуации работал и по-новому, и по-старому. Если возможно — выполняется приобразование в триггер, нет — работает код на VBScript.