Как для ГК операции в LedgerTrans найти соответствующую операцию в VendTrans?

[TasmanianDevil]

Recoilme, коллега, побойтесь бога такое создавать! Как человек, измученный нарзаном, (тьфу, то есть подобной конфигурацией связки двух систем и которого заставляют расширять ее до указанного Вами уровня - чем последние 4 месяца и занимаюсь) заявлю , что данное творение будет больше вреда приносить, а не пользы. Даже в конфигурации 2х Аксапт - ибо если там будет в реплицируемых данных хоть одна связка по RecId - пиши пропало либо сразу, либо в перспективе. Две же разные системы могут просто по структуре хранимых данных не срастись.

Ну а, так сказать, вдогонку про связь проводок модуля/документов/их строк с LedgerTrans добавлю, но только теперь про профили разноски и обработку ими различных документов (как раз на подходе разработка новой операции ОС, касаемо одного из видов выбытия - душа просто "поёт" от перспектив повкалывать на выходных, понастраивать профиля разноски чудные , так что промолчать сил просто нету и потому яду будет немеряно)

Допустим , имеется единое хранилище многострочных профилей разноски (профиль может быть как нормальный, генерирующий проводки, так и виртуальный, без генерации проводок в ГК - в случае смены учетной политики и пропадания/появления необходимости проведения каких-то типов документов это просто спасет систему от программерской хирургии) с разделением идентификацией по модулю/типу документа(типу операции) и связью 1 ко многим для гибкой настройки разноски документа по ГК в зависимости от нюансов операции - в отличии от текущей убогой концепции многотабличного хранения единственно возможного профиля с крайне неявной политикой подстановки как счетов, так и аналитики по операции/документу/справочнику (примитивные расширения профилей по типам группировок обрабатываемых данных вида "Все/Группа/Таблица" как в ОС и Управлении запасами - не в счет, это суть есть попытка изобрести N-угольное колесо вместо старого (N-1)-угольного в то время, когда всем давно ясно о необходимости круглых колес ). Согласно профиля, указанного при обработке документа из набора возможных в данном модуле/для данного документа, по его строкам и настройками строк этого профиля, класс-обработчик абстрактного документа порождает нужного потомка для обрабатываемого документа и производит все необходимые манипуляции с разноской в ГК.

При реализации подобной концепции профилей разноски и разноски документов в ГК по ним, а так же вышеупомянутого мной по связям документов и операций с LedgerTrans - пункты 2,3 из преимуществ реализуются на все 200 % в одной системе.