После обновления в ERP интегрированной с ДО (детали см на картинках) ДО при передаче из ERP заказа на внутренне потребление (в ДО создается внутренний документ) стал очищать должность и график работы в справочнике пользователей ( в ДО), причем проблема возникает только для пользователя, под которым работаешь. т.е. если указать составителя и ответственного отличных от того под кем входили в 1С - все ОК. Вопрос у меня простой. Я, например, знаю где нужно поставить точку остановки в ДО, чтобы увидеть откуда "ноги растут". Как это сделать на работающей интеграции через IIS из ERP? т.е. нужно остаться внутри сеанса ERP
функция ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()) возвращает стек вызовов, далее можно прописать в лог журнала регистрации или куда нибудь еще. По крайней мере будет видно из каких процедур идет вызов, а там уже можно понять кто гадит
В любом случае спасибо за наводку. Ссылку не могу оставить. Тут у нас безопастники звери лютые ))
(3) тупиковый путь. Связанные объекты в бесшовной интеграции обновляются нетривиально. Данные к изменению записываются в очередь, затем формируется файл и на стороне документооборота обновляются данные. И это все формируется в фоновых заданиях. В 8.3.19 есть баг, из-за которого фоновые задания отлаживаться нереально. Флаг РежимОтладки здесь не поможет. Только время потратите
В конфигураторе в настройках подключения поставь галку автоматического подключения к веб сервисам и фоновым заданиям, тогда при передаче данных через бесшовную интеграцию произойдет остановка на выставленной точке останова.
Вам придется сначала отладку на сервере 1С включить (- debug в строке подключения для windows, поправить конфиг для linux), немного замедлит работу сервера, поэтому лучше сделать на копии и на тестовом сервере отладить, после того как включите отладку на сервере в базе документооборота включаете подключение к веб сервисам в отладке.
(4) Попробовал так сделать, а фоновые так не смог остановить хотя галку отладки на них не ставил (но это на стороне ERP). А вот попробовать отключить отладку фоновых на стороне ДО не догадался.
Решил вопрос по другому. Через искусственный вызов исключения в перехвате события "ПриЗаписи" для проблемного регистра сведений с последующей записью стека вызовов в журнал регистрации. Сразу стало видно кто "гадит", ну а дальше дело техники