Hi,
In Apps10 UPD17, R&D has identified one scenario a failed transaction can happen related to task dates and the issue has been fixed. 
However, this error seems to be related Work Order Start Date which is set from back office based on the task start date/s. It looks like this scenario needs further investigations. The best thing would be to report an issue with the test plan.

Regards,
Uthpala

Hi @Uthpala , Tks for the info.

@Bandula , @James Ashmore , @skullk 

I was looking in client log and trace, and found something like:

E    26/02/2023 19:50:20    Wrong data type in parameter WorkStart passed to CustomStartWork
E    26/02/2023 19:50:20    Wrong data type in parameter AssignmentStart passed to CustomStartWork
I    26/02/2023 19:50:20    FISRT
I    26/02/2023 19:50:20    SyncStarted

T    26/02/2023 19:50:20    Procedures: Action<JtExecutionInstance.CustomStartWork> 205ms

Trace:

<PLSQLSTMT>
DECLARE task_seq_ NUMBER := :1 ; execution_instance_seq_ NUMBER := :2 ; work_start_ DATE := :3 ; assignment_start_ DATE := :4 ; BEGIN Maint_Eng_App_SVC.Do_Custom_Start_Work(task_seq_, execution_instance_seq_, work_start_, assignment_start_, jt_execution_instance## => 'DUMMY'); SELECT objid, objversion INTO :5 , :6  FROM IFSPET.JT_EXECUTION_INSTANCE WHERE task_seq=task_seq_ AND execution_instance_seq=execution_instance_seq_; EXCEPTION WHEN NO_DATA_FOUND THEN NULL; END;
</PLSQLSTMT>

I haven’t seen this before.

Anyway, I already reaised a case to support. hope get the solution soon. G2367487

If you guys found out about it, please let me know.

Tks

Hi @Uthpala , I’ve just removed the custom fields from the mobile_work_order logical unit and now it’s OK.

I think this has happened because we updated from 14 to 17.

Tks a lot.

Br.

Lopes