Skip to main content

Currently for our users to transfer parts to our mobile devices, they have to create a request, fill in the part needs, print picks, ship it etc. Then the tech will receive it on his screen under the receiving tab. this is a lengthy process for our shippers, especially in the summer.

Logistics manager lets the user transfer a part in only a few clicks. takes 20 seconds to do. However the part wont immediately show up in the mobile users stock. They have to initialize before the data come into their phone

We’re on v5.7. Is this a version issue or is there a way around this?

This is the expected behavior as the Stock tables and Part table are not synced real time in FSM sync rules (except for part usages and part needs are synced real time). They are synced in "batch all" and "batch delta". Hence why you need to initialize.

It is not recommended to keep part and stock tables on real time sync as they contain large set of data, and non-time critical data. Also, since they need to be sent to many or all devices not just a specific user at a time.Therefore, you could check to see the "Frequency" of the Sync rule. That frequency is the period that the sync rule executes and try to change it to more frequently executed.

This is the expected behavior as the Stock tables and Part table are not synced real time in FSM sync rules (except for part usages and part needs are synced real time). They are synced in "batch all" and "batch delta". Hence why you need to initialize.

It is not recommended to keep part and stock tables on real time sync as they contain large set of data, and non-time critical data. Also, since they need to be sent to many or all devices not just a specific user at a time.Therefore, you could check to see the "Frequency" of the Sync rule. That frequency is the period that the sync rule executes and try to change it to more frequently executed.

Thank you SO MUCH! This is what i figured based on how it works but i needed to have it confirmed by IFS. I greatly appreciate this. 

This is the expected behavior as the Stock tables and Part table are not synced real time in FSM sync rules (except for part usages and part needs are synced real time). They are synced in "batch all" and "batch delta". Hence why you need to initialize.

It is not recommended to keep part and stock tables on real time sync as they contain large set of data, and non-time critical data. Also, since they need to be sent to many or all devices not just a specific user at a time.Therefore, you could check to see the "Frequency" of the Sync rule. That frequency is the period that the sync rule executes and try to change it to more frequently executed.

Hi, i wanted to follow up on the frequency of the sync rule question.The sync rule frequency is 24. assuming thats 24 hours? that means that every 24 hours it automatically syncs the new data? is there a downside to have that sync frequency any shorter? 

@DHPALK my sync is set to 24 but the last run was in november of 2019. Is there a reason its not running?

 

 

This is the expected behavior as the Stock tables and Part table are not synced real time in FSM sync rules (except for part usages and part needs are synced real time). They are synced in "batch all" and "batch delta". Hence why you need to initialize.

It is not recommended to keep part and stock tables on real time sync as they contain large set of data, and non-time critical data. Also, since they need to be sent to many or all devices not just a specific user at a time.Therefore, you could check to see the "Frequency" of the Sync rule. That frequency is the period that the sync rule executes and try to change it to more frequently executed.

Hi, i wanted to follow up on the frequency of the sync rule question.The sync rule frequency is 24. assuming thats 24 hours? that means that every 24 hours it automatically syncs the new data? is there a downside to have that sync frequency any shorter? 

Yes. The frequency is mentioned in hours. Having this frequency set to a lower value will not affect greatly for batch delta syncing. Since then only the changes to the table since the last sync are sen to the device. But for batch all it could have an effect since regardless of the changes, the full table is sent to the device. This could result in data trafficking and lower performance and hit sync issues if the amount of data is huge. However, we cannot provide a recommended value as it depends on your business and data.

If your replication has not worked properly, you could do following,

  1. first check in Metrix run log > run type = mobile replication to see if a replication has been executed. If not, do a manual sync and observe if the syncing happens as expected after that. Because the replications happen by monitoring the past run logs. If for any reason the syncing got stopped it will not be restarted if a recent replication does not exist.
  2. Also, in FSM 6 you have the option to analyze your sync rule to see for any improvement actions. Sync rule screen > analyze.
  3. If above doesn’t work, you might need to do some technical analysis. You could also first check to see if the message queuing is installed properly with read write access. If that is also installed properly please request for further investigation.

  4. However, I can see your issue is with a batch delta sync rule. In batch delta, if there are no changes to be synced the replication will not happen. Because it only select rows whose MODIFIED_DTTM => last run time. In your scenario, this could also be a case. Hence, another suggestion is to add some new data in to that table and see if you still have the issue.

Reply


Terms & ConditionsCookie settings