In Kinetic - Best way to Reuse Serial #'s multiple times?

Hello All,

I am new user to Kinetic and the forum and appreciate any advice on this topic.

We are going live with Kinetic in January 2024.

Our business consists of creating a serialized part # for a customer. We receive the original serialized part back multiple times to repair. We may ship back the same serialized part after it’s repaired or we may ship a similar part with a different serial #.

Basically looking for a quick way to have the Serial #'s active so we can assign to repair jobs and shipments and then track using the Serial Number Tracker.

In a past life, we used RMA as a part number and the shipped serial number for customer repairs. The serial number tracker will show the original shipment and then the RMA part number will show all of the repairs. In the RMA Part Description, we overwrote it with the previous part number. It’s one thought.

Thanks Mark. That is an interesting idea, however we have a lot of legacy data and want to continue to use existing part #'s.

Epicor works great with tracking serial numbers through the whole life cycle as long as the system is used as designed. I have seen issues when companies do not use the system correctly and they run into problems.

One of these areas has to do around parent and child serial numbers. If you sell and ship a customer SN 1 and they call to return SN 2, you will have issues if that is the SN you use for the RMA. Regardless of what they are returning, you always want to enter the RMA with the parent SN.

You can then disposition the RMA and swap out a SN during a repair.

YES! Is there already an Epicor Idea for a “living” BOM, which maintains these S/N relationships? :thinking:

Epicor already does maintain it. (NOTE: I’m speaking to manufactured parts with RMA returns; NOT field service.)

The reason we chose this path, and unless something has changed, it was near impossible to reuse the part number due to the S/N lifecycle in Epicor/Kinetic. You have to use Serial Number maintenance to change the status and that was always iffy. Maybe it’s better now? :person_shrugging:

Agree Mark… we are running into problems reusing the serial #. The RMA process is an option, but we have hundreds of orders and was looking for something more streamlined to just make the S/N status active again.

@thomascratty , what are you trying to do and where are you running into issues? I have not had any issues using serial numbers in Epicor except when an employee did not follow the correct process.

@jkane, thanks for the feedback. The RMA is the path we’re headed down and probably the right one… However, we have high volume of these orders, and this will add some additional steps to the process… wanted to make sure this was best practice and explore if there were any possibilities outside the RMA process.

A business process that I can really relate to. Our shop is 95% repair/refurbishment of serialized parts, extra wrinkle is that the customer may change their serial number to suit their system, or we may not even have sold the original part and therefore have no record. We tried RMA many years ago and the overhead damn near killed us.

In our case, our jobs are all qty 1. We enter the sales order releases with qty 1 and store the customer serial in the reference field (or you could use a new UD field). We store a copy of the serial in a UD field on JobHead with a BPM. We use auto generated numerical serial numbers within Epicor and store the customer serial in a UD field on the SerialNo table, this is also auto populated via BPM or function. Every order results a new (internal) serial number record and we can query history based on the customer serial UD field.

Forcing a qty 1 restriction does add more overhead but when dealing with customer product we can’t afford to mix. For us this is best solution and gives us the traceability and serial separation we need.
@thomascratty dm me if you want to know more details of our process.

@cdcooper, thanks for the valuable information… This sounds like a great solution… I’ll be in touch!