1. Сначала процесс, затем перечень полей
Фраза «связать CRM с 1С» не определяет границы задачи. Одной компании нужно передавать согласованный заказ в учёт, другой — показывать менеджеру сведения об оплате, третьей — синхронизировать номенклатуру. Если объединить всё в первый запуск, становится сложнее отделить ошибки интеграции от проблем исходных данных.
Для начала выберите сценарий с понятным событием и результатом. Например: менеджер переводит заказ в статус «Согласован», после чего в 1С появляется соответствующий объект, а в CRM сохраняется ссылка или идентификатор результата. Название и тип документа в 1С зависят от конфигурации — их нельзя выбрать только по слову «заказ».
Учебный пример границ первого этапа
Передаём из CRM согласованный заказ и позиции. Из 1С возвращаем идентификатор созданного объекта и согласованный статус обработки. Историю оплат, складские остатки и обмен файлами в этот этап не включаем. Это пример задания, а не описание готового коннектора или выполненного проекта ТриЭС.
Запишите также то, что остаётся ручным. Если менеджер должен подтвердить реквизиты перед передачей, это часть маршрута. Если изменение заказа после отправки запрещено, интерфейс и обмен должны одинаково отражать это правило.
2. У каждой записи — устойчивый идентификатор, у поля — владелец
Сопоставление по названию компании ненадёжно: название меняется, а одинаковые строки могут относиться к разным карточкам. Для обмена нужна явная связь идентификатора источника с идентификатором приёмника. ИНН и другие реквизиты могут помогать при первоначальном поиске, но неоднозначные случаи требуют согласованных правил и разбора.
Отдельно решите, какая система является источником каждого поля. Без этого двусторонний обмен способен перезаписывать корректные изменения: менеджер обновил контакт в CRM, а следующий обмен вернул старое значение из учёта. Необязательно назначать одну систему главной для всех данных.
| Данные | Что согласовать | Что проверить |
|---|---|---|
| Контрагент | Идентификаторы и порядок первоначального сопоставления | Две похожие карточки и изменение реквизитов |
| Позиция заказа | Номенклатура, единица измерения, количество, цена | Неизвестная позиция, округление и пустое значение |
| Статус | Система-источник и допустимые переходы | Отмена, изменение после отправки и запоздавшее событие |
| Сумма | Валюта, точность и правила расчёта | Различия итогов и неполные данные |
Полезно различать «не передано», «пусто» и «удалено». Если пустой телефон в источнике должен очистить поле в приёмнике, это нужно написать явно. Иначе технически успешный обмен может незаметно испортить данные.
3. Интерфейс выбирают после проверки систем
До выбора механизма уточните версии и доработки 1С, возможности API CRM, доступы, ограничения частоты запросов и среду размещения. Наличие платформенной возможности не означает, что нужный интерфейс уже опубликован, разрешён и подходит вашему процессу.
В платформе 1С предусмотрены собственные HTTP-сервисы: разработчик задаёт обработку запроса и формирует ответ. Это позволяет описать прикладной контракт, но его всё равно нужно разработать, опубликовать и проверить. Возможности механизма описаны в официальной документации 1С по HTTP-сервисам.
Готовый модуль обмена имеет смысл оценивать по реальным сценариям: какие версии поддерживаются, какие объекты передаются, как обрабатываются доработки и кто сопровождает обновления. Собственная интеграция даёт возможность описать нужные правила, но добавляет работу по реализации и поддержке. Пакетный обмен может подойти там, где допустима задержка; мгновенная передача не должна становиться требованием по умолчанию.
4. Повтор запроса не должен создавать второй заказ
Представьте, что приёмник сохранил заказ, но ответ не дошёл до отправителя. Отправитель видит тайм-аут и повторяет передачу. Если каждый запрос просто создаёт новый объект, возникает дубль. Поэтому правило повторной обработки нужно согласовать до запуска.
Для операции можно предусмотреть устойчивый ключ события или связь с идентификатором исходного объекта. Повтор того же события должен возвращать ранее полученный результат либо обновлять запись по согласованным правилам. При этом одинаковый ключ с другим содержимым нельзя молча считать прежней операцией. Реализация должна учитывать сбои между сохранением бизнес-объекта и отметкой об обработке.
Как проверить повторную передачу
- Передать тестовый заказ с заранее выбранным идентификатором.
- Повторить ту же операцию, включая сценарий потери ответа.
- Проверить, что лишний объект не появился, а результат можно однозначно связать с источником.
- Передать изменённую версию и проверить отдельное правило изменения.
Повторы подходят не для любой ошибки. Временная недоступность и некорректный справочник требуют разных действий. Для временных ошибок предусматривают задержки и ограничение повторов, для проблем данных — очередь разбора с понятной причиной. Общий принцип идемпотентности при повторных вызовах и задержек между попытками описан в AWS Prescriptive Guidance: Retry with backoff; конкретную политику нужно согласовать для вашего интерфейса.
Журнал должен помогать найти объект, этап и причину сбоя. Для этого обычно достаточно идентификаторов, времени и диагностического сообщения; пароли, ключи и полные персональные данные не должны становиться обычным содержимым журналов. Назначьте человека или роль, которая разбирает ошибки, и порядок эскалации.
5. Приёмка — это набор сценариев, а не один успешный запрос
Согласуйте, что именно подтверждает готовность. Ответ HTTP 200 показывает успешность запроса на уровне выбранного интерфейса, но не доказывает корректность итоговой суммы, связи контрагента или дальнейшего бизнес-процесса.
- Обычный маршрут: создание, изменение и согласованные статусы проходят полностью.
- Проблемные данные: неизвестная номенклатура, пустое обязательное поле и неоднозначный контрагент дают понятный результат.
- Повторы: повторная передача и потерянный ответ не создают лишние объекты.
- Последовательность: запоздавшее событие не откатывает новую версию без согласованного правила.
- Сбой и восстановление: после недоступности системы очередь обрабатывается предсказуемо.
- Права: техническая учётная запись выполняет нужные операции без избыточных полномочий.
Проверки проводят на согласованной тестовой среде и данных. Перед запуском полезно сверить начальные остатки очередей, правила переноса существующих записей и способ остановки обмена при обнаружении ошибки.
6. Что подготовить для оценки интеграции
Передайте названия и версии систем, описание одного приоритетного процесса, перечень объектов и обезличенный пример полей. Добавьте допустимую задержку, примерный объём операций и требования к сопровождению. Этого достаточно для предметного первого разговора; доступы и пароли на этом этапе не нужны.
Следующий шаг — превратить описание в таблицу соответствий и контрольные сценарии. Порядок обсуждения и состав возможных работ описаны на странице интеграции 1С и CRM. Если задача шире одного обмена, начните с раздела решений и автоматизации процессов.
Источники и границы материала
- 1С:Предприятие — HTTP-сервисы: возможности платформенного механизма.
- AWS Prescriptive Guidance — Retry with backoff: общие принципы повторов.
Остальные таблицы и контрольные списки — рекомендации ТриЭС для подготовки задания. Материал не подтверждает совместимость конкретных версий систем и не заменяет обследование конфигурации.