Issues from a minor implementation

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Bill

 

A few issues emerged when I was sending an invoice with

 UBL 1.0 beta.

 

 

1) 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.

 

2) 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.

 

3) On the other hand, I wonder whether InvoiceCurrency which is

optional (0..1) should actually be 1..1.

 

 

4) 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

 

5) 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).

 

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.)

 

Stephen Green