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

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

Зафиксируйте, кто является источником данных

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

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

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

Проверяйте заказы по идентификаторам

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

Проверьте отдельно создание и дальнейшее обновление. Заказ может успешно появиться в 1С, но перестать получать новые статусы. Бывает и обратная ситуация: ответ получен, однако сайт не сохранил подтверждение и отправляет объект повторно. Для каждого контрольного примера нужна цепочка событий с временем и результатом.

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

Отделите остатки от отображения витрины

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

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

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

Найдите этап, на котором теряются изменения

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

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

Проверьте повторную обработку и восстановление

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

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

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

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

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