[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Modeling question re: multifaceted price calculation
Thanks again, Fulton, for engaging in this discussion! Please be
patient with my questions below as I seek to understand the correct
business perspective of this problem.
At 2008-04-28 17:11 -0400, Fulton Wilcox wrote:
>You seem to have represented all of the elements of rental price
>calculation. Presumably the company creating and sending these rental bills
>will have no problem creating the require tags and associated payload.
That's my thought ... I haven't presented this to them, but I have
seen their legacy printed invoices that already have all these facets
described.
>Where I still see a problem is what happens with respect to the various
>customer companies who start receiving these invoices. I think that you can
>send all the ingredients of invoice computation, but I also think that for
>"backward compatibility" (systems and people's mental habits) you should
>reconstruct the transaction to put the "real" quantity and real unit price
>in plain sight.
Hmmmmmm ... I thought I had.
>Typically, the customer's invoice processing (manual or automated) will look
>at the line item quantity invoiced and unit price to compare them with
>invoiced extended amount.
Right ... and I calculated the unit price as the monthly charge per
unit, so that when multiplied by the number of units, results in the
monthly charge.
>It will look to see whether the cumulative number
>of units and the unit price is consistent with the order.
Ahhhhhhh ... now I haven't seen the order. Presumably the order
identifies the item and the quantity, but not the days, as that might
be indeterminate due to scheduling and surprises. But the quantity
is precise: they know they need 7 thing-ones ... but not for
precisely how long.
>Often the
>tolerances for all these tests will be set to zero. For those doing
>invoicing, it is therefore a critical success factor to pass these tests.
Excellent ... I hadn't considered this at all.
>In your current example for the rental of ThingOnes, the field invoiced
>quantity (7) is not invoiced quantity, nor is rental rate (.025) the rental
>rate.
>
><cbc:InvoicedQuantity>7</cbc:InvoicedQuantity>
Ummmmm .... but here are 7 Thing-one's that were rented out.
><cbc:Name>Monthly Rental Rate</cbc:Name>
> <cbc:Value>.025</cbc:Value>
You've cited only one of the facets of the rental rate calculation
... and it is a percentage, not a currency value ... is my fault only
in the naming and expression of this facet of the calculation?
>If one multiplies quantity 7 times 2.5 Canadian cents the extended price
>(line extension amount) to be $.175 Canadian dollars.
Why would that "additional item property" be included directly in
your calculation? I see it as commentary because of how I've chosen
to mark it up. Citing from my post, the three significant values for
calculation are:
<cbc:InvoicedQuantity>7</cbc:InvoicedQuantity>
<cbc:LineExtensionAmount currencyID="CAD">29.17</cbc:LineExtensionAmount>
<cbc:PriceAmount currencyID="CAD">4.17</cbc:PriceAmount>
>In fact, the proper line extension amount is $29.17, so accounts payable
>will reject this line or, worse still, pay the $.175 CAD and mark the line
>closed.
>
>Instead, I suggest that you express the InvoicedQuantity and Monthly Rental
>Rate in a way that is "backward compatible" with the more normal use of
>invoice line item quantity and rate.
Fine ....
>For the item named Thing-One, the customer has rented 7 instances of
>Thing-One, each held for 5 days during the invoice period. Therefore, the
>invoiced quantity is 35 Thing-One days.
Oh! Okay ... so what they are purchasing are "days of rental of
thing-one", not "thing-one"s! So my counting of what is being
purchased was reflecting the wrong kind of object.
>The monetary rate per Thing-One day is ($1,000*2.5%)/30 or $.833 per day.
>
>If one multiplies 35 times $.8333 CAD the extended amount is indeed $29.17.
Excellent ... I can see that.
But what led you to this conclusion? What principle did you use to
determine that which is actually being sold? Based on my lack of
business experience (I'm an angle-bracket geek, not a business man) I
couldn't see that.
>Neither the 35 nor the $.8333 appear in your invoice, but I suggest that
>they not only appear, but appear pretty much as if the customer had bought
>35 widgets for $.833 CAD each.
Okay. But I'm not sure how the user, who remembers seeing 7
thing-ones sitting on their lot for a period of time, would get "7"
from that easily.
>Customers who want the additional information to replicate the computation
>of Thing-One days and the conversion of 2.5% and asset value into a daily
>rate can look in the additional, non-traditional tags. You therefore would
>need to move the ThingOne quantity of 7 and the rental as a percent of value
>to 2.5% to additional item property along with the ThingOne value.
It all needs to be there to be reflected in a mimic of the legacy
paper invoice. Interestingly, the legacy paper invoice doesn't have
"$.833" or "35" on it anywhere ... only the facets that I had exposed.
But, to be fair, it also didn't have "$4.17" on the invoice.
All that I recall seeing on the legacy paper invoice line for "thing one" is:
Quantity: 7
Base: 5000
Rate: .025
On site: April 10, 2008
Off site: April 20, 2008
Fee: $29.17
.... with all of the calculations inferred behind the scenes. The
goal was to take this to UBL so that I could reproduce it in paper
from UBL using XSLT and XSL-FO. Hence it didn't come to mind to
express it as 35 * $.833. And, clearly, the end user is expecting to
see "7" somewhere. They ordered 7 thing-ones, and they can count them.
Before I create and post the next version, does <cac:Price>
<cbc:OrderableUnitFactorRate> come into play here? The example in
the UBL common library spreadsheet for this information item reads
"Nails are priced by weight but ordered by quantity. So this would
say how many nails per kilo." Extrapolating this to what you've
said, "Thing-ones are priced by rental-days but ordered by
quantity. So this would be the number of days." Thus converting the
rate per unit per day into the rate per unit would end up with:
<cbc:InvoicedQuantity>35</cbc:InvoicedQuantity>
<cac:Price>
<cbc:PriceAmount currencyID="CAD">.833</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="EA">7</cbc:BaseQuantity>
<cbc:OrderableUnitFactorRate>5</cbc:OrderableUnitFactorRate>
</cac:Price>
But I'm grasping at straws a bit here ... I'm assuming the customer
ordered 7 thing-ones and they ended up on site for 5 days (probably
an indeterminate number of days at order time). I'm not certain
about which unit of measure to use, as I could turn this around and say:
<cbc:InvoicedQuantity>35</cbc:InvoicedQuantity>
<cac:Price>
<cbc:PriceAmount currencyID="CAD">.833</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="DAY">5</cbc:BaseQuantity>
<cbc:OrderableUnitFactorRate>7</cbc:OrderableUnitFactorRate>
</cac:Price>
... but I don't think it is justified to make the base quantity the
number of days.
Thanks again, Fulton! I hope you (and the archive readers) are
finding this a useful discussion in exposing important thought
processes when applying UBL.
. . . . . . . . . . . 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 Nov'07 http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]