Учёт вендинга: план пополнения и фактическая загрузка

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

Ниже предложена модель программы для пополнения торговых автоматов. Это не инструкция по эксплуатации, хранению продуктов, фискальным операциям или финансовому учёту. Величины и аппараты в примере вымышлены. Подключение конкретной телеметрии и оборудования требует отдельной проверки доступных данных. Основная задача — объяснить движение товара между маршрутом и точками без подмены намерения фактом.

Начните с возврата после маршрута

Представим условный маршрут Р-8 с двумя аппаратами А и Б. Для одного учебного товара подготовлено двадцать единиц: двенадцать планировали для А и восемь для Б. По факту сотрудник загрузил десять и шесть. Четыре единицы вернулись. Программа должна объяснять эти четыре через события маршрута, а не считать их неизвестным излишком склада.

Если сразу при подготовке списать двадцать в аппараты по плану, остатки окажутся завышенными: на А — на две единицы, на Б — ещё на две. Если возвращённые четыре затем оприходовать как новую поставку, история станет ещё запутаннее. Правильный для предлагаемой модели вопрос: какие количества реально прошли каждый этап и с чем связана оставшаяся часть.

Здесь 20 = 10 + 6 + 4. Это проверка искусственного количественного примера. Она не подтверждает качество товара, условия его дальнейшего использования или корректность обязательных документов. Если есть другие движения, они требуют собственных записей; арифметическое совпадение не даёт права скрыть их внутри одной поправки остатка.

План нужен подготовке, а не доказательству посещения

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

У каждой позиции укажите единицу. Коробка и отдельная единица товара не должны попадать в одно поле без согласованного пересчёта. Если конкретные упаковки имеют разный состав, модель нужно уточнить до реализации. Не используйте одинаковый коэффициент по привычке сотрудника, если источник данных его не подтверждает.

Изменение порядка посещения не должно само по себе менять количество. А изменение состава маршрута не обязано означать отмену потребности точки. Сотрудник должен видеть причину и следующее действие: переназначить, уточнить или закрыть конкретную задачу по принятому процессу. Один статус «маршрут изменён» не объясняет судьбу каждой товарной строки.

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

У маршрута может быть отдельный количественный остаток выездной команды. Для него фиксируют получение, фактическую передачу на точки и возвращённое количество. Это предложенная операционная модель, а не универсальное название бухгалтерского склада. Её ценность — возможность объяснить, где находится товар между подготовкой и завершением выезда.

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

Отдельно рассмотрите передачу товара между выездными сотрудниками. Если такой процесс разрешён, он связывает два маршрута и не увеличивает общий запас автоматически. Для первой версии можно запретить этот путь или оставить его ручному согласованию. Главное — не делать вид, что исключение отсутствует, если сотрудники регулярно используют его в работе.

На точке подтверждают конкретный аппарат и состав

Экран выезда должен явно показывать выбранный аппарат и его адресное обозначение. Два устройства на одной площадке не стоит различать только свободным комментарием. Пользователь подтверждает загрузку определённой позиции в определённый объект. Если перепутать аппараты, суммарное количество маршрута может сойтись, но данные каждой точки останутся неверными.

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

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

Телеметрия и посещение не обязаны сообщать одно и то же

Если аппарат передаёт данные, сначала определите их назначение: продажи, наблюдаемый запас, сообщение о состоянии или подтверждение операции. Наличие интеграции само по себе не объясняет, как из неё получается остаток. Разработчику нужны описание источника и учебные сообщения с ожидаемой обработкой.

Не принимайте запоздавший снимок запаса за свежее подтверждение ручной загрузки. Для сопоставления должны быть известны времена, область данных и правила разрешения расхождений. В статье о пересчёте товара рассматривается момент сравнения. Здесь важно сохранить самостоятельность события загрузки и наблюдения внешней системы.

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

Непереданный результат остаётся открытой работой

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

Для этого сценария заранее определите, как узнаётся одна и та же операция и кто вправе её исправлять. Удаление ошибочного сообщения без истории усложнит завершение маршрута. Лучше сохранить понятное изменение и причину. Подробная реализация зависит от выбранного клиента; сама форма ввода числа не гарантирует корректную работу без связи.

В завершении выезда покажите открытые вопросы по позициям и точкам. Маршрут нельзя считать полностью разобранным только потому, что сотрудник вернулся. Для учебных двадцати единиц нужно объяснение всех количеств. Если часть пока не установлена, она остаётся видимой с ответственным и следующим действием, не превращаясь в автоматический возврат.

Проверка перед запуском

На демонстрации пройдите таблицу: подготовьте двадцать, подтвердите передачу, загрузите десять и шесть, верните четыре. Затем повторно отправьте первое событие загрузки и убедитесь, что количество не выросло. Поменяйте порядок точек и проверьте сохранность назначений. Добавьте замену артикула и нулевой результат с причиной.

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