E-Recruiting - Recruiter URL works for one user and doesn't for another

Question

Hi
I am new to e-Recruiting, so any help will be greatly appreciated.
We are in the process of configuring the SAP e-recruiting module on  an existing HCM system.  It is only a demo system. 
We started off with the IDES, with SAP sample data.
We activated the BSPs via SICF.
We generated the BSP URLs via program rcf_generate_urls.
We picked two existing employees (PERNRS) in the system and linked test IDs (USERID1, USERID2) to them in infotype 105.  Both USERID1 and USERID2 have BASIS/Superuser authorizations.
When USERID1 runs the recruiter startpage it displays the page correctly.  Pernr of USERID1 has a Candidate(NA Object) linked to it's CP object.
When USERID2 runs the recruiter start page it gives an internal error.  This Id's pernr does not have a candidate object. 
Should there be a NA object for every CP object?  Does any one have some business process guides that may help us understand the relationships between the objects?
Please advise.
Thank you
Amina

Answer 1

Hello Amina,
not everyone should have a candidate (NA) object, every one MUST have a candidate object. No matter which role someone plays within the e-recruiting system (recruiter, manager, admin, internal candidate, external candidate, talent manager, ...) he needs a candidate to work with the system.
Assuming you have an ERP2005 (= E-Recruiting 600) you can use report RCF_USER_CREATE to create users for test purposes. For the productive environment you have to set up HR -> E-recruiting integration and can run HRALXSYNC to create candidates for existing employees.
I am not sure how much business process documentation there is in sap help. I have to admit I prefere learning from the system. Perhaps a very rough overview:
e-rec brings the following objects:
NA - Candidate
NB - Requisition / Application Group
NC - Posting
ND - Application
NE - Candidacy
NF - Talent Group
furthermore e-recruting uses some additional objects from the hr base and other components (P Employee, CP Central Person, US User, BP Business Partner, O OrgUnit, S Position, QK qualification group, Q qualification, VA/VB/VC Questionaire and its elements)
NA - The candidate is the central representation of everyone in e-recruiting. A Candidate is always linked to a CP which is linked to a BP and a US. If the person is an employee the CP is linked to the P object, too. (Hint: for integrated systems the user for an employee is not linked in HRP1001 but retrieved from IT0105 directly, e-recruiting uses a standard function of HR here, the hr function modules for reading object releations virtualize this assingment as hrp1001 relation).
NB - The NB object has currently 3 slightly different tasks. As requisition it is the internal view for an internal/external hiring request, it defines what you are looking for e.g. "ABAP programer, 40 hours/week, place of work London, ..". As application group it allows to accept applications for "areas" where you have currently no exact position to hire but regularely look for canditates. Application groups channalize unsolicited applications e.g. Interns, Engineers. Third usage is the requisition for succession planning - not really important.
NC - Posting is supposed to be the outside view. It contains the texts for the requisition published in the different channels. as you might to use a different text for the different media a requisition can have several postings. A posting has one or more posting instances / publications. They are not an hr object type, they define the channel with publication duration and language where you publish your posting.
ND - The application can be compared with the hardcover application. If a candidate applies he creates an application. The application is linked to the candidate of course and as the candidate applies through a certain channel the application is linked to the posting.
NE - The candidacy is the assignment to a requisition. You could say it is the task / intention to check a candidate for the requisition so it is linked to the requisition and the candidate. As the candidate applies for the job described by the requisition (application group are treated the same here) an application is always linked to at least one candidacy. If a recruiter decides based on the candidates profile that he is interesting for another open positions he can add more candidacies to the application to check the candidate for these requisitions. There is also the posibilit that you create a candidacy w/o application. Every external who applied and every employee is in the system even if he has no active application. External candidates can even register to the system w/o applying. You can check this pool for suitable candidate an assign them to a requisition. This is a candidacy w/ an application. You can later request a candidate to apply to this requisition but it is theoretical possible to process the complete hiring just with a candidacy.
NF The Talent group is used to structure the huge amount of candidates in the pool. E.g. you can form a talent group "High Potentials - Design Engineers". You can use these groups to easier find suitable known candidates if a matching requisition is opened. But they are also needed for pool development. For short applicant groups you can track them and try to stick with your company till you get the right opening for them.
The other object are linked to this core. Qualifications are linked to requisitions as requirement and linked to candidates of course. OrgUnits and Positions can be linked to requisitions to link to OM. Questionaires are assigned to candidates at all for general appraisal or to candidacies to appraise the suitability for the requisition or to track interview, assessment results.
There ore other "objects" in e-recruiting which are not represented by an OTYPE. One example is mentioned above the publication. Others are recruiting team and recruiting plan. If you need information to one of these just post another reply.
Hope that gives some basic overview about the objects.
Best Regards
Roman Weise