Filtering on the comparison

Sometimes not all data existing in the systems should be compared. The reason might be that the comparison of some data is meaningless or that you would like to restrict the data to different organizational units.

An example for the first case would be if data has to be released before it is send to the target systems (e.g. service orders have to be released in a central customer care system before they are replicated to a maintenance systems). In this case an comparison of unreleased service orders would be useless as they exist by definition only in the source system. As this behaviour is build into the process it would not make sense to allow end users to change this filter but it should be build into your data model. To allow this type of filtering, model specific filters can be maintained which are valid for all comparisons using this model. 

An example of the second case could be required if multiple organizational units with different responsibles work in the same system. In this case it might be sensible to define comparisons for each responsible where the employee sees only the data he or she is responsible for. The actual data model for each responsible is identical but he should see only a subset of the data. To do this comparison specific filters can be defined as well.

Sometimes you would like to filter on values for multiple fields in the same comparison. In this case it is important that you provide a well-defined relation ship between the different filter values. An example could be that you would like to compare sales orders for certain sales organisations and distribution channel. If you would provide only the information you are interested in data for sales organization 1, sales organization 2, distribution channel A and distribution channel B the data selection would consider all possible combinations which are the value pairs (sales organization 1, distribution channel A), (sales organization 1, distribution channel B), (sales organization 2, distribution channel A), (sales organization 2, distribution channel B).

This might be okay for most cases but if you are only interested in the combinations (sales organization 1, distribution channel A), (sales organization 2, distribution channel B) you need to provide the relationship, which can be done via filter sets.

Types of Filters

Using relative date syntax

There are many use cases, where the comparison shall be time-dependent. For example, you only want to compare documents created yesterday, or during the last month. Entering static date filter values does not make sense here, because you would have to adapt the comparison filters before each run. To achieve a relative date filtering, which means calculating relative dates instead of absolute dates, CDC provides a special syntax on how define fix points and offsets for relative dates.

Syntax for Relative Dates

Instead of a fixed (absolute) date, you can enter a special keyword for the start date (prefixed by a $ character) and optionally an additional offset as difference in days.

Syntax = <StartDate>[<Difference>]

For <StartDate> the following keywords are available:

These additional keywords are meant for full timestamps only:

The optional <Difference> is entered as positive or negative offset (usually in days, unless otherwise noted)

• using '+' increments days (= move start date into the future)
• using '-' decrements days (= move start date into the past)

Examples:

• $TODAY-2 = day before yesterday
• $TODAY+2 = day after tomorrow

The relative date selection can be combined in ranges (using the LOW and HIGH fields of the selection criteria), e.g. to define "between" intervals.

Example: You want to filter the documents which have a creation date in last month. The selection criteria would be <FieldName> = $FDOPM to $LDOPM.