Как проверить запросы и BSL после ИИ: метаданные и API платформы
Практический порядок проверки сгенерированного кода 1С: syntax_ref, check_query по метаданным, check_bsl_api по корпусу платформы и запуск в тестовой базе.
После генерации BSL и запросов стоит проверить три вещи: правильно ли записана конструкция, существуют ли таблицы и поля в вашей конфигурации и есть ли нужный метод в API платформы. Один успешный запуск не отвечает на все три вопроса: запрос может выполниться, но выбрать не те данные.
В MCP-1C для этого есть справочник code_search.syntax_ref в Расширенной редакции, семантическая проверка check_query в Профессиональной с v2.25.0 и проверка API check_bsl_api в Профессиональной с v2.27.0. Они дополняют обычное ревью и запуск на тестовых данных. Версии появления приведены в истории изменений.
В статье: три проверки, запрос по метаданным, API платформы, рабочий порядок.
Разделите три проверки
| Вопрос | Источник для проверки | Чего он не доказывает |
|---|---|---|
| Как записывается конструкция | Справочник языка и синтаксическая проверка | Что поле существует в вашей конфигурации |
| Есть ли таблица и нужное поле | Метаданные конкретной выгрузки | Что выборка даёт правильный бизнес-результат |
| Есть ли вызов API платформы | Загруженный синтаксический корпус | Что вся процедура корректна в нужном контексте исполнения |
Для поиска конструкции ПОДСТРОКА вызовите code_search с аргументами:
{
"action": "syntax_ref",
"query": "ПОДСТРОКА",
"domain": "query"
}
Справочник работает офлайн, без выгрузки и живой базы; доступны также области scd и format. Подробности — в описании code_search.
Сверьте запрос с метаданными
check_query принимает текст запроса и проверяет его по метаданным выгрузки. Полные проверки существования включаются при запуске сервера с --dump и --enable-query-resolve. Без них остаётся синтаксическая и структурная проверка — это меньший объём проверки, который нельзя принять за полную сверку.
Пример аргументов отдельного инструмента check_query:
{
"query": "ВЫБРАТЬ Товары.Наименование ИЗ Справочник.Номенклатура КАК Товары",
"format": "json"
}
Название справочника здесь условное: используйте объекты своей выгрузки. QRY031 указывает на отсутствующее поле объекта, а QRY032 — на проблему разыменования через точку. Например, существование Документ.Контрагент ещё не подтверждает, что следующий сегмент Контрагент.РегионПродаж существует у ссылочного типа.
Проверка полей охватывает восемь видов объектов: справочники, документы, регистры сведений и накопления, планы счетов и видов характеристик, задачи и бизнес-процессы. Уточнения и параметры опубликованы в контракте check_query. Не переносите этот охват автоматически на все конструкции языка запросов.
Проверьте вызовы платформы
check_bsl_api принимает code и необязательный format: "json" или "text". Он работает по синтаксическому корпусу, который администратор обновляет через --update-syntax; живая база и выгрузка конфигурации для него не нужны.
Диагностика API001 относится к устаревшему глобальному методу. Если корпус содержит сведения о версии и замене, они попадут в сообщение. API010 означает, что вызов без префикса не найден в загруженном корпусе. Это предупреждение: причиной может быть опечатка, другой контекст или другая версия платформы. Отсутствие в корпусе не равно доказанному отсутствию метода.
Инструмент не выводит тип приёмника, поэтому вызовы Объект.Метод() не проверяются. Конструкторы, количество и типы аргументов также вне его области. Если корпус не загружен, проверки пропускаются с явной отметкой. Эти границы важны при чтении пустого отчёта; полный список приведён в описании check_bsl_api.
Рабочий порядок после генерации
Сначала установите источник контекста: версию платформы и ревизию выгрузки. Затем проверьте синтаксис, существование полей и подходящие глобальные вызовы API. Исправляйте замечания по фактам, сохраняя непроверенные места отдельным списком.
После этого выполните запрос или процедуру в тестовой базе на данных с известным ожидаемым результатом. Для отчёта проверьте не только непустую выборку, но и итоги, отборы и границы периода. Для процедуры — изменение состояния и обработку ошибок. Статические проверки помогают найти ошибки раньше; смысл результата подтверждает прикладной сценарий.
О причинах выдуманных полей мы писали в статье «Почему нейросеть ошибается в запросах к 1С».