New part - error when changing UOMClass

Just wondering if anyone has seen this error before? Thanks.

1.) E10 --> Part Maintenance --> new part
2.) Change UOM Class - no other fields changed yet i.e. PartNum and Description are still blank
3.) Immediately receive the following error message

Business Layer Exception
Can not modify uomClassID. PartTran records already exist for this UOM Class.
Exception caught in: Epicor.ServiceModel
Error Detail

Description: Can not modify uomClassID. PartTran records already exist for this UOM Class.
Program: Erp.Services.BO.Part.dll
Method: ChangeUOMClassID
Line Number: 4301
Column Number: 17
Table: Part
Server Trace Stack: at Erp.Services.BO.PartSvc.ChangeUOMClassID(String uomClassID, PartTableset& ds) in C:_Releases\ERP\UD10.1.500.15\Source\Server\Services\BO\Part\Part.cs:line 4301
at Erp.Services.BO.PartSvcFacade.ChangeUOMClassID(String uomClassID, PartTableset& ds) in C:_Releases\ERP\UD10.1.500.15\Source\Server\Services\BO\Part\PartSvcFacade.cs:line 666
at SyncInvokeChangeUOMClassID(Object , Object[] , Object[] )
at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
at Epicor.Hosting.OperationBoundInvoker.InnerInvoke(Object instance, Func2 func) in C:\_Releases\ICE\3.1.500.15\Source\Framework\Epicor.System\Hosting\OperationBoundInvoker.cs:line 59 at Epicor.Hosting.OperationBoundInvoker.Invoke(Object instance, Func2 func) in C:_Releases\ICE\3.1.500.15\Source\Framework\Epicor.System\Hosting\OperationBoundInvoker.cs:line 28
at Epicor.Hosting.Wcf.EpiOperationInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) in C:_Releases\ICE\3.1.500.15\Source\Framework\Epicor.System\Hosting\Wcf\EpiOperationInvoker.cs:line 23
at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
at System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(RequestContext request, Boolean cleanThread, OperationContext currentOperationContext)
at System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(RequestContext request, OperationContext currentOperationContext)
at System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(IAsyncResult result)
at System.ServiceModel.Dispatcher.ChannelHandler.OnAsyncReceiveComplete(IAsyncResult result)
at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Runtime.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.SecurityChannelListener1.ReceiveItemAndVerifySecurityAsyncResult2.InnerTryReceiveCompletedCallback(IAsyncResult result)
at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Runtime.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.TransportDuplexSessionChannel.TryReceiveAsyncResult.OnReceive(IAsyncResult result)
at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Runtime.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.SynchronizedMessageSource.ReceiveAsyncResult.OnReceiveComplete(Object state)
at System.ServiceModel.Channels.SessionConnectionReader.OnAsyncReadComplete(Object state)
at System.Runtime.Fx.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.Security.NegotiateStream.ProcessFrameBody(Int32 readBytes, Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.NegotiateStream.ReadCallback(AsyncProtocolRequest asyncRequest)
at System.Net.AsyncProtocolRequest.CompleteRequest(Int32 result)
at System.Net.FixedSizeReader.CheckCompletionBeforeNextRead(Int32 bytes)
at System.Net.FixedSizeReader.ReadCallback(IAsyncResult transportResult)
at System.Runtime.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.ConnectionStream.IOAsyncResult.OnAsyncIOComplete(Object state)
at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted(SocketAsyncEventArgs e)
at System.Net.Sockets.SocketAsyncEventArgs.FinishOperationSuccess(SocketError socketError, Int32 bytesTransferred, SocketFlags flags)
at System.Net.Sockets.SocketAsyncEventArgs.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

Client Stack Trace

at Epicor.ServiceModel.Channels.ImplBase`1.ShouldRethrowNonRetryableException(Exception ex, DataSet[] dataSets)
at Erp.Proxy.BO.PartImpl.ChangeUOMClassID(String uomClassID, PartDataSet ds)
at Erp.Adapters.PartAdapter.ChangeUOMClassID(String uoMClassID)

What happens if you put in the part number and description in first? I think Epicor is assuming this is the order that everyone is using.

2 Likes

Yes, no error with that order.
But the order is not an issue in any other test/pilot/live systems I’ve checked.

Have not been able to track down why it’s only happening in Live.
And at the form level, seems weird?
I’m running the base form, as far as I can tell, no BPMs, extended properties.

Only reason I ran into this, I was asked to set some defaults in the form when the new part is started. UOMClassID being one of the fields.

Do you have a part number in your system that is null, or just a space or something? It sounds like the system thinks that the part number exists already, but I would imagine you won’t be able to get rid of it if you do. Although that wouldn’t explain why it only happens in live…

I’m sure someone will come up with a suggestion on where to put your BPM so that it sets the defaults after the initial creation to get around that. I wish I could help, but I don’t know the BPM process and the BO’s well enough to help with with that.

We had something similar with RFQs begin done for non-master parts which then became parts. The RFQItems table has the item, but no UOMClass and that interfered with entering any UOMClass.

I made an Updatable baq to set the RFQitems UOMClass to get around the issue.

You could use the SearchAllTables stored procedure that was on the YahooGroup to see where that part number exists.

Greg

Thanks, I have been thinking there is an odd record that is making E10 choke.

FYI… I added a temp workaround until I can find the root cause

In the existing form customization in AfterAdapter Case GetNewPart

  • set the PartNum = “xxx”
  • change my UOMClassID and UOMClassIDDescription
  • set the part number = “”

goofy but seems to work for now.

Hello @bordway the temp workaround you posted is what you use to deal with the error? I’m trying to create parts on the fly for Sales Order and Job Materials but got a similar error.

Thanks

It’s been a while but if I remember correctly it was parts on the fly too.
An extra constraint was that I was updating an existing form customization.
New parts created while using this form needed to default to a specific UOMClass but… business logic required a part number before the UOMClass could be assigned.
So I just “tricked” the method by assigning a dummy number, then the UOMClass and then resetting the number to “”.
May or may not apply in your case.

1 Like

You can select a default in UOM Class Maintenance.
“System Default” on the UOM Class, and “Default UOM” (for that Class), on the UOMs tab.

image

image

Normally I’d probably do that too.
In this case I think it ended up like this because of the way the existing customization was limited to a subset of parts. Other parts still used the default UOMClass.

1 Like

Thank you @bordway I’m going to try or adjust what you suggested.