Посоветуйте, как в РИБ контролировать удаление? #566468

Посоветуйте, как в РИБ контролировать удаление? Есть, база с разветвленной структурой подчиненных узлов (план обмена с галкой РИБ). Все стекается в сводную базу - центральный узел. Где-нить на нижнем уровне Марья Петровна cочтет ненужным и решит удалить элемент справочника, который общий для всех баз. Получается, что команда на удаление объекта пойдет реплицироваться по всей развевленной структуре, дойдет до главного узла, а через главный узел пойдет в другие ветки. Как разруливать такие ситуации?

Запретить удалять элементы справочника например

ну... все-таки как-то хранить информацию где создан элемент - если не в этом узле, отказать в пометке на удаление.

и как это поможет?

например, в каком виде её хранить и как реплицировать в другие узлы? Отдельно взятая база не знает обо всех узлах ветки.

ну предположително  этот элемент не используется другими узлами.. Но если используется, то тогда собственно ничго кроме не остается. 2 все равно обмен идет через центр. А он должен узнать

Маша в фирме А завела номенклатуру "Ящик деревянный". Петя из фирмы Б (другая почка) решил воспользоваться этим элементом. Через месяц Маша, так и не вспонив зачем она его заводила решила его удалить, и удалит (ведь она же его создавала), и что будет у Пети?

Имхо единственный вариант, дать Маши и ПЕти право пометку на удаления, а удалять справочники самому в центре после обменов

завести что-то типа справочника с предопределенными элементами и обозвать его "уникальные номера узлов"? вот такую фигню и предполагаю

маша будет еженедельно в одной ветке ставить пометку удаления и удивляться почему она исчезает, а петя будет её снимать и беситься, кто ставит пометку?

2 ну а чтож ты хотел?

Это лучше чем "Объект не найден" Кстати в свое время в 7-ке у меня у номенклатуры был реквизит "Приоритет". Как только проводился документ с этой номенклатурой тут же этот реквизит уходил в почки, и там уже анализировалась, номенклатура участвует в продажи, значит нельзя править удалять и т.п.

все просто. пометка на удаление - в ПБ. права на удаление - только в ЦБ.

кстати да, Маша увидит ненужный элемент "тапочки" и решит его переименовать в "носки". А в соседней ветке у Пети дико возрастут продажи носков и исчезнут тапочки, которыми он торговал. Пипец какой-то.

а, в уже написали, я кэп Очевидность)

права надо настраивать и не давать Пете с Машей править. ну или регламент.

если враги народа в ПБ будут ставить пометки, то как этих гадов вычислить?

Журнал регистрации?

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

База территориально разбросана по городам и весям.

Есть журнал регистрации.. и при большом желании его можно даже передавать в сообщениях в ЦБ

2 Эти веси что - не определены в любой момент времени в пространстве и по айпишнику?

если поставили - значит права такие есть и положено)

неа, не определены

это межпространственные образования)

да и керн им на воротник, городам и весям этим. На 1С и обмен нашлись деньги и интернеты, значит и журнал регистрации смогут переслать или/и оттопырить удаленный доступ, чтоб сам посмотрел. При отсутствии у бандерлогов прав, вероятность того, что потребуется посмотреть это журнал, исчезающе мала

2 настоящие облака что ли? :)

ога, как у Лукьянко - храм дайверов)

*Лукъяненко

Что значит удалила? Пометила на удаление - это одно. А за "удалила" надо администратору руки оторвать, коль такие права дает. Администратор справочников есть? Кто следит за НСИ?

а типовыми методами можно видеть в журнале регистраций что грузится или выгружается?

а еще есть мощное колдунство в модуле плана обмена

круто

можно увидеть в приемнике, что загружает - это обычное "Данные.Изменение". Если обмен запускать всегда под одним служебным пользователем, под которым больше ни чего не делается, то всё прозрачно. При помощи парадигмы можно и отправку в ЖР завернуть, но это лишнее