Wage types in General Are of THREE types:
1. Model Wagetypes - (Dialog Wagetypes, Primary Wagetypes, Customer Wagetypes).
These are the wagetypes which are defined based on the company requirement. They are the standard wagetypes defined by SAP and they start with a number like 1012, but customers have to copy these wagetypes to make there own wagetype. That copied wagetype will start with a letter.viz:M1234, MXXX. Examples of Primary Wagetype - Basic Pay, HRA, Additional Payments etc.
2. Secondary OR Technical Wagetypes. The system defines
there value AND these Wagetypes are not a Part of Employee Masterdata,
these starts with a slash (\).
We are implementing Version 4.0B at a company in Dubai, just 'across the way' from you. I have been working on payroll in South Africa since the beginning of 1998 and this is my first implementation on the new international version, without a country-specific payroll to use as a base. We have had some strange problems with odd HR policies and it has certainly added to the challenge of implementing payroll in the UAE. Our mandate here as consultants is to implement SAP standard, so we are extremely limited when it comes to ABAPs or any such thing. We have used features to the best of our knowledge to do what we can, but there are a number of validations that the users wish to do, but are limited because of the project management rules on the mandate. The ABAPs we have had approved are absolute necessities without which we would have only a half-baked implementation. I would like to if possible provide some solutions to the validation issues our client has.
I've heard through the SAP grapevine that one can use features to validate payroll master data for wage types. For example, the situation we have come across here is that the company would like to validate a number of different parts of master data for certain wage types that their employees do or don't get: For a wage type "Bachelor Allowance" (which refers to bachelor apartments - confusing!) they want to validate against the marital status of the employee. If he is single he gets X amount according to his grade, if he is married he gets Y amount according to his grade. So T510 alone is not enough. And the two wage types should be mutually exclusive, i.e. if he gets one, he can't have the other on an additional IT0014 record.
Another example is validating the employee's basic salary against a table like T510N. The problem being that T510N validates against ANNUAL salary not monthly and I cannot find anywhere in the system where one can set it to look at the amount field for the basic salary wage type rather than the annual salary field. Also this is the only table I can find that allows for validation against a range per wage type per grade (payscale group).
We are currently looking at user exits to try and make a plan, but that's a bit limited for the complexity of this issue.
If there are any features that you perhaps know of that can be adjusted to validate certain payroll master data against wage types, I would be glad of your advice.
Now I've rattled on enough, but I'd be happy to share ideas and our experiences on this side if there is any way I can help.
Iris Cunningham
CDE Middle East
-----Reply Message 2-----
Most of the work you are describing is outside of payroll.
Much of this can be done through the benefits module or using IT0014 or
IT0015. Some of these types of payments are just dynamically generated
wage
types that you will have to create based on the employee sub group
or other parameters that exist. For example, we have transportation allowance
based on where the employee lives and where he works. We will set up a
separate IT0006 subtype for these and then read them in payroll and then
make a decision on them. (We will also look at what other countries are
using and use them as a model
to support our needs.)
We have only seen T510N used successfully in the USA with the US payroll. The same for benefits. We have chosen to set our country code to the US because our corporate model follows the USA patterns for payroll the closest. We still will have to write a lot of PCRs, etc.
Without writing a user exit we don't know how to use table t510n, except on an annual basis. We have tried to use it on a monthly basis also.
We have written SAP about that and they said we were the only other company outside of the USA that wanted that. Now, of course, you could let them know your problems, too. (SAP will deny that we asked them about this, unless you are very clear with them, that others are really interested in using this functionality.)
We want to run payrolls with 4 currencies. And SAP has problems with that also. Watch out for fake FX gains and losses.
We are now working with 4.5A.
We are going to have quite a few dynamically generated wage types, because of which employee group or subgroup or personnel area or sub area an employee is in. (These will not appear in any IT).
Philip L. Steers, III; CPA
HR/FI Team
Saudi Aramco
-----End of Reply Message-----
