ln123Про ОРМ я знаю тут задача несоклько обратная т.е. я знаю как спроектировать в виде таблиц но не знаю как спроектировать с помощью классов причем так что бы задействовать те вкусности ООБД о которых тут в некоторых топиках рассуждали, к тому мне не нужно ОРМ т.к. база которую я собираюсь использовать изначально объектоно ореентированная и если я могу проектировать в терминах РСУБД то в терминах ООБД как то пока не очень получается :(. Как только начинаю думать о классах - объектах тут же задумаваюсь о хранение в таблицах и производительности в результате затык и дело не движется...

Интересно не ужели ни кто из стронников Cache не разу не проектировал бухгалтерию?

Полноприводная бухгалтерия на CACHE (MSM)
Выполняет те же задачи что и "1с"
200 штук работают в разных отраслях c 2005-2007 г

Обьектный подход выражен слабо - но развивается -
как наиболее перспективный для этого проекта.
Обьектная модель - не от CACHE

mx@enters.eu

ln123 А не могли бы вы расказать об используемых вами проектных решениях по подробнее? (1)Храните ли остатки по счетам отдельно или расчитываете на основе проводок? (2)Храните ли информацию о проводках как то отдельно или внутри других объектов (структур данных)? (3)Если вобще такое понятие как проводка в виде структры хранения?


1- год закрыт - остатки на конец года по счетам-субсчетам фиксируются

2- в течениии года ни проводки ни остатки не храним - скорость CACHE
позволяет этим не заморачиваться

3- нет - проводка возникает только в момент расчета - пересчета и потом исчезает
длина счетов на проводках неограничена
(используется Датская система 9999.zzzz.zzz.zzz....zzzzzz.zzz.zzzz обозначения счета )

все проводки - автоматические на 100 %
(кроме ввода начального сальдо на момент запуска системы)

=================

ln123 MX -- ALEX
2- в течениии года ни проводки ни остатки не храним - скорость CACHE
позволяет этим не заморачиваться

3- нет - проводка возникает только в момент расчета - пересчета и потом исчезает
длина счетов на проводках неограничена
(используется Датская система 9999.zzzz.zzz.zzz....zzzzzz.zzz.zzzz обозначения счета )


О как интересно. В каком-то из топиков данного форума некто ЧАЛ я так понимаю рьяный стороник сетевых систем косвенно упоминал о похожем подходе, мне было очень интересно, но к сожалению из него трудно что либо добиться конкретного.

1. Я правильно понимаю что есть первичные документы (и возможно еще какие либо структуры) по которым в случае необходимости на лету расчитываются проводки?

2. Каким образом осуществляется внесение изменений в документы задним числом? Т.е. бухгалтер выясняет что в документе отраженном при сдаче отчетности за прошлый месяц есть ошибка таким образом ему необходимо отсторнировать этот документ и провести исправленный документ причем это все делается текущим месяцем проводки за месяц сданной отчетности не должны изменться. Как вы этого достигаете? Я вижу два пути учитывать при генерации проводок версионность документа либо создание корректирующих документов связаных с исходным может есть еще способ?

3. Как выполняется расчет закрытия производственных счетов и расчет себестоимости? Данный вопрос вызван тем что на мой взгляд такие вещи на лету генерить не реально (эта процедура чисто расчетно распределительная и первичных документов на основе которых можно сгенерить проводки на лету нет)... т.е должны существовать какие то механизмы для хранения. Наример если у вас бухгалтер хочет увидеть все проводки за какой то старый месяц в корреспонденции Д 20 - К 25 в разрезе какой либо аналтитики то на основании чего у вас будет генерироваться отчет?

4. Если вам не сложно не могли бы вы привести пример кода отчета для моего 3-го вопроса или для например более простого отчета когда бухгалтер пытается получить проводки в кореспонденции Д 10.01 - К 60 по конкретному материалу за месяц. Если логика кода из вопроса 3 мне не понятна совсем, то здесь у меня есть определенные мысли как такое можно строить просто хотелось проверить свои идеи...

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

3 -- хранения проводок нет - но по запросу возвращает любую нужную таблицу проводок -
в том числе и за прошлые годы (все документы хранятся в базе ) ,эта таблица участвует в расчетах себестоимости (но не хранится), делается одним комбинированным запросом
из ячеек EXCEL

4 -- пример кода отчета по себестоимости- прилагается
там же пример первичного документа-обьекта на экране оператора

MX -- ALEX

пришлось делить

ln123Спасибо большое за ответы и за примеры, правда в примерах без бутылки не разобратся :) все таки SQL читается по проще хотя возможно дело привычки.

Есть еще один вопрос как вы определяете по каким документам нужно пройтись при запросе пользователем определенных корреспонденций или идете по всем?

для быстрой работы поддерживается горячий справочник
счет - обьекты
и всякие-разные оптимизаторы

в примерах не разобраться и без ящика водки :)
там язык описания обьектов - на основе MUMPS (CACHE)
SQL не используем - и рады бы но не знаем как его прикрутить к обьектам

для работы с деревьями-обьектами приглянулся именно MUMPS.
Может когда нибудь получится применить и SQL

думаю наша переписка неинтересна людям - пишите на маил

ln123 авторЯ так понимаю, плюс -- это легко получить сальдо и обороты по счёту на любую дату. Ещё какие?
А минус -- по-моему, неудобно проводки генерировать на лету, да и фактически информацию о проводке придётся хранить дважды, в дебетовых и в кредитовых счетах.

Еще то что нет ситуаций что сумма проводок разошлась с суммой по документам, и разошлась с суммой остатков на счетах. Плюс отсуствует не нужная сущьность. Плюс существует ситуации когда инфомации нужно хранить меньше чем при хранение проводок например мы проводим приходную накладную из 10 строк при проводочной системе у нас будет например 10 проводок при предлагаемой системе по одному изменению на каждом экземпляре счета, всего будет задействовано 11 объектов (10 объектов по 10-тому счету если он ведется в разрезе номенклатур и один по 60-тому)

По поводу генерации проводок на лету тут меня очень интересует мнение MX -- ALEX они почему то такую систему выбрали решив не замарачиватся с хранением проводок мне интересно почему?
А хранение информации два раза тут вопрос спорный и зависит от точки зрения на то что мы храним. В моем случае мы храним лог изменения значения счета и для каждого счета он свой.

В общем тут думать нужно, не все так просто можно например сдвинутся еще дальше и хранить изменяемые счета внутри изменяющего документа это уберет дублирование данных, но такой вариант нужно уще обдумать

Обьект - документ - хранится в базе данных
при нем методы - в том числе метод - "расчет проводок"
метод вырабатывает проводки по правилам, заложенным в специальной
настроечной таблице , правила разные для разных периодов времени

посчитанные проводки могут прикрепляются к обьекту-документу
- уже как его свойства
но на CACHE это мало повлияет на скорость в случае небольших систем
и в любом случае бесполезно при изменении правил игры задним числом
(что тоже случается)

самый крупный наш обьект производит всего лишь 17 000 документов в месяц
остальные еще меньше - поэтому нам такой вариант - "проводки на лету"
- в условиях обьектной модели и CACHE как базы данных -
представляется наиболее рациональным