Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storecove - When to send what #10

Open
PatrickVHL opened this issue Oct 10, 2021 · 1 comment
Open

Storecove - When to send what #10

PatrickVHL opened this issue Oct 10, 2021 · 1 comment

Comments

@PatrickVHL
Copy link
Contributor

MLRs are used between C2/C3 and IRs between C1/C4.

• C1 SHOULD NOT receive MLRs
• C4 SHOULD NOT send MLRs
• C1 MAY receive IRs
• C4 MAY send IRs
• C3 MUST send an MLR RE when a document contains errors that make it undeliverable to C4. Not only schematron errors, but could also be things like invalid VAT %, missing OrderReference etc. There is no point bothering C4 with that. Especially if C4 cannot send IRs.
• MLR ABs/APs MAY be sent. but I propose we change that to MLR ABs/APs SHOULD NOT be sent
• MLR ABs/APs do not add value, but they do add confusion. Dutch law uses the “ontvangst theorie” which means that once the invoice was delivered to C3 and a digital signature was received by C3 for this then that is enough. Sending MLR APs/ABs can only serve to confuse the sender. Should they wait for one or not?

@PatrickVHL
Copy link
Contributor Author

Could be useful to explicitely state the missing starting points in the relevant paragraphs.
https://github.com/peppolautoriteit-nl/Invoice-Processes-Draft/blob/main/Invoice_to_Payment_Process/Invoice_to_Payment_Process.md#321-scope
https://github.com/peppolautoriteit-nl/Invoice-Processes-Draft/blob/main/Invoice_to_Payment_Process/Invoice_to_Payment_Process.md#331-scope
The following statements are made within the document:
C1 MAY receive MLRs (see bullet 2 of 3.2.1)
C4 SHOULD NOT send MLRs (see bullet 2 of 3.2.1 but might need an extra bullet?)
C1 MAY receive Irs (see bullet 1 of 3.3.2 but might need a more explicit introduction inside the scope section 3.3.1)
C4 MAY send Irs (see bullet 1 of 3.3.2 but might need a more explicit introduction inside the scope section 3.3.1)
C3 MUST send an MLR RE when a document contains errors, but this should be limited to the scope defined in bullet 4 of 3.2.1.
MLR AB’s MAY be sent.
MLR AP’s are now set to mandatory, see https://github.com/peppolautoriteit-nl/Invoice-Processes-Draft/blob/main/Invoice_to_Payment_Process/Invoice_to_Payment_Process.md#322-response-and-status-codes
A Transport Level Response and Message Level Response have different intentions/goals. Where the TLR supports the “ontvangst theorie”, the MLR gives insight in the correctness of a received document. This has been pointed out by endusers that seek support from NPA as one of the key missing components in the chain of document processing in Peppol’s 4-corner model. Endusers want to be sure that when a document is sent, it is actually delivered without any form of error. Exchanging MLR’s with RE and AP status would greatly improve the trust in the network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant