Маркировка легпрома на типовой 1С:КА 2.5: до 3 000 кодов в день, один ТСД и сбои массовой печати

Я отвечаю за ИТ и автоматизацию швейного производства в Нижнем Новгороде — компании, которую основал в 2008 году. Шьём постельное, столовое и кухонное бельё, спецодежду и текстильные сумки. Поставляем продукцию коммерческим, социальным и бюджетным учреждениям, в том числе по 44-ФЗ и 223-ФЗ.

В маркировке мы с пилота 2019 года, а с 2020 года работаем на потоке. На типовой 1С:КА 2.5 один сотрудник с одним ТСД маркирует на пике до 3 000 единиц в день. Такой объём у нас уже был; верхний предел производительности связки мы пока не проверяли.

Главная история — пропуски этикеток при массовой печати через VPN. Мы искали причину по всей цепочке и меняли настройки MSS и очередей на маршрутизаторах. После этих изменений пропуски перестали наблюдаться.

У нас небольшая компания без штатного ИТ-отдела. Поэтому при выборе решения мне были важны не только расходы на запуск, но и то, сколько внимания система потребует в ежедневной работе.

Содержание

Почему маркировка — это больно для малого швейного производства

Пилот: с чего начинали

Архитектура

Процесс: от заказа кодов до отгрузки

Грабли

Обучение

Цифры

Чек-лист для тех, кто начинает

Почему маркировка — это больно для малого швейного производства

Каждая единица товара получает свой код, а карточка в каталоге нужна на каждое сочетание модели, размера, роста и цвета. У нас около 300 моделей: постельное бельё, полотенца, наматрасники, рабочие халаты, фартуки. Карточек в Национальном каталоге из них получилось 13 471.

В нашем производственном процессе код нужно заказать, напечатать, нанести и ввести товар в оборот. Дальше оформляем передачу либо вывод из оборота по применимому основанию. Условия договора помогают определить сценарий поставки, но сами по себе не заменяют правил маркировки. Сбой печати задерживает работу: код есть в базе, а этикетку для товара ещё нужно получить и проверить.

Штатного ИТ-отдела нет: автоматизацию веду сам, под отдельные задачи беру подрядчиков. Поэтому система должна стабильно работать, обновляться и держать нагрузку — на типовых механизмах и почти без обслуживания.

Пилот: с чего начинали

Первой категорией у нас было постельное бельё. В пилот вошли в 2019 году: хотелось заранее освоить процесс и подойти к обязательному этапу подготовленными.

Работали сразу из 1С, тогда ещё на КА 2.4, без ручной работы в личном кабинете. Это принципиальное решение: личных кабинетов и так хватает, и хочется работать в своём контуре из одного окна. От первых тестов до массового выпуска через ГИС МТ прошло около шести месяцев; на поток вышли в 2020 году.

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

Сложнее всего оказались две вещи. Первая — подобрать связку «железо — софт», которая держит нагрузку, почти не требует обслуживания и удобна на всех участках. Вторая — привести в порядок справочники; о них ниже, в граблях.

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

Архитектура

Обмен с ГИС МТ у нас типовой, без изменения его кода. Это не означает, что весь контур работает без собственных настроек: сценарии документов на ТСД я написал под наш процесс.

• Учёт. 1С:КА 2.5, клиент-серверный вариант на PostgreSQL под Linux. Резервное копирование PITR и репликация, обновления — только через тестовый стенд.

• Обмен с ГИС МТ, СУЗ и Национальным каталогом — типовое рабочее место «Обмен с ИС МП».

• ЭДО. УПД с кодами уходят прямо из 1С.

• ТСД. Urovo с DataMobile, 1С опубликована для него на Apache. Сценарии документов на ТСД я написал сам. DataMobile выбирали долго и сравнивали с другими решениями. Его плюсы для нас — гибкость сценариев и шаблонов, которые сокращают ручные действия, и быстрая поддержка.

• Печать и сканирование. Сетевые принтеры этикеток и два 2D-сканера на рабочих местах.

• Сеть. Пять площадок объединены VPN на MikroTik. ТСД работает на складе по Wi-Fi, а сервер 1С стоит на другой площадке. Этикетки печатает ПК с принтером на складе, и задание к нему сервер шлёт обратно через VPN.

Маршрут команды и задания печати между складом и сервером 1С

Задание на печать идёт от ТСД через Wi-Fi и VPN на сервер 1С, а оттуда снова через VPN — на ПК с принтером. Именно эту цепочку мы проверяли при пропусках этикеток.

На первоначальном этапе, ещё до введения обязательной маркировки для нашей продукции, оборудование, лицензии и работы обошлись примерно в 300 тыс. руб. Моя собственная работа в эту сумму не включена. На весь поток маркировки — один ТСД.

Рабочее место обмена с системой маркировки в нашей установке 1С

Процесс: от заказа кодов до отгрузки

• Заказ кодов. В нашей настройке создаём документ «Маркировка товаров ИС МП», на его основании — «Заказ на эмиссию кодов маркировки СУЗ»; коды приходят в базу.

• Печать и нанесение. Код печатается при приёмке готовой продукции — из цеха и от надомных швей — и клеится на пакет. Приёмку и печать ведёт один сотрудник с ТСД, на пике это до 3 000 кодов в день.

• Ввод в оборот в нашей схеме оформляем типовым документом «Маркировка товаров ИС МП».

• Агрегация. Короба собираем только в 1С, в ГИС МТ агрегаты не регистрируем: для сборки и отгрузки нам этого хватает.

• Сборка заказа с ТСД: на экране фото товара, каждый код сканируется и сверяется с заказом. Средний заказ — около 500 штук изделий.

• Отгрузка. В зависимости от сценария поставки передаём УПД с кодами через ЭДО либо оформляем вывод из оборота по соответствующему основанию. Для поставок по 44-ФЗ используем также электронный документ о приёмке в ЕИС с кодами маркировки. Этот вариант требует контроля успешной обработки сведений в ГИС МТ; одной подписи заказчика недостаточно, чтобы утверждать, что нужная операция завершена. С приёмкой у заказчиков, по нашему опыту, существенных проблем не было.

Исторический список заказов кодов в СУЗ

Документы на ТСД в нашей настройке

Фото на экране ТСД

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

Фото на ТСД помогает найти товар на полке, а сканирование кода и сверка с заказом — проверить нужную позицию и характеристику. За каждой незнакомой позицией уже не нужно идти к руководителю.

Фотография и данные изделия на складском терминале

Просмотр фотографии изделия на терминале

Обувь в опте — другой процесс

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

Главное здесь — приёмка. Объясните кладовщикам и закрепите в регламенте: коды при поступлении принимаются поштучно. У нас не раз бывало, что при разагрегировании упаковки часть кодов не совпадала с документами или была испорчена.

До подписания УПД такой вопрос с поставщиком решается проще и быстрее, чем потом корректировками и претензиями. Этап трудоёмкий, но иначе на складе появляются виртуальные коды, которых по факту нет, или товар, который нельзя продать.

Грабли

Пропуски при массовой печати

При массовой печати из документа недосчитывались от 10 до 30 этикеток. Путь задания длинный: ТСД на складе → сервер 1С на другой площадке → ПК с принтером на складе. Между площадками — WireGuard на MikroTik. Сервер выбирает принтер по шаблону и отправляет задание через туннель.

Канал при этом узкий: реальная пропускная способность по замеру Bandwidth Test — около 10 Мбит/с, и временами он забит.

Приходилось выяснять, какие этикетки не вышли, и восстанавливать печать. Коды при этом оставались в базе; проблема была в том, что сотрудник получал неполный комплект этикеток.

Под подозрением была вся цепочка: ТСД, Wi-Fi, VPN, сервер, ПК с принтером. На поиск ушёл примерно рабочий день: сначала гоняли mtr между площадками, потом воспроизвели ошибку под дампом трафика.

Мы связали сбой с передачей крупных заданий и загрузкой туннеля. Однако одного сетевого наблюдения для точного диагноза мало: TCP повторно передаёт потерянные данные, а неполная печать может возникнуть дальше по цепочке. Уверенно мы зафиксировали результат совместной настройки, а не отказ одного конкретного звена.

На маршрутизаторах меняли MSS — объявляемый максимальный размер данных в TCP-сегменте. Это один из способов работы с проблемами прохождения крупных сегментов через туннель; в документации MikroTik разобрана его связь с MTU и PMTUD. Значение выбирают для конкретного сетевого пути.

Вторым изменением были очереди трафика между площадками: им задавали приоритет при загрузке канала. Здесь имеет значение и место очереди в схеме, и то, какой трафик в неё попадает.

После совместного изменения MSS и очередей пропуски перестали наблюдаться. Для контроля результата нужно сверять список кодов в задании с этикетками, которые действительно вышли из принтера.

Такую печать стоит проверять на объёмах, близких к рабочим, и при занятом канале. При диагностике фиксируйте результат каждого задания, ошибки и тайм-ауты. Один неудачный ping ещё не объясняет, почему из принтера вышло меньше этикеток.

Справочники: всё должно совпадать

Главное в обмене с ГИС МТ — согласованность сведений о товаре в 1С и Национальном каталоге: ТН ВЭД, применимые разрешительные документы и ОКПД2. Эти поля проверяем и сопоставляем, а расхождения разбираем по исходным документам.

Это настройка справочников и сопоставлений в типовом механизме 1С. Чего в типовой не хватило, добавили дополнительными реквизитами, без изменения конфигурации.

Помогает, что сертификацию и декларирование мы ведём сами: коды ТН ВЭД и разрешительные документы в одних руках, и их проще держать согласованными.

Карточки в Национальном каталоге создавали типовой обработкой 1С. Примерно 300 моделей дали 13 471 карточку: каждое сочетание размера, роста и цвета — отдельная карточка со своим GTIN.

Национальный каталог: 13 471 запись на момент исходного снимка

Выцветшие и испорченные этикетки

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

В 2025 году для работы с этикетками мы сделали внутреннее Android-приложение ScanPrint. Когда старая этикетка начинает выцветать, но код ещё считывается, ТСД читает этот код и отправляет его на сетевой принтер у стеллажа. Новую этикетку с тем же кодом наклеиваем рядом со старой на ту же единицу товара; прежнюю оставляем. В этот момент код имеет статус «В обороте». Я отвечал за постановку, архитектуру, тестирование и внедрение; код генерировал ИИ-агент под моим руководством.

Сам код и его связь с товаром в системе маркировки не меняются.

Если повреждённую этикетку не удаётся прочитать, в нашем процессе используется типовой документ «Перемаркировка товаров ИС МП», в том числе с ТСД. Это отдельная операция с новым кодом; она не тождественна описанной выше печати прежнего кода рядом со старой этикеткой.

Данные маркировки пригодились для экосбора

При подготовке отчётности за 2025 год нам понадобилась масса выпущенных товаров и упаковки. Данные маркировки помогли сверить выпуск, но сами по себе не определяли состав отчётности, массу и обязанность уплатить экологический сбор.

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

Обработка для 1С собирает данные для отчёта и сверяет их с данными маркировки. Код обработки по моей постановке написал ИИ-агент, проверял и принимал я. Отчётность за 2025 год подготовили и сдали в 2026 году за неделю.

Практический результат для нас — связь учётных данных с расчётом массы. Массу и основание расчёта я бы завёл в номенклатуру заранее. Тогда при подготовке отчётности остаётся проверить состав выпуска, упаковку и корректировки, а не собирать исходные данные заново.

Обучение

Маркировка касается всех, кто физически работает с товаром. Кого я только не учил за это время: продавцов, швей, водителей, кладовщиков, управляющих — устану перечислять.

Проще всего оказалось с ТСД: фото на экране и проверка кода при сканировании помогают освоить подбор. По моим наблюдениям, новичок начинает работать самостоятельно примерно через 1–3 дня, в зависимости от человека.

Цифры

Чек-лист для тех, кто начинает

• Начните со справочников и сопоставлений: ТН ВЭД, разрешительные документы, ОКПД2. У нас недостающие данные добавили дополнительными реквизитами без изменения конфигурации.

• Берите типовой обмен и настраивайте его. Нам хватило типовой КА 2.5 без доработок обмена.

• Подбирайте связку «железо — софт» под пиковую нагрузку и минимальное обслуживание. Если склад уже работает со штрихкодами, маркировка ляжет на готовый процесс.

• Проверьте путь печати через VPN под рабочей нагрузкой. Настройки MTU, MSS и очередей выбирайте по результатам диагностики конкретной сети.

• Сверяйте состав задания с физически полученными этикетками. Окончание списка кодов в программе само по себе не является подтверждением печати.

• Сканируйте каждый код при сборке. Это заодно и контроль комплектации.

• Подбирайте способ печати и материал этикетки под срок и условия хранения. Проверяйте их на своей продукции; при повреждении средства идентификации учитывайте правила своей товарной группы.

• Ведите массу изделий и основания её расчёта в номенклатуре. При использовании данных для отчётности отдельно проверяйте её применимость, полноту и массу упаковки.

Как у вас организован контроль массовой печати этикеток? Интересно, как вы находите недостающие этикетки и сверяете результат с заданием. Поделитесь своим способом в комментариях.