Расхождение остатков 1С и WMS: как устроить сверку, которой можно верить
Иван Недомолков · Chop etilgan:
Если автоматическая сверка каждый день находит расхождение остатков 1С и WMS, а кладовщик приходит в зону и видит товар на месте, начинать надо с проверки самой сверки. Чаще всего две системы расходятся по определению величины: учётная сторона и складская считают разные вещи в разные моменты, а порог срабатывания стоит в нуле и превращает эту разницу в документы. Обмен при этом может работать безупречно.
Ниже шесть требований, которым должна отвечать сверка учётной и складской системы, и порядок проверки по шагам. Каждое требование показано на одном разборе у крупной розничной сети: робот сверки восемь месяцев переносил найденную разницу на технический склад проверки, и за это время ни одна из найденных им “потерь” не подтвердилась.
Шесть требований к сверке остатков
| Требование | Как проверить | Что нашлось в разборе |
|---|---|---|
| Один момент среза с двух сторон | выписать, на какое время берётся каждая цифра | складская сторона бралась в момент запуска, учётная на конец дня |
| Одна и та же величина с двух сторон | выписать обе формулы рядом | слева зоны, короба и три окна исключений, справа остаток минус хвост ордеров |
| Лаг отгрузки и непроведённые ордера учтены по замеру | померить лаг на нескольких случаях руками | лаг 0-13 секунд, поправка на 3 часа стояла на этом канале |
| Порог выше шума методики | построить распределение модуля разницы за месяц | порог 0, дрейф на быстрой позиции 0,46% |
| Комментарий документа собран из чисел | найти строку комментария в коде | строка была константой и писалась на каждый документ |
| Нет круговорота туда и обратно | посчитать долю движений склада, созданную роботом | 62,7% оборота за 60 дней, 2 081 артикул из 2 102 ездил в обе стороны |
Первые три требования про то, что сравнивается. Три последних про то, что сверка делает с результатом сравнения. Ломается обычно всё сразу, потому что каждое окно и каждую поправку ставили под отдельную жалобу склада.
Шаг 1. Достаньте снимок входных значений
Прежде чем спорить о причинах, нужны два числа, которые робот сравнил в момент запуска. В разобранной базе они лежали в журнале регистрации, в событии “Синхронизация остатков”: учётная сторона 438, складская 436, разница 2, перенесено 2.
Документ перемещения с комментарием для этого не годится, он появился позже и пересказывает. Сегодняшний отчёт по остаткам на ту же минуту тоже: срез регистра по всем складам на момент запуска дал 442 (165 + 3 + 10 + 110 + 154), а робот в ту же секунду записал 438. Разрыв 4 единицы больше самой найденной разницы, и документами он не объясняется: все 64 регистратора за период после среза не тронуты.
Так бывает в базе, где за один вечер прошло 670 допроведений документов прошлыми датами, правка наборов записей при перепроведении не журналируется, а регистр остатков складской системы пишется в журнал не полностью (ячейка на 24 штуки исчезла без единого события, replay журнала против живого состояния дал 240 против 214). Ретроспектива в такой базе не отвечает на вопрос “сколько было в 14:07”. Отвечает только снимок прибора.
Если робот свои входные значения не пишет, это первая доработка, раньше порога и формул. Вытащить историю запусков регламентного задания с параметрами помогает обработка журнала регистрации для нейросети: события сворачиваются в строки, и у каждого прогона видны оба числа.
Шаг 2. Выпишите обе формулы рядом
Требования про момент среза и одинаковую величину проверяются одним листом бумаги. В разборе формулы выглядели так.
ОстатокWMS = россыпь(зона_1) + россыпь(зона_2) + содержимое_коробов
- позиции из списка исключений
ОстатокERP = остаток регистра на конец дня
- непроведённые расходные ордера младше 3 часовСписок исключений на складской стороне снимал позицию целиком, если по ней:
- была отгрузка за последние 60 минут по закрытому заказу или 12 часов по открытому;
- была приёмка младше 12 часов;
- была корректировка младше 60 минут.
Каждое окно когда-то закрывало конкретную ложную тревогу. В сумме они дали величину, которая мало похожа на остаток. Слева физический срез в момент запуска с вычетами по активности, справа учёт на конец дня с вычетом трёхчасового хвоста. Разность этих двух чисел плавает от того, в какую минуту робот проснулся.
У окон разной длины есть побочный эффект, который бьёт по складу. Позиция попадает в документ в первый тихий момент после волны активности, когда все окна закрылись. От события до документа может пройти полсуток, и склад, который добросовестно разбирает “что было в 14:20”, ничего не находит.
Что должно получиться после шага: обе стороны на один момент и одним набором вычетов. Если вычет нужен с одной стороны, он нужен и с другой.
Шаг 3. Померьте лаг, прежде чем его компенсировать
Поправки на непроведённые ордера и окна по отгрузкам нужны, только если канал реально запаздывает. Проверяется это руками на нескольких случаях: время физической отгрузки в WMS против времени появления расходного ордера в 1С.
В разборе пять замеров подряд дали 0, 0, 9, 13 и 1 секунду. Цикл “отбор - отгрузка - расходный ордер” оказался атомарным, а поправка на 3 часа стояла ровно на нём. Настоящий сдвиг нашёлся в другом канале: продажа через маркетплейсы проводится в учётной системе на сутки раньше, чем товар уезжает со склада. Это видно по нетто за пять дней подряд.
| День | Учётная система | Складская система |
|---|---|---|
| 1 | -31 | -31 |
| 2 | +50 | +59 |
| 3 | -13 | -25 |
| 4 | +60 | +60 |
| 5 | -10 | -10 |
| Сумма | +56 | +53 |
Три дня совпадают точно, второй и третий расходятся, за пять дней набегает 3 единицы. Поправку, у которой никто не помнит происхождения, стоит проверять именно так: померить канал, который она якобы чинит, и поискать канал с реальным сдвигом.
Если лаг выходит минутами и часами, проблема уже в самом обмене. Тогда смотрят, встаёт ли изменение в очередь узла, по разбору регистрации изменений в плане обмена.
Шаг 4. Поставьте порог выше шума
Разница между двумя такими величинами колеблется сама по себе, без всякой недостачи. На быстрой позиции в разборе это было 2 единицы при остатке 438, то есть 0,46%. По второй позиции того же снимка разница 4 (86 против 82) разошлась двумя перемещениями, 1 и 3. Порог у робота стоял нулевой, поэтому любая единица превращалась в документ.
Моя позиция: сверка двух систем в первую очередь меряет собственную методику, и её порог обязан быть выше шума этой методики. Подбирают его так:
- Взять историю сверок за месяц.
- Построить распределение модуля разницы по позициям.
- Найти место, где заканчивается шум и начинается хвост.
Второй вариант обходится без подбора числа: позиция уходит в документ, если разница держится два прогона подряд. Шум между прогонами меняется, реальная недостача остаётся.
Граница честности. Порог “от трёх единиц или два прогона подряд” в разборе на исторических данных не проверили, и сколько настоящих недостач он пропустит, неизвестно. Готовой цифрой для чужой конфигурации его считать рано, это гипотеза под прогон по вашей истории.
Шаг 5. Соберите комментарий документа из переменных
В разборе комментарий “при нулевых остатках в WMS” стоял в коде процедуры, которая формирует перемещение, и писался на каждый документ. Когда-то он описывал одну ветку логики, потом ветка поменялась. Восемь месяцев склад искал ноль, которого не было ни разу: в снимке стояло 436.
Проверка занимает десять минут: найти строку поиском по конфигурации и посмотреть, собирается она из переменных или лежит литералом. Сверку чужого регламентника удобно начинать с анализа кода 1С: он показывает, где считается разница и откуда берётся текст комментария.
Минимальный честный комментарий содержит то, что робот сравнил:
Сверка: учёт 438, склад 436, разница 2, порог 0, запуск ДД.ММ.ГГГГ чч:мм:ссС таким текстом кладовщик видит, что речь о двух штуках при остатке в сотни, и не идёт искать пропажу. Похожая подмена бывает у заданий выгрузки, где статус “Выполнено успешно” принимают за доказательство результата, её разбирали в статье про выгрузку 1С по расписанию, которая не работает.
Шаг 6. Посчитайте круговорот на техническом складе
Последнее требование проверяется по движениям самого склада проверки. Цифры разбора за 60 дней:
| Показатель | Значение |
|---|---|
| Строк движений | 9 372 |
| Документов-регистраторов | 2 061 |
| Артикулов | 2 102 |
| Приход | 15 879 |
| Расход | 15 490 |
| Нетто | +389 |
| Оборот | 31 369 |
| Создано напрямую роботом сверки | 19 660 (62,7%) |
2 081 артикул из 2 102 имел по складу проверки и приход, и расход. Робот сверки увозил позицию на проверку, второй робот, пополнение канала, тянул её обратно, и на горячих днях взаимных перекидок набирались десятки. Нетто +389 при обороте 31 369 даёт примерно одно полезное движение на 80.
Как считать у себя: разнести оборот технического склада по видам и авторам регистраторов и отдельно отметить артикулы, у которых за период есть обе стороны. Если доля робота подходит к половине оборота, сверка кормит сама себя.
В разборе осталась неразобранной категория “перемещения с другим комментарием”: 942 документа с нетто +1 584. Это почти треть оборота склада проверки, и что внутри, неизвестно. Такой остаток после разбора лучше записать явно, чем растворить в общем выводе.
Отдельно: список складов собирайте внутри расчёта
Одна находка разбора к шести требованиям не относится, но ломает сверку тихо. Процедура создания перемещений добавляла технический склад проверки в тот же массив складов, по которому считалась учётная сторона. При повторном вызове на том же объекте робот сравнивал бы остаток вместе с результатом собственного прошлого прогона.
Не сработало это только потому, что объект создавался заново на каждый запуск. Любой рефакторинг с кэшированием объекта этот дефект включит. Проверка механическая: найти в расчёте все места, где в коллекцию параметров что-то добавляется, и посмотреть, пришла коллекция снаружи или собрана локально.
В каком порядке править
Порядок диктует цена правки. Комментарий из чисел стоит около получаса и первым снимает споры со складом. Запись снимка в журнал нужна до всего остального, без неё через неделю расследовать нечего. Выравнивание формул и порог идут последними, потому что требуют истории сверок хотя бы за месяц и замера лага по каждому каналу.
Если у вас сверка между 1С и складской системой выросла из заплаток под жалобы и её никто не решается трогать, разберём обмен вместе с вами: от снимка входных значений до порога, посчитанного по вашей истории.
С каким порогом стоит сверка у вас, и мерил ли кто-нибудь распределение разницы за месяц до того, как этот порог поставить?
