У пилота электронного коносамента есть перевозчик, но нет владельца передачи обслуживания: готов ли запрос API?
Определите, заблокирован ли пилотный проект DCSA eBL в инструкциях по доставке, выдаче транспортных документов, цепочке подтверждения или сдаче, прежде чем определять масштаб одного запроса на подключение API.
Сигналы для наблюдения
- Перевозчик и одна платформа электронного коносамента названы, но одно состояние документа не доходит до следующей стороны.
- Запрос определяет, касается ли сбой SI+TD, выдачи, цепочки подтверждения или сдачи.
- Пилотное тестирование имеет идентификатор документа, среду, подотчетного владельца передачи и дату принятия решения.
Пилотный электронный коносамент не готов, поскольку у перевозчика есть конечная точка. Запрос API становится действенным, когда группа называет тип документа, точное состояние жизненного цикла, в котором произошел сбой, обе платформы, удостоверение, разрешенное к действию, ожидаемое подтверждение и владельца датированного приемочного теста. Выпуск, одобрение и сдача оригинального счета — это разные процедуры передачи.
Руководитель по развитию бизнеса в сфере интеграции торговых документов сталкивается с этой путаницей в авторизованных Telegram-группах перевозчиков, экспедиторов, банков и поставщиков программного обеспечения для грузоперевозок. Полезный Signal — это сбой на конкретном этапе передачи документа, а не сама фраза «интеграция eBL». Если увидеть его на день позже, можно пропустить рассмотрение пилотного проекта; если слишком рано передать запрос инженерам, они начнут обсуждать конечную точку API, пока покупатель ещё решает, какая платформа или правовая база регулирует документ.
Этот иллюстративный составной пример не является реальной записью о сделке, клиенте или передаче:
“Перевозчик поддерживает DCSA eBL. Экспедитор получает черновой вариант, банк не видит подтверждения. Нужна помощь API до пятничного пилотного проекта”.
Перевозчик и две стороны присутствуют, но сообщение не идентифицирует тип счета, идентификатор транспортного документа, платформу eBL, держателя, индоссамента, правовую основу, руководство по внедрению, версию API, среду, авторизацию, ожидаемое событие или то, должен ли банк получить документ в этот момент.
Стандарт DCSA не объединяет четыре передачи обслуживания в одну.
В Стандартная страница коносамента DCSA поясняется, что его инициатива цифровой торговли распространяется на оригинальные коносаменты и морские накладные. Он использует интерфейсы прикладного программирования (API) с открытым исходным кодом для поддержки прямой обработки стандартизированных данных коносамента.
В Портал разработчиков DCSA перечислены отдельные руководства по реализации для:
- Инструкции по доставке плюс транспортный документ (SI+TD);
- Выдача коносамента;
- Цепочка подтверждения коносамента; и
- Сдача коносамента.
SI означает инструкции по отправке, данные, которые грузоотправитель предоставляет для подготовки транспортного документа. ТД означает транспортный документ. Разделение руководств является полезным предупреждением: успешный обмен черновыми документами сам по себе ничего не говорит о выдаче, истории передачи или сдаче.
DCSA также сообщает, что работает с поставщиками решений eBL над технической и юридической совместимостью, необходимой для цифровой передачи оригиналов коносаментов между платформами и заинтересованными сторонами. Ответ API сам по себе не может подтвердить переход права собственности, полномочия или признание в рамках применимого правового режима.
Запишите состояние перед открытием документации API.
Выберите один идентификатор транспортного документа и спросите: в каком состоянии он должен находиться сейчас, кто контролирует это состояние и какая сторона должна видеть следующее состояние?
Для проекта транспортного документа источником могут быть данные инструкции по отгрузке, а ожидаемым результатом — черновик, созданный перевозчиком. При выдаче вопрос заключается в том, выдал ли перевозчик документ через согласованную платформу соответствующей стороне. Для цепочки одобрения возникает вопрос, совершил ли уполномоченный текущий владелец действительное действие, которое может отследить следующая сторона и платформа. Для передачи ожидаемое подтверждение и действие оператора связи снова различны.
Не пишите в качестве дефекта «банк этого не видит». Напишите: «После того, как держатель A подтвердил документ с идентификатором X на платформе P в момент T, платформа Q не предоставила ожидаемую запись цепочки одобрения авторизованному субъекту B». Эта формулировка показывает, какие доказательства до сих пор отсутствуют, не утверждая, что одобрение имело юридическую силу.
Перевозчику принадлежит только часть передачи
Перевозчик может самостоятельно создавать и выдавать транспортные документы в тестируемом потоке. Он не является автоматически владельцем учетной записи внешней платформы, личности текущего владельца, прав банка, сопоставления другого поставщика или юридического соглашения между платформами.
Создайте книгу передачи обслуживания с одной строкой на переход:
| Переход | Владелец источника | Владелец места назначения | Доказательства, которые нужно сохранить |
|---|---|---|---|
| СИ для составления ТД | Отправитель/экспедитор и перевозчик | Служба доставки документов | Ссылка SI, идентификатор TD, результат проверки, черновик подтверждения |
| Черновик выданного документа | Перевозчик | Именованный получатель/платформа | запрос на выдачу, подпись или подтверждение, временная метка, событие принятия |
| Текущему владельцу следующему держателю | Уполномоченный держатель/платформа | Приемный держатель/платформа | индоссаментное действие, идентичность, состояние цепочки, взаимное подтверждение |
| Подчиниться действию перевозчика | Держатель/платформа | Перевозчик | запрос на сдачу, статус, ответ перевозчика и окончательное решение |
| Таблица не является универсальным юридическим распределением. Это пилотный рабочий лист. Контракт, правила платформы, тип документа и юрисдикция могут изменить круг лиц, которым разрешено действовать. |
Отдельные три класса отказов
Ошибка данных: необходимое поле транспортного документа отсутствует, недействительно или сопоставлено с неправильным термином. Сохраните точную ошибку проверки и версию полезных данных.
Ошибка идентификации или авторизации: ожидаемый субъект не может получить или выполнить действие над документом. Сохраните тему, роль, права, область действия токена, владельца документа и код ответа, не раскрывая учетные данные.
Сбой в совместимости или юридических границах: обе системы обрабатывают свои локальные записи, но состояние документа или распознаваемое действие не пересекают платформы, как предполагалось. Сохраните пару платформ, управляющее соглашение, состояние цепочки и взаимные события. Юрисконсульту или оператору платформы, возможно, потребуется принять решение о следующем шаге, прежде чем инженерные специалисты изменят код.
Ответ 200 может сосуществовать с неправильным состоянием жизненного цикла. И наоборот, ответ 403 может показать, что граница авторизации работает так, как задумано. HTTP 200 и 403 — это коды веб-ответов для успешного и запрещенного доступа; ни один из них не указывает, кто на законных основаниях владеет оригинальным счетом.
Запустите одно приемочное тестирование полного жизненного цикла
Пилотный пакет должен содержать:
- тип документа, идентификатор транспортного документа и текущее состояние жизненного цикла;
- исходная/назначенная платформа и тестовая среда;
- соответствующее руководство по реализации DCSA и версия;
- Идентификаторы, роли и области авторизации;
- метки времени запросов, ответов и событий;
- ожидаемое и фактическое подтверждение; и
- технический владелец, владелец платформы, юридический владелец и дата принятия решения.
Используйте синтетический или соответствующим образом защищенный тестовый документ. Не размещайте торговые данные клиентов, учетные данные, изображения оборотных документов или личные данные в общедоступной группе.
Предложение о приемке должно быть наблюдаемым: «Уполномоченный держатель подтверждает тестовый документ X на платформе P; платформа Q записывает одно и то же состояние цепочки для поименованного получателя; обе системы возвращают согласованные взаимные события; перевозчик может продолжить следующее определенное действие». Каждое предложение может пройти или не пройти независимо.
Для владения таможенным отчетом сравните Статья о маршрутизации отклонения ICS2. Запрос на юридически обязательную классификацию принадлежит маршрут принятия решения о тарифах, а время установки на судне — испытание проекта морского сообщения.
TOP Prospect может соединять неполные фрагменты из групп, которые пользователь намеренно подключает и имеет к ним доступ, сохранять источник и время, удалять очевидные дубликаты и выдавать кандидата на рассмотрение человека. Он не может прочитать платформу eBL, установить название документа, аутентифицировать владельца, передать вексель, связаться с автором или объявить об успешном пилотном проекте. страница цен показывает рабочий процесс обнаружения без расширения этих границ.
Исходное сообщение становится кандидатом на разработку только после того, как команда заменит фразу «банк не видит подтверждения» одним неудачным переходом, одним идентификатором документа, двумя названными платформами, ожидаемой взаимной записью и владельцем пятничного решения.
Часто задаваемые вопросы
Охватывает ли стандарт коносамента DCSA как оригинальные, так и морские накладные?
Да. DCSA заявляет, что ее инициатива по цифровой торговле и стандарт коносамента применимы как к оригинальным коносаментам, так и к морским накладным, хотя их юридические и эксплуатационные последствия по-прежнему различаются.
Достаточно ли одного API DCSA для полного жизненного цикла электронной накладной?
Нет. Портал разработчиков DCSA разделяет руководства по реализации инструкций по отгрузке, а также транспортных документов, выдачи, сдачи и цепочки подтверждения. Пилот должен назвать интерфейс и указать, что он тестируется.
Доказывает ли соответствие технического API законную передачу права собственности?
Нет. DCSA отличает стандартизированные данные и процессы от технической и юридической совместимости, необходимой для цифровой передачи оригиналов счетов между платформами и заинтересованными сторонами.
Что делает запрос на подключение готовым к разработке?
Укажите тип и идентификатор документа, исходную и целевую платформу, состояние жизненного цикла, версию API или события, субъекты идентификации и авторизации, ожидаемое подтверждение, тестовую среду, владельца и дату принятия решения.
Источники и дополнительное чтение
Как обнаруживается Signal, заслуживающий внимания
Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.
