Ultima-S: Постановка задачи на 20-уровневую бухгалтерию

Для служебного использования

От руководителя группы бухгалтерии В. Иванова

коммерческому директору компании Ниеншанц Д.Разгуляеву

1. Обосновать необходимость и нишу применения 20 и более уровневых бухгалтерий
2. Описать учетный механизм позволяющий иметь счета с 20 и более уровней аналитики
3. Данный механизм не должен существенно замедлять работу системы (не более 10%)
4. Данный механизм должен существовать как расширение 5-уровневой бухгалтерии
5. Данный механизм должен обеспечить совместимость с 5-уровневой бухгалтерией по структуре проводок и сальдо
6. Для данного механизма нужно описать способ создания проводок и построения типовых отчетов.

На первый взгляд кажется, что уже 5 уровней аналитики более чем достаточно для учета на счетах. Именно из этого исходят средние по тяжести бухгалтерии сегодня. Однако бухгалтерии тяжеловесы позволяют иметь неограниченное или ограниченное большим числом (20 и более) количество аналитических уровней. Стоят такие системы очень дорого (100К $ и выше). Как видно существует потребность в таких мощных аналитических бухгалтериях, и чтобы ее удовлетворить пользователю надо заплатить большие деньги.

Действительно, 5 уровней аналитики, как правило, вполне достаточно для хранения всей аналитической информации в балансе. Однако это не означает что это удобно для эффективного анализа данной информации. Гораздо удобнее для отчетов таких как “Движение Денежных Средств” (ДДС) и “Отчет о Доходах и Расходах” (ОДР) иметь один учетный регистр и сканировать его по всей необходимой аналитике стандартным генератором отчетов типа Analyser, чем собирать информацию по всему балансу неким фиксированным отчетом, который под задачу еще нужно программировать. Данный подход, при котором счет содержит в себе всю заявленную аналитическую информацию о своих объектах учета можно назвать подходом единого учетного регистра. Использование единых учетных регистров сразу увеличивает потребность в уровнях аналитики где-то до 10 уровней.

Например, для единого учетного регистра ДР имеем 7 аналитических уровней

ЦФУ, Доход/Расход, Юрлицо, Статья Затрат, Вид Деятельности, Внешние/Внутренние затраты, Оборотная аналитика.

Для ДДС имеем уже 10 уровней

Банк/Касса, Валюта, Расчетный счет, ЦФУ, Доход/Расход, Юрлицо, Статья Затрат, Вид Деятельности, Внешние/Внутренние затраты, Оборотная аналитика.

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

Следует отметить, что существуют учетные методы, которые быстро расходуют уровни аналитики следующим образом. Часто некой комбинации аналитики идентифицирующей сам аналитический разрез сопутствует один или несколько признаков, в принципе легко вычисляемых, но их надо запрограммировать. Однако если их положить как уровень аналитики, то анализ объекта упрощается и доступен стандартными средствами аналитических отчетов типа Analyzer. Такой метод использования аналитических уровней можно назвать спекулятивным. Например, для статьи затрат, из ДР и ДДС приведенных выше, достаточно легко вычисляется признак доходная она или расходная, но можно проблему решить проще не создавая программируя некий специфичный отчет для этого. Достаточно просто положить данный признак статьи как аналитику. Еще вариант – ложится как аналитика папка нахождения объекта ОС, чтобы получить простой анализ по группам ОС.

Следует отметить, что только на идее единого учетного регистра можно построить онлайновую аналитику (OLAP, имеется в MSSQL 7.0). OLAP позволяет создать живой кросс-отчет подобный кросс-таблицам создаваемыми мастерами в Excel. Однако OLAP позволяет производительно оперировать с большими объемами данных и большими объемами размерностей, а также на лету их перегруппировывать, сворачивать/разворачивать и т.д. OLAP-представление возможно построить только для одного счета, т.к. каждая размерность OLAP-представления должна содежать однотипные объекты. Поэтому счета для OLAP должны иметь максимальное количество аналитик.

Обычная ограниченная по уровням (например, пяти) бухгалтерия базируется на так называемой сальдовой таблице примерно такой структуры:

1. Счет
2. Период (чаще N или код периода, т.е. некая грануляция),
3. Поля уровней аналитики (по одному на каждый уровень),
4. Поля сальдовой информации (дебетовые и кредитовые сальдо, обороты).

Например, упрощенный вид сальдовой таблицы 1С 7.5:

У нас имеется абсолютно аналогичная сальдовая таблица Saldo. Заполняется она из проводок довольно сложным, но очень производительным триггером (0.2 сек на проводку при 10000 разрезов).

Как видим, используемый способ хранения отводит под 1 уровень аналитики 1 колонку сальдовой таблицы. В случае если надо добавить еще один уровень, то необходимо добавить поле в сальдовую таблицу и сделать довольно трудоемкое изменение механизма формирования сальдовой таблицы (в нашем случае это триггер). Задача добавить в 3х уровневую сальдовую таблицу еще 3 уровня (например, для склада ЦФУ, Юрлицо, Статус Товара) достаточно сложна.

……