Перед включением новой WMS руководитель склада должен знать три вещи: какая система вправе менять данные, где сохранены события после последней выгрузки и кто принимает решение о продолжении. Если хотя бы один ответ неизвестен, новый заказ может потеряться, резерв — освободиться дважды, а уже собранный короб — снова попасть в работу.
Ниже — методика для склада, который меняет операционную систему и продолжает получать заказы. Она помогает подготовить день переключения, остановиться при расхождении и восстановить работу с сохранением новых операций. Допустимую паузу, способ переноса и возможности конкретных систем согласуют до этого дня. Фиксированного срока или переключения без остановки этот план не обещает.
Рабочие файлы: пустой план и учебный пример
Скачать пустой шаблон XLSX · Скачать заполненный учебный пример XLSX
В обоих файлах одинаковые пять листов:
| Лист | Что заполнить | Какой результат получить |
|---|---|---|
| Решение | Область, момент среза, люди, контрольные условия, доказательства | Запись GO, HOLD или RETURN с автором и временем |
| План | Последовательность, плановое и фактическое время, исполнители | Понятный порядок обычного перехода и восстановления |
| Право записи | Кабинет, склад, операция, прежний и новый исполнитель | Однозначная ответственность за каждое изменение |
| События | Новые заказы, отмены, движения, повторы и подтверждения | Каждое событие обработано один раз либо имеет открытый статус |
| Остатки | Исходные количества, применённые изменения, независимый повторный факт | Сверка по владельцу, складу и варианту товара |
На телефоне таблицу можно прокрутить вправо.
Жёлтые поля предназначены для ввода. Шаблон содержит 20 строк журнала: при расширении нужно продолжить формулы и диапазоны расчёта. Таблица фиксирует работу команды; хранение и доставку событий обеспечивает отдельно проверенный процесс. Это методический документ, а не файл для прямого импорта в Skirbo.
1. Назначьте границы и людей
Запишите конкретную область: владельцы товара, физические склады, кабинеты продаж и операции. «Переключаем одного клиента» недостаточно, если его заказы, остатки и начисления обслуживают разные программы.
У каждой задачи нужен названный исполнитель и замена на время его отсутствия. Руководитель переключения принимает GO / HOLD / RETURN. Старший склада подтверждает физический товар и открытые работы. Ответственный за данные сверяет снимок и связи. Специалист по обмену останавливает и включает запись. Менеджер канала проверяет внешние заказы и подтверждения. Ответственный за расчёты устанавливает границу старого и нового периода.
Такой план заранее включает последовательность, ответственных, окно остановки и время восстановления. Эти элементы входят и в официальную методику подготовки миграции AWS. Здесь они адаптированы к складским операциям.
Определите последний момент принятия решения, оставив время на проверенный возврат. Учебное допущение: работа должна возобновиться к 18:40, восстановление занимает 15 минут, повторная проверка — 5. Решение нужно принять не позднее 18:20. Эти числа показывают расчёт; своё окно берут из репетиции и требований бизнеса. Нельзя расходовать весь перерыв на исправления и только после его окончания начинать восстановление.
2. Разделите право записи по операциям
Для каждой строки матрицы укажите систему, которая может выполнить изменение. Пауза в одном обмене не останавливает автоматически остальные фоновые задачи.
| Операция | Во время переноса | После разрешения запуска |
|---|---|---|
| Приход, расход, перемещение, корректировка | Работы остановлены либо идут по отдельному согласованному журналу | Пишет назначенная WMS |
| Получение заказа и резерв | Входящие события сохраняются; исполнитель резерва определён заранее | Новый обработчик применяет подтверждённые события |
| Публикация остатка и изменение внешнего статуса | Выполняется согласованная процедура конкретного канала | Пишет один назначенный обмен для этой области |
| Задания на сборку и печать | Незавершённые задания учтены; повторная выдача контролируется | Команда работает по принятому списку |
| Начисление складских услуг | Зафиксированы период и уже оказанные работы | Новые услуги учитываются без повторного начисления старых |
На телефоне таблицу можно прокрутить вправо.
Приём информации и изменение данных — разные действия. Остановка складского обработчика сама по себе не прекращает появление заказов у площадки. До переключения определите, кто сохранит их идентификаторы и статусы, где команда увидит необработанное и как исключит повторную обработку. Если это невозможно подтвердить, согласуйте иной режим работы канала или перенесите переключение. Универсальной команды «обнулить всё» для разных площадок нет в этом плане.
Старые начисления и споры могут остаться в прежней системе, а новые операции — перейти в новую. Для этого нужны явные границы периода и оснований. Открытая сборка не становится оказанной услугой лишь потому, что её строка попала в импорт.
3. Зафиксируйте согласованный срез T0
T0 — момент состояния, с которым сравнивают перенос. Укажите дату, часовой пояс, область и способ получения согласованных данных. Время завершения скачивания файла может быть позднее T0.
Если система не даёт единого согласованного снимка, заранее определите проверенный способ остановить запись или собрать финальные изменения. Разные выгрузки, сделанные во время работы склада, нельзя автоматически объявлять одним срезом: остаток мог быть прочитан до сборки, а заказ — уже после неё.
Для каждого файла зафиксируйте состав, фильтры, число строк, контрольные количества и причину исключений. Это практическая проверка: например, официальная инструкция NWMS прямо указывает, что экспорт товара учитывает активный фильтр. Файл по одному магазину не подтверждает полноту всего склада.
Перед включением новой записи сверяют как минимум владельцев и варианты, физические количества, резервы, карантин, открытые заказы и незавершённые работы. Пропущенная строка не означает нулевой остаток. Отклонённый при импорте резерв нельзя оставить без решения, если соответствующий заказ продолжает исполняться. Подготовить состав файлов и связи поможет комплект данных для переезда WMS.
4. Отдельно обработайте события после среза
У каждого поступления в журнал есть собственный идентификатор доставки, источник, владелец, склад, бизнес-объект и вид операции. Сохраните время самого события, время получения, версию источника, устойчивый ключ, исполнителя, результат и подтверждение применения. При повторной доставке идентификатор поступления меняется, а ключ того же бизнес-события сохраняется.
Потерянный ответ ещё не означает, что действие не произошло. Документация Microsoft о повторных сообщениях разбирает именно ситуацию, когда сообщение уже принято, но подтверждение не дошло. Для склада вывод практический: при неизвестном результате сначала выясняют судьбу прежней команды. Повтор с новым ключом может создать второе действие.
В журнале используйте пять понятных состояний:
QUEUED— событие сохранено и ждёт обработки;APPLIED— действие подтверждено и учитывается в расчёте;DUPLICATE— повтор уже учтённого события с тем же содержимым;HOLD— результат или соответствие требует разбора;IGNORE_STALE— устаревшее состояние сохранено в истории и не применено поверх нового.
Одинаковый ключ с разным содержимым требует разбора. Порядок получения тоже не доказывает порядок изменений: поздняя старая версия не должна стирать уже подтверждённое новое состояние. Правило версий и повторов проверяют на реальном источнике; сам XLSX этого механизма не реализует.
Учебный пример: отмена, новый резерв и повтор отгрузки
Все данные ниже вымышлены. Срез получен на 31 октября 2026 года, 18:00, UTC+03:00. У владельца DEMO-A есть 12 единиц PA-M, из них 3 в резерве; ещё 8 единиц PA-L, включая 2 в карантине. У DEMO-B — 5 единиц PB-M. Карантин и резерв не пересекаются, других блокировок нет.
Итого: 25 физически, 3 в резерве, 2 в карантине, 20 доступно. В этом примере доступность считают как физическое количество минус резерв и карантин.
| Событие | Что сделала команда | Изменение физического количества / резерва |
|---|---|---|
| В 18:04 отменён DEMO-ORDER-01 на 3 PA-M | Сохранила событие; подтвердила, что сборка не начата; после GO освободила резерв | 0 / −3 |
| В 18:06 пришёл DEMO-ORDER-02 на 2 PA-M | Сохранила во входящей очереди; после GO создала один резерв | 0 / +2 |
| В 18:27 переданы 2 PA-M по DEMO-ORDER-02 | Сверила физическую передачу и подтверждение; учла расход и снятие резерва | −2 / −2 |
| В 18:28 повторно пришло то же подтверждение | Сопоставила ключ и содержимое; оставила запись DUPLICATE | 0 / 0 повторно |
На телефоне таблицу можно прокрутить вправо.
Получилось 23 физически, 0 в резерве, 2 в карантине, 21 доступно. Повторное сообщение сохранено для разбора доставки, но второй расход не возникает. В заполненном файле эти количества рассчитываются по строкам APPLIED.
Если бы первый заказ уже упаковали, простого снятия резерва было бы недостаточно: понадобились бы разбор физического задания, проверка товара и отдельное разрешение повторной продажи. Эта ветка не входит в обычный путь примера.
5. Принимайте GO по доказательствам
Завершение загрузки позволяет начать проверку. Право работать в новой WMS даёт отдельное решение назначенного руководителя.
| Решение | Когда применять | Что фиксировать |
|---|---|---|
| GO | Критические связи и количества сверены, старое право записи снято, новые события учтены, рабочие проверки выполнены | Область, разрешённые операции, автор, время и основания |
| HOLD | Есть неразобранное расхождение или неизвестный результат | Затронутые операции, ответственный, следующий контроль |
| RETURN | Выбран возврат к ранее согласованному способу работы | Сохранённая дельта, состояние внешних действий, план восстановления и повторная сверка |
На телефоне таблицу можно прокрутить вправо.
Остановите запуск затронутой области, если неизвестен владелец товара, потерян резерв открытого заказа, не сходится физическое количество, две системы могут одновременно изменять один объект или результат внешней команды неизвестен. Отдельный повод для HOLD — невозможность сохранить новые операции при восстановлении.
Не всякая косметическая неточность одинаково опасна. Опечатку в необязательной подписи можно оставить в согласованном списке исправлений с ответственным. Ошибку владельца, варианта, количества или резерва нельзя принять по совпавшей общей сумме склада. Счётчики в файле помогают увидеть открытые условия, но не дают автоматического разрешения на запуск.
6. Возвращайтесь с учётом того, что уже произошло
AWS отдельно рассматривает возврат без новых данных и возврат после новых транзакций. Для действующего склада это три разные ситуации.
Для любой ветки сначала остановите новую запись, сохраните входящие события и зафиксируйте последнюю подтверждённую операцию. После этого выбирайте способ восстановления.
До новых изменений. Остановите новый контур, сохраните входящую очередь, подтвердите актуальность старого состояния. После проверки можно вернуть прежней системе право записи и назначить одного исполнителя отложенных событий.
После новых внутренних операций. Сначала сохраните созданные заказы, резервы, приходы, расходы и незавершённые работы. Затем согласованным способом восстановите их состояние в прежнем контуре и повторно сверьте. Простая загрузка старой копии потеряет эти изменения.
После внешнего действия. Дополнительно сохраните подтверждения площадки, перевозчика и других участвующих систем. Уже переданный товар не становится снова лежащим на складе из-за восстановления базы. Для неизвестного исхода сначала выясните фактический статус по прежнему идентификатору. Документы и маркировочные действия требуют своего проверенного порядка исправления.
В нашем примере старый снимок содержит 25 единиц и резерв 3, а подтверждённое новое состояние — 23 единицы и резерв 0. Возврат к первоначальному снимку как к текущему вернёт в учёт две уже переданные единицы и старый резерв. До возобновления работы нужно учесть отмену, новый заказ и отгрузку, сохранив их исходные основания.
Если безопасный возврат сейчас не подтверждён, руководитель оставляет затронутые операции на HOLD и выбирает проверяемое восстановление либо исправление в новом контуре. Наличие резервной копии само по себе не делает любой возврат безопасным.
7. После GO передайте управление смене
Проверьте все события выбранной области за согласованный период наблюдения: что получено, что применено, что ожидает, что отклонено. Сверьте новые количества с фактическими операциями, убедитесь в доступности старого архива и назначьте владельца поздних возвратов и спорных заказов.
У смены должны остаться порядок действий при сбое, адрес обращения, ссылка на журнал и время следующего контроля. Отметки «импорт завершён», «запись включена» и «перенос принят» сохраняются раздельно. Доказательства окончательной приёмки оформляют по протоколу приёмки перенесённого склада.
Частые вопросы
Можно ли переключить WMS без остановки склада?
Это зависит от доступного механизма согласования данных и организации работ. Для конкретного склада сначала проверяют снимок, события после него и единственного исполнителя записи. Если это не подтверждено, согласуют паузу или другой порядок перехода; универсального обещания нет.
Что делать с заказом, который пришёл между выгрузкой и запуском?
Сохранить его исходный ID, время, состав и статус в контролируемой очереди. Назначить одну систему для исполнения после решения руководителя, сопоставить с уже обработанным и подтвердить результат. Потеря такого заказа не исправляется повторным импортом всех остатков.
Достаточно ли одинаковой суммы остатков до и после?
Нет. Ошибки разных владельцев и вариантов могут взаимно компенсироваться. Сверяют состав и количества в нужных разрезах, отдельно резервы, карантин, открытые работы и события после среза.
Следующий шаг
Заполните пустой план своими владельцами, операциями, моментом среза и условиями HOLD. Строки с неизвестным способом остановки, обработки события или восстановления соберите в один список и обсудите с поддержкой Skirbo. Передавайте обезличенные примеры и идентификаторы проблемы; токены и пароли в таблицу не включайте. Для конкретного источника можно дополнительно изучить переезд с NWMS.
Источники и границы методики
Первичные документы проверены 31.10.2026:
- AWS: подготовка переключения — роли, последовательность, окно и восстановление.
- AWS: этап переключения — остановка записи, синхронизация и возврат с новыми данными.
- Microsoft: повторная доставка сообщений — потеря подтверждения и устойчивые идентификаторы.
- NWMS: работа с товаром — заявленные поставщиком способы экспорта и влияние фильтров; собственный тест кабинета не проводился.
Складские контрольные точки и файлы — авторская адаптация общей методики. Пример не является клиентским кейсом, а наличие описанного API или выгрузки не подтверждает готовый перенос в Skirbo.