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

Потому, например, что реально это более трудоемкая задача, чем наладить просто обмен текстовыми файлами.
Ты вот поминал поставщика, который в здравом уме не будет силами своего ИТ делать выгрузку в XML...
А делать печать двумерных кодов ему будет проще?

Вот выгрузить текстовый файл с артикулом, ценой и количеством сможет почти кто угодно.
Принять его напрямую в СМ или перегнать в XML уже на своей стороне - задача не архисложная.
Да еще и решаемая без участия С+ (если уж неспешность нервирует).

А потом еще надо будет геройски решать проблемы, которые Mtirt озвучила.

Коллеги!
Понятно, что любая вновь появившаяся технология зачастую кажется нам заведомо "избыточной". Т.к. нам привычнее обходиться именно "привычными инструментами". А многое из того, что непривычно,
как раз и кажется какими-то малопотребными костылями, какими-то лишними заморочками и т.д. и т.п.
Это вполне естественно. Все мы - люди, и я сам - "такой же": считаю (до поры-до времени), что "всё лучшее - враг хорошего" (автора этой фразы, увы, не помню)...
Да, понятно, что самый "идеальный", так сказать, способ обмена данными между двумя контрагентами - способ электронный. Хоть через EDI, хоть через простейшие текстовые файлы. Но это означает в таком случае,
что "некто" должен будет принять на себя постоянную (!) работу - и, следовательно, регулярно оплачивать её - по поддержке некоторого "сихронизирующего софта", который при необходимости должен будет оперативно модернизироваться в случае существенных изменений учётных софтов либо на передающей стороне,
либо на принимающей. В последнем случае это система СМ-2000, документация к которой традиционно "подзапаздывает" относительно выхода новых версий и подверсий.
Т.о. вариант чисто программной синхронизации представляется, откровенно говоря, практически НЕреальным.
Т.е. совсем не случайно, как говорит наш модератор, эта идея и призатухла ещё в самом "начале времён" )
Возможно, выборка моя весьма не полна, но мне лично известны только 2 (два) случая относительно успешной синхронизации на "программном уровне". Первый пример - сеть "Седьмой континент", которая ещё 2 с лишним года назад ()
стала категорически навязывать всем своим поставщикам вполне конкретную софтину собственной разработки,
выгружающую из себя расходную накладную поставщика в формате, понятном бэк-офисной системе "7-го континента".
Второй пример - "Мосмарт": тот вообще в упор не желает видеть никаких документов от поставщика, а принимает поставку товаров в свои магазины сугубо по своему же предварительно сделанному
ему - поставщику - заказу (и никак НЕ иначе!).
Кроме того, чем ещё (в наших реалиях) "плох" вариант исключительно электронного документооборота в управленческом, если так можно выразиться, аспекте?
1. С точки зрения "розницы" принимать файлы накладных от поставщика по мэйлу - это значит иметь (в общем случае - круглосуточно) в каждом магазине специально уполномоченного сотрудника,
которому только и доступен выход в Интернет; иначе минимум половина компьютернограмотных сотрудников магазина будет хронически сидеть на порносайтах и на прочих "развлекаловках", а за трафик-то этот придётся регулярно платить.
2. А с точки зрения поставщика передача файлов на флэшках и прочих подобных носителях тоже затратна: экспедиторы/водители будут "терять" их по несколько штук в неделю в расчёте на каждого покупателя/сеть
(типа, "маленькие они", "из карманов выпадают", "забыл в магазине" и т.п.) - т.е. тоже сплошной источник постоянного "разорения", покуда все родственники экспедиторов не наедятся этими самыми "носителями".
А при известной текучести кадров малооплачиваемых сотрудников
данная статья расходов на МБП будет именно "хронической"...

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

Специализированные сканеры двумерных штрихкодов, кстати, нынче не столь уж и дороги: что-то около 450 баксов за девайс (в розницу!) производства Metrologic - а это всего лишь месячная стоимость одного оператора магазина на вводе накладных с учётом его зарплаты,
отчислений в ПФ РФ, тех двух кв.м., на которых он сидит, и т.д. и т.п.
Некоторые сканеры линейных штрихкодов, действительно, потенциально умеют читать двумерные штрихкоды, но пользоваться ими для этих целей... Ну просто не серьёзно. Если откровенно.
Не зря ж ведь "Mtirt" так о них (именно о них?) соответственно и отозвалась... Если же речь была о них, "линейных сканерах", то я её хорошо понимаю.

И ещё вот о чём не могу не сказать: вы, коллеги, по-видимому, просто не совсем понимаете пока существа самой "идеологии" двумерного штрихкодирования. А это, поверьте, ОЧЕНЬ даже мощный "инструмент".

Абсолютно без разницы, например, в каком именно порядке оператор магазина будет эти "штрихи" сканировать. Ну, допустим, пропустит он самый первый штрихкод, в котором закодирован заголовок накладной,
а все остальные будут им отсканированы успешно. Ну и что "страшного"?
Система СМ-2000 сообщит оператору (после своей предполагаемой доработки, разумеется), что спецификация "принята", а вот "заголовка", увы, нет. Ну, значит, оператор магазина отсканирует этот самый "первый штрихкод" повторно. Только-то и всего...

Ещё раз повторю: привычные операции по фактической приёмке товаров ОТНЮДЬ НЕ ИСКЛЮЧАЮТСЯ. Я предлагаю исключить лишь процесс создания черновика приходной накладной в системе СМ-2000.
А затем пользуйтесь хоть технологиями Мосмарта, хоть иными другими...

Поставщикам товаров в ваши сети ГК С+ может предложить для использования и софты собственной разработки,
и других производителей, умеющих печатать двумерные коды в разных кодировках - Aztec, QR Code и т.д.

Спасибо за внимание, уделённое вами моим письмам !

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

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

какая информация, как тебе кажется, должна быть закодирована в этом ШК?
заголовок пока пропустим. хотя там тоже есть про что подумать, ну да бог с ним...

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

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

кстати, глубоко пофигу: делать ставку на двумерные ШК или, к примеру, линейные Code128. те же яйца, только в профиль.

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

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

1. Повторю ещё раз: я даже и не надеюсь на охват хотя бы половины поставщиков из тех нескольких сотен, которые имеются у каждой торговой сети. Я ведь и писал про максимум в 20-25% "устойчивых поставщиков". Это именно те поставщики, с которыми у сети сложились нормальные стабильные партнёрские отношения, с которыми имеются одинаковые взгляды на "арифметическое соответствие цена-налоги-количество-сумма", на работу с номенклатурой товаров и т.п. аспекты, и которые не устраивают особой чехарды с собственными артикулами: например, не переприсваивают артикулы "старых" товаров, вышедших из ассортимента, каким-то новым товарам, недавно вошедшим в ассортимент поставщика. В своих предложениях я как раз и закладывался на уже имеющуюся в СМ-2000 возможность работы с "артикулами поставщиков". Но имел в виду отнюдь НЕ ВСЕХ поставщиков, а только "устойчивых". За счёт ускорения работы с которыми можно выделить больше времени на разборки конфликтов с прочими "мутными" поставщиками. Причём я имел в виду поставщиков
не просто "устойчивых", но ещё и лояльных к требованиям/пожеланиям сети: ведь подать информацию на вход упоминавшимся мной софтинам, которые умеют печатать двумерные штрихкоды, можно только в определённом формате (в одном случае - XML (НЕ супермажный!), в другом случае - текстовый с разделителями), т.е. программерам данных поставщиков ещё придётся написать выгрузку накладных из своих учётных систем в каком-то из этих форматов.
2. Увы, нет, CODE128 - это совсем не те же яйца. Сколько информации можно засунуть в такой код ? Всего лишь одну строку спецификации документа - "артикул, количество, цена, ндс, сумма, срок годности,
страна-производитель, гтд, сертификат". В двумерный же код поместится не строка, а страница документа. Разница, согласитесь, ощутимая - одним сканированием загнать в черновик накладной сразу 25-30 строк.

про какие софтины речь идет, если не секрет?
как их можно пощупать? демо-версии есть?

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

Только еще раз повторю, магазин принимает не документ, каким бы образом он ни был сформирован, магазин принимет товар.
Тогда уж лучше маркировать упаковку товара этикетокой со штрих-кодом с избыточной информацией - количеством, ценой, сроком годности, № ГТД и т.п., всем тем, что выше перечислял Конев. И принимать терминалом сбора данных, понимающим эту строчку. Тогда и точность приемки будет практически абсолютная, и операторов можно увольнять почти всех.
Единственное, предусмотреть в терминале возможность сверки информации упаковки товара с единицей товара, а то поставщики тоже люди, этикетки тоже легко могут перепутать.

1.

2.

В последнем случае развёрнутого описания функционала софта пока нет в виду некоторой задержки с обновлением информации на сайте.

Демоверсий нет. Так что просто "пощупать" пока не получится.

Ответ Mtirt.


Готового ПО для ТСД "DENSO BHT 2XX Q" и "PSC Falcon 4X00 2D Imager", которое умело бы выполнять такую задачу, в С+ пока нет. Надо писать.
Таким образом, задача для С+ усложняется: следует не только научить СМ-2000 читать 2D коды, но ещё и разработать спецПО для ТСД. Задача вполне посильная, но наши коммерческие командиры сначала должны почувствовать определённый материальный интерес к её решению. Т.е., грубо говоря, на примере, допустим, "Матрицы" им, я думаю, интересно было бы узнать, сколько (примерно) таких ТСД будет готова купить сеть (при своих нынешних размерах) и сколько (примерно) поставщиков она уговорит на приобретение принтеров маркировочных этикеток - разумеется, в С+ )

Фальконов у меня уже десаток есть, на РЦ.
Насчет поставщиков - могу рассматривать только как шутку.