Setting Up Receivable Update and Pending Group Generator

This chapter provides an overview of the Receivable Update multiprocess job (ARUPDATE) and the Pending Group Generator process (AR_PGG_SERV) and discusses how to:

• Set up parallel processing.

• Set up run controls for Receivable Update.

Understanding the Receivable Update Application Engine Process

This section discusses:

• Receivable Update process overview.

• Receivable Update multiprocess job.

• Receivable Update processing options.

• Accounting history and accounting periods.

Receivable Update Process Overview

The posting process in Receivables is known as Receivable Update. The Receivable Update process occurs throughout the system as you post pending items. These pending items can be entered online, created by your billing interface, or created during payment processing, draft processing, direct-debit processing, overdue charge processing, or during item maintenance activities.

When you post items in Receivables, the system processes groups of pending items to update a customer’s balance, system-defined history elements, and item balances. During processing, the system creates balanced, valid accounting entries. The Journal Generator Application Engine process (FS_JGEN) then summarizes the accounting entry information in general ledger journal format. The General Ledger Posting Application Engine process (GLPPPOST) updates the ledger balances.

Receivable Update processes records in these transaction tables:

• Group Control (PS_GROUP_CONTROL) - Contains header information for the transaction group.

• Pending Item (PS_PENDING_ITEM) - Contains the transaction type and transaction detail.

• Pending Distribution (PS_PENDING_DST) - Contains accounting entries.

• Pending VAT (PS_PENDING_VAT) - Contains value-added tax (VAT) transaction type and transaction detail.

• Pending Tax (PS_PENDING_TAX) - Contains India excise duty tax and sales tax entries from a billing system.

• Pending Tax Details (PS_PENDING_TAX_DTL) - Contains India excise duty tax and sales tax details.

The process updates six master tables:

• Item (PS_ITEM) - Contains detailed information about the receivable.

• Item Activity (PS_ITEM_ACTIVITY) - Describes the action taken on the receivable item.

• Item Distribution (PS_ITEM_DST) - Contains the accounting entries for the item activity.

• Item VAT (PS_ITEM_ACT_VAT) - Contains the VAT transactions for the item activity.

• Item Tax (PS_ITEM_ACTTAX) - Contains tax information for India for the item activity.

• Item Tax Details (PS_ACTTAX_DTL) - Contains tax line information for India for the item activity.

Note. If you enabled the options for processing entry events selected at the installation level and on the Receivable Update Request - Options page, the Receivable Update process calls the Entry Events Generator Application Engine process (FS_EVENTGEN), which updates the Entry Event Accounting Lines table (PS_EE_ITM_ACCTG_LN) with the supplemental accounting entries.

This graphic shows the flow of data:

Receivable Update transaction tables and master tables

The Receivable Update process also updates the system-defined customer history elements.

See Also

Understanding History Calculations

Receivable Update Multiprocess Job

The Receivable Update multiprocess job (ARUPDATE) consists of up to eight steps. This table describes each step:

See Also

Setting Up Parallel Processing

Using Commitment Control Processing in Receivables

Receivable Update Processing Options

When you run the Receivable Update process, you normally run it as a scheduled process. However, Receivables enables you to post groups from a group action page immediately instead of waiting for a scheduled batch process to run. Use this function for small groups when you need to post a transaction immediately. Each posting action is associated with an on-demand process group by default, and you enable users to use an on-demand process group in user preferences. These posting options are available from the action pages:

Standard Jobs

To schedule a batch standard job, create a run control and do not create any RP_RUN_OPTIONS on the Application Engine Request page for the AR_POST application engine. Each time that the system runs the Receivable Update process for this run control, it processes all groups for which the posting action is set to Batch Priority or Batch Standard.

Priority Jobs

To schedule a batch priority job, create a run control and enter PRIORITY in the Value field and select RP_RUN_OPTIONS in the Bind Variable Name field on the Application Engine Request page for the AR_POST application engine. Each time that the system runs the Receivable Update process for this run control, it processes all groups for which the posting action is set to Batch Priority.

Setup for Receivable Update Processing Options

You must enable all users to run one of the system-defined process groups on the Define User Preferences - Process Group page. This enables users to select a posting action on the group action page. You specify on which group action page the user has access to these options. You can set this up for:

• Pending item entry.

• Payment worksheets.

• Maintenance worksheets.

• Transfer worksheets.

• Unpost groups.

• Item split.

Important! The Post Now and Post Now to GL options should be limited to a small group of users and should not be used as the standard method for posting transactions.

Receivables defines which processes are included in each process group and from which pages a user can run the process groups. In addition to the Define User Preferences - Process Group page, you must specify any real-time run control options and real-time process options such as the server name and whether or not to use event notification on the On Demand Processing Options page.

Note. To check the status of the process if you do not set up event notification, check the FS_STREAMLN job in the PeopleSoft Enterprise Process Monitor.

The ARPOST process group (Post Now option) posts the transactions in the group and creates the accounting entries. It runs these processes:

• Pending Group Generator.

• Interunit Central Processor (IU_PROCESSOR).

• Posting.

• Entry Event Generator (if enabled).

• Revenue Estimate (if commitment control is enabled).

• Budget Processor (if commitment control is enabled).

The ARPOSTGL process group (Post Now to GL option) posts the transactions in the group, creates accounting entries, generates the journal entries, and posts the journal entries to the general ledger. It runs these processes:

• Pending Group Generator.

• Interunit Central Processor.

• Posting.

• Entry Event Generator (if enabled).

• Revenue Estimate (if commitment control is enabled).

• Budget Processor (if commitment control is enabled).

• Journal Generator.

• Edit Journals (GLJEDIT)—if you have General Ledger.

• Post Journals (GLPPPOST)—if you have General Ledger.

Note. If you select the ARPOSTGL option and you do not have PeopleSoft Enterprise General Ledger installed on the system, disable General Ledger on the Installed Products page so that the Journal Generator process does not call the Edit Journals or Post Journals processes.

See Also

Setting Up Run Controls for Receivable Update

Setting Up On-Demand Processing

Accounting History and Accounting Periods

Receivables gives you control over both your calendar periods and when you update history elements. You define detail calendars based on your processing schedule. Each period in this calendar represents a week, a month, or any other amount of time.

You assign a detail calendar for history calculations on the Receivables Options - General 1 page for each setID. The system calculates, summarizes, and stores all monetary transactions that fall within the date range for the periods that you define. You also specify which period in the calendar to use to calculate days sales outstanding (DSO) on the Receivables Options - General 1 page. The Receivable Update process uses this period to update the DSO history element. You also control when to update other history statistics using the Customer History Options check boxes on the Receivable Update Request page. When you select the option to update DSO, the page displays the period for which it will calculate the historical information.

Another factor to take into consideration is the calendar that you use for accounting periods. You assign a calendar ID to a general ledger business unit on the Ledgers for a Unit page. By default, each receivables business unit has the same open periods with the same opening and closing dates as the general ledger business unit with which it is associated. However, you can have different periods open in Receivables or even different beginning and ending dates for the period. You override the general ledger period information for an individual receivables business unit on the Open Period page. After you close an accounting period for a Receivables business unit, you can no longer post transactions to that period.

After running Receivable Update to calculate historical information, if you do not want to log any additional activity to a historical period, you may want to do one of two things:

• Use the same detail calendar for your history elements that is used for the accounting periods for the general ledger business unit.

• Make sure that the period is closed before you run the Receivable Update process to calculate the DSO.

Understanding Pending Group Generator Application Engine Process

All logic for creating accounting entries resides in Pending Group Generator. The Pending Group Generator Application Engine process (AR_PGG_SERV) is a component of Receivable Update that creates all the accounting entries in Receivables and:

• Runs each time the Receivable Update multiprocess job runs.

• Creates accounting entries for payment, overdue charges, maintenance, transfer, direct debit, and draft groups, depending on your setup.

• Creates accounting entries for online billing groups or for external billing groups when the billing interface does not provide accounting entries and Receivables has been set up to create accounting entries.

• Calls the centralized Inter/IntraUnit Application Engine process to create interunit and intraunit accounting entries.

Pending Group Generator is the second step in the Receivable Update process.

You normally only run Pending Group Generator online in a test environment when you want to make sure that your setup is generating the appropriate accounting entries. After the process creates accounting entries, you can review the results online on one of the Accounting Entries pages.

Setting Up Parallel Processing

This section provides an overview of parallel processing for Receivable Update and discusses how to:

• Define the maximum instances in PSAdmin.

• Define the maximum concurrent processes for the server.

• Define the number of parallel processes.

• Add more parallel processes to the AR_PGG and AR_POST multiprocess jobs.

• Add additional Pending Group Generator and Posting process definitions.

Understanding Parallel Processing for Receivable Update

This section discusses:

• Parallel processing overview.

• AR_UPDATE process.

• AR_PGG and AR_POST multiprocess jobs.

Parallel Processing Overview

Receivables enables you to break up the data that Receivable Update processes into multiple pieces (partitions) to be processed in parallel, achieving higher performance. You initiate the parallel processes by using a single run control, and the process automatically divides the work between the number of partitions that you specify in your setup.

The Receivable Update multiprocess job (ARUPDATE) includes:

• The AR_UPDATE Application Engine process.

• The AR_PGG multiprocess job.

• The AR_POST multiprocess job.

• The AR_UPDATE2 process.

Note. The ARUPDATE multiprocess job also includes the Revenue Estimate process and the Budget Processor process. The AR_UPDATE2 process calls the Revenue Estimate and Budget Processor processes if you have enabled commitment control for Receivables and the business unit. The AR_UPDATE2 process also calls the Journal Generator process if you select the Process GL Journal Generator field on the run control. You cannot divide the work for these processes into multiple partitions.

This graphic shows how the process works if you have three partitions.

Receivable Update parallel processes

When you use Process Monitor to check the status of the Receivable Update process, you view the status of the ARUPDATE multiprocess job and each process within the AR_PGG and AR_POST multiprocess jobs. The system does not indicate that the ARUPDATE multiprocess job is successful until each parallel process completes. The Job Message Log Summary page summarizes all the individual parallel process message log messages for the entire ARUPDATE job.

AR_UPDATE Process

The AR_UPDATE process is the first process executed within the ARUPDATE job. The AR_UPDATE process acts as a preprocessor for the actual AR_PGG and AR_POST processes and does these tasks:

• Builds groups from all worksheets set to post.

• Identifies all groups set to post.

• Partitions the data between all the child parallel processes for both AR_PGG and AR_POST.

The distribution of data among the child parallel processes is based on the composition and volume of the data. The process takes into consideration which groups are eligible for Receivable Update, based on the standard Receivable Update run control and automatically partitions the data.

AR_PGG and AR_POST Multiprocess Jobs

The AR_PGG and AR_POST multiprocess jobs contain all the PeopleSoft Enterprise Application Engine process definitions, such as AR_PGG1, that you use for parallel processing.

Each process definition for AR_PGG calls the AR_PGG_SERV Application Engine process. Receivables delivers eight process definitions for AR_PGG_SERV—AR_PGG1 through AR_PGG8. Each process executes the appropriate Application Engine program to process a specific partition of data. For example, the AR_PGG2 process only processes data in partition 2.

Each process definition for AR_POST calls the AR_POSTING Application Engine process. Receivables delivers eight process definitions for AR_POST—AR_POST1 through AR_POST8. Each process executes the appropriate Application Engine program to process a specific partition of data. For example, the AR_POST2 process only processes data in partition 2.

If you want to run more than eight parallel instances of the Pending Group Generator or Posting process at once, you must define additional process definitions by using the PeopleSoft Enterprise Application Designer.

The standard setup for the AR_PGG multiprocess jobs is to run a single process that contains only the AR_PGG1 process definition. The standard setup for the AR_POST multiprocess job is to run a single process that contains only the AR_POST1 process definition. If you want to use parallel processing for these processes, you must assign additional process definitions to the job definition. Working with your system administrator and based on your system configuration, you must specify the number of parallel processes that your organization will use. Specify the number of parallel processes equivalent to the number of processors within your system. You will probably need to experiment with the number of parallel process to find what works best. We recommend that you assign just a couple of additional parallel processes to start with and increase the number if needed.

You may also need to override the server settings for your organization. By default, you can run up to three instances of a process at one time. If you want to run additional instances you must change your configuration. If you also use parallel processing for the Payment Predictor process (ARPREDCT), Aging process (AR_AGING), and Statements process (AR_STMTS), the maximum instances applies to those process as well. For example, if you want to run eight instances for the Payment Predictor process and four for the Receivable Update process, you configure your server for eight instances.

Pages Used to Set Up Parallel Processing

Defining the Maximum Instances in PSAdmin

Open the PSAdmin tool on your server to change the configuration settings.

To change the maximum instances:

1. Scroll to the section titled Values for config section - PSAESRV.

   The section looks as follows:

   Values for config section - PSAESRV.
   Max Instances = 3.
   Recycle Count=0
   Allowed Consec Service Failures=0.

2. Change the value for Max Instances to the maximum number of parallel processes that you want to run at once.

Defining the Maximum Concurrent Processes for the Server

Access the Server Definition page.

Defining the Number of Parallel Processes

Access the AR Parallel Processing Options page.

See Also

Defining Receivables Installation Options

Adding More Parallel Processes to the AR_PGG and AR_POST Multiprocess Jobs

Access the Job Definition page for the AR_PGG or AR_POST job.

Process Type and Process Name	Select Application Engine for the type and select AR_PGG or AR_POST for each separate partition or process that you want to run. The processes must be defined in the job sequentially; for example, AR_POST1, AR_POST2, AR_POST3. A job definition of AR_POST1, AR_POST2, AR_POST5 is incorrect. If you define additional process definitions, select the name of the definitions that you added. Note. You must have the same number of rows in the process list as you enter in the Maximum Partitions field on the AR parallel Processing Options page.
Run Mode	Always select Parallel.
Run Always on Warning and Run Always on Error	You must select these check boxes.

See Also

Enterprise PeopleTools PeopleBook: Process Scheduler PeopleBook

Adding Additional Pending Group Generator and Posting Process Definitions

Access the Process Definition page.

Complete the fields on this page and the other pages in the Process Definition component (PRCSDEFN) to match the AR_PGG1 and AR_POST1 process definitions with the two exceptions:

• Use another process Name.

  We recommend that you use this format for the name: AR_PGG# or AR_POST#, for example AR_PGG9.

• Use another Description.

To add more processes to execute in parallel than the eight delivered by PeopleSoft:

1. Open an existing Application Engine program definition such as AR_PGG1 or AR_POST1 in PeopleTools Application Designer.

   Do a Save As using the new program name, such as AR_PGG9 or AR_POST9.

2. For an AR_PGG program, you must edit program step MAIN.PGG_SERV.DoWhen to define which partition will have accounting entries generated by that individual process. Change only the last parameter to match the partition. For example:

   SelectInit (AR_UPDATE_AET.PGG_MODE, AR_UPDATE_AET.PARTITION)
   %Sql (ARUPDATEPARALLELEXISTS,,9)

3. For an AR_POST program, you must edit program step MAIN.POSTING.DoWhen to define which partition will be posted by that individual process. Change only the last parameter to match the partition. For example, for AR_POST9:

   %SelectInit (AR_UPDATE_AET.RP_ACTION, AR_UPDATE_AET.PARTITION)
   %Sql (ARUPDATEPARALLLEXISTS, 2,9)

See Also

Enterprise PeopleTools PeopleBook: Process Scheduler PeopleBook

Setting Up Run Controls for Receivable Update

This section provides an overview of run control setup and discusses how to:

• Create run control IDs for Receivable Update.

• Select additional processes to run.

• (Optional) Modify steps for AR_POST.

• (Optional) Modify steps for AR_PGG.

See Also

Enterprise PeopleTools PeopleBook: Process Scheduler PeopleBook

Understanding Run Control Setup

The Receivable Update process processes all groups for all business units specified on the Receivable Update request. Depending on your installation size and the volume that you process, you may want to use a different method known as chunking. Chunking enables you to process large sets of data more efficiently by breaking them into subsets or smaller units of work. You can chunk by business unit, by group type, by both of these, or by group.

To use chunking when you run the Receivable Update process or set up batch priority run parameters, perform these steps:

1. Create a run control ID for the Receivable Update multiprocess job on the Receivable Update Request page.

2. Modify the Application Engine steps for the run control ID for each AR_POST# process on the Application Engine Request page.

   For example, if you have 3 partitions, you define the parameters for AR_POST1, AR_POST2, and AR_POST3

3. Modify the Application Engine steps for the run control ID for each AR_PGG# process on the Application Engine Request page.

   For example, if you have three partitions, you define the parameters for AR_PGG1, AR_PGG2, and AR_POST3.

In most cases, you probably will run the Receivable Update process by using a scheduled job.

When you create a run control request for the Receivable Update process, you can also specify that you want to run the Entry Events Generator and the Journal Generator processes.

Pages Used to Set Up Run Controls for Receivable Update

Creating Run Control IDs for Receivable Update

Access the Receivable Update Request page.

Note. If you do not want to use DSO30 or DSO90, use the System-Defined History page to make these customer history IDs inactive.

The run control ID that you used to access this page is linked to your user ID. When you add a Receivable Update request, the system creates a Application Engine request for you with the same user ID and run control ID combination, specifying AR_PGG1 and AR_POST1 as the processes. If you want to add options to other parallel processes, you must add them separately.

See Also

Defining General Options

Setting Overall Installation Options

Selecting Additional Processes to Run

Access the Request Receivables Update - Options page.

Modifying Steps for AR_POST

Access the Application Engine Request page.

Enter the name of the appropriate AR_POST# program, such as AR_POST1.

Use the State Record, Bind Variable Name, and Value fields to define exactly what data you want to post. This enables you to process smaller units of data. Add as many rows as needed.

Setting PRIORITY Parameters

Enter PRIORITY in the Value field to give priority to groups whose posting action is Batch Priority. PRIORITY is designed to run on a recurrence definition that directs the system to run periodically throughout the day to pick up only new priority groups. You define recurrence definitions by using the Process Scheduler when you indicate how often you want the Receivable Update process to run (for example, hourly or daily).

The following is a description of PRIORITY and a description of sample field values.

Note. You do not need to set up an RP_RUN_OPTIONS for a Batch Standard run control. With standard processing, the system processes groups with either a Batch Priority or Batch Standard posting action. A standard scheduled job processes any priority groups that have not been processed since the last scheduled PRIORITY run.

Narrowing the Scope of Receivable Update

These tables show how you can narrow the scope of what the process posts.

Using Chunking in Receivable Update

Chunking enables you to process large sets of data more efficiently by breaking them into subsets or smaller units of work. You can chunk by business unit, by group type, by both of these, or by group. This table shows examples of how to enter chunking parameters.

See the documentation on managing Application Engine programs in the Enterprise PeopleTools PeopleBook: PeopleSoft Application Engine.

Modifying Steps for AR_PGG

Access the Application Engine Request page.

Enter the name of the appropriate AR_PGG# program, such as AR_PGG1.

You use the State Record, Bind Variable Name, and Value fields to define exactly what data you want to process. Add as many rows as needed.

This table shows how you can narrow the scope of what the process posts.