Part Class and Product Group fields

Over time we’ve used Part Class and Product Group for different things(a bit of a mess), and we currently use them for storing lifecycle and product family. We’re in the process of migrating to E10, so now is a good time to “fix” how we use these fields if there is value.

We don’t do much in regards to financial reporting(beyond the basics), and in talking with a consultant to help us understand product profitability he indicated we’re not using part class and product group as they were intended. He recommended we use the fields to categorize how we purchase parts and how we sell parts, as standard financial reports assume that is how we are using these fields.

Any recommendation? Are we painting ourselves into a corner such that as we mature and start wanting to better understand our finances that we’ll have problems because of how we use part class and product group, or…?

1 Like

Your consultant is correct. I recommend reading up on the intended purposes of part class and product groups as they have multiple functions within Epicor.

As for financial transactions, to keep this high level, product groups will direct GL transactions for sales and cogs accounts. Part Classes will direct inventory accounts. Take a look at the GL control setups in E10 for Product Group and Part Class, you will see the accounts for each.

As for how you use these fields, it’s up to you and your business needs. There may be other fields you can use to track the data you have been storing in the class and group fields. Maybe add a few UD fields if you can.

5 Likes

An important thing to note, is that once a PrdGrp or PartClass is referenced on a GL transaction, it can’t be deleted. And there is not an “inactive” field to prevent future use.

I ended up adding a UD field to the PG and PC tables, then using the field to filter the combo boxes where you can select the PG or PC (Orders, Invoices, PO’s, etc…)

1 Like

As others said, your consultant was correct. PartClass = Inventory, Product Group = Sales, COGS, & WIP.
The design is intentional. if you have a part number for a “BicycleWheel”, it might be in a Part Class of “Purchased Hardware”, but in a product group for “Spare Parts”.
Where I used to work, we made miniature transformers… which are made out of about 10-15 parts (Wire, Bobbin, Case, Core, Laminations, Pins, epoxy etc)… the transformers we made were in a bunch of product types: Inductors, Delay lines, Transformers, LVDT, Switching, etc.

  • All materials had an appropriate partclass assigned, but the Product Group was typically “Raw Material”
  • All finished transformers a partclass of “Finished goods”, and had the correct Product class for the type of transformer that it was.

Note that the Product Group can be MODIFIED at the sales order Line level… in other words, you can sell Part A which is normally a Product Group X, but change the product group to something else.

When in doubt, you can always look at the pages from Part Class & Product Group Maintenance.

Part Class Setup is all about Inventory, Inspection, who the BUYER is (if it is purchased), approved Suppliers, Negative Inventory actions, Min Max, etc


image

But Product Group is all about Selling, warranty, Sales Territory, Job Closing (wip)
image
image

The GL Controls match up with these definitions… Part Class refers to Inventory GL accounts… whereas the Product Group refers to WIP, Sales, COGS.

3 Likes

I hate to bring up this old post, but we are considering utilizing these fields but already have existing values in them.

Is this still the best way to not use outdated groups/classes?

For Product Group, yes.

For Part Class, the web version has an Inactive flag.

3 Likes

Nate - a potential big issue exists (that’s not so obvious), when changing the PG or PC selected for a part.

If you have GL Controls assigned to those two (PG’s and/or PC’s), future transactions might not flow as expected. The best example would be if you have a GLC for PC, to use a special inventory account for specific parts.

  • Say you part specifies PC_01, and PC_01 use GL Acct 1124.
  • You make new PC (PC_02) and set its GLC to use account 1166 for inventory
  • There is existing QOH of the part when you change the PC from PC_01 to PC_02

Prior receipts of the part would have debited acct 1124. If the part’s PC was unchanged, issues of that part would credit 1124.

Issues of the part after changing the PC to PC_02, will now credit 1166.

And note that some GLC’s get “queued”. Meaning the GL account to use is recorder at some time prior to the transaction. A PO line with a PC is a good example.

If you create a PO line with a PC selected, the GL acct to use will be recorded at the time the PO LIne is made. If the part’s PC changes after the PO was made, the GL account from the prior PC will be used. Even if the receipt doesn’t happen until after the parts PC changed.

1 Like

Part Class had an inactive flag created for it several releases back… but as @jkane said, it is only visible in the Browser based Kinetic screen since we are not putting new features in the smart client/classic version. If you are still using the smart client version, you could temporarily use the browser version, edit the field, and then go back to smart client. (or you could manually add the field as a customization to the smart client… OR best yet, just start using the new version of the screen.)

For Product Group, we have not yet added the inactive flag. There is an Epicor Idea for this: KNTC-I-2015 - Inactive flag for Product Group

2 Likes