Сайт, 1С и CRM показывают разные цифры: где искать источник ошибки

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

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

Фраза «1С главная» недостаточна для проектирования обмена. Учётная система может отвечать за номенклатуру и склад, CRM — за ответственного и историю коммуникаций, сайт — за первоначальный состав корзины. Это пример распределения, а не универсальная схема: правила зависят от вашего процесса.

Для каждого поля запишите, где его разрешено изменять и что происходит при конфликте. Если телефон поправили в CRM, должна ли следующая выгрузка старого заказа вернуть прежнее значение? Если цена заказа зафиксирована, должен ли новый прайс её пересчитать? Такие решения нельзя оставлять случайному порядку прихода запросов.

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

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

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

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

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

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