Parent/Child vs. MPQ?

Can someone explain to me the differences between the Parent/Child Item function vs. the MPQ (Master Pack Quantity) data?

I have to purchase certain items in Master Packs, and then break them down to individual units in order to sell them. When I create a Purchase Order in SO, using the Reorder/Restock Point calculations, I want SO to look at how many individual units I need to reach my Restock Point and convert this to how many Master Packs I need to order from my supplier. Am I being mislead by the MPQ data field?

Thanks!

Johan

Reply to
jboysen
Loading thread data ...

Parent/Child allows you to stock cases and singles. When the quantity of the single item (child) reaches 0 and the case (parent) quantity is greater than 0, 1 case will be 'broken' and the single item quantity will increase by the case contents.

MPQ is an ordering mechanism. It is similar to the case described above in that it contains a number of single items, but there is no special logic to break master packs as the contents are sold. MPQ is used during ordering. If an item has an MPQ or 12, then you can only order it in quantities of 12, 24, etc... But on the RMS PO, you will not be entering 1 or 2 (as in 1 case or 2 cases), you will be entering 12 or 24 (as in the number of individual items you are purchasing).

I don't see MPQ as particularly useful, but I'm sure many people would disagree...

Glenn Adams Tiber Creek C> Can someone explain to me the differences between the Parent/Child Item

Reply to
Glenn Adams [MVP - Retail Mgmt

That says to me that I've effectively got two options to accomplish what I want:

  1. Forego Parent/Child relationship, use MPQs and set the Reorder/Restock points to individual units, creating Purchase Orders that then show the unit quantity I need (rather than case qty.).

This option makes it tough both for me and my suppliers when it comes to placing orders and receiving shipments.

  1. Use Parent/Child relationships, set the Child item Reorder/Restock points to zero as well as making them 'unorderable' so they don't show up on POs, and JUST order/transfer the Parent 'case' (thereby also letting the Parent item 'break' to Child items automatically). This would mean not using MPQ for anything at all and would give me POs that have case quantities rather than unit quantities.

This option seems to fit a little better and would give me a more easily managed Purchase Order. But it would also make my inventory counts slightly 'inaccurate' if I'm just looking at the parent items....not a big deal I suppose if the case quantity is low, but if it's high I would potentially reorder the case based on Reorder/Restock points even though the 'last' case may have just broken down to 144 widgets. Any ways around this other than setting the case Reorder point one case lower than I would have otherwise?

Thanks,

Johan

"Glenn Adams [MVP - Retail Mgmt]" wrote:

Reply to
jboysen

Reply to
convoluted

Yes, but using MPQs also makes inventory counts difficult. My stock-room at the shop won't be, for the most part, individual units (child). Rather it will be cases (parent). At that point I think I'm better off doing two seperate physical inventory counts, one for the 'floor' on a child basis and another for the stock-room on a parent basis. I guess that just means being extra vigilent about pulling the entire case from back stock and putting it out on the floor and not leaving any individual units behind.

Using MPQs seems like it would also present serious problems when receiving everything in a shipment from my supplier. I see cases when unpacking the pallet and have no idea how many units are in each case. It would also cause problems when sending Purchase Orders to my suppliers, they want case qtys. not unit qtys.

I guess the lesser of two evils at this point is using Parent/Child relationships. Now I just have to figure out how best to deal with having unique ILCs for each, but that's an entirely seperate discussion (coming soon I'm sure)!

"c> I'd use the parent/child relationship only if you need to stock and sell both

Reply to
jboysen

You're figuring out what a lot of us have known for a while, RMS handles parent/child horribly. If you only sell by each and not case you should be able to specify how many child items to have in stock before a parent item is reordered. If there are a 144 items in the case and you don't want more than 200 on hand you will always be in an overstock situation unless you always want an extra case laying around. You should be able to specify to reorder the case when the child gets below a certain count. This is why I use MPQ instead of parent/child. You just have to be viligent when ordering so that you don't receive 144 cases. Craig

Reply to
Craig

Exactly. Certainly seems RMS missed the boat a bit in this aspect. In my opinion you shouldn't have to have two unique items for the Parent/Child relationship to function. Rather one item that has data fields for 'unit', 'case', and 'master case' or something similar with the ability to define one or more of those fields as is necessary as well as a selectable default for 'this item is sold as' and 'this item is ordered as' so that RMS knows the difference between an item being sold and an item being ordered all off of one ILC and one barcode. Would it be possible to develop and add-on with this functionality?

On another note, when using the Parent/Child functionality, does the Parent item automatically break down to the Child item when the Child item reaches zero? Or do I manually have to do this?

I think I'm starting to lean more towards using MPQs, even with the inventory difficulties this represents. If I can coerce my suppliers into tagging each 'case' with the barcode and unit quantity I'd be all set. Granted, this is somewhat standard practice in the US but most of my product line originates in Denmark and they're a bit 'old fashioned'. I'll also need to figure out how best to address my Purchase Orders having 'unit' qtys. rather than 'case' qtys. if I use MPQs. Ugh.

Johan

"Craig" wrote:

Reply to
jboysen

The parent item will automatically be broken open when the child reaches zero and, if you have it set up, will order another parent to reach your minimum. I have chosen to use MPQ instead. The way I handle it is to review each PO closely and change the units being ordered to cases. Then when I receive the PO I change the cases back to units. This is very clunky and error prone but is better than having parent items ordered when I don't need them. Luckily my main supplier already has most cases broken down to units for ordering purposes but I still have upwards of 100 items from other suppliers that I have to manually change on the PO. There was a suggestion made once to add this functionallity so please vote for it if you still can. Craig

Reply to
Craig

Putting the child quantity on the PO confuses the he|| out of our suppliers. I even once received 48 cases of something where I was really requesting 48 child units. That was an expensive mistake.

I wish they would go back to the drawing board on parent/child items.

Reply to
Jason

Putting the child quantity on the PO confuses the he|| out of our suppliers. I even once received 48 cases of something where I was really requesting 48 child units. That was an expensive mistake.

I wish they would go back to the drawing board on parent/child items.

Reply to
CptSoft

Putting the child quantity on the PO confuses the he|| out of our suppliers. I even once received 48 cases of something where I was really requesting 48 child units. That was an expensive mistake.

I wish they would go back to the drawing board on parent/child items.

Reply to
Jason

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.