При переходе на новые версии программных продуктов 1С (особенно в линейке 3.0.142.х) многие технические специалисты столкнулись с проблемой остановки процесса обновления. Программа выдает критическую ошибку: «При выполнении обработок обновления программа не обновлена. Причина: уже существует основание увольнения с таким кодом...». Чаще всего фигурирует код типа ч1тк или аналогичные сокращения. В этой статье мы подробно разберем, почему возникает эта ситуация, как механизмы РИБ влияют на справочники классификаторов и как правильно очистить базу от дублей, чтобы успешно завершить обновление.
Начиная с версии 3.0.142, фирма «1С» внедрила обновленный классификатор оснований увольнения, необходимый для корректного заполнения подразделов формы ЕФС-1. Процедура обновления ОбновитьКлассификаторОснованийУвольнения призвана синхронизировать данные вашего справочника ОснованияУвольненияПФР с эталонным перечнем, зашитым в конфигурации.
Проанализируем ситуацию: почему система видит дубли? Основная причина кроется в несовпадении внутренних идентификаторов (GUID). Если когда-то в базу были добавлены элементы вручную или они «прилетели» из другой информационной базы через механизм РИБ (Распределенная Информационная База), то при обновлении алгоритм пытается создать стандартные элементы. Он ищет существующую запись по ссылке, не находит ее и пытается создать новую с правильным кодом. Однако в базе уже есть запись с таким же кодом, но другой ссылкой. Возникает конфликт уникальности индекса.
Рассмотрим типичную ошибку администратора: попытку переименовать старые коды (например, добавить # или _ перед кодом), чтобы «освободить» место для новых. Как показывает практика, это приводит к еще большему замусориванию базы. Проанализируем, что происходит:
ч1тк на #ч1тк.ч1тк нет, и создает его заново.В итоге мы получаем справочник, где на каждую статью ТК РФ приходится по два-три одинаковых элемента. Это блокирует не только обновление, но и корректную работу кадровых документов.
Проанализируем влияние распределенных баз. В архитектуре РИБ справочники классификаторов часто синхронизируются между узлами. Если в периферийной базе пользователь (или программист) добавил элемент вручную, при синхронизации он попадает в центральную базу. Поскольку этот элемент создан не штатным механизмом обновления, его GUID отличается от того, который ожидает увидеть конфигурация после обновления. Именно это становится «миной замедленного действия», которая срабатывает при попытке обновиться на релиз с жесткой проверкой кодировки ЕФС-1.
Рассмотрим последовательность действий для исправления ситуации. Перед началом любых манипуляций обязательно создайте резервную копию базы данных.
Шаг 1. Поиск дублей через консоль запросов.
Нам необходимо понять масштаб трагедии. Выполним запрос к справочнику, чтобы увидеть все записи, включая помеченные на удаление и скрытые. Проанализируем поля Ссылка, Код и Наименование.
ВЫБРАТЬ
Основания.Ссылка КАК Ссылка,
Основания.Код КАК Код,
Основания.Наименование КАК Наименование,
Основания.ПометкаУдаления КАК ПометкаУдаления
ИЗ
Справочник.ОснованияУвольненияПФР КАК Основания
УПОРЯДОЧИТЬ ПО
Код
Шаг 2. Использование типовой обработки «Поиск и удаление дублей».
Посмотрим, как стандартные средства 1С могут нам помочь. Откройте обработку (Администрирование — Обслуживание — Корректировка данных — Поиск и удаление дублей):
Основания увольнения (ПФР).Кода.Шаг 3. Очистка справочника в сложных случаях.
Если объединение не помогает и ошибка при обновлении сохраняется, разберем более радикальный метод. Если ссылок на этот справочник в документах прошлых периодов немного или они отсутствуют (база новая или учет только начинается), можно полностью очистить справочник ОснованияУвольненияПФР. После очистки процедура обновления создаст все элементы «с чистого листа» с правильными идентификаторами.
Шаг 4. Анализ журнала регистрации.
Проанализируем, кто и когда вносил изменения. Как советуют опытные специалисты, необходимо проверить журнал регистрации по фильтру данного справочника. Если вы увидите массовые изменения от имени «Обмен данными» или конкретного пользователя, это поможет локализовать узел РИБ, из которого приходят некорректные записи.
Иногда ошибка возникает не в момент первого запуска, а при выполнении отложенных обработок. В этом случае полезно заглянуть в регистр сведений СтатусыОбъектовКлассификаторов. Если там зафиксирована ошибка обновления конкретного раздела, система будет пытаться повторить операцию снова и снова, плодя дубли. В некоторых ситуациях помогает временное отключение расширений конфигурации при запуске обновления с параметром /NoExtensions, так как расширения могут блокировать процедуры записи в справочники.
Проблема с кодом ч1тк — это классический конфликт данных в распределенной среде при изменении структуры классификаторов. Для успешного завершения обновления на 3.0.142.56 нам необходимо обеспечить уникальность кодов и соответствие элементов справочника эталонным значениям. Помните, что механическое переименование кодов лишь маскирует проблему, а правильный путь — это поиск, объединение или полная перегенерация данных классификатора штатными средствами обновления.