Ошибки после проверки конфигурации в Конфигураторе: разбор по типам и порядок исправления

Проверка конфигурации в 1С 8.3 запускается в Конфигураторе через меню Конфигурация → Проверка конфигурации.... Ошибки из её отчёта исправляют не в базе, а в метаданных и модулях: двойной щелчок по строке отчёта открывает нужный объект или строку кода. Частое заблуждение — что эта проверка «чинит» базу. Нет: она только находит ошибки, а исправляете их вы или разработчик. Битые данные в таблицах лечит другой инструмент — тестирование и исправление информационной базы.

Порядок такой: сначала логическая целостность и некорректные ссылки, затем синтаксис модулей, затем расширения и внешние обработки. Если после этого в пользовательском режиме остаются странные остатки и итоги — переходите к регистрам. Ниже каждый тип ошибок разобран отдельно.

Как запустить проверку конфигурации и прочитать отчёт

Откройте базу в режиме Конфигуратора и откройте конфигурацию (Конфигурация → Открыть конфигурацию). Проверяется основная конфигурация, а не конфигурация базы данных — то есть то, что вы видите в дереве метаданных, включая несохранённые изменения.

В окне проверки отметьте флажки:

• 🧩 Проверка логической целостности конфигурации — связи между объектами, формы, реквизиты, подписки на события.
• 🔗 Поиск некорректных ссылок — ссылки на удалённые или несуществующие объекты.
• 📄 Синтаксический контроль модулей с выбором режимов исполнения: тонкий клиент, веб-клиент, сервер, внешнее соединение, толстый клиент.
• 🔍 Поиск неиспользуемых процедур и функций и проверка существования назначенных обработчиков — включайте, когда наводите порядок, а не при срочном ремонте.

Результат выводится в окно служебных сообщений. Каждая строка начинается с пути к объекту или модулю, затем идёт текст ошибки. Двойной щелчок переносит к месту проблемы.

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

Нарушения логической целостности: что они значат и как их устранить

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

Типичные ситуации:

• ❌ Ссылка на несуществующий объект. Реквизит документа имеет тип «СправочникСсылка.Склады», а справочник удалён или переименован. Откройте свойства реквизита и задайте тип заново.
• ❌ Пустое значение обязательного свойства. Например, у формы не назначена основная, у регистра не указан регистратор, у подписки на событие не задан обработчик.
• ❌ Объект входит в подсистему или функциональную опцию, которой больше нет. Исправляется в свойствах объекта на вкладке подсистем или в составе функциональной опции.
• ❌ Конфликт имён после объединения: два объекта или два реквизита с одинаковым именем в одной коллекции.

Чтобы быстро найти, кто ещё ссылается на проблемный объект, вызовите на нём в дереве команду поиска ссылок на объект (контекстное меню). Список покажет реквизиты, формы, роли и модули, где объект используется.

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

Роли и права доступа: ошибки, которые находит проверка

Роли — частый источник сообщений после доработок. Проверка конфигурации ловит в них две группы проблем.

1. Текст ограничения доступа к данным (RLS) с ошибкой. Ограничения на уровне записей пишутся на языке, похожем на язык запросов. Если в тексте упомянут удалённый реквизит или таблица, проверка выдаст ошибку в роли. Откройте роль, найдите объект, у которого заполнено ограничение, и исправьте текст. Для типовых конфигураций на БСП ограничения часто собраны из шаблонов, поэтому ошибка может быть в шаблоне роли, а не в конкретной строке.

2. Права на объекты, которых нет. После объединения конфигураций в роли могут остаться права на удалённые объекты. Это ловится логической целостностью.

Есть ошибки прав, которые проверка конфигурации не видит, — они проявляются только у пользователя:

Чтобы проверить, проверьте права конкретного пользователя: в типовых конфигурациях на БСП это делается через карточку пользователя и его группы доступа в пользовательском режиме (Администрирование → Настройки пользователей и прав). В Конфигураторе у роли видно, какие права включены для каждого объекта.

Ошибки компиляции и синтаксиса модулей

Синтаксический контроль — самая понятная часть отчёта. Типичные тексты:

• 📝 Переменная не определена (ИмяПеременной) — опечатка или переменная объявлена в другом модуле без Экспорт.
• 📝 Процедура или функция с указанным именем не определена — вызов процедуры общего модуля, которая удалена или не экспортирована.
• 📝 Ожидается символ ';' и подобные — синтаксическая ошибка рядом с указанной строкой (часто строкой выше).
• 📝 Использование процедуры (функции) ... в данном режиме не допускается — например, серверный метод вызван в клиентском контексте.

Последний тип ошибки появляется именно потому, что модуль проверяется в нескольких режимах. Код может компилироваться на сервере, но не на тонком клиенте. Поэтому в окне проверки отмечайте те режимы, в которых реально работают пользователи. Для управляемого приложения минимум — тонкий клиент, сервер и, если есть веб-доступ, веб-клиент. Толстый клиент обычного приложения отмечайте, только если пользователи им пользуются.

Как исправлять:

1. Дважды щёлкните по строке ошибки — откроется модуль на нужной строке.
2. Проверьте директиву компиляции над процедурой: &НаКлиенте, &НаСервере, &НаСервереБезКонтекста.
3. Для общих модулей проверьте флажки в свойствах: «Клиент (управляемое приложение)», «Сервер», «Вызов сервера», «Внешнее соединение».
4. Внутри процедур, которые должны работать в разных режимах, используйте инструкции препроцессора:

#Если Сервер Или ТолстыйКлиентОбычноеПриложение Или ВнешнееСоединение Тогда
	// код, допустимый только на сервере
#КонецЕсли

Для проверки одного открытого модуля не нужно запускать полную проверку: в модуле есть команда синтаксического контроля (меню Текст или контекстное меню модуля). Она быстрее и проверяет только текущий текст.

Конфликты после обновления и несовпадение версий платформы

После обновления типовой конфигурации проверка нередко выдаёт пачку ошибок. Причины три.

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

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

Версия платформы ниже требуемой. Релизы конфигураций требуют платформу с номером не ниже определённого. Если номер установленной платформы меньше, конфигурация может не загрузиться или не обновиться. Номер видно в Конфигураторе: Справка → О программе.

Регистры накопления, итоги и срезы: когда проблема не в конфигурации

Бывает, что проверка конфигурации чистая, а остатки в отчётах «прыгают», срезы последних в регистрах сведений показывают не то значение, отрицательные остатки появляются без причины. Здесь дело в данных, а не в метаданных.

Порядок действий:

1. Пересчёт итогов. В Конфигураторе: Администрирование → Тестирование и исправление..., флажок пересчёта итогов. Регистры накопления и бухгалтерии хранят итоги отдельно от движений, и при сбое они расходятся.
2. Проверка ссылочной целостности в том же окне — находит записи, ссылающиеся на удалённые объекты («Объект не найден»), и предлагает создать объекты-заглушки или очистить ссылки.
3. Реструктуризация таблиц — флажок там же, нужен при повреждении структуры.
4. Для файловой базы с физическим повреждением файла 1Cv8.1CD — утилита chdbfl.exe из каталога bin платформы. Её запускают при закрытой базе.

Отдельно — проблема с регистрами, которая вызвана кодом. Если документ при проведении пишет неверные движения, тестирование не поможет: оно пересчитает итоги по тем же неверным движениям. Проверьте обработку проведения документа и подписки на события, которые меняют движения. Здесь как раз пригодится проверка существования назначенных обработчиков: подписка, указывающая на удалённую процедуру, не сработает.

Расширения и внешние обработки: как проверить и найти ошибку

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

Что чаще всего ломается:

• 🧷 Заимствованный объект изменился в основной конфигурации. После обновления типовой у заимствованного реквизита сменился тип или объект удалён — расширение перестаёт применяться. Пользователь видит сообщение, что расширение не может быть применено, и его доработки пропадают.
• 🧷 Перехват процедуры, которой больше нет. Аннотации &Перед, &После, &Вместо, &ИзменениеИКонтроль указывают на имя процедуры основной конфигурации. Если поставщик её переименовал, перехват ломается. Для &ИзменениеИКонтроль платформа контролирует ещё и текст процедуры: изменился исходник — перехват придётся перенести на новый код.
• 🧷 Безопасный режим. Расширение в безопасном режиме не может, например, работать с файлами на сервере. Ошибка выглядит как отказ в доступе, хотя код правильный.

Внешние обработки и отчёты (.epf, .erf) проверка конфигурации не видит вообще. Откройте файл в Конфигураторе через Файл → Открыть и выполните синтаксический контроль модуля объекта и модулей форм. Если обработка писалась под старую версию конфигурации, ошибка обычно в обращении к реквизиту или процедуре, которых в текущем релизе нет.

Регулярная проверка и автоматизация через пакетный режим

Ручная проверка перед каждым обновлением занимает время. Её можно запускать командой без открытия Конфигуратора — это удобно перед обновлением и в ночных заданиях.

Пример для файловой базы:

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" ^
 /CheckConfig -ConfigLogIntegrity -IncorrectReferences -ThinClient -WebClient -Server -ExternalConnection ^
 /Out"D:\Logs\checkconfig.log" /DisableStartupDialogs

Что здесь важно:

• /CheckConfig — та же проверка конфигурации, ключи после неё соответствуют флажкам окна;
• -ConfigLogIntegrity — логическая целостность, -IncorrectReferences — некорректные ссылки;
• -ThinClient, -WebClient, -Server, -ExternalConnection — режимы синтаксического контроля;
• /Out — файл, куда пишется результат; его удобно отправлять себе или сравнивать с прошлым запуском.

Для расширения добавьте ключ -Extension с его именем или -AllExtensions, чтобы проверить все. Путь к 1cv8.exe подставьте свой: номер в каталоге совпадает с номером установленной платформы. Для клиент-серверной базы вместо /F указывают /S"сервер\база".

Пароль в bat-файле — плохая практика. Заведите для проверок отдельного пользователя с административной ролью и храните файл там, куда нет доступа у обычных сотрудников.

Минимальный регламент, который реально экономит время при обновлениях:

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

Частые вопросы