A few minor improvements

[renebrain]

Hey i've tried out your tool and it is great. Right now i am just using it for reading Zugferd Files to get them in to my accouting software by extracting the xml from it. While doing it i saw some stuff which i am not sure about if it is right (v1.0.0):

1.) EInvoiceModel getTaxRate() method returns 0 if you are importing an invoice over EInvoiceModelFactory. I assume because it could by ambigious, if there are more than one tax rate present? I couldn't find any routine that sets this property during the import.

2.) EInvoiceModel has the buyerReference property as a protected String, which is fine, but the problem is there is no accessors to access this information. So if i habe a buyerReference from an Invoice imported over EInvoiceModelFactory, i cannot access it. I assume that the accessors just might have been forgotten here.

Right now i am just accessing it directly from the provided xml, via a helper function, but would be cool to just have the accessor for it so i could remove my helper function there.

For exporting my own invoices i am still using a hacked Mustang version, where i set a few properties in the xml manually because it does to many non compliant DIN calculations automatically. I would like to use your tool instead since it is much more straightforward and does not dictate certain calculation paradigms. So i've started to check some of your classes. I also have a few questions regarding those:

3.) I love how you deal with TradePartyies via a Type discriminator; maybe instead of using a string it would be better to use an ENUM for the types, because i had to browse a bit to find the applicable type strings. Via Enum it would be much easier and faster to find, since the ide would be able to give you suggestions.

4.) In the trade parties i am missing a few properties which might be useful to set, which i already have from Mustang, like telephone number, which a person might have like b2c customer or as a part of the receiver address or the sending company. Also the so called extra or additional information line in an adress might be useful for sending information which is known as "Adresszusatz" or in xml as ram:LineTwo. Also setting a VAT and a Taxnumber would be great: SpecifiedTaxRegistration (Scheme ID's VA & FC)

5.) Regarding TradeLineItems, i think you should update the JavDoc since it looks like an copy paste of the TradeParty

`package org.imixs.einvoice;

/**

• A TradeParty is a container for a TradeParty element.
• @author rsoika
  *`

I haven't looked to deeply in TradeLine Items, since i HATE Mustang that's why i love your tool, how they deal with it with all those fixed calculations. Anyways all of these allowances etc. i do not need, since any trade line item can do the same thing if used correctly. So i am fine with the structure how it is for now, but i would definitely recommend to use BigDecimals for all of the values of the TradeItems like you do for the Invoice itself instead of doubles, to keep it 1. consistent and 2.), make it more precise, especially for numbers that doubles are just struggling to save them properly.

If you could make all of these rather small and not so crazy changes, i would immediately completely go to your tool also for creating the xml, since it is 1. more lightweight, 2. much simpler to use and 3.) doesn't impose arbitrary rules on calculations which the tool shouldn't impose since the standard does not recommend them. Until then i'll stay to hacking mustang to put the values i want in my xml until i find a better solution. But for Importing your tool is already great ;)

[rsoika]

Hi @renebrain , thanks a lot for your valuable feedback!
And yes there is room for improvements ;-)
I think we should separate the issues. A good approach is to add a example xml file and add a junit test demonstrating the case. This makes it easy to fix minor issues very fast. And yes there are not so many tests as we may need. Currently only one test class EInvoiceModelTest

If you like you can add such an additional case and create a pull request. We can fix it together very fast I guess.

A typical starting point could be things like the missing telephone in the model. This can be a simple extension in one of the exiting tests or we write a new separate one. What do you think?

Regarding the creation of a E-Invoice I follow the approach of using templates. The idea is to create a template with the static data (e.g. the seller address). Then you read the template with the factory method and add invoice lines via the eInvoice Model object. Finally you can export the XML tree into a new file.

I know there is still the junit test missing - I need to add one test asap for demonstrating this.

But anyway If you like you can create a pull request with your suggestions. Or you can just create separate Issues so we can solve them together one by one?

[rsoika]

@renebrain do you have a test file for Issue #6 ?