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

Steve


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