Сверка заказов, оплат и отгрузок между системами: как находить расхождения
Содержание 9 разделов
Заказ может появиться на сайте, перейти в CRM, получить оплату через банк или платёжный сервис и завершиться отгрузкой в 1С либо WMS. Каждая система показывает свой фрагмент процесса. Поэтому одинаковые на первый взгляд отчёты часто дают разные итоги: в CRM заказ уже оплачен, в банке деньги поступили, а складской документ всё ещё ожидает проведения.
Сверка собирает эти события в одну проверяемую цепочку. Её задача — вовремя показать пропущенную оплату, лишнюю отгрузку, задвоенный заказ, частичный возврат или зависший статус и передать конкретное расхождение ответственному сотруднику. Такой контур полезен интернет-магазинам, оптовым компаниям, дистрибьюторам и любому бизнесу, где заказ проходит через несколько информационных систем.
Почему данные расходятся даже при работающей интеграции
Обмен данными и сверка решают разные задачи. Интеграция передаёт событие из одной системы в другую. Сверка подтверждает, что событие дошло, было обработано один раз и сохранило правильную сумму, состав и статус. Сетевой сбой, ограничение API, повторная доставка вебхука или ручное изменение документа способны нарушить цепочку, хотя сама интеграция продолжит отвечать на запросы.
Часто расхождение связано со временем. Клиент оплатил заказ вечером, банк показал операцию ночью, а 1С загрузила выписку утром следующего дня. Сравнение только по календарной дате создаст ложную ошибку. Похожая ситуация возникает с часовыми поясами, резервированием товара, частичной отгрузкой и возвратом после закрытия отчётного периода.
- заказ изменился после оплаты: клиент убрал позицию или получил скидку;
- платёж поступил несколькими частями либо объединил несколько заказов;
- склад отгрузил часть товара и создал несколько документов реализации;
- вебхук был доставлен повторно, а принимающая система создала дубль;
- оператор исправил статус вручную только в одной системе;
- возврат прошёл в банке, но ещё не отражён в CRM и учёте.
Сначала назначьте источник истины для каждого факта
Единая система редко владеет всеми достоверными данными. Перед разработкой составляют таблицу полей и назначают владельца каждого факта. Это снимает главный спор при разборе: какое значение считать правильным и куда отправлять исправление.
Заказ и его состав
Источником заказа обычно служит сайт, маркетплейс или CRM. Здесь важны внешний номер, клиент, позиции, количество, цена, скидка, валюта и момент подтверждения. Если заказ можно редактировать, контур должен хранить версии либо события изменений, иначе поздняя корректировка затрёт исходное состояние.
Факт оплаты
Финальный статус платежа подтверждает банк, эквайер или платёжный провайдер. Статусы вроде «создан» и «ожидает подтверждения» ещё не означают поступление денег. Например, документация ЮKassa разделяет промежуточные и финальные состояния платежа и рекомендует проверять актуальный статус объекта при обработке уведомлений. В модели сверки отдельно хранят сумму заказа, сумму списания, комиссию, сумму зачисления и возвраты.
Факт отгрузки
Отгрузку подтверждает 1С, ERP или WMS после проведения соответствующего документа. Полезно хранить номер документа, склад, фактический состав, партии, дату и статус отмены. Один заказ может породить несколько отгрузок, поэтому связь «один к одному» подходит лишь для простых процессов.
Возвраты и отмены
Возврат образует самостоятельное событие и связывается с исходным платежом, заказом и возвращёнными позициями. Отмена заказа без денежного возврата и возврат без приёмки товара имеют разный смысл. Это отражают отдельными состояниями, а не одним общим признаком «закрыт».
Сквозной идентификатор делает сопоставление надёжным
Лучший ключ сверки — неизменяемый технический идентификатор заказа, который передаётся во все системы. Человек может видеть привычный номер, а интеграция использует UUID или другую уникальную строку. Ключ записывают в CRM, платёжные метаданные, документы 1С и WMS. Дополнительно сохраняют идентификаторы платежа, отгрузки и возврата.
Почему суммы и телефоны подходят только как подсказка
Сумма, дата и контакт клиента помогают найти кандидата, но не дают однозначного совпадения. За день могут появиться два заказа на одинаковую сумму, телефон может измениться, а банк зачислит несколько платежей одной строкой. Эвристическое совпадение полезно помещать в отдельную очередь с оценкой уверенности, оставляя автоматическое подтверждение только для однозначных правил.
Таблица соответствий для старых систем
Если одна система не умеет хранить внешний ключ, создают таблицу соответствий: внутренний ID, внешний ID, источник, время создания и версия записи. Таблица должна иметь уникальные ограничения, чтобы повторная доставка события возвращала уже созданную связь. Такой подход также помогает при миграции, когда старые и новые номера некоторое время существуют одновременно.
Как устроить автоматический контур сверки
Получение событий и контрольная загрузка
Оперативные изменения удобно принимать через вебхуки или очередь сообщений. При этом ежедневная контрольная загрузка через API остаётся полезной: она находит события, потерянные из-за временного сбоя. Платформа 1С предоставляет REST, HTTP- и web-сервисы для обмена с внешними системами. Конкретный механизм выбирают с учётом конфигурации, объёма и допустимой нагрузки.
Каждый запуск фиксирует период, источник, количество прочитанных записей, последний курсор или отметку времени и результат. Для постраничного API нужно обработать все страницы. Например, метод выписки T‑Bank возвращает курсор продолжения, если операций больше выбранного лимита. Пропуск курсора превращает технически успешный запрос в неполную загрузку.
Нормализация статусов и сумм
В промежуточном слое внешние статусы переводят в согласованную модель: создан, подтверждён, оплачен, частично оплачен, отгружен, частично отгружен, отменён, возвращён. Исходное значение сохраняют рядом, чтобы можно было проверить преобразование. Суммы хранят вместе с валютой и типом: товарная стоимость, доставка, скидка, комиссия, зачисление и возврат.
Правила и очередь исключений
Движок сверки применяет понятные правила. Полностью оплаченный заказ должен иметь сумму успешных платежей за вычетом возвратов, равную ожидаемой сумме. Отгрузка не должна превышать подтверждённое количество. Финальный возврат связывается с исходной операцией. Каждому нарушению присваивают код, приоритет, владельца и ссылку на исходные документы.
Какие расхождения стоит выделять отдельно
- Платёж без заказа. Деньги есть, связанный заказ отсутствует либо ключ передан с ошибкой.
- Заказ без подтверждённой оплаты. CRM показывает оплату, а платёжная система — промежуточный или отменённый статус.
- Отгрузка сверх заказа. Количество или сумма документов склада превышают подтверждённый состав.
- Оплачено, но не отгружено. Допустимое время комплектации истекло, движения на складе нет.
- Двойная обработка. Один внешний идентификатор породил несколько платежей или документов.
- Возврат без отражения в учёте. Провайдер завершил возврат, а заказ и финансовый отчёт остались без изменения.
- Неизвестный статус. Источник добавил новое значение, для которого ещё нет правила преобразования.
У каждого правила нужен допустимый временной интервал. Заказ, оплаченный пять минут назад, может законно ждать обработки. Тот же статус через двое суток уже требует внимания. Порог задают по реальному регламенту компании и измеряют после запуска.
Устойчивость важнее красивого отчёта
Принимающая сторона должна безопасно переживать повторы. Для каждого события сохраняют уникальный ключ, а повтор с тем же ключом подтверждают без создания второго документа. ЮKassa отдельно описывает повтор запросов с тем же ключом идемпотентности при неопределённом результате и повторную доставку уведомлений, пока получатель не вернёт успешный HTTP-ответ.
Ошибочные события помещают в очередь повторов с причиной, числом попыток и временем следующего запуска. После нескольких неудач запись попадает в ручной разбор. Мониторинг показывает свежесть каждого источника, длину очереди, долю совпавших записей и самые частые причины расхождений. Нулевая строка в отчёте при остановившейся загрузке опасна: интерфейс должен явно показывать устаревшие данные.
Как принять работу и проверить результат
Приёмка начинается с контрольной выборки, а не с общего красивого итога. Берут обычный заказ, частичную оплату, две отгрузки, отмену позиции, полный и частичный возврат, повтор вебхука и задержанную загрузку. Для каждого сценария заранее записывают ожидаемые связи и код расхождения.
- Проследите один заказ от источника до всех связанных документов.
- Сверьте итоговые суммы за несколько закрытых дней с исходными системами.
- Повторно загрузите тот же период и убедитесь, что количество записей не выросло.
- Отключите один источник и проверьте предупреждение об устаревании.
- Измените статус задним числом и убедитесь, что контрольная загрузка обновила результат.
- Проверьте права: финансовые данные и контакты видят только согласованные роли.
- Выгрузите реестр исключений и убедитесь, что каждая строка ведёт к исходному документу.
После запуска назначают владельца правил и период пересмотра. Новые статусы API, каналы продаж и способы оплаты меняют модель, поэтому журнал версий и автоматические проверки становятся частью эксплуатации.
Что подготовить перед внедрением
Для первичного разбора достаточно перечня систем, примеров заказов с расхождениями, описания статусов и понимания, кто сейчас разбирает ошибки. Полезны тестовые доступы к API, обезличенные выгрузки и схема текущего обмена. По этим данным можно определить, хватит ли отчёта поверх существующих выгрузок или нужен постоянный интеграционный контур.
Хороший результат выглядит просто: сотрудник открывает реестр и видит только записи, требующие решения, вместе с причиной и исходными документами. Совпавшие операции обрабатываются автоматически, а история позволяет объяснить любой итог без ручного поиска по четырём системам.