I am assuming the PSC has a meeting on Monday 21st at 0800 UTC (normal time).

There are some issues from the PRD2 review we must dispose of at that call. These are...

2.4 Section 5.7.1 Report State of Accounts The name of business document in this business process is "Statement". We think that the name "Statement" had better to be changed to "Payment statement". Because, the term "Statement" make decision about using ISS-4 is a general term. The term "Payment process name versus document statement" is much better to understand. names. If you change this name, the influence is large. For example: Change the name in the Table 2. Document used in each transaction, Business document itself (spreadsheet and XML Schema). I found what could be a serious problem in the UBL 2 prd2 Order in that it could seriously hinder or prevent use, especially by those who don't include tax in their orders: the replacement of UBL 1.0's LineExtensionTotalAmount with LegalTotal leaves a problem for the Order use - it caters for the Invoice usage in having PayableTotalAmount but this is mandatory which is what causes problems when the same LegalTotal is used in the Order to provide the order total. Implications: if I'm completing an order I do not know the PayableTotalAmount with much certainty, only the LineExtensionAmount. I know that there may be tax in the PayableTotalAmount of the invoice and there may be discount too but, especially if the order is sent to a country I'm not ISS-9 familiar with, I don't know the exact Consider qualifying amounts of these so I LegalTotal for Order can't predict the payable amount. Not everyone includes the tax in the order (I wouldn't say doing so was intuitive anyway) but even if I did I wouldn't be catering for the discount in the order too. Further Implications: this would be very difficult to fix in further minor versions since it would be against the rules to make relax something which is mandatory. One way might be to make LegalTotal in the Order 0..0 and add LineExtensionAmountTotal as with the UBL 1.0 Order. A workaround for implementers, but a messy one, might be to deprecate the LegalTotal in the Order by subsetting and add an extension with a LineExtensionAmountTotal - not very satisfactory. Better if it was possible to fix this in UBL 2.0 but might this mean a further, third public review? OrderLine - there is now just the one OrderLine ASBIE for the Order document, OrderResponse and Order Change. This presents a particular challenge for subsets of course but that's beside the point. The point is it doesn't have an ID (neither did it have one in UBL 1.0) and I wonder how accurate or otherwise this makes the OrderLineReferences if they are refering to an OrderLine which doesn't have an ID, presumably by actually referencing the LineItem which does have an ID. The LineItem is not the same since ISS-10 there could be for one OrderLine both PSC need to decide on this LineItem and some (note Tim's comments) kind of SubstituteLineItem so there is a loss of both accuracy and precision when refering to an OrderLine by referencing the respective LineItem. This is complicated even more if LineItem is virtually empty and something like even to QuotationLineReference is used for the data. Admittedly the LineItem is mandatory as is its ID, so at least there must always be a LineItem/ID for every OrderLine. Just that there are other ID's that might be being used instead or as well - a headache perhaps for implementers. Following on from my issue below, I've now been looking at the OrderResponse document. The same LegalTotal is for some reason premanently mandated in the OrderResponse even though it is optional in the Order. This disappoints me somewhat because the PayableAmount is permanently mandatory in the LegalTotal so there may be some who find they cannot adequately respond to an order for which there need to be some lines accepted and others rejected. Why is PayableAmount This would be because they may find legal mandatory in LegalTotal? ISS-11 problems being forced to use PayableAmount unless the PSC can explain as mandatory rather than this we will need to change LineExtensionAmount. The legal problems it are possible because there may be legal implications stating a 'payable' total when discount and tax are unknown at that stage. Indeed,I question whether even Invoice should have PayableAmount as mandatory since sometimes the PayableAmount isn't known until the invoice is being paid (there could be allowances and charges which are not known until then due to some being conditional on payment date, etc). There seems to be a possible bug in the OrderChange and, to a lesser extent, in the OrderResponse concerning the Parties: 1. AccountingCustomerParty is optional in unless the PSC can explain ISS-15 Order, mandatory in OrderChange and this we will need to change missing from OrderResponse it 2. OriginatorCustomerParty is optional in Order and OrderResponse but absent from OrderChange

To keep with our work plan these must be dealt with on Monday. If you have any comments either attend the call or send them via email as soon as possible.