Does anyone have an idea of where why I would constantly get a “Error creating PartTran. Please retry.” error message with the following code below? I’ve looked through a couple other similar posts, but can’t seems to get anything different. This external code called via BPM.
I’m attempting to add a new inventory transfer, but it always fails at CommitTransfer. I feel like I have everything that’s need (based on other posts here), but no luck so far.
Here’s part of the stack trace…
Description: Error creating PartTran. Please retry.
Program: Erp.Services.BO.InvTransfer.dll
Method: doPartTran
Line Number: 1591
Column Number: 33
Table: PartTran
Server Trace Stack: at Erp.Services.BO.InvTransferSvc.doPartTran(String ipPartIUM, Boolean ipPartTrackDimension, String ipPCID, String& partTranPK) in C:\_Releases\ERP\UD10.2.400.18\Source\Server\Services\BO\InvTransfer\InvTransfer.cs:line 1591 at Erp.Services.BO.InvTransferSvc.ProcessInventoryTransfer(InvTransferTableset& ds, String& legalNumberMessage, Boolean refreshttInvTrans, String& partTranPKs) in C:\_Releases\ERP\UD10.2.400.18\Source\Server\Services\BO\InvTransfer\InvTransfer.cs:line 1230 at Erp.Services.BO.InvTransferSvc.CommitTransfer(InvTransferTableset& ds, String& LegalNumberMessage, String& partTranPKs) in C:\_Releases\ERP\UD10.2.400.18\Source\Server\Services\BO\InvTransfer\InvTransfer.cs:line 829 at Erp.Services.BO.InvTransferSvcFacade.CommitTransfer(InvTransferTableset& ds, String& LegalNumberMessage, String& partTranPKs) in C:\_Releases\ERP\UD10.2.400.18\Source\Server\Services\BO\InvTransfer\InvTransferSvcFacade.cs:line 312
Hello, did anybody found why commit transfer BO works sometimes but simetimes not?
I have the same issue like topic but Function with BO is working every couple minutes and errors out most of time.
And sorry @gunny72 I was going to respond this week. I tried a different approach but I am still running into this issue.
For me, I presume it relates to me forcing deferred update on an Epicor Function (EFx) while other native transactions are letting the update stay deferred.
Sorry for the delay @JasonMcD, I’ve been on Holiday.
I have this all running from a function now - and seems to be working OK.
The magic lines of code is to force the update, not sure why it doesn’t work for you.
var Db = new ErpContext();
Erp.Internal.Lib.DeferredUpdate libDeferredUpdate = new Erp.Internal.Lib.DeferredUpdate(Db);
libDeferredUpdate.UpdPQDemand();
I’ve got to come up with a good way to reproduce the problems on demand. But here is what I’ve seen.
There are about 3 scenarios in play:
System as is (using only the client for transactions)
a. No issues
Issue Transfer material via REST/Function
a. Initial problem: cannot transact same part twice rapidly
b. Initial solution: Invoke the deferred update. All seems to be well
Implementing both (1) and (2) with many users
a. Intermittent failures with the “PartTran” error (like the title of this post)
b. Sometimes the issue happens in the client and sometimes it’s an error in the REST call.
I have to think that it’s this hybrid approach (3) that gets me in trouble. One hand is deferring an update and the other hand is forcing it through immediately.
One thing I do wonder about: I’ve been putting this code at the end of my Function. Should it be at the beginning? Or both beginning and end?
Today we got the error with no prior inventory transfers today for the part. There were prior transactions, but not bin to bin. This was the aha moment.
A few things.
First, it looks like the culprit is an EFx that I made for reporting quantity to an operation (via Labor BO). We backflush parts and I did not have deferred update on this EFx - for one big reason: I made it before I made the inventory transfer one and didn’t know I needed it.
So I added deferred update to it and I seem to be avoiding the error. (Won’t be sure till I put it in Production.)
Second, I was saying the problem was hitting the same part repeatedly. Sort of true. It’s the same part and bin. If I use the same part and do not use the same bin (in or out), then there were no issues. But regardless, I think the first point should resolve this.
And third, adding deferred update to the beginning of an EFx does not help.
Three working days now since I made the change and no errors through about 700 runs. Looking good.
So, the point here, is that if you ever make any function/BPM/uBAQ/etc. and it deals with part movement or issue or any transaction, I think you need to invoke the deferred update in that function.
This seems to be true even if the transaction is indirect like an operation that backflushes material.
@Dhanalakshmi I think you are asking me, since I got notified of this reply.
The answer is this:
To elaborate, this means that you need to do a thorough audit of any BPM or function that you have ever made, if it creates part transactions, and then add the deferred update code to the end of it.
(Of course, I also mean any code that others in your organization have made, even if you made it years ago.)
Now, what tripped me up was that the Function that was messing everything up was to report labor. Is that a part transaction? Yes and no. It’s not directly, but because I was reporting quantity, that resulted in material backflush. So I added deferred update to it and we have been fine since. We have done hundreds of thousands of transactions since then without a problem.
BUT if you nor your co-workers (past and present) have never ever used deferred update anywhere, then ignore everything I have said.
Could you please share your BPM or c# code? I was able to get this working fine with a REST Api call on a Node.js application. My end goal is to get this working as a checkbox on an UBAQ. Thank you!
ahahahah no worries, honestly anyone that is willing to help or share their solution/code/BPM/UBAQ/or dashboard. I tried the deferred update that you mentioned and still wasn’t able to get it to stick.