Following the successful execution of a payroll run, one of the subsequent activities that must be performed is posting payroll results to Financial Accounting and Cost Center Accounting. A productive posting run affects the posting of personnel expenses and payables to accounting. This can affect the size of tables PPOPX and PPOIX because they are updated when the payroll results post. However, if tables PPOPX and PPOIX grow very large, posting can be inhibited and adversely affected by long runtimes or even program termination. Therefore, it is important that you manage these tables’ growth before they get too large. Here are some best practices and approaches on how to control the size of these tables.

You can execute posting runs via program RPCIPE00 or by following menu path Human Resources > Payroll > Subsequent activities > Per payroll period > Posting to Accounting > Execute posting run (Figure 1). You can execute three types of posting runs in the system: a test run, a simulation run, and a productive run. You can simulate a posting run by creating a test run without posting documents and by creating a simulation run with posting documents. The type of posting run performed is controlled by the Type of document creation field in Figure 1. To execute a production run, enter P in the Type of document creation field. Alternatively, to execute a simulation run (with documents) enter S or to execute a test run (without documents), enter T.

Figure 1

Initial selection screen for posting payroll results to accounting

When you execute a test run (without documents), the system performs the following activities:

• Selects the payroll result
• Determines posting-related data and the wage types to be posted
• Determines the symbolic accounts and the employee grouping for account determination
• Creates individual line items for the posting documents (but does not save them)

When you execute a simulation run (with documents), the system performs the following activities:

• Creates a posting run, but the posting document is not posted because it is marked as a simulation run
• Subjects the posting documents to similar checks performed for a production posting run

Before executing a productive posting run, you need to satisfy a number of conditions. These include:

• The payroll run for the selected personnel numbers under consideration must be successful
• The payroll run for all affected payroll areas must be successfully completed
• An error-free simulation run containing correct posting document must be executed

You can’t exit Payroll until the payroll has run successfully for all the personnel numbers assigned to the selected payroll area.

Next, the system performs a sequence of activities when posting payroll results to accounting for a productive run. These include:

• Creation of a posting run
• Evaluation of the payroll results
• Creation of payroll documents
• Checking the check boxes of employee-related payroll results for the evaluated employees
• Generation of index information

The generated index information plays a key role in the description of posted items and computation of retroactive accounting differences. The index acts as a bridge between employees’ payroll results and the posting document. The employee payroll result contains accounting-related wage types, which include wage types posted:

• As expenses to appropriate expense accounts
• As credits to appropriate payable accounts
• To an expense account as a debit and to a payable account as a credit

Posting documents are objects created during the creation of a posting run. They contain all the data transferred to accounting when executing a productive posting run.

You can only execute a productive posting run once per personnel number and payroll period. Before you can re-execute a productive posting run, you must delete the initial (i.e., existing) productive posting run. Conversely, you can execute a posting run as a simulation run for the same personnel number in the same period as many times as you desire. Since the size of tables PPOIX and PPOPX is based on the entries created during a posting run, the growth of tables PPOIX and PPOPX is largely dependent on the number of:

• Employees captured in the posting run
• Payroll results for each employee
• Postings for each payroll result
• Posting runs executed as productive runs
• Productive runs that were deleted

When you execute posting runs, you need to perform completeness checks to ascertain whether all employees were taken into consideration during the posting runs, and whether posting runs without the document posted status exist. For test run postings, only the zero balance of expenses and payables are checked. You can perform completeness checks by following menu path Human Resources > Payroll > Subsequent Activities > Per Payroll Period > Reporting > Posting to Accounting > Completeness Check.

Again, the size of tables PPOIX and PPOPX can grow very large to the extent that it affects system performance, especially when running productive postings. This is because large volumes of index information entries are updated into the tables, and are not deleted when the productive runs are deleted. To prevent the growth of these tables, it is a best practice to avoid the execution of a productive posting run with errors. Review your posting documents well before carrying out a productive posting run. Then, execute a posting run as a simulation run to check for errors. You can reverse a successfully posted document if you observe that it has errors. You can create reversal documents that contain the line items of the actual document but with a reversed sign. The posting run jointly manages the actual document and the reversed document. In accounting, the actual posting is deleted after the reversal documents are moved to accounting and the associated indices deleted.

However, use the simulation run option of posting run with caution. Indiscriminate use and high numbers of simulation runs can contribute to the uncontrolled growth of tables PPOIX and PPOPX. This is coupled with the fact that the simulation run also updates the tables with index information entries. Therefore, to effectively manage and control the growth of these tables, it is important that you delete simulation runs as soon as the reason for executing them has been achieved. After all, simulation runs are not needed for long-term purposes (such as retrospective accounting). You can use transaction PCP0 to delete the posting runs that you do not need to free up table space.

The way the system handles productive run deletion differs from the way it handles simulation run deletion. When you delete a productive run, the posting documents and index are not deleted, although the status of the posting run changes to Deleted. This is to allow for a reevaluation of the payroll results. When you delete a simulation run, the index and document lines are also deleted simultaneously. The status changes to Deleted but the document header, attributes, and status history are not deleted. As a result, you should delete the data on deleted productive and simulation runs via the program RPCIPQ00.

Before you attempt to delete a posting run, ensure that the posting run does not have any of the following statuses:

• Documents transferred
• Documents posted
• Partially archived
• Archived
• Reversal documents transferred
• Reversal documents creation is running
• Reversal documents created
• Reversal is running
• Reversal was successful
• Reversal documents are incorrect

If it has any of these statuses, you can’t delete it.

The system supports the archiving of the contents of tables PPOIX and PPOPX to decrease the size of the tables and increase system performance via the archiving object PA_PIDX. Note that you first need to archive payroll results via the archiving object PA_CALC before you can archive the index file up to the retroactive accounting date. Furthermore, consider archiving the indexes via archiving object PA_PDOC only if the indices that belong to this session are also being archived with PA_PIDX archiving object. The archiving process with PA_PDOC is faster because checks are not performed. The drawback is that you cannot use it for a large volume of data. Use the archiving object PA_PDOC for archiving posting documents. Posting documents can have different statuses during posting to accounting, which defines the events that took place on posting documents. When using PA_PDOC, it is important to note that posting objects with statuses such as document transferred, document posted, partial archiving performed, cancellation document transferred, and cancellation document posted cannot be archived.

Kehinde Eseyin

Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management.
 

You may contact the author at eseyinok@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.