1С:Бухгалтерия 8. Переход на редакцию 3.0 с настройкой обмена (УТ 10.3)

Переход на редакцию 3.0 происходит в виде штатного обновления и не представляет из себя ничего сложного. В данной статье я постараюсь сделать упор на восстановление обмена с УТ 10.3 и ошибку с задвоенными элементами регистров сведений. Статья подготовлена на основе рекомендаций компании 1С и личного опыта. Все действия производились на платформе 8.3.4.482.

На старте имеем клиентскую базу бухгалтерии редации 2.0.57.10. Для начала по пунктам переход на 3.0:

1. В обязательном порядке поднимаем релиз до максимального 2.0. В моем случае до 2.0.59.4.
2. В случае, если КЛАДР был загружен по всем областям, желательно очистить классификатор. С данным пунктом связана ошибка нехватки памяти.
   А классификатор адресов при переходе на 3.0 в любом случае придется загружать заново. Для малоопытных сотрудников и "слишком программистов": КЛАДР можно очистить штатным способом:
   
3. Удалите помеченные объекты.
4. Желательно запустить внешнее и внутренее тестирование информационной базы (Ссылки чистим, объекты удаляем) со сжатем таблиц ИБ.
5. Добавляем вашему пользователю право администратора системы (Если пользователей нет - пропускайте пункт):
   
6. Далее запускаем штатный механизм обновления. Для перехода на 3.0 требуется специальный дистрибутив (на диске ИТС либо на сайте поддержки пользователей).
    
7. После перехода (сам процесс отличается от обычного обновления разве что большей продолжительностью) обязательно запускайте тестирование со сжатием ИБ.
   Для примера: файл 1CD до перехода "весил" 1.3Гб, после перехода размер составлял уже 2.2Гб. Соответственно после сжатия: всего 823 Мб. Учитывая, что для статьи
   я использовал одну из самых миниатюрных клиентских баз, экономия может быть существенной.
8. Далее загрузите свежий КЛАДР и настройте для пользователей внешний вид. Для меня наиболее оптимальной является следующая настройка:
   

Переход на 3.0 завершен и если у Вас нет базы УТ с настроенным обменом, то можете счастливо улыбнуться и пойти попить чай) В противном случае продолжим.
Для возобновления штатного обмена (По новому синхронизации данных) необходимо воспользовать обработкой поставляемой вместе с дистрибутивом перехода на 3.0
 

Последовательность действий следующая:

1. Проверяем настройки синхронизации данных в БП 3.0 (Администрирование - Синхронизация данных - Настройки). По умолчанию режим обмена установлен в "Двусторонний (БП УТ)".
   При необходимости меняем на односторонний:
   
2. Запускаем обработку конвертации обменов в БП. Указываем текущую настройку и файл, куда будут выгружены необходимые данные:
   
3. Открываем эту же обработку в УТ. Также указываем текущий обмен и ранее созданный файл (В моем случае 123.xml):
   
4. Жмем "Обновить настройки". Восстановление обмена завершено. Запускается он теперь несколько иначе:
   
   
   
   Обращаю внимание, что данный пункт не будет доступен, если в настройках не будет стоять пометки обмена с продуктами на платформе 8.2:
   
   
   Для синхронизации остается нажать на заветную кнопку:
   

Теперь об ошибках. При запуске обработки конвертации на стороне БП во внешний файл помимо служебной информации копируется регистр сведений "(Не используется) Соответствие объектов для обмена".
Сразу после перехода на 3.0 в нем находится куча пустых ссылок по справочнику банки. Не совсем понятно, зачем нужно было при переходе удалять ссылки на банки в данном регистре, но данное обстоятельство настройке обмена в принципе не мешает.
Хотя я строки с битыми ссылками удаляю. А вот дубли по уникальным идентификаторам в данном регистре приводят вот к такой ошибке при загрузке данных в УТ:

з-за чего возникла такая ситуация, если в регистр в принипе нельзя записать одинаковые строки: в колонке "Ссылка в другой ИБ" в регистре "(Не используется) Соответствие объектов для обмена" содержаться записи следующего вида:

{"#",d2536903-cbe3-4945-b3eb-42b1d353be81,25:b167babe02dfcccc11e2236865511b46}. Первая группа символов (после решетки) указывает на расположение объекта (Например СправочникСсылка.АдресныеСокращения), далее идет номер таблицы БД и после двоеточия сам уникальный идентификатор (Но не в прямом порядке). Расположение элемента и его идентификатор разумеется будут одинаковыми (в противном случае это уже не дубль, а попросту другой элемент), а вот номер таблицы вполне может измениться (Встречал на практике). Проблема решается удалением строк в регистре с меньшими номерами таблиц (Т.е. из записей 25:b167babe02dfcccc11e2236865511b46 и 35:b167babe02dfcccc11e2236865511b46 оставляем последнюю).

Для решения проблемы с дублями была создана обработка очистки регистра "(Не используется) Соответствие объектов для обмена".