We are getting this generic error when trying to process MFG-WIP transactions (job receipt to job) in the Material Queue after upgrading to 10.2.300.8. We are getting this error on MFG-WIP transactions that were created in our old version (10.2.100.8) and also in the new version. Other transactions like MFG-STK and STK-MTL work just fine.
Has anyone had this issue with the upgrade? Any ideas would be appreciated.
Thank you!
-Sharla
Do you have any active MES transactions? Said a different way anyone logged into MES and clocked on a Job. I would make sure you close all MES connections and run COS/WIP capture before backing up the database and trying an upgrade in test. This shoulda like you may have an open transaction somewhere maybe. There is a conversion program to release active WIP records of one is hung.
Hi Josh. I’m not sure I understand the connection. What does MES labor records have to do with being able to complete a job-to-job transaction in the Material Queue?
Either way, there were no active labor records when we did the upgrade.
Thanks, Sharla
Can you do the transaction out of the material queue?
@scline I am sorry I misread what your problem is here. I did not realize it was MtlQueue. I thought it was processing an MFG-WIP transaction in general.
Do you have verbose logging turned on at the server level? Just wondering if there is more detail in the log file. Is this coming up when you try to process? Can you view the record and each option has a correct setting before processing?
Can you post a few more screen shots?
Sorry for the confusion!
Brandon-
No, we cannot do the MFG-WIP transaction from the queue. That is our problem. (We can do a manual MFG-WIP transaction outside of the queue and it works fine… but obviously leaves the row in the queue.)
When we try the MFG-WIP transaction from the Queue, we get that error and then the Job Receipt to Job window appears with nothing filled out. If we fill out the screen manually and click “OK”, the transaction does in fact happen (can see it in Part Tran Hist Tracker), but the row remains in the Queue like it still needs to be processed.
Thanks, Sharla
That’s what I meant, can you do the transaction from the regular client. I just wanted to see if we could isolate the problem to see if it’s the material queue itself, or if there is a problem with the transactions overall. So it sounds like it’s just a material queue problem.
You can delete rows from the material queue using the delete button. It’s not ideal, but my might be a workaround until you can figure out what is going on. Basically, do the transaction, then go delete the row.
Have you created a ticket with service yet?
Hi Brandon.
Yes, that’s exactly the work-arounds we’re doing this weekend (and until we get a fix). Yes, I created a support case yesterday, but I usually have great luck here so I thought I would give it a try. 
Thanks, Sharla
we don’t have 300 yet, but should have a test system set up soon. When I do I’ll test it out here and see if it behaves the same in our system to.
I’d appreciate it! Thanks!
Did you upgrade your DB?
https://epicweb.epicor.com/doc/Docs/Epicor10_ReleaseUpgradeGuide_10xto102200x.pdf#search=upgrade%2010.2
"Note Be sure that Task 3000 (DataModel) completed successfully. If it failed, manually regenerate
the data model. To do this, right-click on your migrated database and select Regenerate Data
Model. Verify the Server Name, Database Name and Authentication. Click Generate. The process
may take several minutes. When complete, click OK. Click Close.
"
Hi Chris.
Yes, we upgraded the DB. Our Data Model Regen actually did fail because we forgot the .NET install. However we did the .NET install and then completed the Data Model Regen successfully. The error remains.
Thanks, Sharla
FYI for anyone else encountering this issue… It is a confirmed bug 
in .300. The fix is planned for release 10.2.300.12 with an ETA of 3/13/19. (PRB0210647 in case anyone wants to review the details.)
Thanks, Sharla
