ORGANIZING SAP PAYROLL PROCESSING
How many programs does your organization run to pay your
employees? Depending on how many separate systems with which
you interface, the list could be quite long. There are programs
to drive the payroll, print the checks, create the bank file,
post the payroll, send payments to vendors to name a few.
With the introduction of SAP release 4.x came a new utility
called process models which order and organize
payroll processing. Visually, the process model is a flow
chart of the programs in your payroll process. Process models
can be created at least for regular payrolls, off-cycle payrolls,
reversals, check replacements and bonus payments. The user
initiates a process directly from the process model workbench
or through the off-cycle workbench. Once the process is started,
containers that carry necessary output from the previous program
as selection criteria for the subsequent program. For instance,
if running a regular payroll, the output container for the
pre-DME program would be the payment run date and payment
identification. This would also be the input container for
the check-printing program.
As the process is running, the user can see the status of
each program by how many personnel numbers are processed and
how many are incorrect. To prevent subsequent programs from
running before the results of the previous program are checked,
breakpoints can be sandwiched between the programs. Green
lights indicate the process is finished and there were no
errors. If a step does end in errors, they can be fixed and
the step restarted
PROCESS MODELS
With a quick background behind us, what are the niceties
of the process model?
|
Obvious from the nature of the
model, there is connectivity to the programs. Has
your payroll processor ever gone down the list of
steps to running the payroll and forgotten a step?
With process models there will not be a list of
to-dos since the programs are linked together in
the model. The process model is a to-do list in
itself. |
|
|
|
Also, there is increased automation
with the process model. Because the programs are
linked and the selection criteria are stored in
variants and containers, the step of manually getting
a variant and supplying the rest of the selection
criteria is eliminated. This also eliminates possible
errors in manually typing the selection criteria. |
|
|
|
Another time-saver is the availability
of the status for each step. Throughout the processing,
the status of the program can be checked for incorrect
personnel numbers and errors. It is obvious if there
is an error when the program is done running and
there is an icon other than a green light for that
program. With a right click on the step of the process,
the user can go to the specific spool or job related
to the program or the user can display the incorrect
personnel numbers related to the program. |
|
|
|
The process model also allows
parallel processing of appropriate steps. Since
certain programs can be run simultaneously, the
processing time will be reduced. |
|
|
|
Another key factor is processing
history. If running programs without the workbench,
the history of what is run can most closely be found
through the job log and the spool list. Although
this will contain what programs were run and their
output, it is not organized with respect to the
payroll process. The job log will contain any other
unrelated programs that the user has run and wont
group the programs by payroll area or process. There
is only an alphabetical list of jobs run for the
period of time specified. The process model will
list each step in a process and its status. It is
very conducive to determining where the payroll
processor is in the process. If the processor has
to unexpectedly leave for the day, her backup can
go directly to the workbench and identify where
she left off. |
|
|
|
Breakpoints were mentioned earlier.
Part of the breakpoint functionality is notification.
When the process reaches a breakpoint, specific
people can be notified automatically. Perhaps after
the programs for third party processing are finished,
accounting should be notified to run the accounts
payable payment run. |
|
Having just focused specifically on the process model workbench,
what is the big picture of payroll processing? Processes have
to start somewhere. As mentioned previously, the beginning
is different for payrolls for mass employees than for individual
processing. Processes for mass payrolls are initiated within
the workbench by creating a process that executes the steps
in a process model. When the processor is ready to actually
run the payroll, the process must be executed. Once executed,
a selection program appears where the processor enters at
least the payroll area and period. These are the initial selection
criteria that get passed to the first program. The selection
program will be different for different processes. A regular
payroll process model will use H99_Select_Pernr whereas a
special payment run model will use H99_Select_Pernr_Mass_Bonus.
The latter allows additional payment types (special, correction,
etc.) whereas the former only allows regular payroll runs.
Individual off-cycle runs are actually launched in the off-cycle
workbench. When a processor runs an off-cycle payment, reverses
a payment or replaces a payment, the off-cycle information
is stored in the table T52OCG. Then the follow-up program
RPUOCB00 (Subsequent Processes of Off-Cycle Activities) must
be run to get processes started in the process model workbench.
Off-cycle processing is organized by payroll area, period
and payment type. So regular off-cycle runs will be grouped
by payroll area and period. Special runs like correction and
special checks will be organized by payment type and date.
Replacement runs will be organized by payment run date and
identification. After the follow-up program is run, the off-cycle
processes will automatically start in the process model workbench.
CUSTOMIZING PROCESS MODELS FOR YOUR
ORGANIZATION
With the big picture in mind, how do you incorporate the
off-cycle workbench, subsequent processing and the process
model workbench into your payroll processing? There are two
key components to recognize: how the existing processing can
be restructured and improved and how the process models can
be created to meet and exceed the needs of the payroll department.
Here are some key questions to ask yourself and your payroll
department. Think of the answers to these questions within
the framework of improving your processing and incorporating
the payroll tools SAP delivers.
|
How many persons are available
and needed for processing payroll in the department?
Which payroll employees talents and abilities
are best suited for the different roles in processing
the payroll? In other words, what are your resources?
|
|
|
|
Where does the process begin
and end? For instance, are time and master data
entered in distributed centers? Is the main portion
of the payroll processed centrally? Are the checks
printed in different locations? Are the distributed
centers staffed deeply enough that someone can run
the off-cycle payrolls related to their employees?
Perhaps the distributed centers could run the off-cycles
and the main payroll could run the batch process
in the process model. |
|
|
|
How often do the checks and advices
need to be processed? Twice a day, once a day? Most
likely, the less times the batches of results have
to be processed, the more efficient the processing. |
|
|
|
What processing records are kept
currently? Is there a log of payrolls processed
and can it be revised to keep less detail? If a
processing log is kept, it could be reorganized
to model the steps in your processes. |
|
|
|
Which programs can be included
in the process model? SAP has designated many programs
that can be used in process models some lesser-used
ones may not be available for the process model.
Perhaps the benefit of having other programs in
a model outweighs the work to maintain a customer
version of the programs. |
|
|
|
How many processes are needed?
At a minimum, a different process will be needed
for regular mass payrolls, off-cycle payrolls and
replacement checks. Models can also be created for
mass bonus payments and voids if needed. |
|
Where should breakpoints be placed?
The most obvious place for breakpoints is to stop
the process before production runs occur so that
the results of the simulation can be reviewed. Are
there other strategic places where breakpoints can
be used? On the other hand, is it necessary to have
as many breakpoints as originally envisioned? |
|
Who should be notified at the
occurrence of breakpoints? |
|
How are you going to set up each
of the variants for the process models? One possible
scenario is to start the name of the variant with
the name of the model. |
|
What else can you ask yourself and the members of your department
which will lead to better organization? The needs of each
payroll department will differ according to its environment.
Spending some time pondering the answers to these questions
may allow you to incorporate the payroll processing tools
in your processing and improve the efficiency of the process.
Of course, there isnt one ideal plan the fits the needs
of all payroll organizations.
AVOIDING PROBLEMS
Although the process models can bring organization and efficiency,
there are some avoidable problems that may occur.
|
SAP delivers standard examples
of process models that can be copied and modified
to suit your payrolls needs. Be careful to
copy the SAP delivered model for the correct process.
Each model is connected to a selection program and
is assigned to a type of process (e.g. regular or
off-cycle). Double-check the attributes of the model
to ensure it is assigned to the correct selection
program and model type. If either of these is incorrect,
the process most likely will not start. |
|
|
|
As more processes are started
in the workbench, the time it takes to refresh the
list increases. Once processes are finished and
correct, they can be at least closed. A filter can
be applied to limit the number of processes viewed
in the workbench and reduce the refresh time. |
|
|
|
For some, the process model workbench
can be visually deterring especially if the model
contains many steps. Be sure to number the steps
to be visually logical within the workbench. Also,
use descriptive text to explain each step. If you
need to download or print the spool in a certain
step, include that in the text for the step. Perhaps
a step is Execute Posting. The text could be changed
to Execute Posting (D) to indicate that the file
should be downloaded. |
|
|
|
As mentioned previously, the
names of the variants must be customized and transported.
With some careful thought, the variant names can
be created to avoid having to create transports
at the last minute. For instance, it may be more
useful to have a separate variant name for each
combination of program and model rather than the
same variant for the same program across several
models. Then if you have to change the selection
criteria for a program related to two different
process models, you have the complexity to be able
to change the selection criteria for the program
related to a specific model. If the variant name
were the same for both models, the change to the
variant would affect both models. |
|
|
|
The process model workbench uses
elements of the SAP Workflow module. If you create
and execute a process and it never starts, check
whether the generic workflow user is unlocked. |
|
|
|
Lastly, if there is more than
one payroll processor, thought must be given to
the security for viewing jobs and spools. If one
person starts the process and another ends it, it
will be necessary for the second person to be able
to view the jobs and spools of the previous person. |
|
Upon review of your payroll organization, the payroll tools
can probably add efficiency and more order to the processing
of your payroll. Rather than simply connecting the existing
programs together in a process, use the tools to discover
ways to help your organization.
|
|