Question

Object Reference Error When Receiving Subcontract PO

mwilson
Userlevel 4

10.2.700

 

This error…

Object reference not set to an instance of an object

… is appearing when we try to receive against a subcontract PO line.  Any ideas?  We opened a case with Epicor already.

 

Thanks

...Monty.

..Monty. Monty Wilson, Vice-President North America, Epicor Users Group

10 replies

S
Userlevel 4

Hi Monty

Can you expand the error and post the full details - looks like a bpm/customization would throw an error like this and the details may give us a clue as to where to look

mwilson
Userlevel 4

@sue.lowden 

 

Thanks!  Detail is below.

 

Error Detail

============

Correlation ID: 5d615cbb-a083-4d84-80e6-cb8f336d0748

Message: Object reference not set to an instance of an object.

Program: Epicor.ServiceModel.dll

Method: ShouldRethrowNonRetryableException

Client Stack Trace

==================

at Epicor.ServiceModel.Channels.ImplBase`1.ShouldRethrowNonRetryableException(Exception ex, DataSet[] dataSets)

at Erp.Proxy.BO.ReceiptImpl.SetToLocation(Int32 vendorNum, String purPoint, String packSlip, Int32 packLine, ReceiptDataSet ds)

at Erp.Adapters.ReceiptAdapter.SetToLocation(Int32 vendorNum, String purPoint, String packSlip, Int32 packLine)

..Monty. Monty Wilson, Vice-President North America, Epicor Users Group
mwilson
Userlevel 4

If we just try to create the receipt line and save it, without even receiving, we get this error message as soon as Save is clicked.  We have eliminated BPMs and run in Base Only.

 

Application Error

Exception caught in: Epicor.ServiceModel

Error Detail 
============
Correlation ID: 622458c9-2ea1-4c38-b570-379dc2fa59b5
Message: Object reference not set to an instance of an object.
Program: Epicor.ServiceModel.dll
Method: ShouldRethrowNonRetryableException

Client Stack Trace 
==================
   at Epicor.ServiceModel.Channels.ImplBase`1.ShouldRethrowNonRetryableException(Exception ex, DataSet[] dataSets)
   at Erp.Proxy.BO.ReceiptImpl.DisplayWarnMsg(String PartTranType, String JobNum, Int32 AsmSeq, Int32 JobSeq, String& pcMsg)
   at Erp.Adapters.ReceiptAdapter.DisplayWarnMsg(String partTranType, String jobNum, Int32 asmSeq, Int32 jobSeq, String& pcMessage)

..Monty. Monty Wilson, Vice-President North America, Epicor Users Group
D
Userlevel 1

That is undoubtedly the least helpful error message in all of Epicor. We most often see this when something has happened out of order or in a way that it should not. For example the PO release was deleted even though it was linked. 

Our work around would most likely be to unlink the PO Line link to a new PO and receive then void the old PO Line. It does not solve the underlying problem. It depends how much time you can invest.

mwilson
Userlevel 4

Thanks @doug.harvey !  We tried that, and the replacement PO failed in the same way.  Something has gone wrong with the jobs involved, and we’re scratching our heads on what it could be.  Please share any further ideas.

 

Best,

…….Monty.

..Monty. Monty Wilson, Vice-President North America, Epicor Users Group
mwilson
Userlevel 4

With our own expert and with Epicor Support in a live session today, we discovered that the jobs causing the subcontract PO releases to fail to receive, have an operation added immediately after the subcontract operation.  In our test environment, the jobs were created, the POs were created, but the additional operation was not yet added to the jobs, and they receive normally.

 

Our purchasing manager was able to receive in our live environment, after the added operation was deleted from the job.

 

Epicor is now investigating what causes this issue to happen, and meanwhile we have our workaround.

 

Thanks Everyone!

…….Monty.

..Monty. Monty Wilson, Vice-President North America, Epicor Users Group
D
Userlevel 1

That is an odd one. I’m curious to hear what Epicor says.

mwilson
Userlevel 4

Nothing yet from them.  At yesterday’s regional Texas EUG meeting, I found someone who had found this issue.  Their workaround is to insert after every subcontract operation, a Receive-Subcontract operation, in the manufacturing methods.  She said it would work as auto-clock (backflush operation) although they don’t do that.

 

By inserting any subsequent job operation after the Receive-Subcontract op, one can avoid the issue described.  It works for them but I’d rather find the root cause solution if possible.

..Monty. Monty Wilson, Vice-President North America, Epicor Users Group
mwilson
Userlevel 4

Now our purchasing and planning manager reports that the root cause was that the job operation that was added, was created as a subcontract operation, but an in-house op code was used for it.  I didn’t know Epicor would allow that.  When we attempted to re-create the error in Test, we were unable to do so.  When we added the job operation as subcontract but with an in-house operation, then attempted to receive against the original subcontract operation, the receive was successful when we expected it to error-out.  Still scratching our heads.

..Monty. Monty Wilson, Vice-President North America, Epicor Users Group
D
Userlevel 1

That makes sense. It has always struck me as a bad design that Epicor allows me to select add new subcontract operation and then add a non-subcontract operation to that and vice versa.

Reply


Terms & Conditions