Что происходит с данными базы при заполнении у существующего элемента справочника свойства "ИмяПредопределенныхДанных"? Есть ли это свойство на платформе 8.2? Может в недоступном для редактирования виде?

Задача в следующем. Есть распределенная самописная база в режиме совместимости с версией 8.2.16. В ГК установлена платформа 8.3.14.43, на филиалах - 8.2.19.116. Почему тк - не спрашивайте - по техническим причинам.
Так вот, нужно сделать элемент справочника, который уже давно используется, предопределенным. Если сделать это в ГК на 8.3, прокатит ли это с обменом в регионах на 8.2?
Кто-нибудь уже делал такое?

http://bfy.tw/1k23

В 8.2 такого свойства нет и даже в первых версиях 8.3 тоже

пробуй, че. на копии.
потом нам отпишись, интересно же

(0) Это врядли. Предопределённый элемент создаётся (!!!) в конфигураторе и может иметь код и наименование совпадающие с существующим элементом, но UID будет другой.
В каждой твоей БД будет создан свой предопределённый элемент со своим UID.
По крайней мере такова логика предопределённых элементов справочников.

(4) Я так понимаю, если у справочника свойство "Обновление пердопределенных данных" установлено в "Не обновлять автоматически" то предопределенный элемент не создается.

Там все сложнее
http://its.1c.ru/db/metod8dev#content:5367:hdoc

(5) Чисто теоретически: предопределённый элемент - изначально заводится в конфигураторе и создаётся при первом обновлении конфигурации, в которой его нет.
При попытке обмена между разными конфигурациями и возникает дилемма вроде как предопределённый элемент уже заведён, но у него UID разный в обеих БД и создавать его повторно ненужно, а построить соответствие как то придётся. Вот и появились разные галки типа "Обновление предопределённых данных" и признак у элемента справочника Предопределённый, что бы можно было отдельно организовать работу с такими элементами специальным образом.

делаем новый, предопределённый элемент
Делаем замену дублей.
распространяем информацию о конфе и изменениях по узлам.
Наслаждаемся.

Переводим на мой счёт 500 евро.

(8) В ИР кстати для этого есть команда "Изменить идентификатор"

(9) И таки шо она сделает со всеми ссылками?

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

(10) Она создаст копию объекта с нужным ИД и откроет инструмент "Поиска дублей и замена ссылок" для замены ссылок со старого объекта на новый.

(11) Ой ну шо ви мне тут делаете нервы?
Это же совсем то же самое, за что я только что говорил...

(12) А я разве утверждал обратное? Я лишь обозначил факт автоматизации описанных действий в ИР.

(13) Ша... Ты таки тоже прав...
)))))))

(8) "Делаем замену дублей"
Ты представил что будет после этого с обменом если это справочник, например, "Номенклатура"?
А делать это в каждой из 30+ баз довольно затратно.
Извини, но твой совет на 50 евро не тянет.
(6) Спасибо за ссылку. Ознакомлюсь чуть позже.

(15) Замена идентификаторов предопределенных - считаю лучшее решение при наличии хороших средств автоматизации. Альтернатива - таблицы соответствия для подмены идентификаторов при отправке или получении данных.

(15) Да, я очень хорошо представляю. Поэто и назвал цену в 500 (пятьсот!!! пятьсот, Карл!!) евро.

Если надоест мучаться и готовы потратиться, то обращайтесь =) У нас есть готовые средства решения такой задачи.

* И на 50
(18)Спасибо, у меня тоже есть.