Tuesday, July 24
Friday, July 20
Friday, July 13
- ECM was designed in the aspect being an MSS utilize functionality. Through MSS, there are several checks and balances the system goes through. However, this does not exist via PA30 if these records were to be created in the backend. For example, via PA30, you can still create, approve, and activate an employee for a particular plan he/she is NOT eligible for. Through MSS, this employee would've been grey out and not allowing the manager to proceed with the planning process of it. Please refer to OSS Note 879720 for further details
- By default, in MSS the manager can plan for his/her employees in currency he/she wishes. However, when activiation occurs, it will do currency conversion automatically and post in their local currency. To override this factor you would need to remove the flag in T77S0 table at switch HRECM XEECU. Please refer to OSS note 891609 for further details
- Complensation Planning iview shows ineligible employees. According to SAP, this is a per designed functionality. The purpose is to illustrate his/her entire employees population. Please refer to OSS note 919298
- Out of the box functionality, planning manager can in fact approve his/her plan they had submitted. A lot of this issue is due to the lack of workflow functionality for ECM delivered with mySAP ERP 2004. Please refer to OSS note 802992. You can also look at these post available on SDN (HERE #1 , HERE #2, HERE #3)
- ECM uses the currency exchange rate type "M" in TCURR table. This exchange rate is hard coded in the standard function modules used by ECM. Function module is "HR_ECM_CONVERT_CURRENCY"
If you are planning to customize ECM through BADIs to enhance how the program determine things, you could look into one of these many available BADIs from SAP
- HRECM00_ACTIVATION - Replace activation procedure or new infotype determination
- HRECM00_BDG0001 - EC budgeting
- HRECM00_CACLBASE - Replace determination of calculation base salary
- HRECM00_CARGP - Replace evaluation of compensation area
- HRECM00_CP1GP - Replace evaluation of first compensation program grouping
- HRECM00_CP2GP - Replace evaluation of second compensation program grouping
- HRECM00_EFFDATE - Replace increase or award effective date
- HRECM00_ELIGIBILITY - Replace or extend eligibility check
- HRECM00_ELIGP - Replace evaluation of eligibility group
- HRECM00_GDEGP - Replace evaluation of guideline grouping
- HRECM00_GUIDELINE - Replace or extend guideline evaluation
- HRECM00_MATRIX_SEGM - Define axis for matrix guideline
- HRECM00_SALARY - Replace evaluation of salary and salary-related quantities
Thursday, July 5
During an SAP implementation, conversion program will occur to load OM and PA data separatedly as their own infotypes / objects. But there is a missing connection between OM / PA through relationships and other tables that might not get loaded via conversion. With that, we have several RHINTE programs to assist in this matter. You can access it via SE38 transaction code.
- RHINTE00 - Transfer PA Records To PD Positions. In another world, it creates the HRP1001 between P to S in the OM side of the world. When you view a record via IT0001, you see this person holds the position, however via HRP1001, that relationship isn't so.
- RHINTE10 - Generates the required relevant tables. (T513 - Jobs, T513S - Jobs, T528B - Positions, T528T - Work Center, T527X - Org Unit
- RHINTE20 - checks for all objects for integration between PA and OM. This is a big one and will take awhile to run. What it does is look at table T513/T513T - Jobs, T528/T528T - Position, and T528X - Org Unit. It will then compare it against the HRPxxxx table to find missing objects. If there are any missing objects, it will create the record.
- RHINTE30 - Transfer OM to PA. This will create infotype 0001. If the conversion strategy is to have SAP auto inherit factor to kick in for IT0001, often time jobs and org unit are missing via IT0001 during the inital conversion load. RHINTE30 will find the relationship and push it through IT0001.
You can also execute RHINTECHECK program to check for any issue on the integration side.
Usually the rule of thumbs on conversion is that you use DTT, LMSW, or even custom ABAP program to load P0000, P0001, and P0002. Once those are done, you run RHINTE00 to establish the P-S relationship on the OM side from information you've load via P0001. You then would run and RHINTE10 to establish the text table on the PA side for positions, org unit, and jobs. You are correct that text are stored in HRP1000, however that is where OM stores the information. PA has a few text tables storing the same information for PA usage. RHINTE10 will handle that. At the end of the process you would run RHINTE30. What this would do is re-create P0001, this time allowing standard SAP integration functionality to default in the org unit and job into the field. Since you did RHINTE00 earlier, you've established P to S relationship on the OM side. Not SAP knows where to find the O and C.
Of course the process above is only showing one point of view and scenario. Different implementation will have different flavor of how conversion occurs. You would have to test it out and do trial and error on finding the best solution for you.
Read the help files for further details and also explore what other possibility you can use this for outside of implementation (i.e.: Pos Go-Live situation as in Production Support)
Tuesday, July 3
Until recently when SAP introduce Management Global Employees (MGE) / Concurrent Employment (CE) functionality, all of that went down the tube. If you had installed the Best Practice Client w/ client 000 stuff, you should be safe with what is delivered. But with those who did not, you are into a big surprise.
You will need to maintain ENTRY feature as you normally would, but in addition need to maintain a whole new node of configuration in the IMG
IMG -> Personnel Management -> Personnel Administration -> Evaluation Basis -> Calculation of Employment Period
This entire nodes needs to be maintain. If you have a best practice client setup, the best practice setting will be enough for most implementation to work against. Enterprise Compensation Management module which uses senority setting in their guidelines will be able to leverage it as well.
Took me awhile to figure this out!
Have Fun w/ researching it.
Friday, June 1
In the program, send data from PME01 to the ZPM01 structure. You will need it for the decision tree in ZPM01 later. What you don't have in PME01 is the job function. This is where you use the read infotype function module, look up the job function code and pass it back to the ZPM01 structure.
At the every end after you finishes with looking up data, send the ZPM01 structure to the HR_FEATURE_BACKFIELD function module for it to handle it's own duties of going through the feature ZTARI and send you back the return value.
Play around with this method and you can see the flexibility of it is fairly nice. What other methods have you come across, feel free to share it!
Thursday, April 19
SAP standard delivered Total Compensation Statement (TCS) is different from the Compensation Review Statement (CRS). The Compensation Review Statement was ment to act like similar to a merit slip, showing your employee his/her recent performance merit increases, bonuses, and stock option awards. It is only available via ECC transaction, so would need to be printed by HR or someone with ECC access on the behalf of the employee. The Total Compensation Statement, on the other hand, are available in both ESS, MSS, and ECC. The employee could log directly into his/her ESS and view his/her Total Compensation Statement at any given time.
What you need to do first if do the standard configuration for TCS. Define your category and sub category in the IMG configuration "Determine Structure of Total Compensation Statement".
Don't configure the "Select Wage Types For Pay Categories" yet, this is restricted to one category. It is program to hard code in the category "PAY". In the event you define your own category, you might define more than one. You need to make a copy of that table and add a Category field.
Now we are ready to use the BADI! The BADI structure will import in several key fields you need to make use of.
Using the CATEG and SUBCATEG_TAB, have it look up the "Z" table you've copied earlier. It will link to a list of wage types you've configured should be tally up for that sub category.
Tuesday, March 27
Monday, March 19
To enable it or disable it, start by clicking on this icon on the menu bar.
Click on "OPTIONS" and then go to the "EXPERT" tab. There is a checkbox, as illustrated below. This control the keys showing in transaction dropdown.
Tuesday, February 20
This trick was shown to me by Narendran on the SAP SDN Forum. All credit goes to him on this one. One method of allowing the user to maintain a table is to attach a transaction code to it. For example, you have the need to maintain table V_T510W.
First you will need to go to transaction SE93 to create the new customized transaction. Give it a name and short description. Be sure to select "Transaction With Parameters (Parameters Transaction)".
Click on the green check to continue to the next screen.
Under the "Default Values For" section area, you have two pieces you need to focus on. Next to the "Transaction" field, type in the transaction "SM31". Right below it, check the box next to "Skip Initial Screen".
What you've just done there, was basically tell the program to use SM31 to maintain the table structure, but skip the initial screen where the user had a choice to enter in the type he/she wants to maintain. In the next steps, we will enforce what table they will be maintaining for this transaction.
Towards the bottom of this same screen, you have a section called "Default Values". In the left side, under "Name Of Screen Field", select "VIEWNAME" via the drop down button. To the right of it, you have a column called "Values". Type in the table you wish to maintain, in our example, we will type in "V_T510W". On the next line, selection "UPDATE", as we want this to be a maintain transaction. If we want it to be a display transaction, we would choose "DISPLAY". To the right under the "Values" column, put an "x" as the value for it.
These are the basic values you need to create a transaction code and link it to a table for you to maintain w/o having to give out access to transaction SM30/SM31 where the user might be able to enter in any tables they wishes.
Give it a shot and let me know via the comments what you think.
Friday, January 26
The installation number could be found from SAP GUI. Inside SAP, click on system and status.
Wednesday, January 17
Sample Program Screen: