Nonconformance and customization - Use existing fields or UD ones

Epicor ERP 10
1

Good Afternoon,

I am trying to decide how to go about a customization on Nonconformance entry that has been requested. Frequently our nonconformances come from inventory, well after PO receipt has been done. Our QA folks have a paper form (i.e., called Material review report) that they fill out to date. The only time they actually do the nonconformances in system are when they want to return to vendor and get a debit memo and a person higher up in the chain of QA command does that.

They are on board with an engineering request to get the nonconformances into the system. They would like the same people who can fill out the paper to be able to do same entry of data at nonconformance entry. This includes PO number, Job number, Vendor Number and name, and sales order number, in addition to comment regarding why nonconformance.

The system has fields for PO number, Job number, vendor number in system already, for when a nonconformance is done against PO receipt or job material. I am thinking of using these same fields for entry of inventory nonconformance when needed and have tested and see it can be done. Alternately, I could use UD fields to store this data since system is not exposing these for completion naturally via nonconformance entry because the NC is frequently from inventory. I’d really like to use existing fields where feasible, but have concern that it could cause some future processing difficulty. The end purpose for all of this is to provide dashboard of the data to allow for analysis and do away with paper form. I know that it would really be preferred to do the NC at time of receipt, and off the job, but we don’t have the current people/discipline to do this right now. And I keep thinking, well sometimes things would be missed anyway and have to come from inventory so…

Can anyone give me their thoughts on whether to use existing fields or go for the UDs on this?

Thanks
Nancy

2

Be careful re-using fields for this. Some of those fields aren’t actually available on the table anyway (Like Vendor Name).
I would recommend UD fields if you have arbitrary values to record. You can set them up to be “LIKE” the fields they represent so they have right-click ability.

3

IMHO i avoid ‘hijacking’ any existing fields in a given form/process if it’s used by Epicor in a base function or process flow. Usually they are good about declaring a given field as free form or user based if it’s not already gainfully employed by an existing process (see the data dictionary). Hijacking these fields can do anything from polluting other data/metrics to outright breaking other processes in their natural state. The overhead to creating fields for your own use is pretty light weight i think. Not to mention is more supportable from a documentation standpoint for your custom processes. Per Jason’s comment, you can add additional and extended properties to your custom fields to get them to behave like other key fields.

4

Darn, I can’t check two solutions!
Thanks Rob and Jason for your input. Using extended properties is a great idea. You’re right, it’s not worth possibly breaking something else.

Nancy

5

This. All. Day. Long.