Разноска накладной по большой закупке

[belugin]

Это моё.

SubledgerJouralizerBondExtension написан так, чтобы быть расширением для SubledgerJournalizer.

SubledgerJouralizer в данной фазе обрабатывает distributions и генерирует по ним subledger согласно AccountingRules. Для этого он сначала вставляет во временные таблички

SubledgerJouralizerBondExtension не может дополнить уже готовый сабледжер. Так что ему приходится действовать двумя путями: либо говорить SubledgerJouralizer не делать этого (см использование SysEventOverride ) либо вытирать то, что сделал SubledgerJournalizer и вместо него писать свое.

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

Вы можете попробовать закомментить код в SubledgerJournalizer.recordSubledgerJournalAcctEntriesDist кроме вызова события.

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

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

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

[trud]

Цитата:

Сообщение от belugin

либо вытирать то, что сделал SubledgerJournalizer и вместо него писать свое.

Тут еще проблема что не учли как работает SQL Server и Optimistic concurrency control, т.е. если при паралельных update все это нормально разрешается, то при delete сессии просто блокируются

Цитата:

Сообщение от belugin

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

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

Причем ксати это не единственный момент, более простой случай при разноске отборочной накладной - т.е. в какой то момент запускается метод подсчета накладных расходов по строке (при том что накладных расходов в моем примере вообще не было).
Перед этим он решает посчитать итоги по закупке(а чтобы это сделать надо опять же пройтись во всем строкам закупки), Получается для 1000 строк надо сделать миллион проходов
В 2012 лечится довольно просто - надо в класс подчета итогов purchTotalMarkup передать стандартный параметр - кешировать результат.
В D365 думаю будет веселее, код там остался