Новый API не исправит хаос в справочниках
Интеграция с государственным сервисом часто воспринимается как задача разработчика: получить ключ, отправить JSON, получить статус. На деле самый трудный вопрос возникает раньше. Что именно отправлять, если в договоре один номер, у логиста другой реестр, на складе третий артикул, а бухгалтер видит поставку только после закрывающих документов?
Если одна поставка не имеет общего идентификатора, API просто быстрее передаст несогласованные данные. Поэтому техническое подключение стоит начинать с модели данных, а не с кнопки «интегрировать».
Как выглядит нормальная карточка поставки
Внутренняя карточка поставки — это не огромная ERP. Это один экран, который связывает договор, поставщика, позиции, ожидаемую дату, транспорт, документы, складской приход и финансовый статус. Разные сотрудники могут видеть свой блок, но работают с одним событием.
- Номер поставки и контракт, поставщик, валюта и ответственный.
- Список товаров с внутренними артикулами, кодами, количеством и стоимостью.
- Партии, сертификаты, декларации, маркировка и связанные файлы.
- Плановые и фактические даты: заказ, отгрузка, граница, склад, закрытие.
- Статусы отправки в внешний сервис и понятные тексты ошибок.
- Журнал: кто менял данные, приложил документ или подтвердил получение.
Какие уведомления окупаются первыми
Самые полезные уведомления почти никогда не звучат как «новое сообщение от API». Команде нужны сигналы, на которых можно действовать: поставка задержана, документ не приложен, количество не сходится, срок сертификата заканчивается, отправка не прошла, товар уже обещан клиентам, но не подтверждён к продаже.
Уведомление должно содержать контекст и кнопку действия. «Ошибка в документе» бесполезна. «В поставке № 418 нет декларации для трёх SKU, менеджер продаж уже видит предзаказы» — это задача, которую можно решить до потери денег.
Подготовка за одну рабочую неделю
Возьмите последние пять поставок и попробуйте восстановить их историю только по данным внутри компании. Замерьте время, число источников и места, где сотрудник вынужден спрашивать коллегу. Это покажет реальную архитектуру процесса лучше любого технического задания.
После этого можно определить MVP: единый реестр поставок, обязательные поля, статусы и простая выгрузка. Когда появится API, его подключение станет коротким этапом, а не запуском новой ручной работы.
Источники
Материал подготовлен по открытым публикациям и официальным разъяснениям, актуальным на дату статьи.