Как найти место ошибки в 1С, если в журнале регистрации не указан стек вызовов, а только текст сообщения

← На главную

В практике разработчика 1С часто возникает ситуация, когда пользователь сообщает об ошибке, или вы обнаруживаете запись в Журнале регистрации (ЖР), которая не содержит ссылки на конкретную строку кода. Сообщение вида «Значение поля "Номенклатура" не заполнено или заполнено неверно» является классическим примером системного уведомления платформы. Проблема заключается в том, что такое сообщение может генерироваться не программным вызовом Сообщить(), а внутренними механизмами платформы «1С:Предприятие».

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

1. Анализ механизма автоматической проверки заполнения

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

Для поиска «виновника» выполним следующие шаги:

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

Также стоит заглянуть в модуль объекта. Разберем по шагам работу с событием ОбработкаПроверкиЗаполнения. В этом методе разработчики часто программно добавляют реквизиты в массив ПроверяемыеРеквизиты или вызывают метод ПроверитьЗаполнение(). Рассмотрим пример кода:


Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
    // Если условие выполняется, добавляем номенклатуру в список обязательных
    Если ЭтоСпециальныйСлучай Тогда
        ПроверяемыеРеквизиты.Добавить("Номенклатура");
    КонецЕсли;
КонецПроцедуры

Если вы видите подобный код, значит, причина именно здесь. Платформа проверяет наличие Номенклатура в списке и, если поле пустое, выдает стандартное сообщение.

2. Использование отладчика и режима «Остановка по ошибке»

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

Выясним причину, пройдя по шагам:

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

В такой ситуации применим метод «точек останова». Найдем процедуру ПередЗаписью в модуле объекта и модуле формы подозрительного документа. Установим точку останова в самом начале и начнем выполнение операции в режиме предприятия. Шагая по коду с помощью клавиш F10 (шаг через) и F11 (шаг внутрь), мы поймаем момент, когда управление передается платформе для записи, и именно в этот момент возникнет окно с ошибкой.

3. Настройка Технологического журнала (ТЖ)

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

Для локализации сообщения нам нужно создать файл конфигурации logcfg.xml. Настроим его так, чтобы он собирал события пользовательского интерфейса и ошибки. Проанализируем пример структуры файла:


<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\LOGS\1C" history="24">
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="UI"/>
    </event>
    <property name="All"/>
  </log>
</config>

Событие EXCP зафиксирует исключение, а UI (User Interface) поможет увидеть текст, выводимый пользователю. После возникновения ошибки откройте лог-файлы в папке C:\LOGS\1C и выполните поиск по строке «Номенклатура». ТЖ покажет контекст выполнения, включая стек вызовов, что позволит точно определить модуль и строку кода.

4. Проверка Системы компоновки данных (СКД)

Если ошибка появляется не при записи объекта, а при формировании отчета или динамического списка, причину нужно искать в СКД. В схеме компоновки данных предусмотрен механизм контроля заполнения параметров.

Разберем, как это проверить:

Откроем схему компоновки данных отчета.
Перейдем на вкладку «Параметры».
Найдем параметр Номенклатура.
Проверим колонку «Запрет незаполненных значений».

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

5. Специфика веб-сервисов и XDTO-пакетов

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

Посмотрим на ситуацию глубже: в XDTO-пакете для каждого свойства можно указать минимальное количество вхождений (MinOccurs). Если для свойства «Номенклатура» установлено MinOccurs = 1, а во входящем XML или JSON это поле отсутствует или пустое, платформа выдаст системную ошибку еще до того, как данные попадут в ваш программный код. В этом случае место ошибки — сам момент вызова метода ПрочитатьXML() или точка входа веб-сервиса.

6. Анализ расширений конфигурации

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

Проверьте, не переопределены ли свойства реквизита Номенклатура в расширении.
Поищите методы &Перед, &После или &Вместо для процедур ПередЗаписью или ОбработкаПроверкиЗаполнения.

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

7. Битая ссылка или неверный тип данных

Напоследок рассмотрим редкий, но коварный случай. Сообщение «заполнено неверно» может возникать, если поле визуально заполнено, но содержит «Битую ссылку» (объект был удален из базы, а ссылка на него осталась в документе). Платформа видит, что ссылка не ведет на существующий объект, и считает поле незаполненным или заполненным некорректно.

Выясним это с помощью консоли запросов или простой проверки в коде:


Если Объект.Номенклатура.ПолучитьОбъект() = Неопределено Тогда
    Сообщить("В поле находится битая ссылка!");
КонецЕсли;

Также проверьте составной тип данных. Если в поле Номенклатура разрешено выбирать и СправочникСсылка.Номенклатура, и СправочникСсылка.Услуги, убедитесь, что в коде или настройках не стоит жесткое ограничение на конкретный тип, который не совпадает с выбранным.

Используя предложенные методы — от анализа метаданных до настройки Технологического журнала — вы сможете локализовать и устранить причину любой «невидимой» ошибки в кратчайшие сроки.