у меня такая проблема, я уверен, что с подобным сталкнулся не я первый. Из Торговли в Бухгалтерию идет перенос документов отгрузки, но идет так - же перенос недостающей Номенклатуры и Контрагентов. Причем недостаток последних определяется по коду. Где мне найти доработку, что-бы синхронизировать коды в справочниках номенклатуры и конрагентов. Причем нужна доработка что-бы она определяла ссылки на предыдущие документы меняемого элемента и заменяла все корректно. Дабы комфортно работать с предыдущими документами.

По ИД надо синхронизировать, по ИД...

Я сталкивался и решал таким образом
1. При загрузке анализирую код и наименование элемента
2. Пытаюсь искать по коду, если нахожу сверяю наименование, если наименования разные то у имеющегося элемента справочника меняю код на любой доступный, а загружаемый элемент записываю с тем кодом, который в базе-отправителе
3. Если не нахожу по коду, пытаюсь искать по наименованию, если есть элемент с таким наименованием, то по желанию пользователя либо просто записываю новый элемент с нужным кодом, либо меняю код у существующего подгоняя его под код в базе-отправителе

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

(2) Учиться, учиться и ещё раз учиться ...

(3) У тебя??? :(
Чему??

(4)Я думаю, что найдется чему... То, что описАл в (2) не есть синхронизация...

(4) Для начала, учиться думать головой, а не тем, на чём ты сидишь ...

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

(2) это может продержаться только на голом энтузазизме, пожалуй - ситуаций масса... неуникальность кода, наименование и т.п.; отсутствие реквизитов "Код" или "Наименование" вовсе и т.п. и т.д. Слушай(1) )))

(7) Ок, дорогой ученик ...
Но сперва пришлите мне 50 американских копеек ...

(8) Мне заранее известны справочники так ведь. Отключена уникальность - тогда да, по ID, но во-первых как к нему достучаться, а во-вторых какой смысл в таком справочнике?

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

(10) бывают "истЕрически сложившиеся условия", когда такие справочники имеют смысл. До ID достучаться можно...

(9) Тьфу, ну вас нафик дорогой учитель.
Схемка рабочая и ладно, а как она правильно называется мне нас...ть. Главное что всё работает и все довольны. То что вы, дорогой учитель, прекрасно умеете теоретически изливать словесную массу знают все посетители форума.

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

(12) Можно вопрос:
Как разрулить такую ситуацию
в базе приёмнике создали элемент с ID кодом например 100, после этого в справочнике базы-отправителя тоже создали другой соверешнно элемент с ID (надоже какая удача) тоже 100. Что произойдёт при обмене данными если ID совпадают, а элементы по сути разные?

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

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

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

(17) А я про что. Если происходит так, что коды одинаковы, а наименования разные (т.е. предполагаем что разные элементы), то у существующего в базе-приёмнике элемента меняем код (не трогая ID - в документах всё ОК) и записываем элемент справочника загружаемый из базы-передатчика с тем кодом, с которым он записан в той самой базе. Это для того, чтобы при загрузке документов в соответствующие поля подставлялся нужный (совпадающим с базой-передатчиком) элемент справочника. При выгрузке документов вместо значений реквизитов типа "справочник" документа выгружаются коды элементов.

(19) Я ничего из (19) не понял, поэтому ничего по поводу (19) не скажу ...

(20) Может слишком запутанно но попробую ещё раз
База-передатчик
Элемент1   Код1  Наименование1
База-приёмник
Элемент2   Код1  Наименование2
При загрузке программа ищет нужный код (Код1) и сверяет Наименование1 с Наименование2 т.к. наименования разные программа меняет у существующего в базе-приёмнике элемента Код1 на Код2. В результате получается

База-приёмник
Элемент2   Код2  Наименование2
Элемент1   Код1  Наименование1

(21) Фигня какая-то ...
Зачем программа при загрузке ищет нужный код?
Зачем программа сверяет Наименование1 с Наименование2?

(22) Затем, что всё чудесно, если в одной из баз закрывается доступ на ввод новых элементов справочника, а если нет, и происходит параллельный ввод новых элементов на двух местах, то приходится сравнивать минимум два (код и наименование) реквизита элементов справочника в двух разных базах. А т.к. база-передатчик недоступна, то изменение кода происходит в базе-получателе.

(21) Элемент создают копированием, наименование не меняют, все остальные реквизиты изменяют. Затем, происходит (20). Типа, синхронизация. Через кокое то время обнаруживают ошибку и изменяют наименование.
?

(+23) мало того, один из клиентов заказал ещё дополнительно отлавливать не только по наименования и коду,о и каталожному номеру товара (каталог отраслевой).

(24) Такая же точно фигня произойдёт и в том случае, если пользоваться и ID. Поймите, без разницы по чём проверять совпадение и не важно совпадение каких реквизитов будет говорить о том, что элемент уже есть в справочнике и догружать его не надо. Если не будет чёткой схемы работы и организации труда то всё пойдёт прахом. Приведите мне хоть одну схемку, в которой "человеческий" фактор не играет роли, и я извенюсь за свою тупость.

(24) Плюс ко всему у созданного копированием элемента будет другой код.

(25) Не путай, это у тебя не синхронизация, а просто нае#ательство клиента с целью лёгкой наживы ...

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

(28), (29) Я просил аргументировать, а не оскарблять

(30) Я никого не оскорбляла вообще-то, а в общепринятых выражениях объяснила, что программно все ситуации можно обыграть, если хорошо подумать - совершенно необязательно при копировании элемента справочника копировать туда ID копируемого элемента. У меня все устойчиво работало очень долго, пока я не нашла другие средства решения своей конкретной задачи.

(31) Привет, Чашка!

(31) При каком копировании? О чём речь? Может при создании? Тогда ответьте мен на такой вопрос. При создании новоого документа (программно) необходимо найти в нужном справочнике необходимый элемент и его передать в реквизит документа. Что записывать в файл (формат роли не играет) обмена данными и по чём осуществлять поиск элемента справочника?

Привет, Композитор.
Рада тебя видеть снова.
P.s. "Композитор" - удачный ник - всегда получается с большой буквы )))

(34) Ну что конструктивных предложений по (33) не будет? МОжет конечно и рано вывод делать, но он увы напрашивается сам собой ....

(34) Ник удачный. Рупор абсурда вспоминает меня, когда помогает дочке писать сочинение про композитора Моцарта. И вообще, я у всех на слуху. Перед именем всех авторов музыки (даже самых известных) упоминается мой ник. Композитор Моцарт, композитор Бах, ну и перед другими именами тоже. То есть я первичен, а Бах вторичен. Я присутствую в титрах всех фильмов. Приятно, знаете ли, посмотреть фильм, а потом среди создателей фильма увидеть: Композитор.

(26) Согласен, что полностью исключить коллизии, которые возникают при одновремененном вводе элементов (возможно идентичных) при перегрузках нельзя. Поэтому, надо выбрать схему, при которой данные будут прегружаться по возможности более корректно.
1. Сократить время между перегрузками. А лучше вообще on-line. Тогда пользователям не придется вводить два одинаковых элемента.
2.Использовать для синхронизации уникальные реквизиты. Для организаций - ИНН, для номенклатуры штрих-код производителя, артикул.
3.В любом случае, чем програмно изменять при перегрузках реквизиты и атрибуты справочника, лучше оставить в базах два элемента. При выполнении 1. вероятность того, что пользователи в двух базах вводят одновременно один и тот же элемент все-таки небольшая, а при выполнении 2., по моему незначительная.

(35) Sorry,  я ведь еще и работаю...
В базе-источнике реквизит ID (с признаком отбора) заполнять вопреки коварным действиям пользователя реальными ID элементов ->> добьемся того, что у нас есть по крайней мере один реквизит, по которому можно идентифицировать.
В базе-приемнике - искать по реквизиту ID, который уже совершенно не обязан совпадать с внутренним идентификатором... Просто одинаковый реквизит ID для всех справочников и четкая система контроля за его заполнением...

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

Фигня все (с) Бекас....

Дитер так и не понял идеи... Как использовать ИД...

Не понял - мне что всю ветку читать?
в (1) Конечно лажа - лучше синхронизировать по ID - если дубляжи  - значит элементы забивались/ются в двух базах паралельно - и что дальше?

Лажа все вообще! Синхронизация - не обязательно 1:1 !!, на три элемента источника, к примеру, нужно создавать 1 (или произвольное количество) элемент приемник. И "синхронизация" по Id - это рудимент мыслепоисков отсталых 1с-ников.

Абасрацца...

Привет, Снарк...

Абасрацца...  то Абасрацца... но если это ты по поводу (42) - иногда Свету посещают частично умные мысли... Насчет свртки при переносе... А насчет ИД оно тупит качественно....

Привет... Да я не по этому поводу... Перенос данных, в частности справочников, может быть весьма разнообразным и изощренным, на что, собственно, NS со Светой и указали... Только если мы говорим о синхронизации, то свертки/развертки при переносе, иначе говоря - неоднозачное отображение некоторого подмножества элементов источника в элементы приемника - тут не при чем... Если имеется неоднозначность, то это НЕ синхронизация, а нечто совсем иное... Давайте заменим в обсуждаемом вопросе термин "синхронизация" на "перенос данных" и я соглашусь практически со всеми вышеизложенными постами...

и будешь прав...

(45) Если под "сихронизацией" понимать некое действо, после которого справочники в двух базах становятся абсолютно идентичными минимум по трём признакам (ID, Код, Наименование) тогда конечно моя схема не есть реализация этого. Но ведь (0) задал вопрос о проблеме, возникающей именно при обмене данными. Тут я полность с тобой согласен :)
Вообще добиться идеальной синхронизации справочников (ИМХО конечно) можно только одним способом - запретить ввод и корректировку элементов на одной из сторон (обычно это "подчинённые" базы филиалов компании). Тогда для синхронизации можно воспользоваться стандартными обработками типа TranRef. Все остальные методы, по чём ты не проверяй уникальность, неработают.

Питух, ты родом с какого хутора?