Purpose
The purpose of this job aid is to explain how time, payroll, and accounting are integrated in the Integrated HR-Payroll System.
The Time Management (TM) process is closely integrated with Payroll Administration and Financial Accounting (general ledger). TM creates time wage types based on Federal and State business rules and classifications of employees/positions. The system supports the application of numerous business rules associated with the details of the time data processing. Time data is entered, processed, and the outcome, after applying the various business rules, is time wage types. The time wage types determine hourly wage, overtime wage, and additional wage, and form the specifications for the financial valuation of work performed in payroll. Time wage types are passed to Payroll for conversion to payroll wage types. When time wage types are processed in payroll, it determines payroll wage types such as regular wages, overtime, shift premium, or holiday premium. They are used to form employees’ gross wages.
By means of the employee subgroup, the system recognizes whether the employee receives an hourly wage or a period-related salary.
Wage types from payroll are not assigned directly to accounts in Financial Accounting, but via symbolic accounts. A number of wage types, which the system posts to a specific account in Financial Accounting, are assigned to a symbolic account. The symbolic account’s account assignment type determines the type of posting (for example, posting to expense account, posting to receivable account, posting to payable account). The symbolic account is, in turn, assigned to the account in Financial Accounting. If the account in Financial Accounting is an expense account, it is usually assigned a cost element in Controlling.
A wage type can be assigned to several symbolic accounts. This is usually the case for wage types that should be posted as both expenses and payables (for example, wage types for the employer’s contribution).
Assigning symbolic accounts to accounts in Financial Accounting does not have to be done 1:1. Several symbolic accounts can be assigned to the same account in Financial Accounting. The amounts that are posted via a symbolic account to Accounting can be distributed among different accounts in Financial Accounting due to the employee grouping for account determination (feature PPMOD).
The system determines the symbolic account assignment from the wage types. It derives the employee grouping for the account assignment from certain characteristics of the employee. The G/L account is derived from the combination of employee grouping and symbolic account. The wage types from the payroll results are posted to the assigned accounts. This automatic process is called account determination.
The two-stage procedure is advantageous since Payroll is separated from the Accounting components by the "Symbolic Account" interface. If there are organizational changes in Accounting, the symbolic account assignment of the wage types remains unaffected. On the other hand, payroll changes do not necessarily cause changes to the account assignment settings in the Accounting components.
The results of each payroll calculation are stored in clusters to allow reporting of each payroll calculation for each employee for as long as the data is stored in the Integrated HR-Payroll system. This storage scheme also allows for automatic recalculation of an employee's pay based on the retroactively dated changes to employee data that impact payments or deductions.
When retroactive accounting data is posted, the posting run for the previous payroll result is reversed (posting with reversed sign) and the new payroll result is posted for the payroll periods accounted retroactively.
At the time of posting, Financial Accounting has usually closed the previous posting periods already. For this reason, retroactive accounting data is posted in the posting period that belongs to the current payroll period.
There is also a custom table (Ztable - ZFIA019_ACCOUNTS) that is manually maintained to determine the following values in order to derive NCFS GL account based on Funding source, employee group, and employee subgroup for Salary Control System (SCS) and BI reporting.
The Ztable is required as part of the interface from SAP to SCS/NCFS. This table will map vacant and filled positions in SAP to NCFS GL accounts. This is necessary because SCS positions are tracked by NCFS GL accounts among other objects. In SAP, vacant positions are not mapped to GL accounts while filled positions are mapped to SAP GL accounts via wage types. To simplify the process the Ztable will be used for both vacant and filled positions.
This table will be used by salary control interface to determine and populate the correct NCFS accounts on the interface output file.
This table uses a similar principal but is not as comprehensive as what occurs in SAP because it only deals with high level classifications such as EPA vs. SPA, LEO vs. Regular wages. It does not take into consideration other types of wages that are generated through time entry such as overtime, shift premium, holiday premium etc. During SCS interface, the interface program reads infotype 9018 and identifies the funding source from the fund. It also reads employee group and employee subgroups from infotype 1013. Then it reads the Ztable to determine if a record exists for the funding source, employee group and a range of employee subgroups. If a match is found, the appropriate NCFS GL account is written to the output file.
In both instances, the generated wage type will follow a similar conversion. If SAP account is ‘ EPA–Regular salary wages’ it will crosswalk to NCFS account ‘EPA-Regular Salaries’. SAP fund will determine the 6th digit of the NCFS account.
In general, the relationship is a 1:1- SAP account SPA Regular salary & wages equates to NCFS account SPA Regular Salaries –Receipts (Appropriations or Undesignated*).
Each position has an infotype for employee group (EG) and employee subgroup (ESG). Each person also has an infotype for EG and ESG. Most of the time, the EG and ESG are identical, but there are cases where this is not true. The position may be a ‘Full time SPA permanent’ position but is held by a ‘Temporary employee’. In this example, the employee’s EG and ESG would override the position EG and ESG and the salary expense would be charged to’ Regular Temporary Wages’, not ‘SPA Regular salary & wages’. This is in keeping with best business practices and OSBM policy to reflect the true identity of an expense.
The Department of Health and Human Services is the only state agency that uses the undesignated account (due to cost allocation). Additional coding was incorporated into the SCS and NCFS crosswalk interface to allow for the undesignated account which does not exist in SAP. The funding source is determined as described above and then an additional step is performed. The internal order number text field is read and if the last two digits (in 13 & 14 byte) are ’99, it will convert the 6th digit of the NCFS account to (previously 531213 in NCAS) or (51210000 NCFS).
And/Or NCFS segment will also includes ’99’ in the Project fields on 32-33 positions.