вот ...еще ....думку подумать...

- Многомерный План счетов. (Главная книга, бюджетные счета, аналитические, ресурсные....) ...любой документ способен... генерить проводки на произвольное кол-во планов счетов...

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

- 4 измерения - ПЛАН, ФАКТ, ПЛАН-НА-ФАКТ, ПРОГНОЗ. Провести документ – значит изменить "состояние его измерений". Любая проводка всегда изменяет ПЛАН или ФАКТ или ПЛАН-НА-ФАКТ или ПРОГНОЗ....( как это юзать реально честно говоря еще плохо понимаю...)

Касательно субсчетов и субконто. Нужно и то и другое. Субчета - очень просты для бухгалтера....их легко "добавлять" и на атомате получать отчетность.

Субконто - удобно для аналитики в разрезе ресурсов. Когда каждый ресур - есть новый субконто. Это - все для Менеджеров, что хотят получать инфо из бух_учета.

Если ввести в ситему надстройку - ТАБЛИЦА Синонимов - то можно легко обойти эти противоречия.

Таблица - хранит в себе классификатор Субсчетов и Субконто, так что, конечному аналитику будет абсолютно все равно - что там было внизу - субконто или субсчет.

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

Когда часть инфо бралась путем анализа суб_счетов, а часть - "субконто" (точнее инфо о движении ресурсов).

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

Доказано реально - что при помощи такой Таблицы - обработка любых данных бух_учета для целей анализа - возможна "за 1 селект", без юзания какой-либо "расчетной" процедуры.

Хорошо. Есть расходный (приходный) кассовый ордер.
Его сумма может делится на части (до 8).

Вопрос философский, но ИМХО зависит от вашей среды разработки.

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

Такое описание проводки - удобно иметь в виде пакета строк. В этих строках прописаны... Имена Полей (айтемов) + Коды + Инструкции....

Коды - удобно - понимать под этим как Коды Субконто.

Инструкции - ИМХО можно смело писать в терминах языка программирования, или в терминах макросов...или в терминах "выпадающего списка".

Если нет - тогда вам проще в скрипте, "одним инсертом", заполнить 8 полей (строк) аналитики...жестко привязав их к субчетам.

Замечание - Таблица синонимов - - стирает различия между этим. Ей - все равно.

таблица синонимов...

Ну хочу я, например узнать из бух_учета сколько ресурса было списано на себестоимость...значит открываем проводки ...дебет 20-31 счет, кредит - почти все остальные.

Субсчет типа 10.01 - ресурсы хорошие
Субсчет типа 10.02 - ресурсы плохие...
....
Отчет должен получиться в терминах
ресурс 1 ....
ресурс 2 ....

Если сразу есть субконто - то все само получится

Если нет - делаем таблицу синонимов

ресурс 1 , субсчет 10.01
ресурс 2 , субсчет 10.02

И на селекте - ее юзаем (джойним то бишь к проводкам)...
И все становится все равно.

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

мне почему-то кажется что в плане счетов не должно быть более чем 150-200 строк, 150 - это даже и много...судя по вашей фразе, вы в плане счетов как то отразили табельные номера сотрудников -если так - то вы "ПОПАЛИ".

Табельный номерочек (в ID своем коде) эта такая фишка что для одинаковых людей должна быть ВСЕГДА разная....чел может уже давно уволиться - а мы все помним его ID и таб_номер что был у него. И все что по нему расчитали когда-то - все хранить надо долго...