добрый день
не могу понять как уйти от одной проблемы...
УТ,10...риб

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

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

P.S.
Думал сделать план обмена ,на который будут регистрироваться изменения,и потом какое нить фоновое будет бегать через веб сервис   ,и шуршать по базам и искать дубли в заданном справочнике...Ну а потом выводить каким нить отчета.
это не очень быстрая проверка и актуальная,а хотелось бы что бы актуальная проверка была..
контроль уникальности стоит в справочнике
Веб сервис который проверяет проверяет константу "ПрефиксУзлаРаспределеннойИнформационнойБазы" я сделал

прошу  подкинуть идей

поставь префикс

(1)для кода справочника ессно

(1) для сравочников и констант я проверку поставил...а как вот проверять на то что бы в других базах не было дублей?

(3) справочника организации)

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

(5) так префикс задается в константе

или префикс или уникальное значение или разрешение вводить только в одной базе .

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

(6) у каждой базы в рибе надо сделать еще одну константу, которая не участвует в обмене. в нее писать префикс этой базы.
современные префиксы обычно уже состоят из 2х частей.
например, УТРТ (управление торговлей в розничной точке), УТОФ (управление торговлей в офисе), УТДС (управление торговлей в далёком складе).

но может лучше сделать Настоящий ВебСервис? который поможет вести оперативный контроль справочников? да и других фишек навешать можно будет.
например:
во вторичной базе юзер хочет выбрать контрагента, которого не нашел в своем справочнике. жмякает "создать", вводит поля. вторичная база стучится httpзапросом в первичную, первичная ищет у себя такого контрагента по ключам уникальности (ИНН, КПП, Полное наименование) и в ответ отдает структуру.
в структуре есть флаги ("есть точное совпадение", "создан новый контрагент" для диагностики и записи в ЖР), строка с УникальныйИдентификатор, строка с кодом.
вторичная база, приняв ответ, делает УстановитьСсылкуНового и пихает туда указанный УИ.

если первичная не нашла, тогда она пишет пустую заготовку с ключевыми полями у себя, получает код, отправляет в ответ получившуюся ссылку и код.

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

(9)
ПрефиксУзлаРаспределеннойИнформационнойБазы и так не обменивается

я вот думал что бы оно стучало во все базы,а их штук 15...(((
и пока все оббежит долго будет

и кол-во баз будет расти

(10) В таких случаюх задумываются о базах с мастер данными

(10) зачем стучать во все, когда данные можно аккумулировать в одной МастерБазе?

ИМХО, в узлах риба только доки...справочники должны заполняться в центральной базе

(14) не получиться так...точка работает удаленно,магазин,и получается пришел клиент,его не будут заводить в своей ,а центральной только,ждать пока придет обмен,долго...

(12)(13) что такое мастер база?

(15) ну тогда только префиксация

(16) в картинках это вот как в тут https://курсы-по-1с.рф/articles/дисконтный-сервер-в-1с-розница-2-1/
но не продажи по дисконту, а НСИ.

(18) ну вот что то такое я и планировал..просто получается надо что бы все в одной базе проверяло ,т.е. на филиалах (удаленных магазинах) через веб сервис выполнялось подключение к Центральной и выполнялся какой то запрос...вот только возникает вопрос,а что если в этот момент базеN создался такой же код(вероятность маленькая но все таки) и придет уже с обменом позже(мин через 10)

(19) как вариант:
Константа - ПоследнийКодСправочника.
При создании элемента в филиале, ПередЗаписью (или при установке нового номера или еще где) обращение к веб-сервису центра, получаем ПоследнийКодСправочника, тут же её же +1. Элементу присваиваем код полученный от веб-сервиса.
Тут может получится пропуск каких-то кодов по порядку, в случае отказа на запись после получения ПоследнийКодСправочника, но уникальность будет гарантирована. Если такие пропуски недопустимы, надо будет еще усложнять систему с проверкой после записи.
По мне так из-за какого-то кода лепить это все не очень та и целесообразно. Проще префикс.

Ну и в случае каких-либо веб-сервисов, стоит учесть варианты падения интернета на филиале, когда до центра не достучаться будет.

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

(21) это мелких точек касается

Обычная нерешаемая проблема риб,если в двух узлах создают элементы с одними и теми же данными.Всякое шаманство с подключением к опрелеленной базе,это уже не риб,здесь сразу повод задуматься о переходе в единую базу,т.к.это проще,удобнее и исключает многин проблемы
а если есть проблемы со связью,то будет два элемента в любом случае,если,конечно,в удаленном филиале будут работать с программой,а не выключат ее,если же выключат,то смысл риб теряется.

(23) "Обычная нерешаемая проблема риб"
-прокляетие риб?)))(,как проклятие Черной жемчужины в пиратах кар. моря?)

Так а в чем проблема то? префиксация кода должна помочь, зачем какие-то велосипеды.

(19) "если в этот момент базеN создался такой же код" - вероятность нулевая, т.к. базеN в то же самое время сходила к тому же вебсервису, а он отдает только последовательные номера\ссылки.

(26) нет инета - нет мультиков)

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

Интуиция мне подсказывает, что если автор озвучит примеры дублирования, то разбор полётов пойдёт более плодотворно.

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

(0) НСИ надо всегда вводит в одном месте. Можно разные Справочники в разных местах, но всегда 1 справочник - одно место ввода. В остальных базах данные появляются с обменами.

(30) Не обязательно ограничивать ввод НСИ одним местом (двусмысленная фраза получилась, вы не находите? :)
Достаточно чётко определить в бизнес-процессах кто/когда/чего/куда. У нас, например, наиболее ходовые справочники, типа контрагенты и номенклатура, вводятся в нескольких узлах. Тоже самое относится к документам. Дублированием не страдаем :)

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

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

(28) ну про пул до этого не было ничего...

(34) + а с пулом да, должно взлететь...