Comments 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 — гоните ссаными тряпками, ну серьезно)
Забавно, что удалил мой комментарий, где я подробно расписал про низкую эффективность данного решения и возможные грубые наружешия договора маркировки с ЦРПТ, с которыми вас просто отключат от системы маркировки.
Sign up to leave a comment.
Поездка в Китай: маркировка обуви на фабрике