Як три сторони підписують е-ТТН: від створення до завершення перевезення

Що перевірено й до якого процесу це стосується

Матеріал перевірено 16 жовтня 2026 року за інструкцією е-ТТН, оприлюдненою офіційним порталом у квітні 2026 року. Описуємо типовий випадок, коли перевезення ініціює відправник, перевізник є окремою стороною, а одержувач приймає вантаж. Для іншої структури операції чи спеціального вантажу перевіряють потрібні ролі й документи окремо. Назва «три сторони» не означає, що в кожній операції обов’язково рівно три фізичні підписувачі.

До першого підпису: узгодьте відповідальних

Складіть список сторін, їхніх уповноважених осіб і контактів на рейс. Упевніться, що реквізити організацій, транспорт, адреси та вантаж походять із погоджених довідників. У внутрішньому регламенті визначте, хто може створити чернетку, хто звіряє фактичне відвантаження, хто підписує та хто перевіряє результат реєстрації. Не передавайте особистий ключ колезі, щоб він «підписав за водія». Роль у програмі та юридичні повноваження перевіряють разом.

Підписання та зміни за офіційною інструкцією

Ініціатор заповнює обов’язкові дані, підписує та реєструє е-ТТН у центральній базі. Після реєстрації пряме редагування змісту не дозволене. Наступний учасник, який погоджується зі змістом, додає свій підпис без зміни номера транзакції. Якщо потрібні зміни, застосовують належний акт; після його статусу SIGNED формується нова транзакція з номером n+1. Це механізм актуального стану тієї самої е-ТТН, а не самовільна заміна документа новим файлом.

Одержувач, ARRIVAL та завершення

При отриманні одержувач доповнює дані про розвантаження й реєструє транзакцію зі своїм підписом у статусі ARRIVAL. Для цього етапу інструкція передбачає окремий виняток із загального порядку змін через акти. Інші учасники мають дві доби після ARRIVAL, щоб за потреби підписати цю версію; зміни оформлюють актом. Через дві доби документ автоматично переходить у FINISHED, де зміни та акти вже не дозволені. Контролюйте фактичні статуси, а не лише наявність третього підпису.

Що перевіряє кожна сторона

Приклад із розбіжністю під час прийняття

Відправлено умовно 100 місць, а на складі одержувача фактично нарахували 98. Різниця — 2 місця. Не виправляйте початковий підписаний XML на 98 так, наче відправник одразу відвантажив саме стільки. Зафіксуйте фактичну подію та оформіть належний акт за процедурою відповідного сценарію; перевірте пов’язану актуальну транзакцію й стан документа. Так зберігається можливість порівняти відвантаження з прийняттям. Хто несе вартість нестачі, визначають за обставинами й договором, а не за самим натисканням кнопки підпису.

Що робити при відмові або технічній помилці

1. Прочитайте конкретний результат реєстрації: відсутній підпис, невірна роль, невідповідна схема та недоступність сервісу — різні причини.
2. До повторного надсилання встановіть, чи перша дія вже виконана, щоб не створити дубль.
3. Перевірте актуальну транзакцію, стан і доступний для неї сценарій, а не редагуйте локальну стару копію.
4. За розбіжностей залучіть відповідальних сторін до оформлення належного акта до завершення дозволених процедур.
5. Після відновлення обміну звірте підписи й статуси в усіх учасників та експортуйте пов’язаний комплект для архіву.

Типові помилки та FAQ

1. Вважати документ юридично «неіснуючим» до підпису одержувача: до прийняття вже є зареєстровані події та підписи.
2. Плутати підпис перевізника з безумовним прийняттям усіх комерційних умов.
3. Переписати вантаж у локальній копії, не застосувавши потрібний акт.
4. Чи всі сторони мають користуватися однією назвою програми? Перевіряйте сумісність авторизованих операторів і фактичний обмін, а не лише збіг інтерфейсу.
5. Чи можна чекати безстроково після ARRIVAL? Ні: в інструкції є дві доби до FINISHED.
6. Чи достатньо PDF для архіву? Зберігайте належний електронний пакет із підписами та пов’язаними актами, не тільки зображення.