Автоматизация согласований между CRM и 1С: документы, статусы и ответственность систем

Связать CRM и 1С технически можно разными способами, но согласование документов остаётся сложным не из-за транспорта. Основная проблема возникает, когда обе системы считают себя вправе менять сумму, статус или состав документа. Менеджер видит «согласовано» в CRM, бухгалтер получает другую версию в 1С, а повторная отправка создаёт второй объект. Формально обмен работает, но участники больше не знают, какому состоянию доверять.

Поэтому автоматизацию согласования счёта, договора или заказа нужно проектировать как общий процесс с распределённой ответственностью. Сначала определяют владельца каждого поля и статуса, затем — события и API-контракт. Отдельно описывают повторы, ошибки, сверку и ручной разбор. Такой подход дополняет общую архитектуру интеграции CRM, 1С, сайта и телефонии (https://synchroweb.ru/blog/integraciya-crm-1c-sajta-telefonii/), но сосредоточен именно на жизненном цикле согласуемого документа.

Согласование — это переход состояния, а не пересылка файла

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

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

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

Выберите границу ответственности CRM и 1С

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

Для каждого типа документа нужно определить:

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

«Единое окно» для пользователя не требует единственной базы. CRM может показывать номер и статус из 1С, сохраняя ссылку на связанный объект. Главное, чтобы отображаемое значение имело понятное происхождение, а не вычислялось независимо в двух местах.

Матрица владельцев устраняет борьбу за поля

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

Данные Кто создаёт Источник истины Кто может изменить Куда передаётся
———————— ———————————- —————————- ———————————————— ————————————————
Контрагент и реквизиты CRM или 1С по принятому процессу Назначенная мастер-система Ответственная роль после проверки Во вторую систему с устойчивым идентификатором
Состав предложения Менеджер в CRM CRM до согласования Автор либо согласующий по правилам В 1С после контрольной точки
Учётный номер 1С 1С Механизм учётной системы В CRM только для отображения и связи
Проведение и оплата 1С 1С Уполномоченная роль или регламентная операция В CRM как подтверждённое событие

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

Версия документа должна иметь собственную идентичность

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

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

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

API-контракт описывает бизнес-событие целиком

Интеграция не должна состоять из неформального набора запросов «создать что-нибудь в 1С». Для каждой операции задают назначение, схему данных, обязательные поля, правила проверки, успешный ответ, типы ошибок и требования авторизации. OpenAPI позволяет оформить поверхность HTTP API в машиночитаемом виде, но бизнес-семантика всё равно требует явного текста.

Запрос на регистрацию согласованного документа может включать:

— идентификатор события и время его возникновения;
— идентификаторы документа и версии в CRM;
— тип операции: создание, изменение, отмена;
— структурированные реквизиты и строки документа;
— ссылки на клиента, договор и заказ;
— сведения о согласовании и инициаторе;
— ключ идемпотентности;
— версию схемы сообщения.

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

Возможности 1С не заменяют проектирование процесса

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

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

Разумная граница определяется ответственностью: где пользователь принимает решение, где выполняется учётная проверка и где должен оставаться официальный результат. При необходимости CRM и ERP-контур (https://synchroweb.ru/crm-erp/) могут предоставить единый интерфейс, не дублируя правила проведения 1С.

Идемпотентность защищает от повторного создания

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

В HTTP некоторые методы определены как идемпотентные по своей семантике. Однако бизнес-операция через POST не становится безопасной для повтора автоматически. Для неё применяют устойчивый ключ идемпотентности или уникальный идентификатор события. Получатель сохраняет ключ вместе с результатом и при повторе не создаёт новый документ.

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

Повторная попытка допустима не для каждой ошибки

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

Для каждой операции задают:

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

RFC 9457 предлагает общий формат машиночитаемых сведений о проблемах HTTP API. Его можно использовать как основу для стабильных типов ошибок, не подменяя ими бизнес-коды конкретного обмена. Пользователь должен видеть не трассировку программы, а объект, причину и допустимое действие.

Статус обмена не равен статусу документа

Документ может быть согласован, но ещё не зарегистрирован в 1С из-за очереди. Или передача может быть успешной, а проведение отклонено учётными правилами. Если хранить одно поле «статус», эти ситуации станут неразличимы.

Полезно разделять как минимум три оси:

— бизнес-состояние документа: черновик, на согласовании, согласован, отменён;
— учётное состояние: не зарегистрирован, записан, проведён, проведение отменено;
— техническое состояние обмена: ожидает отправки, выполняется, подтверждён, требует повтора, передан в ручной разбор.

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

Сверка обнаруживает тихие расхождения

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

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

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

Ручной разбор — часть архитектуры, а не признак провала

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

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

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

Нельзя превращать ручной разбор в безымянный журнал для разработчиков. Бизнес-ошибки принадлежат роли, принимающей решение; технические — команде сопровождения; проблемы качества справочника — владельцу данных. Такая маршрутизация является частью системной автоматизации бизнеса (https://synchroweb.ru/avtomatizaciya-biznesa/).

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

Безопасность и аудит закладывают в контракт

Интеграционная учётная запись должна получать только необходимые операции и данные. Если CRM требуется создать проект документа и прочитать его состояние, ей не нужен полный административный доступ к 1С. Секреты не передают в теле бизнес-сообщений и не записывают в открытые журналы.

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

Ошибки API не должны раскрывать внутренние пути, запросы к базе и секретные реквизиты. При этом у каждой ошибки нужен идентификатор экземпляра, по которому сопровождение найдёт подробности во внутреннем журнале.

Критерии приёмки для контура согласований

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

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

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

Источники

— 1С:Предприятие: официальный REST-интерфейс платформы (https://v8.1c.ru/platforma/rest-interfeys/)
— 1С:Предприятие: механизм бизнес-процессов (https://v8.1c.ru/platforma/biznes-processy/)
— 1С:Предприятие: объект «План обмена» (https://v8.1c.ru/platforma/plan-obmena/)
— OpenAPI Initiative: актуальная спецификация OpenAPI (https://spec.openapis.org/oas/latest.html)
— IETF RFC 9110: HTTP Semantics, раздел об идемпотентности (https://www.rfc-editor.org/rfc/rfc9110.html)
— IETF RFC 9457: Problem Details for HTTP APIs (https://www.rfc-editor.org/rfc/rfc9457.html)