BR-FX-EN-04 mystery

[halfbyte]

I recently ran into a validation error with the latest Mustang-CLI that flagged a violation of BR-FX-EN-04.

I've been trying to hunt down this validation rule, and everything about it seems to be a bit absurd. I know that this is an upstream issue but maybe someone here can help me with figuring out how to approach this.

At first, the business rule seemed undocumented, but then I found out that it is documented in the german "Technischer Anhang" for the EXTENDED ZUGFeRD variant as BR-FX-DE-04. As far as I can tell, this seems to be the only business rule that is name spaced by language and to me this makes absolutely no sense? (I initially thought the EN stood for the EN16931variant, which would make sense, as there are business rules named BR-FXEXT in the EXTENDED docs as well, but well)

I cannot trace where this BR comes from, it doesn't seem to be, as far as I can see, part of EN16931 itself (but then FX suggests that it is indeed a Factur-X extension?)

Additionally, even though it is documented as part of EXTENDED, the validation is included in the BASIC schematron file.

The rule itself is fine, I guess.

So my questions are basically:

• What the [BLANK] happened here?
• Is there a good place to ask/ report this? I don't have any experience with reporting something to the standard body and with a quick search I couldn't find any official contact points or bug trackers or whatever.

[jstaerk]

That's an issue within Factur-X/ZUGFeRD introduced in 2.4 and it's under discussion (internal issue 298). You can join, free of charge, but AFAIK you have to join CC3 to take part in the discussion.

[jmichler]

Is there any news in the internal issue 298? We struggle with this as well since we have invoices with a billing-period and not a OccurrenceDateTime without defining a ship-to-country-code. Is this what is discussed in 298? Currently the AWV-Forum you linked seems to be unreachable?

[TheSmoun]

Any news on this?

[JoachimTuchel]

I'd also be very interested in the resolution for this.
If you automate the generation of accounting entries from an invoice with an actual delivery date (BT-72) or an invoicing period (BG-14), this has implications on when VAT is due in Germany. So if such a date is mandatory in an invoice, I as the receiver or sender have to decide whether this date really is the due date of VAT, and that is not only dependent on the invoice's actual delivery date / end date of the invoicing period...

A second question is whether it wouldn't be a good idea to ignore this rule, as it is only relevant for the EXTENDED profile of factur-X (at least accoring to its name and being mentioned only in the technical appendix for EXTENDED).

[JoachimTuchel]

The rule itself is fine, I guess.

I am not even sure about this. There is no rule anywhere that says ACTUAL DELIVERY DATE or INVOICING PERIOD are mandatory. And also BT-80 in BG-13 (ShipToTradParty) is not mandatory and in practice will probably not be present in loads of invoices.... at least not yet. So the rule enforces a mandatory field in a seemingl very specialized context (EXTENDED PROFILE)...

I can only find rules that demand that IF an invoicing period is given, then some other things have to be present.

But BR-FX-EN-04 fires for each and every invoice where neither INVOICING PERIOD nor ActualDeliverDate ist present and also no ShipToTradeParty is present.

The only solution at this time is to either enforce the date or period or make sure the buyer is copied into the ShipToTradeParty if not present. I have a hard time believing this is intended.

I know this is not the right place to influence the decisions on Business Rules, but I'd be interested how other users of ZUGFeRD and/or Mustang solve this problem. Valitool has obviuosly decided to make this a non-fatal error (warning) - is this a possible solution for Mustang as well?

[JoachimTuchel]

I've been in contact with Daniel Vinz now and he helped me get a little more insight to this rule.

I learned I approached the problem from the wrong standpoint: I tried to understand the business needs behind this rule.

The problem here is that the group including BT-72 must not be empty, so you always need either BT-72 or (as a mininum that doesn't hurt) BT-80. There is no business requirement behind this, the reasoning is just that the deliver country is most likely known anyways and thus can be used to avoid empty elements.

The most important info from Daniel is that in ZF 2.5 / FX 1.09 this rule is not part of the checks for the EN16931 - profile any more
(I haven't checked yet).
It is being replaced by PEPPOL-EN16931-R008 which simply states empty elements are not allowed. I am not sure this makes anything better from the standpoint of understandability of this particular case where there is no delivery date (BT-72).
This delivery date thing has no connection to the invoice period. I (and maybe others) were irritated by the fact that the riule seemed to say you need either an invoicing period or a delivery date and this BT-80 thingie seemed to make no sense at all. Which is true from the business perspective, but still there needs to be "something" in the enclosing group for techmical reasons.

So the rule remains in place, it just gets a new name and text in ZF 2.5 / FX 1.09 (which is not necessarily an improvement imo, because the hint to at least fill BT-80 was helpful once you read it literally)-

So this issue can remain closed and all. No action needed. I just wanted to share my learnings and hopefully help others understand this strange rule...

Joachim

[JoachimTuchel]

Oh, but one interesting detail: the new rule PEPPOL-EN16931-R008 is marked as a warning in the technical appendix for EN16931 in ZF 2.5 - so depending on how fast we assume other systems migrate to 2.5, this rule can possibly ignored for now (unless we want the invoices to be peppol compliant)

So does this mean much ado about nothing?

[JoachimTuchel]

I have checked now: BR-FX-xx-04 is not in the ZF 2.5 schematron (Factur-X_1.09_EN16931.sch) any more.
... but also not the PEPPOL rule ...

[IsThatUniqueEnough]

but also not the PEPPOL rule ...

The rule is there and it works as expected:

<pattern>
    <rule context="//*[not(*) and not(normalize-space())]">
      <assert test="false" flag="warning">
	[PEPPOL-EN16931-R008]-Document MUST not contain empty elements. (still status warning)</assert>
    </rule>
</pattern>```

[JoachimTuchel]

It is, indeed. Why didn't I find it in the first place (scratching my head)?
(I guess I was searching for "BR_PEPP", which obviously yielded no result)