Orgazm написал:
Besa написал:
Какое это имеет значение? В смысле, нет PI который бы рассплитил на два айдока, Вам принципиально чтобы было именно два айдока конкретных типов? А что если изменят только атрибут адреса, change point сработает для cremas? cremas не придется генерить искусственно?
Для инфо, в двух словах отправляли через функционал программы RMDMIDVE (как основа) айдоки типа cremdm debmdm matmdm по портам (xml file).
По change point-ам конкретно для cremdm я не настраивал, в моем понимании должно сработать. Попробуйте настроить (тр bd50/52/60).
Этого делать не надо. Вы хотите это сделать только для того чтобы RBDMIDOC сработала?
Мне необходимо чтобы сработала RBDMIDOC на ADRMAS, если кредитора например скопировали с другой БЕ, и при этом адрес не поменялся.
У нас идоки настроены так, что физически они никуда не уходят, а преобразуются в xml и эта xml улетает в веб-сервис 1С.
Сейчас оба типа идоков ( CREMAS и ADRMAS ) уходят как надо, единственная проблема - 1С необходимо получить адресные данные ADRMAS вместе с отправляемым CREMAS\DEBMAS
Если по архитектуре точки интеграции ничего уже не изменить, учитывая Ваши вводные, как вариант тр WYL2 внесет изменения в модель распределения, adrmas будет зависимым от debmas, при отправке debmas будет генерится adrmas, по сути это сериализация в приоритете адрес.
Проблема в том, что программы генерирующие айдоки на основании change point-ов это не понимают (зависимости).
Отправка через функционал bd12, то есть можно использовать ФМ CALL FUNCTION 'MASTERIDOC_CREATE_REQ_DEBMAS' (бади/экзит) передав туда номер дебитора, система сгенерит два айдока.