Почему приемка маркированного товара по количеству перестает работать — и при чем здесь мобильное приложение

Проблема обнаруживается позже: на кассе, при возврате, перемещении между магазинами или инвентаризации. К этому моменту товар уже смешан с остатками, а восстановление истории превращается в разбор документов, переписки и действий нескольких сотрудников.

В этой статье разберем, где ломается процесс приемки маркированного товара, почему одной интеграции с 1С недостаточно и какую часть задачи можно перенести в мобильное приложение.

Типовой процесс выглядит нормально — пока не начинается продажа

Во многих магазинах приемка устроена примерно так:

1. Поставщик привозит товар и передает документы.
2. Сотрудник считает коробки и товарные позиции.
3. Количество сверяется с накладной.
4. Поступление проводится в 1С.
5. Товар отправляется на склад или в торговый зал.

Для обычного количественного учета схема понятна. Для маркированного товара в ней отсутствует важный этап — проверка конкретных Data Matrix.

У одинаковых товаров может быть один артикул, один GTIN, одинаковый размер и цена, но разные коды маркировки. Поэтому 100 единиц в документах и 100 единиц физически могут представлять разные наборы экземпляров.

Например:

1. в документе указано 100 кодов;
2. физически принято 100 товаров;
3. 95 кодов совпали;
4. пяти кодов из документа нет;
5. вместо них приехали пять других кодов того же товара.

По количеству поставка сошлась. Поэкземплярно — нет.

Если приемка выполняется только по номенклатуре и количеству, расхождение остается внутри остатков.

Где обычно обнаруживается ошибка

Проблема редко становится заметна сразу после разгрузки. Чаще она проявляется на следующих этапах.

На кассе

Код не проходит проверку или товар нельзя корректно вывести из оборота. Покупатель уже ждет, а кассир не понимает, почему внешне обычный товар нельзя продать.

При возврате

Покупатель возвращает товар, но код не совпадает с тем, который ожидает учетная система. Сотрудникам приходится вручную разбираться, был ли этот экземпляр продан именно этим магазином.

При перемещении

Один магазин отправил 20 единиц, другой принял 20. Количество сошлось, но часть кодов отличается. Расхождение переносится между подразделениями.

При инвентаризации

Фактически найдено столько же товаров, сколько числится в системе, но набор Data Matrix не совпадает. Количественная ведомость показывает ноль расхождений, а поэкземплярный учет остается неправильным.

Во всех случаях причина могла появиться еще при приемке, но искать ее приходится значительно позже.

Почему проблема не решается только настройкой 1С

Учетная система хорошо работает с документами. Она знает, что должно поступить, от какого поставщика, в каком количестве и по какой цене.

Но она не может самостоятельно определить, что физически лежит в коробке.

Чтобы подтвердить фактическую поставку, кто-то должен находиться рядом с товаром и последовательно проверить каждую единицу.

Если сотрудник работает с бумажной накладной, он обычно отмечает количество. Переписывать Data Matrix вручную бессмысленно: код длинный, одна ошибка делает запись непригодной для сопоставления.

Можно установить стационарное рабочее место со сканером, но тогда возникает другая проблема: товар нужно переносить к компьютеру или организовывать приемку строго в одной зоне.

Поэтому здесь появляется отдельный слой — мобильное рабочее место сотрудника склада или магазина.

Что именно должно попадать в мобильное задание

Мобильное приложение не должно начинать приемку с пустого экрана и предложения «сканируйте все подряд».

Из 1С или другой учетной системы в него передается конкретный документ. Минимальный набор данных:

1. номер и дата поставки;
2. поставщик;
3. магазин или склад;
4. товарные позиции;
5. ожидаемое количество;
6. характеристики товара;
7. GTIN;
8. ожидаемые Data Matrix;
9. изображения товаров, если они помогают различать похожие позиции.

Изображения особенно полезны для одежды и обуви. Сотрудник может отличить модель или цвет до того, как начнет разбираться с кодом.

При этом источником учетных данных остается 1С. Мобильное приложение используется для получения фактического результата.

Как выглядит проверка на месте

Сотрудник открывает документ на смартфоне и сканирует поступающие товары.

После каждого считывания приложение должно сразу определить состояние кода:

1. код ожидается в этой поставке;
2. код относится к другой позиции;
3. код отсутствует в документе;
4. код уже сканировался;
5. код не распознан;
6. маркировка повреждена;
7. товар подтвержден.

Важно показывать результат сразу, а не после завершения всей приемки. Иначе сотрудник сложит спорный товар вместе с подтвержденным, и физическое разделение придется выполнять повторно.

На экране также полезно отображать прогресс:

1. сколько единиц ожидалось;
2. сколько подтверждено;
3. сколько осталось;
4. сколько найдено расхождений.

Это простая функция, но она снижает вероятность преждевременно завершить проверку.

Неизвестный код нельзя автоматически добавлять в приход

Одна из опасных идей при автоматизации — считать любой отсканированный товар фактически принятым.

Если код отсутствует в документе, приложение не знает, почему он появился.

Возможные причины:

1. поставщик положил лишний товар;
2. передан товар из другого заказа;
3. документ сформирован неправильно;
4. исправленный документ еще не поступил;
5. код относится к другой товарной позиции;
6. произошла ошибка при упаковке;
7. данные не полностью загрузились из учетной системы.

Поэтому неизвестный код должен попасть в отдельную группу расхождений.

Дальнейшее решение принимается в 1С или другом учетном контуре: получить исправленные документы, принять дополнительную поставку, вернуть товар либо провести отдельную проверку.

Автоматическое добавление неизвестных кодов ускоряет приемку только на первый взгляд. Фактически оно переносит проблему внутрь учета.

Подтвержденная и спорная часть поставки

Не каждое расхождение должно останавливать всю приемку.

Если из 500 товаров проблемы обнаружены у десяти, остальные 490 можно подтвердить, а спорные экземпляры разместить отдельно.

Для этого мобильное приложение должно формировать как минимум две группы:

Подтвержденные товары — коды совпали с документом и могут участвовать в дальнейшем процессе.

Расхождения — отсутствующие, дополнительные, повторные, поврежденные или неправильно сопоставленные коды.

Такой подход позволяет продолжить работу с основной частью поставки, не смешивая ее с товарами, по которым еще нет решения.

Физически для спорной продукции желательно выделить отдельную зону хранения. Иначе после завершения проверки сотрудники снова перемешают товары.

Почему сканировать GTIN недостаточно

GTIN определяет товарную позицию. Data Matrix идентифицирует конкретный экземпляр.

Если сотрудник сканирует только обычный штрихкод, приложение может понять, что перед ним нужная модель товара. Но оно не сможет определить, тот ли именно экземпляр указан в документах.

Для обычной количественной приемки GTIN подходит. Для поэкземплярной проверки маркированного товара требуется полное значение Data Matrix.

Это важно учитывать при интеграции. Иногда из мобильного приложения в учетную систему передают только извлеченный GTIN, потому что с ним проще работать. В результате внешне процесс выглядит автоматизированным, но контроль конкретных кодов отсутствует.

Повторное сканирование — не мелкая ошибка интерфейса

Во время приемки сотрудник может случайно считать один товар дважды.

Если приложение просто увеличивает количество после каждого сканирования, итог станет неправильным. Особенно сложно заметить ошибку в поставке из нескольких сотен единиц.

Поэтому повторный код должен блокироваться или явно выделяться.

При этом полезно различать:

1. случайное повторное сканирование;
2. одинаковый код на двух физических товарах;
3. повторную проверку уже зарегистрированного расхождения.

Это разные ситуации и требуют разной реакции.

Работа с поврежденной маркировкой

Часть кодов не считывается из-за повреждения упаковки, плохой печати, загрязнения или складки на этикетке.

Плохой сценарий — позволить сотруднику вручную выбрать товар и отметить его как подтвержденный.

Внешне похожий экземпляр может иметь другой Data Matrix. Такая операция снова возвращает процесс к количественному учету.

Более надежный вариант:

1. Повторить сканирование.
2. Попробовать другое устройство или освещение.
3. Зафиксировать товар как проблемный.
4. Добавить фотографию маркировки.
5. Указать комментарий и место хранения.
6. Передать экземпляр на отдельный разбор.

Мобильное приложение в этом случае не решает юридическую или учетную судьбу товара. Оно сохраняет фактическую ситуацию и не дает потерять проблемный экземпляр среди подтвержденных остатков.

Что должно вернуться в 1С

Результатом мобильной приемки не должна быть одна отметка «выполнено».

В учетную систему необходимо передавать структурированные данные:

1. фактически подтвержденное количество;
2. список подтвержденных Data Matrix;
3. отсутствующие коды;
4. дополнительные коды;
5. повторные сканирования;
6. поврежденную маркировку;
7. комментарии;
8. фотографии;
9. дату и время проверки;
10. исполнителя;
11. место приемки.

Дальше учетная система формирует документы и отражает операции по внутренним правилам компании.

Таким образом, мобильное приложение отвечает на вопрос «что фактически приехало», а 1С — «как это оформить».

Какой обмен безопаснее: онлайн или пакетный

Есть два основных варианта.

Онлайн-проверка

Каждый код сразу проверяется через сервер и учетную систему.

Плюсы:

1. сотрудник получает актуальный результат;
2. расхождения обнаруживаются сразу;
3. меньше риск работы с устаревшим документом.

Минусы:

1. требуется стабильная связь;
2. приемка зависит от доступности сервера;
3. увеличиваются требования к скорости обмена.

Загрузка задания и отправка результата

Документ заранее загружается на смартфон, сотрудник выполняет приемку, затем передает результат.

Плюсы:

1. можно работать при нестабильном интернете;
2. сканирование не зависит от задержки сервера;
3. подходит для складов с плохим покрытием.

Минусы:

1. нужно контролировать версии документов;
2. возможен конфликт, если исходные данные изменились во время приемки;
3. требуется продуманная повторная отправка результата.

На практике часто используется смешанная схема: задание хранится локально, а серверная проверка выполняется при наличии соединения.

Какие ошибки делают при внедрении

Автоматизируют только сканирование

Сотрудник считывает коды, но приложение не сравнивает их с документом. В итоге бумажный список заменяется электронным, а контроль не появляется.

Не разделяют подтвержденный и спорный товар

Все сканирования попадают в общий результат. Неизвестный код фактически становится частью прихода.

Передают только количество

В 1С возвращается «принято 100 единиц», но конкретные Data Matrix теряются.

Не учитывают повторные коды

Один товар можно отсканировать несколько раз, а итоговое количество выглядит правильным только случайно.

Не фиксируют исполнителя

После обнаружения проблемы невозможно понять, кто проводил приемку и какие действия выполнялись.

Не предусматривают работу без сети

На складе пропадает связь, и процесс полностью останавливается.

Делают слишком сложный интерфейс

Если для подтверждения каждого товара нужно открыть несколько форм, сотрудники начнут искать обходные пути.

Что мобильное приложение не решает

Мобильное решение не заменяет:

1. договоры и первичные документы;
2. 1С;
3. электронный документооборот;
4. систему маркировки;
5. кассовое программное обеспечение;
6. решения ответственного сотрудника по спорному товару.

Оно также не исправляет автоматически ошибки поставщика и не определяет правовое основание для неизвестного кода.

Задача приложения уже и практичнее: получить достоверный фактический результат непосредственно у товара.

Это важно понимать до внедрения. Иначе от мобильного проекта ожидают, что он полностью «закроет маркировку», хотя он отвечает только за одну часть процесса.

Где здесь QR Inventory

В проекте QR Inventory мобильное приложение рассматривается как рабочее место сотрудника магазина или склада.

Из 1С передается приходная накладная, товарные позиции, GTIN, Data Matrix и изображения товаров. Сотрудник выполняет сканирование и видит расхождения во время приемки.

Подтвержденный результат возвращается в 1С. Товары, которых не было в исходном документе, не добавляются автоматически — дальнейшая работа с ними продолжается в учетной системе.

Такая архитектура сохраняет привычное разделение:

1. 1С управляет документами и учетом;
2. мобильное приложение фиксирует фактическую поставку;
3. сотрудник принимает решения по расхождениям;
4. история проверки сохраняется вместе с исполнителем, датой и фотографиями.

Как оценить, нужен ли такой процесс бизнесу

Мобильная приемка дает наибольший эффект, если одновременно выполняются несколько условий:

1. в поставке много маркированных единиц;
2. товары внешне похожи;
3. приемка выполняется вдали от компьютера;
4. есть несколько магазинов или складов;
5. расхождения часто обнаруживаются после проведения документа;
6. сотрудники тратят время на повторные сверки;
7. возникают проблемы при продаже, возврате или инвентаризации;
8. необходимо сохранять фотографии и историю приемки.

Если поставки небольшие и проверяются на стационарном рабочем месте, отдельное мобильное решение может оказаться избыточным.

Автоматизация имеет смысл не из-за самого наличия Data Matrix, а когда текущий процесс создает заметные ошибки, задержки или повторную работу.

Вывод

Главная проблема приемки маркированных товаров состоит не в сканировании кода. Считать Data Matrix умеют многие устройства и приложения.

Сложность заключается в построении процесса:

1. получить ожидаемые данные из учетной системы;
2. проверить каждый фактический экземпляр;
3. сразу показать расхождение;
4. не смешать спорный товар с подтвержденным;
5. сохранить доказательства;
6. передать структурированный результат обратно;
7. не выполнять за сотрудника учетные решения, для которых недостаточно данных.

Мобильное приложение здесь полезно не как замена 1С, а как промежуточный слой между физической поставкой и учетным документом.

Оно позволяет обнаружить расхождение в момент, когда товар еще находится в зоне приемки, а не через несколько недель на кассе или во время инвентаризации.