Как устроена интеграция маркировки с информационной системой
Интеграция связывает учетные данные предприятия с системой маркировки и операциями на производстве или складе. Информационная система передает сведения о товарах, заказах и действиях с продукцией, а система маркировки возвращает коды и результаты обработки запросов. Обмен обычно включает несколько этапов: подготовку карточек, получение кодов, их нанесение, проверку и передачу сведений о движении товара. Подробнее об услугах по маркировке товаров можно узнать здесь: https://iiii-tech.com/services/markirovka-tovarov/.
Связь строится через интерфейс обмена данными: он передает запросы и ответы по согласованным правилам. Для каждой операции фиксируются идентификатор сообщения, время отправки, результат и связь с товаром или заказом. Такой журнал помогает сопоставить состояние записи в учетной системе с результатом обработки на стороне маркировки.
Роли учетной, производственной и складской систем
Учетная система хранит номенклатуру, единицы измерения, заказы и производственные задания. Производственная система получает задание на выпуск, связывает нанесенный код с конкретной товарной единицей и сообщает о результате печати. Складская система фиксирует приемку, перемещение, комплектацию и отгрузку. Если одно приложение совмещает несколько ролей, для него все равно задаются отдельные правила работы с каждым видом данных.
Разделение функций снижает риск расхождений: производственный участок не должен самостоятельно менять исходные сведения карточки, а складская операция должна опираться на фактически считанный код. Состав систем зависит от организации процессов и технической архитектуры предприятия.
Данные и события, участвующие в обмене
В обмен входят идентификаторы товара, коды маркировки, производственные задания и события оборота. Для каждой товарной единицы фиксируются получение или назначение кода, печать, контроль считывания, ввод в оборот и последующие складские действия — если они предусмотрены правилами конкретной системы маркировки. Событие должно содержать время, тип операции, участника процесса и ссылку на код.
Карточка товара содержит наименование, GTIN, характеристики и единицу измерения. GTIN может иметь длину 8, 12, 13 или 14 цифр; при обмене его представление согласуют между системами, поскольку ведущие нули и формат поля влияют на сопоставление. Набор обязательных реквизитов определяется товарной категорией и применяемыми правилами.
Подготовка справочников и настройка обмена
До включения обмена сверяют справочники товаров, единиц измерения, складов, производственных линий и типов операций. Для каждой сущности назначают устойчивый идентификатор, который не меняется при переименовании записи. Отдельно описывают, какая система считается источником данных по карточкам, остаткам и производственным заданиям: иначе обновления могут перезаписывать друг друга.
Проверка карточек товаров и идентификаторов
Карточки проверяют на полноту и согласованность: GTIN должен относиться к нужной товарной позиции, единица измерения — соответствовать учетной модели, а упаковочные уровни — быть описаны без противоречий. Дубликаты идентификаторов приводят к неоднозначной привязке кода. Перед обменом полезно проверить контрольную цифру GTIN и убедиться, что система не удаляет значимые нули при преобразовании формата.
API, форматы сообщений и авторизация
Интерфейс может использовать API с сообщениями в JSON или XML. Стороны согласуют адреса методов, обязательные поля, кодировку UTF-8, правила дат и формат ошибок. Например, дата и время могут передаваться в ISO 8601 с часовым поясом; конкретное представление должно быть единым для обеих систем. Авторизация обычно основана на учетных данных или токенах, а передача защищается шифрованием TLS. Секреты доступа хранят отдельно от журналов и регулярно обновляют согласно внутренним правилам.
Обработка кодов в производстве и логистике
Полученные коды распределяются по заданиям и передаются на участок нанесения. Система должна сохранять связь между кодом, товаром, серией или партией и производственным событием. Повторное использование одного кода блокируется проверкой уникальности, а его дальнейший статус обновляется только после подтвержденной операции.
Получение, нанесение и проверка кодов
Запрос на получение кодов содержит сведения, необходимые для формирования набора, и идентификатор задания. Ответ системы маркировки сверяют с запросом: проверяют количество записей, формат и отсутствие повторов. На линии принтер наносит код на этикетку или упаковку, а сканер считывает его после печати. Для Data Matrix ECC 200 считыватель должен распознавать двумерный символ; результат печати оценивают по читаемости и соответствию установленным требованиям, а не только по наличию изображения.
Если код не читается, товар направляют на повторную печать или отбраковку по регламенту. Система записывает результат проверки, чтобы не передать в учет код, который фактически не нанесен либо не связан с нужной единицей.
Агрегация упаковок и передача сведений об операциях
Агрегация связывает коды отдельных товаров с кодом групповой или транспортной упаковки. Родительская упаковка содержит перечень дочерних кодов; при изменении состава связь обновляют, а при вскрытии фиксируют расформирование. Складская система передает события приемки, перемещения и отгрузки с указанием соответствующих кодов или агрегатов. Перед отправкой проверяют, что дочерние единицы не числятся одновременно в несовместимых упаковках.
Тестирование и контроль корректности
Интеграцию проверяют на тестовой среде до выполнения рабочих операций. В нее загружают тестовые карточки и имитируют получение кодов, печать, агрегацию, отгрузку и отказ обработки. Проверка охватывает не только успешный обмен, но и неполные ответы, неверные идентификаторы и повторную передачу сообщений.
Проверка сценариев и сверка статусов
Для каждого сценария сравнивают исходный запрос, ответ системы маркировки и запись предприятия. Сверяют количество кодов, их статусы, принадлежность товарам и состав упаковок. Расхождения выявляют по журналам интеграции и отчетам сверки: например, код может быть сохранен в производственной системе, но не получить ожидаемый статус после передачи сведений об операции.
Обработка ошибок, повторных запросов и сбоев связи
Ошибки делят на исправимые данные, отказ авторизации, конфликт статуса и временный сбой связи. При повторной отправке сообщения используют уникальный идентификатор операции или ключ идемпотентности, если интерфейс его поддерживает: это предотвращает повторное выполнение уже принятого действия. После потери связи система сохраняет очередь сообщений, а при восстановлении передает их с контролем ответа. Повторять запрос без проверки его предыдущего результата рискованно: операция могла быть выполнена, хотя подтверждение не дошло. Журнал должен хранить время, код ответа, идентификатор сообщения и сведения о причине сбоя.
