Поиск виновника проблемы со стороны получателя.
Документ.ПроизводствоБезЗаказа должен уходить в односторонний обмен из КА в БП и конвертироваться в Документ.ВыпускПродукции на строне приемнике, он же БП. Но почему-то не перелетает, проблема возникла после обновления на релиз (2.5.17.74).
В базе отправителе документ прекрасно регистрируется и даже показывает журнале регистрации статус, что ушло в базу приемник.
Проверим БП, чтобы быть уверенными, что проблема не на стороне базы приемника. Со стороны БП идет отсечка по коду в модуле ОбщийМодуль.ОбменДаннымиXDTOСервер.ПрочитатьСообщениеОбмена, мешает признак "УдалениеОбъекта".
Почему этот признак сюда вообще прилетает - не понятно, документ который я использую для тестового обмена не помечен на удаление и вполне себе штатный.
Поиск виновника проблемы со стороны отправителя.
Сразу идем смотреть наши ПКО для документа ПроизводствоБезЗаказа. Пробую отладчиком провалиться в ПКО ПриОтправкеДанных для того, чтобы посмотреть, что не так с данными которые мы передаем в БП, но отладка не отрабатывает. Что настораживает и косвенно говорит о проблемах в ПРО.
Идем в общий модуль ОбменДаннымиСобытия.ПриОтправкеДанных и видим условие по результату работы функции ДанныеСоответствуютФильтруПравилРегистрации. Именно тут начинаются проблемы. Копаем в глубь.
Процедура ПриОтправкеДанных(ЭлементДанных, ОтправкаЭлемента, Знач Получатель, Знач СозданиеНачальногоОбраза, Знач Анализ)
...
Если Не ДанныеСоответствуютФильтруПравилРегистрации(ЭлементДанных, Получатель) Тогда
Если СозданиеНачальногоОбраза Тогда
ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
Иначе
ОтправкаЭлемента = ОтправкаЭлементаДанных.Удалить;
КонецЕсли;
КонецЕсли;
...
Получение результата функции многоуровневое и много раз проходится проваливаться для поиска конечного результата (ДанныеСоответствуютФильтруПравилРегистрации - ВыполнитьПравилаРегистрацииОбъектовДляПланаОбмена - ОпределитьПолучателейПоУсловию - ВыполнитьОбработчикПРОПередОбработкой - ДокументПроизводствоБезЗаказаПередОбработкойПРО)
И вот он. Запрос, который возвращает Отказ = Истина;
Процедура ПроизводствоБезЗаказаПередОбработкойПРО(Объект, Отказ)
Если НЕ Объект.ГруппировкаЗатрат = Перечисления.ГруппировкиЗатратВПроизводствеБезЗаказа.ПоДокументу Тогда
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| КОЛИЧЕСТВО(ПроизводствоБезЗаказаВыходныеИзделия.Номенклатура) КАК КоличествоСтрок
|ИЗ
| Документ.ПроизводствоБезЗаказа.ВыходныеИзделия КАК ПроизводствоБезЗаказаВыходныеИзделия
|ГДЕ
| ПроизводствоБезЗаказаВыходныеИзделия.Ссылка = &Ссылка
|";
Запрос.УстановитьПараметр("Ссылка", Объект.Ссылка);
РезультатЗапроса = Запрос.Выполнить();
Если РезультатЗапроса.Пустой() Тогда
Возврат
Иначе
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
Если ВыборкаДетальныеЗаписи.Следующий() Тогда
КоличествоСтрокВнутреннейПереработки = ВыборкаДетальныеЗаписи.КоличествоСтрок;
Если Объект.ВыходныеИзделия.Количество() = КоличествоСтрокВнутреннейПереработки Тогда
Отказ = Истина;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Сто раз перечитал сей код и не нашел ему смысла, зачем ставить флаг отказа, документу ТЧ которого равна между самой собой по количеству строк. Возможно подразумевалась проверка на неравенство (<>) или какой-то другой ТЧ, но это не точно. Но в данном исполнении Отказ всегда будет Истина. В своем решении я прост закомментировал строку кода Отказ = Истина, поставил директиву ИзменениеИКонтроль и в последующих обновлениях посмотрю, что именно хотели разработчики. Обмен заработал.
