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