On Jul 20, 2009, at 12:43 AM, Vince Clark wrote:
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.
I think that what I have proposed meets all the above requirements.
Under your scenario we would have to calculate the actual unit cost,
which could create rounding errors.
The unit cost is only computed when the inventory is received (and
InventoryItem is created), but this will happen also if we implement
the receiving/unpacking of "vendor packs" (marketing packages).
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.
I think that this information could be stored in Product.
piecesIncluded field.
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.
I agree that implementing automatic mkt pkg disassembly would be a
nice feature (however there will be other processes to fix, MRP and
some reports, to properly show correct information if we purchase and
sell different product ids that related to the same inventory); but
for this specific use case scenario I just don't think it is needed.
Jacopo
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
