Перенос можно принять, когда вы понимаете судьбу согласованных данных, сверили их связи и проверили продолжение складских операций на конкретной загрузке. Сообщение «импорт завершён» подтверждает только один этап. Заказчику нужен протокол: какая версия перенесена, что сравнили, какие расхождения нашли и кто разрешил использовать результат.
Начните с двух файлов: пустого протокола приёмки и заполненного учебного примера. В них шесть рабочих листов: решение, охват, остатки, связи и расчёты, операции, дефекты. Краткая инструкция объясняет поля и ограничения расчёта.
Это общая методика приёмки. Названия полей в шаблоне описывают предмет проверки и не являются готовым форматом импорта Skirbo. Все данные с префиксом DEMO — учебные. Реальные операции в продукте для этого примера не выполнялись.
Зафиксируйте, какой перенос принимаете
В начале протокола укажите владельцев товара, склады, виды данных, момент среза с часовым поясом, версию исходного пакета и целевой загрузки. Добавьте версию WMS, окружение, способ сверки и ответственных со стороны склада и заказчика. Без этого результаты разных попыток легко смешать: вчера проверили тестовую копию, сегодня загрузили другой файл, а подпись поставили под общей фразой «остатки сошлись».
У каждого вида данных должна быть согласованная судьба: перенесён для работы, оставлен в доступном архиве, продолжает обрабатываться прежней системой или требует решения. Например, закрытые документы могут остаться в архиве, а активные резервы — перейти вместе с заказами. Исключение записывают до приёмки, с причиной, местом хранения и ответственным. Молчаливый пропуск строк таким решением не является.
Если склад работал после среза, сравнивайте состояния на одной границе. Либо обе стороны приведены к моменту среза, либо исходный снимок дополнен подтверждёнными движениями до общего контрольного момента. Порядок учёта этой дельты описан в плане дня переключения WMS.
Разделите четыре отметки:
| Отметка | Какое доказательство требуется |
|---|---|
| Импорт выполнен | Версия пакета, журнал загрузки, принятые и отклонённые записи |
| Данные сверены | Сопоставление ключей, контроль значений и связей, разобранные исключения |
| Рабочая запись включена | Решение о конкретном контуре и подтверждение, какая система им управляет |
| Перенос принят заказчиком | Названный подписант, согласованная область, результаты и остаточные ограничения |
На телефоне таблицу можно прокрутить вправо.
В официальном руководстве Microsoft приёмка включает работу с перенесёнными данными, правильные роли пользователей, обычные и крайние сценарии, а затем согласование бизнесом. Здесь этот принцип применён к складскому переносу; он не подтверждает возможности какой-либо конкретной WMS. Источник: Microsoft, проверено 31.10.2026.
Сверьте весь согласованный объём данных
Сначала убедитесь, что ни одна часть переноса не исчезла из проверки. На листе «Охват» для каждого объекта укажите число исходных ключей, проверенных сопоставлений, согласованных исключений, дублей, обрывов связей и непроверенных записей. Приложите реестр, из которого получились числа.
Счёт строк полезен, но недостаточен. Одна исходная карточка может разделиться на несколько вариантов, а несколько строк — агрегироваться по согласованному правилу. Тогда сверяют исходные идентификаторы и все целевые связи, а не требуют механического равенства числа строк. Строка без понятного назначения остаётся в разборе.
Полностью проверьте ключи и обязательные связи в переносимом объёме:
- владелец — товар — вариант — единица измерения;
- склад — зона — ячейка и необходимые партии или экземпляры;
- заказ — строка — резерв — открытое задание;
- выполненная работа — начисление — распределённая оплата;
- операция — документ или доступное архивное доказательство, если они входят в перенос.
Для этих проверок удобно использовать выгрузки и автоматический отчёт. Человек разбирает найденные исключения и подтверждает область. Проверить несколько карточек глазами вместо полного контроля исходных ключей — слабое основание для приёмки большого пакета.
В документации AWS DMS загрузка и валидация также разделены: исходные строки сравниваются с соответствующими целевыми, а ожидающие и непроверяемые записи учитываются отдельно. Практический вывод для протокола: «не проверено» не должно превращаться в ноль ошибок. Это методическая аналогия, а не утверждение об использовании AWS DMS в Skirbo. Источник: AWS, проверено 31.10.2026.
Сравнивайте остатки по владельцу и состоянию
Минимальный ключ адресной сверки: владелец + склад + вариант + ячейка + состояние + единица. Добавьте партию, срок или экземпляр, если они являются частью вашего учёта. Не объединяйте чужие товары по совпавшему артикулу поставщика или штрихкоду. Идентификаторы сохраняйте строками, включая ведущие нули.
Для каждого ключа нужны исходное количество, целевое количество, разница и ссылка на доказательство. Отдельно сверяются годный товар, карантин, брак и другие применяемые состояния. Возврат в пути нельзя считать физически принятым только потому, что он появился в перечне возвратов.
Резерв имеет собственный уровень детализации. Он может относиться к владельцу, складу, варианту и строке заказа без назначения конкретной ячейки. В таком случае проверяйте его на этом уровне и не придумывайте адресное распределение. Документация Microsoft отдельно показывает, что детализация отображаемого остатка зависит от измерений, а резервирование в WMS может находиться выше уровня ячейки. Значения полей нужно сопоставлять по смыслу. Источник: Microsoft, проверено 31.10.2026.
Учебный пример: общая сумма совпала, перенос принимать нельзя
На условном складе два владельца. У DEMO-A есть PA-M: 12 годных единиц в A-01, из них 3 зарезервированы по заказу DEMO-ORDER-01. У него же PA-L: 6 годных и 2 в карантине в A-02. У DEMO-B — 5 годных PB-M в B-01.
В этой учебной модели физически на складе 25 единиц, годных 23, резерв 3, карантин 2, доступно 20. Резерв относится только к годному запасу. Поэтому доступное количество равно годному минус резерв; карантин уже исключён из годного и второй раз не вычитается.
В ошибочной загрузке одна единица отнесена другому владельцу:
| Контрольная группа | Источник | После ошибочного переноса |
|---|---|---|
| DEMO-A: PA-M, годные | 12 | 11 |
| DEMO-A: PA-L, годные | 6 | 6 |
| DEMO-A: PA-L, карантин | 2 | 2 |
| DEMO-B: PB-M, годные | 5 | 6 |
| Физический итог | 25 | 25 |
На телефоне таблицу можно прокрутить вправо.
По владельцам получается DEMO-A: 20 → 19, DEMO-B: 5 → 6. Общий доступный остаток тоже остаётся 20, но у PA-M доступно уже 8 вместо 9, а у PB-M — 6 вместо 5. Два правильных общих итога скрывают ошибку принадлежности.
В примере открыт дефект D-01 с решением «Не принято (HOLD)». Нужно исправить сопоставление, проверить весь затронутый класс владельцев и вариантов, получить новую версию загрузки и повторить зависимые проверки. Простая ручная поправка двух итогов не объясняет, почему ошибка возникла и какие ещё записи затронула.
Выберите операции по риску и запишите ожидаемый результат
Полная сверка данных не заменяет проверку действий. Заказчик должен увидеть, что перенесённый заказ продолжается с правильным резервом, а исправно выглядящая карточка не привязана к чужому владельцу.
Для операций составьте перечень разных условий: владельцы и склады, статусы открытых заказов, способы резервирования, партии и комплекты при наличии, возвраты, рабочие роли, устройства и расчётные правила. Включите каждый обязательный тип процесса и известные проблемные преобразования. Это выбор по риску, а не обещание статистической надёжности от определённого количества тестов.
В каждой строке протокола нужны исходные ID, действие, ожидание, фактический результат и доказательство. Последнее должно позволять восстановить версию загрузки, окружение, исполнителя и время. Скриншот итоговой суммы без этих связей плохо объясняет результат.
| Сценарий | Что требуется увидеть |
|---|---|
| Продолжение открытого заказа | Тот же владелец и вариант, сохранённое незавершённое действие, отсутствие второго задания или резерва |
| Отмена до сборки | Освобождение именно связанного резерва по принятой модели, сохранение физического факта |
| Отмена после упаковки | Согласованный порядок распаковки и внешнего обновления, без преждевременного освобождения товара |
| Возврат | Раздельные состояния «в пути», «физически принят», «карантин», «разрешён к дальнейшей работе» |
| Повтор импорта или события | Нет повторного прихода, списания, резерва, начисления или оплаты |
| Работа обычной роли | Доступ к своим данным и отказ в доступе к чужим объектам, поиску и выгрузкам |
На телефоне таблицу можно прокрутить вправо.
Проверяйте действия в согласованной изолированной копии или тестовом контуре. Каждому сценарию задайте исходное состояние: после тестовой отмены нельзя без подготовки ожидать резерв 3 в следующем тесте сборки. Внешние записи и реальные документы допускаются отдельно; локальный успех не доказывает принятие площадкой.
Например, для уже упакованного отменённого заказа Яндекс Маркет описывает распаковку и передачу актуального остатка. Поэтому проверка одной только локальной отмены не закрывает весь такой сценарий. Для других каналов нужен их собственный актуальный порядок. Источник: Яндекс Маркет, проверено 31.10.2026.
Если в выборке обнаружена ошибка, расширьте проверку на все записи с тем же правилом преобразования или связью. Для физического обхода действуют те же границы: несколько адресных пересчётов помогают проверить перенос, но не заменяют полную инвентаризацию и не доказывают истинность всех исходных остатков.
Примите расчёты вместе с их происхождением
Финансовый итог должен объясняться записями. В учебном примере уже существует начисление DEMO-CHARGE-01 на 150 ₽ за выполненную работу DEMO-WORK-01. На него распределено 100 ₽ из DEMO-PAY-01. Открытый остаток — 50 ₽.
Проверьте не только вычитание 150 − 100. Начисление, оплата, распределение, владелец и валюта должны остаться связанными. Повторная загрузка не создаёт вторые 150 ₽, а открытая сборка DEMO-WORK-02 по заказу на PA-M × 3 не становится новой платной услугой из-за самого импорта.
Если в область включены тарифы, добавьте расчёты по их версиям, единицам, датам действия и округлению. Аванс, распределённая оплата, спорная сумма и корректировка проверяются отдельно. Для закрытого периода может быть согласовано сохранение расчётов в прежнем учётном контуре с доступным архивом. Тогда протокол должен назвать этот контур и проверить нужные ссылки, а не изображать полный перенос денег одной цифрой.
Разберите расхождения и подпишите конкретную область
Разница по владельцу, варианту, резерву или открытой финансовой позиции требует объяснения. Для ключей и штучных количеств не вводите разрешённый «процент потерь». Допуск по округлению имеет смысл только для конкретного расчёта с заранее согласованным правилом.
В реестре дефектов запишите затронутые ключи, наблюдение, последствие, владельца исправления, следующий шаг и доказательство повторной проверки. Статус «исправлено» означает, что результат ещё нужно проверить. Не заменяйте старый протокол новым без сохранения версии и причины изменения.
Остановите приёмку затронутого контура, если смешаны владельцы, не объяснён остаток, потерян резерв, неверно сопоставлен вариант, повторился эффект операции, открыт чужой доступ или неизвестен внешний результат обязательного сценария. Обязательный тест со статусом «не проверено» также оставляет вопрос открытым.
Частичная приёмка возможна для точно выделенной независимой области. Например, согласованные закрытые документы остаются в доступном архиве, а перенос активных данных принят отдельно. В решении нужны граница, рабочий порядок, ответственный и срок снятия ограничения. Формулировка «принимаем всё, остальное потом» такую область не задаёт.
Заказчик подписывает версию переноса, перечисляет принятые данные и операции, сохраняет остаточный список. Разрешение на рабочую запись оформляется отдельно от подписи о загрузке файлов. После новой загрузки или изменения правил сопоставления повторяют затронутую сверку: прежний успешный протокол не распространяется на новые байты автоматически.
Следующий шаг
Откройте пустой протокол вместе с руководителем склада и ответственным за расчёты. Сначала заполните область, версии и исходные количества. Затем соберите отчёты, объясняющие каждое расхождение, и назначьте обязательные операционные проверки.
Если исходный пакет ещё не готов, используйте таблицы и словарь полей для переезда. Для конкретного исходного продукта пригодится разбор переезда из LiteWMS. Если рассматриваете Skirbo, обсудите с поддержкой состав данных, непроверенные сценарии и способ передачи обезличенного образца. Возможность переноса конкретных объектов, объём работ и критерии приёмки согласуются по результатам этой проверки.
Частые вопросы
Достаточно ли одинакового общего остатка?
Нет. В учебном примере 25 единиц до и после загрузки скрывают −1 у одного владельца и +1 у другого. Нужны сверки по согласованным ключам, состояниям и связям.
Нужно ли выполнять каждый заказ вручную?
Все исходные ключи, обязательные связи и контрольные значения в области переноса проверяют полностью. Действия операторов, физические адреса и документы выбирают по риску с покрытием значимых сценариев. Найденный дефект расширяет область проверки.
Кто должен принять перенос?
Названный заказчиком ответственный принимает конкретную версию и область по доказательствам. Участие склада, владельца данных и ответственного за расчёты зависит от переносимого состава. Сообщение исполнителя об успешном импорте не заменяет это решение.
Можно ли работать с незакрытыми замечаниями?
Только в явно согласованной независимой области с понятным рабочим порядком. Ошибки владельца, остатка, резерва, чужой доступ и неизвестный обязательный внешний результат не закрываются общей оговоркой «доработаем позже».
Подтверждает ли этот протокол готовый перенос в Skirbo?
Протокол задаёт, какие доказательства получить. Он не подтверждает конкретный импортёр, включение кабинета, реальные операции или клиентскую приёмку. Эти результаты фиксируются отдельно на согласованной конфигурации.