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

br-co-25 check does not match description #386

Open
SteinRobert opened this issue Jun 22, 2024 · 6 comments
Open

br-co-25 check does not match description #386

SteinRobert opened this issue Jun 22, 2024 · 6 comments

Comments

@SteinRobert
Copy link

https://docs.peppol.eu/poacc/billing/3.0/rules/BR-CO-25/

The rule should actually test if either (exclusive) DueDate or Note is present. However, it also passes if both are present.

Does the description or the test need any adaptation? Maybe something like:

[BR-CO-25]-In case the Amount due for payment (BT-115) is positive, either the Payment due date (BT-9) or the Payment terms (BT-20) or both shall be present.

@MartinForsberg-Ecru
Copy link

I don't see an issue with the current statement. The logical OR gives that at least one (or both) have be present for the rule to pass.

@SteinRobert
Copy link
Author

SteinRobert commented Jun 22, 2024

It did confuse me, since other rules explicitly mention that providing both options is valid:
https://docs.peppol.eu/poacc/billing/3.0/rules/BR-CO-24/

[BR-CO-24]-Each Invoice line charge (BG-28) shall contain an Invoice line charge reason (BT-144) or an Invoice line charge reason code (BT-145), or both.

Furthermore either + or in the English language gives the statement an exclusive character (one of the options not both).
Source: https://dictionary.cambridge.org/dictionary/english/either-or

@swarupdotbanerjee
Copy link

can it it be a problem for the receiver, if
1.both are present and
2. they lead to different dates?

@MartinForsberg-Ecru
Copy link

The Payments terms is often used together with the due date. I would say this also was the intention from start. See the definition from the EN:

A textual description of the payment
terms that apply to the amount due
for payment (Including description
of possible penalties).

And usage note:
This element may contain multiple lines
and multiple terms.

If the wording BR-CO-25 is perceived as confusing (and I agree that the it can be written better), then I propose that this is forwarded for an editorial fix in the next revision of the EN16931-1.

@AndreasPvd
Copy link
Contributor

I understand your problem, but it is necessary to allow multiple payment terms that contain different due dates: Example in several states there exist conditions where the amount to be paid is dependent on the time of payment. It may be a discount or a surcharge. Unfortunately, today, the EN16931 does not support those kinds of terms in its semantics. The syntax bindings and validation rules do not reflect this, although the two syntaxes would be capable of providing the information in a structured way.

Example for multiple payment terms with different due dates:

Line 1: 1000.00 EUR payable within 30 days (until 2024-07-23) without deductions.
Line 2: Payable within 14 days (until 2024-07-09) with 1% deduction (990,00 EUR)
Line 3: Payable within 7 days (until 2024-07-02) with 3% deduction (970,00 EUR)
Line 4: Payable within 3 days (until 2024-06-28) with 5% deduction (950,00 EUR)

Or (common in some other countries)
Line 1: 1000.00 EUR payable within 10 days (until 2024-07-05) without deductions.
Line 2: Payable within 14 days (until 2024-07-09) with 3% surcharge (1030,00 EUR)
Line 3: Payable within 30 days (until 2024-07-23) with 10% surcharge (1100,00 EUR)

@SimonsPaul
Copy link
Collaborator

It shall be interpreted as both are allowed.

Changing the text of the current version of the EN16931-1 as suggested is not possible at this moment. It will however be withheld for the Revision.

@SimonsPaul SimonsPaul reopened this Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants