RE: [ubl-dev] Modeling multiple possible invoice totals based onpayment means

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

Ken,

Quite apart from eBusiness, an invoice by definition will always have a
single-number "total due," which represents "truth" as to the buyers'
commitment as understood by the seller. That single number is probably what
has been booked in the seller's accounting system, probably what the
seller's dunning process/debt collection team would use in pressing the
seller for payment, and what the seller would sue for in court, if that is
an eventuality.

On the other hand, conditional discounts and fees (e.g. a discount of 1% for
paying in less than 10 days, the discount you showed for using a credit
card, the premium you showed for using EFT) are not current "truth," but
projections of the results of optional, non-committed buyer behaviors. For
there to be a different seller-recognized invoice total, the payer has to
choose to pursue some non-base case payment option. Therefore, from the
seller's perspective, the other totals you showed are mythical until the
payment is received via an optional track.

In the normal transaction cycle flow, payment options would be defined as
part of the terms and conditions prescribed in the governing contract or, in
the absence of a contract or the quote/purchase order dialog. The T's & C's
would also prescribe (at least by default) which payment option is the "base
case."  For example, if seller a and buyer b agree that payment by EFT is
the base case, then the single invoice "truth" total would be reflect the
EFT payment method.

Therefore, what I suggest is that in your model of the invoice process, the
model should presume a "norm" or "base case," which produces the single
invoice total which the seller believes the buyer must pay - e.g., in your
example, probably the pay by check option that makes the invoice total
$1,000. 

Amounts due if the buyer elects other payment options therefore would not be
conveyed in the invoice at all or would be appear as an advisory (pretty
much as would happen in printing a physical invoice).


						Fulton Wilcox
						Colts Neck Solutions LLC

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Friday, January 05, 2007 10:37 PM
To: UBL-Dev
Subject: [ubl-dev] Modeling multiple possible invoice totals based on
payment means

Hi folks!

I have a question for the UBL business experts.

I'm modeling my invoice and I don't know how to express that the 
invoice total is different based on the payment means chosen by my customer.

Say my invoice totals CAD$1000 by whatever calculations are made for 
products and services sold.  At the bottom of my paper invoice I have 
three lines, assuming an exchange rate of .85:

   Payment by cheque:                    CAD$1000.00
   Payment by Internet (USD + USD5% Fee) USD$ 892.50
   Payment by EFT:     (CAD$20.00 Fee)   CAD$1020.00

I note that in:Invoice/cac:LegalMonetaryTotal is mandatory and not 
repeatable, and that there are only BBIE child elements, but 
interestingly a number of them are repeatable.  I cannot see how one 
would make correlations or how one would identify multiple repeated 
children, but I think there is a clue there.

Looking at the optional and repeatable in:Invoice/cac:PaymentMeans, I 
do not see any financial amounts in the children of PaymentMeans with 
which to specify the differentiated amounts.  Though I do see 
repeatable children like InstructionNote.

What recommendations would members of the list have for how I would 
model the three possible payments from which a customer can choose to 
pay?  Is this even possible?

Thanks for any suggestions!

. . . . . . . . . . . Ken

--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org