Guides
Start typing to search…

ERP integration flow

A robust ERP integration must track statuses of outbound documents and mark all inbound documents as having been processed (business documents, as well as response documents)

Fetching of inbound documents (billing document or response documents), it is done in the classical way (polling, acting on webhooks for direct integration, or receiving via the eB2B protocol for service providers).

When querying the pending inbound documents, they can be differentiated based on the transactionGroup parameter and the business logic based on it:

  • SubmitInvoice for the inbound invoice. Use GET /transaction/submit-invoice to fetch.
  • CorrectWithCredit for the inbound credit note. Use GET /transaction/correct-with-credit to fetch.
  • SubmitMessageResponse for the MLR and eMLR documents (extended MLRs). Use GET /transaction/submit-message-response to fetch.

Supplier flow

ERP system on supplier side must, after submitting the invoice, be aware of the tax administration's response for the reporting of that invoice.

Later on, when payment is received, they must register the payment of the invoice and be aware of the tax administration's response related to that registration.

In FiskApplicajia, they should have full overview of what has been reported.

More details are provided in the sequence diagrams below.

flowchart LR
	A(Submit invoice/credit note) --> B(Process tax response)
  B --> C(Register payment)
  C --> D(Process payment response)

Customer flow

ERP system on customer side must, after importing the invoice, be aware of the tax administration's response for the reporting of that invoice.

If customer wants to reject an invoice, they must register the rejection of the invoice and be aware of the tax administration's response related to that registration.

In FiskApplicajia, they should have full overview of what has been reported.

More details are provided in the sequence diagrams below.


flowchart LR
        A(Import invoice/credit note) --> B(Process tax response)
        B -.-> C(Register rejection )
        C -.-> D(Process rejection response)
  style C opacity:0.5, stroke-dasharray: 5 5
  style D opacity:0.5, stroke-dasharray: 5 5

Sending e-invoices (supplier)

Flow between ERP system and Unimaze for outbound flow using MLR response messages.

Processing the content of MLR and eMLR documents is optional before marking them as delivered (imported), but at least pay attention to the final statuses AP (accept) and RE (reject):

📘

Submitting the e-tax report can happen simultaneously while the invoice is delivered to the customer (diagram is simplified),

  • It can be assumed that if Tax Administration rejects the invoice on the supplier side, the same will happen on the customer side.
sequenceDiagram
    autonumber
    participant E
    participant U
    participant C
    participant TA
    box Invoice issuer
    participant E as ERP (Supplier)
    end
    box Access Point &  External systems
    participant U as UNIMAZE
    participant C as ERP (Customer)
    participant TA as Tax Admin
    end
    activate E
    E->>U: POST /submit-invoice, POST correct-with-credit
    U-->>E: Fetch MLR (acknowledgment)
    E-->>U: POST /mark-as-delivered (for the MLR)
    deactivate E
    activate U
    U->>C: Deliver e-invoice
    U-->>E: Fetch MLR (accept/reject)
    deactivate U
    activate E
    E->>U: POST /mark-as-delivered (for the MLR)
    deactivate E
    activate U
    U-->U: Generate e-action docment (MLA) 
    U->>TA: Deliver e-tax report
    TA->>U: Receive e-tax report result
    deactivate U
    activate E
    U->>E: Fetch inbound eMLR (signed accept/reject from Tax Admin)
    U-->>E: Fetch MLA (unsigned e-action)
    deactivate E

Receiving invoices (customer)

Flow between ERP system and Unimaze for outbound flow using MLR response messages.

Processing the content of MLR and eMLR documents is optional before marking them as delivered (imported), but at least pay attention to the final statuses AP (accept) and RE (reject):

📘

For the same reason as mentioned in the previous section, an invoice that is rejected by the Tax Administration, should be considered not issued as a valid invoice, and should not be paid.

sequenceDiagram
    autonumber
    participant E
    participant U
    participant C
    participant TA
    box Invoice receiver
    participant E as ERP (Customer)
    end
    box Access Point &  External systems
    participant U as UNIMAZE
    participant C as ERP (Supplier)
    participant TA as Tax Admin
    end
    activate U
    C->>U: Receive e-invoice
    U->>E: Fetch Invoice/Credit Note (acknowledgment)
    deactivate U
    activate E
    E-->>U: POST /mark-as-delivered (for the invoice)
    deactivate E
    activate U
    U-->U: Generate e-action docment (MLA) 
    U->>TA: Deliver e-tax report
    TA->>U: Receive e-tax report result
    U->>E: Fetch inbound eMLR (signed accept/reject from Tax Admin)
        deactivate U
    activate E
    U-->>E: Fetch MLA (unsigned e-action)
    E->>U: POST /mark-as-delivered (for the eMLR)
    deactivate E

Register a payment (supplier)

The supplier must register the payment of an invoice, full or partial payments, once received.

The flow between ERP system and Unimaze is as described below.

sequenceDiagram
    autonumber
    participant E
    participant U
    participant TA
    box Invoice issuer
    participant E as ERP (Supplier)
    end
    box Access Point &  External systems
    participant U as UNIMAZE
    participant TA as Tax Admin
    end
    activate E
    E->>U: POST /register-payment
    deactivate E
    activate U
    U-->U: Generate e-action docment (MLA) 
    U->>TA: Deliver e-tax payment registration
    TA->>U: Receive e-tax payment registration result
    deactivate U
    activate E
    U->>E: Fetch inbound eMLR (signed accept/reject from Tax Admin)
    U-->>E: Fetch MLA (unsigned e-action)
    deactivate E

Register a rejection (customer)

The customer must report to the Tax Administration any invoices that are rejected.

📘

It is not possible to receive an event on the supplier side from the network when invoices are rejected by the customer.

  • In most cases, customer and supplier interact manually regarding the dispute of invoices.
  • The information about rejected invoices is available in the Tax Admin FiskApplicajia (if it is not there already).

The flow between ERP system and Unimaze is as described below.

sequenceDiagram
    autonumber
    participant E
    participant U
    participant TA
    box Invoice receiver
    participant E as ERP (Customer)
    end
    box Access Point &  External systems
    participant U as UNIMAZE
    participant TA as Tax Admin
    end
    activate E
    E->>U: POST /register-rejection
    deactivate E
    activate U
    U-->U: Generate e-action docment (MLA) 
    U->>TA: Deliver e-tax rejection registration
    TA->>U: Receive e-tax rejection registration result
    deactivate U
    activate E
    U->>E: Fetch inbound eMLR (signed accept/reject from Tax Admin)
    U-->>E: Fetch MLA (unsigned e-action)
    deactivate E

Updated 15 days ago