TrackMatrix

Разбор предмета здесь и есть содержание проекта, поэтому с него.

Asl Belgisi — национальная система маркировки и прослеживаемости Узбекистана. На упаковку наносится код Data Matrix: похож на QR, но это другой формат. Внутри — код товара, уникальный серийный номер и криптоподпись.

Отсюда первое следствие, которое переворачивает всю задачу: код опознаёт не товар, а конкретную бутылку. Не «минеральная вода такая-то», а именно эта, сошедшая с линии в такую-то минуту. Значит кодов ровно столько, сколько физических единиц выпущено — на среднем заводе напитков это десятки миллионов строк в год.

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

Третье: у кода есть жизнь. Эмиссия, нанесение, ввод в оборот, перемещения между участниками, вывод из оборота при продаже. Каждый переход — событие со своей датой.

У системы есть API. Но доступ к нему — по токену самого участника оборота, и видит он только свои данные. Никакого общего доступа к рынку нет.

Из этого вытекает вся архитектурная сложность:

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

Часть команды до этого работала с 1С и внедряла нанесение этих кодов на производственных линиях. Это оказалось решающим, и видно это в модели данных.

В ней есть поля, которых не бывает у того, кто читал только документацию:

• как код попал на упаковку — напечатан, наклеен или навесной;
• куда именно нанесён — на упаковку, на сам товар или на этикетку;
• четыре разные даты: производства, выпуска, эмиссии кода и срока годности. Разницу между первыми тремя знает только тот, кто стоял у линии;
• кто печатал коды — сам заказчик или оператор системы.

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

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

• Модель данных под предмет. Коды, товары, контрагенты, история движения. Товар и код связаны по коду товара, а не по внутреннему ключу: данные приходят извне и в любом порядке, и связь обязана это пережить.
• Разделение по компаниям. Один человек ведёт несколько юридических лиц, переключается между ними и не видит чужого. Разграничение — на уровне выборки, а не на аккуратности запросов.
• Агрегация данных и аналитика поверх того, что отдаёт государственная система.
• Дашборды, собираемые под каждую компанию.

Мы спроектировали систему и передали наработки. Дальше её вела команда заказчика — и это нормальный исход для внутреннего продукта: он должен жить без подрядчика.

Мы показываем этот проект не ради объёмов, а ради того, что в нём главное: прежде чем считать, надо разобраться в предмете до уровня, на котором понятно, чем «дата производства» отличается от «даты выпуска». Так мы работаем со всеми — и с таможенными платежами, и с исламским финансированием.