PartLot Table

Good morning,
I have a Lot Finder BAQ that looks at PartLot, and links it to RcvDtl, Part, and PartBin to pull in relevant information about the lot in question.

I recently noticed that there is a lot in my PartLot table that no longer has any qty on hand. What function/process removes records from the PartLot table? I guess I thought that PartLot only existed if there was a quantity. I can see that is not the case. The BAQ table description for PartLot has no details at all.

Can someone help me understand how PartLot table is used?
Thanks!
Nate

I don’t think the data in PartLot ever goes away. It contains relevant data about the lot that you record and may need to refer to long after the quantity of the lot is consumed, like mfg batch #, expiration date, etc.

1 Like

Thats a great point! In this one instance someone accidentally created a lot with the same number as another part number’s existing lot. We wanted to remove that mistake, and I think it is now stuck in PartLot.

I mean I’m sure you have your reasons, but that technically isn’t a mistake. The lot number itself isn’t the key, part # + lot # is the key.

You could have a million parts and they could all have a lot # 1, they are still distinctly different things.

2 Likes

Just to clarify, there are no rules against having two parts with the same lot number. This happens all the time in industry. This is why the index to the part lot file includes both the part number AND the lot number (This same rule applies to Serial Numbers too).
Also confirming: The PartLot table is one of those permanent record tables. While you CAN change SOME of the fields (expiration dates for example), the partlot record is kept after all the quantity is gone to zero. Why? for lot trace reasons… there is information that needs to be kept for the future if the lot ever has a challenge. This way you can trace back to the source lot information.

2 Likes

Thank you guys! This makes more sense now. It would be neat if we could easily see the tables that are “permanent record” tables when designing a BAQ.

It is a mistake. The lot does not exist for the part number that it was entered for in reality. So having a record in the PartLot table showing a link between this lot number and this part number is incorrect information. If someone were to look back at this lot, they may incorrectly begin looking for the wrong part number.

I can easily filter my LotFinder BAQ to only show lots with an on hand quantity, which would eliminate this issue for the user. But on my end, the record in PartLot still holds incorrect information.

While in Lot Entry, I attempted to delete the lot. However the part number has another lot with a quantity on hand, so I couldn’t delete the records from Lot Entry. I am going to check with receiving to make sure we do actually have the part on hand. If we don’t have the material on hand, I should be able to quantity adjust the stock out of the other lot, perhaps allowing me to delete the lot record from Lot Entry.

What do you think?

EDIT: well, poop. The material is in stock, so I can’t try deleting any records. :poop:

I had never tried it before, so I tested it. How about that.

I was able to delete a lot in lot entry. This Part/Lot had no QOH, but it did have other data attached to it. (MFG Batch # to be specific).

This part did have plenty of other quantity in other lot #s, but not the one I tried to delete.

What message do you get when you try to delete?

2 Likes

IDK what I did wrong the first time, but on trying again to show you it worked! Woooo! :partying_face:

1 Like

The key to MOST part/lot/serial number deletion is transactions… if there are transactions (PartTran records usually, but also others) that include the part/lot/serial number, you can’t delete them. If there are no transactions, it’s likely possible to delete them.

If your user had actually received a quantity into this Lot Number, then adjusted it out, you would not have been able to delete it.

1 Like

Thats a great point. Thankfully they caught it before they received a quantity!

I do not believe this is true. I deleted a lot that had been received and then issued in full.

e: actually let me verify that instead of talking out of my…

e2: yes definitely able to delete VIA lot entry Part/Lot combinations that have transaction history.

1 Like

and the plot thickens!

That should be a problem… because now you have a lot that you have no history on.

EDIT: It’s a BUSINESS problem… why have Lot Traceability if you can’t trace your lot?

1 Like

I am surprised it works this way. You do not lose the transaction history though. On the surface it seems like the only thing you lose is the lot specific data like mfg batch #, etc.

This seems like a boon if you account for @NateS’s situation where a lot is entered in error.

Gets scary when you think relevant data could be deleted by accident.

1 Like

We attach material certs to the Lot, so it’s nice to keep it around for any future quality concerns. :person_shrugging:

1 Like