← На главную

Переход с профессиональной версии конфигурации «Зарплата и Управление Персоналом» (ПРОФ) на версию КОРП в рамках редакции 2.5 является стандартной, но технически сложной процедурой. Основная проблема, с которой сталкиваются специалисты, — это массовое задвоение предопределенных данных: видов расчета, справочников, вычетов НДФЛ и видов доходов. Это происходит из-за несовпадения внутренних идентификаторов (GUID) объектов в базе данных и в загружаемом файле конфигурации. В результате старые элементы теряют статус предопределенных, а новые создаются с пустыми значениями или дублируют существующие, что делает базу неработоспособной. Рассмотрим подробно, как правильно выполнить переход и что делать, если возникли дубли.

Разберем стандартную методику перехода

Согласно официальной инструкции, переход выполняется через полную загрузку конфигурации. Прежде чем приступать к активным действиям, обязательно создадим резервную копию информационной базы. Рассмотрим последовательность шагов, которую рекомендует фирма «1С»:

1. Убедимся, что текущий релиз ПРОФ не ниже 2.5.25. Рекомендуется обновлять ПРОФ до самого актуального релиза перед началом процедуры.
2. Запустим систему в режиме Конфигуратор.
3. Откроем конфигурацию через меню Конфигурация — Открыть конфигурацию.
4. Снимем базу с поддержки: перейдем в Конфигурация — Поддержка — Настройка поддержки. Нажмем «Включить возможность изменения», а затем «Снять с поддержки». Это необходимо, так как мы будем менять поставщика конфигурации.
5. Выполним загрузку: Конфигурация — Загрузить конфигурацию из файла. Выберем файл 1cv8.cf из дистрибутива версии КОРП (он находится в каталоге шаблонов tmplts\1c\HRMCORP\...).
6. После завершения процесса нажмем F7 для обновления конфигурации базы данных.

Важный нюанс: Перед загрузкой .cf файла необходимо запустить специализированную обработку Восстановление_уникальности_записей_регистров_сведений.epf. В версии КОРП некоторые регистры лишились части измерений (они получили префикс «Удалить»). Если в базе ПРОФ были записи, различающиеся только по этим измерениям, то в КОРП они станут идентичными, что вызовет ошибку уникальности. Найти эту обработку можно в папке с дистрибутивом обновления (например, в релизе 2.5.138.1).

Проанализируем причину появления дублей

Почему даже при следовании инструкции возникают задвоения? Проблема кроется в механизме сопоставления объектов. Платформа 1С при загрузке конфигурации (LoadConfigFromXML или «Загрузить конфигурацию из файла») сопоставляет предопределенные элементы по их внутренним UUID. Если база ПРОФ создавалась очень давно или переносилась из других систем нетиповыми способами, идентификаторы «Оклада» или «Вычета 103» в ней могут не совпадать с идентификаторами в эталонном .cf файле КОРП.

Когда соответствие не найдено, платформа:

• Снимает пометку предопределенного элемента со старого объекта (он остается в базе как обычная запись).
• Создает новый предопределенный элемент из метаданных КОРП.

В итоге в Плане видов расчета ОсновныеНачисленияОрганизаций мы видим два «Оклада». Один — старый, на который ссылаются все документы прошлых периодов, но он больше не является предопределенным. Второй — новый, чистый, который «знает» программный код, но в котором не настроены формулы и вытеснения. Это приводит к тому, что НДФЛ перестает считаться, а документы отпусков и больничных не заполняются.

Альтернативный метод через «Сравнение и объединение»

Если стандартная загрузка приводит к хаосу, проанализируем другой подход, который позволяет более гибко управлять процессом сопоставления. Этот метод основан на «мягком» объединении конфигураций:

1. Откроем конфигурацию ПРОФ и выполним Конфигурация — Сравнить, объединить с конфигурацией из файла, выбрав файл КОРП.
2. На вопрос системы о постановке на поддержку ответим Да.
3. В окне сравнения проверим, чтобы все объекты сопоставились корректно. Если мы видим, что какой-то элемент справочника в одной колонке не имеет пары в другой, хотя имена одинаковые — значит, UUID разные.
4. После объединения в окне Настройка поддержки появятся две конфигурации поставщика (ЗУП ПРОФ и ЗУП КОРП).
5. Нам необходимо полностью снять базу с поддержки ЗУП ПРОФ (включая все подчиненные объекты). После этого старая конфигурация поставщика исчезнет.
6. Для конфигурации ЗУП КОРП установим статус «Объект поставщика редактируется с сохранением поддержки».

Этот метод часто помогает избежать «потери» предопределенных данных, так как механизм сравнения/объединения может использовать сопоставление по именам (в зависимости от настроек), а не только по внутренним ID.

Что делать, если задвоение уже произошло?

Если обновление завершено и вы обнаружили дубли, ситуацию можно исправить программно. Рассмотрим алгоритм восстановления работоспособности базы:

1. Использование обработки «Поиск и замена значений»: Это классический способ. Нам нужно заменить все ссылки на «старые» (уже не предопределенные) элементы ссылками на «новые» (предопределенные). Однако это трудоемко для Планов видов расчета, так как там важны настройки базы и вытеснения.
2. Восстановление статуса предопределенности: Проанализируем возможность вернуть старому элементу его системное имя (ИмяПредопределенныхДанных). В управляемых формах это делается свойством ИмяПредопределенныхДанных, в обычных формах (ЗУП 2.5) ситуация сложнее — связь хранится в таблицах Config. Можно воспользоваться внешней обработкой УстановкаПредопределенныхЭлементов.epf, которая позволяет вручную «привязать» запись справочника к метаданным.
3. Очистка кэша: После любых манипуляций с метаданными обязательно очистим серверный и локальный кэш. Часто платформа «видит» дубли только из-за старых данных в кэше метаданных. Запустите базу с параметром /ClearCache.

Переход на ЗУП 3.1 как радикальное решение

Если состояние базы ЗУП 2.5 ПРОФ настолько тяжелое, что переход на КОРП вызывает фатальные ошибки, стоит рассмотреть переход на современную редакцию 3.1. Разберем этот путь по шагам:

1. Выполним штатный переход с ЗУП 2.5 ПРОФ на ЗУП 3.1 ПРОФ с помощью помощника начальной настройки. При этом перенесутся данные для расчета среднего, остатки и кадровые данные.
2. После того как данные окажутся в ЗУП 3.1 ПРОФ, апгрейд до КОРП версии 3.1 выполняется бесшовно. В редакции 3.1 архитектура едина, и переход с ПРОФ на КОРП — это простое обновление конфигурации без изменения структуры метаданных и потери идентификаторов.

Заключение: Основная сложность перехода в версии 2.5 заключается в том, что эта редакция создавалась в эпоху, когда механизмы управления предопределенными данными были менее гибкими. Если вы решите продолжать работу в 2.5 КОРП, подготовьтесь к ручному сопоставлению объектов и обязательно используйте обработку восстановления уникальности регистров. Однако, учитывая окончание активной поддержки 2.5, переход на 3.1 через ПРОФ-версию может оказаться более стабильным и перспективным решением.