[ubl-lcsc] summary list of FPSC work issues

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Greetings

Attached is a summary of issues raised from implementation efforts on 0.80, while updating from 0.70. 

An updated detailed list is attached too.

Most of these issues have been non-normatively fixed for 0.81

Stephen Green
2003-07-11

UBL_instances_0_70_to_0_80_issuelist_04.txt

This is a summary of issues raised from implementation efforts on 0.80, while updating from 0.70. Most of these have been non-normatively fixed for 0.81

 
Issues Fixed in 0.81

referencing one document from another
- more reliable means required
- most such references might best be unbounded
- keep consistency across documents
- all documents being able to reference all previous documents
- referencing at document top level and at line level
- referencing at line level to be to a line i.e. a reference both to the document and to the line in that document
- order-like documents need both buyer and seller id's
- should both buyer and seller id be optional or one or other optional


PartyName somehow got left out of Party
- does AlternativePartyName need to be there with PartyName being unbounded?

Party Id and maybe some other ID's may cause problems being mandatory since where party name is used there may not be a party ID. 
- Perhaps there should be a choice between either party name mandatory and party id optional or party id being mandatory and party name optional
- or just have both as optional (0.81)
- the id shouldn't be left blank if it is mandatory by NDR rules but it is valid according to the schema even if it is blank as empty long as the tag is present in the instance

Delivery Date and Delivery Address

- there should be consistent and apparent structure / methodology throughout range of documents
- delivery details (dates and addresses) at both document top and
document line levels seems appropriate in general unless reasons dictate otherwise
- different documents need different date names (e.g. ReceivedDate)
- different documents have different uses for addresses which may require different address entity names (e.g DeliveryRequirements is OK for an Order but perhaps a different name of ABIE for 
delivery details in an Invoice)
- still want to have reusability
- the contents of a DeliveryRequirement ABIE may need to be different for an Order compared with an Invoice

smaller documents still need (optional perhaps) party details

notes may help in each document (half had at document top level) both at top level and at line level




Issues not yet fixed in 0.81

Address needs an optional unstructured text line (1..x)

There may be cross-document references 
at lower levels in the 'structure' which 
I wasn't able to alter in the time 
available (these should be looked at 
but may not affect the samples and 
scenario form specs)