Связать n8n с 1С можно через HTTP: платформа 1С публикует стандартный интерфейс OData или собственные HTTP-сервисы, а в n8n к ним обращается узел HTTP Request. Встроенного узла 1С в n8n на момент проверки нет, поэтому рабочая схема строится на универсальных узлах. Чтение данных допустимо автоматизировать сразу, запись в учётную систему идёт только после подтверждения человека и проверок на стороне 1С.
Как устроен обмен
1С отдаёт данные по адресу вида /<публикация>/odata/standard.odata/<ресурс>, n8n запрашивает их узлом HTTP Request, а запись в базу выполняется отдельным шагом после подтверждения.
По материалам сообщества 1С, автоматический стандартный интерфейс OData давно есть в платформе и отдаёт ответы в Atom или JSON. Он публикуется вместе с веб-сервером базы, а состав доступных объектов задаётся отдельно: пока состав объектов остаётся пустым, нужные данные по адресу недоступны, и на первом шаге это легко принять за ошибку n8n. Описание шагов есть, например, в статье на Инфостарт; точный порядок для вашей версии платформы сверьте с документацией 1С.
Альтернатива стандартному интерфейсу — собственный HTTP-сервис, который пишет программист 1С. Он отдаёт готовую структуру вместо сырых таблиц и берёт на себя проверки: допустимость значений, права пользователя, уникальность документа. Для записи этот путь обычно надёжнее, потому что правила остаются внутри 1С, рядом с учётом. О разных способах подключения ИИ к 1С рассказывает статья про подключение нейросети к 1С, а об MCP как отдельной теме — материал MCP для 1С.
Здесь описана именно сторона n8n: какие узлы взять, как сопоставить поля, как защититься от повторов и где поставить человека. Конкретную заявку с сайта в 1С подробно разбирает статья про поля, дубли и контроль при загрузке заявок.
Узлы n8n
В основе схемы лежит узел HTTP Request. Он отправляет запросы GET, POST и PATCH, подставляет заголовки и передаёт учётные данные, которые хранятся в n8n отдельно от сценария. Для обращения к 1С создают отдельного пользователя базы с минимальными ролями: чтение нужных справочников и документов, а запись выдают только тому пользователю, который связан с подтверждёнными операциями.
Встречаются и community-узлы для OData. В каталоге пакетов npm можно найти универсальные узлы для этого протокола, но сделаны они для общего случая, поэтому их поведение на вашей базе нужно тестировать. Установка таких узлов доступна на самостоятельно размещённом n8n только владельцу и администратору, а документация n8n описывает их как непроверенный код из публичного источника. Обновление узла способно сломать работающий сценарий. Разбор выбора узлов вообще есть в статье про выбор и проверку узлов n8n.
Учтите нагрузку и окно работы. Запросы к рабочей базе в часы закрытия периода способны замедлить пользователей, поэтому расписание согласуют с администратором 1С и ставят на спокойное время. Размер страницы ограничивают параметром $top, а большие выгрузки режут на порции. Ответы 1С с ошибкой записывают в журнал вместе с кодом ответа и адресом запроса, но без содержимого документов.
Для первого сценария хватает четырёх узлов: триггер по расписанию или входящему вызову, HTTP Request на чтение из 1С, узел преобразования полей и узел с уведомлением ответственному. Всё остальное добавляйте после того, как цепочка отработает на тестовой базе.
Сопоставление полей
Читать из 1С проще всего с отбором. Параметры протокола вроде $filter, $select, $top и $format=json позволяют забрать только нужные поля и свежие записи. Запрашивать всю таблицу целиком бессмысленно: нагрузка на базу и объём данных в журнале n8n вырастут без пользы. Запрашивайте дату изменения и сохраняйте отметку последнего прочитанного момента, чтобы следующий запуск начинался с неё.
| Поле в 1С | Куда в n8n | На что смотреть |
|---|---|---|
| Идентификатор объекта (ссылка) | Ключ записи для проверки повтора | Стабильный ключ вместо номера документа с возможной перенумерацией |
| Дата изменения | Отметка последнего чтения | Часовой пояс и формат даты в ответе |
| Контрагент | Поле организации в целевой системе | Совпадение по ИНН вместо сверки написания названия |
| Сумма и валюта | Числовое поле с проверкой формата | Разделитель дробной части и пустые значения |
| Статус документа | Условие маршрута | Проведён ли документ и можно ли его менять |
Какое событие в 1С должно запускать ваш первый сценарий?
Опираясь на эту таблицу, опишите соответствие на бумаге до сборки: слева поле 1С, справа поле целевой системы, посередине правило преобразования. Для спорных значений заранее определите поведение: пустой контрагент отправляет запись на ручной разбор, а нераспознанная валюта останавливает обработку. Такая таблица заодно служит документацией для следующего сотрудника, который будет сопровождать сценарий.
Повторы и дубли
Сценарии с расписанием и внешними вызовами рано или поздно выполнятся дважды: n8n перезапустили, 1С ответила с задержкой, оператор нажал запуск вручную. Поэтому каждая обработка обязана быть идемпотентной, то есть повторный запуск для той же записи оставляет всё как было. Для этого записи присваивают ключ из идентификатора объекта 1С и версии данных, а перед действием проверяют по журналу, обрабатывали ли уже такой ключ.
- Храните журнал обработанных ключей в таблице или базе, доступной n8n, и записывайте в него результат каждого шага.
- При записи в 1С передавайте внешний идентификатор операции и проверяйте на стороне 1С, нет ли уже документа с таким идентификатором.
- Для повторов при сетевых сбоях ставьте ограниченное число попыток с паузой; бесконечный цикл способен завалить базу.
- Записи, оставшиеся без разбора, отправляйте в отдельную очередь ручного разбора вместе с причиной.
Защиту от дублей лучше ставить на двух уровнях: в n8n по журналу и в 1С по уникальному признаку документа. Если защита стоит только в сценарии, то любой другой источник записи — ручной ввод, обмен с другой системой — её обойдёт. Приёмы работы со входящими вызовами и повторной доставкой описаны в статье про входящие события n8n и повтор.
Подтверждение записи
Принцип такой: полные данные обрабатывает сценарий, модель при необходимости объясняет и предлагает, а запись в учётную систему делает сервис после подтверждения человека. Если в цепочке есть нейросеть, например для разбора текста письма, её результат считается черновиком. Прямая запись из ответа модели в 1С исключена.
В n8n паузу до решения человека обеспечивает узел Wait, который останавливает выполнение и продолжает его после вызова. Ответственному сотруднику уходит сообщение с картой операции: что будет записано, в какой документ, из какого источника. Он нажимает подтверждение, и сценарий продолжается. Права проверяет сервер: пользователь базы, под которым идёт запись, ограничен нужными ролями, а 1С отклоняет всё лишнее.
Проверка результата завершает цепочку. После записи сценарий читает появившийся объект обратно, сверяет ключевые поля с отправленными и пишет итог в журнал. Расхождение вызывает уведомление, и цепочка останавливается до разбора. Сначала прогоните весь путь на копии базы с тестовыми данными и только потом подключайте рабочую.
Выберите одно событие, например новый заказ покупателя. Настройте только чтение и уведомление без записи, на копии базы. Через неделю сверьте, сколько событий сценарий увидел и сколько действительно произошло в 1С. Когда числа совпадают, добавляйте запись с подтверждением. Для проекта под ключ обсудите автоматизацию бизнес-процессов с нами.