Паллетный учёт на ТСД для оптовика: приложение под 1С

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

Задача

Заказчик — оптовик мясной продукции. На складе 7 терминалов сбора данных на Android. Товарный учёт ведётся в 1С УТ, и это граница, которую не трогаем: остатки, документы и цены остаются там, где они есть.

Нужен был учёт паллет на всех этапах движения. Приёмка фуры. Формирование паллеты из коробок. Разделение паллеты на несколько и расформирование целиком. Отгрузка целыми паллетами и россыпью, когда уходит часть коробок.

Что я сделал

Приложение написал на Flutter — одна кодовая база под терминалы, которые уже стоят на складе.

Главное архитектурное решение — данные идут через слой-интерфейс. Экраны не знают, откуда берутся паллеты и куда уходят операции. Сейчас за интерфейсом стоит демо-реализация, на следующем этапе вместо неё подключается HTTP-сервис 1С. Экраны при этом не переписываются.

Сканирование: штрихкоды GS1-128 и EAN. GS1-128 несёт в одном коде несколько полей, в том числе вес, поэтому его разбор — отдельная логика. Там, где кода с весом нет, кладовщик вводит вес руками.

Печать этикетки паллеты 100×150 миллиметров с QR-кодом. Паллету потом можно отсканировать и сразу увидеть, что на ней.

Бизнес-правило, которое вшито в приложение: нельзя отгружать вместе паллеты разных организаций. Если в одну отгрузку попадает паллета другой организации, приложение её не пропустит.

Маркировку заложил в архитектуру на следующий этап, но в текущую версию не включал.

Протокол обмена с 1С

Самая недооценённая часть таких проектов — договорённость между приложением и учётной системой. Поэтому протокол обмена v1 описал отдельным документом до подключения, а не после.

Авторизация — Basic, её поддерживает HTTP-сервис 1С без дополнительных модулей. Каждая операция несёт Idempotency-Key — уникальный ключ запроса. Это защита от дублей: если на складе пропала связь и терминал отправил приёмку повторно, 1С по ключу поймёт, что это та же операция, и не проведёт её дважды. Коды ошибок описаны заранее, чтобы терминал показывал кладовщику понятную причину, а не «что-то пошло не так».

Документ нужен и программисту 1С на стороне заказчика: по нему видно, что именно должен принимать и отдавать сервис.

Что было сложно

Первое — граница с 1С. Соблазн сделать «удобно» и начать двигать остатки из терминала велик. Но товарный учёт уже работает, и любое вмешательство в него — риск для всего склада. Поэтому приложение отвечает только за паллеты и их состав, а 1С остаётся источником правды по товару.

Второе — операции, которые меняют структуру. Приёмка и отгрузка целой паллетой понятны. Разделение, расформирование и россыпь сложнее: коробки переезжают с паллеты на паллету, и в любой момент должно быть ясно, где какая. Поэтому логику этих операций закрывал тестами, а не только проверкой на экране.

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

Четвёртое — разные терминалы. Процессоры на складских устройствах бывают 64- и 32-битные, поэтому демо-сборку сделал под обе архитектуры.

Что получилось

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

Что дальше

Следующий этап — подключить слой данных к HTTP-сервису 1С по протоколу v1 и прогнать сценарии на настоящих документах. После этого — выход на 7 терминалов и маркировка, под которую место в архитектуре уже оставлено.

Порядок здесь важен. Сначала сервис 1С должен научиться принимать операции по протоколу и честно отвечать кодами ошибок. Только потом терминалы уходят на склад. Если сделать наоборот, кладовщики первыми столкнутся с ошибками интеграции, и доверие к приложению будет потеряно ещё до того, как оно начнёт экономить время. Демо-сборка как раз и нужна, чтобы заказчик заранее посмотрел экраны и поправил сценарии, пока это дёшево.

Частые вопросы

Почему не делать всё прямо в 1С?

Товарный учёт в 1С УТ уже работает, и трогать его не нужно. Паллетный слой — отдельная задача со своими экранами для терминала. Приложение отвечает за паллеты, 1С — за товар, связь между ними идёт через HTTP-сервис.

Что будет, если на складе пропадёт связь?

Для этого в протоколе Idempotency-Key. Повторная отправка той же операции не создаст дубль в 1С: сервис узнает ключ и ответит, что операция уже принята.

Какие штрихкоды читает приложение?

GS1-128 и EAN. Если вес в коде не зашит, кладовщик вводит его вручную.

Можно ли отгрузить в одной машине паллеты разных организаций?

Нет. Это правило вшито в приложение: паллеты разных организаций вместе не отгружаются.

Приложение уже работает на складе?

Нет. Заказчик получил демо-APK для arm64 и arm32, подключение к 1С и запуск в работу — следующий этап.

Коротко о главном

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

Сейчас это разработанное и протестированное приложение с демо-сборкой. Проверку на живом складе и подключение к 1С я называю следующим этапом, а не сделанной работой.

Если у вас склад на 1С и нужно приложение для ТСД под свои операции — приёмку, паллеты, отгрузку, этикетки, — я соберу его и договорюсь с вашей 1С через понятный протокол. Напишите в Telegram, MAX или VK.