<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2002698&amp;fmt=gif">

Whitaker-Taylor Insights

Good Practices When Updating or Modifying Schemas

Jul 22, 2016 12:00:00 PM / by Whitaker-Taylor

shutterstock_168212465.jpgSchemas are an essential component of time and payroll processing. The payroll and time schema itself contains multiple subschemas filled with logic such as operations and functions that essentially govern how your payroll and time processes are handled within your business. Although it may not be apparent, a business’s weekly paycheck to an hourly associate is directly a result of running the respective payroll and time schemas.

From an end user, as well as a consultant perspective, dealing with time and payroll-related changes can often be difficult due to the complexity of how the payroll and time schemas are built in the HRIS system. While working in the payroll and time schemas, you must not only ensure that the new changes as a result of the new requirements are working, but also that all other functionality remains untouched and working as normal. Here are three tips that can help you achieve this goal. 

Use Descriptions, But Be Concise

Requirements within a business are ever changing year to year because of changes in payroll and time concepts such as new numbers of pay periods or new overtime and shift premium regulations for employees. Consequently, the logic in rules operations within a schema may frequently change. So it is good practice to ensure that the rules that make up your schema have an appropriate description that summarizes the operation and logic which is being processed. It’s also a good idea to have descriptive, but concise, comments in the logic and operations of your rules. These practices allow your schema to be more navigable when a new requirement demands a change.

Let’s look at the example below from the state of California. They have used appropriate and descriptive comments, and therefore a user can easily navigate within the schema when a change is required with regards to Overtime processing in the state of CA.



Figure 1. Overtime Payroll Processing in State of CA


If You Don’t Need It, Take It Out

Ideally, a perfect schema would be one that is concise and ensures that business policies and regulations are being calculated and performed correctly. In reality though, schemas are oftenIt is not uncommon for a payroll schema to comprise more than 2,000 lines. Therefore, take any steps you can to condense a schema and make it more user friendly. One of these steps is rules and operations that are no longer used within a schema. By doing so, you shorten the processing time because the schema skips the processing of the commented out rule or operation. I it also allows you to see which rules, and the business process they represent, are no longer in use. This tip produces a schema that is more understandable to a new user, as well as an experienced one.



Figure 2. Commented Rules and Operations within a Schema

In the screenshot above, you can see that lines 150, 210, and 220 have been commentated out. As a result of this, the text for these lines changed to black which indicates that these rules are no longer processed within the schema. In the screenshot represented by Figure 2, commentating these 3 lines represents a business process that is no longer needed: an automated mailing process sent to an administrator if an error within a schema occurs and/or a work center substitution.

Think About the Date

When making changes or updates to your schema, ensure that the logic changes you are adding to the schema are date sensitive. For example, if a change to the schema is effective 01/01/2016 and onward, you should include this date logic requirement in the schema change as well. This step yields two benefits. First you are not replacing or deleting the old logic in the schema and, therefore, maintaining historical data. Secondly, you are preventing any potential errors when retro accounting happens in the future. Without this date logic check, when a retro occurs before the effective date of the policy change, it will process the newly added logic associated with the new policy change rather than using the correct old logic associated with the old policy. Figure 3 below represents date effective logic in the schema that ultimately will allow (or not allow) new logic to be processed based on the comparison of the year of the processing date to that of 2016.



Figure 3. Date Effective Logic within a Schema


To sum it all up, following these three tips

  • Include descriptive, but concise comments.
  • Remove rules and operations that are no longer used.
  • Ensure logic changes are date sensitive.

…will make your schema more concise and user friendly. It also will make future updates or changes to the rules and operations in the schema as painless as possible by eliminating the fear of encountering problems that could harm business productivity for day to day processes.


Click the button below to gain weekly access to useful SAP HCM and SuccessFactors blogs written by Whitaker-Taylor expert consultants.   


Topics: HRIS, Payroll

Written by: Whitaker-Taylor