Расхождения между 1С и WMS выглядели одинаково: в одной системе товар есть, в другой нет; количества отличаются; остатки не соответствуют физическому наличию. Но причины могут быть разными: несинхронное проведение документов, различия в логике систем, ошибки ручного ввода: например, вместо 50 штук в одной упаковке фиксировались 50 упаковок по 50 штук. Поэтому задача не сводится к поиску «ошибки интеграции». Каждое расхождение разбиралось по позиции: конкретный случай → причина → признаки причины → поиск всех аналогичных случаев → исправление данных → системное решение. После определения признаков весь массив расхождений прогонялся повторно. Уже классифицированные случаи отделялись от ошибок с неизвестной причиной. Это позволяло одновременно устранять накопленные последствия и сокращать сам источник повторов.

Один из типов расхождений возникал при вычерках.Если физически товара в ячейке не было, кладовщик фиксировал вычерк в WMS. Ячейка блокировалась, и WMS больше не направляла туда сборщика. В 1С этот статус не передавался. Товар продолжал числиться свободным остатком и снова попадал в заказы. Решение: передавать статус проблемной ячейки в 1С через резерв на количество, равное остатку по этой позиции в конкретной ячейке WMS. Свободный остаток уменьшался, повторные вычерки по уже известной проблеме прекращались.

Другой тип ошибки возникал из-за различий в моменте списания товара. В 1С товар уходил из остатка при реализации. В WMS — при передаче со склада хранения на склад выдачи. Физически товар после этого мог остаться на складе. Если заказ отменялся, обратное размещение в WMS проводилось через приёмку или ручное изменение остатка в WMS. В первом случае эта операция передавалась в 1С как новый остаток, и количество удваивалось, во втором – требовало ручного изменения остатка в ячейке при наличии определенных прав и с риском новых ошибок ввода данных. Последствия приемки неотправленного товара приходилось устранять списаниями или удалением автоматически созданных поступлений, что уже затрагивало бухгалтерский учёт. Здесь исправление требовало изменения процесса. После физической сборки заказа его отмену ограничили. Собранный товар проводился через реализацию, а при необходимости возвращался уже документом возврата.

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

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