Как проектировать бухгалтерию ?

Архитектура ядра подсистемы бухгалтерского и управленческого учета на примере реализации в системе NEXUS

Необходимость учета с большим числом разрезов аналитики

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

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

Например, для единого учетного регистра ДР имеем 7 аналитических уровней: Центр Финансового Учета (ЦФУ), Доход/Расход, Юр.лицо, Статья Затрат, Вид Деятельности, Внешние/Внутренние затраты, Оборотная аналитика.

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

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

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

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

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

Счет Период Аналитика 1 Аналитика 2 Аналитика 3 Сальдо на конец периода
41 1 мес. Монитор LG Склад 2 этаж Партия 1 10
41 2 мес. Монитор LG Склад 2 этаж Партия 1 5
41 2 мес. USR 33600 Склад 1 этаж Партия 2 10
50 1 мес. Касса N1 Рубли 0 100

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

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

Краткое отступление: минимум сведений по архитектуре NEXUS

Организация схемы хранения объектов NEXUS не является полностью оригинальной, а стала уже скорее классической. Описанный подход к построению ОО-надстройки над реляционной СУБД проверен практикой многих разработчиков. На наш взгляд, это хороший пример использования гиперключа, дерева и сети объектов.

Так как NEXUS является документно-ориентированной системой, то разработчики оперируют не термином "объект", а термином "документ". Организация хранения документов базируется на концепции главной таблицы с гиперключом. Приведем скрипт данной таблицы с описанием

CREATE TABLE dbo.Docs (
   UDN int IDENTITY (1, 1) NOT NULL, -- ID документа
   No varchar (128) NOT NULL , -- Пояснительное поле документа (чаще его номер в виде строки)
   Name varchar (128) NOT NULL , -- Название документа
   Date datetime NOT NULL , -- Дата документа
   Folder int NOT NULL , -- Ссылка на папку вхождения документа
   timestamp timestamp NOT NULL , -- Метка времени работы с документом
   DocFlags smallint NOT NULL , -- Системные флаги
   ParentDoc int NULL , -- Для ссылок: указатель на документ
   Class varchar (24) NOT NULL , -- Класс документа
   Deleted tinyint NOT NULL- Признак логически удаленного документа
)
  • UDN - это гиперключ, т.е. в базе существует только один данный ключ для всех документов. Данный ключ суррогатный, представляет собой сквозную нумерацию и имеет в рамках бухгалтерии физический смысл кода аналитического учета. UDN никогда не меняется, т.е. каскадных обновлений ключей в БД нет, также чаще всего нет составных ключей. Все это обеспечивает высокую производительность БД. Указанный подход к формированию гиперключа не является единственным и самым удачным, расширенный вариант может включать в состав гиперключа ID домена для распределенной БД.
  • No – поле без фиксированного назначения, чаще всего в него помещают уникальный идентификатор документа в рамках предметной области. В данном случае нумерация объектов и отслеживание ее идентичности ложится на объекты-нумераторы. Заметим, для идентификации документа внутри системы нумератор не нужен, он идентифицируется независимо от No по полю UDN.
  • Folder – это ссылка на папку хранения документа, т.е. Folder содержит UDN папки. Таким образом, Docs может описывать древовидную структуру. Отдельные ветки данного глобального дерева играют роль древовидных справочников типа "Товары", "Клиенты" и т.д.
  • ParentDoc – указатель на истинный документ для сылки (shortcut). Каждый документ может иметь одно физическое нахождение в дереве и множество ссылок на него. Таким образом, реализуется сетевое преставление, если в нем есть необходимость.
  • Class – название класса документа
  • Deleted – признак логического удаления документа. Чаще всего документы не удаляются физически, а помечаются как удаленные и попадают в архив. Всегда можно восстановить ошибочно удаленный объект.

Таблица Docs позволяет хранить информацию о базовом классе 'Doc', производные классы хранят информацию в дополнительных таблицах, связка осуществляется через UDN.

Например, абстрактный класс "Платежный документ".

CREATE TABLE dbo.PaymentExt (
  UDN int NOT NULL , -- Ссылка на гиперключ
  VAT money NOT NULL , -- НДС
  TSum money NOT NULL , -- Сумма в учетной валюте
  PCur int NOT NULL , -- UDN для валюты документа
  Stat tinyint NOT NULL , -- Состояние документа
  PType tinyint NOT NULL , -- Тип платежа
  Supp int NOT NULL , -- Абстрактный источник
  Rec int NOT NULL , -- Абстрактный приемник
  SuppPC int NOT NULL , -- Абстрактный центр платежа источника
  RecPC int NOT NULL , -- Абстрактный центр платежа приемника
  Sum$ money NOT NULL -- Сумма в валюте
)

Описание структур машины проводок

Замечание. Не приводится описание таблиц и полей системы поддержки 20 уровней аналитики и категориальной аналитики.

Таблица заголовков проводок

Заголовок проводки крепится к Docs по ключу UDN. В заголовке указан план счетов, счета дебета и кредита, ссылка документ породивший проводку.

CREATE TABLE dbo.Pass (
  UDN int NOT NULL , -- UDN код проводки
  AccId int NOT NULL , -- План счетов проводки
  Processed tinyint NOT NULL , -- Признак "проведенно"
  Acc1 int NOT NULL , -- Счет дебета (UDN-код)
  Acc2 int NOT NULL , -- Счет кредита
  Typ tinyint NOT NULL , -- Тип проводки (не расшифровывается)
  Doc int NOT NULL – Документ-основание проводки
)

Таблица комплекта (содержания) проводок

Описание аналитики (u1..u13) и сумм (i, s, v) в проводке содержится в таблице Complect. Она связана с проводкой по ключу UDN.

Следует заметить, что в системе NEXUS проводки обладают уникальным качеством. Они множественные на уровне архитектуры. Имеется в виду то, что проводка может содержать не как обычно набор-строку аналитик и сумму, а целую таблицу наборов аналитик и сумм. Например, проводка к накладной проводит одна сразу весь набор товаров, а не серией в 20-100 проводок как системах типа 1С. Данный подход позволяет достигнуть высокой скорости формирования и проведения проводок.

CREATE TABLE dbo.Complect (
  ComplectKey int IDENTITY (1, 1) NOT NULL , -- Код строки комплекта проводки
  UDN int NOT NULL , -- Ссылка на код проводки (Pass.UDN)
  u1 int NOT NULL ,
  u2 int NOT NULL ,
  u3 int NOT NULL ,
  u4 int NOT NULL ,
  u5 int NOT NULL ,
  u6 int NULL ,
  u7 int NULL ,
  u8 int NULL ,
  u9 int NULL ,
  u10 int NULL ,
  u11 int NULL ,
  u12 int NULL ,
  u13 int NULL ,
  i float NOT NULL , -- количество
  s money NOT NULL , -- сумма в учетной валюте
  v money NULL -- сумма в валюте документа
  doc int
)

Грануляция дат (номера периода для сальдовых отчетов)

Сальдовые отчеты всегда рассматриваются в определенном интервале дат. Конечно можно учет по датам вести в формате datetime или суррогате varchar (что-то типа '19990102', как в ForSale и 1С). Однако, зная что сальдовый учет ведется с неким минимальным периодом (день, неделя, месяц), то более производительный вариант будет использовать в для учета номера периодов, так называемые "грануляции периодов". Для их описания служат следующие таблицы.

Таблица-заголовок объекта грануляции

CREATE TABLE dbo.Gran (
  UDN int NOT NULL ,
  Closed int NOT NULL , -- Номер закрытого периода
  Origin tinyint NOT NULL , -- Вид грануляции (день, неделя, месяц,...)
  Auto tinyint NOT NULL – Автоматическое наращивание номеров периодов
)

Таблица описания периодов и их номеров

CREATE TABLE dbo.GranDates (
  UDN int NOT NULL ,
  Cindex int NOT NULL , -- Номер периода
  d1 datetime NOT NULL , -- Начальная дата
  d2 datetime NOT NULL -- Конечная дата
)

Заголовок счета

В NEXUS счета, как и любые другие документы, связываются по UDN. Номер и название счета хранятся в Docs.No и Docs.Name. Остальная информация описывается в отдельной таблице связанной по ключу UDN

CREATE TABLE dbo.Acc (
  UDN int NOT NULL ,
  AccId int NOT NULL , -- План счетов
  Closed int NOT NULL , -- Номер закрытого периода
  Typ int NOT NULL , -- Тип счета (активный, пассивный, активно-пассивный, забалансовый)
  Cache smallint NOT NULL
)

Описание видов аналитики на счету

Для этого имеется специальная таблица Storage, в которой в полях u2..u10 находятся UDN папок в дереве Docs, являющихся справочниками, привязанными к счету. В u1 находится ссылка на грануляцию, указывающий в какой периодике ведется учет по счету.

CREATE TABLE dbo.Storage (
  UDN int NOT NULL , -- Код счета (Acc.UDN)
  u1 int NOT NULL , 
  u2 int NOT NULL ,
  u3 int NOT NULL ,
  u4 int NOT NULL ,
  u5 int NOT NULL ,
  u6 int NULL ,
  u7 int NULL ,
  u8 int NULL ,
  u9 int NULL ,
  u10 int NULL ,
  u11 int NULL ,
  u12 int NULL ,
  u13 int NULL
)

Сальдовая таблица

Для анализа сальдовой информации имеется специальная таблица автоматически формируемая триггером при проведении проводок. В u1 находится номер периода, в u2..u8 аналитики (напоминаем, что описывается вариант без поддержки 20 уровней). Назначение полей с префиксами i, s, v приводим ниже.

CREATE TABLE dbo.Saldo (
  UDN int NOT NULL , -- Код счета (Acc.UDN)
  u1 int NOT NULL , -- Номер периода
  u2 int NOT NULL ,
  u3 int NOT NULL ,
  u4 int NOT NULL ,
  u5 int NOT NULL ,
  u6 int NULL ,
  u7 int NULL ,
  u8 int NULL ,
  id float NOT NULL ,
  ic float NOT NULL ,
  idt float NOT NULL ,
  ict float NOT NULL ,
  sd money NOT NULL ,
  sc money NOT NULL ,
  sdt money NOT NULL ,
  sct money NOT NULL ,
  vc money NULL ,
  vd money NULL ,
  vct money NULL ,
  vdt money NULL
)
Количество (дебет, кредит) Сумма в учетной валюте (дебет, кредит) Сумма в валюте проводки (дебет, кредит)
Сальдо на текущий период (u1) ict idt sct sdt vct vdt
Оборот за период (u1) ic id sc sd vc vd

Примеры запросов к проводкам и сальдо

Запрос к проводкам

Данный запрос используется при вычислении рентабельности реализации товаров. Приводится его упрощенный вид: вывести по подразделениям все проводки в дебет по указанному @Acc2, плану счетов @AccId, при этом показать аналитику "Товар" с артикулом и документ-основание.

select 
  D1.Name as _ПОДРАЗДЕЛЕНИЕ, 
  D3.Name as _ТОВАР, 
  D3.No as _АРТ, 
  D2.Name as _НАКЛ , 
  sum(C.s) as _ОТПУСКНСУММА, 
  sum(C.i) as _КОЛИЧЕСТВО
from Pass P, Complect C, Docs D1, Docs D2, Docs D3, Docs DP 
where 
  P.Processed=1 and -- Проведенные проводки
  P.AccId=@AccId and – По указанному плану счетов
  DP.UDN=P.UDN and -- Свяжем заголовок проводки Pass с описанием проводки
 
  D2.UDN=P.Doc and –- Свяжем код документа-основания с Docs, для получения его Name
  C.UDN=P.UDN and -- Свяжем заголовок проводки и комплект ее аналитики
  P.Acc2=@Acc2 and – Будем брать проводки только с кредитом счета @Acc2
  C.u6=D1.UDN and C.u2=D3.UDN and – Найдем Name и No для объектов аналитики
  DP.Date>='1.1.2004' and DP.Date<='12.31.2004' – Будем брать проводки за указанный интервал
group by D1.Name, D3.Name, D3.No, D2.Name

Запрос в сальдо

Приводится упрощенный запрос для расчета себестоимости товара: вывести отношение сальдовой суммы к количеству для указанного счета @Acc2 и товара @Good на период @ToIdx

select sum(sct-sdt)/ sum(ict-idt) as СЕБЕСТОИМОСТЬ
from Saldo S 
where 
  UDN=@Acc2 and – Будем брать сальдо по указанному счету @Acc2
  u2=@Good and -- Будем брать сальдо по указанному товару @Good 
  u1=(select max(u1) from Saldo where u1<=@ToIdx and UDN=S.UDN and u2=S.u2)
  -- Будем брать сальдо для периода до @ToIdx

Маршрут аналитики из проводок в сальдо

"Это математически сделать невозможно! Нельзя без описания типов аналитики в отдельной таблице определить, как аналитика из проводки попадает в сальдо!" (с) Очень Хороший Проектировщик

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

Маршрут аналитики – это однозначный и стандартный способ перемещения аналитики из проводки (Complect) в сальдовую таблицу (Saldo), т.е. соответствие и назначение u-полей.

Перемещение аналитики из проводки (Complect P) в сальдовую таблицу для счета дебета (Saldo A1) Номер уровня аналитики Название уровня аналитики
Дебетуемая аналитика
Pass.Doc, Date => A1.u1 (проводка делается на дату документа) G Индекс грануляции
P.u1 => A1.u2 1 1я (основная) аналитика счета
P.u3 => A1.u4 O Оборотная аналитика (корр. счета)
P.u6 => A1.u3 2 2я аналитика
P.u7 => A1.u6 3 3я аналитика
P.u8 => A1.u7 4 4я аналитика
P.u9 => A1.u8 5 5я аналитика
P.u5 => A1.u5 $ Валюта
Кредитуемая аналитика
Pass.Doc, Date => A1.u1 (проводка делается на дату документа) G Индекс грануляции
P.u2 => A1.u2 1 1я (основная) аналитика счета
P.u4 => A1.u4 O Оборотная аналитика (корр. счета)
P.u10 => A1.u3 2 2я аналитика
P.u11 => A1.u6 3 3я аналитика
P.u12 => A1.u7 4 4я аналитика
P.u13 => A1.u8 5 5я аналитика
P.u5 => A1.u5 $ Валюта

Исходный текст процедуры проведения SuperDocPass вы можете найти в файле Account.sql модуля Account, загрузив исходные тексты NEXUS.

Концепция триггера накопления статистики

В MS SQL триггер является эффективным средством организации статистических суммирующих (накапливающих) таблиц типа Saldo. Триггер получает в оптимальном виде разницу (дельту) для данных по которым ведет статистику и сразу может поправить данные в статистической таблице ровно на эту дельту без дополнительных отложенных пересчетов. Рассмотрим простой пример такого механизма.

Как уже отмечалось, проводка в NEXUS содержит целую таблицу аналитик с суммами. Поэтому когда интересен вопрос какова сумма по такой составной проводке без учета аналитик, то выгодно иметь накапливающую таблицу (кэш) следующего плана:

CREATE TABLE dbo.ComplectInfo (
  UDN int NOT NULL , -- Проводка
  sum_s money NULL   -- Общая сумма по проводке без учета аналитик
)

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

CREATE TRIGGER ComplectInformator ON Complect FOR INSERT, UPDATE, DELETE
as
  insert ComplectInfo(UDN, sum_s)
    select distinct inserted.UDN, 0 from inserted
      where not exists (
            select inserted.UDN
              from ComplectInfo
              where ComplectInfo.UDN=inserted.UDN)
 
  update ComplectInfo
    set ComplectInfo.sum_s=ComplectInfo.sum_s + (
        select sum(inserted.s) from inserted
          where inserted.UDN=ComplectInfo.UDN)
    where exists (
      select distinct ComplectInfo.UDN
        from inserted
        where ComplectInfo.UDN=inserted.UDN)
 
  update ComplectInfo
    set ComplectInfo.sum_s=ComplectInfo.sum_s - (
        select sum(deleted.s)
           from deleted where deleted.UDN=ComplectInfo.UDN)
    where exists(
      select distinct ComplectInfo.UDN from deleted
        where deleted.UDN=ComplectInfo.UDN)
GO

Таблица сальдо является достаточно сложной таблицей статистики, в которой множество разрезов, имеются нарастающие суммы, требуется обработка случаев дебетования и кредитования счетов. На начальном этапе представить себе как выглядит алгоритм, обрабатывающий большле условий человеку затруднительно. Поэтому первый вариант триггера был не написан в прямом смысле, а сгенерирован программой путем раскрытия большого количества макросов содержащих указанные условия. После того как текст триггера был сгенерирован, стало понятно как выглядит искомый алгоритм. Далее он был многократно оптимизирован, фактически такие правки потребовались сразу. Текущее состояние триггера SaldoInformator вы можете увидеть в файле KernelTables.sql.

Заключение

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

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

Владимир Иванов, Сергей Тарасов
1999, 2005 с исправлениями и дополнениями

Комментарии

"Сон разума..."

Собственно, авторы статьи приводят весьма и весьма нетривиальное решение... весьма тривиальной задачи (если речь идет о бух. учете). К сожалению, сложность полученного решения, видимо, не заставила их задуматься над тем, какую задачу они решают...
Одно дело бухгалтерский учет, совершенно иное - управленческий учет и, наконец, совершенно иная задача - это анализ хозяйственной деятельности предприятия. Можно предположить, что так была поставлена перед разработчиками задача, а разбираться было недосуг... Разбираться им пришлось по ходу дела... и не в сути, а в океане частностей.
Свалив все перечисленные ранее задачи в одну кучу, разработчики получили... то, что получили. Можно предположить, что ориентироваться в такой системе тяжеловато даже тем, кто ее разрабатывал, а эффективно сопровождать и развивать ее, вряд ли возможно. (IMHO, разумеется).

Изображение пользователя Serguei_Tarassov.

На самом деле

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

Если есть другие решения - с удовольствием посмотрим и обсудим.

Простота vs. упрощение

Боюсь, что это не простота, а... упрощение. Есть разные задачи (о них я говорил в прошлом сообщении) и все они требуют принципиально разных решений. Пытаться найти некое "объединенное" решение подобно UML, когда вместо единой теории выдали "пучок", никак не связанных между собой концепций.
Так, какую задачу хотите рассмотреть? Бухгалтерский учет? Давайте рассмотрим.
1. План счетов; /* устанавливается законодательно */
2. Корреспонденции между счетами; /* устанавливается законодательно */
3. Типы документов, регистрируемых в бухгалтерии; /* устанавливается законодательно -- частично */
4. Реальные документы;
5. Позиции документов;
6. Проводки по позициям документов.

Это основа, на которой можно строить и развивать бухгалтерию:
а) формировать правила выполнения проводок (для автоматизации);
б) формировать правила построения отчетов;
в) выполнять простейшую (бухгалтерскую!) аналитику.

Если говорить об управленческом учете, то это совсем другая задача, и ее надо рассматривать в теме управления предприятием (довольно большая тема).
Если говорить о финансовом управлении, как о части общего управления, то надо исходить из управления в целом. Понять те задачи, которые стоят перед финансистами, и, исходя из этого, создавать финансовое управление. И т.д.

Изображение пользователя Serguei_Tarassov.

Нету никакой ложки

Нету никакой ложки, то есть "пучка решений". Описанный "движок" решает узкие задачи, но на обобщенном уровне классов вроде "обьект учета", "абстрактный счет":
1. План счетов - да (устанавливается не только законодательно, для внутреннего учета может быть иным, одновременно можно использовать несколько планов)
2. Корреспонденции между счетами - да (то же самое)
3. Типы документов, регистрируемых в бухгалтерии - нет, это определяется выше уровнем
4. Реальные документы - нет, другая подсистема
5. Позиции документов - нет
6. Проводки по позициям документов - нет

Это основа, на которой можно строить и развивать любой учет:
а) формировать правила выполнения проводок (для автоматизации)
б) предоставлять данные для дальнейшей аналитической обработки

Если имеются альтернативные решения - приводите, с удовольствием посмотрим и обсудим.

Ветки у задач... разные...

Сергей, это не "движок" - это отражение сути бух. учета. Если внимательно посмотреть, то приведенная мной схема позволяет реализовывать бухгалтерию РФ, МФО, GAAP почти без изменений.

План счетов - да (устанавливается не только законодательно, для внутреннего учета может быть иным, одновременно можно использовать несколько планов)
Ни о каком "внутреннем" учете не должно быть и речи! Бухгалтерия не решает внутренних задач, она нужна только для работы с внешними организациями (гос. органами, акционерами, партнерами по бизнесу и пр.). Именно поэтому правила бух. учета жестко регламентируются государствами, а не руководителями предприятия. Это, выражаясь Вашими терминами, "внешний" учет. Внутренний (видимо, управленческий) учет совершенно иная задача. И не надо эти задачи сваливать в одну кучу.

Далее, у Вас шла речь, о... "для отчетов таких как “Движение Денежных Средств” (ДДС) и “Отчет о Доходах и Расходах” (ОДР) иметь один учетный регистр". Понятия БДДС (Бюджет Движения Денежных Средств) и БДР (Бюджет Доходов и Расходов) - это из области финансового управления, они не имеют ни малейшего отношения к бухгалтерии. Как и финансовый учет - это совершенно иной учет, отличный от бухгалтерского. К сожалению, бухгалтерию и финансовое управление часто смешивают, создавая себе проблемы на пустом месте.
Финансовое управление включает в себя финансовое планирование (формирование бюджетов будущих периодов), которое тесно связано с планами и нормативами других подразделений (их финансовое отражение). Далее, после принятия и утверждения бюджета, начинается его исполнение, включая учет, и последующий анализ. Аналогично можно представить и работу других подразделений предприятия (подсистем). Как видите, ничего общего с бухгалтерией, где нет никаких планов, и, следовательно, бух. учет для внутреннего потребления полная бессмыслица. Тем более, не имеет смысла, анализ бух. информации (с чем ее сравнивать в процессе анализа?).

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

Бухгалтерия - это не только НДС

Вы слишком узко трактуете бух. учет. Принципы учета по счетам (регистрам) были разработаны в 15 веке совсем не для генерации отчетов для налоговой, а именно как управленческий учет в современном понимании этого термина.

Технические ограничения той эпохи вынудили аналитику "зашивать" в код счета. И до сих пор многие системы, спроектированные профессиональными бухгалтерами, реализуют именно этот подход (например, Oracle и SAP). Получить, подробные данные о деятельности предприятия из "классической" Главной книги не возможно: кол-во сегментов в коде счета ограничено очень скромным числом (4-8).

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

Движок предложенный в статье позволяет преодолеть "проклятие" учета по плану счетов с сегментацией кода счета. Код счета отражает только вид операций - кассовые, банковские, складские, ДЗ, и т.д. Существенные признаки операций, сохраняются в виде аналитических срезов. В результате получается структура сразу пригодная для OLAP.

Судите сами: Saldo - таблица фактов, несколько раз соединенная с таблицей Docs (измерения). Классическая звезда. Для того, что бы помочь OLAP клиенту, делаются отдельные view для каждой роли таблицы Docs - Клиенты, Товары, Счета (в смысле регистры учета), Валюты и т.д.
Далее подключаем эту структуру в Excel и получаем готовый OLAP. Который наполняется данными в соответствии с учетной политикой предприятия, непосредственно в момент выполнения хоз. операций. Это не просто анализ операционной деятельности, это сверх оперативный анализ. Такая оперативность в других, более раскрученных системах, возможна только в виде убогих плоских отчетов, построенных по первичным документам.

Я поддерживаю системы на этом движке 10 лет - решение на удивление простое, гибкое и мощное. За это время имел близкие отношения с JDEdwards OneWorld, Oracle Apps. Шапочное знакомство с SAP.

Зеркало заднего вида

Я не трактую бух. учет... Есть законодательство, оно и определяет суть/смысл бух. учета. Принципы учета были известны еще в шумерском государстве (судя по найденным археологами материалам). "Регистры" использовались еще финикийцами (а может и до них тоже, сейчас трудно сказать). В 15 веке Лука Пачоли описал принцип "двойной записи", но вполне возможно, что не он является его автором.

Получить, подробные данные о деятельности предприятия из "классической" Главной книги не возможно: кол-во сегментов в коде счета ограничено очень скромным числом (4-8).
Дело совсем не количестве сегментов. Подробных данных в бухгалтерии быть не может, поскольку иначе все управление предприятием превратится в одну огромную бухгалтерию, и предприятие... умрет. Банально, можно ли из бухгалтерской системы получить данные по потерям от брака в производстве с разбивкой по причинам возникновения брака? А потери от простоя оборудования?.. Продолжить?

Из-за этого и возникла задача анализа хозяйственной детельности предприятия. Но по сути эта все таже учетная задача - построение отчетов об операциях на основании заданных правил группировки типов документов (такая группировка далается в ГК, но с потерей существенной для принятия решений информации).
Господа, вы живете своими представлениями... Предположим, что на основе анализа данных бух. учета мы установили, что в прошлом квартале израсходовали стройматериалов в 10 раз больше, чем за весь предыдущий год. Что из этого следует?.. Ровным счетом ничего. Просто в этом квартале началось строительство нового цеха. Мало того, строители должны были потратить больше материалов, они срывают нам график строительства, а, следовательно, цех выйдет на проектную мощность с опозданием, и предприятие понесет потери. Что об этом знает бух. учет?.. Для того, чтобы управлять, надо иметь план/график строительства, сметы, нормы расхода материалов и пр. Но ни планов, ни смет будущих периодов, ни нормативов в бухгалтерии нет.
Бухгалтерия живет прошлым (свершившимися фактами), а руководитель живет будущим - целями, планами, задачами. И анализ хоз. деятельности для него нужен совершенно не тот, что может предложить бухгалтерия. Фактические данные сравниваются с плановыми, а плановые данные рассчитываются на основании нормативов и поставленных целей. И если происходит отклонение фактических данных от плановых/нормативных, то руководитель должен видеть и понимать причины этого и способы выхода их сложившейся ситуации.
Как замечательно сказал один знакомый директор предприятия: "Управлять предприятием по данным бух. учета, все равно, что управлять автомобилем... глядя в зеркальце заднего вида".

И проблема наших разногласий в том, что мы по разному понимаем задачи, которые призвана решать бухгалтерия и те задачи, в решении которых она не должна принимать никакого участия.

Учет - фундамент управления

Управление: целепологание (планирование) - учет - анализ, далее повторение цикла. По этому вопросу мы сходимся.

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

Но остается задача управленческого учета. Откуда брать данные о фактическом положении дел, что бы анализ план/факт делать?

А факторный анализ? Без оперативных данных о хозяйственной деятельности, любые планы и бюджеты декларация о намерениях, не более.

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

Банально, можно ли из бухгалтерской системы получить данные по потерям от брака в производстве с разбивкой по причинам возникновения брака? А потери от простоя оборудования?.. Продолжить?

Это учетная задача, поэтому из учетной системы это получается легко, при правильных настройках: регистр "Брак в производстве", аналитики Период, ЦФУ, Участок, Смена, Причина брака. Дебетуется актами о браке, кредитуется документами, которые отражают судьбу этого брака - акты списания, передел, и т.д.

С простоями аналогично. Основное условие, что бы информация по браку и простоям заносилась в БД с нужной детализацией.

Вот еще набросок системы контроля за исполнением бюджетов на основе регистра.

Регистр "Бюджетные лимиты" (Период, ЦФУ, Статья). Тип регистра Активный. Регистр дебетуется в момент утверждения бюджета на суммы лимитов по статьям. Кредитуется на основании документов об одобренных затратах (заявка на затраты). Сальдо по дебету - остаток лимита по бюджету. Т.к. счет активный, то дебетовое сальдо может быть только положительным, поэтому заявка сверх лимита не сможет быть учтена, т.е. исполнена. Аналогично с корректировкой бюджета, она возможна только в рамках остатка по лимиту.

Поймите "бухгалтерский учет" не равно "налоговый учет".

Регистры, двойная запись (там где необходимо) - это универсальные учетные инструменты. Они существенно облегчают настройку и сопровождение учета (не путать с управлением).

Антиуправление

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

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

Откуда брать данные о фактическом положении дел, что бы анализ план/факт делать?
Из жизни вестимо... Причем чем ближе ввод данных к источнику появления данных, тем, как правило, точнее данные (и оперативнее их обработка). Простой пример. Рабочему перед началом смены (или в конце предыдущей смены) выдается наряд-заказ, где, в частности, есть позиция: обработать деталь А в количестве 20 шт. Рабочий обработал эти детали и отметил в наряд-заказе: обработано 20 шт, из них 2 забракованы. Кому нужны эти данные? Бухгалтеру? В первую очередь, эти данные нужны ПЭО (Планово-Экономическому Отделу), возможно им теперь придется в оперативном режиме менять производственную программу (запустить в экстренном режиме повторную партию изделий, чтобы не сорвать план выпуска продукции). Эта информация необходима технологам, чтобы проконтролировать соблюдение технологического регламента на данной операции в данном тех. процессе. Эти данные необходимы администрации, чтобы проанализировать, как работу данного рабочего, так и участка в целом. Эти данные необходимы экономистам, чтобы рассчитывая будущие производственные партии, они учитывали возможность производственного брака. Чтобы они рассчитали потери от брака. Наконец, анализ этих данных нужен руководству, чтобы оно подумало над решением проблемы устранения брака в будущем. Сами данные должен вносить или рабочий или мастер участка, закрывая наряд-заказы в конце смены.
Что же Вы предлагаете?.. Чтобы данные со всех участков всех цехов, кто-то собрал и передал в бухгалтерию, там их занесут по всем правилам бух. учета в бух. систему. Сколько уйдет времени на сбор и занесение этой информации?.. Как сохранить привязку брака к производственной партии, участку, рабочему? Кто и как потом извлечет эти данные из бух. системы, чтобы сделать их многосторонний анализ для всех заинтересованных служб? Сколько на это уйдет времени? Наконец, каков должен быть штат бухгалтерии, чтобы обрабатывать не только брак, но и другие проблемы? Понимаете мою мысль?.. Она о том, что бух. учет не в состоянии решать проблемы, но создает множество новых проблем, практически на пустом месте.

Изображение пользователя Serguei_Tarassov.

Бухгалтерия как посмертный учет

Бухгалтерия как посмертный учет - это бородатая шутка, в которой есть доля правды, относящийся к фискальной отчетности или другим официальным планам счетов. Вы почему-то не хотите признать, что упомянутый вами же GAAP как стандарт нужен не предприятию, а его потенциальным инвесторам и акционерам. Любая "официальщина" и стандарты - это прежде всего требования к учету/отчетности для внешнего по отношению к фирме использования.

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

Муки от скуки...

Вы почему-то не хотите признать, что упомянутый вами же GAAP как стандарт нужен не предприятию, а его потенциальным инвесторам и акционерам.
Хм?.. Жаль, что Вы невнимательно читаете мои сообщения. Дискуссия теряет всякий смысл... Если позволите, я свое процитирую более ранее сообщение:

Бухгалтерия не решает внутренних задач, она нужна только для работы с внешними организациями (гос. органами, акционерами, партнерами по бизнесу и пр.). Именно поэтому правила бух. учета жестко регламентируются государствами, а не руководителями предприятия.

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

Изображение пользователя Serguei_Tarassov.

Совершенно верно, муки от скуки

Вы узко трактуете понятие бухгалтерии. Не раз было сказано, что бухгалтерия - синоним учета вообще, а не только фискального.

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

Я ничуть не сомневаюсь в том, что и эти процессы можно (при большом желании) описать с помощью механизма производственного планирования. Я только сомневаюсь в целесообразности этого... действа. Этакие муки от... скуки.

Масло масленое

Зачем термину "учет" нужен синоним "бухгалтерия"... Получается, что бухгалтерский учет "масло масленое"...
(Остальное в комментариях не нуждается)

Изображение пользователя Serguei_Tarassov.

Это просто

Термин "бухгалтерский" добавляет необходимость использования принципов, сформулированных в 15 веке.

Ладно. По сути возражений нет, на сем и разойдемся.

Re: Проектирование бухгалтерии

Обсуждение по материалам статьи
Как спроектировать бухгалтерию ?

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

Изображение пользователя Serguei_Tarassov.

Да, явного определения не дает

Да, явного определения не дается. "Бухгалтерия" используется как синоним термина "учет", не обязательно финансового, конечно.
Речь идет о некоем общем подходе, ядре, которое предназначено для фиксирования фактов деятельности предприятия (хоз.операций) в денежных и натуральных показателях.
Если вспомнить классификацию систем управления, построенных "от бухгалтерии" и "от производства (MRP)", то это как раз первый вариант.

Да, явного определ

Да, явного определения не дается. "Бухгалтерия" используется как синоним термина "учет", не обязательно финансового, конечно.

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

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

Деятельность (в том числе, и учетная) имеет некую цель и средства/методы ее [цели] достижения. Управленческий и бухгалтерский учет имеют разные цели, и, соответственно, разные средства. То, что хорошо в одном случае, будет не очень хорошо в другом случае. Какие-то элементы управленческого учета не применимы к бухгалтерскому учету и наоборот.

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

С моей точки зрения, есть системы автоматизирующие деятельность отдельного подразделения, и есть системы автоматизирующие управление всем предприятием. Все остальное более или менее неудачные гибриды.