Tagging #IFSACH #ACHTECH
CC: @Yasas Kasthuriarachchi
I am also getting a same issue for another customer.
could you please some one from RnD answer this question.
Hi @Kalpani Dissanayake/ @Subash Perera
Any inputs on above query and comment?
Thanks & Best Regards,
Yasas
Hi @jbernardo ,
When executing the perform_replication_for_tables MPM with an invalid mobile user in the person_id parameter, the noted error is added to the Mobile Error Log. This happens if the person_id value is not valid, if a valid person has mobile_user = N, or if a valid person with mobile_user = Y, but the person has no activated mobile device.
Hope this answer helps
Best Regards,
Atheeq
Hi @jbernardo ,
When executing the perform_replication_for_tables MPM with an invalid mobile user in the person_id parameter, the noted error is added to the Mobile Error Log. This happens if the person_id value is not valid, if a valid person has mobile_user = N, or if a valid person with mobile_user = Y, but the person has no activated mobile device.
Hope this answer helps
Best Regards,
Atheeq
Thanks - i get that part of it but what i dont get is why this process requires a mobile license? the user doing this is someone in the warehouse doing some sort of shipment or receiving processing. this is one example - there are more with different messages but the error description is the same
This issue was investigated by R&D and their initial analysis yielded the following:
“There could be several causes of the reported behavior. The key is to identify the specific activity that resulted in the error being created.
“One likely suspect would be the SHIPMENT sync rule. The baseline configuration has an extension that executes <perform_replication_for_tables> for STOCK_BIN and STOCK_SERIAL_ID every time a shipment record is updated and INVENTORY_ADJUSTED = 'Y'. This will happen for every shipment record even if the shipments have nothing to do with mobile users. The ownership query uses shipment_ownership_view to determine which users to send messages to.
“The purpose of the Extension on the SHIPMENT sync rule is to refresh mobile users' inventory after anyone has posted a shipment where the shipment.person_id_shipping is the mobile user. The default configuration is wide open and results in these error messages for shipments where the Shipping Person does not have a mobile device. There is no harm beyond the extra noise in Mobile Error Log.
“This can be resolved through configuration. However, the method will depend on how the customer is using the mobile solution. If replications are not needed when shipments post, simply remove the Extension from the Sync Rule. If that functionality is desired, then changes will need to be made to the sync rule's ownership query. Perhaps a custom view to replace the baseline shipment_ownership_view would be in order.
“Of course, this might not be the cause of the customer's error messages. That will have to be verified by investigating their environment.”
Further investigation by R&D has now resulted in the following feedback:
“IFS R&D have completed investigation of this issue and have determined that the error message provides no benefit. It is simply notice that data was not replicated because the user was not a valid user. The system resources consumed before the error is logged are minimal. Therefore, this issue has been accepted as a standard software fault and this particular error will no longer be logged in the Mobile Error Log. We plan on delivering this change in FSM 6 Update 13 currently scheduled for release at the end of September.”
We recommend you ensure only Persons who interact with FSM through the mobile solution are flagged as mobile_user = Y. See App Param named MOBILE_USER_LICENSE_TYPES.
@jbernardo, @Yasas Kasthuriarachchi, @Kajendran Chandreswaran, @Atheeq Maharoof, @Ann Degroat
This issue was investigated by R&D and their initial analysis yielded the following:
“There could be several causes of the reported behavior. The key is to identify the specific activity that resulted in the error being created.
“One likely suspect would be the SHIPMENT sync rule. The baseline configuration has an extension that executes <perform_replication_for_tables> for STOCK_BIN and STOCK_SERIAL_ID every time a shipment record is updated and INVENTORY_ADJUSTED = 'Y'. This will happen for every shipment record even if the shipments have nothing to do with mobile users. The ownership query uses shipment_ownership_view to determine which users to send messages to.
“The purpose of the Extension on the SHIPMENT sync rule is to refresh mobile users' inventory after anyone has posted a shipment where the shipment.person_id_shipping is the mobile user. The default configuration is wide open and results in these error messages for shipments where the Shipping Person does not have a mobile device. There is no harm beyond the extra noise in Mobile Error Log.
“This can be resolved through configuration. However, the method will depend on how the customer is using the mobile solution. If replications are not needed when shipments post, simply remove the Extension from the Sync Rule. If that functionality is desired, then changes will need to be made to the sync rule's ownership query. Perhaps a custom view to replace the baseline shipment_ownership_view would be in order.
“Of course, this might not be the cause of the customer's error messages. That will have to be verified by investigating their environment.”
Further investigation by R&D has now resulted in the following feedback:
“IFS R&D have completed investigation of this issue and have determined that the error message provides no benefit. It is simply notice that data was not replicated because the user was not a valid user. The system resources consumed before the error is logged are minimal. Therefore, this issue has been accepted as a standard software fault and this particular error will no longer be logged in the Mobile Error Log. We plan on delivering this change in FSM 6 Update 13 currently scheduled for release at the end of September.”
We recommend you ensure only Persons who interact with FSM through the mobile solution are flagged as mobile_user = Y. See App Param named MOBILE_USER_LICENSE_TYPES.
@Kalpani Dissanayake, @Subash Perera
For my case that I mentioned, IFS R&D have completed investigation of this issue and have determined that the error message provides no benefit. It is simply notice that data was not replicated because the user was not a valid user. The system resources consumed before the error is logged are minimal. Therefore, this issue has been accepted as a standard software fault and this particular error will no longer be logged in the Mobile Error Log. We plan on delivering this change in FSM 6 Update 13 currently scheduled for release at the end of September.
