Suggestions to speed up the loop resolution

When you make some changes to the operation definitions, to identify possible loops, run daily planning trials. In this way, there will be smaller networks to analyze and fewer messages to check, if a loop condition is detected.

When a loop is detected, ensure that you promptly modify the application definitions to prevent the network from generating the same loop condition again.

The messages generated by the loop analysis process in the EQQLOOP data set are not intended as the only possible way to resolve the loop. They are only a suggestion path to solve the loop; you can adopt it or not, according to your application definitions requirements. For example, consider a network with three operations involved in a loop, all of them having the same Input Arrival (IA) date and time. Suppose the following dependencies link the operations:
  • Operation A is predecessor of operation B
  • Operation B is predecessor of operation C
  • Operation C is predecessor of operation A

The batch daily planning detects a loop condition (A, B, C) and suggests a path to solve it by removing one of the dependencies. The removed dependency is not necessarily the bad dependency, because the IA date and time is the same for all the operations. In this case, no IA TIME CHECK condition occurs. If the network has one or more FOPs, the matrix reduction sets the closest operation to the loop entry and the removed dependency follows this criteria. If the network has no FOPs, the CLOSEST TO LOOP ENTRY condition does not occur; the MINIMAL NET DISTORTION will determine the dependency to be removed.

When applicable, avoid using the same IA date and time for the operations in the network. Setting the IA date and time according to the dependencies makes it easier for the loop analysis process to identify bad dependencies.