David, all,
I'm trying to implement this but I have some doubts and I'd really
appreciate your advices.
Scenario:
let's consider the WG-1111 product, that has quantityIncluded = 50 and
unit price = 59.99$; this means that 50 units of WG-1111 are sold at 59.99$.
This is correctly handled by the system.
However, when you create a sales order for 1 unit of WG-1111 in the
OrderItem entity the following values are stored:
quantity = 1
unitPrice = 59.99
And from the inventory 1 unit is reserved.
This means that in warehouse I'm storing WG-1111 in sets of 50 units.
My goal is different: I'd like to store (and buy from suppliers) WG-1111
in quantity units and sell it in sets of 50 (at the price of 59.99).
Should we change the order entry process so that, if I want to sell
three sets of WG-1111, I have to enter a quantity of 150 (and add a
constraint to the shopping cart to only accept multiple of 50 in orders)
so that in the OrderItem entity the following values are stored:
quantity = 150
unitPrice = 59.99 (for a set of 50 units)
itemAmount = 59.99 * 3
?
But if this is the right approach, how can we express this information:
unitPrice = 59.99 (for a set of 50 units)
?
Should we add a new field to store the units for which the unitPrice is
expressed? Can we reuse the amountSelected field?
Am I totally wrong?
Please help me because as soon as I've figured out how to implement this
I'd like to apply the same pattern to the purcahse orders
(SupplierProduct entity)
Thanks,
Jacopo
Jacopo Cappellato wrote:
David,
David E Jones wrote:
>
> Will this require using sub-unit quantities? That's something we've
> started moving away from, and I'd prefer to continue that...
>
> -David
>
no, I agree with you that we should really avoid this (i.e. in inventory
items the qty, reservations, QOH and ATP will always be integers numbers).
I've thought a bit about this, and I think that the trick here is that
the unit in the uom set in Product.quantityUomId should be the minimum
indivisibile entity of a product.
For example, if quantityUomId = "centimeters", this means that we will
purchase, sell (or consume) and stock the product in centimeters (not
millimeters).
And the unit price (in ProductPrice) will be referred to one centimeter
of the product.
In this way, I think, the system will work fine as is now; the only
modification I will do is to store the Product.quantityUomId (in not
null, i.e. if not 'units' or 'each' uom) in the already existing
InventoryItem.uomId (every time newly inventory items are created for
the product).
Is this ok?
And, continuing with the example above, (sorry for the long post, but
this is very similar to the issue I'm facing with
SupplierProduct.lastPrice, discussed in another recent thread) if the
product is consumed/stocked in centimeters but we need to specify the
unit price for one meter (because we will sell it in 'units' of 100
centimeters long) we could represent it in the following way:
Product.quantityUomId: "centimeter"
Product.quantityIncluded: 100
ProductPrice.price = 0.5 $ (i.e. 0.5 is the price for 100 centimeters of
the product, i.e. one meter)
In order entry, if I enter a quantity of 2, in the cart the new item
will have a quantity of 200 (2*100) and the item amount will be 1$ (0.5*2).
Does this make sense? (I'm not sure it is 100% correct)
Jacopo
