Counter Sales broke after 10.2.300.7 to .12 upgrade

After we upgraded from 10.2.300.7 to .12 a few weeks ago, our folks in the store noticed they could not process counter sales if “invoice” was selected.

In our PILOT testing environment, we’ve disabled bpms, ran Order Entry in base mode, and still get the following error after clicking “Process Counter Sale”. I have my test customer set to infinite credit, and they are off credit hold. After I click Refresh, the order shows as Shipped, Ready to invoice in Order Tracker.

What can I do next to narrow this down? Thanks for the help.

Error:


A server error occurred. Review the server event logs for details.

Exception caught in: Epicor.ServiceModel

Error Detail 
============
Description:  A server error occurred. Review the server event logs for details.
Program:  Epicor.System.dll
Method:  ProvideFault
Line Number:  32
Column Number:  13
Server Trace Stack:     at Epicor.Hosting.Wcf.ErrorHandler.ProvideFault(Exception error, MessageVersion version, Message& fault) in C:\_Releases\ICE\ICE3.2.300.12\Source\Framework\Epicor.System\Hosting\Wcf\ErrorHandler.cs:line 32
   at System.ServiceModel.Dispatcher.ErrorBehavior.ProvideFault(Exception e, FaultConverter faultConverter, ErrorHandlerFaultInfo& faultInfo)
   at System.ServiceModel.Dispatcher.ErrorBehavior.ProvideMessageFaultCore(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage8(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.ProcessError(Exception e)
   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.SecurityChannelListener`1.ReceiveItemAndVerifySecurityAsyncResult`2.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.SalesOrderImpl.ProcessCounterSale(Int32 iOrderNum, Boolean lGeneratePackingSlip, Boolean lGenerateInvoice, Boolean lReadyToShip, String cCreditShipAction, String& cPackNum, Int32& iInvoiceNum, String& opMessage, SalesOrderDataSet ds)
   at Erp.Adapters.SalesOrderAdapter.ProcessCounterSale(Int32 iOrderNum, Boolean lGeneratePackingSlip, Boolean lGenerateInvoice, Boolean lReadyToShip, String cCreditShipAction, String& cPackNum, Int32& iInvoiceNum, String& opMessage)```

It appears Epicor made an undocumented change between 10.2.300.7 and .12 where the Counter Sales AR Invoice Group Prefix has been reduced from x(4) to x(2) characters. We had ‘CNT-’ and changed it to ‘C-’, and counter sales now work.

Hopefully this helps someone else. Our EpiCare Analyst figured this out, and is making a KB article to help the support team as well.

Note - Field Help states 4 characters, the dot release upgrade process did not flag this during the conversion, and nothing was mentioned in the release notes pdf. The warning message didn’t help, and this wasted dozens of hours across 5 peoples time to troubleshoot and work around. I can say for sure that we’re not going to treat upgrading dot releases without doing full CRP testing again…

Epicor’s lack of testing and documentation on this .update change cost our company 48 man-hours in testing, meetings, and work arounds. This also impacted 150 customers that needed to be contacted again by A/R for credit card information.

2 Likes

Undocumented Changes are my favorite.

1 Like

Did they end up backing out the undocumented change? XaSyst.InvcGrpPfx still claims to be 4 characters in 2021.2.5.

Try setting a 4 digit prefix and doing a counter sale. If it doesn’t error, then they fixed it! :crazy_face:

Designing around observable behavior instead of documented behavior is always risky. Even if it appears to work, I’d feel safer knowing Epicor acknowledged that the change was a mistake. I can probably just convince everyone to just use a 2-character prefix…

You could submit a bug report to Epicor if it errors, and tell them to update the field to x(2) or fix the code. . Software will get better as we help them identify/fix errors (not that we have to, but it’s in our own best interest!).

Normally I’d agree, but it’s always hard to convince them that anything is wrong, and I feel like I need to pick my battles.

Maybe this conversation is all for naught and the bug was fixed 2 years ago.