We recommend switching to the latest versions of Edge, Firefox, Chrome or Safari. Using Internet Explorer will result in a loss of website functionality.
Our Support systems migrated on Saturday, May 21. We'll automatically forward you to the new location for this content.

Articles in this section

See more

Common ACR/Summary And ACR/Detail Control Processing Issues

Avatar
Chenelle R
  • Updated
Follow

In this article I will provide solutions for problems that pertain to controls processing. This article contains the following topics: 

  • "Extending the Number of Internal Items"
  •  "Storing History for a Certain Number of Runs"
  •  "Matching Reconciliation Transactions from Two Input Sources"
  •  "Calculating Report Date Against Current Date"
  •  "Improvise a Calendar Feature"
  •  “Minimizing Transaction Processing Errors”

I. Extending the Number of Internal Items

ACR/Summary uses internal items to store control values extracted from a balancing job or control values that result from the manipulation of item values in a calculated item. For releases prior to 4.0, a job can have up to 100 internal items. Beginning with release 4.0, the system allows extended internal items, which can store lengthy extracted values. In addition to the 100 internal items, a job can have up to 100 extended internal items.

Here is a problem scenario:

You need to arrange more than the 100 internal items allowed by the system.

Your resolution is as follows:

Use Extended Internal Items
For releases 4.0 and above, a user can use extended internal items to hold smaller values as well as lengthy values. This increases the available number of internal items to 200.

Use Qualifiers
A qualifier represents multiple invocations of the same job/step combination or multiple processing of the same input file during a single balancing run. After the initial job/step runs, the system runs the qualifier or qualifiers. The addition of a qualifier can give you an additional set of internal items.

Example
If you add a qualifier of 01 to a job step called MYJOB/MYSTEP, you have two sets of rules in your definition database:

  • MYJOB MYSTEP
  • MYJOB MYSTEP 01

When you execute the job in batch mode, the system executes both the blank qualifier and the 01 qualifier. Thus, you have 100 internal items available for each set of rules. For more information about qualifiers, see the ACR/Summary User Guide.

Use ACR/Detail
You can use ACR/Detail to assign keys or to use static keys. For more information about using keys, see the ACR/Detail User Guide.

Assign Keys
Use this solution if you need more than 100 items in ACR/Summary to repeatedly extract a similar value for different areas. For example, you need to extract counts and amount total values for each company department. In ACR/Detail, each key has its own set of internal items. Therefore, each key can have its own unique count and amount total. You can use the different departments for the key fields, then extract the count and amount total one time for each key.

Use a Static Key
If you do not repeatedly extract a similar value for different areas, but you can extract with access mode 6 or 7, you can still use this solution in ACR/Detail. Set a key to a literal value and extract as you would in ACR/Summary. In ACR/Detail you can use up to 999 internal items for each reconciliation job.

II. Storing History for a Certain Number of Runs

In a suspense processing job, where you can match off items over time, it is important to build in a mechanism to age off histories. This can be implemented by date, either internal item date or cycle number, but there are times when it is important to match off items for a specified number of runs.

Here is a problem scenario:

You need to store history to use for matching for 30 runs. Due to weekends and holidays, 30 runs span more than 30 days.

Your resolutions are as follows:

Use the Suspense Aging Report to see the actual age of the history items, and then manipulate the items in ACR/TransMatch to obtain the desired data. Periodically run a job to delete history for items older than 30 days or whatever time frame you want.

Use the @DATE function to save the current date as an internal item for the original job. With each run, subtract the original date from the current date and delete the item if it is older than a certain number of  days, for example, if it is older than 30 days.

Create a run counter for a key, which allows you to use rules to delete or maintain history when normal history roll-off or roll-off by the number of days will not work.

Complete the following steps to set up a run counter and store history for 30 runs:

1. Set up an input source and when you initially extract a key, force a value of zero (0) into an internal item that is the count of days the item has been in history (I-001).

2. Create a calculated item that will be stored as the internal item that will add 1 to the original internal item that is the count of days the item had been in history (I-001 + 1).

3. Set up your history file as an input source.

4. Set up the rules to check the number of days and delete the key value if the value in the calculation equals 30, that is, the number of runs for which you want to store history.

III. Matching Reconciliation Transactions from Two Input Sources

In some instances of reconciliation processing, multiple transactions can have the same key combinations. For example, ATM transactions posted to your account may include the account number, ATM terminal number, and date as the key. Multiple transactions on the same day would have the same key and you want to make sure that each transaction posts individually. 

Typical ACR/Detail processing combines transactions with the same key. You want to verify that you have the correct number of transactions, so you do not want to combine the transactions when you match them to the general ledger.

Here is a problem scenario:

You need to match data between input sources where there are multiple occurrences of the same key data that needs to be matched individually.

Your resolution is as follows:

You need to write rules to determine if the key values are the same from one record to the next in each input file. If the key values are the same, increment a tally that starts with 1 to keep each occurrence separate. If the key values are different, reset the tally back to 1. This solution will match items in order of appearance, so if an item in the middle of a sequence is missing, all subsequent items will not match. This solution does not indicate which item is the actual item that did not match, but it narrows the field of mismatches and starts the errors with the missing item.

Putting Items in Order
This example starts numbering each key with a 1, so that transaction 1 for your ATM key on your first input source can be matched to transaction 1 for your ATM key on your second input source. To begin the numbers with 1 for each input source, the data in the input sources must have the keys sorted together. If the keys are not together in your input source, you will need to put them together on the file, so that each transaction within the keys can be numbered in sequential order, beginning with 1.

Complete the steps below to run an ACR/Detail job, for each input source, to put the keys in the correct order. If your keys are already together on your file, proceed to the "Matching the Items" section, below.

1. Add +1 to an extraction variable named MyInitialTallyEV.

2. Extract the ATM key fields and also use MyInitialTallyEV as a key. For this example, you need to extract the following key values:

  • Account Number
  • ATM Terminal Number
  • Date
  • MyInitialTallyEV


3. Extract your remaining record in internal or extended internal items, as needed, to maintain your input values.

For example:

Move pos 1 to 80 to X-001
Move pos 81 to 160 to X-002


4. Create a free-form output file that has your initial record value items as the outputs, such as X-001, and then X-002. See “Setting Up an Output File” in the ACR/Detail User Guide. The free-form output file will then replace your input source as the input to the actual reconciliation step. The transactions are the same as the original transactions, except that they are in order by the keys that you specified, Account Number, ATM Terminal Number, and Date.

Matching the Items
After you have determined that the items are in order, set up extraction definitions for selection groups in the following order: 


1. Set up the first selection group to see if values in extraction variables are equal to values of the key fields on the input source.


SELECT if pos 1 for 8 = MyLastAcctNumEV AND
SELECT if pos 9 for 8 = MyLastATMTermEV AND
SELECT if pos 18 for 8 = MyLastDateEV
Move literal of “MATCH” to MyEVIndicator
Add +1 to MyEVTally


If the values in the first selection group match, place a literal value of MATCH into an extraction variable, MyEVIndicator. This extraction variable is used to keep track of the match. Adding 1 to MyEVTally creates a unique key for transactions that would otherwise have the same key.

2. Set up the second selection group to see if values in extraction variables are not equal to values of the key fields on the input source.

SELECT if pos 1 for 8 NOT = MyLastAcctNumEV OR
SELECT if pos 9 for 8 NOT = MyLastATMTermEV OR
SELECT if pos 18 for 8 NOT = MyLastDateEV
Move literal of “NONMATCH” to MyEVIndicator
Move pos 1 for 8 to MyLastAcctNumEV
Move pos 9 for 8 to MyLastATMTermEV
Move pos 18 for 8 to MyLastDateEV
Move literal of +1 to MyEVTally

If the values in the first selection group do not match, place the key values into extraction variables and a literal value of NONMATCH into the extraction variable, MyEVIndicator. Moving 1 to MyEVTally creates a unique key and starts a new sequence for transactions that would otherwise have the same key. Identifying mismatches between input sources is easier because each key sequence starts at 1.

3. Set up a selection group to extract your data, using the MyEVTally item to pick up the keys and internal items.

SELECT if pos 1 for 3 = ATM

where ATM is your business selection criteria

Move MyLastAcctNumEV to Key1
Move MyLastATMTermEV to Key2
Move MyLastATMTermEV to Key3
Move MyEVTally to Key4
Move pos 32 for 15 into Internal Item 1

where 32 for 15 is the data that you need to extract and Internal Item 1 is the location where you want to place the extracted data.

IV. Calculating Report Date Against Current Date

Infogix ACR stores dates as a Date Count. Sometimes, a customer needs to check dates on an input source or a report to determine if the input data is current.

Here is a problem scenario:

You want to determine the number of days between a date on a report and the current system date. For example, you want to make sure that a record is less than one year old or that a posted transaction date is less than one day old.

Your resolution is as follows:

Infogix ACR stores both the current date and the report date as date counts. Follow the steps below to calculate the report date against the current date.

1. To obtain the report date, create a detail field to extract the report date, and specify the date format, such as MMDDYY, in an internal item defined as a date format. The target detail field must specify the field type and format and must contain the Last Date and the Last Date-Count Value. 

2. To obtain the current date, set up a calculated item and extract the date using the following equation:

+99999999 >(into) + @DATE


3. Create another calculated item to subtract the internal item report date from the calculated current date.

CURRENT DATE -REPORT DATE


4. Define a rule, formatted as a count, to analyze the calculated item with the difference in the number of days.

V. Improvise a Calendar Feature

A user may need to identify exceptions to normal processing. For example, suppose a bank holiday falls on a Monday, a day on which processing typically occurs. Or suppose that the processing for a particular day differs from the normal processing. You need to be able to identify exceptional days on which  processing either differs or does not take place at all. This topic uses standard and conditional rules to simulate a calendar feature. A standard rule compares item values to determine if they are in or out of
balance. An inactive standard rule is evaluated only within a conditional rule. A conditional rule uses IF/THEN logic to determine whether a condition is true or false. An active conditional rule can activate an inactive standard rule.

Here is a problem scenario:

Your company processes approximately the same number of transactions each weekday, except for the day that monthly paychecks are distributed. On that day, the number of transactions jumps dramatically, so you want to run your rules with a higher tolerance level. You have a job in ACR/Summary that runs on weekdays. The job is defined with a 15% tolerance. On the Monday following the third Friday of each  month, you want to run an alternate rule, with a 20% tolerance.

Your resolution is as follows:

The resolution is to set up a job that applies an alternate rule on the Monday following the third Friday of each month. The Monday following the third Friday of the month will fall between the 18th and the 24th of the month.


Follow the steps below:


1. In ACR/Summary, set up three calculated items:

A. For C-001, use the @DATE function to obtain today’s date.

B. For C-002, use the @DAY function, with the previous calculation, to separate out the day of the month, that is, the 1st through the 31st.

C. For C-003, use the @DAYOFWEEK function to determine if the day is a Monday.

2. Define an inactive standard rule, R-001, with a 15% tolerance, for use on normal processing days.

3. Define a second inactive standard rule, R-002, with a 20% tolerance, for use on the Monday after the third Friday of each month.

4. Define a third inactive rule, R-003, to determine if the value of Calculation 2 is greater than or equal to 18.

C-002 ≥ 18

5. Define a fourth inactive rule, R-004, to determine if the value of Calculation 2 is less than or equal to 24.

C-002 ≤ 24

6. Define a fifth inactive rule, R-005, to determine if the value of Calculation 3 is 1.

C-003 = 1


7. Define an active conditional rule, R-006, to determine if R-003, R-004, and R-005 are in balance. If Yes, activate R-002. If No, activate R-001.

VI. Minimizing Transaction Processing Errors

3. Set up standard rules in reverse: consider unmatched items in balance 

  • Use the default cycle value of 1 or use the same cycle number to store all history items so the items will match up across days. 
  • Extract the transaction date for aging.
  • Generate the Suspense Aging Report to show the length of time that
    items remain in history.

 

Related articles

Comments

0 comments

Please sign in to leave a comment.