Интеграция 1С и CRM: ошибки и чек-лист приёмки
Как определить владельцев данных, предотвратить дубли и принять обмен 1С с CRM: сценарии сбоев, повторов и сверки документов.
Интеграцию 1С и CRM стоит принимать по выполненным бизнес-сценариям: заказ дошёл до учётной системы, изменения вернулись менеджеру, повторная доставка не создала дубль, а сбой можно обнаружить и исправить. Успешный ответ API доказывает только обработку конкретного запроса. Он ещё не доказывает, что сотрудник видит правильного контрагента, согласованную цену и актуальное состояние заказа.
Сначала опишите движение одного заказа
Возьмите типичный заказ и пройдите его путь вместе с продажами и учётом. Кто создаёт клиента, где подтверждают цену, когда резервируют товар, кто разрешает отгрузку? Отдельно разберите изменения: покупатель заменил позицию, менеджер исправил количество, бухгалтер отменил документ. Каждый переход должен иметь инициатора, данные на входе и наблюдаемый результат. Так появляется схема обмена, которую можно проверить без чтения программного кода.
Не объединяйте заявку и учётный документ без обсуждения. Заявка может содержать свободный текст, неподтверждённую номенклатуру и предполагаемую цену. Для проведения документа нужны другие требования. Сохранение обращения в CRM может быть успешным, даже если заказ в 1С ещё требует уточнения. Интерфейс должен показывать это состояние прямо, иначе менеджер будет считать техническую очередь подтверждённой продажей.
Назначьте владельца каждого поля
Для номенклатуры, контрагентов, цен, остатков и статусов составьте таблицу ответственности. В ней нужны поле, система-владелец, направление передачи и правило конфликта. Например, CRM хранит историю общения, а учётная система подтверждает доступность товара. Это пример распределения, а не обязательная схема: реальное решение зависит от вашего процесса. Важно, чтобы одно поле не переписывалось обеими системами по принципу «последняя запись победила».
Отдельно согласуйте пустое значение. Оно может означать «данных нет», «поле нужно очистить» или «источник его не передаёт». Если обмен не различает эти случаи, очередное обновление способно стереть телефон клиента или адрес доставки. Такие правила удобнее закрепить на примерах до разработки: исходная карточка, входящее сообщение, ожидаемая карточка после обработки.
Идентификаторы важнее похожих названий
Названия компаний и товаров изменяются, поэтому связь объектов должна опираться на устойчивые идентификаторы. Для существующих справочников заранее определите сопоставление. Если обнаружено несколько похожих контрагентов, оператор должен увидеть кандидатов и выбрать связь. Автоматическое слияние спорных записей скрывает решение, которое может влиять на договор, задолженность и адрес получателя. Сама интеграция должна хранить результат выбора, чтобы не спрашивать его повторно.
При работе с товарами проверьте варианты, упаковки и единицы измерения. Десять штук и десять коробок могут выглядеть одинаково в плохо описанном сообщении. Для каждой позиции нужны артикул или идентификатор, единица, коэффициент пересчёта и правило округления. Если поле отсутствует, обмен должен выдать понятную ошибку, а не подобрать значение по сходству названия.
Повторная доставка должна быть безопасной
Сеть и внешние сервисы иногда работают нестабильно. Отправитель может не получить подтверждение после того, как получатель уже сохранил заказ. Поэтому технический сценарий обязан включать повтор того же сообщения. Результат должен остаться одним заказом, а журнал показать, что событие обработано ранее. Для этого определяют идентификатор операции и срок хранения сведений о выполненных операциях. Конкретный механизм выбирает разработчик, бизнес проверяет отсутствие дублей.
Другой случай — события пришли в неправильном порядке. Изменение заказа может обогнать его первоначальное создание. В задании нужно зафиксировать, можно ли временно отложить изменение, как сравнивать версии и что происходит с устаревшим сообщением. Не следует принимать обмен только на последовательном наборе из двух идеально доставленных запросов: такой пример не проверяет восстановление после реального разрыва связи.
Цена и остаток требуют отдельного соглашения
У цены есть контекст: покупатель, договор, валюта, НДС, дата и объём покупки. Передаваемая сумма без этих условий может быть правильной технически и неверной коммерчески. Согласуйте, когда цена фиксируется, кто её подтверждает и как пользователь узнаёт об изменении. Если итог пересчитан при отправке заказа, покупателю нужно показать новое значение и получить подтверждение согласно выбранному процессу.
Для остатков разделите наличие, доступный объём и резерв. Периодическое обновление каталога не гарантирует, что товар останется доступным к моменту подтверждения. Опишите допустимую задержку и поведение при устаревших данных. Для части процессов достаточно заявки менеджеру; для других потребуется повторная проверка перед созданием документа. Обещание «остатки всегда актуальны» без интервала и точки проверки невозможно объективно принять.
Составьте приёмку из проверяемых случаев
Минимальный набор включает нового и существующего клиента, заказ с несколькими единицами измерения, изменение количества, отмену, повтор сообщения, недоступность одной системы и восстановление. Для каждого случая подготовьте исходные данные и ожидаемый результат в обеих системах. Проверяйте не только появление карточки, но и связи, суммы, статусы, время обновления и видимость для нужного сотрудника. Тестовые данные должны исключать случайное совпадение со старой записью.
Добавьте сверку итогов: число переданных объектов, число обработанных операций и список расхождений. Объект, который завис между системами, должен быть виден в отчёте вместе с причиной и ответственным. Если исправление требует ручного действия, опишите его пошагово. Приёмка завершается тогда, когда сотрудник может восстановить сценарий по инструкции, а не только после звонка автору интеграции.
Как оформить задание подрядчику
Передайте конфигурацию и версию 1С, название CRM, перечень объектов, схему владельцев полей, примеры сообщений и приёмочные сценарии. Укажите ограничения публикации интерфейсов, доступные окна обслуживания и контакт ответственного за учёт. Платформа 1С поддерживает различные способы интеграции, включая собственные HTTP-сервисы; выбор способа нужно делать после проверки конфигурации и требований, а не по названию популярного коннектора.
Попросите разделить оценку на обследование, разработку, перенос сопоставлений, приёмку и сопровождение. В результате должны остаться схема обмена, журнал ошибок, инструкция повторной обработки и перечень согласованных ограничений. Такой комплект позволяет сравнить предложения по одному объёму и понять, какая часть ответственности останется внутри компании. Следующий шаг — собрать один сквозной сценарий и документы для него: это гораздо полезнее общего требования «синхронизировать всё».