When a kit has a top level price of $17.31 and its components are
ComponentA individually priced at $2/EA - Total unit price $2ComponentB individually priced at $3/EA - Total unit price $3ComponentC individually priced at $5/EA - Total unit price $15How should I expect that $17.31 price will get distributed among the components, and is there a base logic block I can call to get back that distribution given the above inputs?
I tested the above kit configuration/price and what I saw is the platform distributes the prices as follows, and everything looks good/adds up as far as I can tell:
ComponentA individually priced at $1.72/EA - Total unit price $1.72ComponentB individually priced at $2.60/EA - Total unit price $2.60ComponentC individually priced at $4.33/EA - Total unit price $12.99Still interested in what logic block is doing these calculations and how it all works so I can leverage that logic outside of creating a Sales Order in the UI if possible.
I took a quick look and it seems that CalculateTotalAmountsForSalesOrderDetailKitshandles those calculations. That logic works completely differently than the calculation logic for the Landed Costs module, but it’s essentially the same premise: take some total amount and distribute it across many detail lines based on some allocation method.
It appears that there’s two methods supported in the kit pricing logic - data item KitPricingIO has values Roll Up and Top Down. Don’t know the inner workings, but it seems like based on those, calculations distribute differently per-detail and then the logic handles any rounding errors.
Thanks Ross. If the kit contains quantity 7 of a single item, and the top-level price is $10, there is no unit price that will add up to $10. Do you know if the logic splits the original one item with quantity 7 into into an item with quantity 6 with one unit price, and an item with quantity 1 with a different unit price when adding the kit to a Sales Order?
Please take with a grain of salt - I’m not a subject matter expert for kits.
My expectation would be that all 7 of the same item are kept together unless there’s a reason that part of the inventory would be priced differently (for example, of the 7 units, 6 were sourced from one Lot and the other was sourced from a different Lot, which may have different prices). That kind of split is unlikely until attempting to hard commit, though.
It likely isn’t a problem that $10 doesn’t evenly divide into 7, as the system can store a unit price with more precision ($1.4286 or $1.43) and then round as necessary. I believe that the sales order can capture any rounding discrepancy and fix it dynamically.
@dave.anderson2 confirmed on @ross’s diagnosis in a test I just did.
Your example gets handled by the system as 7 @ 1.43 for a Gross of 10.00 on a single line even though 7 * 1.43 is technically 10.01.
