Разберем, как спроектировать веб-приложение для приемки товара по QR: поток «поставка → позиции → расхождения», сканирование и формирование акта.
Приемка по QR обычно ломается не на сканировании, а на фиксации факта: что именно приехало, что вы реально увидели на паллете и как быстро оформить расхождения. Хорошее приложение убирает ручные записи, снижает ошибки и делает процесс прозрачным для склада, снабжения и бухгалтерии.
Расхождение - это не только «не доложили». В реальной приемке чаще всего встречаются четыре ситуации: недостача (приехало меньше), пересорт (приехал не тот товар), излишек (товар есть, но в документах его нет) и брак (приехал, но не принимается в остатки). Ключевое требование: расхождение фиксируется сразу, в момент обнаружения, пока коробка еще в руках, а не «потом в конце смены».
Процесс лучше держать линейным: сначала выбираете поставку, затем работаете с ее позициями, и только после этого оформляете расхождения. Если эти шаги смешать, люди начинают сканировать «в никуда», появляются дубли, а разбор превращается в поиск по чатам и звонкам.
На выходе обычно нужны два результата: акт расхождений по поставке (для поставщика и учета) и история действий (кто сканировал, что подтвердил, когда и почему).
Пример: приехали 20 коробок, по QR нашли 2 пересорта и 1 недостачу. Система должна показать итог по каждой позиции и сформировать акт без ручного переписывания.
Чтобы приложение для приемки по QR не превратилось в «комбайн», начните с трех сущностей: поставка, позиции поставки и расхождения. Этого хватает, чтобы сканировать, фиксировать факт и выпускать акт.
Поставка - это «контейнер» приемки. Обычно достаточно номера (как в накладной), поставщика, даты и статуса. Статусы держите простыми: черновик (создали и загрузили позиции), в приемке (идет сканирование), закрыта (все подтверждено, акт сформирован).
Позиции поставки - это ожидаемая ведомость: SKU (или внутренний код), наименование, ожидаемое количество и единица измерения (шт, кг, уп). Важно разделять «ожидаемое» и «фактическое», даже если чаще всего они совпадают.
Расхождение хранит факт и причину. Практичный минимум: фактическое количество, разница (или непринятое количество), тип расхождения (недостача, пересорт, излишек, брак), комментарий и кто подтвердил. Для пересорта полезно хранить связку «ожидали SKU A, фактически пришло SKU B».
Чтобы потом не спорить «кто нажал», заведите журнал событий (аудит). Это отдельный лог, который пишет записи при каждом скане, отмене, подтверждении и правке.
Для акта тоже не усложняйте структуру: заголовок (поставка, поставщик, дата), таблица расхождений, комментарии и подписи (ФИО или роль, время). Например: по поставке 4512 нашли недостачу 2 шт по SKU 1007 и пересорт, где вместо SKU 2001 пришел SKU 2003.
Чтобы приемка не превращалась в спор «кто виноват», роли и права лучше задать сразу. Тогда у каждого будет понятный экран и набор действий, а цифры по поставке будут сходиться без ручных правок.
Чаще всего хватает трех ролей:
Важно разделить «ввод факта» и «утверждение». Например, кладовщик может указать недостачу 2 шт., но официальным расхождением это станет только после подтверждения старшим смены. Такой подход снижает конфликты: данные появляются сразу, но не считаются финальными, пока их не утвердили.
Без правил правок любой акт быстро теряет доверие.
После закрытия поставки не меняйте количества «в строке». Вместо этого создавайте корректировку отдельным действием, обязательно фиксируйте причину и автора, а в журнал событий добавляйте запись «кто, что изменил, когда и почему». Если акт нужно пересобрать, выпускайте новую версию (например, «Акт v2») и храните, кто и зачем его пересоздал.
Интерфейс приемки должен помогать делать одно действие за раз. На складе шумно, руки заняты, времени мало, поэтому лучше ограничиться двумя основными экранами и одной вкладкой контроля.
1) Выбор поставки. Пользователь находит поставку по номеру, дате или поставщику, видит краткое резюме (сколько позиций и плановое количество) и нажимает одну кнопку «Начать приемку». Это снижает риск, что сканирование уйдет не в ту поставку.
2) Экран сканирования. Камера открывается сразу. В центре - крупный статус: «Сканируйте QR», «Код распознан», «Код не найден», «Позиция не в этой поставке». Под ним - короткая подсказка: поднести ближе, включить свет, протереть этикетку, перейти на ручной ввод.
После каждого скана показывайте карточку позиции: название, артикул, ожидаемое количество и уже принятое. Для скорости добавьте быстрые действия (+1, +5) и ручной ввод, если принимаете коробами.
Кнопки для фиксации расхождений лучше держать всегда на виду и сделать одинаковыми для любой позиции: недостача, пересорт, излишек, брак и короткий комментарий.
3) Вкладка «Расхождения». Список всех проблем, фильтр по типу и быстрый переход в нужную позицию. Кладовщик отмечает проблему на месте, а старший смены позже быстро проходит список и подтверждает решения.
Сильная приемка по QR держится на простом потоке: сначала фиксируете, что должно приехать, затем накапливаете факт сканами, и только при проблемах уходите в расхождения. Если постоянно прыгать по экранам или пытаться «разбирать ошибки» до накопления факта, люди начнут обходить систему.
Рабочий поток выглядит так:
Пример: поставка на 120 единиц. На 37-й минуте сканируете товар, который относится к другой позиции. Одним действием создаете пересорт с причиной «в коробке другой артикул» и идете дальше. В конце у поставки 3 проблемные строки, и сразу понятно, готов ли акт.
Сканирование должно быть предсказуемым: один QR - одна понятная реакция. Заранее договоритесь, что именно зашито в коде, иначе будет много «не распознано» и ручной работы.
Минимум, который спасает приемку от путаницы: SKU или внутренний код позиции (лучше не название). Дальше по необходимости добавляют номер партии и срок годности. Если часто принимаете коробами, полезен коэффициент или единица учета.
Если QR не читается (грязь, блики, камера без фокуса), нужен быстрый запасной путь: ручной поиск по SKU, штрихкоду или названию, но только в рамках текущей поставки. Хорошее правило: ручной режим не должен занимать больше 10-15 секунд на позицию.
Антидубли обязательны. Частый сбой: сотрудник держит камеру над кодом, и система успевает прибавить +1 несколько раз. Защита обычно включает блокировку повторного скана того же значения на 1-2 секунды, явный счетчик на экране и идемпотентность на сервере (одно событие скана имеет свой идентификатор).
Если пропала связь, приемка не должна останавливаться. Сохраняйте действия в очередь на устройстве (скан, ручное добавление, отмена), а при восстановлении сети отправляйте пачкой и показывайте статус: «в очереди», «отправлено», «конфликт».
Чтобы быстро понимать, что ломается, ведите логи: ошибки камеры и прав доступа, невалидный формат QR, конфликты дублей, сетевые ошибки и повторы отправки, а также кто и когда делал ручные правки.
Акт расхождений нужен не ради «бумажки», а чтобы зафиксировать факт и дальше спокойно разрулить пересорт и недостачу: принять, оформить претензию, сделать возврат или корректировку остатков. Если акт формируется автоматически, важнее всего, чтобы он был понятным и одинаковым каждый раз.
В акте обычно три блока:
Логика заполнения простая: ожидалось берется из документа поставки, факт - из сканирований и подтвержденных корректировок. «Чистые» позиции без отклонений в акт не попадают.
Чтобы повторно сформированный акт не путал людей, добавьте номер и версию: «Акт N 17, версия 2, пересоздан 21.01.2026 14:35», и храните, кто и почему пересоздал.
По выводу чаще всего хватает печатной формы и PDF. Иногда нужна выгрузка в файл для бухгалтерии. В любом случае оставьте поля для согласования: комментарий, ответственный, дата и статус подтверждения.
AI дает лучший результат, когда вы описываете процесс как для исполнителя: какие экраны нужны, какие статусы меняются и кто имеет право нажимать «Подтвердить».
Начните со «скелета»:
Отдельно проговорите экран сканирования «для одной руки»: крупные кнопки, минимум текста, автофокус, простые сообщения при ошибках (неизвестный QR, дубль, скан не в ту поставку).
Затем задайте шаблон акта: шапка, таблица расхождений, правила (что считать пересортом), и один пример на тестовых данных.
И сразу зафиксируйте критерии готовности. Например: 3 тестовые поставки с ожидаемыми результатами, возможность сканировать 10 позиций за минуту без лишних кликов, расхождение создается за 2 действия и попадает в акт, после закрытия данные не меняются, акт одинаково формируется для пересорта и недостачи.
Самая частая причина хаоса не в QR, а в том, что люди по-разному понимают, что считать ошибкой. Термины лучше закрепить в интерфейсе и данных.
Смешивание уровней расхождений. Расхождение по позиции (SKU) - одно, по коробке/партии/палете - другое. Фиксируйте на том уровне, который влияет на учет и акт. Если важны партии, добавьте поле «партия/серия» и не позволяйте закрыть строку без него.
Нет статусов и запретов. Если поставку можно править после «Закрыто», ошибки становятся невидимыми. Держите понятные статусы и жесткое правило: после закрытия только корректировка с причиной, автором и записью в журнал.
Слишком много ручного ввода. На складе никто не будет печатать длинные комментарии. Помогают быстрые причины (пересорт, недостача, повреждение, нет маркировки) и минимум полей на экране.
Расхождения разбросаны по разным местам. Нужен единый список «Проблемные позиции» со счетчиком и фильтрами.
Акт строится из «текущего состояния». Если кто-то поправил данные после печати, вы не докажете, что было в момент формирования. Акт должен иметь версию, дату и время, автора и снимок данных на момент выпуска.
Перед запуском прогоните тест в условиях, похожих на реальную смену: тот же свет, те же телефоны, тот же интернет.
Проверьте:
Если какой-то пункт не проходит, не усложняйте. Чаще всего помогает одно: меньше экранов и больше подсказок прямо в момент скана.
Представьте поставку с двумя позициями: товар А (100 шт.) и товар Б (50 шт.). Задача приложения - быстро собрать факт, показать расхождения и подготовить акт.
Кладовщик открывает поставку, переходит на сканирование и принимает товар А. По итогам выходит 97 шт. Он фиксирует недостачу и добавляет короткий комментарий: «не хватает 3 шт., пломба целая».
С товаром Б сложнее: часть QR указывает на другой SKU (похожая упаковка). Кладовщик фиксирует, что фактически пришло 45 шт товара Б и 5 шт другого SKU, отмечает пересорт и добавляет пояснение: «вместо Б пришел SKU B2, 5 шт.».
Итог по поставке:
Старший смены открывает спорные строки, проверяет комментарии, при необходимости добавляет решение (например, «принять фактом, выставить претензию») и закрывает поставку. После подтверждения система формирует акт: реквизиты, строки «документ/факт/разница», причины, комментарии, итоги и подписи.
Начните с короткого пилота на живых поставках, где реально встречаются пересорт, недостача и спорные позиции. Подготовьте 10-20 QR-кодов, пару накладных и несколько типовых расхождений. На таком наборе сразу видно, занимает ли приемка секунды или превращается в ручной ввод.
Дальше согласуйте минимальный состав акта, который устраивает компанию: номер поставки, дата, контрагент, позиции, факт, тип расхождения, комментарий, подписи. Споры чаще возникают из-за отсутствующих полей, а не из-за интерфейса.
Если нужен быстрый прототип, TakProsto (takprosto.ai) позволяет собрать веб-приложение через чат и затем развивать его итерациями. Это удобно, когда вы хотите быстро проверить на складе поток «поставка -> позиции -> расхождения», не растягивая разработку на месяцы.
