Response Examples & Error Handling

Elise Basic Validation

This process makes sure that the required fields are provided. If any of the required fields are missing or are invalid, this process throws Elise Basic Validation Exception.

Send Method Validation

This process is responsible for checking that email recipients exist when the provided send method requires them. Supported Send Methods are:

E E-mail

A Archive

M SMS/Viber

C Email and SMS/Viber

If requirements are not fulfilled, the process throws Elise Basic Validation Exception.

Issuer Authentication

This process is responsible for validating that document issuer is an active subscriber with a valid API key. The process retrieves the issuer from the database and updates the software cache, adding the current issuer. If issuer is not found, provided API key is invalid, or anything else unexpected happens, it throws an Elise Authentication Exception.

Conversion to Elise Core

This process converts an object to Elise Core Document. The conversion takes into consideration any Parsing Rules that are registered to the corresponding conversion type. Those parsing rules can apply to all companies, or just the issuer company. The Elise Core Document that is produced is treated as the “one and true” document. Any process that follows depends on this document. Any exception during the conversion procedure, results in an Elise Conversion Exception.

Uniqueness Validation

This process ensures that the incoming document has not already been successfully sent to the service. In order to do so, it produces the incoming document’s UID (as described by IAPR documentation) and checks the issuer’s database for any document with the same UID.
If document is found to have already sent to the service, an Elise Duplicate Invoice Exception is thrown.

Conversion to IAPR

This process converts an Elise Core Document to AadeBookInvoiceType, as described by IAPR documentation. The conversion takes into account all issuer’s Parsing Rules, alongside the generic parsing rules that correspond to this conversion type. Any exception during the conversion procedure, results in an Elise Conversion Exception.

Signature Data Validation

This process is included when Documents sent to the API contain the XML for IAPR. It is responsible for validating that the data sent to IAPR in field aadeXml are consistent with the corresponding data in the Elise Core Document. Fields checked for consistency are the following:

Issuer Vat,

Issuer Branch Code,

Invoice Type

Series

Number

Total Vat Amount

Counter Party Vat

Total Gross Amount (this check is optional and by default skipped, due to IAPR’s inability to perform correct checks)

Postage to IAPR

This process is handled by the “AadeMyData” Module. Any errors during this process, which includes pre-validation and actual IAPR validation steps, result in an IAPR Exception.

IAPR response handling

This process is responsible for updating the incoming document with data provided by

IAPR: Authentication Code, Mark, UID

Elise: Public Salt, Public Signature, Private Signature

Data Persistence

This multi part process is responsible for persisting all data that need to be stored. It handles the following data:

In case of outgoing invoices:

Saves Elise Core Document in Azure Blob Storage

Saves Invoice Counter Party in SQL database

Updates POS activity in Azure Table Storage

Updates Awaited Invoices (Offline Module)

In case of incoming invoices:

Saves Invoice issuer in SQL database

In both cases:

Saves raw document in Azure Blob Storage (the raw data of the request)

Saves document’s metadata in SQL databases of both issuer and counter party (if same database only one copy is created).

If any unhandled error occurs during these processes, an Elise SQL Storage Exception is thrown.

Notification Service

This service is responsible for adding the incoming document to the notification queue. Entries are read and emails are produced and sent to inform the document’s counterpart that a new invoice has been sent. Any errors during this process, result in Elise Notification Service Exception.

**Success Response **

If no preceding process throws an exception, the API responds with a HTTP-Created Status code (201). Alongside the public document url, an object is sent back to the caller, including:

Success status, set to true

Message informing that all processes have successfully completed

Integrity Signature

Signature

UID

Mark

AuthenticationCode

MyDataResponse

Responses

- 201 - Success
The document has been transmitted successfully

- 400 – Bad Request
There is an error in the data in the payload

- 401 - Unauthorized
The authentication failed

- 408 - Request Timeout
IAPR service is down

- 409 - Conflict
The document has already been transmitted to IAPR

- 5xx - Server Error
There is an exception to our server

Mandatory Metadata Display on Invoice Visualization

When visualizing an invoice document, the following metadata must be clearly and visibly displayed:

- MARK: The unique identifier number assigned to the invoice by the tax authority.

- Signature: The digital signature verifying the authenticity of the invoice.(Defined in the API response as: authenticationCode)

- UID: The unique identifier of the document.

- Service Supplier: The name or identifier of the certified e-invoicing service provider.

- Certification Number: The official certification number of the service provider, as issued by the competent authority.

📌

These fields are mandatory and must appear in a readable and standardized manner on all rendered invoice views.

Response Examples & Error Handling

Responses#

Mandatory Metadata Display on Invoice Visualization#

Responses

Mandatory Metadata Display on Invoice Visualization