Проверка конфигурации 1С: что это и зачем она нужна

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

Механизм проверяет не только синтаксис встроенного языка, но и корректность ссылок между объектами метаданных, права доступа, заполнение обязательных свойств, соответствие модулей контексту исполнения. Например, если в модуле формы вызывается серверная процедура, которой не существует, или в роли указан объект, удалённый из конфигурации, проверка покажет это в виде списка ошибок с указанием места.

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

Что именно проверяет платформа

При запуске проверки платформа последовательно анализирует дерево метаданных: справочники, документы, регистры, отчёты, обработки, роли, общие модули и другие объекты. Для каждого объекта проверяется корректность его свойств, наличие обязательных реквизитов и согласованность с другими объектами. Например, если документ указан в последовательности, которая была удалена, или движения документа ссылаются на несуществующий регистр, это будет зафиксировано.

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

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

Виды проверки конфигурации

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

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

Сравнение вариантов

Быстрая проверка (целостность + модули)

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

Полная проверка всех режимов

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

Проверка расширения отдельно

Применяется при разработке расширений, чтобы не затрагивать основную конфигурацию

Как запустить проверку: пошаговый порядок

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

1. 1
   Откройте базу в конфигураторе с правами на изменение конфигурации
2. 2
   Убедитесь, что конфигурация открыта: меню «Конфигурация → Открыть конфигурацию»
3. 3
   Выберите «Конфигурация → Проверка конфигурации»
4. 4
   Отметьте нужные режимы проверки флажками, при необходимости включите проверку модулей в контекстах клиента и сервера
5. 5
   Нажмите «Выполнить» и дождитесь завершения анализа
6. 6
   Разберите список ошибок в окне сообщений: двойной щелчок открывает проблемное место
7. 7
   Исправьте ошибки и повторите проверку до чистого результата

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

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

Как читать результаты и исправлять типовые ошибки

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

Типовая ситуация после объединения конфигураций — массовые ошибки вида «объект не найден» в ролях и подписках на события. Обычно это следствие того, что объекты при объединении получили другие имена или были удалены. Исправляется вручную: открывается роль или подписка, снимаются ссылки на отсутствующие объекты.

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

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

Проверка перед обновлением и после доработок

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

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

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

Ограничения и частые ошибки при работе с проверкой

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

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

Контрольные точки

Как проверить результат

Окно сообщений после проверки

Норма

Пусто или только информационные сообщения

Тревожный признак

Есть строки с пометкой «Ошибка»

Обновление конфигурации базы данных

Норма

Завершается без сообщений об ошибках

Тревожный признак

Процесс прерывается или выводит список конфликтов

Запуск базы в пользовательском режиме

Норма

Формы открываются, документы проводятся

Тревожный признак

Ошибки компиляции при открытии объектов

Повторная проверка после исправлений

Норма

Количество ошибок уменьшается до нуля

Тревожный признак

Ошибки сохраняются или появляются новые

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

Чем проверка конфигурации отличается от тестирования и исправления?

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

Можно ли запускать проверку, пока пользователи работают в базе?

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

Сколько времени занимает полная проверка?

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

Что делать, если ошибка находится в типовом коде на поддержке?

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

Нужно ли проверять расширения конфигурации отдельно?

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

Проверка не выявила ошибок, но база работает некорректно. Почему?

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