← На главную

При попытке обновить конфигурацию 1С:Зарплата и Управление Персоналом с редакции 2.5 на редакцию 3.0 или 3.1 стандартным накатыванием файла конфигурации через режим «Конфигуратор» администраторы и разработчики часто сталкиваются с критическими ошибками реструктуризации базы данных. Наиболее распространенное сообщение об ошибке указывает на нарушение уникальности записей в регистре сведений, например, ВоинскийУчет.

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

Технические причины ошибки уникальности при реструктуризации

Рассмотрим, что происходит внутри СУБД и платформы «1С:Предприятие», когда выполняется попытка прямого наката конфигурации .cf редакции 3.x на базу редакции 2.5:

1. Несовпадение внутренних идентификаторов (UUID) метаданных: Конфигурация ЗУП редакции 3.x разрабатывалась с нуля, а не путем эволюционной модификации ветки 2.5. При сравнении и обновлении конфигураций платформа сопоставляет объекты, реквизиты и измерения не по строковым именам (синонимам или идентификаторам), а по их внутренним UUID. Поскольку UUID измерений старого регистра в ЗУП 2.5 и нового регистра в ЗУП 3.x не совпадают, платформа интерпретирует это как удаление старых измерений и добавление абсолютно новых. В результате реструктуризации новые измерения во всех существующих строках заполняются значениями по умолчанию (пустыми ссылками). Это приводит к тому, что все строки регистра получают одинаковый ключ, вызывая блокирующую ошибку СУБД Duplicate key.
2. Изменение структуры периодичности регистров: В редакции 2.5 многие кадровые регистры сведений (включая воинский учет) являлись периодическими (в пределах дня). Уникальность записи гарантировалась составным первичным ключом: Период + Измерения. В редакции 3.x изменилась модель хранения данных — регистры стали непериодическими либо сменили состав измерений. При удалении периодичности поле Период исключается из первичного ключа. Если по одному физическому лицу в базе существовало несколько записей за разные даты, все они претендуют на одну и ту же комбинацию измерений, что делает реструктуризацию невозможной.

Ограничения низкоуровневых механизмов платформы

Проанализируем работу механизма реструктуризации таблиц. Во время применения изменений конфигурации платформа создает во временных таблицах СУБД новую структуру, копирует в нее данные и накладывает уникальные индексы. Платформа не обладает логикой прикладного разрешения коллизий — она не может автоматически выбрать последнюю актуальную запись или очистить дубли. Любое нарушение уникальности ключа таблицы немедленно прерывает транзакцию обновления информационной базы с откатом всех изменений.

Почему конфигуратор предлагает некорректный файл обновления

Иногда конфигуратор в списке доступных обновлений может отобразить переход на релиз 3.x поверх 2.5. Выясним причину такого поведения. Поиск доступных обновлений опирается на файлы манифестов v8upd.manifest в каталогах шаблонов на диске и строковое сопоставление имени конфигурации. Наличие в общих шаблонах файлов смежных конфигураций или пакетов переходов может приводить к ошибочному отображению несовместимой версии в мастере поиска.

Важно понимать: дистрибутивов прямого обновления (.cfu) с редакции 2.5 на редакции 3.0 и 3.1 фирмы «1С» не существует. Любая попытка объединить конфигурации или накатить файл .cf приведет к разрушению структуры данных.

Штатный регламент перехода с ЗУП 2.5 на ЗУП 3.x

Переход между принципиально разными редакциями осуществляется исключительно через перенос данных в новую, чистую информационную базу ЗУП 3.x. Разберем правильный порядок действий по шагам:

1. Подготовка исходной базы: Выполним резервное копирование рабочей базы ЗУП 2.5, закроем расчетные периоды, проверим и исправим ошибки учета, а также обновим базу 2.5 до актуального релиза, поддерживающего выгрузку данных в целевую версию 3.x.
2. Создание пустой информационной базы ЗУП 3.x: Развернем новую информационную базу из типового шаблона актуального релиза редакции 3.1.
3. Запуск помощника начальной настройки: При первом запуске пустой базы ЗУП 3.x откроется стартовый помощник, где необходимо выбрать вариант «Перенести данные из информационной базы 1С:Зарплата и кадры 7.7 или 1С:Зарплата и Управление Персоналом 8, ред. 2.5».
4. Выбор варианта переноса данных:
   1. Рекомендованный перенос (перенос среза данных): Оптимальный вариант для большинства предприятий. Переносятся справочники (организации, подразделения, должности, физические лица, сотрудники), кадровые срезы на выбранную дату начала учета и данные для расчета среднего заработка за предыдущие расчетные периоды (для отпусков, больничных и пособий). Старые громоздкие расчетные документы за прошлые годы не переносятся, что обеспечивает высокую производительность новой базы.
   2. Полный перенос данных: Переносит кадровую историю и расчетные данные за прошлые периоды в виде специальных документов ПереносДанных, заполняющих регистры накопления и расчета напрямую. Этот вариант требует значительных трудозатрат на последующую сверку итогов.
5. Проверка и сверка перенесенных данных: Сверим кадровые остатки, штатную расстановку, сальдо по взаиморасчетам и контрольные расчеты среднего заработка между старой и новой базами перед началом полноценной расчетной работы.