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

Интересуют разные идеи, как это можно реализовать...

(Отклонение документов, при загрузке уже работает, но эта информация, пока не доходит до удаленной БД).

(0) Сорри, заголовок не дописал

(1) Груви это пох... щас тебя забанят

Закладка. Сам пытаюсь в РИБ сделать подобное

(0) Я так понимая, что отсев документов прописан в правилах? Ну так в правилах и прописать создание лога с последующим чтением его удаленной БД.

сделать РС и писать туда отклоненные, и отправлять РС по правилам.

имхо табчасть с узлами и статусами. при загрузке в ЦБ писать в таб часть и отправлять измененный документ обратно в ПБ

либо РС

(3) Есть мысли?

(4) >Я так понимая, что отсев документов прописан в правилах
Вставил код в обработку обмена.

создать план обмена, управлять регистрацией объектов. выгружать только зарегистрированные(обработка универ обмен XML это умеет)

(10) Это уже есть. Сейчас более тонкая настройка обмена.

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

(12) Это понятно. Трудность в осмыслении обработки документов в удаленной БД. Самой логики.

Недостаточно информации (принципы "отклонения" в центальной базе)... ммм... могу попасть "пальцем в небо"...

(ИдеЯ) Если в конфе есть РС ВерсииОбъектов - очистить и туда записывать объекты в удаленном узле во время отправки (или перед отправкой) собщения обмена.

Если центральная база "отклоняет" измение, то для объекта регистрируется измение, чтобы очередным обменом он был передан в удаленный узел для "восстановления" исходного состояния.

В удаленном узле, при получении данных, изменение объектов "принимать" и записывать в регистр...

Смысл или как этим "пользоваться": Если в регистре на один объект пара записей - мы имеем случай "отклоненные". Первая запись в регистре - изменение объекта, не принятое центральной базой. Вторая запись - исходное состояние объекта до изменения (текущее состояние объекта)... Дальшеможно не "разжевывать" ? :)

(14) Всё-таки добавлю имхо :) Не нравитсямне эта идея. Даже еслианализ записей регистра проводить оперативно, однократно, до следующего сеанса обмена. "Каша" какая-то получается :(

В центральной базе изменение отклонили и... а что, собственно говоря, дальше? Можно использовать документ или ждать очередного изменения? И как долго эта фигня "туда-сюда" будет продолжаться? :)

(14) > принципы "отклонения" в центальной базе
Проверяются реквизиты, и если не подходят, то документ, просто пропускается, и не загружается.

В остальном подходящий вариант. Надо продумать.

(15) Обмен предполагается раза 4 в день. В центральной использование документа продолжится несмотря ни на что, т.к. принять некорректный это большее зло чем использовать старый. Вот, что бы избежать неоднозначности и прозрачности, что документ не принят это и задумывается. Задержка в несколько часов, не будет проблемой, т.к. документ не оперативный.

Я за структуру подчинености

(16) Ок. "Хозяин - барин"(с) Тогда в (14) поправка: на один объект записей может быть не две, а более...

PS: Задействовать "типовое" использование версий объектов и пусть юзверы там копошатся, как хотят :)