Допустим, вы хотите, чтобы сотрудник получал в 1С черновик комментария к отчёту. Для этого программа должна собрать нужные показатели, отправить запрос модели через API и проверить ответ. До разработки определите, где будет выполняться эта логика, как хранить ключи и обрабатывать незавершённые запросы.
Статья рассчитана на специалистов, знакомых с разработкой в 1С, HTTP, JSON и серверной авторизацией. Для примеров используем официальную документацию OpenAI. Это схема возможной интеграции; провайдера и условия его использования нужно выбрать отдельно. Готовая интеграция DeltaC в статье не рассматривается.
Начните с одной операции
Возьмите одну задачу — например, комментарий к уже рассчитанным отклонениям продаж. Для неё не нужна вся база. Подготовьте показатели, период, единицы измерения и несколько агрегированных строк.
Пусть код считает суммы, проценты и проверяет их, а модель объясняет значения и предлагает вопросы для разбора. Эти роли проще тестировать по отдельности. Возможную причину падения продаж, предложенную ИИ, всё равно нужно подтвердить другими данными.
Заранее опишите хороший ответ: он использует переданные показатели, не придумывает причины, сообщает о нехватке данных и соблюдает формат. Проверьте это на нескольких учебных примерах, в том числе пустом наборе и противоречивых значениях.
Какие компоненты участвуют
1С выполняет прикладную операцию, учитывает права сотрудника и собирает данные. Платформа поддерживает обращения по HTTP, а при необходимости — собственные HTTP-сервисы. Наличие этих механизмов не означает, что нужный сервис уже реализован в вашей конфигурации.
Промежуточный сервер проверяет, кто прислал запрос и что ему разрешено, ограничивает объём данных и обращается к модели со своим ключом. Здесь же можно организовать очередь, журнал ошибок и повторы. При нескольких базах эти правила проще поддерживать в одном месте.
Провайдер модели обрабатывает подготовленный запрос и возвращает ответ. Права сотрудника 1С к нему автоматически не переходят. Какие сведения доступны этому сотруднику, нужно проверить до отправки и при каждом последующем обращении к данным.
Прямое обращение или промежуточный сервер
В небольшом контролируемом сценарии серверная логика 1С может обращаться к API модели напрямую. Тогда в самой интеграции придётся решить хранение ключа, тайм-ауты, ограничения запросов и обработку ошибок. Не размещайте секрет в форме клиента или в свободно распространяемом файле обработки.
Промежуточный сервер придётся обслуживать, зато через него проще менять провайдера, отзывать доступ отдельной базе и обновлять разрешённые операции. Он особенно полезен, когда такие изменения иначе потребуют обновить много рабочих мест. Для небольшого прототипа отдельный сервер нужен не всегда.
Обратное направление — внешний сервис вызывает прикладной HTTP API 1С. В этом варианте публикация сервиса, аутентификация и сетевой доступ требуют отдельной настройки. Для исходящего запроса из 1С открывать входящий доступ к информационной базе в интернете обычно не требуется.
Как проходит один запрос
Для учебного примера возьмём два месячных итога. 1С уже посчитала выручку: 250 000 ₽ в прошлом периоде и 300 000 ₽ в текущем. Разница — 50 000 ₽, рост — 20%. Руководителю нужен комментарий к этим значениям, поэтому имена клиентов передавать незачем.
- Пользователь выбирает согласованный отчёт и период; 1С проверяет его доступ к данным.
- Серверная логика собирает значения и передаёт идентификатор операции промежуточному серверу по HTTPS.
- Сервер проверяет источник запроса, допустимый набор полей и размер, затем обращается к API модели со своим ключом.
- Модель возвращает черновик; сервер проверяет структуру и сопоставляет упомянутые числа с исходными.
- Пользователь видит результат вместе с показателями и решает, использовать ли его дальше.
Название базы и идентификатор установки помогают различать подключения, но не подтверждают права. Посторонний тоже может указать знакомое название организации. Сервер должен проверять доступ независимо от этих полей.
Где хранить ключи и как ограничить данные
Секрет провайдера храните в серверном хранилище секретов или защищённой конфигурации окружения. Разделяйте тестовые и рабочие ключи, ограничивайте доступ процесса и предусмотрите отзыв. Не выводите ключ в журнал, сообщение об ошибке или HTML. Эти практики описаны в рекомендациях OpenAI для production.
Отдельно определите, какие данные вообще допустимы для отправки. Условия хранения и обработки зависят от провайдера, используемого API и настроек аккаунта. Не обещайте «ничего не сохраняется» только потому, что запрос сделан по HTTPS. Для примера OpenAI проверяйте действующие настройки обработки данных.
Лимит файла 1С и контекстное окно модели — разные величины. Проверяйте размер сериализованного запроса, количество записей и ограничения выбранной модели. Сначала агрегируйте данные по смыслу, а не обрезайте таблицу посередине. Если в запрос поместились только первые товары, модель не должна описывать их как все продажи компании.
Ожидание, ошибки и повторное выполнение
Ответ модели иногда приходится ждать дольше, чем обычного открытия формы. Покажите пользователю, что запрос ещё выполняется, а при сбое — понятное сообщение и возможность повторить. Долгую задачу удобно поставить в очередь и выдать ей номер: тогда к результату можно вернуться позже.
Различайте неверные входные данные, ошибку авторизации, ограничение частоты и временную недоступность. Ответ 401 обычно требует исправить доступ, а не бесконечно повторять запрос. Для 429 или временной серверной ошибки допустимы ограниченные повторы с паузой, если это согласуется с документацией API.
Тайм-аут означает, что ответ не пришёл вовремя. Сам запрос при этом мог продолжить работу. Присвойте операции свой идентификатор и проверьте поведение при повторе, особенно если результат затем записывается в документ 1С.
Проверяйте ответ до записи в 1С
Если API поддерживает структурированный ответ, задайте схему полей. Structured Outputs помогают контролировать форму результата, но не доказывают истинность текста и чисел. Обрабатывайте отказ модели, незавершённый ответ и отсутствие ожидаемого поля.
Не исполняйте полученный текст как код или произвольный запрос к базе. Комментарии и наименования из исходных данных тоже могут содержать инструкции, которым модель не должна следовать. Выводите результат как данные, а ответственные изменения документов подтверждайте отдельным действием пользователя с повторной проверкой прав.
Начните с режима чтения и черновиков. Когда качество и обработка ошибок понятны, расширяйте сценарий по одному действию. Подготовка входной таблицы разобрана отдельно; для выбора способа предоставления инструментов прочитайте сравнение MCP и API. Если нужна интеграция под конкретный процесс, опишите задачу разработки.