Issues from a minor implementation

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