Implementing processes to support SupplierProduct.unitsIncluded field

[Jacopo Cappellato-4]

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

[Vince Clark]

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
[hidden email]
[phone]

----- Original Message -----
From: "Jacopo Cappellato" <[hidden email]>
To: [hidden email]
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

[Jacopo Cappellato-4]

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
> [hidden email]
> [phone]
>
> ----- Original Message -----
> From: "Jacopo Cappellato" <[hidden email]>
> To: [hidden email]
> 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
>