Расскажите кто-нибудь логику работы LedgerBondServer_RU и иже с ними ...

[TasmanianDevil]

собственно subj ...

[EVGL]

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

Пример:
1) Д62 300 р.
2) К90.1 100 р.
3) К90.2 100 р
4) К90.1 100 р

1 шаг: если (1) корреспондирует с (2), (3), (4), то получаем
(1.1) Д62 - (2) К90.1 100 р.
(1.2) Д62 - (3) К90.2 100 р.
(1.3) Д62 - (4) К90.1 100 р.

2 шаг: первая и третья строчки сливаются:
(1.1) Д62 - (2) К90.1 200 р.
(1.2) Д62 - (3) К90.2 100 р.

Когда-то я все описал с рисунками в CHM-файле к одной из версий.
Предлагаю просто оттрассировать отладчиком. Включите еще макрос #Never для вывода отладочной информации.

[EVGL]

Кое-что нашел: функциональная спецификация ко 2 версии корреспонденции:
On-line correspondence_RU.doc

Предпосылки к 3 версии (из того самого CHM):

Цитата:

Общее описание (Vision / Scope summary)

В данной технической спецификации изложены принципы работы нового механизма разноски проводок ГК и нового интегрированного блока корреспонденции.
Помимо очевидных переделок корреспонденции, связанных с тем, что HQ полностью переписала классы разноски проводок ГК, предполагается решить проблему "позднего" связывания ссылок VRef с проводками LedgerTrans. Ситуация следующая:

пусть создаются проводки в режиме суммирования

Д62 500 - К10 600

Д10 600 - К90 500

В этом случае проводки по счету 10 "сократятся", и в итоге будет проведено: Д62 500 - К90 500. Текущая система корреспонденции запоминает проводки по 10 счету и пытается найти для них реальные проводки LedgerTrans. А их нет. Для данной конкретной ситуации проблема решена, но если "сократятся" проводки по схеме 2-1, 2-2 и т.д., задачу успешной корреспонденции оставшихся проводок не решить.

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

Д62 500 - К10 600

Д10 600 - К90 500, а не две.

Это требует коренной переделки заключительных этапов корреспонденции.

[EVGL]

А также модель классов и вызовов в формате Rational Rose:
30001.rar

Буду очень рад, если кто-нибудь откроет этот файл и выложит сюда рисунки в формате GIF. У меня Rational Rose (или как это теперь называется) нет.

[belugin]

Немного об архитектуре разноски в ГК и проблеме корреспонденции счетов

[fed]

А зачем возникла потребность разбираться в ledgerBondServer_ru ? Я просто залезал туда когда-то из любопытства, но детально разбираться не стал, поскольку для прикладных задач там вроде бы менять особо нечего (все и так хорошо), а из спортивного интереса разбираться в нетривиальном коде особого смысла нет...
Есть сильное подозрение, что любую прикладную задачу можно решить без изменения кода классов корреспондирования.

[EVGL]

Совершенно согласен. В класс LedgerBondServer_ru, как правило, лезут тогда, когда что-то не корреспондируется, и отладчик приземляется в нем. Вот только проблема в 99,9% случаев не в классе, а в неправильном указании корреспонденции где-то извне в соответствующей части приложения.

[TasmanianDevil]

У нас пробовали прикрутить количество в проводки/балансы - с разносками, где LedgerVoucher работает с режимом DetailSummary:: Detail все ОК, а вот в варианте DetailSummary::Summary при слиянии проводок количество не участвует и в результирующую проводку кол-во попадает из последней в сливе.
В данном аспекте и есть интерес к данному классу, ибо, потыкамшись раз N-дцать дебаггером при разноске накладной по закупке, ясного понимания логики всех манипуляций не постиг, как собственно по классу, так и по временным таблицам для корреспонденции.

Хочется понять - стоит в этом направлении копать дальше или забросить, как безперспективное направление ?

P.S. Ноги там растут из LedgerVoucher.postGroup(), в котором на sys слое есть учет кол-ва в проводке при слиянии, а на dis модификация уважаемого EVGL( с участием subj'а) в которой объекты хоть и имеют методы передачи/возврата кол-ва, но внутри с ним никак не работают

[fed]

А ты не пробовал просто заменить суммирование по ledgerBalncesDimTrans на суммирование исходного ledgerTrans ? Просто на реальных внедрениях размеры таблицы балансов и таблицы проводок отличаются где-то в 20-50 раз. При этом время выполнения выборки по индексу ростет не по линейной зависимости от числа записей, а по логарифмической. И есть большие шансы что замена суммирования балансов на суммирование проводок не даст заметного для пользователя проигрыша в производительности...

[TasmanianDevil]

fed, нет-нет - LedgerTrans и LedgerBalancesDimTrans тут не причем, они не причина, а следствие.
В них попадает уже свернутые subj'ем проводки из накладных закупок/продаж , в которых LedgerVoucher в варианте DetailSummary::Summary, т.е. со сверткой, работает. Номенклатура у нас является одним из уровней аналитики и , в случае единичного явления номенклатуры в строках этих документов - с количеством все ОК, разная аналитика по строкам не дает свернуть. Когда же номенклатура более чем один раз фигурирует в накладной (разная цена , разная номенклатурная аналитика хранения) - образуется пара или более проводок ГК с идентичными счетом,аналитикой и пр., которые сначала сворачиваются subj'ем, а затем после свертки постятся в ГК и иже с ней. Вот на этапе свертки второй день сижу, не могу понять, как можно корректно вклиниться в семейство LedgerBond*_RU для корректного подсчета кол-ва в свертываемых проводках и передачи подсчитанного в свернутую проводку.

Там оно просто жуть, тамошняя логика реверс-инжинирингу поддается с трудом ...

[EVGL]

Понял. Решение:
1) в методе \Classes\LedgerBondTransObject_RU\splitBondTransObject разделяйте количество пропорционально чему-либо (см. "шаг 1")
2) в методе \Classes\LedgerBondTransObject_RU\mergeBondTransObject суммируйте количество (см. "шаг 2")
Все.