OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-psc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issues for agenda on August 21st meeting

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

ISS-4 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” is a general term. The term “Payment statement” is much better to understand.
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).
make decision about using process name versus document names.
ISS-9 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
familiar with, I don't know the exact amounts of these so I
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? 
Consider qualifying LegalTotal for Order
ISS-10 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
there could be for one OrderLine both LineItem and some
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. 
PSC need to decide on this (note Tim's comments)
ISS-11 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.
This would be because they may find legal problems being forced to use PayableAmount as mandatory rather than LineExtensionAmount. The legal problems 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).
Why is PayableAmount mandatory in LegalTotal? unless the PSC can explain this we will need to change it
ISS-15 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 Order, mandatory in OrderChange and missing from OrderResponse
2. OriginatorCustomerParty is optional in Order and OrderResponse but  absent from OrderChange
unless the PSC can explain this we will need to change it 

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.

tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]