Setup a 'many' (UD) table for a many-to-one relationship with a standard table

Our end products are assigned serial numbers. Some of the component parts use to assemble the end product have mfr serial numbers and we want to record component SN in a separate (UD) table, with appropriate records in the UD table linked to the parent part SN in the Serial table. We do not need for the child (many) records to be SN tracked because we don’t want to log when we receive those parts … which I’m told is how it must be done if we use Epicor’s SN tracking. Again, all we want to records is which component SN’s link to the parent part SN.

What is your process (or what will your process be) for recording those child serial numbers? Who is the person (or what is the role of the person) responsible for doing that, and at what point (job completion, shipment, etc.)?

Creating a UD table to hold the data is not difficult, but making sure that the right person has access to it in the right place at the right time is critical. Will they have to type everything in manually?

Thanks Ernie.

This would be someone in production, and yes I can assign them the necessary permission to do so. This would be a manual entry because we don’t know the component SN until the part is assembled into our product.

We are an electronics manufacture so SN tracking is a big deal for us. You could do this with a UD table, but Epicor does track SN job parts for you as well. Though we have had to do the custom route as well for Serialized Kitting. Which in a way is what you would be doing, creating a serial parent part and then creating serial child parts (We use a UD101/101A tables to do this)

What is the reason for not tracking the serial number when they are received?

Each UD table has five “Key” fields (Key1, Key2, Key3, Key4, Key5), and the combination of those must be unique for every record. Beyond that, you can have as many fields per record as you have data to fill.

Whatever you are likely to want to SEARCH this data on should be in the Key fields (probably at least Parent Serial Number and Child Serial Number since that combination will always be unique, but also maybe Parent Part Number, Job Number, and/or Child Part Number). Beyond that, think about how you want to look at the data after entry to determine how to set up your table.

Good luck!

1 Like

When it comes to component serial numbers, our only concern is which components are related to the parent SN. We have no need to know when it arrived, lot number, etc. That’s the way we’ve been doing it for years.