После нажатия «Завершить приёмку» появилось сообщение об ошибке. Товар физически пересчитан, на экране документа прежний статус, а остаток уже изменился. Здесь недостаточно написать «не работает приёмка»: сначала нужно сохранить факты и понять, безопасен ли повтор.
Рабочий результат этой статьи — описание одного сбоя, по которому можно найти операцию, оценить влияние на смену и проверить восстановление. Методика подходит для приёмки, сборки, печати, отгрузки и обмена с другой системой. Она не задаёт срок ответа поддержки и не подтверждает возможности конкретной WMS.
Начните с короткого сообщения. Если работа остановлена, отправьте известные время, операцию, ошибку и масштаб сразу. Остальное добавляйте в ту же переписку; собирать идеальный архив до первого обращения не требуется.
1. Зафиксировать, что именно произошло
Назовите действие, которое человек собирался выполнить, и отделите его от сообщения системы. «Приёмка не завершена» — предположение, если известен только тайм-аут. Точнее: «После одного нажатия появился тайм-аут; статус документа такой-то; фактическое завершение неизвестно».
Запишите время события вместе с датой и часовым поясом, например 31.10.2026 10:14:22 UTC+03:00. Если на устройстве часы могут отставать, укажите это. Время снимка экрана и время действия — разные значения. При плавающем сбое полезны два наблюдения: последнее успешное выполнение и первый известный сбой.
В официальных рекомендациях Google Cloud к обращению предлагают прикладывать ожидаемое и фактическое поведение, время, конкретные идентификаторы и относящиеся к проблеме материалы. Ниже этот принцип адаптирован к складской операции; условия поддержки Google не переносятся на Skirbo. Источник: Google Cloud.
Минимальный пакет для первого сообщения
Таблицу можно прокрутить по горизонтали.
| Поле | Что написать |
|---|---|
| Где | Кабинет или организация, склад, раздел, канал продаж, если он участвует |
| Какая операция | ID заказа, приёмки, перемещения или документа; вид операции |
| Когда | Дата, время и часовой пояс; продолжается ли сбой сейчас |
| Ожидание | Какое одно действие и какой результат должны были получиться |
| Факт | Точный текст ошибки и наблюдаемый статус; неизвестное так и назвать |
| Влияние | Сколько заданий остановлено, затронут ли один клиент или несколько |
| Рабочий срок | Ближайшая передача или другой реальный дедлайн с часовым поясом |
| Что уже сделано | Число повторов, выполненные проверки, согласованный обход и ответственный |
Идентификатор нужен для поиска конкретной записи. В адресном канале поддержки оставляйте нужный ID точным, включая ведущие нули. Не добавляйте ФИО покупателя, телефон и адрес доставки, если они не нужны для разбора. Если номер объекта сам содержит персональные данные, согласуйте защищённый способ передачи. Для публикации в общем чате используйте обезличенный пример, а настоящие сведения передавайте только уполномоченному получателю.
2. Определить, можно ли повторять действие
Повторный просмотр и повторная запись решают разные задачи. Если отгрузка, приёмка, списание или документ могли уже пройти, ещё одно нажатие нельзя использовать как универсальную диагностику. Сначала требуется установить состояние исходной операции.
Таблицу можно прокрутить по горизонтали.
| Наблюдение | Следующий шаг |
|---|---|
| Опечатка или ошибка проверки до отправки, сохранения не было | Сохранить текст ошибки; исправлять только понятное поле в пределах своих прав |
| Запрос отправлен, ответ потерян или показан тайм-аут | Отметить результат как неизвестный; сверить исходную операцию по ID до повтора |
| Система показывает успех, а следующий этап не видит результат | Сопоставить время, ID и состояния двух этапов; не создавать заменяющий заказ вслепую |
| Принтер не выдал этикетку | Проверить наличие задания и бумагу по инструкции рабочего места; не повторять складскую операцию вместо предусмотренной перепечатки |
| Видны данные другого клиента или меняется неверный товар | Остановить затронутое действие, сообщить ответственному и поддержке адресно; не продолжать исследование чужих данных |
В HTTP стандарт отдельно ограничивает автоматическое повторение операций, для которых одинаковый запрос может дать повторный эффект. Практический вывод для склада: отсутствие ответа ещё не доказывает, что запись не произошла. Это общая осторожность при неопределённом результате, а не утверждение, что конкретная кнопка Skirbo создаёт дубли. Источник: RFC 9110, § 9.2.2.
Не меняйте остаток, владельца товара или статус вручную только ради исчезновения ошибки. Такое действие может скрыть исходную причину и разорвать связь с фактическим товаром. Исправление выбирает ответственный с нужными полномочиями после сверки. Если затронута внешняя система, проверяют и её подтверждение: исправленный экран WMS не отменяет уже принятый внешний документ.
3. Добавить подробности без опасного воспроизведения
После первого сообщения опишите последовательность до сбоя: что открыли, что выбрали, какое значение ввели и какое действие выполнили. Отдельно перечислите последующие попытки. Фраза «несколько раз попробовали» скрывает важный факт; полезнее «первое нажатие в 10:14, повтор в 10:16, затем остановились».
Приложите роль пользователя, устройство, браузер и его версию. Для сканирования или печати добавьте модель устройства, тип подключения и размер этикетки, если они известны. Версию складского приложения указывайте только тогда, когда она показана; не нужно её угадывать. Если интерфейс выводит request ID или correlation ID, скопируйте его вместе с ошибкой.
Проверка на другом компьютере не всегда безопасна: она может снова отправить ту же запись. Для разбора действий, меняющих данные, попросите поддержку указать допустимый способ: штатную проверку состояния, согласованный тестовый контур или подготовленный учебный объект. Не создавайте фиктивную продажу, отгрузку или юридический документ в рабочем потоке ради видео.
Если ошибка исчезла сама, сохраните оба факта: когда наблюдали сбой и когда состояние изменилось. Это ещё не объясняет, корректно ли завершилась первая операция. Причина может остаться неизвестной до проверки журнала; в обращении допустимо честно написать «повторить безопасно не удалось».
4. Подготовить вложения, которые можно передать
Для первого сообщения приложите текст ошибки и обрезанный скриншот: нужный объект, статус, относящиеся к сбою поля. На снимке не должны случайно остаться другие клиенты, адресная книга, вкладки с личной перепиской или секрет в адресной строке. Сохраняйте оригинал у себя по правилам компании; в поддержку передавайте проверенную копию.
Логи и сетевой архив HAR добавляют, когда их запросили и объяснили безопасный способ получения. В Chrome DevTools доступен экспорт HAR (sanitized), который исключает чувствительные заголовки вроде Cookie, Set-Cookie и Authorization. Такой экспорт всё равно нужно проверить: в URL, телах запросов и ответах могут оставаться данные, не относящиеся к сбою. Полная запись с чувствительными данными не нужна «на всякий случай». Источник: Chrome DevTools.
Не отправляйте пароли, коды входа, API-токены и cookies. Не вставляйте без проверки команду Copy as cURL: она может содержать данные авторизации. Убирайте лишние персональные сведения, платёжные реквизиты и полные коды маркировки. Рекомендации OWASP по журналам прямо выделяют секреты и чувствительные данные как сведения, которые требуют исключения или специальной обработки. Источник: OWASP.
Если не можете уверенно проверить HAR, отправьте описание, ID и снимок экрана, а способ получения остальных данных согласуйте с поддержкой. Не загружайте архив в случайный онлайн-сервис для «очистки». При подозрении, что секрет уже отправлен не тому получателю, сообщите своему администратору: удаление сообщения само по себе не подтверждает, что доступ к секрету прекратился.
5. Пример: приёмка изменила остаток, но не статус документа
Все данные ниже учебные. Это вымышленная ситуация в условной складской программе; названия кнопок не описывают интерфейс Skirbo.
В кабинете DEMO-OWNER-A, склад DEMO-WH-1, приёмка RCV-DEMO-031. 31.10.2026 в 10:14:22 UTC+03:00 один раз нажали «Завершить приёмку» на 12 штук SKU-DEMO-001. Ожидали завершённый документ и остаток 36 штук вместо 24. Получили «Время ожидания ответа истекло». В 10:15:10 документ показывал «Черновик», а просмотр остатка — 36. Фактическое завершение неизвестно, повторных нажатий 0. Товар остаётся в зоне приёмки. Старший смены остановил действия по этой приёмке. Просим проверить факт завершения и безопасный следующий шаг. Внутренний срок размещения — сегодня в 12:00 UTC+03:00.
Такое сообщение не подменяет диагностику. Оно даёт проверяемую отправную точку: одну запись, время, исходные значения и конкретное противоречие. Из него нельзя заключить, что на складе пропал товар или что ошибка затрагивает все приёмки.
В полном учебном примере отдельно отмечены неизвестный HTTP-код, отсутствующий на экране ID запроса и отсутствие повторов. Имена вложений условные; настоящий скриншот клиента к файлу не приложен.
Для восстановления здесь проверяют не только статус документа. Нужны одна приёмка на 12 штук, одно соответствующее движение и объяснимый итог 24 + 12 = 36. Если вместе с приёмкой учитываются услуги, проверяют и отсутствие повторного начисления. Это критерии проверки, а не сообщение о том, что вымышленный инцидент уже устранён.
6. Вести одну переписку и согласовать временную работу
По одному сбою удобно сохранять одну цепочку: сообщение, уточнения, согласованные действия, результат. При наличии номера обращения добавляйте его в дальнейшую переписку. Если проблема расширилась, обновите масштаб и срок в том же обращении. Параллельные сообщения без общей ссылки могут привести к разным версиям происходящего.
Пусть один сотрудник склада отвечает на вопросы и согласует действия с руководителем смены. Временное решение должно содержать три вещи: кто разрешил, к каким операциям оно относится и как позже сверить ручные действия. «Пока ведём всё в другом файле» без этих правил не объясняет, кто записывает остаток и как избежать двойной обработки.
Останавливать весь склад или только одну область — решение ответственного по фактическому масштабу. Продолжение других операций допустимо после подтверждения, что они независимы от сбоя. Неизвестную область влияния нельзя считать безопасной по умолчанию.
Если работа действительно остановлена, назовите это прямо: например, «не можем завершить 8 подготовленных заказов; передача в 16:00 UTC+03:00». Это описание влияния. Из него не следует обещание поддержки устранить проблему к этому времени. Приоритет, часы связи и следующий контакт определяются действующим регламентом и договорённостью по обращению.
7. Закрывать обращение после сверки результата
Исчезнувшее сообщение об ошибке — повод проверить состояние исходной операции. Перед подтверждением восстановления ответьте на пять вопросов:
- Установлен ли результат именно того заказа, приёмки или документа, с которого начался сбой?
- Сходятся ли физический товар, складской учёт и внешнее подтверждение, если оно требуется для этой операции?
- Нет ли дубля движения, второго документа или лишнего начисления в затронутом объёме?
- Отражён ли согласованный ручной обход ровно один раз?
- Прошёл ли согласованный контрольный сценарий, а оставшиеся исключения получили ответственного?
Запишите фактический результат, время проверки и сотрудника, который его подтвердил. Если проверен один заказ, так и укажите: это не доказывает восстановление всей очереди. Если причина не установлена, сохраните это ограничение и договоритесь, какие признаки собирать при повторении.
Следующий шаг
Заполните первую часть шаблона обращения, удалите лишние данные и отправьте в действующую группу поддержки своего кабинета. Если своего обращения ещё нет, откройте поддержку Skirbo в Telegram: этот адрес указан на официальном сайте Skirbo. Открытие чата само по себе не отправляет сообщение и не подтверждает, что его приняли в работу.
Когда причина требует изменения процесса или доработки, отдельно сформулируйте ожидаемое поведение и проверку результата. Не расширяйте срочное обращение до «заодно переделать весь склад»: сначала зафиксируйте состояние проблемной операции и условия продолжения работы.
Источники и границы
Первичные источники проверены 31.10.2026: рекомендации Google Cloud по обращениям, Chrome DevTools — экспорт HAR, OWASP — данные в журналах, RFC 9110, § 9.2.2, публичный канал поддержки Skirbo.
Шаблон — общая методика работы с инцидентом. Порядок необратимых операций, полномочия, способ безопасной проверки и условия поддержки уточняют для конкретной системы. Канал связи проверен на открытие; отправка тестового обращения и работа оператора в рамках подготовки статьи не проверялись.