О двумерных штрихкодах : Супермаг Плюс (Супермаг 2000)

Коллеги.
Хотелось бы услышать ваши мнения относительно следующего вопроса. Есть идея воспользоваться двумерными штрихкодами (см., например, ) для ускорения создания в СМ-2000 черновика приходной накладной.
Исходим из того, что поставщик товаров в магазины торговой сети имеет необходимые программые и аппаратные средства для того, чтобы распечатывать двумерные штрихкоды определённой системы, в которых кодируется содержимое его расходной накладной (или счёта-фактуры), например, по одному штрихкоду на каждую станицу накладной. Эти штрихкоды наклеиваются на отдельные чистые листы бумаги, чтобы не портить первичку, оформленную по стандартам ТОРГ-хх. И вручаются экспедитору поставщика вместе с этой самой первичкой.
Кроме того, исходим из того, что система СМ-2000 "будет обучена" работе с двумерными штрихкодами, а в магазине будет иметься специализированный сканер двумерных штрихкодов.
Ещё одно допущение: артикулы поставщика меняются не слишком часто (не номенклатура, а именно артикулы)
Оператор магазина, последовательно сканируя двумерные штрихкоды из нового "приложения к накладной", быстро создаёт заголовок и спецификацию приходной накладной. Фактическая же приёмка товара может осуществляться в дальнейшем с использованием традиционных сканеров и терминалов сбора данных. Кроме того, в СМ-2000 ещё потребуется "подкрутить" некоторые проверки и механизмы, связанные с документами типов "заказ поставщику" и "контракт с поставщиком", которые срабатывают при оформлении приходной накладной на их "основе".
Такая вот идея. Целесообразно ли её реализовывать в СМ-2000 ?

Я аналогичную тему уже пытался поднимать на заре существования этого форума, а именно - создание унифицированной системы, позволившей бы создавать и обмениваться электронными накладными. Идея с треском провалилась, по каким причинам - можно поискать посмотреть. Не упирался ввиду апатичности реакции на предложение. Суть предложения не в двумерности, а в том, что потребуется некая связующая между поставщиком и магазином, общая база, что даже при наличии одинакового софта и ассортимента практически исключено, даже при наличии второго твоего допущения базу необходимо контролируемо привязать одну базу к другой. Я даже было взялся за реализацию унифицированной базы, но опять же апатия присутствующих привела к тому, что все было заброшено. Твоя же идея отличается только тем, что для нее еще потребуется софт печати, поддерживающий разнообразие софта поставщика и (или) ручной ввод, этикетки и железка для чтения.
Поэтому, думаю, не стОит заморачиваться. Либо сначала озаботиться созданием веб-сервиса объединения баз с учетом транспортировки необходимых данных до него и по модемным/емейл-транспортам.

Я по своему скудоумию конечно могу не понимать всей сути вопроса, но проблема однозначной идентификации товара решается ведь с помощь ШТРИХКОДА ПРОИЗВОДИТЕЛЯ , а артикулы поставщика и магазин могут с колько угодно разными и никакая обшая база тут не нужна. (Если где то не прав раскачайте пожалуста, потому что тема реально интересная.)

Целая куча товара немаркирована, куча практически разово появляющегося товара, много товара, появляющегося в первый раз именно от поставщика. Читай https://olegon.ru/showpost.php?p=6395&postcount=48, это как пример.

идея, безусловно, интересная...

надо только убрать из нее двумерные ШК вместе с железками :)
какой смысл во всей этой фурнитуре, если задача _передачи_ накладной имеет множество более простых решений от почты до флешки в кармане экспедитора?

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

Мля...
Покажите-ка мне хотя бы одного поставщика любой торговой сети, который, будучи "в здравом уме и твёрдой памяти", согласится писать силами своего ИТ-отдела ту самую "выгрузку" из своей учётной системы в специфическом "XML-формате", который только и "разумеет" на входе система СМ-2000 ?

Это не аргумент.
Можно попросить поставщика выгрузить туда, куда он может и загружать его данные.

Не понял, к чему это ты. Выгрузка/загрузка - значительно более простые задачи, чем поиск этой самой связующей, которой бы мог быть ш/к, если бы не куча проблем с этим связанных. Из какого формата загрузить в СМ не имеет значения, хоть из Excel, хоть из простого текстового файла. Было бы согласие, я бы конструктор для практически любого формата собрал, это просто. И XML-формат значительно проще, чем тот забубенный, что делает 1С. Вопрос в объединении описания товара поставщика и магазина. Силами одного человека или какой-либо разовой дописки к СМ эта задача нерешаема.

1. Ни на чём НЕ настаиваю.
2. НИКОГО НЕ хотел и НЕ хочу обидеть. Не приведи, Господь, что называется... )
3. Затеял весь этот "базар" про двумерные штрихкоды исключительно по одной простой причине: хорошо знаю, сколь трудоёмка операция ввода спецификации ("тела") приходных накладных в магазине (сетевой он или нет - это совершенно НЕ важно), затем я несколько месяцев назад вообще "познакомился" с темой "двумерных штрихкодов", а пару-тройку месяцев назад увидел, насколько эффективен документооборот с их использованием на примере Гознака и Федеральной таможенной службы (ФТС), где над этими самыми "темами" поработали разные сотрудники и службы ГК С+.
Вот отсюда-то и родился мой исходный вопрос. Т.е. мне показалось (или "померещилось" ?), что торговым сетям уровня Матрицы, Монетки, оскольского Провианта или сибирского Кожемякина вполне по силам заставить/продавить хотя бы какую-то часть (ну, допустим, хотя бы 20-25%) своих поставщиков хоть в малой степени пойти навстречу своим клиентам-ритейлерам в отношении упрощения ввода теми "первички" при обмене документами между двумя юрлицами ("продавец-покупатель"). Магазинным операторам в этом уже было бы куда легче
Двумерные штрихкоды, как мне показалось/"померещилось", это совершенно идеальный "инструмент". Ведь с атрибутикой "артикул поставщика" система СМ-2000 ДАВНО уже умеет работать.
Главное - наладить хоть какой-нибудь "интерфейс" между учётными системами поставщиков и Супермагом. Причём желательно такой, который бы минимизировал трудозатраты на его реализацию. Как со стороны различных поставщиков, так и, ПРЕЖДЕ ВСЕГО, со стороны С+. У нас ведь многое "небыстро".
Например, "двумерный интерфейс"... Почему бы и нет ?

Я лично в текущий момент не буду связываться с этим, потому что:
1. Это ненадежно. Что будет, если оператор считает штрих-кода не в том порядке? А еще, на примере алкоголя видно, что эти штрих-кода отдично стираются...
2. Это дорого. Стоимость одного сканера, читающего двумерные штрихкода достаточно велика. Причем надежного чтения мне добиться и не удалось... Ну ладно, это скорее отзыв о моих способностях.
3. Это не нужно. Торговая сеть принимает факт поставки. Физически товар, а не бумажную, электронную, штрих-кодовую накладную. Представляете, как "весело" будет опратору искать товар, если поставщик наклеил товар, соотвествующий одному товару, а отгрузил другой? А как "весело" будет магазину, если этот товар просто пропустят и он попадет в торговый зал?

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