| WGA |
|---|
| Появилась тут задача по бухгалтерскому учету. |
Как раз именно в бухгалтерском учете всё уже давным-давно придумано. Ведь понятие "бухгалтерской проводки" сводится к отражению хозяйственной операции на "бухгалтерских счетах", которые и являются, по своей сути, агрегатами. ОСВ - это всего лишь отчет, который выводит содержимое подобного агрегата в тех или иных аналитических разрезах.
Некоторые разработчики пытаются избежать хранения в базе отдельных сущностей вроде "бухгалтерских счетов" и "проводок" по ним, формируя, в частности, ОСВ непосредственно по массивам первичных документов в процессе формирования ОСВ как отчета. Однако, по-моему, это не совсем удачный подход по множеству причин.
Во-первых, на одних и тех же счетах могут производить движения документы очень многих различных видов. Во-вторых, одни и те же документы, в зависимости от их смыслового содержания, могут производить движения по разным счетам. В-третьих, существуют пусть и небольшой процент нестандартных ситуаций, которые система должна уметь обработать, и такие ситуации невозможно изначально вписать ни в какой систематизированный алгоритм.
Именно по этой причине первоисточники в виде электронных документов хранят в одних сущностях (журналах документов), а проводки, которые они вызывают, в других - в бухгалтерских счетах и бухгалтерских регистрах. Это удобно еще и потому, что неподготовленные по различным причинам документы огут оставаться "непроведенными", либо "проведенными частично" (например, когда по приходу ТМЦ предоставлена накладная ТОРГ-12, но не предоставлена корректно оформленная счет-фактура). Проводки также могут возникать не на основе формализованного документа с заранее расписанной схемой проводок, но и на основе "бухгалтерской справки", в которой могут быть совершенно любая заранее непредсказуемая совокупность проводок.
Таким образом, на счетах аккумулируется (агрегатируется) информация, у которой может быть огромное количество различных источников, алгоритмов и причин попадания на счета, в том числе несистематизируемые. ОСВ выводит отчет по этой информации, который никак слабо связан с источниками информации и который, как правило, не модифицируется при изменении схем проводок, алгоритмов проведения, появлении новых видов документов и т.п.
Бухгалтерский счет - и есть, по сути, нечто подобное OLAP-кубу. Аналитические разрезы бухгалтерского счета определяют перечень его измерений, учетные периоды - одно из измерений, другие определяются видом счета (для счетов взаиморасчетов это могут быть контрагенты и договоры, для счетов учета ТМЦ - перечень складов и номенклатура и т.д.). А суммы в различных валютах, натуральные показатели (количество) образуют его меры.
Понятно, что возникают взаимно противоположные задачи иметь максимально оперативно получаемые по проводкам агрегированные данные, и при этом не слишком утяжелять базу всеми комбинациями агрегатов и, по возможности, не слишком тормозить работу многих пользователей, которые проводят документы и оперативно отражают в учетной системе факты хозяйственной деятельности. Ну так это классическая задача оптимизации OLAP-куба. Можно хранить лишь часть агрегатов, а остальную досчитывать "на лету", когда она потребуется. Например, можно хранить остатки на начало каждого месяца и обороты за месяц по всей совокупности аналитических разрезов, а данные в промежутках между месяцами получать "на лету".
Классическая система имеет отдельные таблицы "документов" и "бухгалтерских счетов". "Проводки" - это формирование записей в таблицах "бухгалтерских счетов" на основе данных таблиц "документов". OLAP-кубы можно построить на таблицах счетов, исходя из фактических возможностей и требований к оперативности получаемых агрегатов.
P.S. А вообще-то это вопрос по тематике немного другого форума - разработка информационных систем.
| Модератор: Могу перенести туда тему, если создатель темы не возражает |