@emre, thanks for letting me know your approach.
I realize that method is how it is currently done. Since you are going to re-visit the infrastructure, I like my method better, because it takes the manual math out of it.
Working in a cumulative fashion as I am suggesting doesn’t require any math on the part of the user… the system does it for you, forward and backward…
Base Unit Cost is still determined by Case Cost - that doesn’t change. I simply don’t want to have to figure out (8 x 6 = 48) in a Case; I want the system to do it for me by taking the Quantity of Pieces (8) and multiplying it by the Quantity of Trays (6).
Consider this, for a Case of Wine.
1 Case
12 Bottles
24 Ounces per Bottle (6 ounces poured to a glass x4)
I don’t want to need to figure out there are 288 Ounces in a Case. That’s why I want a Quantity for Base Unit.
Unit 1 (base): Ounce, Quantity: 24
Unit 2 : Bottle, Quantity: 12
Unit 3 : Case, Quantity: (default 1, x number of cases ordered)
Unit 3 should have the Cost as well, per 1 case
Now the system decides that there are 12x24=288 ounces in a Case - honestly, I don’t care how many ounces are in the case - this is what I’m getting at, or call me lazy.
I also don’t want to calculate the Base Unit Cost… Let the system do it for me, i.e. if a Case cost $100, then all the rest is done for me automatically (consider too that I sell by the Bottle, so I need to know the cost of a Bottle, not just a 6 oz glass)… I want to avoid having to make these calculations when I’m entering Inventory.
100/12 = 8.33 per bottle
100/12/24 = 0.347 per ounce
Recipe uses 6 ounces per glass = 6 * 0.347 = 2.08 (cost per glass)
This should also allow me to create a recipe for Bottle of Wine.
No matter the implementation, I look forward to it, and I’ll make it work for me, since I really need a 3rd Unit right now.