RO e-Transport Service

Access info

Usage

The RO e-Transport Service enables callers to submit mandatory e-Transport declarations to Romanian National Agency of Fiscal Administration (ANAF). e-Transport declarations are mandatory for:

• importers whose name features on the import customs declaration and exporters whose name features on the export customs declaration, if the import/export operation involves high fiscal risk goods;
• beneficiaries in Romania, in case of purchases of high fiscal risk goods within EU;
• suppliers in Romania, in case of internal shipments or deliveries within EU that involve high fiscal risk goods;
• warehouse keepers, if the high fiscal risk goods are the object of deliveries within EU that transit Romania. This concerns goods unloaded on Romanian territory either for storage or for the purpose of creating a new shipment, as well as goods loaded from Romanian territory after storage or after a new shipment has been created.

The object of e-Transport monitoring are road vehicles with a maximum mass of at least 3.5 tons, loaded with high fiscal risk goods exceeding 500 kg of gross weight or the total value exceeding 10000 RON (Romanian Lei).

The list of high fiscal risk goods, as well as the most recent regulations pertaining to e-Transport reporting system, are established by the relevant Romanian legislation, which is available (in Romanian language) at https://mfinante.gov.ro/ro/web/etransport/legislatie.

From the technical point of view, the e-Transport reporting involves sending any of the following transaction types (as HTTP requests) to the ANAF API:

• Notification. The notification informs ANAF about a planned shipment; it includes an XML file with detailed information about the shipment, including the vehicle details and type and quantity of transported goods. In return, on success, ANAF responds with a UIT code (in Romanian, Unique Transport Identification code) and a signed XML inside a zip archive. The vehicle driver must have the UIT code before starting the route (or before reaching the Romanian customs office, if applicable) and provide it to the relevant authorities on request.
• Confirmation. The confirmation is submitted to ANAF by the recipient of high fiscal risk goods to confirm receipt, partial receipt, or non-receipt of high fiscal risk goods;
• Modification. This refers to modification of transport details, as long as it occurs within the legally permitted period (for example, before the vehicle started the route, or before it has reached the Romanian customs office);
• Modification of vehicle. This refers to modifying any details about the vehicle that will carry out the transport.
• Deletion. This request permits deletion of incorrectly submitted notifications.

As is the case of other SBS services, the RO e-Transport Service interacts with ANAF on your behalf and provides an abstraction layer to simplify ANAF reporting. More specifically, it enables you to perform the following tasks:

• manage authentication and secure access to ANAF;
• submit new e-Transport declarations to ANAF and obtain the Unique Transport Identification codes (UIT codes);
• modify existing declaration data, including vehicle information
• delete declarations submitted erroneously and thus cancel previously obtained UIT codes
• send e-Transport confirmation transactions
• store data related to each shipment.

There are two versions of e-Transport API provided by ANAF:

• v1: legacy version which is still in use at the time of updating this documentation (3 May 2023)
• v2: newer version, available from 17th of February 2023

This documentation covers reporting for version 2 only.

Prerequisites

Before using this service, note the following prerequisites:

1. The organization(s) for which e-Transport reporting takes place done must exist in the SBS system. You can add new organizations programmatically through the Organizations Service, or from the SBS Portal.
2. Any application that communicates with ANAF, including your application, requires authorization with ANAF. Therefore your app must be configured to handle OAuth 2.0 authorization with ANAF, as described in Configure ANAF Oauth 2.0 secrets.
3. Once the OAuth 2.0 secrets are configured for your app (see previous bullet), you must authorize with ANAF the organization(s) for which e-Transport reporting takes place. You can perform the authorization either programmatically or from the SBS Portal. To authorize an organization programmatically, run the generateAuthorizationRequest mutation of the RO ANAF OAuth Service. For instructions about performing the authorization process from the SBS Portal, see Managing ANAF Authorizations.

How it works

You can submit e-Transport declarations either to the ANAF test API or to the production API. To configure which API should be used, modify your application settings from the SBS Console, as described in Configure ANAF Environment.

To submit a new e-Transport declaration to ANAF, run the notify mutation. The response includes, among other fields, a unique shipment ID that you will need to track the declaration status in subsequent requests. To status field of the response provides the status of the declaration. Note that, immediately after submission, the declaration has the status UPLOADED. This means that is has been uploaded to ANAF but there is no indication yet if it was accepted or rejected by ANAF.

To check for the shipment declaration’s outcome, wait at least 5 minutes, and then run the shipment query, for example:

query shipment ($organizationId:ID!, $id:ID!) {
    shipment(organizationId:$organizationId, id:$id) {
        id
        organizationId
        uit
        stages {
            id
            type
            xmlFile { id, downloadUrl }
            uploadDate
            uploadId
            downloadId
            status
            uploadedToTestEnvironment
            errors
            createdAt
        }
        status
        errors
        createdAt
    }
}

Make sure to replace the input variables as applicable.

{
  "organizationId": "YOUR_ORGANIZATION_ID",
  "id": "YOUR_SHIPMENT_ID"
}

The response provides the status of the declaration in the status column. The possible values at this stage are as follows:

• UPLOADED - see above.
• REJECTED - the declaration has been rejected by ANAF. For the error details, please check the messages field of the response, or the response XML.
• PROCESSED - ANAF has accepted the shipment declaration.

Note that the list of values listed above is not exhaustive; if you take subsequent action against an existing declaration (like running a modify or delete mutation for the same declaration), then additional values may appear, as described in the status field of the Shipment type.

Importantly, the field stage of a Shipment represents the state of the shipment declaration at a particular point of time during the its lifecycle. There may be multiple stages for the same declaration, and each stage indicates the kind of operation taken against the declaration (like NOTIFICATION, MODIFICATION, DELETION, or CONFIRMATION).

For example, immediately after you create a new declaration, the declaration has a stage of type NOTIFICATION which has the status UPLOADED. After a few minutes, if the declaration is rejected by ANAF, the stage status (and the overall declaration status) will change to REJECTED. If the declaration is accepted by ANAF, then the stage status (and the overall declaration status) will change to PROCESSED.

Let’s assume that a declaration has been rejected by ANAF. In this case, you will likely want to submit a modify mutation with corrected data for the same declaration. Consequently, a new shipment stage will be created of type MODIFICATION. This stage will go through the same statuses as the initial submission. That is, it will first be in the UPLOADED status, and after roughly 5 minutes it will get either the status PROCESSED or REJECTED.

The same applies if you delete an existing declaration, through a call to the delete mutation. A new shipment stage will be created of type DELETION, and its status will initially be UPLOADED and subsequently become PROCESSED or REJECTED. Depending on the delete operation outcome, the overall declaration status in this case will become either DELETED or DELETE_FAILED.

The same logic also applies if you confirm an existing declaration through a call to the confirm mutation. Namely, when you confirm a declaration, a new shipment stage of type CONFIRMATION will be created, and its status will initially be UPLOADED, and will subsequently become CONFIRMED or REJECTED. Depending on the confirmation operation outcome, the overall declaration status in this case will become either CONFIRMED or CONFIRMATION_FAILED.

Queries

messages

Returns a list of information messages available from ANAF for the organization supplied as input.

Arguments

MessagesFilter input

Result

MessagesResult type

Message type

ErrorMessage type

shipment

Returns information about a single shipment.

Arguments

Result

Shipment type

ShipmentStage type

File type

shipments

Returns information about all shipments that satisfy the filter criteria.

Arguments

ShipmentsFilter type

Result

ShipmentsResult type

version

Returns the API version.

Mutations

confirm

Submits a confirmation declaration to ANAF. There are two possible scenarios when this action takes place:

1. The recipient of goods confirms complete or partial receipt of goods, based on the unique transport identification code (UIT). In this case, the mandatory input arguments are organizationId, uit, and input.

   At the time when this documentation is updated (15.05.2023), ANAF does not yet provide technical means to submit confirmation declarations for a given UIT.

2. The importer of goods is the same as the declarer and they confirm receipt of goods based on a shipment ID. In this case, the mandatory input arguments are organizationId, id, and input.

Arguments

ConfirmInput input

Result

See the Shipment type.

delete

Submits to ANAF a declaration requesting deletion of a previously submitted declaration.

Arguments

Result

See the Shipment type.

modify

Submits to ANAF a declaration requesting modification of a previously submitted declaration.

Arguments

ShipmentInput input

BunuriTransportateType input

PartenerComercialType input

DateTransportType input

LocatieType input

DocumenteTransportType input

NotificareAnterioaraType input

Result

See the Shipment type.

modifyVehicle

Submits to ANAF a declaration requesting modification of the vehicle information on a previously submitted declaration.

Arguments

ModifyVehicleInput input

Result

See the Shipment type.

notify

Submits a notification declaration to ANAF, with the purpose of obtaining a unique transport identification code (UIT).

Arguments

Result

See the Shipment type.

Example

The following code listing illustrates sending a new e-Transport declaration to ANAF:

mutation notify($organizationId:ID!, $input:ShipmentInput!) {
  notify(organizationId:$organizationId, input:$input) {
    id
    organizationId
    uit
    stages {
      id
      type
      xmlFile { id downloadUrl }
      uploadDate
      uploadId
      downloadId
      status
      uploadedToTestEnvironment
      errors
      createdAt
    }
    status
    errors
    createdAt
  }
}

Make sure to replace the input variables as applicable. Note that YOUR_ORGANIZATION_ID must be the ID of an ANAF-authorized organization.

{
  "organizationId": "{{organizationId}}",
  "input": {
   	"codTipOperatiune": "30",
    "bunuriTransportate": {
      "codTarifar": "0202",
      "denumireMarfa": "Marfa",
      "codScopOperatiune": "101",
      "cantitate": 1323,
      "codUnitateMasura": "10",
      "greutateNeta": 45,
      "greutateBruta": 45,
      "valoareLeiFaraTva": 9987
    },
    "partenerComercial": {
      "codTara": "RO",
      "cod": "1590082",
      "denumire": "Partener comerical"
    },
    "dateTransport": {
      "nrVehicul": "B111ABC",
      "codTaraTransportator": "RO",
      "codTransportator": "38575952",
      "denumireTransportator": "Transportator",
      "dataTransport": "2023-12-20"
    },
    "locIncarcare": {
        "codJudet": "CT",
        "denumireLocalitate": "Constanta",
        "denumireStrada": "Stejarului"
    },
    "locDescarcare": {
        "codJudet": "BV",
        "denumireLocalitate": "Brasov",
        "denumireStrada": "Independentei"
    },
    "documenteTransport": {
      "tipDocument": "30",
      "dataDocument": "2023-10-05"
    }
  }
}

Appendices

List of operation types

List of county codes

List of border crossing points codes

List of customs office codes

Rules for reporting location, customs office, and border crossing point

The fields locIncarcare (loading location), locDescarcare (unloading location), codPtf (border crossing point), and codBirouVamal (customs office) provide information about where the route starts and ends. These fields must be reported based on the operation type (codTipOperatiune), according to the table below: