Once the Dependency Manager has captured one or more precedent change items and grouped them into a precedent change set, then the Dependency Manager can identify which dependents are potentially affected by one or more of the precedent change items, by examining the stored dependency records for each precedent in the precedent change set. It is at this point that the Dependency Manager filters out any dependents which are identified more than once.
This identification of the potentially affected dependents occurs either in deferred processing or in batch processing, depending on the mode in effect when the precedent change items were captured (see Capture of Precedent Change Items).
For example, if a single database transaction writes changes to several database rows, then the deferred processing step will identify each affected case only once, even though each changed database row on its own affects a particular case.
Similarly, if the batch precedent change set contains changes to both CER rule sets and rates, then the batch processing step will again identify each affected case only once, even though the CER rule set change on its own affects a particular case, as does the rate change on its own, too.