Автоматизация документооборота в 1С: что делать внутри 1С, а что через интеграции

Спор о том, делать процесс внутри 1С или отдельным сервисом, часто начинается слишком рано. Сначала нужно описать сам маршрут.

Для каждого объекта полезно определить четыре вещи:

• где документ появляется;
• какая система хранит его основное состояние;
• где принимается решение;
• какие системы должны получить результат.

Например, счёт поставщика может прийти по ЭДО, связаться с учётным документом в 1С, пройти проверку реквизитов и только после подтверждения ответственного участвовать в следующей учётной операции. Здесь нет необходимости выводить базовую логику из 1С.

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

Поэтому сначала составляют карту владения данными.

Такая схема снижает риск ситуации, когда один и тот же статус независимо меняется в нескольких системах.

Внутри 1С стоит оставлять операции, тесно связанные с прикладной моделью конкретной конфигурации.

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

Если используется 1С-ЭДО, обмен юридически значимыми электронными документами с контрагентами уже встроен в поддерживаемые программы 1С. Сервис предназначен для работы со счетами-фактурами, УПД, накладными, актами и другими электронными документами непосредственно из 1С. Поэтому добавлять отдельный интеграционный слой только ради передачи этих документов в сторонний интерфейс часто нет смысла.

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

Например:

документ создан в 1С → обязательные поля проверены → определён маршрут → поставлена задача сотруднику → решение зафиксировано → документ проведён или возвращён на исправление.

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

Интеграция становится оправданной, когда один процесс пересекает несколько самостоятельных систем.

Типичные признаки:

• документы приходят через сайт, почту, CRM, личный кабинет или API;
• участвуют несколько баз 1С;
• часть сотрудников вообще не работает в 1С;
• состояние процесса нужно показывать во внешнем кабинете;
• требуется связать 1С с корпоративным хранилищем, CRM, сервисом подписания или отраслевой системой;
• внешнее событие должно запускать операцию в 1С;
• при недоступности одной системы процесс не должен теряться;
• нужен единый технический журнал обменов.

Платформа 1С поддерживает HTTP- и web-сервисы, а также доступ внешних приложений через OData. Это позволяет выдавать наружу ограниченные прикладные операции вместо прямого доступа внешней системы ко всей информационной базе.

Например, интеграции может быть разрешено выполнить команды:

• получить состояние документа;
• проверить наличие контрагента;
• создать черновик объекта;
• передать утверждённые реквизиты;
• получить номер записанного документа.

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

Практическое дерево выбора можно свести к нескольким вопросам.

Отдельный случай — связка с «1С:Документооборотом». Для него существуют механизмы интеграции, при которых из интегрируемой системы можно создавать связанные документы, запускать работу с объектами документооборота и возвращать состояние процесса. Это позволяет не переносить всю предметную логику одной конфигурации в другую.

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

Схема может выглядеть так:

входящий документ → получение файла и метаданных → сохранение исходника → определение типа документа → извлечение реквизитов → проверки формата и обязательных полей → поиск объектов в 1С → применение бизнес-правил → создание черновика → ручная проверка спорных значений → подтверждённая запись в 1С → передача статуса во внешнюю систему → журнал результата.

Здесь интеграция, OCR, AI и сама 1С выполняют разные функции.

Интеграция отвечает за передачу данных и состояние операции.

OCR нужен только для получения текста из изображения или скана.

Шаблонный парсер подходит, если структура документа стабильна.

AI может использоваться, если документ приходит в разных формах и нужные сведения определяются по смыслу. Но результат модели сначала должен пройти обычные проверки.

1С остаётся владельцем тех объектов, которые относятся к учёту и внутренней предметной логике.

Подход к построению сквозного контура между внешними каналами, CRM и 1С отдельно разобран в статье «Система обработки заявок: как связать сайт, почту, CRM и 1С».

Рассмотрим условный пример.

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

Необязательно переносить весь этот процесс в одну систему.

Первый контур можно построить так:

• Внешний канал передаёт файл и идентификатор обращения.
• Интеграционный сервис сохраняет исходник и регистрирует операцию.
• Реквизиты контрагента проверяются по 1С.
• Если найдено точное соответствие, оно связывается с карточкой.
• Документ отправляется по утверждённому маршруту.
• Система собирает результаты согласования.
• Ответственный подтверждает договорное решение.
• В 1С записываются только утверждённые данные.
• Во внешний канал возвращается финальный статус.

Если контрагент не найден однозначно, система не создаёт новую карточку автоматически. Она показывает кандидатов сотруднику.

Если изменились существенные условия договора, автоматизация не должна самостоятельно считать документ согласованным только потому, что предыдущая версия уже прошла маршрут.

Сам документооборот обычно не требует генеративного AI.

Без модели надёжно решаются:

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

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

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

На сайте engineer. опубликован кейс AI-системы для B2B-поставщика, где заявки и документы связываются с данными 1С, склада и CRM, а менеджер проверяет результат перед дальнейшим действием.

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

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

Третья ошибка — прямая двусторонняя синхронизация одинаковых реквизитов. Если статус можно изменить и в 1С, и в CRM, нужно заранее определить приоритет источников и правила конфликта.

Четвёртая — считать успешный HTTP-ответ завершением бизнес-процесса. Техническая доставка команды и фактическое проведение документа — разные состояния.

Пятая — отсутствие идемпотентности. Повторная доставка одного события после тайм-аута не должна создавать второй документ.

Шестая — автоматическое выполнение необратимых действий без ручного контроля.

Интерфейс ручной проверки должен отвечать не только на вопрос «подтвердить или отклонить».

Сотруднику нужны:

• исходный документ;
• извлечённые реквизиты;
• найденный объект 1С;
• источник каждого значения;
• сработавшие проверки;
• причина передачи на ручной контроль;
• предыдущая версия документа;
• действие, которое произойдёт после подтверждения.

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

Не нужно начинать с полного документооборота компании.

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

До разработки собирают:

• примеры обычных и проблемных документов;
• список обязательных реквизитов;
• роли участников;
• текущий маршрут;
• правила исключений;
• объекты 1С, которые должны создаваться или изменяться;
• внешние системы;
• правила подтверждения;
• требования к журналу действий;
• поведение при недоступности интеграции.

Подход к выбору первого процесса подробнее описан в материале «Автоматизация бизнес-процессов: что стоит автоматизировать первым».

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

Стоимость определяется не тем, работает решение «внутри 1С» или «через API», а сложностью всего маршрута.

На оценку влияют:

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

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