I would like to know if Epicor is able to use Master Carton Partnumbers that are groupings of the actual partnumber in the inner casings.
Example: We have light bulbs that come in a master carton and inside that master carton there are 10x smaller boxes that are the actual merchandise cartons.
Also, I would like to know if there’s a function to place purchase orders and sales orders with the Master Carton Partnumber which would act almost like a KIT for the actual partnumber.
UOM’s would be how I would attempt it first. since it’s actually the same part just different Packaging Measures.
PCID could work but not on the purchasing end, PCID is great for packaging mixed or same parts for internal storage and shipping.
Using UOM’s WITH the use of the UPC code associated with each UOM would seem ideal to me. Epicor’s built in logic with UPC (and other Product Codes) will allow the entry of the UPC or other PC into any Part Number field and auto convert it to the Part Master Part Number and the related UOM. If you purchase in one UOM (Master Carton) and then it’s broken out in inventory, you can set the part’s Purchase UOM (or per supplier price list) and set it’s Inventory UOM to whatever you stock it in internally and on receipt it will auto convert to your Inventory UOM. Or if you want control of that conversion you can use the Merge/Split UOM transaction to break or combine into which each UOM Carton Sizes you setup.
UOM’s is a lot more flexible than they appear on the surface once you consider you can create any UOM you want and have multiple Product Codes associated with each, which all auto converts to the Part when entered.
BTW - By definition, UPC and other Product Codes are by definition by UOM which can then also drive pricing on Customer and Supplier Price Lists.
Can you provide some more detailed examples Of how you might buy, use and sell the different pack qty’s?
Here’s an example that applies to us. We use a special adhesive that comes in a can with an applicator brush (live PVC cement). We use it in production, and it’s also used in the field during installation of our equipment. This latter part means it needs to appear on Orders so it goes out with the product.
In production we use (1) OZ per Assy.
But it actually comes in a 32 OZ can.
The supplier will give us a better price if we buy a case of 24 cans.
So we have 3 UOM’s for this part: OZ (ounces), CN (32 ounce can), and CS (case of 24 cans)
We stock it (Part IUM) by the OZ (this makes fewer mistakes when entering it on a job, as the drawings and BOM’s will specify the qty per in ounces).
We buy it (PUM) by the CS. A receipt of 1 CS increases the QOH by 768 OZ (24 cans x 32 oz/can)
We sell it (SUM) by the CN. A packer with a line for 2 CN would reduce QOH bu 64 OZ
There is nothing from preventing the buyer to place an order for 768 OZ instead of 1 CS, or 24 CN. Either would process properly (but it’s best to minimize the thinking required by the receiving person).
Now all of this assumes there is nothing special about the case (like all items in the case need to have the same lot number), and that packing 24 loose cans in a box is the same as a box specifically designed for holding exactly 24 can, and marked as such.
Once transactions are created using them they can’t be deleted. I strongly recommend that you do lots of testing with UOMs, in a test environment first.
Including doing things wrong - simulate common mistakes, like order 100 BX of a screw that is stocked as EA, when you should have made the PO for 1 BX, or 100 EA. This is just so you can see how hard it is to correct those errors when they happen. And they will.
It would default to it. but the receiver can change it.
Also, the PO entry person can select to purchase it in either your stocked Qty (IUM), or the vendors selling qty (PUM). That way they don’t have to do the math to convert the vendors price per to your qty.
For example, we use a nylon thread, by the foot. But the vendor sells it by the LB (yes weight). So we have a UOM conversion that says 1 LB = 8920 FT. If we need 89,000 FT, we could just buy 10 LB, and enter the vendors price per pound.
edit
buy allowing the receiver to enter it in the vendors selling qty, it will most likely match the suppliers packing slip. If the packer says 1 CS, and there’s a case of the stuff, the receiver doesn’t have to do the math to determine how many OZ it is.
And FWIW - you can have many UOM’s not just 3 (IUM, PUM and SUM). Like screws may be invntoried as EA (so IUM =EA). But say you can buy them in boxes of 100, or 500, or 1,000. You might make UOM’s:
BX100 (1 BX100 = 100 EA)
BX500 (1 BX500 = 500 EA)
BX1K (1 BX1K = 1,000 EA)
Youd be able to select any of them during PO Entry or Receipt. They’d also be available to use as the UOM on jobs and Orders too.
It’s a double edged sword. Can solve big problems, and also create big problems.
UOM’s can be assigned to a UOM Class, then any part of that UOM Class can use them. Or them can be part specific. So you could try it on a lone part first and see how that goes.
And FWIW - even before we used UOMs and conversions we would run into problems like buying a box of 100 screws. We stocked it as SCREW-001 with a UOM of EA. But the vendor sold it by the box of 100, as P/N ABC-123.
No big deal, right? Just enter our PO for 100 EA of SCREW-001. But the PO LIne would include the vendors P/N ABC-123. So the vendor may send us 100 of ABC-123 - which would be 100 boxes of 100 screws each.