I know a baker who is technologically astute. He runs his bakery on JD Edwards EnterpriseOne ERP software, because EnterpriseOne features Advanced Pricing, which can handle sweet discounts on doughnuts and tiered pricing on cakes.
Using the EnterpriseOne manual, my friend the baker has figured out how to properly set up his pricing hierarchies and schedules. He has also figured out how to price a baker’s dozen of doughnuts. He simply sets up a list price and a discount pricing adjustment with Basis Code “5” (add on amount), Factor Value Unit of Measure “BDZ” (13 EA [each] == 1 BDZ [baker’s dozen]), and Price Partials = “0” (no). The discount is equal to the price of one doughnut, so that each time someone orders thirteen doughnuts, he receives the discount and pays only for twelve. Similarly, if he orders 26 doughnuts, the thirteenth and twenty-sixth are free. The price partials flag makes order entry simple because EnterpriseOne is smart enough to know that the customer gets the discount only after reaching the whole baker’s dozen.
Now, my friend the baker has a challenge. He is about to introduce a line of cakes, and because most of the cake-making effort is in the frosting, the amount of work required to make a three layer cake is only slightly more than that required to make a one layer cake. Therefore, although orders are entered by the layer, pricing is by the cake, and each cake may have up to three layers (3 LR [layer] == 1 CK [cake]).
The advantage of advanced pricing is that we don’t have to create pricing structures for each item, and if our friend has hundreds of cakes he might build, we can save him some time by pricing those cakes with a single formula. It is not easy, however, to see how EnterpriseOne could handle this pricing structure. In the case of the baker’s dozen, EnterpriseOne finds the multiplier for the discount by converting the each (EA) quantity to baker’s dozen (BDZ) and then rounding down. To properly get the number of cakes, we would need to convert layers (LR) to cakes (CK), and then round up.
First, we might try doughnut strategy in reverse. An adjustment using Basis Code “5” but with a positive factor value gets us close, but we will always be short by one cake unless your order has a multiple of three layers.
Trying a different tack, what, if we create a pricing adjustment with Basis Code “7” (add on formula amount)? Using the formula “&SDUPRC * ( ((&SDUORG#CK/(1#LR/1#CK))+1) / 1000000000 * 1000000000 / (&SDUORG#CK/(1#LR/1#CK)) )”, we can accomplish this feat (your pricing constants may vary).
What did we do?
- “&SDUPRC…” gets the list price in Cakes.
- “…((&SDUORG#CK*(1#CK/1#LR))…” converts our transaction quantity to CK cakes (it was entered in Layers).
- “…))+1) / 1000000000 * 1000000000…” By adding one, dividing by 109, and then multiplying by 109, we have achieved the ceiling function that EnterpriseOne does not offer. The rounding is accomplished by exceeding the available precision of UPRC, and the ceiling is accomplished by adding one before rounding.
- “…/ (&SDUORG#CK*(1#CK/1#LR)) )” One last time, we use our quantity converted to cakes.
In simplified form, we have [Unit Price] * [ceiling(# of Cakes)] / [fractional # of Cakes]. Since EnterpriseOne will find the extend price by multiplying by the fractional number of cakes, that part gets cancelled out, and we are left with pricing by the whole cake!
Note that this method does have a limitation or two. A key limitation is that the orders must be entered in layers or the unit of measure conversions mess things up.
Do you need more help developing your advanced pricing rules? Contact us at Deft Flux via the contact page.