comments on 1.0 beta

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

 

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

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

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

3. 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?

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

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

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

3. Perhaps the CopyIndicator should be dropped and all documents have StatusCode

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

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

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

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

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

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

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

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

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

a) DeliveryTerms

b) PaymentTerms

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

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

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

15. 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'.

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

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