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: Re: [ubl-psc] ISS-11 Mandatory PayableAmounts was.. Re: [ubl]Proposed Changelog and Action Items for PRD2 to PR

Sorry to have missed this before my last posting (which still applies
in addition to this I think). My rushed responses inline:

Quoting Tim McGrath <tmcgrath@portcomm.com.au>:

> I also get the feeling we are moving away from a common understanding.
> However i dont thiink anything you say about business requirements
> contradicts what we propose.  Maybe we should revisit the basics.
> Point 1. Change LegalTotal to MonetaryTotal
> - this is because calling something Total (or LegalTotal) doesn't tell
> us what it is the total of.  It could be total weights, total numbers,
> etc., etc..  it also isn't always associated with legal requirements.
> You are correct we are not proposing to change LegalTotal (except for
> its name).  Are you OK with that?

No. (PayableAmount should be optional, as I've kept saying I think)

> Point 2. Qualify its use
> Quotation has Quoted_MonetaryTotal
> Order and OrderChange has Anticipated_MonetaryTotal
> Order Response has Legal_MonetaryTotal
> Invoice,Self Billed Invoice, Credit Note, Self Billing Credit Note,
> Reminder, Freight Invoice have Legal_MonetaryTotal
> Debit Note has Requested_MonetaryTotal
> Are you OK with the names?

I don't think this solves anything. Whatever the ASBIE qualifier the
semantic of the BBIEs is the same (or should be) and, more to the
point, so is the cardinality

> Point 3. Not all MonetaryAmounts are mandatory
> Order and OrderChange. Anticipated_MonetaryTotal is optional
> Order Response. Legal_MonetaryTotal is optional
> Your original concern was about Order Response having a mandatory
> LegalTotal.  This is no longer the case, it is now optional. Are you OK
> with that?

It makes no difference. It's one level down from there that concerns me.

> Point 4. Some MonetaryAmounts are mandatory
> Quotation. Quoted_MonetaryTotal is mandatory
> Invoice,Self Billed Invoice, Credit Note, Self Billing Credit Note,
> Reminder, Freight Invoice. Legal_MonetaryTotal is mandatory
> Debit Note. Requested_MonetaryTotal is mandatory
> Your comment "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)." is well taken.  However, this does not mean an Invoice would
> have no monetary amounts - just not necessarily the final ones.  Is
> that correct?

It should have just LineExtensionAmount as mandatory. The same applies
to the other documents.

> I suspect that is the nub of this issue.
> If we agree that there should be monetary amounts on an Invoice, then
> we suggest the one amount always present would be the PayableAmount.

I believe this will prevent use of a UBL 2 Invoice for optional or
variable PayableAmount consituents (such as a variable AllowanceCharge).

> It may not be the final PayableAmount but it is the amount considered
> for payment at the time the document is issued. Allowances and charges
> can be applied later as you say.

Then it should be called something else. An use cases will still need another
optional PayableAmount BIE.

> If we consider that there could be no monetary amounts on an Invoice,
> then maybe this is a pro-forma invoice and out of scope for UBL 2.0

Just because no amount is mandatory doesn't mean one won't be used - but
I still could live with LineExtensionTotalAmount being mandatory if one
amount has to be mandatory

> In general terms I think we all agree that we should balance specifying
> mandatory elements against flexibility and ease of implementation.  It
> is another 80/20 decision.

If we decide that the 80/20 excludes the use case of variable AllowanceCharge
then we can eliminate large parts of the ABIE (and possibly others too)
- but that doesn't gives us 80/20, more like 20/80 (acceptable perhaps for
UBL 1.0 but hardly for 2, I think)

> But there are some business rules that we
> feel are made clearer by specifying mandatory elements.  For example,

Who is the 'we'?

> it makes no sense to have an Invoice without a Customer and a Supplier.
>  We think MonetoryAmount on an Invoice comes into this category as well.

There is no use case established and on the table for having
no Supplier or no Customer but there is a clear use case for having
a non-fixed total which we have clearly accommodated elsewhere in UBL
(AllowanceCharge, TransactionTerms, etc)

Sorry to be a bit pushy but I think it's important UBL 2 gets this
right without an unreasonable need for customisation (which could
be very tricky if this was worng anyway)

All the best


> Stephen Green wrote:
>> Sorry Tim, now I'm even more confused and perplexed.
>> Quote "..if you are going to use MonetaryTotal" confuses me. Is the "you"
>> here the modeller or the invoicer? The qualifiers seem to be a bit
>> of a side issue. It still seems to still leave the invoicer having   
>> to provide
>> a PayableAmount (as a mandatory part of the mandatory MonetaryTotal
>> aggregate), even if that is not known at the time the document is
>> created. This therefore ignores, it seems, my issue. Is there a hope that
>> the added semantics of the qualifier will help? I'm not at all   
>> convinced it will. In fact I now think there may be even more cause  
>>  for concern with
>> this decision than there was before when considering the Order, etc.
>> Making the MonetaryTotal optional for orders doesn't help at all if the
>> MonetaryTotal itself includes a mandatory PayableAmount because
>> then using MonetaryTotal at all forces the order placer to provide the
>> PayableAmount which they might not know. The only way it would make
>> some sense is if another Total aggregate is also provided (without   
>> a mandatory PayableAmount) and that would surely just add to the   
>> confusion.
>> I got the impression from the original resolution in ISS-11 that there
>> would be AnticipatedTotal rather than AnticipatedMonetaryTotal (the
>> latter 'inheriting' a mandatory PayableAmount) in Order, etc. Are you saying
>> there will be both? Or is the only way to provide an order total now to
>> include a mandatory payable amount. That would be back to where it
>> was before the issues.
>> Thanks Steve
>>>>> Tim McGrath <tmcgrath@portcomm.com.au> 25/08/06 12:57:53 >>>
>> sorry for that (and well spotted).  I updated the item in the All   
>> Issues sheet and did not copy it into the Action sheet.  Please   
>> take it that what it says in the All Issues is the Actions.
>> That is....
>>> Change LegalTotal to MonetaryTotal and qualify its use:
>>> Quotation has Quoted_MonetaryTotal (and it is mandatory, 1..1)
>>> Order and OrderChange has Anticipated_MonetaryTotal (and it is   
>>> optional, 0..1)
>>> Order Response has Legal_MonetaryTotal (and it is optional, 0..1)
>>> Invoice,Self Billed Invoice, Credit Note, Self Billing Credit   
>>> Note, Reminder, Freight Invoice have Legal_MonetaryTotal (and it   
>>> is mandatory 1..1)
>>> Debit Note has Requested_MonetaryTotal (and it is mandatory, 1..1)
>> I hope that also clarifies my response to your earlier comment.    
>> The idea here is that if you are going to use MonetaryTotal then   
>> you must at least know the PayableAmount.  That is why   
>> PayableAmount remains mandatory.  Obviously on many documents you   
>> may not know this and so MonetaryAmount itself is optional.  But on  
>>  some documents they don't make sense without a MonetaryAmount and   
>> therefore they must have a PayableAmount.
>> PS. Peter can you make note of this and update your Action on this issue.
>> Stephen Green wrote:
>>> Tim
>>> I've been looking in the actions list (I didn't see a 'changelog')
>>> for mention of what you've called the 'new Legal Monetary Total'
>>> (for Invoice) and all I could find was the following (under ISS-11)
>>> " * create "AnticipatedTotal" that has the same structure as   
>>> LgealTotal but PayableAmount is optional and LineExtensionAmount   
>>> is mandatory.
>>> * Order and Order Change use AnticipatedTotal and it is optional.
>>> * Order Response uses legalTotal and it is optional.
>>> * Invoice uses LegalTotal and it is mandatory (as it is already)
>>> * Quotation uses LegalTotal and it is mandatory "
>>> Is there any documentation of the proposed Legal Monetary Total?
>>> Thanks
>>> Steve
>>>>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 25/08/06   
>>>>>> 09:56:04 >>>
>>> Hi Tim
>>> I think you might have misunderstood,
>>> the issue is
>>> "whether even Invoice should have PayableAmount as mandatory"
>>> In other words, should PayableAmount in LegalTotal (or whatever
>>> the document level totals in Invoice get called) be mandatory? I
>>> say absolutely not. Your idea for the Order, etc of an anticipated
>>> total which is not necessarily the actual payable total is also more
>>> like what an invoice needs except that there are legally binding
>>> aspects of invoice totals which are not quite like what you have   
>>> decided for orders, etc.
>>> 1. should invoices have a catch all mandatory amount?
>>> - i appreciate the desire to have a mandatory amount but which
>>> of the amounts that should be would differ from invoice to invoice
>>> 2. should the payable amount be mandatory?
>>> - this is the one amount which is particularly not always possible to
>>> state in some invoices
>>> 3. should there be something like payable amount which is mandatory
>>> but has different semantics?
>>> - i think this is just confusing things
>>> 4. should there be a payable amount which is optional?
>>> - i think so
>>> The need is to have a payable amount for some instances of invoice or,
>>> in line with 3 (so here i'd advise caution that there could be confusion)
>>> there could be an anticipated payable amount but even that would be
>>> inappropriate for some invoice instances so it shouldn't be mandatory
>>> either. In short, the nature of invoice, it seems to me, is such that the
>>> specific total which is appropriate differs from instance to   
>>> instance subject
>>> to strict but complex and divers rules. Trying to embody such rules into
>>> to schema, other than in a relaxed way, is likely, i think, to result in
>>> an over-engineered and often unusable (without problematic workarounds)
>>> base standard. Hence I advise not making either amount mandatory.
>>> All the best
>>> Steve
>>>>>> Tim McGrath <tmcgrath@portcomm.com.au> 25/08/06 00:17:27 >>>
>>> maybe this is just semantics. the new Legal_MonetaryTotal in the   
>>> Invoice is the legal total up to the point where circumstances   
>>> dictate a change (as you say, additional allowance and charges).    
>>> what we are saying is that if you have an Invoice there will be a   
>>> MonetaryTotal and without any other evidence it should be   
>>> considered the Legal_ MonetaryTotal.
>>> so is it the term "legal" that concerns you or the fact it is mandatory?
>>> if the former, then what is a better term?
>>> if the latter, then could we ever have an invoice with no amount totals?
>>> Stephen Green wrote:
>>>> Just to point out that there is still a significant outstanding aspect to
>>>> ISS-11 which is the last bit
>>>> " 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)."
>>>> This doesn't seem to me to be resolved in the disposition and could
>>>> cause problems for a very large group of invoicers whose invoice
>>>> payable totals are not known at the time of invoicing. This happens when,
>>>> for instance, the allowance/charge is unknown at the time of invoicing
>>>> (as is allowed for in the UBL 2 allowance/charge which caters for  
>>>>  dependencies
>>>> of the amount on certain conditions such as payment within a certain time.
>>>> This is *very* common in invoicing.
>>>> In UK, tax rules, for instance, allow for this by ruling that certain
>>>> situations of such charges do not affect the TaxTotal. But they
>>>> do of course not prevent the need for a non-fixed PayableTotal. I  
>>>>  would see this as very difficult to fix in a minor release so it  
>>>>  seems
>>>> very pressing for UBL 2. I can't really ignore it as it impacts so much
>>>> on allowance for proper invoice usage with UBL 2 and UBL 2's invoice
>>>> being fit-for-purpose'
>>>> Much obliged
>>>> Steve
>>>>>>> Tim McGrath <tmcgrath@portcomm.com.au> 24/08/06 07:28:51 >>>
>>>> The attached spreadsheet describes the issues from PRD2 and their  
>>>>  resolution for PRD3 together with a separate sheet indicating  
>>>> the  actions and persons responsible.
>>>> Can those who have action items work on these over the next few   
>>>> days and give a progress report at the TC meetings next week.
>>>> It would also be useful to have others check we have covered   
>>>> everything required from the PRD2 review.
> -- 
> regards
> 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]