Обмен с 1С отработал «успешно», а данные не сходятся

С чего начинать поиск

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

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

Четыре места, где рвётся чаще всего

• Пагинация без возобновления: обмен упал на середине, повторный запуск начал сначала и часть данных не доехала
• Выборка всех полей подряд: работает на тестовой базе и падает по таймауту на боевой
• Мёртвый обработчик: правки вносят в код, который давно не вызывается
• Разные единицы измерения на сторонах: количество совпадает, а суммы — нет

Третий пункт встречается чаще, чем можно ожидать. В одном разборе «очевидный» обработчик оказался мёртвым кодом с 2023 года: правки в него вносили, эффекта не было, причину искали в другом месте.

Как убедиться, что починили

Не по формулировке «обмен отработал без ошибок». Сверяйте числа: количество записей и суммы до и после, на обеих сторонах.

• Совпало количество записей
• Совпали суммы — до копейки, а не «примерно»
• Повторный запуск не изменил ничего: обмен идемпотентен
• Проверено на реальных данных, а не на тестовых

В одной из задач сквозная проверка шла на трёх средах реальными заказами, и критерием приёмки было совпадение сумм в CRM и на сайте до копейки. Это единственная формулировка результата, которую нельзя истолковать двояко.

Что сделать, чтобы не повторилось

• Логировать не только ошибки, но и объёмы: сколько записей обработано за прогон
• Падать заметно: молчаливый пропуск записи хуже явной ошибки
• Делать обмен перезапускаемым — тогда сбой перестаёт быть аварией
• Хранить позицию обработки, чтобы возобновляться с места падения