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