Part Class definitions

Epicor ERP 10
1

What are common or standard part class definitions?

2

A Part Class = a class of parts that differentiates that class from another class. There are different things that companies base their classes on, This depends on many factors. Types of Materials that you consume, how many buyers, how the accounting department wants to categorize inventory, etc.
My first pass is that you need a minimum of THREE part classes:

  1. Raw / Purchased material
  2. Sub Assemblies (Partially complete / stocked assemblies or partially fabricated machining)
  3. Finished Goods.
    The reason for these three categories is because these represent three different costing requirements. Raw/Purchased typically has no labor assigned. Sub-Assemblies has some labor, but is not finished, and therefore has no sellable value to the bank. Finished goods, are “ready to go”, and therefore is typically segregated by Accounting.

BUT… I almost always want to segregate the first category into multiple part classes… this is totally industry specific. In my old industry, we manufactured miniature transformers. We created about 15 different part classes… Pins, Wire, Bobbins, Cores, Cases, Laminations, Epoxy, etc. Each “Class” of material told you what it was.

Also, note that Part Classes can also optionally assign WHO the BUYER is for that class of parts. This can really help so that you don’t have to assign the buyer at the individual part level.

ONE MORE SHOEMAKER RULE: EVERY part gets a part class! I typically enforce this rule with a BPM to make sure that it is always assigned.

7 Likes
3

One warning on part classes (actually applies to anything with GL controls) …

If you use GL controls on your part classes (almost always done to specify different GL Accts for raw material inventory and finished goods), changing the part class, with a QOH of the part, can leave dollars orphaned in a GL acct.

You should do a Qty adj to zero out the QOH before changing the part class. Then another Qty adj to restore the QOH after the class change.

edit

This also applies when changing the account specified by a GL Control.

4 Likes
4

Thanks you for sharing!

5

What about if your new part class uses the same GL and you have on hand qty? We do average costing for all our purchased parts and now we want to break them up more so we can assign buyers.

Thanks in Advance

6

That should be fine.

An example of when it wouldn’t we be like if an inventoried raw material was changed to a part class that uses a different acct for inventory.

Receipts prior to the change would have DB the original acct. Issues after the change would CR the new acct.

7

Thanks.

8

Calvin, I know this is an old post, but maybe you can help. How do you guys address this. Seems like it could be a nightmare if someone inadvertently makes this change. We’re in the design phase of our project and want to make sure we can mitigate this risk.

Thanks in advance!

9

Saw this post and caught my interest. Wouldn’t it be easier to just do a journal entry? Move all the dollars associated with the QOH of the part in question from the old account to the new account. This would require one step instead of 2. Plus it should keep FIFO layers. I wonder if you could do a BPM (or application studio event that calls a function) that automates the journal entry upon changing the part class if the new part class uses a new inventory account.

1 Like
10

Changing Part Class on part with different GL’s you should:

  1. adjusted out the inventory
  2. change the part class
  3. adjust in the inventory
11

A BPM to stop the change if the new class had different GL Controls would work. If that’s to complicated, maybe just look for any change of Part Class, and either stop it, or throw up a warning.

A most basic preventative measure would be to limit changing PC to specific security group.

PS I like Dans idea for maintaining FIFO (and other issues like Lot and SN controls), but…

Really don’t like accounting doing JEs on “system accounts”. They’ve too much history of “fixing” the system, only to realize the system would be correct after the next transaction, and then have to fix their fix.

1 Like
12

Thanks for the feedback! We’re currently working in a system that was implemented in 1999 that will adjust the GL in the background when the class code is changed so I’m a little blown away that this isn’t something that Kinetic can handle.

The idea of removing inventory and losing FIFO and lot traceability sounds like it could cause some compliance audit issues. On the other hand, making journal entries to these accounts when parts are moved could cause financial audit issues. Sounds like we’re in a lose/lose situation here.

Just curious – are my expectations too high that I would expect that the system would have recorded a move that has all the associated account numbers in the background?? (i.e.: every part class defines what GL will be transacted against). Feels like I’m going to be putting security on and babysitting a field that shouldn’t require it.

13

Which is a good reason to use GL Controls sparingly.

14

Sounds like an Epicor Idea in the making…
But there is a much deeper challenge that could take place. what if someone actually changes the GL Control itself. if they do that, and change the inventory account on the GL Control, it could conceptually change 1000s or MILLIONS of parts, making this not something suitable for an automatic GL transaction.

ALSO… even for Partclass changes, a part could be in multiple SITES and WAREHOUSES, and changing the part class, with the site/warehouse driving a flexed field, the transaction could be fairly deep since the debit/credit would need to be accomplished for each location that the inventory currently exists. (just thinking out loud how big this enhancement would be)… how big of a problem is this? It probably depends on the company.