May 22, 2012 -- 11:27AM, M.S. Hein wrote:

Hi, Sven. I have a question.

Which tables are especially affected by local changes, and what naming conventions

and other best practices should we implement?

I forgot to mention T030 (payroll and expense posting). High risk in particular as the whole thing is transported every time, not just lines changed. Easier to get proper naming conventions in Payroll, if you use feature PPMOD sensibly. But in expenses you don't have this, so you may need naming conventions in symbolic accounts.

In any case: when several projects are going on, do not transport without checking with others. It is easy for one group starting later, but going through QA faster and then getting stabbed from behind by the secodn group. Central control for T030 is adviseable.

Maybe a final note from me:

Wagetypes are often considered 100% local, because they are payroll.

However, requirements fro global reporting as well as posting guidelines from group accounting are likely to come in. Tese should not determien your wagetypes, but you should make sure that your wagetype catalogue has the right granularity to provide an appropriate mapping afterwards. Extreme example: if local legislation allows you to use one wagetype for all gross salary elements, it may still be wise to distinguish a bit more as group reporting may ask for seperate numbers on base salary, overtime, etc.

still 4 min to go. A quick question left? Maybe Anna?

A big thank you for all who joined and contributed with their questions. Drop by, if you are in Milan! Or drop a line on sr@iprocon.com

And: apologies for the typos…

May 22, 2012 -- 11:02AM, Sven Ringling wrote:

May 15, 2012 -- 5:40AM, Pushhpa Maiwar wrote:

hi

We have implemented E recruitment for one company in a Cloud environment and now we have to roll E Rec module for other locations like USA, UK etc.

Please help me in knowing that How can we handle the external candidate scenario for various countries differently where in an external candidate wants to register his job profile in the portal. For example an external candidate from India has to provide his gender, marital status and date of birth  whereas contrary to this an external candidate from USA need not to be asked to provide the Gender , Date of Birth etc.

How the system understands that a candidate is from USA and a different portal screen  need to be prompted where the DOB, Gender fields are hidden ( Maintain profile ) or if a candidate is from India then screen while maintaining prole should prompt fields like Date Of Birth, Gender should be visible????

How can we handle this in a multitenancy environment??

Secondly education types in E Rec gets stored in one table for all countries. How can we filter these education types based on different countries in frontend ( portal ) in a global roll out scenrio??

 

Starting with your 2nd question:

Education types are by nature a global field, because candidates applying for a role in one country may have a degree from any country in the world. It is good practise to add a few more generic types where candidates with more ‘exotic’ degrees can find a choice that’s close enough to what they’ve done – otherwise it is almost impossible to cover them all.

(On a personal note: as someone from a country, which hasn’t used Master and Bachelor until recently, I found it very frustrating to apply in other countries, where companies didn’t think about education types overseas candidates might bring)

Thanks Sven. Logically you are correct about the Education types config and  you have mentioned a very valid point to make client  undertsand about the logic as to "why SAP has chosen this way of Education types config"  but sometimes clients are difficult.

Apologies for delayed response .