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

При всей парадоксальности этого факта бухгалтерские данные обычно не используются для управления в режиме реального времени. Очень часто на столах по утрам какие-то разрозненные но полезные цифры  (отгрузки, оплаты), а бухгалтерия живёт своей жизнью, закрывая периоды после многочисленных сверок и получая, конечно, полезную и точную информацию но с задержкой от дней до недель.
Чтобы уйти от этой проблемы в своё время была придумана такая штука как тип счета. Бухгалтерский счёт это ведь всего лишь хранилище каких-то оборотов по дебету и кредиту. Что-то может прояснить его название. Более того, человек прекрасно понимает что такое «Расчётный счёт»  а что такое «Подотчёт». А вот для машины это всё одно и то же. Вот этот тип счёта и «объяснял» машине, чем является этот счет. Точнее объяснял он, а какую строчку этого списка засовывать обороты по счету определённого типа:

Это позволяло получать информацию сразу, до закрытия периода. Желтым на картинке расставлены номера счетов. Ведь номер можно взять любой. Пусть номер счета «Доход» будет «01»,  номер счета «Расчетный счет» - «10»., а номер счета «Касса» - «11»
Пусть на дороге нашли 100 рублей и принесли их в кассу. Тогда проводка будет Дебет (приход) сч 11 «Касса» Кредит сч 01 «Доход».
Увеличение доходного cчета по кредиту – самое нелогичное что есть в бухгалтерии, но это можно просто запомнить и торжественно постановить, что для счетов типа «Доход/расход» плюсы считаются минусами и наоборот. Просто потому, что так удобно. 
Тогда найденные 100 рублей из проводки Д 11 К 01 100 рублей распишутся по таблице так:

По этой странной картинке я cразу вижу что, во-первых, у меня увеличился остаток в кассе на 100 рублей (что приятно). Во-вторых, что это был доход а не деньги с депозита или из взятого кредита.
В базе у меня есть несколько таблиц. Вот их названия: CSUB_CUL_PFEA_D, ZF_D, CSUB_CUL_PFEA, RNK_BU, ZF_R
Эти названия так же ничего не значат для человека как для машины ничего не значит номер бухгалтерского счета. Это просто таблицы с суммами. Просуммировать можно в любой момент. И зная что
CSUB_CUL_PFEA_D – план доходов,
CSUB_CUL_PFEA – план расходов
RNK_BU – договора на расход
ZF_D – платёжки на приход
ZF_R – платёжи на расход
… можно получить всю информацию не городя никакого огорода. Теоретически это так. Практически это почти так для одного учреждения. На самом деле и для него таблиц больше. А ещё там возникает проблема, о которой ниже.
Я попробую придумать план счетов для информации этих таблиц и записать суммы по ним во всё тот же список. План счетов это ведь не то что какое-то начальство придумывает. Это учетный аппарат с формулой «Дебет X Кредит Y». В чернухе для каждого объекта иногда свой удобный для него вариант плана придумывают.
Все суммы и операции по перечисленным таблицам выглядели бы, например,  так:

Слово «например» важно. Потому что я имею полное право считать доходом только разность полученных и потраченных денег, но мне захотелось «назначить» прибылью разность планов по доходам и расходам.
В первой операции я как раз планирую доход на 100 рублей. Но денег-то у меня на расчётном счете пока нет. Потому я вынуждена повесить своеобразный долг на нерасторопную внешнюю среду, постановив, что прибыль у меня уже есть, только на не в кармане, а где-то за его пределами.
Во второй операции деньги (95 рублей) ко мне приходят, но эта операция уже никак не меняет прибыль а только вызывает перераспределение сумм по «карманам». Деньги перемещаются из придуманного долга на расчетный (лицевой) счет.
Жирновата прибыль и в третьей операции я её уменьшаю на запланированные расходы. Тоже пока никаких движений реальных денег, только взводится ещё один долг, на этот раз наш перед теми, кому запланировано отдать все деньги.
Четвёрная операция это заключение договоров. Часть неисполнения бюджета (остаток сч.09) переходит в зарезервированное состояние (сч.07). Остаток по этому счету =-80. Это вроде как уменьшение денег на лицевом счете (потому минус), но ещё не состоявшееся (состоится оно только в операции №6).
А операция №5 – это прямая оплата без договора. Зарплату, например, так выплачивают.
Теперь про то, зачем мне это всё, зачем мне из этих пяти (пусть десяти) «кубиков»-таблиц городить какое-то сооружение.
А затем что цифры у меня примерно так выглядят:

За счет двухуровневой системы лезет пересортица кодов. Одна и та же цифра попадает в разные строки.
Или лучше здесь:

Сумма, упавшая в район, уже в нем размазывается на реальные экономические статьи (211, 212 и т.д). Для передающих это общая туша передачи кому-то денег (статья 241). Общая сумма-то совпадает, но всё это странным образом размазано по таблице и общие фильтры для этой общей информации не работают. А хочется-то видеть полную картину и по всё той же одной кнопке а не с помощью кучи выборок-фильтров
С предпринимательской деятельностью (деньги, заработанные учреждением)  примерно так же по сути но иначе по нестыковкам и отсутствию информации:

Если в бюджетных деньгах я ещё могу просуммировать по разделу и целевой статье, то тут в ZF_D даже раздел (означающей отрасль) не хранится. Это не означает что его нельзя найти. Здесь, например, он интуитивно угадывается. Но мне-то то надо чтобы это всё машина выбирала.
Дело, скорее всего, в том, что несколько лет назад «Казначейство» работало иначе. Сейчас в ту же структуру базы вогнали нечто двухуровневое (т.е район, а под ним учреждения). Формально это бОльшая гибкость. Уже  район может распределять сумму по каким-то своим статьям. Но программа-то изначально была рассчитана на строки, по которым можно ставить фильтры. Пропадает или меняется информация – сумму не собрать. Точнее собрать вообще всё по учреждению (общей суммой) можно, но интересны-то подобности. А информации нет, она теперь «дырявая». Район, например, сейчас кассовые планы по учреждениям сам рисует в Excel-е. раньше они были в «Казначействе», а теперь там только суммы по районам.
В «Казначействе» можно из любой таблицы выдернуть суммы по любому фильтру. А потом можно как угодно их расставить на Excel-евском листе, т.е доступ к информации они дали (через те сааме OLAP-кубы, выбирайте себе что хотите). Но я-то не хочу резьбой по Excel-заниматься. Я хочу чтобы машина мне собрала полную информацию по одной кнопке. А она это может сделать только если есть структура – надстройка над таблицами, имена которых не важно что означают. А программную структуру лучше всего делать когда есть логическая надстройка иначе это будет как в Excel-е (ос всеми плюсами и минусами), т.е выбрать почему-то отсюда это и к нему просуммировать (почему-то) это. Такие вещи очень плохо реагируют на изменения, например.
Не знаю, насколько понято то что я написала, но я старалась))). Этих таблиц там больше, конечно. Фильтры по строкам не работают (точнее работают как показано). Возможен (вроде бы) выход в  двойную запись и переход от фильтров к оборотом и остаткам. В этой форме-структуре (изначально более сложной) всё, по идее, должно быть логично и аккуратно.