Scheduling - Nullable object must have a value

Anyone know what could cause this error? We can’t schedule any jobs suddenly -

I’ve received some random errors like this.
If possible, I might start with recycle app pools, reset IIS or worst case reboot.
Just to rule out any bad sessions.

Hi Patty,

We’ve seen this on 10.0.700.4. I wrote a BAQ that searches for jobs with scheduled end dates and no start dates. I then try to schedule them in job entry and eventually a few will throw that nullable error. When it does, I remove the schedule then reschedule and am able to run an MRP with a good schedule.

Mark Wonsil
Perceptron, Inc.

1 Like

Took a bit but we found it. First op was missing the Scheduling Relation (Finish to Start, etc…). I wish the error could be more specific about what field it found with the MISSING data. Thanks Mark - you pointed me in the right direction.

1 Like

Just curious if you couldn’t schedule any jobs from job entry?
Or if this was just a problem with global scheduling?

This happened to us as well. It was the Scheduling Relation that was missing. Glad you were able to find the issue!

either way

Interesting
So sounds like even one null JobOper.SchedRelation would result in failure for any attempt to schedule.
I guess that makes sense but…now I’m wondering how ScheduleRelation could end up “” or null?
Possible with DMT?
Or maybe an failed/interrupted record update?

We are receiving a similar issue despite all our Dates and Columns being populated.

Application Error

Exception caught in: Erp.Adapters.ScheduleEngine

Error Detail 
============
Message: Nullable object must have a value.
Program: Erp.Adapters.ScheduleEngine.dll
Method: MoveJobItem

Client Stack Trace 
==================
   at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
   at Erp.Internal.ES.SchedEngine.MoveJobItem(String ttScheduleEngineCompany, String ttScheduleEngineJobNum, Int32 ttScheduleEngineAssemblySeq, Int32 ttScheduleEngineOprSeq, Int32 ttScheduleEngineOpDtlSeq, Nullable`1 ttScheduleEngineStartDate, Int32 ttScheduleEngineStartTime, Nullable`1 ttScheduleEngineEndDate, Int32 ttScheduleEngineEndTime, Boolean ttScheduleEngineWhatIf, Boolean ttScheduleEngineFinite, String ttScheduleEngineSchedTypeCode, Boolean ttScheduleEngineOverrideMtlCon, Int32 OverRideHistDateSetting, Boolean ttScheduleEngineScheduleDir, Boolean il_surpressexceptions, Int32 ttScheduleEngineAllocNum, String& WarnLogTxt, Boolean ttScheduleEngineMinimizeWIP, Nullable`1 ipOverrideBounceDate) in C:\_Releases\ERP\UD10.1.500.18\Source\Server\Internal\ES\SchedEngine\SchedEngine.cs:line 15505
   at Erp.Internal.ES.SchedEngine.doMultiSchedule(ScheduleEngineRow ScheduleEngine, Boolean scheduleDirection, Nullable`1 ipDate, Int32 ipTime, List`1 ipSchedItemRows, Boolean ipDoingPartial) in C:\_Releases\ERP\UD10.1.500.18\Source\Server\Internal\ES\SchedEngine\SchedEngine.cs:line 14860
   at Erp.Internal.ES.SchedEngine.moveMultiJobItem(ScheduleEngineRow ttScheduleEngine, List`1 ipSchedItemRows, List`1 ipSchedRelItemRows) in C:\_Releases\ERP\UD10.1.500.18\Source\Server\Internal\ES\SchedEngine\SchedEngine.cs:line 15331
   at Erp.Internal.ES.SchedEngine.MoveItem(ScheduleEngineRow ttScheduleEngine, String& opWarnLogTxt) in C:\_Releases\ERP\UD10.1.500.18\Source\Server\Internal\ES\SchedEngine\SchedEngine.cs:line 14543
   at Erp.Services.BO.ScheduleEngineSvc.MoveJobItem(ScheduleEngineTableset ds, Boolean& l_finished, String& c_WarnLogTxt) in C:\_Releases\ERP\UD10.1.500.18\Source\Server\Services\BO\ScheduleEngine\ScheduleEngine.cs:line 2905
   at Erp.Services.BO.ScheduleEngineSvcFacade.MoveJobItem(ScheduleEngineTableset ds, Boolean& l_finished, String& c_WarnLogTxt) in C:\_Releases\ERP\UD10.1.500.18\Source\Server\Services\BO\ScheduleEngine\ScheduleEngineSvcFacade.cs:line 281
   at SyncInvokeMoveJobItem(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   at Epicor.Hosting.OperationBoundInvoker.InnerInvoke(Object instance, Func`2 func) in C:\_Releases\ICE\3.1.500.18\Source\Framework\Epicor.System\Hosting\OperationBoundInvoker.cs:line 59
   at Epicor.Hosting.OperationBoundInvoker.Invoke(Object instance, Func`2 func) in C:\_Releases\ICE\3.1.500.18\Source\Framework\Epicor.System\Hosting\OperationBoundInvoker.cs:line 47
   at Epicor.Hosting.Wcf.EpiOperationInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs) in C:\_Releases\ICE\3.1.500.18\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 Erp.Adapters.ScheduleEngineAdapter.MoveJobItem(Boolean& l_finished, String& c_WarnLogTxt)
   at Erp.UI.App.JobEntry.Transaction.scheduleJob()
1 Like

@hasokeric did you ever find out what it was that was causing this error?

For us it was bad data so we re-ran that Process that re-calculated the Scheduling values, can’t remember what its called now maybe PO Suggestions. It fixed the bad data from either a failed MRP Run or something else.

No - still happens randomly. When it does it removes all our scheduled resources and we can’t get the job rescheduled. Job just disappears off schedules and even if we remove and reschedule - no way to get it back on. It happens more frequently when someone reschedules a job while an operation may be logged into it.

What is happening to us is that it is suggesting a start hour of -0.06 which is not a real hour. We see this in the job scheduling log.

1 Like

We had an issue like this back in 10.2.200.3 during upgrade testing. I created an Epicor Case(CS0000949039) for it.

This is how I explained it to support:
Create a Job with two operations:

Opr 10: Start-To-Start, Labor Reporting Resource for Production: OprDtl 20, Labor Reporting Resource for Setup: OprDtl 20
-OprDtl 10: Labor Resource Group Marked with “Use Calendar for Queue Time”
-OprDtl 20: Location Resource Group Marked with “Use Calendar for Queue Time”

Opr 20: Finish-To-Start, Labor Reporting Resource for Production: OprDtl 20, Labor Reporting Resource for Setup: OprDtl 30
-OprDtl 10: Labor Resource Group Marked with “Use Calendar for Queue Time”
-OprDtl 20: Production Location Resource Group Marked with “Use Calendar for Queue Time”
–Marked for Production in “Required For” on Scheduling Resource Detail
-OprDtl 30: Setup Location Resource Group Marked with “Use Calendar for Queue Time”
–Marked for Setup in “Required For” on Scheduling Resource Detail

Backward Schedule from Current Date or Forward Schedule with any Date will throw the exception.

For us it was caused where on a Operation the Primary Labor Resource Group for Setup is different than the Primary Labor Resource Group for Production and using the “Use Calendar for Queue Time” on the Resource Group.

image
image

Unchecking all the “Use Calendar for Queue Time” on the resources was a workaround.

The ticket was closed with SCR ERPS-88458 and fixed at patch level 10.2.200.7.

Ran into this Error while Scheduling a Job in 10.2.200.10.
Was advised by Support to upgrade to at least 10.2.200.19 for the latest fix for this type of error.
In this case the scheduling process was getting hung up with the following final log:
“Scheduled start time for resource QC for and a start hour of -0.31 — GetBackwardDateTime”
Found that the related operation had a Hrs/pc of 0.01 and Support advised changing that to at least 1.00.
Made the change and the job scheduled without an error.

We also got the nullable object error, having random failures to schedule on jobs with Hours / Piece with the prod std out to a bunch of decimal places. I just had to round them up to 2 decimal places. Weird thing is it only happened on some methods with certain multiples. So a qty of 25 on the job might be fine but 80 could fail. Some strange math error. We were on 10.2.300.5 and since we upgraded to 10.2.300.16 the problem has resolved itself. I believe in testing this issue was fixed as of 10.2.300.12