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

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

Сначала ограничьте последствия

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

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

Определите, что именно отсутствует

Под фразой «заказ без контрагента» могут скрываться разные состояния. От этого зависит место диагностики.

  • Поле контрагента в заказе пустое.
  • Заказ связан с техническим покупателем «Розничный клиент».
  • Контрагент создан, но заказ содержит другой или старый ID.
  • Для каждого заказа создается новая карточка одного клиента.
  • Физическое лицо создается как организация или наоборот.
  • Контрагент есть, но адрес, телефон и реквизиты не передались.
  • Связь видна в интеграции, но не записана в учетной системе.

Проследите один заказ от сайта до учета

  1. Выберите тестовый заказ и зафиксируйте его внутренний order_id.
  2. Найдите пользователя, гостевой профиль и контактные данные в базе сайта.
  3. Посмотрите payload, который формирует интеграция.
  4. Найдите запрос поиска или создания контрагента.
  5. Проверьте HTTP-код и тело ответа учетной системы.
  6. Убедитесь, что внешний ID сохранен в таблице соответствий.
  7. Проверьте payload заказа: в нем должна быть ссылка на найденного контрагента.
  8. Сопоставьте результат с документом в 1С или МойСклад.

Полезно использовать correlation_id, общий для всех шагов одного заказа. В логах не следует сохранять пароли, токены и полный набор персональных данных.

Разделите покупателя сайта и контрагента учета

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

  • site_customer_id — постоянный клиент сайта, если он существует.
  • guest_key — контролируемый идентификатор гостевого покупателя.
  • external_counterparty_id — ID карточки в 1С или МойСклад.
  • counterparty_type — физическое лицо, ИП или организация.
  • source — сайт, маркетплейс, менеджер или другой канал.
  • sync_status и updated_at — состояние последней синхронизации.

Проверьте обязательные поля контрагента

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

  • Корректное наименование для физического или юридического лица.
  • Тип контрагента, разрешенный выбранной сущностью API.
  • Телефон и email после нормализации.
  • ИНН, КПП и юридические реквизиты только для подходящего типа.
  • Организация, владелец или группа доступа, если они обязательны.
  • Адреса в формате, который принимает конкретная версия API.
  • Отсутствие пустых строк там, где поле лучше не передавать.

Не ищите клиента только по имени

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

  1. Сначала использовать сохраненный external_counterparty_id.
  2. Для организации искать по проверенному ИНН и, при необходимости, КПП.
  3. Для физического лица использовать подтвержденный контакт по согласованному правилу.
  4. Если найдено несколько кандидатов, не выбирать случайный — отправить случай на разбор.
  5. Если совпадений нет, создать карточку и сохранить возвращенный ID.

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

Нормализуйте контакты до поиска

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

Соблюдайте порядок создания

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

  1. Проверить данные покупателя и определить его тип.
  2. Найти существующее сопоставление external ID.
  3. При необходимости найти контрагента через API.
  4. Если он не найден, создать карточку.
  5. Проверить успешный ответ и сохранить внешний ID.
  6. Сформировать заказ со ссылкой на этот ID.
  7. Создать или обновить заказ идемпотентно.
  8. Сохранить внешний ID заказа и итоговый статус.

Если создание контрагента не удалось, заказ лучше поставить в очередь повторной обработки или явно создать по согласованному fallback-правилу. Молчаливое продолжение делает ошибку незаметной.

Учтите гостевые заказы

Гость не имеет постоянного user_id, но его заказу все равно нужен контрагент. Решение зависит от бизнеса: создавать отдельную карточку для каждого уникального клиента, использовать контролируемого розничного покупателя или связывать по подтвержденному контакту.

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

Разделите физлиц и организации

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

  • Тип клиента сохраняется в заказе сайта.
  • Маппинг создает подходящий тип сущности учета.
  • Реквизиты не записываются в случайные пользовательские поля.
  • Смена типа после оформления проходит отдельную проверку.
  • Печатные документы используют данные связанного контрагента и заказа по согласованному приоритету.

Сделайте обмен идемпотентным

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

  • Один site_customer_id связан не более чем с одним актуальным external ID в заданном контексте.
  • Один order_id обновляет прежний документ, а не создает новый.
  • Повторный ответ API не перезаписывает корректное сопоставление пустым значением.
  • Неопределенный результат после timeout сначала сверяется с учетной системой.
  • Retry ограничен и применяется только к временным ошибкам.

Проверьте права API

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

  • Сервисная учетная запись имеет минимально необходимые права на обе сущности.
  • Контрагент создается в доступной организации или группе.
  • Интеграция использует один согласованный контекст для поиска и создания.
  • Секреты не хранятся в коде, логах и браузерном JavaScript.
  • После ротации ключа проверяется полный сценарий, а не только тест соединения.

Разберите журналы обмена

  • order_id и безопасный correlation_id;
  • этап: validate, find, create counterparty, create order;
  • HTTP-код и технический код ошибки;
  • external ID без полного набора персональных данных;
  • номер попытки и причина retry;
  • итоговый статус и время выполнения.

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

Как исправить уже созданные заказы

  1. Выгрузить список заказов без контрагента за известный период.
  2. Сопоставить их с order_id и покупателями сайта.
  3. Найти или создать контрагентов по исправленному правилу.
  4. Показать неоднозначные совпадения для ручной проверки.
  5. Связать документы через поддерживаемый API или штатный механизм.
  6. Повторно проверить оплаты, отгрузки, скидки и печатные формы.
  7. Сохранить отчет об измененных и пропущенных записях.

Не создавайте контрагентов массово только по имени из заказа. Старые документы могут содержать неполные или уже измененные контакты.

Как проверить исправление

  • Новый заказ зарегистрированного покупателя связан с его существующей карточкой.
  • Гостевой заказ обрабатывается по утвержденному правилу.
  • Юридическое лицо создается с правильным типом и реквизитами.
  • Повторная синхронизация не создает второго контрагента.
  • Timeout и retry не порождают дубли.
  • Неоднозначный поиск останавливается, а не выбирает случайную карточку.
  • Заказ содержит внешний ID контрагента после повторного чтения.
  • Счет, отгрузка, скидки и история клиента используют корректную связь.

Типичные неправильные исправления

  • Подставлять одного технического контрагента для всех заказов без анализа.
  • Искать покупателя только по имени.
  • Создавать нового контрагента при каждом запуске обмена.
  • Продолжать создание заказа после любой ошибки покупателя.
  • Считать успешный HTTP-код доказательством корректной связи.
  • Хранить внешний ID только в памяти текущего процесса.
  • Объединять карточки по одному совпавшему телефону автоматически.
  • Записывать токены и персональные данные в открытый лог.

Профилактика

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

  • Мониторьте число заказов без контрагента.
  • Отдельно считайте созданные и повторно использованные карточки.
  • Сигнализируйте о резком росте дублей покупателей.
  • Версионируйте маппинг полей и изменения API.
  • Регулярно сверяйте связи сайта и учетной системы на тестовой выборке.

Итог

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

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