DmitryOrlovкаждый документ считать операцией или по-другому, каждая операция оформляется своим документом.
...
Если хорошенько подумать, то все должно оформляться документами и, вероятно,
нет такой операции, которая не имеет основы в виде документа.
...
Из этого можно(????) сделать вывод, что вынесение проводок в отдельную таблицу, наглядный пример лени разработчиков, которые не хотят анализировать и описывать все связи между документами и т.д.
Хотя может я и не прав и здесь скрывается какая-то страшная тайна. А кто ее узнает, сам виноват:)странная логика, не находите? мысел о документ-проводка вер-но пральная, но...
вот токо этта ваша правильная мысль хорошо моделируется _в_РБД_ снизкой таблиц-документов нанизанной на единую таблицу проводок (1-1), без дублирования значащих для проводки полей в полях таблиц-документов. что, в неком смысле, отвечает идее вынесения абстракции "проводка" в отдельную сучность, что и соответсвует принципу самого бух-учета (документ - всего лишь основание, проводка - собственно учет). т.е. таки никаких проблем с организацией проводок в сквозную таблицу нет, даже при "не слишком ленивой" разработке. Вопрос лишь в том, что ЧАЛ пользует не реляционную модель, а там, вполне вероятно, _удобнее_ (но не суть, что _единственно правильно_) пользовать какие-то внутренние структурки, а не сквозную структуру-сущность, связанную со всеми типами документов.

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

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