Using the Ledger Interface Utility

Task 1 - Define Message Nodes

Message nodes represent publishing or subscribing entities such as databases or application servers, and they are most often associated with a database name. Both corporate and regional locations need to define message nodes. Corporate defines its own local node and one remote node for each regional location that sends data. Each regional location defines its own local node and defines one remote node for the corporate location.

To define the necessary message nodes:

1. Define a local message node.

   As delivered, the Ledger Interface Utility publishes data to the standard PSFT_EP message node. Rename the standard local node with a unique node name that is associated with your database.

2. Verify that the node, as you renamed it, is the local node.

   There can be only one local node at a location. If you attempt to save a second local node, the system displays an error message.

3. Define remote message node locations.

   A region defines one remote node for its corporate location, and the corporate location defines multiple remote nodes, one for each regional database to be consolidated. If the corporate list is missing a URL for one of the regional databases, the corporate location does not receive the data for that region.

Task 2 - Define the Service Operation Queues

A service operation queue is a logical group of messages. Each message must belong to one (and only one) queue, which specifies a routing. Both publishing and subscribing nodes use this service operation queue.

To define the necessary queue:

1. Use the delivered service operation named LEDGER.

2. As delivered, the Ledger service operation contains one routing rule for the standard PSFT_EP message node.

   You can delete the delivered routing rule and create rules that apply to your databases. Regional and corporate locations define different routing rules.

3. At the local regional location, define one routing rule with a message node name for your corporate location, with Publish To as the direction.

4. At the corporate location, define a routing rule with one message node name for each regional database that is involved in the consolidation.

   All routing rule definitions must be Subscribe From. If the corporate list is missing a routing rule for one of the regional databases, corporate does not receive data for that region.

Task 3 - Define the Message

A Ledger Interface Utility message contains a general ledger database. The message is the vehicle of transport that carries the database from the regional entity at one URL to the corporate entity at another URL.

The system inserts application data into the message according to the records that you specify in the message definition. Regional message definitions must match corporate message definitions. If you change your table in the database, the changes are automatically inherited by the message definition as long as table names remain the same.

To define the message:

1. View the LEDGER_LOAD message.

   Because consolidation does not support PeopleSoft Projects or Commitment Control, no ledger record names for Projects or Commitment Control are listed under LED_PUB_REQ in the message definition.

2. Keep the delivered record names in the LEDGER_LOAD message definition because changing them is considered a customization.

   If you must use a different table name, the table name listed below LED_PUB_REQ must match the ledger table name on the ledger template. For detail ledgers, the record definitions of your new ledger table and your staging table must be identical.

3. Activate the LEDGER_PUBLISH message at regional and corporate offices.

Task 4 - Create Staging Tables

Because summary account ChartField values are the same for regional and corporate summary ledgers, the summary ledger subscription process writes the subscribed data directly into the consolidated ledger table. Access the Setup Financials/Supply Chain, Business Unit Related, General Ledger, Definition page and select the Allow Ledger Load Updates check box.

Because detail ledgers frequently contain account ChartField values that differ between regional and corporate entities, the regional accounts need to be mapped to corporate accounts. To accomplish the mapping, detail ledger data is subscribed into staging tables. A ChartField mapping process reads the staging table, maps it, and writes the resultant data to the consolidated detail ledger table.

To create staging tables:

• Define staging table names at the corporate location.

  For detail ledgers, create record definitions for the staging tables that are identical to the record definitions of their corresponding ledger tables.

• At the corporate location, create a message record alias for each staging table.

  The alias names for the corporate node must match the alias names at the remote nodes.

Task 5 - Publish the Ledger Data

Publishing ledger data is done at regional locations. To publish a regional database, use the Publish Ledger page to select criteria and process options.

Task 6 - Subscribe from the Ledger Data

Using Application Messaging, data is published by initiating a process request on the regional general ledger database. At the corporate location, the subscription process is run automatically on the application server of the subscribing node.

Summary ledger data is written to the summary ledger file, and detail ledger data is written into the staging tables that are defined at the corporate location.

Before you run the ChartField mapping process (task 7), verify the detail ledger data. Add a view to the query tree for the staging table, and save it so that you can query the staging table to ensure that the data is written properly.

Task 7 - Perform ChartField Mapping

Regional detail and summary ledgers must have the same ChartFields and use the same calendar when you assign them to a business unit. Because account numbers often differ between detail and summary ledgers, run the ChartField Mapping process against the detail ledger data that is written to the staging tables. After mapping, run the consolidation process.

For detail ledgers, the system checks the staging table alias against the ledger template definition. If the staging table alias is pointing to the ledger template definition, it is possible for data to be written to an application table in error. To prevent such an error, the subscription process rejects any message whose staging table alias points to an application table that is defined in the ledger template.

If the staging table alias does not point to the ledger template definition, the system writes data into the staging table as specified by the alias.

To perform ChartField mapping:

1. Verify that the proper detail ledger data resides in the staging table (recommended).

   Add views to the query tree for the staging tables, and save them only once. Query the staging tables to verify that the data is written properly.

2. Run the ChartField mapping process against the staging tables.

Task 8 - Load Ledger Data

Loading ledger data is done at the corporate location. To load ledger data, use the Load Ledgers Request page to select criteria and process options.

Detail Ledgers

Considerations:

• Detail ledger ChartField values from regional databases can differ from the corporate database because the data is transmitted to the staging table.

  The ChartField mapping process reconciles these differences.

• For staging tables, add and save a view to the query tree.

  Query the staging table to verify that the data loaded properly before performing ChartField mapping.

• Regional detail ledgers must use the same calendar when you assign them to a business unit.

  Verify the calendar on the Ledgers for a Unit page.

• Regional detail ledgers must have the same ChartFields when you assign them to a business unit.

  Verify detail ledger ChartFields by navigating to the Detail Ledger Group - ChartField page: General Ledger, Ledgers, Ledger Groups. Select the ChartField tab. The Detail Ledger Definition report (FIN0022) also shows the structure of the detail ledgers.

Summary Ledgers

Considerations:

• ChartField values must be valid in both corporate databases and regional databases for the summary ledger.

• Regional summary ledgers must use the same calendar when you assign them to a business unit.

  Verify the calendar on the Ledgers for a Unit page.

• Regional summary ledgers must have the same ChartFields when you assign them to a business unit.

  Verify summary ledger ChartFields using the Summary Ledger Definition report (GLC1000), which shows the ChartField structure of summary ledgers.

Setup

To complete setup and verify the publication and subscription of information, refer to the PeopleTools documentation for the PeopleSoft Integration Broker, and see the section on using the Service Operations Monitor.