Комментарии 17
off это телефон или штрихсканер?
Это терминал сбора данных, т.е. мобильный компьютер с функцией чтения штрихкодов. А на нём стоит софт, который мы и тестировали.
Ну zebra именно ТСД и сканеры штрихкодов производит. Правда у них на сайте нету, видимо либо модель снята с производства, либо это какая-то модель исключительно для китайского рынка, но похожие, без хардварной клавиатуры — есть…
TC20K представлен широко в мире.
Как интересно… Это модификация TC20, который на сайте есть, а в саппорт зоне нету. Но он, кстати, уже отживает свой век. С 10-го декабря не продаётся, правда саппорт до марта 24-го.
Угу, а теперь расскажите нафига это вообще нужно? Нет, понятно — друзья Вована на этом бабло стригут, а вот нормальным то людям оно зачем?
Нормальным людям это помогает в учёте, если вы спрашиваете про наклеивание этикеток и сканирование. Если про наш софт, то ответ простой — тсд сам по себе просто железка со сканером. Если ответа не нашли в этом комментарии, спрашивайте точнее — с удовольствием поделимся информацией.
Я, если честно, так и не понял проблему.
Линия с обувью двигается, работнику надо что сделать? Посмотреть на наклейку на коробке и наклеить соответствующую наклейку на ботинок? Или нет? Грубо говоря как они понимают что надо клеить?
Не очень понял, зачем ручной сканер тогда? Почему вообще это автоматизировать нельзя?
НЛО прилетело и опубликовало эту надпись здесь
Ребята, вы бы определились: вы — туристы или автоматизаторы каких-то процессов? Потому как непонятен смысл написанного.
А если и то, и другое, то как-то постараться надо было — могло получиться весело и полезно. А так получилось ни то, ни сё!
А если и то, и другое, то как-то постараться надо было — могло получиться весело и полезно. А так получилось ни то, ни сё!
Автоматизировали))) Вы случаем в ЦРПТ не работали, а то там такие же "оптимизаторы". Маркировка насаживаемая нашим государством это мертворожденное дитя. Маркировка должна быть исключительно добровольной и контролироваться производителями и импортерами. Остальное рынок отрегулирует сам. Сейчас легпром маркирует остатки. Обжегшись на обуви, заказывают марок с запасом на 1-3 года, чтобы можно было торговать, пока все утрясется. Так что утверждение что "левака больше не будет" это ложь. Очередная выемка денег у населения через торговлю, так сказать новый налог
Автоматизировали только через два месяца. На данном этапе задача была протестировать софт и понять на сколько он полезен на фабрике, при условии, что на стороне фабрики работает только ТСД с Кировкой. Все данные по кодам маркировки при этом находятся в России (на серверах заказчика/продавца обуви).
А что касается заказов марок в избытке, так это проблема есть только у компаний, кто не готов мириться с новыми правилами и подходить к маркировке с чувством, с толком, с расстановкой.
А что касается заказов марок в избытке, так это проблема есть только у компаний, кто не готов мириться с новыми правилами и подходить к маркировке с чувством, с толком, с расстановкой.
Этикетки на коробке и на обуви чем-то отличаются?
Я извиняюсь, но никакая это не автоматизация.
Объясняю почему. Сканером рабочий считывает штрих-код EAN13 на упаковке, в котором уже есть вся информация о модели, цвете, размере и тд., а ваше «решение» только вытаскивает из БД клиента (с заранее сгенерированными кодами DataMatrix) первый попавшийся с подходящим EAN13 (gtin) и печатает его на принтере. При этом кто наносит EAN13 на упаковки? Кто контролирует, верно ли нанесен EAN13? На ту ли модель, на тот ли цвет и размер?
Вы, возможно, скажете, что линия выпускает один продукт и такой контроль не обязателен. В таком случае заказчик в РФ может отправить в Китай количество этикеток в соответствии с ожидаемой партией товара, и на фабрике еще быстрее и проще наклеят их на коробки, ничего не сканируя. А в вашем случае просто у китайцев тройная работа — первый раз наклеить EAN13, второй — считать EAN13 и распечатать DataMatrix, третий — считать DataMatrix и агрегировать их в коробку. При этом ваше «решение» работает с готовыми кодами DataMatrix, то есть: лезет в базу, где они хранятся (и может теоретически там что угодно наделать), и плюс клиенту эту базу нужно обновлять каждый раз при выпуске новых DataMatrix. И еще интересно, как в БД хранятся выпущенные клиентом DataMatrix: если в картинках — то вы просто психи гонять такой объем данных из РФ в Китай, учитывая качество соединения и количество блокировок в Китае, а если в тексте — то это грубое нарушение правил маркировки и договора с ЦРПТ, и с вами могут расторгнуть договор в любой момент.
Лично я для нужд нашей компании написал мобильное решение, которое считывает и агрегирует DataMatrix в транспортные упаковки. Клиент просто отправляет тучу этикеток на фабрику, те в свою очередь наклеивают на изделия при производстве. Затем на выходе линии ставится контролёр — он считывает своим смартфоном с моим решением DataMatrix-коды и агрегирует в коробку.
Плюсы такого решения:
1. В БД моего ПО нет DataMatrix-кодов, а это значит, что клиенту не нужно такую базу постоянно обновлять, и мое ПО не нарушает правил договора с ЦРПТ
2. Не нужно гонять большие объемы информации по всему миру => высокая производительность
3. Мое решение легко и бесплатно масштабируется. Если завтра ваша линия втрое увеличит темп или откроется еще пара линий, что делать? Срочно докупать еще + ТСД по 30к рублей + принтеры? А если это нужно всего на неделю? В моем случае решение ставится на любой смартфон с Android или iOS, сегодня один контролер, а завтра ставь хоть 10 дополнительно со своими смартфонами. Смартфоны легко бьются и ломаются? Гораздо реже, чем ТСД, особенно если смартфон — свой) А сейчас он есть у каждого.
4. Хотите доп. проверку? Легко! Загружаем в БД описание для gtin из Excel, и при сканировании DataMatrix контролер будет видеть фото, модель, цвет, размер — и сразу может отбраковать неверно нанесенные коды.
5. Три языка: русский, английский, китайский. Добавить новый язык — не проблема.
Вообще, честно, я удивляюсь над вами, ребята) В 2016, когда началась маркировка меха, попробовал ваше «Мягкое золото». Весело поиграться, когда у тебя до 1000 единиц номенклатуры, куча свободного времени и есть стойкое желание кликать мышкой до мазолей на пальцах. А когда номенклатура переваливает за 10 тыс позиций (сейчас у нас больше 30 тыс), и объемы растут — программа просто висит, глючит, про трудозатраты на маркировку я вообще молчу. В итоге через два месяца плюнул и написал своё десктопное ПО, в котором сейчас одновременно работают с нашей БД в РФ, Турции и Китае, маркируют мех и теперь еще и обувь и одежду в разы быстрее и проще. При этом я в компании один разработчик от слова совсем.
Ладно бы мы были одни такие уникальные со своими «запросами», так и другие к нам обращаются периодически — эти просят метки эмитировать, те просят на КИЗ RFID-метки запись осуществить. Работают с «Мягким золотом» и слёзы крокодильи льют.
Ни в коем случае не набиваю себе цену, но мой вам совет — кто там у вас отвечает за бизнес логику ПО и за UI — гоните ссаными тряпками, ну серьезно)
Объясняю почему. Сканером рабочий считывает штрих-код EAN13 на упаковке, в котором уже есть вся информация о модели, цвете, размере и тд., а ваше «решение» только вытаскивает из БД клиента (с заранее сгенерированными кодами DataMatrix) первый попавшийся с подходящим EAN13 (gtin) и печатает его на принтере. При этом кто наносит EAN13 на упаковки? Кто контролирует, верно ли нанесен EAN13? На ту ли модель, на тот ли цвет и размер?
Вы, возможно, скажете, что линия выпускает один продукт и такой контроль не обязателен. В таком случае заказчик в РФ может отправить в Китай количество этикеток в соответствии с ожидаемой партией товара, и на фабрике еще быстрее и проще наклеят их на коробки, ничего не сканируя. А в вашем случае просто у китайцев тройная работа — первый раз наклеить EAN13, второй — считать EAN13 и распечатать DataMatrix, третий — считать DataMatrix и агрегировать их в коробку. При этом ваше «решение» работает с готовыми кодами DataMatrix, то есть: лезет в базу, где они хранятся (и может теоретически там что угодно наделать), и плюс клиенту эту базу нужно обновлять каждый раз при выпуске новых DataMatrix. И еще интересно, как в БД хранятся выпущенные клиентом DataMatrix: если в картинках — то вы просто психи гонять такой объем данных из РФ в Китай, учитывая качество соединения и количество блокировок в Китае, а если в тексте — то это грубое нарушение правил маркировки и договора с ЦРПТ, и с вами могут расторгнуть договор в любой момент.
Лично я для нужд нашей компании написал мобильное решение, которое считывает и агрегирует DataMatrix в транспортные упаковки. Клиент просто отправляет тучу этикеток на фабрику, те в свою очередь наклеивают на изделия при производстве. Затем на выходе линии ставится контролёр — он считывает своим смартфоном с моим решением DataMatrix-коды и агрегирует в коробку.
Плюсы такого решения:
1. В БД моего ПО нет DataMatrix-кодов, а это значит, что клиенту не нужно такую базу постоянно обновлять, и мое ПО не нарушает правил договора с ЦРПТ
2. Не нужно гонять большие объемы информации по всему миру => высокая производительность
3. Мое решение легко и бесплатно масштабируется. Если завтра ваша линия втрое увеличит темп или откроется еще пара линий, что делать? Срочно докупать еще + ТСД по 30к рублей + принтеры? А если это нужно всего на неделю? В моем случае решение ставится на любой смартфон с Android или iOS, сегодня один контролер, а завтра ставь хоть 10 дополнительно со своими смартфонами. Смартфоны легко бьются и ломаются? Гораздо реже, чем ТСД, особенно если смартфон — свой) А сейчас он есть у каждого.
4. Хотите доп. проверку? Легко! Загружаем в БД описание для gtin из Excel, и при сканировании DataMatrix контролер будет видеть фото, модель, цвет, размер — и сразу может отбраковать неверно нанесенные коды.
5. Три языка: русский, английский, китайский. Добавить новый язык — не проблема.
Вообще, честно, я удивляюсь над вами, ребята) В 2016, когда началась маркировка меха, попробовал ваше «Мягкое золото». Весело поиграться, когда у тебя до 1000 единиц номенклатуры, куча свободного времени и есть стойкое желание кликать мышкой до мазолей на пальцах. А когда номенклатура переваливает за 10 тыс позиций (сейчас у нас больше 30 тыс), и объемы растут — программа просто висит, глючит, про трудозатраты на маркировку я вообще молчу. В итоге через два месяца плюнул и написал своё десктопное ПО, в котором сейчас одновременно работают с нашей БД в РФ, Турции и Китае, маркируют мех и теперь еще и обувь и одежду в разы быстрее и проще. При этом я в компании один разработчик от слова совсем.
Ладно бы мы были одни такие уникальные со своими «запросами», так и другие к нам обращаются периодически — эти просят метки эмитировать, те просят на КИЗ RFID-метки запись осуществить. Работают с «Мягким золотом» и слёзы крокодильи льют.
Ни в коем случае не набиваю себе цену, но мой вам совет — кто там у вас отвечает за бизнес логику ПО и за UI — гоните ссаными тряпками, ну серьезно)
Забавно, что удалил мой комментарий, где я подробно расписал про низкую эффективность данного решения и возможные грубые наружешия договора маркировки с ЦРПТ, с которыми вас просто отключат от системы маркировки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поездка в Китай: маркировка обуви на фабрике