So, what you're saying is that you want to stock in quantities of 1
but sell only quantities of 50?
You could have a product (product "A") that represents a single unit
and put that in inventory but don't make it available for sale, and
then have another product (product "B") that is available for sale
that represents 50 of the stocked product and use a marketing package
or manufactured product to handle the quantity.
In this way you don't need any price attached to product A, and
instead just have your $59.99 associated with product B. That way
even if it is a small price that would make the price of product A
too small to reasonably handle, it will still work fine.
-David
On Sep 17, 2006, at 4:30 AM, Jacopo Cappellato wrote:
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
