Fedex Logo

Введение 

Regulatory API предназначен для сохранения данных о соответствии товаров нормативным требованиям, которые можно использовать при создании отправления.

Regulatory API поддерживает данные для перечисленных ниже органов регулирования.

  • Комиссия по безопасности потребительских товаров США (Consumer Product Safety Commission, CPSC): данные сертификата соответствия (CoC), подаваемые в качестве отказа от обязательств, ссылки на реестр продукции CPSC или полного сертификата.

  • Комиссия Европейского союза — отмена de minimis: идентификаторы товаров, требуемые в связи с отменой ЕС порога de minimis в размере 150 евро, которая вступает в силу в июле 2026 года, для сопровождения малоценных (стоимостью менее 150 евро) поставок по схеме «бизнес для потребителя», поступающих в ЕС.

Этот API не подает заявки напрямую в Погранично-таможенную службу (CBP) США, Комиссию Европейского союза или другие органы. 

Рабочий процесс, в котором применяется Regulatory API, в целом выглядит описанным ниже образом.

  1. Используйте этот API для сохранения нормативных данных о товаре в соответствии с требованиями конкретного органа регулирования и страны. Требуемая информация может быть разной. Более подробные сведения см. в разделе Создание профиля.
  2. Создайте отправление с помощью Ship API. Обязательно укажите для каждого товара массив regulatoryDetails[], каждый элемент которого должен содержать поля regulationCode, productId и productIdType.
  3. FedEx объединяет сохраненные профили товаров и информацию об отправлениях.
  4. FedEx выступает в качестве ответственного импортера и подает все необходимые нормативные документы от вашего имени.

Дополнительные сведения см. в разделе Использование нормативных профилей и Ship API.

Создание профиля

Гибкость Regulatory API сводит к минимуму количество точек интеграции и централизует хранилище. В каждом профиле используются одни и те же поля верхнего уровня. Данные, связанные с конкретным органом регулирования, хранятся в массиве details[], форма элементов которого определяется параметром RegulationCode.  

Ниже перечислены обязательные поля профиля верхнего уровня.

  • regulationCode*: орган регулирования, к которому относятся сведения. Пример: CPSC или EU_DE_MINIMIS. Значение в этом поле определяет форму элементов для подробных нормативных сведений. 
  • productId*: идентификатор товара продавца или покупателя.
  • productIdType*: тип идентификатора товара. Пример: SKU, PART_NUMBER, REGISTERED_NUMBER, GTIN, UPC, EAN, MPN и OTHER. 
  • countryOfImport*: страна назначения импорта.
  • details[]: форма элементов в этом массиве зависит от органа регулирования, выбранного для отправления. Для отправлений, регулируемых CPSC, он содержит наборы сообщений об отказе от обязательств или ссылок; для отправлений, регулируемых EU_DE_MINIMIS, он содержит идентификаторы производителей. 

* Эти значения используются для сопоставления значений в массиве regulatoryDetails[] запроса Ship API, что позволяет подставить данные из профиля в данные отправления.

Совет: эта структура повторяет запись в массиве commodities[].regulatoryDetails[] Ship API. Запросы Ship API можно заполнять, копируя их непосредственно из сохраненного профиля. Это удобно, если вы отправляете разовое отправление, данные профиля в котором устарели.  

Отправьте POST-запрос на конечную точку Regulatory Profiles, чтобы создать профиль регулирования.

Сведения для различных органов регулирования приведены в разделах ниже. 

Профили CPSC

Regulatory API хранит данные сертификата соответствия (CoC), которые необходимы для CBP и CPSC, а также запись ACE в наборе сообщений PGA. Создайте профиль с полями regulationCode = "CPSC" и countryOfImport = "US".  

В элементе detail[] необходимо заполнить один из трех перечисленных ниже наборов сообщений.

Помимо обязательных параметров regulationCode, productId, productIdType и countryOfImport, передайте наборы сообщений в массиве detail[]:  

  • disclaimMessageSet: данные, необходимые для отказа от обязательств.

    • disclaimCode: A = товар не регулируется CPSC; B = данные не требуются согласно рекомендациям ведомства. 
    • intendedUseCode: основной код и подкод. Пример: "130.003". Дополнительные сведения см. в разделе Коды предполагаемого использования.
    • intendedUseDescription: произвольный текст. Требуется только в том случае, если intendedUseCode = "980.000" (для других целей). 
  • referenceMessageSet: данные, необходимые для ссылки.

    • productVersion: идентификатор версии сертификата товара, связанный с данным сертификатом в реестре продукции CPSC. 
    • certificateId: идентификатор сертифицирующего лица, выданный вам реестром продукции CPSC.
  • fullMessageSet: полные данные сертификата. Полное описание, сведения и примеры см. в информации о конечных точках нормативных сведений. Основные данные включают следующие: 

    • productDetails;
    • manufacturerDetails;
    • lotDetails;
    • certifierEntity;
    • pointOfContact;
    • citationDetails.

Примечание. Управление записями реестра продукции CPSC осуществляется непосредственно через CPSC. Этот API использует идентификаторы реестра CPSC для подачи документов с помощью ссылки, но не создает, не читает и не обновляет записи в реестре CPSC.

Коды предполагаемого использования

Значение intendedUseCode — это шестизначный код (###.###), который сообщает Погранично-таможенной службе (CBP) США и соответствующим ведомствам, для чего предназначен импортируемый товар. Коды определены CBP в Приложении R к ACE CATAIR. В зависимости от набора сообщений CPSC считает действительными для подаваемых электронных документов только определенное подмножество этих кодов. Это поле является обязательным всегда, когда заполнен набор disclaimMessageSet

CPSC распознает восемь базовых кодов: 081, 090, 100, 130, 155, 940, 970 и 980.

Чаще всего для CPSC используется базовый код 130, поскольку данное ведомство работает с потребительскими товарами. При подаче полного набора информации можно использовать только коды с 130.000 по 130.006. Для отказа от обязательств A можно использовать любой подкод 130, кроме 130.001–130.005 (то есть 130.000 или 130.006). Для отказа от обязательств B можно использовать только подкод 130.006.

Профили отмены de minimis ЕС

Regulatory API поддерживает требования в отношении данных, введенные ЕС в связи с отменой порога de minimis в размере 150 евро. Чтобы создать профиль, задайте для параметра regulationCode значение EU_DE_MINIMIS, для countryOfImport — любую из 27 стран ЕС, а также укажите нормативные сведения для данного товара. 

Поле productId содержит буквенно-цифровой идентификатор вашего товара. В ЕС это поле считается SKU продавца.

Помимо обязательных параметров regulationCode, productId, productIdType и countryOfImport, передайте следующие данные в массиве detail[]

  • merchantProductId: идентификатор товара продавца. Этот параметр отличается от productId, если вы используете отдельные идентификаторы на уровне продавца и SKU; в противном случае установите его равным productId.
  • nonStandardManufacturerProductId: внутренний SKU или идентификатор производителя. Пример: SH123456-L. 
  • standardManufacturerProductId: стандартный идентификатор, например GTIN, UPC или EAN. Пример: 01233456789012. Если у товара нет стандартного идентификатора, укажите строковое значение «NA».

Если в профиле EU_DE_MINIMIS не указан ни один из трех идентификаторов, API выдает неблокирующее предупреждение REGP_EU_MISSING_IDENTIFIERS. 

Использование нормативных профилей и Ship API

Вы можете ссылаться на нормативные данные, сохраненные с помощью Regulatory API, из Ship API. Данные из нормативных профилей применяются к отправлениям на этапах после их создания. 

Ниже перечислены стандартные рабочие процессы, в которых используется Ship API и (или) Regulatory API.

  1. Метод на основе профилей. Зарегистрируйте каждый товар один раз с помощью Regulatory API, а затем указывайте только значения productId + productIdType + regulationCode в массиве regulatoryDetails[] для товаров в своем отправлении. Сведения из зарегистрированного профиля будут подставлены в отправление. 

  2. Метод с непосредственным заполнением данных. Для каждого товара в отправлении указываются значения productId + productIdType + regulationCode, а также полностью заполняется массив details[]. Полные данные CPSC не поддерживают возможность непосредственного заполнения; этот метод предназначен только для наборов сообщений CPSC с отказами от обязательств и ссылками, а также для органа регулирования EU_DE_MINIMIS.

  3. Гибридный метод. Вы можете переопределить существующие данные Regulatory API для конкретного отправления. Укажите элементы productId + productIdType + regulationCode и отдельные значения details[]. Непосредственно введенные значения имеют приоритет над данными, сохраненными с помощью Regulatory API. Сведения, не указанные для отправления непосредственно, но содержащиеся в профиле, подставляются из него после создания отправления. 

CLOSE

Response

Copy