Erp.Services.BO.InvTransfer.dll - "Error creating PartTran. Please retry."

,

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

Any ideas?

Thanks,

Josh

C# DLL Code:

                     // get transfer record
                    invTransfer.GetTransferRecord(partNumber, Guid.NewGuid(), "", uomCode, out getTranResult, ref invTranTS);
                    wmsBase.Logging.LogInfo("GetTransferRecord partNum: " + invTranTS.InvTrans[0].PartNum);
                    wmsBase.Logging.LogInfo("invTranTS: " + JsonConvert.SerializeObject(invTranTS));

                    if (getTranResult)
                    {
                        //InvTransRow invTranTS.InvTrans[0] = (from InvRow in invTranTS.InvTrans select InvRow).FirstOrDefault();

                        invTranTS.InvTrans[0].Plant = plant;
                        invTranTS.InvTrans[0].TransferQty = partQuantity;
                        invTranTS.InvTrans[0].TrackingQty = partQuantity;
                        invTranTS.InvTrans[0].RowMod = "A";
                        invTransfer.ChangeUOM(ref invTranTS);
                        invTranTS.InvTrans[0].RowMod = "A";
                        invTranTS.InvTrans[0].FromWarehouseCode = fromWhs;
                        invTransfer.ChangeFromWhse(invTranTS.InvTrans[0].FromWarehouseCode, ref invTranTS);
                        invTranTS.InvTrans[0].RowMod = "A";
                        invTranTS.InvTrans[0].FromBinNum = fromBin;
                        invTransfer.ChangeFromBin(invTranTS.InvTrans[0].FromBinNum, ref invTranTS);
                        invTranTS.InvTrans[0].RowMod = "A";
                        invTranTS.InvTrans[0].ToWarehouseCode = toWhs;
                        invTransfer.ChangeToWhse(toWhs, ref invTranTS);
                        invTranTS.InvTrans[0].RowMod = "A";
                        invTranTS.InvTrans[0].ToBinNum = toBin;
                        invTransfer.ChangeToBin(toBin, ref invTranTS);
                        invTransfer.PreCommitTransfer(ref invTranTS, out requiresUserInput);
                        invTranTS.InvTrans[0].RowMod = "A";
                        wmsBase.Logging.LogInfo("invTranTS before Commit: " + JsonConvert.SerializeObject(invTranTS));
                        invTransfer.CommitTransfer(ref invTranTS, out legalNumberMsg, out partTranPKs);

                    }

Anyone ever figure this out? I’ve run into this lately, in 3 places - REST (EFx), DMT, and even in the client:

I am forcing the deferred update in the Efx; perhaps this is messing things up?

Yeah, it worked fine after a couple minutes - client and DMT - with the same parts, bins, quantities, etc.

Ugh, this does not bode well for my app, though.

Hi Jason,

Did you ever get this sorted - I’ve just bumped into this issue?
Thanks

Mark

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.

@Reiju No, I still struggle with this.

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();

Thanks

Mark

1 Like

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:

  1. System as is (using only the client for transactions)
    a. No issues
  2. 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
  3. 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?

OK, I see what is happening.

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.

1 Like

Can you please tell me what change you did in the code to avoid the issue?

@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!

@jakepielage Who are you asking?

Edit - Whom - I know, I know.

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.

Some thoughts:

  1. So, if you weren’t calling Deferred Update already, don’t start. You don’t want that madness unless you have an actual need for it.

  2. Are you the only Epi-guru to ever work there, or have others built out BPMs and such that may already be calling Deferred Update?