ДОКА: как я проектировал контур «инвойс → XML»

Я архитектор системы ДОКА. Автор продукта: Аксёнов Юрий Васильевич. Правообладатель: ООО «ГК Фороней». Роспатент №2026681995.

Декларант получает спецификацию, код ТН ВЭД ЕАЭС с обоснованием и проект XML для Альта-ГТД. Инвойс в публичный чат не уезжает. OCR здесь только первый шаг.

Зачем отдельный продукт

Инвойсы из Китая, Турции и Ближнего Востока приходят на 30–50 страниц. Кода ТН ВЭД либо нет, либо он в чужой схеме. Ручной перенос в Альта-ГТД занимает часы. Ошибка в одном знаке даёт КТС, простой на СВХ и риск по ст. 16.2 КоАП РФ.

Политика ИБ и 152-ФЗ обычно закрывают путь «загрузить инвойс в облачную модель». Значит, инференс живёт на серверах заказчика.

Как устроен конвейер

Та же последовательность, что и в методе as-is:

1. Извлечение. Таблицы, сканы, MSDS. Не сдвинуть строку, не потерять артикул.
2. Три роли. Юрист смотрит ограничения ЕЭК/ФТС. Инспектор ставит код и пишет, почему соседняя субпозиция отброшена. Координатор сводит риски КТС.
3. Платежи. Пошлина, НДС, ценовой профиль риска. Всё до подачи.
4. XML. Schema-валидированный проект для Альта-ГТД. Подпись и подача остаются у декларанта.

Канон метода на сайте продукта: дока.рус/method/. Тот же разбор у правообладателя: Как ДОКА готовит XML. Перепечатка здесь: /insights/doka-invoice-xml/.

Границы

• Не заменяет декларанта.
• Не гарантирует нулевую КТС.
• Не выносит файлы в публичное облако «для демо».

Старт без выноса ваших инвойсов в интернет: разбор 5 файлов на сайте продукта.

Кто за что отвечает

Про связку с внедрением отдельно: ГК «ФОРОНЕЙ» и продукт ДОКА. Чеклист до любого пилота: as-is.

Павел Наумов