тема от разработчиков СМ+: поштучный ЕГАИС в реальной жизни : Супермаг Плюс (Супермаг 2000)

По придуманной РАРом методике при приёмке алкогольной продукции , учтённой поштучно, предусмотрен вариант с расхождениями. В этом случае в акте расхождения нужно будет указать те PDF, которые не получены.
Т.е. если отправлено 1000 единиц продукции, а получено по факту 999, то для выявления кода недостающей бутылки нужно будет прощёлкать сканером 999 бутылок.
По моему предположению этого никто делать не будет. Поэтому сценарий с актом расхождения должен быть исключён в принципе, как нереализуемый в реальной жизни. Останется варианты: принять всё или отказать. Если отказать, то пусть поставщик разбирается с ТТН, переделывает её, ищет недостающие коды и пр.

Что думают пользователи по данному вопросу ? Прошу активно высказываться по существу..., а не отмалчиваться. Возможно, по высказанным предложениям организуем голосование.

А разве все 1000 бутылок не надо будет сканировать в любом случае, чтобы проверить, правильно ли поставщик указал номера марок?

Если товар физически есть, но магазин отказывается принять одну бутылку по каким-то причинам, то эту бутылку проще считать и указать в акте расхождения.
Если бутылка разбилась при перевозке, то тоже есть вероятность получить штрих-код марки.
Ситуацию, когда поставщик забыл положить бутылку, и ее нет от слова "совсем", в природе не встречала.

Хорошо, так и запишем.
Вариант 1. Принуждение к обязательному сплошному сканированию кодов PDF до тех пор пока данные не сойдутся. Необязательность сканирования в этом случае EAN, чтобы убыстрить процесс, обсуждается.

Какие ещё будут предложения?

Александр предлагает замордовать приемщиков цикличностью поиска :) Как всегда ерничает.

Есть еще вариант, бутылку украли в процессе транспортировки.
Есть варианты подмены контрафактом, есть варианты дублирования номеров марок (причем поставки с одного и того же завода).
Поэтому даже при полном совпадении кол-ва, сканировать/проверять придется все.

Но вариант забить и сверять только кол-во по головам забавный, а далее принимать или не принимать, его нужно тоже оставить, для самых "опытных" и доверчивых. Ну а если серьезно, то вариант алкогольный завод/экспортер со своей сетью алкогольных магазинов (правая рука передает левой, а организм один), наверное вариант приемки вслепую по головам будет приемлем. Только насколько знаю, таких на СМ+ нет, но если думать о перспективе, то да.

Еще. Насколько я понимаю, эти 1000 бутылок будут сложены в коробки по X штук.
Поставщик должен коробки сложить на паллеты и промаркировать (и паллеты, и коробки).
И указать это дерево коробок в накладной.

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

Весь приход сканим помарочно (в сторонний софт) практически с введения ЕГАИС. Начальник ВЦ так решил, и видимо был прав.

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

Тогда при получении файла ТТН 3-го формата будем требовать обязательного ввода массива кодов по каждой позиции ТТН.
Если придёт поштучная продукция, то ввод всех кодов будет нужен для подсчёта и проверки.
Если придёт партионная продукция (без кодов), то результаты сканирования используем для "привязки цифровых идентификаторов к уже существующей партии".

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

Для "ленивых" сделаем функцию признания присланных кодов по поштучной продукции без проверки. Если поставщик прислал поштучную продукцию и перечислил

Если у кого-то появится бизнес-процесс маркировки упаковок и паллет разными sscc кодами, то можно будет от сканирования бутылок перейти к сканированию упаковок.

(Следует оговориться, что никто пока не знает, как сам ЕГАИС будет отрабатывать привязку. )

Да, что-то не густо предложений...

Голосования не получится.

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