Should the component calculate things or not ?

[danvy]

In its actual state, the component is mainly a reader and writer of various e-invoicing formats.
Should it stay in his prime role or get enhanced with calculation ?

Here are my thoughts.

First, some might give different meaning to calculation : Is it pure calculation (IE : Calculate the total amount based on lines detail) or validation (IE : Ensure that the produced output is compliant with the selected standard).

Those two aspects have their challenges.

• Calculation
  Pros :

• facilitate the output validation in areas where the producer does not deal with such data but is required to fill them in Zugferd
  Cons :
• The core purpose of the component is to ease data exchange through e-invoicing data structures
• Probably already done by someone else if you read content or by yourself before you create the Zugferd instance
• The component can't cover all the needs of every invoicing apps. Extensible models will complicate the core
• The Zugferd model/representation is not the same as the app using it, it has its limitations and is often overkill
• Not a single good PR proposal at this time

• Validation
  Pros :

• Closer to the component core
  Cons :
• Specific to each format, version and country
• Translation of official specifications is a challenge by its own. Schematron often used and are not easy to translate in .NET as it comes from a Java world

Please, comments with your additional pros and cons

[danvy]

@stephanstapel FYI

[Dirksche]

At the beginning of this year, I've implemented for my employer a C++ wrapper DLL and tests (using the Google Testing Framework).
The C++ wrapper DLL just exposes the functions and enumeration values that we need to C++.
Tests have been written to cover all our different use-cases (e.g. payment by bank transfer, payment by direct debit, credit note, discount on items (we are not going to use this, because this gives larger rounding errors), discount on invoice lines, discount on the whole invoice, skonto, vouchers, items with 0 VAT rate, ...). (Nearly) every test generates an XML e-invoice which validates as valid. Every generated XML file is compared by the testing framework against a reference XML file. So if an update or code change breaks something, we will (most likely) notice.

While doing this work, I've noticed that the functions of this ZUGFeRD-csharp library has a lot of redundant input parameters. I went through all the business rules (Geschäftsregeln) in DIN EN 16931-1:2020-12 and removed in our C++ wrapper DLL all the redundant parameters. All the parameters which can be calculated automatically from other input parameters are now gone. At the end, the user has to call a function AddTotals() (or similar) which adds all the invoice total values, which have been calculated automatically. All the tests are still running fine and the generate XML files are identical to the ones before my changes.

I think having values calculated automatically, reduces the risk of producing e-invoices which are invalid or have warnings. Therefore, I prefer it this way. As we normally work with gross prices (including VAT) and the e-invoices are based on net prices (without VAT), we will get occasionally rounding errors. This means not all values will be exactly the same as in the PDF invoice. There can be a few cent difference. We just have to live with this. We are going to specify the rounding error as rounding amount BT-114. Even this is calculated automatically by our C++ wrapper DLL. I feed in the total gross amount that we've calculated and which will be shown in the PDF and the C++ wrapper DLL calculates BT-114 automatically and also adds a note regarding this to the invoice.

On the other side, there are people who want to be in control about all values in the e-invoice, even if they may produce warnings. Some want even a higher number of decimal places, as EN 16931 or the ZUGFeRD standard define.
In the most common validators, differences in the calculated amounts (even large differences) are anyway only warnings and not errors.
But I think, we cannot rely on the most common validators. Some companies might have written their own validator and if any business rule (Geschäftsregel) is violated, they might reject the invoice. Therefore, my aim was to produce e-invoices which don't generate any warning.

In my opinion, it would be nice, if the ZUGFeRD-csharp library would calculate as much as possible automatically (like our C++ wrapper DLL does). Maybe it can provide overloaded functions without the redundant parameters which can be calculated automatically.
So it works for both "worlds".
I could theoretically do this work, like I've done already in our C++ wrapper DLL, but I think we should then first have test cases which generate XML files and validate these against reference XML files. Just to make sure that before and after the changes and also with the new overloaded functions the generated XML files do not change. In my summer holiday, I've started on my own fork with implementing some automated tests, but as with all of us, there's always a lack of time. It's easier if you are on a beach holiday, but are not allowed to go into the water, due to an open flesh wound.

@danvy @stephanstapel FYI

[danvy]

Thank you @Dirksche :)
I can't wait to get others feedback on this point.