Как с помощью ИИ разбираться в чужой конфигурации 1С и не придумывать причины ошибок

Как с помощью ИИ разбираться в чужой конфигурации 1С и не придумывать причины ошибок

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

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

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

Почему не стоит просить «объяснить всю конфигурацию»

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

Надёжнее начать с наблюдаемого действия пользователя. Например: «При проведении конкретного заказа ожидался отказ из-за превышения кредитного лимита, но заказ был проведён». Это ещё не причина ошибки, но уже хорошая граница исследования.

Для выбранного действия полезно последовательно ответить на пять вопросов:

1. Какая форма, команда или событие запускает действие?

2. Какие модули и процедуры исполняются дальше?

3. Откуда берутся данные правила и где они могут изменяться?

4. Какие расширения, подписки, общие модули и права способны повлиять на путь?

5. Чем проверить предполагаемое поведение именно в текущей базе?

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

Три статуса, без которых карта быстро превращается в догадку

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

• Факт текста — утверждение прямо видно в предоставленном артефакте: строке модуля, свойстве метаданных, настройке или журнале.

• Гипотеза исполнения — правдоподобное предположение о том, что этот фрагмент выполняется в рассматриваемом сценарии.

• Неизвестно — данных для вывода нет либо источник не был предоставлен.

Например, строка Если Не КонтрольЛимитаКлиента.ПроверитьЗаказ(...) Тогда подтверждает, что модуль объекта содержит вызов функции. Но она сама по себе не доказывает, что процедура была вызвана для обращения пользователя, что внутри функции нет другого условия или что расширение не изменило сценарий.

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

Условный кейс: заказ проходит при превышенном лимите

Представим, что в учебной базе есть документ ЗаказКлиента, регистр сведений ЛимитыКонтрагентов, регистр накопления ВзаиморасчетыСКлиентами и подключённое расширение ОсобыеУсловияПродаж. От оператора поступила жалоба: иногда заказ проводится при превышенном лимите. Конкретный документ, время и условия воспроизведения не приложены.

В модуле объекта найден фрагмент:

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
     Если Не КонтрольЛимитаКлиента.ПроверитьЗаказ(Контрагент, СуммаДокумента, Дата, Ссылка) Тогда
         Отказ = Истина;
     КонецЕсли;
 КонецПроцедуры

А в общем модуле — такой код:

Функция ПроверитьЗаказ(Контрагент, СуммаЗаказа, ДатаЗаказа, Заказ) Экспорт
     Лимит = ПолучитьЛимит(Контрагент, ДатаЗаказа);
     Долг = ВзаиморасчетыКлиентов.ПолучитьДолг(Контрагент, ДатаЗаказа);
     Возврат Долг + СуммаЗаказа <= Лимит;
 КонецФункции
 
 Функция ПолучитьЛимит(Контрагент, ДатаЗаказа)
     // Запрос к регистру ЛимитыКонтрагентов; текст запроса не предоставлен.
 КонецФункции

Из этих фрагментов можно уверенно записать в карту следующее:

• ОбработкаПроведения содержит вызов ПроверитьЗаказ;

• если функция возвращает Ложь, устанавливается Отказ;

• функция складывает долг и сумму заказа, а затем сравнивает результат с лимитом;

• для получения лимита и долга вызываются другие функции.

Но нельзя утверждать, что найден корень проблемы. Нам неизвестны текст ПолучитьЛимит, способ расчёта долга, обработка пустого лимита, состав расширения, права менеджера и фактические параметры спорного заказа. Комментарий о регистре не заменяет текст запроса. Жалоба оператора подтверждает наличие обращения, но не выполнение конкретного участка кода.

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

Какие слои нужно учитывать в незнакомой базе

Один модуль редко объясняет наблюдаемый результат целиком. В минимальную инвентаризацию сценария обычно входят:

• метаданные: документ, форма, команда, регистр, общий модуль;

• код основной конфигурации;

• расширения и их заимствованные объекты;

• подписки на события и обработчики;

• настройки, данные и права пользователя;

• версия конфигурации и платформы;

• фактическое наблюдение: документ, дата, пользователь, входные значения, сообщение или результат.

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

Инструменты конфигуратора и 1C:EDT помогают ориентироваться в объектах, расширениях и исходниках текущего проекта. Но они не отменяют необходимость определить сценарий и проверить его в подходящей среде.

Где ИИ действительно помогает

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

• составить инвентаризацию переданных файлов и объектов;

• построить черновую цепочку вызовов по доступным фрагментам;

• привязать каждый вывод к цитате и пути файла;

• разделить факты, гипотезы и открытые вопросы;

• найти противоречия между фрагментами;

• подготовить список недостающих артефактов и план ручной проверки.

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

Запрос к модели может звучать так:

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

Такой контракт важнее красивой формулировки промпта. Он запрещает модели заполнять пробелы общими знаниями и делает результат удобным для ревью.

Как проверить ответ модели

Проверка ответа ИИ начинается не с вопроса «звучит ли он убедительно?», а с более простых вопросов:

1. Для каждого вывода есть конкретный источник и цитата?

2. Не перепутаны ли факт текста и факт исполнения?

3. Названы ли расширения, права, версия и другие возможные слои влияния?

4. Перечислены ли пробелы в данных?

5. Можно ли по итогам сформулировать одно следующее проверяемое действие?

Например, фраза «лимит точно берётся из регистра» в нашем кейсе чрезмерно уверенная: показан лишь комментарий, а текст запроса отсутствует. Корректнее написать: «Функция ПолучитьЛимит вызывается из ПроверитьЗаказ; источник лимита не подтверждён, потому что тело функции не предоставлено».

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

От карты к проверке в базе

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

Для рассмотренного случая разумный следующий шаг выглядит так:

1. Запросить полные тексты функций расчёта лимита и долга.

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

3. Зафиксировать версию конфигурации и платформы, а также права пользователя.

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

5. Воспроизвести сценарий на копии или в тестовой базе под сопоставимыми правами и записать входные значения, путь выполнения и результат.

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

Итоги

Незнакомую конфигурацию 1С не нужно пытаться понять целиком с первого запроса. Более надёжный маршрут выглядит так: действие пользователя → доступные артефакты → карта подтверждённых связей → список пробелов → проверка в базе.

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

Если после анализа в карте осталось «неизвестно», это не провал. Это точный перечень того, что следует запросить до того, как обсуждать причину и исправление.