Jacopo You've probably already thought of this, but I've been finding the new Auto Marketing Package system to work excellent for situations like this, as it let's me take a base set of products and sell them in a wide variety of combinations while keeping perfect track of inventory and very clear descriptions of what's being bought and sold.
Thanks Daniel On Sun, 2006-09-17 at 12:30 +0200, 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 > > >
