I made a boo boo today. We are in the final phase of implementing epicor, and I did something dumb. I was adjusting inventory, and noticed a duplicate part. I went to delete it, but it had a transaction on it. Keep in mind, accounting is currently turned off for inventory transactions until we go live. There was/is no costs associated to the part, and the transaction was an adj-inv. I wanted to delete the part, so I deleted the record in the PartTran table.
The only transactions that exist in the table are adj-inv. Again, finance is currently turned off for inventory transactions. And there is no costing associated with any part in the database.
No need to scold me, I know it was incredibly stupid. I just need to know so I can talk to my boss if needed, did I just screw us? If so, is there anyway to fix it?
I know that’s an option… Just lose hours and hours of work. So it’s really that screwed? No fixing it, no redeeming it? I can’t recreate the record on the back end?
Well you could restore the record into another DB and then copy the part tran record back over, however you also then deleted the Part from Part table and I assume all related tables (Part Rev?) etc… so if you can figure out exactly what you removed… MAYBE you could restore the records back individually…
Restore the DB to another instance, do a DB wide search for that PartNumber and find any records that exist. Then you could manually restore those records into your other DB.
However if it were my DB I would have no faith whatsoever in the data at that point, but if you are willing to live with that…
Well I did, but I don’t think they fully understand what actually happened, and don’t view it as big of a deal as it is. What tables reference this PartTran table?
Pretty much everything in the system regarding inventory , financials and the such use PartTran in some fashion. If it’s just this one record you are probably ok doing the manual restore.
I know you are not. No one recommended deleting the record either, but here I am. At this point, if it is as hosed as you are implying, then what does it hurt to go that approach?
We have no way to know of its “hosed” or not. The fact remains that manually deleting PartTran records can have severe repercussions throughout the system. However by what you’ve told me your system is pretty much in a virgin state so you might be ok just deleting the Part and moving on. However once you’ve delete the record there is really no way to know what if any impact it will have in the future. (Probably none, especially if you delete the part and anything else related to it)
There were no financial transactions in place since there was no inventory movement or adjustments.
You are likely ok to remain as you are, just delete the part and move on, but if you want to restore the PartTran record and just “deactivate” the part going forward you’ll have to do it manually as above.
Sorry it is hard to give you an exact “correct” answer because there really isn’t one. There “could” be issues in the future… maybe… but it could all just be fine assuming there aren’t other records in the DB laying around.
Thank you Jose for your help. That is the crappy part about what that. The only way we will ever know if it causes issues is down the road. I want to delete the part, but I don’t want to cause further trouble than what has been done. The only thing this part# was used for was this transaction, so it is no where else in the system. I created it, then did a qty adjustment.
I agree with Jose, if you unintentionally created the part and then ran a QtyAdj transaction with Inventory & Accounting interfaces disabled then you should be ok.
To be sure you might want to check the TranGLC table for any reference to that transaction, not sure how you would do that as I don’t think the part number is referenced there, maybe by timestamp? and other data on the record?
Also you can do a DB wide search for any other references to that Part Number.
ApexSQL has a very nice free DB search tool:
Okay. This helps a lot. I checked out that table, and because we have transactions turned off, the only items in the table are for PORel. There are no Inventory transactions in that table. So I think I am alright then
Well at least we think we did. We are talking with our consultants, and I think they are still implying we might need to restore an older version. Getting mixed feed back between here and them.
And you are dang right. As soon as I did it, I immediately regretted my choice. Stupid stupid stupid. Why is it we have to learn the hard way?
Another quick dirty is to compare the DB against a restored older version. I have used SSDT in visual studio. Most compare tools will allow you to select specific tables. I would select all ERP schema tables, identify the differences and reconcile if needed. This can take a while and can sometimes be bother some but it does give you a defined difference between DBs. Take a back up of the DBs before starting, maybe even run this in an test environment if you have the resources.
