zeon11Если у нас есть первичка (куда без неё), мы можем используя заранее прописанные правила, сформировать любой отчёт, требуемый бухгалтером "на-лету", благо современные компьютеры очень мощны и такие запросы будут делаться очень быстро.
Если бы, если бы... Кроме конечных отчетов, выборка для которых может осуществляться почти по всей существующей в системе первички еще требуются разнообразные расчеты при внесении самой первички.
Например для корректного списания нужно посчитать существующее количество списываемой сущности.
И не забываем, что в реальной жизни в бухгалтерском учете существуют две категории измерения сущностей - деньги и "штуки". Правила же изменений денег и штук для сущностей - могут различаться. Напр - оприходование товара - штуки пошли на склад 1, а вот деньги еще нужно по этой сущности разместить на складе 1, причем минус "некое НДС", а это "некое НДС" положить на "фин результат 1".
И все это еще - во времени, с учетом что произошло "до ..., после ...,", и времени еще и не ровном, а с периодами "месяц, квартал, год - закрыт"

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

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

То же и с проводками. Какими бы ненужными, ветхими, древними (что спорно) они не казались, если они существуют в словаре предметной области, то лучше бы что такими же сущностями оперировал программист в своем коде. На уровне ли БД, или бизнес-логики в сервере приложений или клиенте - но они должны существовать.
То есть не дело программиста ломать, изменять предметную область.