У нас налажен двусторонний обмен между базами по расписанию, но ИНОГДА на базу-приемник приходят не все объекты (вот недавно отправлено 5, а получено 2)  и при этом на базе-источнике ВСЕ отправленные объекты "слетают" с регистрации. Не так сложно, конечно, зарегистрировать повторно (и тогда всё приходит), но нельзя же непрерывно контролировать. Что может быть причиной такого поведения?

Расписание для БазыА (источника в указанном случае): каждый  день; с 8:00:00 по 22:00:00 каждые 600 сек., повторять после завершения через 300 сек.

Расписание для БазыБ (приемника в указанном случае): каждый  день; с 8:05:00 по 22:05:00 каждые 600 сек., повторять после завершения через 300 сек.

Одно время грешили на то, что регламентные задания слишком близко начинали выполняться по времени, разносили (через 5 минут). (Тогда еще " повторять после завершения через 300 сек" не было выставлено). Вроде начинало всё работать. Потом опять случался прокол. Потом я выставил "повторять после завершения через 300 сек.". Думал, что это решит проблему. Но вот указанный выше случай произошел при нормально разнесенных по времени регламентных заданиях

Не думаю, что это важно, но сообщаю, что обмен идет между Управление холдингом, редакция 1.0  (1.0.7.26) (БазаА) и Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.43.52) (БазаБ). Платформа 1С:Предприятие 8.3 (8.3.8.1652)

Конфликт блокировок например.

(0) Посмотри в предупреждениях синхронизации в БП

"на базу-приемник приходят не все объекты" // Так и должно быть. В чем вопрос-то?

(0) Как разруливаются коллизии? Возможно в приемники эти объекты тоже изменены и внешние изменения не принимаются.

(4) В приемнике запрещены изменения (указанных в рассматриваемом случае объектов)

(2) Нет никаких сообщений, на данную дату

(3) Не понял недоумения. Под объектами я подразумевал (в данном контексте) выгруженные элементы справочника Договоры. Т.е. из 5-ти договоров пришли 2

Баз-копий приемника нет, а то может они забирают часть файликов

Аналогичная проблема была) Обмен по регламентным заданиям? На сервере? Может при записи где то директивы "&НаКлиенте"?

Возможно где-то срабатывает отказ=Истина в правилах обмена?
Я добавлял логи в технологический журнал - так вычислял...

(8) идея интересная. Можно посмотреть, проверить. Только из ОДНОЙ выгрузки 2 из 5-ти то пришло :)

(9) тогда по идее загрузка должна завершаться ошибкой, а источник не должен снимать регистрацию

(1) Пока это наиболее "рабочее" предположение. Вопрос: а как это проконтролировать?

(10) эти 2 могли прийти раньше/позже

(11) Вот, вот. И я о том же :)

(9) Да, на сервере, регламентными. А вот это:
"Может при записи где то директивы "&НаКлиенте"?"
поясните, пожалуйста.
ГДЕ именно?

И по-прежнему остается вопрос: ПОЧЕМУ слетает регистрация? Как у Вас было?

ПОЧЕМУ слетает регистрация?

Она не слетает, она обнуляется. Видимо у вас загрузка в базу-приемник выполняется не в транзакции, или в транзакции не обрабатываются ошибки загрузки.  
Соответственно даже если ошибки загрузки происходят, обратно все равно отправляется обменник с подтверждением удачной загрузки, который и обнуляет регистрацию в базе-источнике.

(16) Спасибо за ценную мысль. Но если из-за одного объекта отказывать в удачном переносе для ВСЕХ остальных было бы неправильным. так можно вообще остановить обмен. А интересно, существует ли механизм, который позволяет снимать с регистрации (да, пусть обнулять :)) ОТДЕЛЬНЫЕ объекты

(17) в типовых как правило есть обработка "регистрация изменений для обмена"

(17) Нет. Стандартной типовой процедурой обмена нет.
Каждый обменный файл (условно назовем его пакет) имеет свой номер. Так вот, ответный обменный файл с подтверждением удачной загрузки не содержит информацию об объектах(загруженных или нет), он тупо очищает таблицу регистрации изменений по номеру отправленого пакета.

(19) Увы! Это я тоже знаю :(

Только вот как сделать, чтобы при неудачной загрузке в базе-приемнике ОДНОГО объекта, регистрация ИМЕННО ДЛЯ него не слетала?
Кстати, для (18). Я неудачно сформулировал в прошлый раз вопрос, поэтому и получил Ваш ответ. :) Очевидно, что для моего случая эта обработка не поможет

(21) Может начать с выяснения причин незагрузки?

:) Хороший совет. :) Только "поймать" я эту причину не могу никак. В один из прошлых раз ее причиной было массовое перепроведение документов в приемнике (и как результат, очередной сеанс в базе-источнике не "успевал" за выгрузкой из базы-приемника; обмен то двусторонний). Но, я полагал, что добавлением "повторять после завершения через 300 сек.", я эту проблему решил. Оказывается нет

Точнее я, полагаю, решил причину "не успевал". А вот проблему незагруки - нет :(

(21) Такие "проблемные" объекты, которые могут не загрузиться, рекомендуется передавать через отдельный план обмена.

(21) ключевым здесь "проблемные". Не совсем понятно, что к ним отнести. Пока у нас обмен массово идет только по справочникам (Договора, Контрагенты, Счета к/а). И по статистике (% незагруженных ОЧЕНЬ мал) другие объекты и не проявляются. А вот когда пойдет обмен документов, есть вероятность, что и они "посыпятся"

(7) Еще раз: в чем вопрос-то?

(27) Суть проблемы: в базе-источнике зарегистрировано к обмену 5 объектов, все 5 отправлены, загрузилось в базе-приемнике 2, при получении квитанции в базе-источнике ВСЕ 5 объектов снялись с регистрации

(28) Дебажь загрузку.

(28) Как отлаживать загрузку в on-line? В обработке "Универсальный обмен..." -  всё ясно. При попытке отладить даже если ставлю на точку останова проверяет является ли режимом отладки обработчиков загрузки и запускается Выполнить(ТекстАлгоритма). Вот это место:
Если ОтладкаОбработчиковЗагрузки Тогда
    ВыполнитьОбработчик_Конвертация_ПослеЗагрузкиПараметров(ФайлОбмена, Отказ, ПричинаОтказа);
            
Иначе         
     Выполнить(ТекстАлгоритма);
КонецЕсли;

Как установить режим отладки обработчиков загрузки?

обмен типовой? нет варианта перенастроить его на прямое подключение?
(30) подключите отладку фоновых заданий.

(31) Обмен по оригинальному плану обмена. Понятно, что по БСП, но правила оригинальные. Отладка фоновых подключена (+ еще и внешние на всякий случай подключил; может не надо?).

(32) А в этих оригинальных правилах в обработчиках может что-то через Попытку-Исключение делается?

Кстати, ЭТУ ошибку удалось побороть (точнее устранить причину): не переносился параметр из выгрузки в загрузку, ну и на пустой объект так реагировала система. Оказывается ТЕПЕРЬ нельзя параметры ставить в Конвертации (на закладке). Если ставишь "Выгружать в загрузку" автоматически предполагается, что параметр надо вводить в диалоге. А у меня программно заполняется. Убрал из закладки, вставил найденную в интернете процедуру ПередатьОдинПараметрВПриемник(Имя, Значение).

Но после этого появилась ошибка
'Ошибка формата сообщения обмена.'

Ошибка возникает при проверке
ФайлОбмена.ЛокальноеИмя <> "ДанныеПоОбмену",
т.к. в файле  
ФайлОбмена.ЛокальноеИмя = "ИнформацияОТипахДанных"

Не знаете, в чем дело?

(32) А в этих оригинальных правилах в обработчиках может что-то через Попытку-Исключение делается?

А на что это влияет? Правила сложные, писаны моим предшественником. Но ЭТА ошибка (как я указал в (34)) возникает из-за пустого параметра. Меня В ПРИНЦИПЕ интересовало на будущее: как поставить в Истину параметр ОтладкаОбработчиковЗагрузки? В настройке узла я вижу новые возможности запуска отладки загрузки, только непонятно как ими пользоваться. В Универсальном обмене всё было по-другому

(31) Вариант перенастроить на прямое подключение отпадает. Мне досталось "дорабатывать" обмен на этапе запуска проекта, а сам проект выполнял другой человек

(28) Я вроде бы уже ранее ответил, что так и должно быть, т.е. это не проблема. Вопрос-то будет?

(11) Если было не исключение, а явное указание Отказ=Истина где-то в ПВД или ПКО, то загрузка проходит все равно успешно и высылается квитанция о доставке; так что кури правила обмена.