Finance tab: Rules

AccountingIntegrator Enabler Rules

Rule versions and validity periods

Rule versions and activation dates

AccountingIntegrator Enabler Rules

All processing relating to an Input-Event is defined in the Composer Rule objects.

Use the following table as a quick reference to the Rule topic and related objects that you need.


Refer to

For details about how to


Group into a single segment a set of multiple segments which have the same structure, that is, they reference the same Business-Document.


Track and trace data processed by AccountingIntegrator Enabler  Rule Engine at any given stage in the transformation cycle.


Check that the accounting entries, that is, the Output-Events generated balance based on certain selection criteria.


Modify, enrich and validate the data in an Input-Event segment.


Define the processing which AccountingIntegrator Enabler applies to transform Input-Events into Output-Events via Financial-Cases.

Rule versions and validity periods

You can create several versions of a single Rule object by duplicating the object and setting each duplicated copy a distinct validity period and version number.

Creating a Rule version

You can create a maximum of 999 versions of a given Rule.[FOR DETAILS: AccountingIntegrator Enabler limits]

To create a new version:

  1. Right-click the Rule that you want to duplicate and select Copy from the contextual menu.
  2. Paste the copied Rule in the Rule node on the Dictionary tab.

Composer creates an exact copy of the selected Rule and assigns it the name of the original Rule suffixed with the word Copy.

  1. Open the copied Rule and modify the following fields:
Field Modification


Remove the word Copy.

Validity period

Change the Start and End dates as required


Increment the version number. The maximum value you can enter in this field is 999.

  1. Click Apply or Close.

Composer updates the list of Rules and displays the duplicated Rule with the new version number you assigned.

Creating a Rule validity period

A Rule possesses one validity period which comprises a start and end date, where the start date is always equal to, or earlier than the end date. You set these dates on the General tab of the Rule object.

By default, AccountingIntegrator Enabler assigns the current date as the start date and 31/12/2099 as the end date.

The lifespan of a Rule thus begins at the start date of its first validity period (which must be later than or equal to 01/01/1900) and ends at the end date of its last validity period (which must be earlier than or equal to 31/12/2099). The validity periods define the time span during which you can apply a given version of the Rule. The Rule validity period can:

  • Be a single day, when you specify the same date for the start and end date parameters
  • Overlap the validity period of another version, but not identical

Overlapping validity periods

When validity periods in the same Rule overlap, the version that takes precedence is the one whose start date is closest to the DAR defined in the Processing-Context-In.

If, during execution, AccountingIntegrator Enabler does not find a Rule version, it rejects the Input-Event.

Remember that during execution, the Input-Event version also has an impact on the Rules AccountingIntegrator Enabler selects. [FOR DETAILS: Input-Event versions]

Managing Rule versions

When you create or modify a Rule version, AccountingIntegrator Enabler automatically modifies the Input-Event(s) that reference it. This approach ensures greater data integrity during processing due to the following:

  • Enables you to identify the impact on an Input-Event or Processing-Context-Out object.
  • Prevents you from removing a Rule from Production or updating it, without also removing or updating the Input-Events or Processing-Context-Out objects that the Rule impacts.

Managing Rule versions in Input-Events

There are significant differences in how AccountingIntegrator Enabler and RDJ manage Rule versions in Input-Events. When you select a Rule (and by implication, the versions of the selected Rule) AccountingIntegrator Enabler and RDJ handle the processing differently, as explained in the following table.

To ... RDJ ... AccountingIntegrator Enabler requires that...

Check the Input-Event

Requires that at least one version of the Rule exists with the status Checked.


When you modify a Rule, all versions of that Rule must have the status ToBeChecked before the status of the Input-Event that uses it can change to ToBeChecked.

Requires that all versions of the Rule have the status Checked.


When you modify a Rule, the system automatically modifies the Input-Event.

Attach a Rule to an Input-Event

Attaches all versions of the Rule

Attaches only the Rule versions whose validity period overlaps that of the Input-Event by at least one day.

Managing Rule versions on Processing-Context-Outs

To attach a Rule to a Processing-Context-Out, AccountingIntegrator Enabler attaches all versions of that Rule. This approach constrains AccountingIntegrator Enabler to create a new version of Rules which are already in Production. This requires that the system first makes the Input-Events that reference the Rule modifiable via either of the following methods:

  • Create a new Release
  • Run a Back to Design operation on the Input-Events concerned

Rule versions and activation dates

An AccountingIntegrator Enabler Rule can be in Production on a Server and not be active. Until version V1.3, the validity period of the Rule was used to determine when to activate the Rule on all Servers. From now on, you can define a specific activation date for each Server where the Rule can be broadcasted.

Example: You have many Servers and want to deploy the Rules (R1, R2, and so on) on the Servers at different times. You can plan the activation dates as follows: Rule R2 should be sent on the Server New York on 01/08/2006, on the Server Hong-Kong on 01/09/2006, and so on.

[FOR DETAILS: Activation dates tab]

Back to top

Related Links