Наверх

База знаний
Try 2 Fix
beta

Honeywell Metrologic MS3780 не считывает штрих-код EAN13 + EAN5

У одного нашего клиента множество похожего товара, но всё-таки разного. Поэтому производитель печатает на товаре не привычный штрих-код EAN13, а EAN13 с дополнительными 5 символами, то есть EAN13 + EAN5. И так случилось, что сканер не считывает эти дополнительные символы. Решаем эту проблему.

Итак, всё дело в настройках сканера. По умолчанию считывание дополнительных 5 символом отключено. Включаем с помощью руководства по программированию.

  1. Заходим на сайт производителя нашего сканера.
  2. Скачиваем руководство по программированию (MetroSelect Configuration Guide).
  3. Находим там штрих-код с текстом «Enable Five Digit Supplements» в разделе «Supplements/Redundancy». В текущей инструкции это страница 41.
  4. Сканером считываем этот штрих-код дважды (первое считывание переводит его в режим программирования)! Сканер издаст три разных коротких сигнала, индикаторы на нём мигнут.
  5. Всё, можете считывать штрих-код EAN13 + EAN5 сразу.

Эти статьи будут Вам интересны

Настройка онлайн-кассы Штрих-М в режиме Ethernet и Wi-Fi (Штрих-М-02Ф / Штрих-Мини-01Ф)

В преддверии перехода на онлайн-кассы, рассказываем как настроить популярный фискальный регистратор Штрих-М-02Ф (или аналогичные) для передачи данных в ОФД через Ethernet и Wi-FI.

Zimbra 8.6 OSE: Произошла неизвестная ошибка (mail.TRY_AGAIN). Ошибка сети. postfix/postqueue fatal: Queue report unavailable — mail system is down

На корпоративном почтовом сервере Zimbra OSE пользователи при отправке внутренней почты стали получать сообщение "Произошла неизвестная ошибка (mail.TRY_AGAIN)", другие пользователи увидели "Ошибка сети". А мы во всех логах (/var/log/zimbra.log, /var/log/mail.log и /var/log/mail.err)  увидели это волшебное сообщение "postfix/postqueue fatal: Queue report unavailable - mail system is down". Работа была парализовано, но решение оказалось простым.

1С:Предприятие и PostgreSQL: Размещение базы данных 1С за пределами хранилища PostgreSQL

Вносить какие-то глобальные изменения сразу в работающую базу данных 1С:Предприятие - дело неблагодарное. Даже если у Вас есть резервные копии, понадобится время, чтобы восстановить их, а время для некоторых организаций критично. Поэтому лучше проводить отладку своих обработок на копии базы данных. Если это файловая версия - вообще нет никаких проблем. Если SQL - всё немного сложнее. А если ещё и закончилось место в хранилище баз данных СУБД, а расширять хранилище нет места/возможности - то это вообще проблема. Но мы поможем!