comments on 1.0 beta

Bill

Here are 
some more matters perhaps warranting changes before beta goes to 
final.

1. Perhaps a candidate for a (CC) Datatype is the shorter ISO 
date format used by credit cards and the like i.e. yyyy-mm

At present 
the DataType for CardAccount.ExpiryDate and CardAccount.ValidFromDate is 
Date_DateTime.Type which hardly seems appropriate for what is certainly not a 
datetime and barely a date. Someone correct me if I'm wrong, but I don't think a 
short ISO date like 2004-11 (equivalent to 11/04 on a credit card say) would be 
valid as an xsd:date but then neither would 2004-11-00 so one would be forced to 
use 2004-11-01 which might confuse some and leave the way open to error. Against 
this is the possibility that some types of card might not use the month and year 
only but the whole date (though I've never heard of such).

2. a) 
Still on CardAccount, the EEG1 e-Invoice work suggests that we may need a BBIE 
for CardProvider (e.g. MasterCard or VISA).
b) The definition for 
CardAccountType is rather vague and does not relate to the 'account' refered to 
in the BIE name:
"Information that directly relates to a credit or debit 
card, a small plastic card issued by a financial institution, bank or building 
society, allowing the holder to make purchases against the card."
c) It is 
also too close to the definition of CardTypeCode
"The type of card used for 
payment"
d) If either of these mean 'card provider' then they should have 
their meanings tightened up somewhat. They probably should anyway me thinks 
:)

3. The Representation Term Schema has what appears to be an error: 

The schema reads for 
Amount, Measure and Quantity like the following

<xsd:simpleContent>

<xsd:restriction 
base="cct:MeasureType">

<xsd:attribute 
name="unitCode" use="required"/>

<xsd:attribute 
name="unitCodeListVersionID" use="prohibited"/>

</xsd:restriction>

</xsd:simpleContent>

This, apparently, 
should be

<xsd:simpleContent>

<xsd:restriction 
base="cct:MeasureType">

<xsd:attribute 
name="unitCode" type=”xsd:token” use="required"/>

<xsd:attribute 
name="unitCodeListVersionID" type=”xsd:token” 
use="prohibited"/>

</xsd:restriction>

</xsd:simpleContent>

with 
type=”xsd:token” inserted before 'use=...'

This was shown up by 
Sonic Software Corporation's Stylus Studio (version 4.6) but surprisingly not by 
XML Spy. Perhaps NDRSC would confirm whether this is a W3C XSD Schema error or 
just a software quirk.

4. As I mentioned on 
a call, there appears to be an ugly inconsistency between the manner in which 
multiple BBIEs are added to an instance for a) a party name and b) an 
unstructured address line

With party name this 
goes:

<cat:PartyName>

<cat:Name>String</cat:Name>

<cat:Name>String</cat:Name>

</cat:PartyName>

But with address 
line the following is invalid

<cat:AddressLine>

<cat:Line>String</cat:Line>

<cat:Line>String</cat:Line>

</cat:AddressLine>

Instead it has to 
be

<cat:AddressLine>

<cat:Line>String</cat:Line>

</cat:AddressLine>

<cat:AddressLine>

<cat:Line>String</cat:Line>

</cat:AddressLine>

Which to me looks 
uglier and obscure to a programmer so I'd suggest the model be 
changed

to make AddressLine 
0..1 and Line 1..7 as with PartyName. (I seem to remember this being 
the

solution proposed 
for, dare I say it, containers – but I seem to remember too that it might be my 

fault for how things 
look in the AddressLine.Line part of the model – sorry.)

Then my own business 
address would read

<cat:PartyName>

<cat:Name>Stephen Green</cat:Name>

<cat:Name>Seventh Project Consulting 
Ltd</cat:Name>

</cat:PartyName>

<cat:Address>

<cat:AddressLine>

<cat:Line>c/o 61 Cromwell 
Road</cat:Line>

<cat:Line>St Andrews</cat:Line>

<cat:Line>Bristol</cat:Line>

<cat:Line>BS6 5HA</cat:Line>

</cat:AddressLine>

</cat:Address>

instead of

<cat:PartyName>

<cat:Name>Stephen Green</cat:Name>

<cat:Name>Seventh Project Consulting 
Ltd</cat:Name>

</cat:PartyName>

<cat:Address>

<cat:AddressLine>

<cat:Line>c/o 61 Cromwell 
Road</cat:Line>

</cat:AddressLine>

<cat:AddressLine>

<cat:Line>St Andrews</cat:Line>

</cat:AddressLine>

<cat:AddressLine>

<cat:Line>Bristol</cat:Line>

</cat:AddressLine>

<cat:AddressLine>

<cat:Line>BS6 5HA</cat:Line>

</cat:AddressLine>

</cat:Address>

I think it's obvious which looks more intuitive and therefore clearer to 
a developer.

[Already mentioned in my previous e-mail, I point out in the 
above

a) that the reason I have to use the unstructured address is that there 
is no way to represent c/o and 

b) therefore I have to make the whole address unstructured which means 
even the postcode has to

be so – not convenient for any receiving software. An indicator to denote 
that the whole address is 'c/o'

would prevent this I think.]

5. EEG1 suggested codelists UNCL 1229 for line status code and UNCL 1225 
for document status code.

Other extras to 
consider (though perhaps outside of the 80:20 scope) learnt from the EEG1 
e-Invoice

comparison 
are

  

  
(from CIDX) a 
  secondary payment currency – slightly different from just a second occurance 
  of a currency in that this is specified as secondary (the primary one being 
  the prefered currency, e.g for invoice payment.

  

  
Delivery.DespatchedDateTime (or ShippedDateTime or 
  DespatchCommencedDateTime) as distinct from Delivery.ActualDeliveryDateTime – 
  to allow the specifying of both the date a delivery is despatched (leaves the 
  warehouse) and the date a delivery is completed. (Harmonisation may come up 
  with a solution CC here.) 

  

  
Does UBL have the 
  means to specify the shipping cost which isn't included sometimes in an 
  invoice total calculation but which is required to be stated for customs so 
  that they can deduct it from the value of the goods?

  

  
Does UBL provide 
  for negative values (perhaps in the CCTs)? (e.g. for negative allowances and 
  charges say)

  

  
There does not 
  seem to be a way that a reference to an order can specify that it is a change 
  order. 

  

  
The status code 
  should be included in references to order documents (perhaps in all refernces 
  to documents) 

  

  
Perhaps the 
  CopyIndicator should be dropped and all documents have StatusCode 
  

  

  
now that it is 
  clear that there is a codelist UNCL 1229 used for this and

  

  
finding some other 
  way to clarify that the document status codelist for an order should not 
  include an option for 'changed' except in the order document reference and 
  that an invoice status code cannot include the use of a code to denote 
  'changed' either. 

  

  
Apparently the EU 
  requires an additional tax number for VAT besides the VAT Registration 
  Number.

  

  
Does UBL include 
  the means to quote lot numbers on an invoice?

  

  
Some countries 
  apparently may require that where reference is made to exemption from VAT (as 
  a tax rate) it must be accompanied by a reason (free text at present but a 
  codelist is possible later)

  

  
I get the 
  impression that in the USA, ISSS requires that transport/shipment details be 
  included in the invoice. It looks like UBL only has these in the despatch 
  advice.

  

  
An 
  InvoiceAcceptedIndicator might be included in the invoice to allow the invoice 
  to be responded to using an invoice message

  

  
ManufacturerParty 
  as another party (at line or item level as well as document 
  level)

  

  
Perhaps UBL should 
  include the following at line level as well as at document 
  level:

a) DeliveryTerms

b) PaymentTerms

  

  
CarrierParty as 
  another party within the Delivery ABIE (line level use as well as document 
  level in invoice)

  

  
An 
  AdditionalMaterialInformation ABIE to act as a container for easier extensions 
  by vertical industries

  

  
Add Telex to 
  Contact since it is still used on ships?

  

  
In spite of my 
  previous e-mail of comments regarding the need for less 1..x cardinality in he 
  payment means ABIE, perhaps there should be something in the PaymentMeans ABIE 
  to cater specifically for 'cheque payable to'.

  

  
Europe may require 
  (for Euro conversion) the means to allow either divide or multiply as the 
  operator in currency conversion using a particular rate (the rate for 
  multiplication say might not be available or even calculatable so division 
  might have to be used) – a MultiplicationOperatorIndicator or the like as 
  optional could provide this (with explanation in the 
  definition)

  

  
Maybe a 
  FreightBillDocumentReference (optional of course) could be added to the 
  invoice (even though not in UBL at present - rather like the 
  ContractDocumentReference and QuoteDocumentReference in the 
  order)

Thats all for now 
:-)

All the 
best

Stephen 
Green