Всем привет!
Такой вопрос - кто-нибудь делал сабж или может есть в БСП такое? Может какие подводные камни?

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

В ответе РИБ нет отчёта по каждому объекту. Только по всему пакету целиком.
Поэтому тебе писать свой механизм

(1) Это я понимаю, поэтому и спрашиваю, может я не углядел в типовых механизмах (например БСП) такого, или может кто писал такое. И взлетит ли вообще такое

Нужно список того, что нельзя загружать "по некоторым условиям" передавать в источник (в рамках того же обмена или отдельного). И при выгрузке это не выгружать.

(0) в ответном тикете передаешь список незагруженного, очищаешь узел по номеру в тикете, незагруженные заново ставишь на регистрацию

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

"в пользовательском режиме устранять проблему данных" // Не нужно управлть регистрацией в пльзовательском режиме

Нужно просто список ошибочных объектов (тех, которые в приемник не загрузились и были пропушены) передавать в источник. А что уж в источнике с ними делать - включать в следующую выгрузку или удалять из очереди, решает пользователь.

если их нельзя загружать, то может и не выгружать вовсе?

(6) Почему, какие могут быть траблы?
Данные не загружены в приемнике, пользователь должен устранить проблему в источнике

(8) При выгрузке ты не знаешь, что из выгруженного загрузится, а что - нет. Поэтому у пользователя должна быть работа со списком ошибочных объектов в источнике. По умолчанию тупо включать эти объекты в очередную выгрузку, пока пользователю не надоест получать отчет-уведомление со списком ошибочных объектов каждый раз.

(9) Должен быть промежуточный буфер, с которым работает пользователь. Содержимое этого буфера включается в выгрузку (регистрируется). При удалении пользователем объекта из буфера снимать регистрацию.
Без буфера ты не сможешь отделить для пользователя работу с ошибочными объектами в плане регистрации.

(11) Был опыт реализации такой функциональности?

(0) Как ты собираешьтся "отвергать" удаление объекта или запись пустого регистра при его очистке?

(12) Да. Схема рабочая.

(13) Отвергать в источнике? Как мне кажется, проблема только в представлении этих данных для пользователя в буфере ошибочных данных

+(13) Хотя проблема и в хранении таких данных. Как лучше хранить нессылочные данные в буфере (подозреваю, что это будет РС)?

(0) "По некоторым условиям в приемник нельзя загружать некоторые данные"

Это можно легко решить сделав подписку на события

ПриОтправкеДанныхПодчиненному
(если нужно не выгружать данные в узел)  
или
ПриПолученииДанныхОтПодчиненного
(если нужно не загружать данные)

(12) См. (14) + личный опыт (уже не связанный с тем товарищем) тоже имеется

(16) Очевидно же - хранить ключ

(17) В этом случае не нужно морочить себе голову как снимать регистрацию объектом для обмена. Пусть себе будут зарегистрированы. Подписка  не даст им выгрузится или не даст загрузиться.

(19) В каком виде хранить? А если, к примеру, структура РС изменится (добавится измерение)?

(21) В сериализованном, например

(22) При изменении структуры обратная сериализация не пройдет :-(
Хотя у меня пока только ссылочные данные в обмене

(23) Так хранить нужно структуры ИмяПоляОтбора-ЗначенияПоляОтбора.

(24) Да, понял, спасибо.
Удаление объекта как ссылку с признаком удаления хранить?

(23) Это смотря как сделаешь сериализацию и десериализацию. Конечно же не о платформенной речь.

(25) За удаление разъясни, где оно создается и где планируется его использовать

(27) Удаление объекта - это скорее уже из теоретических изысканий. Не представляю пока, зачем отказываться от удаления в приемнике.
Но если все таки такое может быть, то удаление объекта создается в том же источнике и отказ от удаления в приемнике

Пятница, вечер...
- Ничего не понимаю!
- Аналогично, шеф!

Зачем отправлять из источника то, чего нельзя принять в приемнике и зачем сохранять регистрацию этого безобразия?

Это какая-то хитро вогнуто/выгнутая логика? В чём прикол?

Хотя... с другой стороны... я легко могу реализовать в приёмнике "управление" регистрацией источника (и без всяких "промежуточных" буферов и прочая) - но не пойму "А зачем?".

(29) Отправляется же по правилам регистрации.
Например правила регистрации в конфе с поддержкой.

Но вопрос зачем же так сложно блокировать принятие если это легко решается подпиской на события ПриОтправкеДанныхПодчиненному или
ПриПолученииДанныхОтПодчиненного

(29) (30) потому как в Источнике может не быть информации о принятии решения об отказе от загрузки

а можно реальный случай зачем такое может нужно быть?

(32) В источнике создаются документы, которые загружаются в приемник и на основании которых в приемнике создаются свои документы.
Эти документы нельзя менять в источнике, после того, как в приемнике на их основании были созданы документы.

Примерно так

(33) Ну и нельзя загружать измененные документы из источника, если они все же были изменены

(33) и что ж с ними делать тогда потом?

те 2 базу уже разошлись - и это уже навсегда

(33) Возвращать в исходное состояние в источнике и убирать регистрацию

(31) В источнике есть информация ЧТО приходит в приемник.

Если вам мне не нужно это в Приемнике выставляете Отказ в подписке которая отрабатывает загрузку объекта в Приемник и это не приходит.

Зачем вместо этого удалять из регистрации непонятно.

(38) я не обсуждаю КАК
реализация, с которой я сталкивался, была сделана задолго до БСП :)

(39) ты теряешь информацию, что объект не загрузился. а этого делать не нунжно. по условиям ТС