РИБ-база, объект одновременно изменили в нескольких узлах - выявить/предупредить #724810

Вот, например, далеко не абстрактный пример: Покупатель оплатил заказ и с ним сразу начинается интенсивная работа сотрудников: отдел логистики уточняет дату отгрузки, отдел сбыта - место доставки... покупатель, после общения с производственным отделом, поняв что "промахнулся" с размерами изделия, звонит менеджеру по продажам и требует изменить позицию продукции... Всё бы ничего, да вот беда: эти сотрудники сидят на разных узлах риб-базы :( И после сеанса обмена останется только одно изменение!

Мысли "вслух": Дополнить конфигурацию регистром сведений, где будут фиксироваться события изменения объекта (дата/время, объект, узел, пользователь). И дополнить регистр "контрольными точками" - записями проведения сеансов обмена (дата/время, объект, узел запись/чтение) Далее - анализ ситуаций, когда между двумя сеансами обмена объект был изменен в различных узлах...

Хмм... регистр сведений "ВерсииОбъекта" наиболее походящий для моих целей.

а у тебя РИБ - он по какому принципу? по разделению "измерению" или функциональному?

Не совсем понял вопрос. Типовая УПП (с изменениями), план обмена "Полный" (без правил обмена)

Мысли "вслух": Включить версионирование (кстати: не забыть внести изменение, а то оно "не дружит" с риб-базой) и повесить на регистр подписку на событие ("ПриИзменении"?), которое будет писать в мой регистр сведений (в справочник?). Регламентное задание (запускаемое после сеанса обмена?) будет анализировать(дополнять?) записи. Насчет справочника подумать: справочник двухуровневый, группа - ссылка на объект, записи в группе - регистрация самих изменений объекта(?) Может быть и ТЧ задействовать? Писать туда измененные реквизиты объекта (старое и новое значение)? Надо подумать.

пусть работают через тонкий клиент удаленно

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

геморрно это всё без полноценной блокировки объекта

Сам звонящий поменять позицию не в состоянии?

у нас 77 и у нас просто - принцип семафора, например непроведен - редактирует офис, провели в офисе сразу "отпускается" документ и проведенный дает редактировать на складе... а если много стадий, то состояния выносятся из документа во вне - в справочники, регистры кому как нравится

Некоторые пользователи так и работают. И даже есть те, у которых есть возможность подключаться к нужному узлу базы (для оперативного внесения изменений). В целом согласен. Порядок/очередность установлены. Но сотрудник, изменивший позицию непосредственно в заказе, нарушил инструкцию - он был обязан ввести документ изменения (ИзменениеЗаказаПокупателя или КорректировкаЗаказаПокупателя). Принцип "семафора" (или статусов) - неудобная вещь, когда у тебя риб-база. Всё начинает "квантоваться" сеансами обмена. А между ними - по прежнему эффект неопределенности. Вот, например: сотрудник, имеющий на это право, изменил дату запрета редактирования, внёс изменения задним числом в документ прошлого месяца и тут-же вновь опять закрыл датой запрета редактирования этот месяц. Всё было сделано менее чем за минуту. На первый взгляд ничего криминального? А если после действия был сеанс обмена и действие было уже после сеанса обмена? Тогда прошлый месяц в узле, куда ушло сообщение, будет "открыт" до следующего сеанса обмена. А это уже чревато негативными последствиями.

Не понимаю зачем в наши времена риб, если это не розница....

например, запускать несколько мини-серверов (или даже файловых веб) на скромных компах вместо одного мега-сервера, масштабируя по необходимости

Да ладно... Мега... Одна зп одинэсника...

Вопрос в лоб: а какое изменение должно остаться?

Центр всегда прав.

филиалы пусть бегают и потеют.

.2 а чего тогда не залочите документ?

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

Неистово плюсую Помню как бывало "с повеления выше" и с легкой руки саппорта все нахрен сыпалось на конвейере, потому что пометили на удаление заявку, которая начала собираться. Закон один для всех и он должен работать.

Ответ "в лоб": я не собираюсь вмешиваться и изменять принципы работы РИБ. Тема - выявить и предупредить.

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

PS: на форуме регулярно происходят обсуждения так называемой "системы статусов" документов - попыток формально отразить сложные отношения между системой принятия решений и документооборотом.

там вроде должен быть регистр сведений "коллизии при обмене". Все такие случаи смотришь в этом регистре.

В типовой конфигурации при РИБ-обмене этот регистр не используется. Его назначение - фиксировать проблемы с проведением документов после обменов между базами с различными конфигурациями. В РИБ-обмене документ и его движения мигрируют автономно и независимо друг от друга.

не знаю как в УПП, в БП 2.0 используется в РИБ этот регистр.

В УПП тоже самое - при обмене с БП, он используется.

Уточню, ибо не совсем правильно сказал как мне кажется: В УПП этот регистр (КоллизииПриОбмене) используется(!) в обработке ОбменДаннымиXML, а типовой конфигурации УПП в планах обмена (в том числе "Полный" для РИБ) он не используется и не мигрирует(!)

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

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