Jacopo I'm concerned about breaking everything down to unit cost. This is why one of the solutions we have suggested to you for this is equivalent to how we are handling this on the sales side. We define a product at the unit level, but we do not sell this product. Instead, we create marketing packages that we call "retail packs". Then we set the price there.
On the purchasing side, at least in our situation it is unusual for a supplier to provide unit or piece pricing. They only provide pricing for "vendor packs" or "wholesale packs" which are often really just some quantity greater than one of retail packs. So for example a vendor pack might really just be 10 retail packs. This is much like walking into a warehouse club like Sam's or Costco (not sure what the equivalents are in other regions) and buying a large quantity of chewing gum. When you open up the "vendor pack" that you purchased wholesale you will have 10 retail packs that can be sold individually. There is no price for the individual pack of gum when you purchase it wholesale. So it seems to me that if we can define the item, then create multiple marketing packages that reflect the quantities we can buy it in from our suppliers then we can define our supplier price on the marketing package and have a more realistic scenario of how we purchase. Under your scenario we would have to calculate the actual unit cost, which could create rounding errors. Note that I do believe the functionality you are describing needs to work since there will be cases where the original item does need to be purchased in discrete quantities. But in that case I would avoid the calculation to determine the unit cost and just put in the proper unit cost in SupplierProduct. A check on the minimumOrderQuantity and orderQtyIncrements would make sense to make sure you are creating a PO the supplier will accept. I see unitsIncluded as really just a piece of information for items that would never be broken down to the individual unit, like a bag of screws that would never be sold as individual screws, but you do need to know how many are in the bag. If you take the approach I am suggesting you will need to fix the issue with not being able to receive a marketing package and have it properly broken down and put into inventory. This is the same problem that exists with returns so this could be a high value fix. Vince Clark [email protected] (303) 493-6723 ----- Original Message ----- From: "Jacopo Cappellato" <[email protected]> To: [email protected] Sent: Sunday, July 19, 2009 4:03:22 AM GMT -07:00 US/Canada Mountain Subject: Implementing processes to support SupplierProduct.unitsIncluded field Scenario: a company sells the product WG-1111 to its customers at 0.1$ each. The company purchases WG-1111 from a supplier, but the supplier sells it in boxes containing 1000 pieces of WG-1111, at the price of 5$ for a box. When the purchased products are received from the supplier, the boxes are opened and the individual WG-1111 are put in warehouse, increasing the inventory units of WG-1111. Proposed data mapping: SupplierProduct. productId: WG-1111 SupplierProduct. supplierProductId: WG1111BOX10 SupplierProduct. supplierProductName: Box containing 10 pieces of WG-1111 SupplierProduct. unitsIncluded: 1000 SupplierProduct. lastPrice: 5$ (this means that the unit cost is 0.005$) Purchase Order for 2 boxes (2000 pieces): OrderItem.productId: WG-1111 OrderItem.quantity: 2000 OrderItem.unitPrice: 5$ NOTE: during order entry the system should only allow quantities that are multiple of SupplierProduct. unitsIncluded NOTE: the above setup will require to change all the purchase documents (order, invoice etc...) to compute order item amount as: OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice For example, the purchase order PDF sent to the supplier will show: Product: WG1111BOX10 Quantity (OrderItem.quantity / SupplierProduct. unitsIncluded): 2 Unit Price: 5$ Total Amount (OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice): 10$ Is it an acceptable solution? Apart from this, everything should work just fine (when items are received into inventory etc...); the inventory item unit cost will be computed as: total amount / inventory units = (OrderItem.quantity / SupplierProduct. unitsIncluded * OrderItem.unitPrice) / OrderItem.quantity = 10 / 2000 = 0.005$ What do you think? Jacopo
