eTTN — електронна товарно-транспортна накладна¶

Реалізація електронної ТТН відповідно до законодавства України. Замість паперової накладної — цифровий документ з підписом Ed25519, що передається між учасниками.

1. Призначення¶

Електронна ТТН (eTTN) замінює паперову форму ТТН-1, яка раніше супроводжувала вантаж при перевезенні. Переваги: - Швидке формування (без ручного заповнення формуляра) - Цифровий підпис → юридична сила без друку - Передача між учасниками online (відправник → перевізник → отримувач) - Архівація + швидкий пошук - Інтеграція з податковою системою

2. Учасники документа¶

Сторона	Роль
Відправник (Shipper)	Хто відвантажує товар (звичайно — продавець)
Перевізник (Carrier)	Транспортна компанія / водій
Отримувач (Consignee)	Хто отримує товар (покупець)
Замовник перевезення	Хто платить за перевезення (може = відправник або отримувач)

3. Backend моделі¶

backend/fleet/models/ettn.py:

Модель	Призначення
`ETTNDocument`	Сам документ eTTN (заголовок + рядки)
`ETTNParty`	Учасник документа (Shipper / Carrier / Consignee)
`ETTNTestKey`	Тестові ключі Ed25519 для розробки/підпису

ETTNDocument — ключові поля¶

document_number / document_date
shipper / carrier / consignee → ETTNParty
vehicle → Vehicle
driver → Driver
route_from / route_to — пункти A → B
cargo_lines — JSON або related (опис вантажу)
total_weight / total_volume / total_amount
status — draft / signed_by_shipper / accepted_by_carrier / delivered / signed_by_consignee / archived
shipper_signature — Ed25519 підпис відправника
carrier_signature — Ed25519 підпис перевізника
consignee_signature — Ed25519 підпис отримувача
gps_track — GPS-маршрут (з Wialon або mobile app)

Криптографія¶

Алгоритм: Ed25519 (eliptic curve, швидкий, маленький підпис 64 байти)
Бібліотека: cryptography
Кожен учасник має свій ключ (приватний → у нього, публічний → у системі для верифікації)
Хеш документа підписується → зміна будь-якого поля інвалідує підпис

4. Frontend (ERP)¶

Сторінка: ETTNPage.tsx (1077 рядків) — /fleet/transactions/ettn-documents

Функції: - Список документів (з фільтрами по статусу / даті / контрагенту) - Форма створення (з імпортом даних з Waybill або Invoice) - Підписання (input приватного ключа або з ETTNTestKey для тестів) - Перегляд статусу + історії підписань - Завантаження PDF / XML версії - Передача іншому учаснику (поки manual — у v2 буде через спільний реєстр)

5. Workflow¶

1. Відправник створює eTTN на базі GoodsShipment + Waybill:
   └── Поля автозаповнюються
   └── Status: draft

2. Підписання відправником:
   └── Ed25519 sign по hash(document_data)
   └── Status: signed_by_shipper

3. Передача перевізнику (online або через QR-код)
   └── Перевізник перевіряє підпис відправника
   └── Підписує своїм ключем → Status: accepted_by_carrier

4. Перевезення (опц. з GPS-треком)
   └── Інтеграція з GPS Wialon / Driver App

5. Прибуття до отримувача:
   └── Отримувач перевіряє вантаж
   └── Підписує приймання → Status: signed_by_consignee
   └── Status: delivered

6. Архівація → archived

6. Інтеграція з документами Essentials¶

З GoodsShipment / Invoice¶

При проведенні видаткової накладної — кнопка "Створити eTTN": - Заповнюються товарні рядки з GoodsShipmentLine - Підставляється Waybill (якщо є) - Поля учасників — з Client + Organization

З Waybill (Fleet)¶

При створенні Waybill з вантажним замовленням — eTTN може створюватись автоматично, з прив'язкою до конкретного рейсу.

7. Тестове середовище¶

ETTNTestKey — таблиця тестових ключів для dev/QA: - Зручно для тестування підписів без реальних USB-токенів - В production — приватні ключі не зберігаються у системі (в ідеалі — на ключовому носії)

8. Регуляторні питання¶

Поточна реалізація — proof-of-concept з Ed25519. У production-edition потрібна:
Інтеграція з УЦСК (КЕП) — вимога українського законодавства для юридично значущих підписів
Передача документів через офіційні шлюзи (M.E.Doc, Vchasno, тощо)
Для внутрішнього використання (B2B, де сторони довіряють один одному) — Ed25519 достатньо

🔮 Deferred / Ideas¶

КЕП-інтеграція через УЦСК¶

Мотивація: обов'язкова вимога для юридично значущого документообігу в Україні Чому відкладено: потрібна сертифікація + інтеграція з токенами (Diia.Signature, IIT) Trigger: клієнт з вимогою юридично значущих eTTN

Інтеграція з ЦБД ТТН (НДЛБ)¶

Мотивація: Україна планує єдину базу електронних накладних Чому відкладено: API ще не релізнутий державою Trigger: запуск державного реєстру

QR-код для миттєвої передачі¶

Мотивація: на дорозі — водій показує QR, інспектор сканує → бачить eTTN Чому відкладено: UI для генерації + перевірки QR Trigger: дорожні перевірки + вимога ДПС

Mass-signing для пачок документів¶

Мотивація: оптові відвантаження — 50+ накладних/день Чому відкладено: потрібен batch-sign UI + safety Trigger: клієнт з великим обсягом

Multi-language eTTN (export)¶

Мотивація: експортні перевезення — потрібен документ російською/англійською Чому відкладено: необхідні шаблони для перекладу Trigger: експортний клієнт