Возникла следующая проблема: поступил новый товар от поставщика, штрих-код вида 27ххххххххххх  При создании номенклатуры нормально считывается.
При считывании данного штрих-кода в документ поступления или продажи выдается сообщение что такой шрих-код не найден, предлагает зарегистрировать, и при этом отображает штрих-код вида 27ххххх000000 а окончание штрих-кода запихивает в поле количество.
Весовой товар вообще мы не используем, префикс весового товара установлен в 1, штучного в 0. Со Своими этикетками проблем нет. Не может же сканер такую ошибку генерировать, как 1Ске объяснить что так делать не надо ?

УТ 11.1 Платформа 8.2 последняя, драйвер сканера 1С последней версии.

v8: Проблема при считывании Штрихкода в УТ 11.1

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

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

(3) У некоторых поставщиков и весовые товары приходили с такими кодами, причём, от разных поставщиков приходили одинаковые коды.
Некоторые поставщики соглашаются и получают EAN-коды на стой товар, но - это забота производителей. Если поставщик от производителя получает товар на вес и сам расфасовывает, то EAN-код он использовать не может - вот и приходится извращаться.
P.S. в старой УТ.10.Х был штрих-код штучного товара с 20 и весовой с 21 - все остальные рассматривались как обычные штрих-коды.
Вообще-то, в нормальных кассовых программах типа Frontol есть понятие шаблона штрих-кода, когда можно задать диапазоны штрих-кода и научить сканер их обрабатывать.
Кстати, некоторые сканеры поддерживают программируемые внутрь штрих-коды - можно сделать так, что будет выдаваться штрих-код с префиксом, который УТ не будет понимать как EAN, а будет думать, что это CODE39 и т.п. И уже весовым считать не будет.

На вскидку(пришлось однажды делать для сети..)  прочитать первые несколько цифр, после того определить поставщика и .. уже не помню. работы были давно.. ))

(5) Есть, например, поставщик (по мойму, мясницкий ряд) - у него весовой товар, но коды начинаются с 23,27,28 и т.п. (может быть, и другие есть, но все уже перевешивают).

Я в подобном случае просто закомментировал эту проверку на весовой штрихкод в общих модулях. Там действительно просто напрямую указано всегда считать это весовым(

(6)Ну так считай первые цифры, а дальше онанируй по желанию.. хочешь - их вес прими(и радуйся) хочешь - отправь на перевес и свои ШК

(7) У них в прошлых релизах какие-то непонятки с префиксами были - вот они и решили, что всё будет весовое.
По-хорошему, нужно писать в 1С и объяснять, что пора вводить шаблоны штрих-кода, но у 1С там багов полно и о новом функционале они и не думают - интерфейс, видите ли, важнее.

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

(10) Если упаковка герметичная, то вес её уменьшится не должен - он может только увеличится. При перевесе у покупателей возникают вопросы - они считают, что их обвешивают. Кроме того, из веса товара нужно исключать вес упаковки, что не всегда можно сделать.