No known Issues
1. A first check of (only) the re-usable spreadsheet regarding the correctness of the Directory Entry Name is enclosed. The counted number results almost from too many Blanks in the different columns of the spreadsheets. Three times the term 'details' seems to be missed. The enclosed spreadsheet compares the EF generated Directory Entry Names with the spreadsheet generated one. The error sample indicates more various handcraft typos than any systematic error, i.e this is avoidable. Many other occurances of non-optional 1..1 entities are questionable. Another example, besides 1) above, is PaymentMeans where it should be possible to ask for payment by cheque made payable to a particular name. Here one wouldn't wish to give bank details ,etc, but there are many entites which are 1..1 so one is forced to have empty 'tags' in the XML, say. So FinancialInstitutionBranch probably should be 0..1 (perhaps AccountTypeCode too). *Perhaps* there should be hardly any 'mandatory' entities, especially in the 'reusable' module, where reuse may be resticted by them. Another example, perhaps, is the fact that LegalTotals has both LineExtensionTotalAmount and ToBePaidTotalAmount totals as 1..1 but where in fact, for a simple invoice, only one or the other (e.g. ToBePaidTotalAmount) might be relevant. At a glance, in 'Reusable', other ABIEs with questionable 1..1 or 1..n entities are DespatchLine, InvoiceLine and PaymentTerms (PaymentTerms.Note is 1..1). There may be more in the document models.
2. I'd like to know where do I have to address myself to find a practical example of some parts of the UBL 1.0 standard. I'm developing an Invoice XSD based on your specification and I don't know the real meaning of some elements, or in which cases they can be used.
3. Where can I find a list or similar of the governments or public institutions ina ny country interested in UBL implementation? Where cam I find this kind of information?
4. The TaxPointDate *should* really be optional (0..1 rather than 1..1). It is only relevant when tax is involved (of various kinds), and then sometimes (in EU VAT rules, for instance) as a supplement to the InvoiceIssueDate, required only when different from the latter. The worse part about the above is that the mandatory, 1..1 issues would break backwards compatibility if corrected after the beta. (*Perhaps* sooner better than later though.)
5.Many other occurances of non-optional 1..1 entities are questionable. Another example, besides 1) above, is PaymentMeans where it should be possible to ask for payment by cheque made payable to a particular name. Here one wouldn't wish to give bank details ,etc, but there are many entites which are 1..1 so one is forced to have empty 'tags' in the XML, say. So FinancialInstitutionBranch probably should be 0..1 (perhaps AccountTypeCode too). *Perhaps* there should be hardly any 'mandatory' entities, especially in the 'reusable' module, where reuse may be resticted by them. Another example, perhaps, is the fact that LegalTotals has both LineExtensionTotalAmount and ToBePaidTotalAmount totals as 1..1 but where in fact, for a simple invoice, only one or the other (e.g. ToBePaidTotalAmount) might be relevant. At a glance, in 'Reusable', other ABIEs with questionable 1..1 or 1..n entities are DespatchLine, InvoiceLine and PaymentTerms (PaymentTerms.Note is 1..1). There may be more in the document models.
6. On the other hand, I wonder whether InvoiceCurrency which is optional (0..1) should actually be 1..1.
7. AddressLine a) Model: The AddressLine in the Address doesn't work as well as one might wish since it is an ABIE rather than a BBIE, which forces that it go to the bottom of the Address ABIE - not where it belongs really. b) XML: Futhermore, it isn't possible to mix AddressLines with structured address elements such that AddressLine elements in an XML file can be interspersed between the structured elements
8. Perhaps there should be a structured way to specify 'c/o' in an address (this is where, being forced to use AddressLine for it, I found it broke the order of the address so that I had to express the entire address in an unstructured way with AddressLine).
9.
10.