Master Selector Tables

As an alternative to the COMBO_DATA_TBL, you can build static or dynamic master selector tables. Make the decision about the combination build option based on the nature of the combination rules. Consider both the number of rules and expected changes in the relationships of the underlying values.

You build a static set of master selector tables to support online and batch PeopleCode editing that is done in general ledger feeder systems when it is not practical to build the COMBO_DATA_TBL. This is usually due to the number of combinations that are generated or due to the time it takes to clear and rebuild the COMBO_DATA_TBL when you make changes in the combination values.

Static master selector tables are not maintained dynamically by the online PeopleCode or the batch editing process and must be rebuilt each time that you change a tree or a combination rule. However, they still have an advantage over the COMBO_DATA_TBL, which must be built every time you add a ChartField value to the system. You do not need to rebuild the master selector tables when you add a ChartField value if it falls within a range of values that are defined in a tree that is used by the combination rules.

When you use trees to define the combination rule, the system stores the ranges of values in the tree that you specify for the master selector tables when you build the tables. You only need to rebuild the tables when certain data on which they are based changes. For example, rebuild the tables when you change the combination rule to reference a different node of a tree, or if you change a tree originally having a range of accounts from 100001-100099 to a new range of 100004-100099 in a particular node.

You can build master selector tables for a range of time spanning a period as long as you want. The transactions during the specified date range are correctly edited. The tables contain data from the PeopleSoft trees you referenced in your combination rules. If you do not have many effective dated versions of trees, you can build the Master Selector Tables for a very large date range, for example January 1, 1900 to January 1, 2999.

However, if you change the trees often and create new effective dated versions of trees when you make changes to the trees, you can build the master selector tables more often, and have the tables span shorter periods of time. The amount of data that is in the master selector tables grows according to the number of effective dated trees in the time period that you specify. It is best practice to build master selector tables only for the time period for which journals or transactions are most actively being edited. For example, build them for one or two accounting periods or for one fiscal year at a time.

Batch editing, such as for journal edits, use the master selector tables if they are built for a time period that includes the date of the journals or vouchers being edited. If they are not built, batch edit builds the tables dynamically. You may want to build the master selector tables even if you are only using batch editing to improve the performance of the edits.

Run Build Combination Data Request Page for Master Selector Tables

Use the Build Combination Data Request page to run the process to build master selector tables.

Before you can run the Build Combination Data process, you must first define the detail ledger group for the business unit, and then tie the combination editing group to that ledger group.

Select Build Selector Tables in the Build Option field, and the From Date and To Date fields become available for you to specify a time period. All trees that are in the rules that have effective dates that are within the range of this time period are included in building the Master Selector tables.