Доброго времени суток всем. Есть РИБ в двух разных базах вводят и перезаписывают документы. Часто перезаписывают одни и те же документы. Понятно что после обмена остается один вариан - тот который был загружен первым. Изменяются разные данные, например в одной базе меняют одну табличную часть, во второй другую. Какие есть варианты разрулить конфликт версий?

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

(0)  "...Понятно что после обмена остается один вариан - тот который был загружен первым..."
Не верно понимаешь.
Приоритет у объекта созданного в центральной базе.
(1)Разделяй документ на два. Коллизий в подобном варианте не будет (изменения в двух разных таблицах).
В классическом РИБ в обмен идет в разрезе объекта.
И это правильно ИМХО.
Иначе замучаешься разгребать гуано.

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

(3)это невозможно, данные по работам делает один, по цене, второй, проводит третий.

(4) пусть в очередь встанут. БП замути

- Эй филиал, не трогай документ, мне надо цену поправить,
- а че ты сразу? сейчас моя очередь!
- так все отошли в сторону, я ща с документом работать буду, когда я подошел вас здесь не стояло.
Так это должно выглядеть? Но как вариант рассмотрим.

(6) Если будет Бизнесс процесс будет выглядеть так:
- прошу вас коллега, документ будет виден у вас через пару минут.
- Благодарю вас, как вы быстро заполнили, передаю в другой отдел

1 документ, одно действие, один ответственный.
иначе - бардак и безответственность.

(6) Вообще-то именно так.
Ставятся границы временные кто, что когда может править и в путь.
Везде где работал так решалось.
Ну и (5) можно.

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

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

(11) + Одна фигня - на момент заливки изменений в узел уже неясно - где какую ТЧ меняли. Т.е. главная проблема - определить, какие данные оставлять без изменений, а какие заливать.

идея конешн бредовая, но реализовать несложно.

можно с изящным вариантом с дополнительным узлом

(1) Такие случаю разруливают набором прав

+ док в ЦБ регистрируется для двух узлов. для 1 - всегда, для 2 - только если изменены какие-то основные данные, по которым он считается приоритетнее перед загружаемым из периферии.

перед загрузке дока из периферии, проверяем таблицу регистрации по второму узлу. если загружаемый объект там есть - пишем отказ.
если его там нет, но он есть в первом - удаляем записи в первой таблице. нет записей - нет коллизий, док в ЦБ затирается доком из ПБ

(14) обычно обмен проходит под пользователем "роботом" с полными правами. и при загрузке данных многие проверки не работают, сам знаешь почему

(0) Задача классическая. Вариантов много. Например:
1. Актуальной становится версия модифицированная позже (пользователем, а не системой при репликации)
2. Версия модифицированная в узле являющемся более приоритетным (например в ЦБ - главнее чем на перфиферии, или наоборот)
3. Создается несколько версий объекта для разрешения конфликта  администратором
4. Создается версия объединяющая разные версии (в случае их непротиворечия)

и так далее.

>в одной базе меняют одну табличную часть, во второй другую

да здесь, похоже, коллизия в мозгу автора идеи...

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

(15)Нет данных по которым можно было бы выставить приоритеты. Тогда и регистр сведений можно использовать и туда писать лог. Проблема именно в (12).
(17) что то еще есть? Очень интересно, продолжайте.
(19) да да да именно это он и хотел сказать и я отчасти с ним согласен.

(20) Мож проще набрать в поисковике чтонибудь в стиле "асинхронная репликация методы разрешения коллизий"?

заменить вторую табличную часть - ссылкой на документ, второй документ(который в ссылке) редактируется только на перифирии, основной в ЦБ, при обмене пересчитывай с/с если нужно. или что там еще

корректировку цены - ограничивать правами на табл часть

(4) это невозможно, данные по работам делает один, по цене, второй, проводит третий.
значит это 3 документа а не один.

цену менять до списка Номенклатур/Услуг не логично, нужно определить очередность внесения количества/цены однозначно.