После обновления 1С база открывается, документы проводятся, ошибок на экране нет. Для склада этого мало: проблема часто проявляется позже и не там, где её ждали. Заказ не дошёл до WMS, кладовщик не смог подтвердить отбор, а результат вернулся в учёт дважды.
Чек-лист ниже проверяет не отдельные функции, а сквозную цепочку: заказ → задание на ТСД → результат → учёт. Восемь сценариев; у каждого указано, что сделать и по какому признаку видно, что всё в порядке. Названия документов, статусов и регистров в вашей системе могут отличаться, поэтому формулировки нужно адаптировать под свою конфигурацию, версию WMS и правила обмена.
Для проверки понадобятся четыре роли: администратор 1С или интегратор, руководитель склада, кладовщик, который будет работать на ТСД, и сотрудник учёта, умеющий сверять документы. Без кладовщика и учёта проверка превращается в техническую: она покажет, что обмен работает, но не покажет, что работает склад.
До обновления: зафиксируйте исходное состояние
Уточните совместимость. Прежде чем обновлять рабочую базу, спросите у поставщика WMS и компонента обмена, поддерживают ли они новую версию вашей конфигурации. Это самый дешёвый способ избежать остановки склада: ответ нужен письменно и до установки релиза.
Запишите версии. Платформа 1С, конфигурации (УТ или ERP), расширения, WMS и мобильное приложение, компонент обмена, а при необходимости ОС и версия приложения на ТСД. После обновления вам будет с чем сравнить.
Соберите контрольный набор. Пять–десять документов, отражающих реальную работу склада: обычный товар; товар с характеристиками или сериями, если они у вас есть; разные единицы упаковки; маркированный товар; частичная отгрузка; отмена; возврат. Для каждого сохраните исходный документ, ожидаемые количества, статусы и результат обмена: скриншот или выгрузка подойдут.
Проверяйте на копии. Копия должна быть изолирована: никаких реальных заказов, документов и сведений о маркировке во внешние системы. При первом запуске скопированной базы платформа может спросить, перемещена она или скопирована; для тестовой копии выбирается «скопирована». Даже после этого проверьте вручную, что регламентные задания и подключения к внешним сервисам отключены, а ключи доступа и учётные данные интеграций заменены тестовыми или удалены. Для внешних проверок используйте только тестовый контур, предусмотренный поставщиком.
Проверьте откат. Резервную копию мало создать, нужно убедиться, что из неё можно восстановиться, и заранее согласовать условия отката. Если после обновления в базе уже появились новые операции, возврат к старой версии означает их потерю или отдельный план переноса.
Сценарий 1. Заказ попадает в WMS
Что делаем. Создаём в учётной системе контрольный заказ и запускаем обмен.
Что смотрим. Номенклатуру, характеристики, единицы измерения, количество, склад назначения, статус заказа в обеих системах.
Критерий. В WMS появился один ожидаемый заказ, поля совпадают с учётом, в очереди обмена нет необъяснённых ошибок.
Сценарий 2. Задание выполняется на ТСД
Что делаем. Под обычной рабочей ролью, не под администратором, открываем задание, сканируем адрес и товар, подтверждаем операцию. Затем намеренно сканируем неверный товар.
Что смотрим. Сообщения на экране, скорость отклика, поведение приложения после ошибки.
Критерий. Правильная операция выполняется; ошибочная обрабатывается по согласованному правилу, а сотрудник видит понятное сообщение и может продолжить работу, не обращаясь к администратору.
Сценарий 3. Результат возвращается в учёт
Что делаем. Завершаем складскую операцию и находим связанный документ в учётной системе.
Что смотрим. Фактическое количество, статус документа, связь с исходным заказом, время появления результата.
Критерий. Результат привязан к нужному заказу, не потерян и не продублирован; факт в учёте совпадает с фактом в WMS.
Сценарий 4. Частичное исполнение
Что делаем. Если склад допускает частичную отгрузку или недокомплект, выполняем такую операцию на контрольном заказе.
Что смотрим. Как обе системы отражают выполненную часть и остаток.
Критерий. Неполное исполнение нигде не превратилось в полное. Судьба остатка (дозаказ, резерв, закрытие) соответствует вашему процессу.
Сценарий 5. Отмена и возврат
Что делаем. Проверяем отмену до исполнения и возврат после отгрузки — те варианты, которые предусмотрены вашим процессом. Это разные сценарии, и один не должен подменяться другим или удалением документов.
Что смотрим. Статусы, резервы, остатки, историю операции.
Критерий. Резервы и остатки согласованы между системами, история операции сохранена и объясняет, что произошло.
Сценарий 6. Коды маркировки в обмене
Что делаем. На разрешённом тестовом сценарии сравниваем набор кодов в мобильном приложении, WMS и учётной системе. Учитываем режим учёта и товарную группу, которые вы используете.
Что смотрим. Количество кодов, целостность строк, отсутствие повторов. Обработку внешнего документа проверяем отдельно от его отправки: «отправлен» не значит «принят».
Критерий. Передан нужный набор кодов, строки не обрезаны, одна единица не добавлена дважды. Подробный маршрут поиска расхождений — в материале «Товар на складе, а данные не сходятся».
Сценарий 7. Повторный обмен без дублей
Что делаем. На тестовом контуре воспроизводим повтор после сбоя в том виде, в каком его предусматривает механизм обмена: например, повторную передачу того же сообщения.
Что смотрим. Не появился ли второй документ, вторая отгрузка, второе списание.
Критерий. Операция восстанавливается без дубля. Ошибку можно найти по идентификатору и времени, а не «по ощущению».
Сценарий 8. Роли и регламентные задания
Что делаем. Проверяем доступы кладовщика, диспетчера и сотрудника учёта, расписание обменов, обработку фоновых ошибок.
Что смотрим. Выполняются ли регламентные задания по расписанию, куда попадает информация о сбое и кто её получает.
Критерий. Смена работает без выдачи всем административных прав; ответственный узнаёт о сбое обмена раньше, чем склад остановится.
Если склад работает с маркетплейсами
Если у вас настроены обмены с Ozon или Wildberries, добавьте к контрольному набору отдельную линию и пройдите её целиком: заказ с площадки → документ в учёте → задание на сборку → отгрузка → статус обратно на площадку. Отдельно проверьте остатки: то, что выгружается на площадку, должно совпадать с учётом, а не обнуляться и не уходить в минус из-за изменившегося правила расчёта.
Возвраты с маркетплейсов тоже проверяйте отдельно: их обработка часто отличается от возврата обычному покупателю. И главное правило: на копии базы не должно быть боевых ключей доступа к кабинетам площадок. Иначе тест создаст реальные операции.
Как зафиксировать результат
Результат проверки удобно вести в виде таблицы. Для каждого сценария записывают номера контрольных документов, ожидаемый и фактический результат, подтверждение (скриншот или выгрузка), ответственного и статус: «пройдено», «ошибка» или «не применимо». Причину «не применимо» тоже указывайте: через полгода она будет важна.
| Сценарий | Что проверяем | Критерий успеха | Статус |
|---|---|---|---|
| 1. Заказ в WMS | Поля заказа, очередь обмена | Один заказ, поля совпадают | … |
| 2. Задание на ТСД | Верная и ошибочная операции | Понятное сообщение, работа продолжается | … |
| 3. Результат в учёт | Количество, статус, связь с заказом | Без потерь и дублей | … |
| 4. Частичное исполнение | Выполненная часть и остаток | Системы согласованы | … |
| 5. Отмена, возврат | Статусы, резервы, остатки | История сохранена | … |
| 6. Коды маркировки | Набор кодов в трёх местах | Нет обрезки и повторов | … |
| 7. Повторный обмен | Повтор после сбоя | Нет дубля, ошибка находится по идентификатору | … |
| 8. Роли и задания | Доступы, расписание, уведомления | Нет лишних прав, о сбое сообщают | … |
| 9. Маркетплейсы (если есть) | Заказ, остатки, возврат | Сквозная цепочка и остатки сходятся | … |
Критические сценарии согласуйте до обновления. Если заказ теряется, остатки расходятся или формируется дубль, оснований считать проверку завершённой нет, и переносить обновление в рабочую среду рано.
Первая смена после переноса
После переноса в рабочую среду выполните короткую согласованную проверку: один реальный заказ проходит всю цепочку, очереди обмена пусты или сокращаются, в журнале нет повторяющихся ошибок, остатки по выбранным десяти позициям совпадают в обеих системах.
В первую смену на связи должны быть ответственный за обмены и руководитель склада, и заранее нужно решить, что делает смена, если обмен остановился: какие операции продолжаются, а какие ждут.
Новостной контекст и источник
В описании УТ 11.6.2.59 1С перечисляет изменения интеграций с Ozon и Wildberries. Это повод проверить используемые обмены по перечню изменений, но не доказательство того, что что-то обязательно сломается. Чек-лист выше — редакционная методика, а не официальная инструкция по установке релиза.