Применение уникальной маркировки товаров нашими контрагентами

                                                                               Преамбула

    Недавно к нам обратился один из наших постоянных клиентов с просьбой помочь наладить обмен данными между нашими компаниями таким образом, чтобы они могли повысить степень автоматизации процесса приёмки товара их кладовщиками. При приемке клиентом товара от нас, их кладовщик:

1. Идентифицирует товар;

2. Сравнивает фактически прибывший товар со списком ожидаемого от нас товара;

3. Отражает отклонения плана с фактом в своей системе учёта;

4. Формирует этикетку в своей системе координат;

5. Оклеивает товар своими этикетками;

6. Размещает товар в ячейках склада.

   При наличии у клиента информации в машиночитаемом виде о поставляемом нами товаре, можно существенно сократить временные затраты на три первых этапа.

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

   Перед прочтением сути решения, желательно сначала ознакомиться с ранее опубликованной статьей "Уникальная маркировка товаров на складе". Если совсем кратко, мы при приемке товара (или группы товаров) от своих поставщиков, оклеиваем его уникальным штрихкодом, который в нашей информационной системе хранит информацию о типе (модели/артикуле) и количестве товара, связанного с данным уникальным штрихкодом. И нами не предполагалось использование данного штрихкода во внешних информационных системах. Однако, был найден рациональный вариант применения, о чём мы вам и рассказываем.

                                                                                            Решение

   В условиях тотального перехода компаний на электронный документооборот, появилась возможность формировать стандартизированные машиночитаемые файлы, и отправлять их через операторов связи своих контрагентам. Одним из типов такого документа является универсальный передаточный документ (далее УПД). Документ содержит перечень товаров или услуг, их цену, реквизиты продавца и покупателя.

   В стандарте (к примеру, (Ссылка) , описывающем формат этого документа, есть возможность добавлять внутри каждой товарной строки (тэг «СведТов») произвольную информацию в формате «идентификатор-значение» (тэг «ИнфПолФХЖ2»). Соответственно, мы воспользовались этой возможностью, добавив туда выгрузку информации о наших штрихкодах.

Пример фрагмента получившейся выгрузки:

<СведТов КолТов="5" НаимТов="Самый лучший товар" НалСт="20%" НомСтр="1" ОКЕИ_Тов="796" СтТовУчНал="5000.00" ЦенаТов="1000.00" >

<ИнфПолФХЖ2 Идентиф="ШтрихкодКоличество" Значен="9064514:1,9064513:4"/>

Где добавилась строка, выделенная жирным:

ИнфПолФХЖ2 - тэг для описания прикладных характеристик заранее не предопределенных стандартом, в формате "идентификатор-значение";

Идентиф - атрибут, в котором описан идентификатор пары "идентификатор-значение";

Значен - атрибут, в котором описано значение пары "идентификатор-значение".

Для взаимодействия с покупателями, мы формируем прикладную характеристику "ШтрихкодКоличество", в которой через запятую перечисляются пары "штрихкод:количество_товаров".

То есть "9064514:1,9064513:4" следует читать так:

- Штрихкод 9064514 наклеен на упаковку с количеством товаров равным 1;

- Штрихкод 9064513 наклеен на упаковку с количеством товаров равным 4.

И оба этих штрихкода относятся к товару (модели/артикулу), внутри которого добавлена эта строка. Сумма количеств товара по штрихкодам совпадает с суммой по строке (тэг «КолТов»)

                                                                                          Особый случай

   Следует упомянуть об одном моменте, который может в некоторых случаях нарушить работу данного механизма. В тэге "ИнфПолФХЖ2" атрибут "Значен" согласно стандарта имеет длину, ограниченную 2000 символами. Это означает, что если по одной строке УПД нашим складом будет отгружаться большое количество штрихкодов, и совокупная длина строки превысит 2000 символов, то это особая ситуация, которую необходимо обработать частным образом. Мы увидели как минимум три способа решения проблемы превышения длины 2000 символов:

1. Вообще не добавлять в эту строку УПД информацию о штрихкодах с количеством. Не лезет, значит не лезет, надо обрабатывать эту строку УПД руками полностью;

2. При достижении лимита 2000 символов разбивать на несколько строк, добавляя еще "ШтрихкодКоличество-2", "ШтрихкодКоличество-3", ... и так до тех пор, пока не упакуем весь набор штрихкодов с количествами;

3. Выводить только те штрихкоды с количествами, которые влезли в буфер длиной 2000, остальные игнорировать.

   Сейчас мы реализовали и обкатываем с клиентом способ 3. Если время покажет, что этот способ не является удовлетворительным, то можно будет поменять (или дополнить) реализацию.

                                                                                Что получилось в итоге

   Процесс дилера, связанный с приемкой товара от нас, заметно оптимизировался. Получая от нас информацию в машиночитаемом формате и используя её в связке с терминалом кладовщика осуществляющего приемку, дилеру удалось выстроить часть процесса, в которой кладовщик выполняет преимущественно функцию контроля:

• сканируя терминалом наш уникальный штрихкод, алгоритм осуществляет его поиск в ранее полученных от нас УПД, в результате чего происходит позиционирование фокуса на соответствующем товаре в накладной;

• кладовщик видит заявленную нами модель (артикул) товара и соотносит её с фактически поставленным товаром;

• он сразу получает из УПД количество отсканированного товара и может оценить это количество визуально;

• при полном соответствии плана с фактом (99% случаев), происходит подтверждение, и это отражается в системе учета дилера;

• при наличии расхождений по составу и/или количеству, кладовщик тут же их фиксирует.