Let’s look at some tax calculations – especially if you're a company that has many, many tax jurisdictions. In the US, for example, if you’re a company in Pennsylvania or Ohio where employees move between areas and there are many locals. In these cases, you may not have the configuration set up for the right employer identification numbers. The employee can still enter that tax jurisdiction based on where they're located, but when you're running payroll, you'll error out because the underlying configuration is missing for that tax jurisdication. So it’s great to have audit reports to identify situations where there are tax jurisdictions coming in from CATS (cross‑application timesheets) or in the employee infotypes that are not set in configuration. This gives you some ability to catch that on the front end. 

Then there are work location errors, where an employee – either via infotypes or from data coming in from the cross‑application timesheets or attendances – has a different work location than normal. Without the right setup, you'll get an error when processing through payroll because configuration is not setup. We want to try to eliminate that, because depending on how your support structure is built, it might be a while before the configuration can be put in place to fix that employee record so you can continue on with your payroll activities.

This is one error I especially like to find long before doing an audit report. At the infotype level or time entry level, when work location is entered we have a user exit built to check the configuration tables and validate that "Yes, Illinois is a state that we're set up or generate a message that says Illinois is not a state that we're set up."

There's a couple different ways to approach that: If an employee is entering time and they select a tax jurisdiction that is not set up, you can give them a hard error. But you can also give them a warning. And while there are pros and cons to both, I like to set up the warning. 

It gives the employee an opportunity to report the warning message to the payroll department and typically provides enough time to add the configuration before running payroll. Also, it can ensure more accurate reporting. Erroring the employee out during time entry or infotypes, the employee is more likely to use shortcuts ("Well, I'll just use something else to get by…") and then you don't get proper tax reporting.

And these are all user exits. Infotypes like Infotype 207, 208, 209, and 210 can all be set up with user exits to validate that your configuration actually has these tax jurisdictions as available options.

User exits also give you some flexibility, compared to removing all non-applicable jurisdictions from the dropdowns. If you clear all configuration not used as of today, you may have an issue in the future of having to setup the tax jurisdiction from scratch. User exits are dynamic, so with this approach, you can move into new tax jurisdictions as long as you do the configuration and there's no change to user exits.

Consier both audit reports and user exits when determine how best to reduce the number of issues you experience during your payroll processes.

- Mike Timm, Integrated Consulting Group
@MikeTimmSAP
mtimm@integratedcg.com

When dealing with that, typically audits should start at least a day or two prior. If it's on Monday, by Friday you might want to start looking at some basic things:

• Do I have all my audit reports? 
• Does everybody have a cost center? 
• Does every employee have an Infotype 9?

Then, based on your report, you can set it up to find any exceptions that occurred over the weekend. On Monday morning, the report was already processed early in the morning, so when you arrive you can now review it and look for problems: "There's a couple employees that were added over the weekend by HR, but the cost center is missing, so I need to get those addressed."

As part of a bigger audit check, you can actually run Time Evaluation and Payroll over the weekend before you arrive on Monday. Then you can have process models set up to automatically generate some of the documents or you can set up batch jobs that will run subsequent jobs.

One of the clients I've been working with runs payroll on Monday. They started to look at options to get the process started earlier by using the weekend. They were all working until 10:00 or 11:00 on Monday night and that was taking a toll. So we started running time evaluation late Sunday and we set up  a standard SAP batch program to release the payroll and then start payroll. When everyone arrived on Monday, employees had been processed through time evaluation, payroll, payroll journals had been run along with other audit reports.

They also gave HR a much larger window to go in and make HR master data fixes instead of the usual hour or an hour and a half.  HR now has the better part of the morning to tweak data and put in new hires.

The best part of the automation was a reduction in the payroll department overtime and a more relaxed atmosphere. Error rates reduced signifantly because of the gained time and employee trust of their paycheck increased.

Map out your payroll processes and look for areas that could be run earlier to get a head start on audits. The time will be well spent and payoff dividends in the long run.

- Mike Timm, Integrated Consulting Group
@MikeTimmSAP
mtimm@integratedcg.com

In fact, I'm actually working with a client that's recently gone live now. These audit checks were not put in place prior to go‑live, and now there's a scramble to put them in. 

One of them is checking a report that will go out and check for missing infotypes. If an employee is missing certain infotypes when they get into running the payroll, they'll bomb out.  For example, if you've had any experience with missing Infotype 9, which is the payment method, direct deposit or a check, you know that can cause some problems – especially when you discover this only after going through the entire process.

For any infotype check, you have to identify which ones are important to your company. Once you verify that everybody has their infotype, you might even want to go in to look for specific fields. If you've created any custom infotypes or custom fields on existing infotypes that you need as part of your payroll process, your report can look for those specifics. I like to verify there are no employees missing a cost center using the Flexible Employee Data report, tcode S_AHR_61016362. Key date is set to Today and for Selection I set it to look for blank cost center in Infotype 0001.

I also always like to check something very basic: Making sure that no employees are locked right before I run payroll. If you run your payroll late at night, you're probably OK. But run it during the day on Monday or Tuesday, like a lot of companies do, and HR might lock an employee incorrectly, because they forgot that you're running payroll. There's a standard SAP report, tcode PC00_M44_UCPL, that you can run to avoid employees being locked.

There are other reports or audits that you can run. You might want to check and see, for example, do you have Infotype 8s, basic pay, that have numbers or dollar amounts that don't make any sense?

If your employees are typically paid less than so many dollars per hour, show me any employees that are set up to have more than that. This way, you'll be able to avoid the problem of employees who are set up as hourly, but were given  a salary rate – so then you’re paying them $200,000 or $300,000 in a weekly payroll.

These -- "Is everything there that I expect to be there? Is anybody locking the employee records? Do my employees make within a certain salary range?" -- are just some of the basic checks that should clear up many errors you might encounter.

- Mike Timm, Integrated Consulting Group
@MikeTimmSAP
mtimm@integratedcg.com

When the time comes to apply TUBs, Cyclic, or upgrade to a newer version of BSI TaxFactory, we can reuse the files we’ve already created by changing the Check Date instead of having to locate and create all the data in SAP. This does not replace end user testing, but it does expedite unit testing in development environments where data is typically sparse and out of date. 

Getting started we need to get the information we want to use in the BSI TaxFactory Batch Test Tool. Find the employees you want to use as test scenarios in production or create the scenarios in a test environment. Once you have all the master data setup run your payroll as you would typically do, but make sure to select the Payroll Log check on the Payroll Driver (transaction codes PC00_M10_CALC or
PC00_M10_CALC_SIMU) parameter screen.

Once the payroll runs, follow the log path to the BSI Interface node. The BSI interface node detail provides you with the same information that is passed from SAP to BSI.  Tax calculations for the employee are performed on this data

Gross cumulation and tax processing > ELSE > LPBEG > Run > Calculate Taxes > USTAX > Processing > BSI interface

Push CTRL + Y to highlight the data and then CTRL + C to copy the data and paste directly in BSI TaxFactory Batch Test Tool. Make sure to get from the first line of ATC to the last line of ETC so BSI knows where the beginning and end are in the data. You should have something that looks similar to this, but with a complete data set.

With this data you can manipulate the contents and save the different scenarios. Here are a few quick scenarios you can put together and save for current and future use.

1. Change the CD (check date) to see how taxes calculate on a specific date in time.

2. Change the tax authority next to the lines that start with ‘ADC TC:’

3. Test reciprocity by copying lines that start with ‘ADC TC:’ through lines that start with ‘LUD PT:’ and change the tax authority.

Once you have your scenario created, it is as simple as selecting the Run Test button and  you should receive output very quickly that displays the details you need to validate.

If you want a method to quickly test BSI, using the Batch Test Tool is a good way to go. Scenarios can be created and reused with as little as changing the check date.

- Mike Timm, Integrated Consulting Group
@MikeTimmSAP
mtimm@integratedcg.com

This does not replace end user testing, but it does expedite unit testing in development environments where data is typically sparse and out of date.

First, access the BSI TaxFactory GUI and then open the Test node:

The first step is to enter the basic pay-related data of the scenario:

The second step is to enter the specific tax data scenario to be reviewed. Here we are setting up Federal:

Our pay period wages are $1,000 with a married status and 2 exemptions. We save that information and add any additional tax authorities we want to test.

The final step is to select the Calculate button to generate the calculation based on the scenario we entered.

We can now review exactly how our scenarios will calculate taxes. If you set up the exact same data in SAP you’ll get the same result.  You can now save the scenario and use it at a later time by making small tweaks, such as check date.

Once you have your scenario created, it is as simple as selecting the Calculate button and you should receive output very quickly that displays the details you need to validate.

If you want a method to quickly test BSI, using the What If Tool provides an easy option. Scenarios can be created and reused with a little data change.

The next blog post will discuss the BSI TaxFactory Batch Test Tool, which is my preferred method of testing BSI due to the easy of copying SAP information and manipulation of that information.

- Mike Timm, Integrated Consulting Group
@MikeTimmSAP
mtimm@integratedcg.com