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