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

там вообще то файл обновления есть для перехода. Свои реквизиты переносить самому придется

(1)
"В файл обновления эти реквизиты также были добавлены" вручную, почему они остались пустыми?

а они что должны быть заполнены?

(3) Вообще-то хотелось бы, иначе зачем они есть?

(4)
действительно зачем они... не нужны!
ответ в (1)

(2) А с чего бы им стать не пустыми?
Откуда вдруг там возьмутся данные?
Они и должны быть пустыми, по другому просто быть не может.

План переноса писали программисты 1с, которые нихрена не знают про то что вы там добавляли, и чего не добавляли.
Они переносят только то что там должно быть.
А уж остальное - ваши проблемы.

тут на самом деле 2 пути - поправить правила, либо написать обработку самому, я обычно такие вещи переношу сам обработкой - если сопоставлять хитрым образом не надо данные - работы на час максимум

стандартный вопрос - чем вы занимались последнии 10 лет? )

(9) В 2.0 есть док РКО, добавил реквизит допСумма, заполнил его в предприятии.
В обнове 3.0 нет этого реквизита, добавил в конфигу 3.0 этот реквизит.
Загрузил 3.0 в 2.0, обновил ИБ, реквизит обнулился, почему?
Как  сделать чтобы не обнулился?

Речь не о переносе, а об обновлении, если вы не поняли.

+(11) Нет тут никаких правил и КД .

(9) Пиво пил.

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

артикул = код

(0) в бп 3.0 не вздумай в конфигураторе добавлять реквизиты

(16) без них никак, синхрон с 7.7

(15) Это не справочник номенклатуры.

(18) так я написал - синхронизируй по номеру, если документ

(17) добововлять через дополнительные реквизиты в режиме предприятия

(19) Ты не понял, это не обмен, это обновление.

Я бы обновил так, позже дозагрузил в тч нужные ланные

(22) +100500, уже 2 час пытаюсь донести

(20) С этим пока не знаком, надо посмотреть.

(24) или найми кого-нибудь

(24) заплати денег спецу - там реально работы на пол часа, если типы реквизитов "строка", "число"

(23) Был реквизит  у дока GUID, формируется в 7.7, загружается в 8.2, по нему поиск при загрузке. Номер у дока в 8 свой, после обновления GUID в 8 пустой, по какому признаку определять в 8 при загрузке куда писать? База с 2012 года, нумерация пересекается по годам.
(26) дело не в типах, а куда записать.

На (10) может кто внятного сказать?

(27) смотри (20) - у каждого объекта можно добавить реквизит в режиме предприятия, добавляй свой ГУИД, запрос по док-там с учетом номера и даты элементарный

если совсем все будет плохо - напиши в почту под ником

(29) Решили бухи прошлый месяц перевыгрузить из 7.7 после обновы, все задвоится т.к GUID не тот.

(28) В БП3.0 не надо лезть в конфигуратор, чтобы добавить реквизит для хранения. Достаточно добавить дополнительный реквизит и обработкой перенести в этот реквизит данные из предыдущей базы.

(31) Обработка для загрузки из 77 должна быть другой для БП3.0

(32) Вот это полезно, а как перенести из предыдущей базы?
(33) С этим как раз нет проблем.

(31) надо было в самом начале сказать что выгрузку из 7.7 идет

(35) Проблема не в 7.7, а в том как обновить на 3.0 и не потерять данных существующих в 2.0.

7.7 (если что) своя самописка, обмены тоже свои. Вся проблема в обновлении 2.0 на 3.0

(37) ответ в (14)+(29)

Что бы данные при переходе с 2.0 на 3.0 сохранились, нужно добавлять в 3бп реквизит через сравнение-объединение.
Тогда сохраниться внутренний guid реквизита и он не удалиться. Если просто в конфигурацию 3.0 добавить реквизит, то у него будет новый guid и при загрузке старый реквизит удалиться и будет добавлен новый, хотя имена у них и совпадают

(39)
вот оно как?!
офигеть!

"Разработчик дал инструкцию для обновления: производится путем загрузки файла новой конфигурации."

Непонятно, кто такой этот "разработчик", но обновление с БП 2.0 на БП 3.0 следует выполнять как любое другое обновление типовой конфигурации (а не путём загрузки одной конфигурации вместо другой).

Путем загрузки тоже можно.
Разницы между обновлении через поддержку и загрузкой конфигурации нет.
Через обновление проще, когда конфигурация типовая, через загрузку проще, когда много изменений, особенно если идентичных баз несколько.
Т.е. в стороне готовится конфигурация с изменениями, тестируется, а потом на боевой базе загружается.

+ (42) правда, при загрузке нужно хорошо понимать, что ты делаешь и зачем :)

(42) Ну, чтобы обновлять доработанную конфигурацию через загрузку, сначала всё-таки хотя бы раз придётся пройти через обновление. ;)

Если очень хочется, то можно и без обновления. :)
Можно создать новую базу 3БП, включить изменения и внести необходимые изменения. После этого выгрузить конфигурацию и загрузить ее в базу 2.0.
Но обновление все же приоритетней - процесс получается более контролируемым и понятным.

(39) Т.е. сначала на 3.0 накатить 2.0 с реквизитами, а не вручную добавлять, а потом 3.0 грузить в 2.0?
(41) Разаработчик: "1С Бит", конфа "Бит Финанс"

(46) зачем же вы вручную добавляли реквизиты? Ну вы даете. Копипастом надо.

(46) Да, все верно. Сначала через сравнение-объединение перенести в 3бп ТОЛЬКО добавленные реквизиты, а потом полученную конфу грузить в 2бп и запускать обновление.
(47) Копипаст вроде тоже не помогает, идентификатор реквизита при этом не сохраняется. По крайней мере раньше не сохранялся, может в новых версиях платформы что то изменилось.

(48) всегда если копируешь реквизит копипастом, внутренний уид его переносится. Не знаю, в каком месте у вас не сохраняется, но на платформах 8.0, 8.1 и 8.2 всегда идентификатор сохранялся.

(49) Как раз на этих платформах вплоть до 8.3.6 не сохранялся.
В любом случае, это легко проверить. Можно взять 2 одинаковых конфы, добавить в одну из них реквизит, применить конфигурацию ИБ и заполнить его каким либо значением.
Затем скопировать его в другую Конфу, выгрузить ее и загрузить в первую базу. Если после применения конфигурации ИБ значение реквизита сохраниться, то идентификатор при копипасте сохраняться. Если нет - то не сохраняется, все просто :)

Если файл конфигурации именно загружался, то сравнение объектов производилось по GUID, а значит внесенные в БП 3.0 реквизиты наверняка имели другой GUID и просто прошла замена реквизитов и данные уничтожились. В таких случаях как правильно написано в (39) конфигурацию нужно сравнивать и объединять, в этом случае сравнение объектов и дет по наименованию и данные не пропали бы.

(47) Вроде копипастил, хотя может копипастил уже в 3.0, не помню.
Пробую вариант (46)

Принципы использования и добавления дополнительных реквизитов в БП2.0 и в БП3.0 разные. Поэтому повторение структуры из другой версии нерационально. Объединение конфигурации порождает дублирование функциональности.

1. Выгружаешь цф из 2.0
2. Берешь чистую 3.0, через объединение накатываешь из цф 2.0 добавленные реквизиты
3. Выгружаешь полученную конфу в цф
4. Загружаешь полученный цф в конфу 2.0
профит