0
Отвечен
Антон Парфенов 2 недели назад в UROVO • обновлен Дмитрий «РайтСкан» (Руководитель отдела разработки) 2 недели назад 24


ни один терминал правильно прочитать не может еан  13

Ответ

Ответ

Смотрите как интересно получается (по данным Википедии)
Немного теории, но почитайте пригодиться для понимания сути проблемы. 

UPC, содержащий 12 цифр, является прародителем европейского усовершенствованного кода EAN-13, кодирующего 13 цифр. Код UPC является частным случаем, подмножеством кода EAN-13. Код UPC преобразуется в код EAN-13 дописыванием нуля перед двенадцатью цифрами кода UPC. То есть, товар, штрихкод которого мы видим на рисунке к этой статье, будет иметь код EAN-13: 0036000291452. Именно по этой причине коды товаров произведённых в США или Канаде в европейской кодировке начинаются с нуля.

Важно, что сама «штриховка» при таком преобразовании, то есть рисунок EAN-13 для кодов, соответствующих UPC, идентична «штриховке» UPC. Таким образом была обеспечена совместимость американских кодов для чтения в Европе без какой-либо перепечатки этикеток или переупаковки товара.


Разработанная и внедрённая система кодировки товаров UPC в США и Канаде стала настолько популярной в супермаркетах, что европейцы также задумались о её внедрении. Стояло две задачи: обеспечить производителей определённым диапазоном кодов, отличных от американских, для кодировки производимых товаров и обеспечить возможность магазинам считывать как американские, так и европейские коды, причём желательно, чтобы на упаковке был только один, единый штрихкод, а не два кода (для США и для Европы). Для того, чтобы закодировать в коде товары других стран, необходимо было увеличить количество разрядов кода с 12 цифр, которые были в эксклюзивном владении американцев и канадцев до, как минимум, 13 цифр, чтобы использовать эту дополнительную, и первую по счёту цифру в коде в качестве условного сигнала для торговых программ, что этот товар не американского производства.

Американцам и канадцам в качестве этой цифры разработчики сразу зарезервировали нуль. У европейцев стояла и организационная задача: распределить (делегировать) определённые диапазоны значений кодов различным странам мира, для чего определили в качестве префикса региона первые три цифры, включая дополнительную тринадцатую.

Помимо организационной задачи, перед разработчиками стояла серьёзная техническая задача — сохранить совместимость кодов и одновременно возможность минимальных аппаратно-программных переделок сканеров штрихкода, тогда ещё достаточно дорогих. Важно было сохранить то же самое количество штрихов, осевую симметричность кода для его удобного чтения как в прямом, так и в обратном направлении (если товар поднесён к сканеру «вверх тормашками»), возможность чтения негативных кодов (светлые штрихи на тёмном фоне). В результате было найдено простое решение: в целях максимальной совместимости кодирование EAN было переработано из UPC так, что по-прежнему содержало только 12 «штриховых цифр» (то есть только 12 цифр в коде имеют соответствие конкретным штрихам), а дополнительная тринадцатая цифра вычислялась логическим путём. «Рисунок» EAN-13 ничем не отличается от рисунка UPC, а для кодов, начинающихся с нуля был точной копией.

и что получается в итоге.

вот я генерировал ваш ШК 



все коды идентичные по штрихам.

первый 0 на коде EAN13 он даже не закодирован в штрихах, его просто нет в штрихах на  штрих-коде.

Я  от сканировал ваш ШК на ручных сканерах Motorola и результат тот же самый самый первый 0 не читается. его просто нет в кодировке на штрих коде. 

Тут дело не в сканирующем модуле и не в терминале сбора данных и не в производителе. 

Мы в RS-CORE добавили возможность при сканирование кода UPC начинающегося с нуля добавлять еще один ноль спереди. Но производитель такие настройки вряд ли  будет добавлять, по сути это "костыль". по правильному есть два варианта:

1. Это в вашу программу добавлять значения штрих-кодов, которые реально закодированы на рисунке ШК.

2. Добавить в вашу программу такой же "костыль", чтобы при поиске ШК у которого спереди "ноль" и длинна штрих-кода 12 символов, добавлялся еще один ноль

Ну или все-таки воспользоваться нашим RS-CORE.


На рассмотрении

у вас каждый раз считывает по разному один и тотже ШК?

нет это просто разные терминалы, скорее всего настройки разные. А вот какие нужны?

Все галочки в UPC-A стоят тоже самое.

А вы в дальнейшем как будете использовать ТСД с каким приложением?
1С или собственным или через браузер?

1с терминально через 2x parallels

всего 3 терминала

на 2 рс коре нет вообще

на 1 отключен

Он похож на EAN но по факту воспринимается сканирующим модулем как UPC за счет префикса из двух нулей.
Должен RS:Core стоять. Напишите номер серийный я для вас обновление отправлю. может старая версия какая у вас (ну это только в том случае если вы их у нас покупали)
Не у вас первого такой вопрос с префиксом "0" для UPC.

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

без RS:core не как.
A что за проблема такая. у вас как-то включалось обратно "Keyboard output mode"? за счет чего он два раза вносился в активное поле?

а с чем связано что upc а не ean-13?

нет Keyboard output mode был выключен. Завтра напишу. По идее можно оставить и без ноля впереди.

но по идее если он был включен, то у вас ШК передавался два раза все верно:

- один раз нашим драйвером RS:Core.
- второй раз типовым драйвером ТСД.

то что идет в стандартной прошивке ТСД мы изменения внести не можем или это делать сложно нужно через производство. 
Для этого мы RS:Core и написали чтобы оперативно вносить изменения по требованию клиентов.
я бы конечно вернулся к вопросу двойного считывания ШК и устранил эту ошибку если она появляется.(у нас локально поймать ее не получается)

понятно. завтра напишу. любой сканер действительно считает, что это upc-a

Если возможно обратитесь к производителю, пусть добавят возможность префикса.

Не понятно почему терминалы воспринимают это как upc-a это же еан-13?


Ответ

Смотрите как интересно получается (по данным Википедии)
Немного теории, но почитайте пригодиться для понимания сути проблемы. 

UPC, содержащий 12 цифр, является прародителем европейского усовершенствованного кода EAN-13, кодирующего 13 цифр. Код UPC является частным случаем, подмножеством кода EAN-13. Код UPC преобразуется в код EAN-13 дописыванием нуля перед двенадцатью цифрами кода UPC. То есть, товар, штрихкод которого мы видим на рисунке к этой статье, будет иметь код EAN-13: 0036000291452. Именно по этой причине коды товаров произведённых в США или Канаде в европейской кодировке начинаются с нуля.

Важно, что сама «штриховка» при таком преобразовании, то есть рисунок EAN-13 для кодов, соответствующих UPC, идентична «штриховке» UPC. Таким образом была обеспечена совместимость американских кодов для чтения в Европе без какой-либо перепечатки этикеток или переупаковки товара.


Разработанная и внедрённая система кодировки товаров UPC в США и Канаде стала настолько популярной в супермаркетах, что европейцы также задумались о её внедрении. Стояло две задачи: обеспечить производителей определённым диапазоном кодов, отличных от американских, для кодировки производимых товаров и обеспечить возможность магазинам считывать как американские, так и европейские коды, причём желательно, чтобы на упаковке был только один, единый штрихкод, а не два кода (для США и для Европы). Для того, чтобы закодировать в коде товары других стран, необходимо было увеличить количество разрядов кода с 12 цифр, которые были в эксклюзивном владении американцев и канадцев до, как минимум, 13 цифр, чтобы использовать эту дополнительную, и первую по счёту цифру в коде в качестве условного сигнала для торговых программ, что этот товар не американского производства.

Американцам и канадцам в качестве этой цифры разработчики сразу зарезервировали нуль. У европейцев стояла и организационная задача: распределить (делегировать) определённые диапазоны значений кодов различным странам мира, для чего определили в качестве префикса региона первые три цифры, включая дополнительную тринадцатую.

Помимо организационной задачи, перед разработчиками стояла серьёзная техническая задача — сохранить совместимость кодов и одновременно возможность минимальных аппаратно-программных переделок сканеров штрихкода, тогда ещё достаточно дорогих. Важно было сохранить то же самое количество штрихов, осевую симметричность кода для его удобного чтения как в прямом, так и в обратном направлении (если товар поднесён к сканеру «вверх тормашками»), возможность чтения негативных кодов (светлые штрихи на тёмном фоне). В результате было найдено простое решение: в целях максимальной совместимости кодирование EAN было переработано из UPC так, что по-прежнему содержало только 12 «штриховых цифр» (то есть только 12 цифр в коде имеют соответствие конкретным штрихам), а дополнительная тринадцатая цифра вычислялась логическим путём. «Рисунок» EAN-13 ничем не отличается от рисунка UPC, а для кодов, начинающихся с нуля был точной копией.

и что получается в итоге.

вот я генерировал ваш ШК 



все коды идентичные по штрихам.

первый 0 на коде EAN13 он даже не закодирован в штрихах, его просто нет в штрихах на  штрих-коде.

Я  от сканировал ваш ШК на ручных сканерах Motorola и результат тот же самый самый первый 0 не читается. его просто нет в кодировке на штрих коде. 

Тут дело не в сканирующем модуле и не в терминале сбора данных и не в производителе. 

Мы в RS-CORE добавили возможность при сканирование кода UPC начинающегося с нуля добавлять еще один ноль спереди. Но производитель такие настройки вряд ли  будет добавлять, по сути это "костыль". по правильному есть два варианта:

1. Это в вашу программу добавлять значения штрих-кодов, которые реально закодированы на рисунке ШК.

2. Добавить в вашу программу такой же "костыль", чтобы при поиске ШК у которого спереди "ноль" и длинна штрих-кода 12 символов, добавлялся еще один ноль

Ну или все-таки воспользоваться нашим RS-CORE.


Большое спасибо, я и пытался разобраться в сути проблемы. Скорее всего мы будем заводить штрих коды без впереди идущего нуля.

Сервис поддержки клиентов работает на платформе UserEcho