Добрый день.
Описание ситуации:
Есть две базы БД_Источник и БД_приемник, обмен через xml, изменения регистрируются на ПланОбмена. Из БД_Источник отправляем документы (в фалйе xml) для БД_приемник. База БД_приемник их обрабатывает допустим 9 из 10.
Нужно чтобы при следующем обмене из БД_Источник отправился только 1 (тот что не обработался раньше), плюс новые документы зарегистрированные на обмен.
Подскажите где можно посмотреть и есть ли вообще такое в типовых конфигурациях?

вообще это на автомате выполняется за счет тикетов о получении пакета.

посмотреть можно
план-обмена/состав-отправляемых-данных

для большего понимания нужно не просто просить про Типовые, но указывать насколько "старые" или "новые" интересны.
Т.е. версию БСП желательно указывать.

(0) "Нужно чтобы при следующем обмене из БД_Источник отправился только 1 (тот что не обработался раньше)"

Оно так не работает. Источник (пока не получит выгрузку из приемника) не может знать, что принялось, а что нет. И выгружает все. После получения ответа от приемника то что уже обработано снимается с регистрации. Остаются только изменения с номером сообщения выше уже обработанного.

(0) Пакет либо отработан целиком, либо не отработан целиком. Если в передаваемых Пакетах содержатся слишком громоздкие пакеты, которые долго обрабатываются, сбоят, требуют повторной выгрузки, то на уровне типовых такого механизма замечено не было.

Я бы написал свою процедуру выгрузки в обработке, которая формировала бы очередной пакет только с ограниченной порцией данных. Но это превратить весь обмен в окончательно асинхронный процесс - задолбаются передавать.
Поскольку это будет очередь на отправку, в которой следующий пакет в отправку пускать нельзя, пока не придет ответка от получателя по предыдущему пакету.

(0) Ключевой вопрос: почему обрабатывается 9 из 10? Так запланирована и это не ошибка? Если так запланирована - то это плохое планирование :)

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

А если говорить в общем случае, то в типовых конфигурациях, в типовых планах обмена используется принцип "всё или ничего"- по умолчанию обмен идёт в транзакции. Если база-источник не получит подтверждение - то все объекты вновь будут отправлены в обмен.

Там еще проблема не только на стороне Отправителя, но и на стороне Получателя, в котором ВЕСЬ пакет в приемке идет как _1_ транзакция.

(4) В обмене отправляются не связанные друг с другом документы. И поэтому если 1 из 10 не пришел то ничего страшного, его можно передать при следующем обмене вместе с другими документами.

(7) не может прийти только 1 из 10, если все 10 были в одном пакете.

(6) причем обмен в котором мы загрузили 9 из 10 нужно считать успещным и для узла менять номер полученного пакета.

(7) Ничего "страшного" - Вы так считаете? А если подумать?

Есть такая фишка у типовых: поддержка целостности и не противоречивости данных. Легче отвергнуть всё, чем принять часть информации.

PS: теоретически можно такое реализовать, это не сложно. В подтверждении получения пакета можно отправить игнорирование регистрации изменений для таких объектов и на стороне базы-источника этот случай можно поймать и обработать за счёт повторной регистрации изменений.

(10) в моём случае, если один документ из 10000 не загрузился, то ничего страшного нет, страшно что документы будут накапливаться и обмен загнется.

(9) Увы, если это типовая и не испорченное поведение Обмена на стороне Получателя (не было шаловливых ручек программиста), то не примется 9 объектов из 10 , если все 10 объектов были отправлены в одном пакете (хмл-файл  обмена).

(11) в принципе как реализовать есть идеи. Хотелось бы посмотреть пример из типовых как там реализовано (если есть конечно такое).

(14) Если подобное где-то есть, то это будет "ручная" регистрация объектов на выгрузку. Именно на выгрузку.
На стороне Получателя в типовых - только Транзакция, только Хардкор.

(15) Понятно.

(0) Никогда ещё такое не поддерживалось в 1С.

(15) При ручной установке легко получить нецелостность базы.

(15) Просто алгоритм и ничего более, просто типовая УПП:

Процедура ПриОтправкеДанныхГлавному(ЭлементДанных, ОтправкаЭлемента)
    
    Если ТипЗнч(ЭлементДанных) = мТипСправочникРегОтчеты Тогда
        
        ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
        
    КонецЕсли;
    
КонецПроцедуры

мТипСправочникРегОтчеты = Тип("СправочникОбъект.РегламентированныеОтчеты");

*(19) В типовой конфигурации УПП к этому справочнику регламентированных отчетов свои особенные отношения.

Кстати, рекомендую в своих конфигурациях глобальным поиском поискать ".Игнорировать". Некоторые будут удивлены :)

Всем спасибо)