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

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

LSVЕсли у нас есть первичка (куда без неё), мы можем используя заранее прописанные правила, сформировать любой отчёт, требуемый бухгалтером "на-лету", благо современные компьютеры очень мощны и такие запросы будут делаться очень быстро.Мож лучше в армию сходить ? :)

Теоретически - можно. Но на практике это будет крайне долго, монструозно и ненадежно.
Н-р банальная урезка базы первички сведёт все потуги на нет.

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

Дискуссия пошла, и это хорошо.

Позвольте опять уточнить свою позицию.
1. Мы все находимся на сайте SQL.RU, и поэтому, априори, мы все здесь в большей мере специалисты по БД и информационным системам, чем по смежным дисциплинам, в частности, бухгалтерии.
Одно из основных требований к БД информационной системы - это то, что информация в любых её частях между транзакциями должна быть непротиворечива . Если каким-либо образом меняется первичка, а баланс который якобы построен на этой первичке остаётся прежним - то как мне кажется грош цена такой ИС. Т.е. с точки зрения специалиста БД, в информационной системе для соблюдения целостности либо должен быть тотальный запрет на изменение первички, что достаточно легко реализуется, либо каскадные изменения всего и вся, если всё-таки такие изменения требуются.
2. БД должна быть нормализована и это для нас, специалистов по БД закон. Т.е. по требованиям нормализации никаких промежуточных итогов в принципе не должно быть. Конечно-же, в мире не найдётся ни одного практикующего архитектора БД, который бы не делал денормализацию. Но, как говорится, чтобы нарушать правила, их надо очень хорошо знать.
Если-же посмотреть на кишочки БД любой бухгалтерии - то там практически сплошная денормализация, мало того, денормализация - это жёсткое требование.

Итак, по п.1 и 2: чтобы построить ИС для бухгалтерии, мы должны отринуть основополагающие принципы построения БД?

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