[ОТВЕТИТЬ]
08.05.2007 21:18
victor
 
Коллеги.
Хотелось бы услышать ваши мнения относительно следующего вопроса. Есть идея воспользоваться двумерными штрихкодами (см., например, ) для ускорения создания в СМ-2000 черновика приходной накладной.
Исходим из того, что поставщик товаров в магазины торговой сети имеет необходимые программые и аппаратные средства для того, чтобы распечатывать двумерные штрихкоды определённой системы, в которых кодируется содержимое его расходной накладной (или счёта-фактуры), например, по одному штрихкоду на каждую станицу накладной. Эти штрихкоды наклеиваются на отдельные чистые листы бумаги, чтобы не портить первичку, оформленную по стандартам ТОРГ-хх. И вручаются экспедитору поставщика вместе с этой самой первичкой.
Кроме того, исходим из того, что система СМ-2000 "будет обучена" работе с двумерными штрихкодами, а в магазине будет иметься специализированный сканер двумерных штрихкодов.
Ещё одно допущение: артикулы поставщика меняются не слишком часто (не номенклатура, а именно артикулы)
Оператор магазина, последовательно сканируя двумерные штрихкоды из нового "приложения к накладной", быстро создаёт заголовок и спецификацию приходной накладной. Фактическая же приёмка товара может осуществляться в дальнейшем с использованием традиционных сканеров и терминалов сбора данных. Кроме того, в СМ-2000 ещё потребуется "подкрутить" некоторые проверки и механизмы, связанные с документами типов "заказ поставщику" и "контракт с поставщиком", которые срабатывают при оформлении приходной накладной на их "основе".
Такая вот идея. Целесообразно ли её реализовывать в СМ-2000 ?
08.05.2007 23:13
OlegON
 
Я аналогичную тему уже пытался поднимать на заре существования этого форума, а именно - создание унифицированной системы, позволившей бы создавать и обмениваться электронными накладными. Идея с треском провалилась, по каким причинам - можно поискать посмотреть. Не упирался ввиду апатичности реакции на предложение. Суть предложения не в двумерности, а в том, что потребуется некая связующая между поставщиком и магазином, общая база, что даже при наличии одинакового софта и ассортимента практически исключено, даже при наличии второго твоего допущения базу необходимо контролируемо привязать одну базу к другой. Я даже было взялся за реализацию унифицированной базы, но опять же апатия присутствующих привела к тому, что все было заброшено. Твоя же идея отличается только тем, что для нее еще потребуется софт печати, поддерживающий разнообразие софта поставщика и (или) ручной ввод, этикетки и железка для чтения.
Поэтому, думаю, не стОит заморачиваться. Либо сначала озаботиться созданием веб-сервиса объединения баз с учетом транспортировки необходимых данных до него и по модемным/емейл-транспортам.
10.05.2007 06:47
reddevil
 
Я по своему скудоумию конечно могу не понимать всей сути вопроса, но проблема однозначной идентификации товара решается ведь с помощь ШТРИХКОДА ПРОИЗВОДИТЕЛЯ , а артикулы поставщика и магазин могут с колько угодно разными и никакая обшая база тут не нужна. (Если где то не прав раскачайте пожалуста, потому что тема реально интересная.)
10.05.2007 07:44
OlegON
 
Целая куча товара немаркирована, куча практически разово появляющегося товара, много товара, появляющегося в первый раз именно от поставщика. Читай https://olegon.ru/showpost.php?p=6395&postcount=48, это как пример.
10.05.2007 08:07
akonev
 
идея, безусловно, интересная...

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

тогда остается только задача синхронизации справочников поставщика и получателя между собой, но это уже совсем другая тема
10.05.2007 12:21
victor
 
Мля...
Покажите-ка мне хотя бы одного поставщика любой торговой сети, который, будучи "в здравом уме и твёрдой памяти", согласится писать силами своего ИТ-отдела ту самую "выгрузку" из своей учётной системы в специфическом "XML-формате", который только и "разумеет" на входе система СМ-2000 ?
10.05.2007 12:24
Mtirt
 
Это не аргумент.
Можно попросить поставщика выгрузить туда, куда он может и загружать его данные.
10.05.2007 12:29
OlegON
 
Не понял, к чему это ты. Выгрузка/загрузка - значительно более простые задачи, чем поиск этой самой связующей, которой бы мог быть ш/к, если бы не куча проблем с этим связанных. Из какого формата загрузить в СМ не имеет значения, хоть из Excel, хоть из простого текстового файла. Было бы согласие, я бы конструктор для практически любого формата собрал, это просто. И XML-формат значительно проще, чем тот забубенный, что делает 1С. Вопрос в объединении описания товара поставщика и магазина. Силами одного человека или какой-либо разовой дописки к СМ эта задача нерешаема.
11.05.2007 13:11
victor
 
1. Ни на чём НЕ настаиваю.
2. НИКОГО НЕ хотел и НЕ хочу обидеть. Не приведи, Господь, что называется... )
3. Затеял весь этот "базар" про двумерные штрихкоды исключительно по одной простой причине: хорошо знаю, сколь трудоёмка операция ввода спецификации ("тела") приходных накладных в магазине (сетевой он или нет - это совершенно НЕ важно), затем я несколько месяцев назад вообще "познакомился" с темой "двумерных штрихкодов", а пару-тройку месяцев назад увидел, насколько эффективен документооборот с их использованием на примере Гознака и Федеральной таможенной службы (ФТС), где над этими самыми "темами" поработали разные сотрудники и службы ГК С+.
Вот отсюда-то и родился мой исходный вопрос. Т.е. мне показалось (или "померещилось" ?), что торговым сетям уровня Матрицы, Монетки, оскольского Провианта или сибирского Кожемякина вполне по силам заставить/продавить хотя бы какую-то часть (ну, допустим, хотя бы 20-25%) своих поставщиков хоть в малой степени пойти навстречу своим клиентам-ритейлерам в отношении упрощения ввода теми "первички" при обмене документами между двумя юрлицами ("продавец-покупатель"). Магазинным операторам в этом уже было бы куда легче
Двумерные штрихкоды, как мне показалось/"померещилось", это совершенно идеальный "инструмент". Ведь с атрибутикой "артикул поставщика" система СМ-2000 ДАВНО уже умеет работать.
Главное - наладить хоть какой-нибудь "интерфейс" между учётными системами поставщиков и Супермагом. Причём желательно такой, который бы минимизировал трудозатраты на его реализацию. Как со стороны различных поставщиков, так и, ПРЕЖДЕ ВСЕГО, со стороны С+. У нас ведь многое "небыстро".
Например, "двумерный интерфейс"... Почему бы и нет ?
11.05.2007 13:23
Mtirt
 
Я лично в текущий момент не буду связываться с этим, потому что:
1. Это ненадежно. Что будет, если оператор считает штрих-кода не в том порядке? А еще, на примере алкоголя видно, что эти штрих-кода отдично стираются...
2. Это дорого. Стоимость одного сканера, читающего двумерные штрихкода достаточно велика. Причем надежного чтения мне добиться и не удалось... Ну ладно, это скорее отзыв о моих способностях.
3. Это не нужно. Торговая сеть принимает факт поставки. Физически товар, а не бумажную, электронную, штрих-кодовую накладную. Представляете, как "весело" будет опратору искать товар, если поставщик наклеил товар, соотвествующий одному товару, а отгрузил другой? А как "весело" будет магазину, если этот товар просто пропустят и он попадет в торговый зал?

Мое мнение - лучше работать над мобилизацией приемки товара, продажи товара, но не искать способа загнать накладную в систему с помощью "костылей".
11.05.2007 15:28
akonev
 
Цитата:
victor ...
Главное - наладить хоть какой-нибудь "интерфейс" между учётными системами поставщиков и Супермагом
Например, "двумерный интерфейс"... Почему бы и нет ?
Потому, например, что реально это более трудоемкая задача, чем наладить просто обмен текстовыми файлами.
Ты вот поминал поставщика, который в здравом уме не будет силами своего ИТ делать выгрузку в XML...
А делать печать двумерных кодов ему будет проще?

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

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

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

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

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

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

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

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

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

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

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

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

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

кстати, глубоко пофигу: делать ставку на двумерные ШК или, к примеру, линейные Code128. те же яйца, только в профиль.
12.05.2007 10:53
inna
 
Кстати действительно проблема стыковки артикулов вещь непростая. Зачастую получается связь между таблицами типа "многие ко многим", что на программном уровне реализуется тяжело.
12.05.2007 16:39
victor
 
В прежнем своём посте я как бы "попрощался", т.к. предполагал, что поднятую тему мы вроде бы "прикрыли". Однако из последних откликов стало очевидно, что понят я был не до конца.
Поэтому не могу удержаться от дополнительных уточняющих реплик.

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

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

2.

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

Демоверсий нет. Так что просто "пощупать" пока не получится.
14.05.2007 17:36
victor
 
Ответ Mtirt.


Готового ПО для ТСД "DENSO BHT 2XX Q" и "PSC Falcon 4X00 2D Imager", которое умело бы выполнять такую задачу, в С+ пока нет. Надо писать.
Таким образом, задача для С+ усложняется: следует не только научить СМ-2000 читать 2D коды, но ещё и разработать спецПО для ТСД. Задача вполне посильная, но наши коммерческие командиры сначала должны почувствовать определённый материальный интерес к её решению. Т.е., грубо говоря, на примере, допустим, "Матрицы" им, я думаю, интересно было бы узнать, сколько (примерно) таких ТСД будет готова купить сеть (при своих нынешних размерах) и сколько (примерно) поставщиков она уговорит на приобретение принтеров маркировочных этикеток - разумеется, в С+ )
14.05.2007 18:08
Mtirt
 
Фальконов у меня уже десаток есть, на РЦ.
Насчет поставщиков - могу рассматривать только как шутку.
15.05.2007 10:18
deucel
 
Цитата:
Mtirt Торговая сеть принимает факт поставки.
Согласен, на текущий момент оптимальный вариант - ТСД (с учетом возможностей использовать для инвентаризаций и т.д.)
16.05.2007 13:39
baggio
 
Цитата:
victor Коллеги!
1. С точки зрения "розницы" принимать файлы накладных от поставщика по мэйлу - это значит иметь (в общем случае - круглосуточно) в каждом магазине специально уполномоченного сотрудника,
которому только и доступен выход в Интернет; иначе минимум половина компьютернограмотных сотрудников магазина будет хронически сидеть на порносайтах и на прочих "развлекаловках", а за трафик-то этот придётся регулярно платить.
2. А с точки зрения поставщика передача файлов на флэшках и прочих подобных носителях тоже затратна: экспедиторы/водители будут "терять" их по несколько штук в неделю в расчёте на каждого покупателя/сеть
(типа, "маленькие они", "из карманов выпадают", "забыл в магазине" и т.п.) - т.е. тоже сплошной источник постоянного "разорения", покуда все родственники экспедиторов не наедятся этими самыми "носителями".
Спасибо за внимание, уделённое вами моим письмам !
Глупости говорите сударь
1. По поводу порносайтов не промолчу... поскольку у всех здесь присутствующих есть корпоротивная почта.. для справки POP3 по умолчанию работает на 110 потру а SMTP на 25 ... и я что то здесь не вижу нигде 80 порта на HTTP??? Есть такие штуки называются Фаэрволами и Роутерами... в их чисте и Циски... они прекрасно справляются с задачами фильтрования трафика и обеспечения безопасности...
Что касаемо людей которые не могут принять почту... если человек не может принять электронную почту после небольшого обучения - ему не место в магазине на ответсвенной должности... даже медведей в цирке на велосипедах учат кататся...
2. объем информации необходимый для передачи ничтожен... а по поводу затратности... посмотри прайс Ультры и посмотри сколько стоят флешки на данный момент... и смех и грех 512 метров за 250 рублев ... и вконце концов если они фуру потеряют по дороге это тоже будет не их проблема а начальника? они мат ответсвеные... ни что не мешает повесит на них кроме товара, машины... флэшку...
06.06.2007 21:04
victor
 
Ваше большое счастье, ДРУЖИЩЕ, что эти ВАШИ посты НЕ читает ВАШ сетевой хозяин. Предполагаю, что ТОТ бы мог весьма внятно объяснить ВАМ, как ему надоедают перманетные затраты на "расходные материалы".
Я тоже, знаете ли, пролетарий и нахожусь в одной с вами "обойме".
Однако если бы я оказался вашим "хозяином", то незамедлительно помножил бы количество магазинов торговой сети (видимо, "вы" достаточно мелкИ) на количество этих самых "расходников", а также и на частоту их "пропадания".
Про фуры не говорим - с этой темой отдельный "вопрос". И к ментам и т.д.
07.06.2007 11:40
baggio
 
1. Кстати он регулярно читает форум ...

2. Наш хозяин не занимается расходниками... однако как любой нормальный человек он понимает что машина бензин кушает, принтер тонер, админ пиво... и как любому нормальному человеку ему в голову не приходит мысль о закупке аккомуляторных машинок для экономии на бензине, и т.д., поскольку любая новая технология имеет два пути развития - один из которых тупиковый. и к сожелению не всегда в начале жизненного пути продукта или технологии видно что с ни будет.
3. По поводу пролитариата... не буду спорить поскольку не знаю Вас лично, а также чем Вы занимаетесь.
5. Да мы мелки по меркам Москвичей и Питерцев, одноко мы самая большая сеть(продуктовая про другие не знаю) в нашем городе.
6. У меня лично к пропаже расходников свой нормальный подход... пропал кардридж однажды годика 3 тому назад... заплатили ответсвенные люди, кому по накладной был выдан и все. Более расходников за мои лет 6 работы не пропадало (я говорю про комп расходники, за швабры и туалетную бумага ответсвенности не несу)

З.Ы. спор просто какойто не очень понятный... вот есть технологии по которым все работают... емэйл там, флешка и т.д., они работают и вроде всех все устраивает... приход человек и говорит блин... гавно.. все на чем Вы работаете работает неправильно, а вот так надо... и показывает красмвые картинки из пауэр поинта... Живое решение будте добры... позовите на демонстрацию, дайте руками пощупать, раскрутить, потыкатся вот тогда и посмотрим
Опции темы


Часовой пояс GMT +3, время: 15:39.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.