Как исправить ошибку с ссылками на удаляемый регистр накопления НДСпоОСиНМА при обновлении 1С:УПП?

При обновлении нетиповых или находящихся на частичной поддержке конфигураций 1С:Управление производственным предприятием (УПП) с релиза 1.3.86.3 на релиз 1.3.87.2 разработчики часто сталкиваются с ошибкой контроля ссылочной целостности: «Обнаружены ссылки на следующие объекты, помеченные на удаление: Регистры накопления НДСпоОСиНМА». Конфигуратор блокирует сохранение конфигурации базы данных, сообщая о наличии многочисленных зависимостей в метаданных.

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

Причина возникновения ошибки в релизе 1.3.87

В рамках рефакторинга подсистемы учета налога на добавленную стоимость фирма «1С» полностью исключила регистр накопления НДСпоОСиНМА из типовой конфигурации. В эталонной конфигурации поставщика были одновременно удалены сам регистр и все движения по нему во всех типовых документах-регистраторах.

Однако, если ваша информационная база снята с полной поддержки (находится в режиме редактирования с сохранением поддержки), механизм сравнения и объединения конфигураций сохраняет пользовательские свойства доработанных объектов. В результате возникают следующие коллизии:

1. Типовые документы (например, Документ.РеализацияТоваровУслуг), в которых ранее были включены доработки, сохраняют флаг движения по удаляемому регистру.
2. В конфигурации присутствуют добавленные нетиповые документы, для которых данный регистр был указан в качестве регистратора.
3. На регистр продолжают ссылаться измененные роли пользователей, подсистемы, планы обмена или критерии отбора.

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

Способ 1. Очистка списка регистраторов через свойства регистра

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

Выполним следующие действия:

1. Откроем дерево метаданных конфигурации до начала объединения с файлом обновления .cf (или вернемся к конфигурации до применения обновления).
2. Найдем ветку Регистры накопления и откроем окно редактирования объекта НДСпоОСиНМА.
3. Перейдем на закладку «Регистраторы».
4. Снимем флажки со всех документов, выбрав команду снятия всех отметок.
5. Нажмем кнопку «Закрыть» и обновим конфигурацию базы данных клавишей F7.

После того как документы перестанут быть регистраторами для регистра НДСпоОСиНМА, последующее обновление на релиз 1.3.87.2 пройдет без блокировки по регистраторам, так как взаимные ссылки метаданных будут разорваны.

Способ 2. Правильное сопоставление свойств движений в окне сравнения и объединения

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

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

Способ 3. Поиск скрытых зависимостей в нетиповых объектах

Если после очистки регистраторов конфигуратор все равно выдает сообщение о наличии ссылок, причиной являются нетиповые объекты или элементы прав доступа. Чтобы не перебирать дерево вручную, воспользуемся встроенным инструментом платформы:

1. В дереве метаданных щелкнем правой кнопкой мыши по объекту РегистрыНакопления.НДСпоОСиНМА.
2. В контекстном меню выберем пункт «Поиск ссылок на объект».
3. Платформа сформирует отчет со всеми местами использования. Проанализируем список:
4. Нетиповые документы: если в базе созданы собственные документы, выполнявшие движения по этому регистру, откроем их свойства и на вкладке «Движения» вручную снимем признак использования данного регистра.
5. Роли: если в пользовательских ролях были назначены права (например, Чтение или Изменение) на этот регистр, откроем эти роли и снимем галочки прав с регистра НДСпоОСиНМА.
6. Планы обмена: проверим, не включен ли регистр в состав распределенной информационной базы (РИБ) или обмена данными. Если регистр включен в состав плана обмена, исключим его оттуда.
7. Подсистемы и интерфейсы: снимем вхождение регистра в пользовательские подсистемы и командные интерфейсы обычных форм.

Способ 4. Сохранение архивных данных (если удаление недопустимо)

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

В такой ситуации применим безопасный сценарий архивации:

1. Перед началом обновления переименуем регистр в основной конфигурации, например, в НДСпоОСиНМА_Архив или УдалитьНДСпоОСиНМА.
2. Снимем переименованный регистр с поддержки поставщика (установим статус «Редактируется с сохранением поддержки» или снимем полностью).
3. Исключим архивный регистр из списка движений рабочих документов, чтобы новые проводки по нему не формировались.
4. Запустим обновление на релиз 1.3.87.2. Поскольку имя объекта изменилось, платформа не сопоставит переименованный регистр с удаленным типовым регистром поставщика, и таблица в базе данных со всеми историческими записями останется нетронутой.

Также при возникновении комплексных коллизий метаданных рекомендуется выполнять обновление поэтапно: сначала выполнить переход с 1.3.86.3 на промежуточный релиз 1.3.87.1, разрешить все конфликты метаданных, применить конфигурацию базы данных и только после этого накатывать финальный релиз 1.3.87.2.