Самый неприятный отказ агента в 1С выглядит так. Запрос отработал, ошибок в журнале нет, агент вернул аккуратный ответ. В ответе одиннадцать позиций номенклатуры. В базе их девятнадцать: восемь агент не увидел, потому что у служебной учетки настроено ограничение доступа на уровне записей. Он принял решение по обрезанным данным и ни разу не соврал.
Эта статья про саму конфигурацию: про базу, которую дорабатывали десять лет, и про девять мест, где она ломает интеграцию. Выбор процесса и выбор модели здесь вынесены за скобки — разбор процесса закупки со стороны бизнеса лежит в отдельном материале. Здесь речь про платформу, и написано это для того, кто будет отвечать за базу после внедрения.
Хорошая новость в том, что список конечен. Конфигурации, которые пилят под себя годами, ломаются в одних и тех же местах, и все девять проверяются заранее, за один разговор с администратором.
Почему база с историей — это отдельный класс задачи
Типовая конфигурация предсказуема. Вы знаете имена объектов, знаете, что проведение работает штатно, знаете, где лежат справочники. База, которую дорабатывали десять лет, отличается от типовой сотней мелких переделок, и каждая была разумной в свой год.
Реквизит добавили в 2014-м под акцию, акция кончилась, реквизит остался и теперь используется под другое. Модуль проведения дописали в 2016-м, когда менялся учет, и автор уволился в 2019-м. Регистр сведений завели, чтобы не трогать справочник, и в нем теперь живет половина коммерческой политики. Документации нет ни на что.
Готового расширения, которое встанет на любую 1С, не существует ни у одного подрядчика. Разница между исполнителями в другом: кто называет список поломок по результатам обследования до начала работ, и кто предъявляет тот же список счетом на середине проекта.
Четыре способа достучаться до 1С
Прежде чем разбирать поломки, надо договориться о канале. Их четыре, и выбор канала определяет половину сроков.
| Канал | Что умеет | Чего не умеет | Когда берем |
|---|---|---|---|
| Стандартный интерфейс OData | Читать, создавать и менять объекты, которые включены в состав интерфейса | Вызвать произвольную процедуру конфигурации; отдать результат сложного запроса с соединениями | По умолчанию. Быстрее всего запускается, не требует кода на встроенном языке |
| HTTP-сервис в расширении | Любую логику: вызвать штатное проведение, собрать сложную выборку, вернуть готовый ответ одним запросом | Появиться без разработки на встроенном языке 1С | Когда нужна нетиповая логика или когда OData отдает данные слишком мелкими кусками |
| Внешняя обработка | Отработать в контексте базы по расписанию или по команде | Отвечать на запросы по требованию с приемлемой задержкой | Пакетные и регламентные операции, разовые выгрузки |
| Прямое чтение базы данных | Формально — быстро прочитать таблицы в обход платформы | Пережить обновление, учесть разделители и кэши, остаться в рамках лицензионного соглашения | Никогда. Разбор ниже |
Про последнюю строку отдельно, потому что предлагают ее регулярно и звучит она соблазнительно. Прямое чтение таблиц СУБД в обход платформы нарушает лицензионное соглашение, ломается при первом же обновлении конфигурации, не видит логику разделителей и кэшей и обходит любые проверки. Если подрядчик предлагает так «для скорости» — это исчерпывающая характеристика подрядчика.
Пятый вариант, COM-соединение, встречается в наследуемых интеграциях. Он работает, но привязан к Windows, хрупок при обновлениях и плохо переносит параллельные обращения. Новые интеграции на нем не строим; существующие трогаем только по необходимости.
Практика: 80% сценария закрывается OData, оставшиеся 20% — HTTP-сервисом в расширении. Кода на встроенном языке 1С при этом требуется мало, но без вашего администратора 1С проект не поедет: публикация, состав интерфейса, права служебной учетки — все это его работа.
Девять мест, где ломается
1. OData опубликован частично, и об этом никто не знает
Для работы через OData нужна платформа 8.3.5 или новее, публикация базы на веб-сервере и — ключевое — настроенный состав интерфейса. Объекты попадают наружу поштучно, через явное включение в состав. Никто не включает их «на всякий случай».
На живой базе состав почти всегда настроен под давнюю интеграцию: что-то выгружали в отчетность, что-то в старый обмен. Половина объектов, нужных агенту, наружу не отдана. Правится администратором за час, но узнать об этом надо до оценки сроков. Всплывшее на третьей неделе — это сорванный срок.
2. Реквизит называется «Свойство12»
Агенту нужен смысл поля. Метаданные хранят имена и типы, смысла в них нет. На базе с историей вы получаете смесь: часть реквизитов названа по-человечески, часть — по номеру, часть названа осмысленно, но используется под другое с позапрошлого года.
Лечится словарем полей: таблица «техническое имя — что это на самом деле — какие значения допустимы — кто подтвердил». Составляется руками, вместе с вашим сотрудником, который в базе живет. Это скучная работа на несколько дней, и попытка ее пропустить дает агента, который уверенно заполняет не тот реквизит.
Побочная польза: словарь остается у клиента и переживает наш проект. За десять лет это часто первый документ, где написано, что означают поля.
3. Модули проведения переписаны
Здесь самое опасное место, и правило простое: агент проводит документы тем же путем, которым их проводит человек. Никаких прямых записей в регистры в обход проведения, даже если так быстрее и проще.
Причина: в переписанном модуле проведения живут проверки, которые дописывали годами. Контроль остатков, запрет отгрузки должникам, проверка на дубли, письмо руководителю при превышении суммы. Документ, записанный мимо этого модуля, формально корректен и фактически прошел мимо всего контроля предприятия.
Практическое следствие для первого контура: агент готовит документ и оставляет его непроведенным, проведение выполняет человек. Это дешевле и снимает весь класс рисков разом. Развернуто про границу чтения и записи — в разборе прав агента на запись в 1С.
4. Бизнес-правила живут в самописных регистрах
Классика конфигурации с историей: чтобы не трогать типовой справочник, завели регистр сведений и сложили туда то, что не помещалось. Через несколько лет там лежат лимиты по контрагентам, скидочная матрица, признаки временной блокировки поставщика, персональные условия отсрочки.
Агент, который об этих регистрах не знает, строит документ, корректный по типовой логике и невозможный по факту: превышает лимит, применяет базовую цену к контрагенту с индивидуальной, заказывает у поставщика, заблокированного две недели назад.
Найти их можно только обследованием. В метаданных они выглядят как обычные регистры, а то, что в них лежит половина коммерческой политики, знают два человека в компании.
5. Ограничение доступа на уровне записей отдает неполные данные молча
Тот самый отказ из первого абзаца. Служебной учетке дали роль, роль ограничена по складам или по подразделениям, и выборка приходит урезанной. Ни ошибки, ни предупреждения: механизм работает штатно, он ровно для этого и сделан.
Опаснее этого только сочетание с моделью, которая склонна объяснять любые данные. Одиннадцать позиций вместо девятнадцати выглядят как нормальный результат, и агент строит по ним связный вывод.
Лечение состоит из трех частей: права служебной учетки согласуются письменно и по списку объектов; при старте агент делает контрольную выборку с известным ответом и сверяет количество строк; расхождение останавливает работу с явным сообщением. Проверка занимает один запрос и экономит недели разбирательств.
6. Регламентные задания и блокировки
База живет своей жизнью. Ночью идут регламентные задания, в начале месяца — закрытие периода, в это же окно приезжает обмен с внешними системами. Агент, который полез в базу в момент перепроведения документов, встает в очередь на управляемых блокировках и получает таймаут.
Это не ошибка агента и не ошибка базы, это несогласованное расписание. Окно работы согласуется с администратором на этапе обследования, и в конфигурацию агента прописывается поведение при блокировке: подождать, повторить ограниченное число раз, остановиться с внятным сообщением.
7. Распределенная база и узлы обмена
Если у компании несколько баз с обменом, добавляется вопрос, в какой узел агент пишет. Документ, созданный в периферийном узле, доедет до центра со следующим обменом. Документ, созданный в центре, приедет в периферию тогда же. Между этими двумя моментами данные в разных базах отличаются.
Для агента это означает, что проверка «такой документ уже есть» может дать неверный ответ просто потому, что созданное коллегой в другом узле еще не приехало. Ключ идемпотентности здесь обязателен, и проверять его надо в том узле, где документ создается.
8. Тестового контура нет, а боевую базу трогать нельзя
Обследование и разработка идут на копии. На живой базе с историей копия — это отдельная работа: развернуть, обезличить персональные данные, отключить обмены и рассылки, чтобы тестовый агент не отправил письмо реальному поставщику.
Компании, у которой копия боевой базы разворачивается по кнопке, повезло. В остальных случаях это несколько дней работы администратора, и планировать их надо заранее. Разработка без тестового контура означает, что вы платите за ожидание окна обслуживания.
9. Лицензии и сеансы
Веб-сервисы и HTTP-сервисы клиентских лицензий не требуют, но каждый сеанс лицензируется, и агент, работающий постоянно, занимает сеанс. Однозначного публичного ответа на все схемы лицензирования мы не нашли, поэтому формулировка у нас одна и та же на всех проектах: лицензионную схему подтверждаем с вашим администратором 1С и вашим партнером 1С до старта. Выяснять это после внедрения дороже.
Во что это обходится
Оценка по нашим проектам. Числа — рабочие дни на конкретный пункт, при условии, что администратор клиента доступен и отвечает в тот же день.
| Что делаем | Дней | Кто нужен со стороны клиента |
|---|---|---|
| Ревизия состава интерфейса OData, публикация недостающего | 0,5–1 | администратор 1С |
| Словарь полей по нужным объектам | 2–4 | сотрудник, работающий в базе ежедневно |
| Разбор модулей проведения по затрагиваемым документам | 1–3 | тот, кто дорабатывал базу, либо ваш подрядчик |
| Поиск самописных регистров с бизнес-правилами | 1–3 | руководитель направления плюс администратор |
| Служебная учетка, права по списку, проверка полноты выборки | 0,5–1 | администратор 1С |
| Согласование окна работы с регламентными заданиями | 0,5 | администратор 1С |
| Разбор схемы узлов при распределенной базе | 1–2 | администратор 1С |
| Тестовый контур: копия, обезличивание, отключение обменов | 1–3 | администратор 1С |
| Итого обследование | 8–17 | — |
Это те самые 5–10% сметы, которые в разборе стоимости агента проходят строкой «карта процесса». Разброс вдвое объясняется одним фактором: наличием человека, который помнит, почему в базе сделано так. Если такой человек есть и у него выделено время — берите нижнюю границу. Если единственный носитель знаний уволился — верхнюю, и закладывайте риск сверху.
Что остается у вас после обследования
Обследование заканчивается документами. Устного «мы посмотрели» на выходе не бывает: вы получаете семь вещей, и они ваши независимо от того, продолжите вы с нами работать или нет:
- Карта доступа: какие объекты берутся через OData, что придется делать HTTP-сервисом в расширении, что остается недоступным.
- Словарь полей по затронутым объектам с подтверждением от вашего сотрудника.
- Список бизнес-правил, найденных в самописных регистрах.
- Матрица прав служебной учетки по списку объектов.
- Окно работы агента, согласованное с расписанием регламентных заданий.
- Список ограничений первого контура: что агент делает сам, что готовит на подтверждение, чего не делает вовсе.
- Оценка сроков и вилка стоимости с разбивкой по статьям.
Что из этого следует для архитектуры
Девять пунктов складываются в четыре правила, которые мы применяем на любой базе с историей.
- Работаем поверх конфигурации. Расширение или внешняя обработка, без изменения основной конфигурации и без снятия с поддержки. Ваш 1С-подрядчик остается на своем месте, мы его не заменяем и его работу не трогаем.
- Первый контур — чтение и черновик. Агент читает, считает, готовит документ. Проведение остается за человеком. Это снимает весь класс рисков из третьего пункта и дает возможность неделю смотреть, что агент собирался сделать, ничем не рискуя.
- Каждая операция с побочным эффектом получает ключ идемпотентности. Собранный из смысла операции, проверяемый перед записью. Иначе повтор после таймаута дает второй документ.
- Полноту данных проверяем каждый раз. Контрольная выборка с известным ответом на старте каждой сессии. Расхождение означает остановку.
Отдельно про длину цепочки: чем больше шагов агент делает внутри одной задачи, тем выше шанс, что он упрется в контекст или накопит ошибку. Для 1С это особенно чувствительно, потому что ответы на запросы к учетной системе объемные. Арифметика этого потолка — в разборе сколько шагов держит агент в закрытом контуре.
Что сломается через полгода после сдачи
Про это почти никогда не думают на старте. Ломается оно при этом у всех: база не застывает в момент сдачи агента: выходят обновления, ваш 1С-подрядчик продолжает дорабатывать, кто-то переименовывает реквизит, кто-то меняет состав интерфейса OData под новую задачу.
Агент завязан на форму ответа. Пропал реквизит — агент читает пустоту и трактует ее как отсутствие данных. Изменился тип поля — сравнение молча перестает срабатывать. Объект убрали из состава интерфейса — запрос возвращает ошибку, и хорошо, если обвязка ее не проглотит.
Лечится это контрактными тестами. Небольшой набор проверок, который гоняется по расписанию раз в сутки и отвечает на четыре вопроса:
- Все ли нужные объекты по-прежнему в составе интерфейса OData?
- Все ли поля из словаря на месте и того же типа?
- Дает ли контрольная выборка с известным ответом то же число строк?
- Отвечает ли база в пределах согласованного времени?
Расхождение по любому пункту уходит письмом ответственному, и агент останавливается до разбора. Это дешево в разработке, входит у нас в состав работ и закрывает самый частый сценарий деградации: система, которая полгода работала, тихо начала врать, и заметили это по итогам квартала.
Второй пункт того же регламента: перед каждым обновлением конфигурации контрактные тесты прогоняются на копии. Это тридцать минут работы, которые избавляют от разбирательств в понедельник после обновления в пятницу.
Чек-лист: что проверить до звонка подрядчику
Восемь вопросов своему администратору. Ответы на них меняют оценку проекта сильнее, чем выбор модели, и получить их можно за час.
- Какая версия платформы и опубликована ли база на веб-сервере?
- Настроен ли состав интерфейса OData и какие объекты в него входят?
- Конфигурация на поддержке или снята с нее? Если на поддержке — доработки через расширения или прямым изменением?
- Кто дорабатывал модули проведения и есть ли этот человек в доступе?
- Какие регистры сведений содержат бизнес-правила помимо справочников?
- Используется ли ограничение доступа на уровне записей и для каких ролей?
- Разворачивается ли копия боевой базы и за какой срок?
- Расписание регламентных заданий и обменов: когда база занята?
Подрядчик, который не задал вам эти вопросы до того, как назвал цену, назвал цену не вашего проекта. Подрядчик, который задал их и после этого сузил объем работ, скорее всего понимает, что делает.
Вопросы и ответы
Можно ли поставить ИИ-агента на нетиповую 1С?
Можно, и для нас это типовой входной билет. Разница с типовой базой измеряется днями обследования: от восьми до семнадцати рабочих дней на разбор состава OData, словарь полей, модули проведения, самописные регистры и права. Готового расширения, которое встанет на любую конфигурацию, не существует ни у кого.
Нужен ли 1С-разработчик для внедрения агента?
Кода на встроенном языке 1С требуется мало, но без вашего администратора 1С проект не поедет: публикация базы на веб-сервере, состав интерфейса OData, служебный пользователь с ролью удаленного доступа, расписание регламентных заданий, копия базы под тесты. Заложите его время в план заранее.
Снимут ли базу с поддержки?
При нашем подходе — нет. Работаем расширением или внешней обработкой поверх конфигурации, основную конфигурацию не меняем. Если база уже снята с поддержки по другим причинам, это отдельный разговор о том, как в ней жить дальше, и он ведется с вашим 1С-подрядчиком.
Понадобятся ли дополнительные лицензии 1С?
Веб- и HTTP-сервисы клиентских лицензий не требуют, но каждый сеанс лицензируется. Схему мы подтверждаем с вашим администратором и вашим партнером 1С до старта работ, чтобы вопрос закрылся в пресейле.
Что будет с агентом после обновления конфигурации?
Ничего, если настроены контрактные тесты: ежедневная проверка состава интерфейса, полей, типов и контрольной выборки. При расхождении агент останавливается и уведомляет ответственного. Перед плановым обновлением те же тесты прогоняются на копии базы.
Сколько стоит агент для 1С?
Цену определяет состояние интеграции; название системы роли не играет. Опубликованный OData с полным составом интерфейса и типовые механизмы проведения дают нижнюю границу вилки, конфигурация с десятилетней историей — верхнюю. Разброс на одной и той же задаче доходит до трех раз, поэтому цену мы называем после обследования. Ступени и состав работ — в разборе сметы.
Что дальше
Если у вас база с историей и есть процесс, который хочется отдать агенту, пришлите ответы на восемь вопросов из чек-листа. По ним мы говорим предметно: что доступно через OData, что придется делать расширением, где придется остановиться на черновике вместо проведения и во что это встанет по срокам. Состав работ и ступени — на странице Разработка ИИ-агентов.