Skip to main content

Failed transaction handling is big trouble in practical scenarios. Work order transferred to mobile is accepted by the mobile user but later it is taken back or put up in the prepared status in IFS for reassignment or replaning. IN SUCH SCENARIOS, Group messages will fail and handling of these messages becoming big hurdle. How these can be properally handled. Specially, I  such scenarios where WO no is showing g different WO no like - 50004 etc. 

Hi, You will see negative wo no for the work orders created in the mobile. Real wo_no assigned in the server side. But you can see a field called ‘originating system id’. eg. N2345678. You can find that in prepare work order → General tab.

I assume this is App9. In the scenario you explained, are you unassign wo before doing the change? Unassigned will send push delete message to the device. So mobile user won’t able to do futher changes to that work order, which will end up as FTs. 


I have experienced some of the different scenarios where inconsistency observerd.

Case1: WO is assigned to the mobile user by the IFS PSO and sent to the Mobile user by the Event. He accepted the WO but that message took little bit time and in between this work order is taken back (Changes status from Assigned to Prepared) in IFS. Now message carrying or coming back to IFS to update the status from Assigned to Accepted is getting failed, As Work order is already move to Prepared. As mobile user also accepted and started WO, Even some cases, He had already reported the Time transactions are also coming back to IFS and getting failed.


I think this is a possible use case in an offline solution. Offline clients could send outdated transactions to the server because field users can perform tasks while the device is offline.  When device is online (has a connection to the server), it first send all pending messages in the offline queue to the server and then downloads any pending messaged from the server out queue. This means any operations device do while offline will first reach the server and then the client consumes the out messages in the server. So there is a chance to trigger such failed transactions in the real offline environment.  So, those types of failed transaction can be classified as known errors and can be  ignored where admin can set up the rule in the IEE to move such FT to ignored queue. Will that solve the issue?

 

Also failed transaction in the queue does not prevent field user to continue their work. Server only queue transactions related to that failed work order.


This is really helpful ! 

How it can be configured in IEE for such messages to move automatically in ignored queue. 

Thanks! 


Hi

Please see F1 Technical Documentations for Ignored Error Types. Hope this helps. 

Apps9: https://wit.ifsworld.com/f1docs/apps9/Foundation1/040_administration/415_touch_apps/020_configuration/020_ignored_error_types/default.htm

Apps10: https://docs.ifs.com/techdocs/Foundation1/040_administration/415_touch_apps/020_configuration/020_ignored_error_types/default.htm

 

*Admin note: Replaced wit link with docs link. (April 2020)


Hi, I’m seeing many failed transactions for FND_LOCKED. We have the job running to resend these transactions every 5 mins, so can I safely set this transaction to be ignored ? We notify the back office via email of any failed transactions and I would prefer to remove any uneccessary emails, thanks


Reply