WPCubed GmbH
Wordprocessing and PDF components
WPCubed GmbH
Wordprocessing and PDF components
It contains classes that represent elements outlined in the EN16931 specification. Some classes are applicable to many data types, while others are specific to certain data types or particular properties. It is feasible and fairly straightforward to replace a general class with a more specialized one. This provides additional type savety.
There are multiple possibilites to create X-Factur data. Many involve to create the XML data by using an XML component to add the elements node by node. There are libraries available which makes this easier by implementing functions to create the proper class names. The idea behind WPXOrder was ther should be a way to do this with without having to deal with XMLNodes but use standard Delphi code instead. Only then the delphi compiler will check the corrrect nesting of the objects and very often also the correct type of the assigned data.
Order commercial license for EURO 199,92 incl. 19% VAT (only available in Germany)
Rather than using predefined coded classes that encompass all potential properties and elements, the primary objects contain a list that references each element.
With this list, it is possible to identify which objects and properties were created, as well as the order in which they were assigned.
This is why importing the XML data into WPXOrder and then saving it again essentially generates the same XML data, which can be easily verified using a text comparison tool. (Tip: In Delphi use Edit/Compare)
This made is possible to create easy to maintain classes using very small prototypes.
We used a propritary converter to create the codes from the official X-Facur XSD data. This reduced the probability to typing errors and made it possible to create a rather complete representation of the data model as Delphi objects.
Using enums it is possible to assign some values for codes with full checking by the delphi compiler
Many of the classes can be used as arrays, too. For example the ApplicableHeaderTradeSettlement.ApplicableTradeTax can occur multiple times in the object ApplicableHeaderTradeSettlement. In such cases you can access all elements using the array operator [x].
Example:
ApplicableTradeTax[1].RateApplicablePercent.SetValue('19.00');
ApplicableTradeTax[2].RateApplicablePercent.SetValue('7.00');
With the exception of Transaction lines (used for each product in the invoice) you do not have to create any of the objects. They are automatically created for you when you first access the property.
At present WPXOrder deals with X-Factur (ZUGFeRD) only. We made some design choices to make it possible to later also add X-Invoice, but for now X-Factur is more important for us.
No, it cannot.
It generates the document structure based on the properties added by the developer, maintaining the same sequence.
It does compute values and can give a hint whether the summation values are accurate. (no guarantee!)
We suggest using a validation tool to verify the accuracy and completeness of the generated data. https://portal3.gefeg.com/invoice/page/validation)