Qualifications Forms vs. Documents of Record page

Recently, I got asked this question about where employee qualifications should be captured? The context was that the client wanted to move to Documents of Record for all attachments. So I made a note of considerations:

#	Feature	Qualifications Screen	Documents of Record Page
1.	Primary Focus	Emphasis is on capturing details of Education. While documents can be attached to this screen, that focus is secondary	Emphasis is on capturing and managing documents. Capturing of Educational details such as subjects, etc. is secondary.
2.	Ease of navigation	In ESS & MSS, a separate link called “Qualifications” is available under “Performance Management & Career Development” parent link.	A link to a copy of Documents of Record page can be provided under “Performance Management & Career Development. However, when employee clicks on this link to enter Qualification information, employee will also be able to see information entered for other documents, such as Passports, Visas, etc.
3.	Field Names	Names of fields are “suited to purpose”. E.g. Ø  Start Date Ø  Awarded Date Ø  Awarding Body, etc.	Names of fields are standard* for all types of documents. E.g. Ø  Valid From Ø  Issued Date Ø  Issued By, etc. *Note – In case a copy of Documents of Record page is created, the fields can be renamed in that copy of the page to be more “suited for purpose”.
4.	Field availability	Qualifications screen has area to capture individual Subjects studied and also capture “Majors” information. Unlimited number of subjects can be listed on this screen in individual rows.	Documents of Record screen does not have native fields to capture subjects. While these fields can be configured as part of DFF, there is a limitation to the number of segments available in this DFF.
5.	Compliance	When entered through SSHR, Education documents are stored on the People screen with no reporting capability (and therefore very little control over compliance). Also, employee does not have access to these documents through SSHR.	Documents are stored against suitable categories (such as Qualification Information) and compliance information is readily available through building simple custom Discoverer reports. Employee and Manager also have ready access to these documents through Self-Service.
6.	Supervisor verification of docs	Native – Supervisor “approves” the Qualifications transaction only after “Sighting” the document. However, Supervisor will not be able to change the value of the “Status” field to “Sighted” using MSS – this field will be blank for records created via MSS.	Native – Supervisor “verifies” a document, rather than approving it. A verified document indicates that the document is sighted.
7.	iRecruitment	Qualification Types are ranked, which helps in quickly filtereing out suitable candidates in iRecruitment module. Also, when an applicant enters his qualification details via iRecruitment, this information gets stored on the Qualifications screen and gets carried over when Applicant is made an Employee.
8.	Security	Security can be controlled by correctly defining Menus and Responsibilities.	Security is easily switched on or off by responsibility. E.g. - You could potentially have two categories under Qualifications – 1) Education 2) Professional Certification. Access to these two categories can be easily limited to two different teams who can then manage only those records entered under the category they have access to.

Spell check in self service pages

As Oracle Applications is moving browser based OA Pages, the need and ability to spell check as you type is on the rise. Here is a simple workaround to achieve spell check (useful, for example, when entering data in iRecruitment or Talent Management / Performance Management modules)

For Internet Explorer:
1) An add-on called ieSpell does the job. ieSpell is a free Internet Explorer browser extension that spell-checks text-input boxes on a Web page. User can highlight a text and spell check by using Tools => ieSpell. Notice that ieSpell is subject to licensing for corporate users.
2) Installing the Google toolbar will also provides spell check functionality.

For Mozilla Firefox:
This includes a spellchecker tool by default. This tool will check spelling as you type. To enable spell check in Mozilla Firefox, go to Tools -> Options. Choose the Advanced Tab and highlight the General sub tab. Check the check box for 'Check my spelling as I type'.

Reference - Metalink Note ID 454126.1

Competence Requirements

Question: Is it possible to define “Competence Requirements” based on a Job-Org combination? What is the hierarchy of precedence if a competence gets defined at an org, and then again at a job, but at different competence requirement levels?

Response: It is NOT possible to define competency requirements for a combination. Having said this, a position inherits competence requirements from the Organization as well as Job that it is attached to. It is not possible to delete such inherited competencies from the position. Since position inherits from both levels, there is a possibility that the same competence will repeat with different proficiency levels and different “essential/ desirable” flag.

In the Competence Requirements screen, competencies can be defined at 4 levels:

Ø  Business Group: Competencies defined at this level are called "Core Competencies".

Ø  Organization

Ø  Job: Job Competencies can be added by clicking the "Add Job Competencies" button during appraisal process.

Ø  Position

You can identify the competencies that workers in an organization or holders of jobs or positions must possess. When you use the Suitability Matching function or advertise a vacancy, the application can compare worker competencies with the competency requirements for an organization, job, or position to find suitable candidates.

Follow on Question: Let’s say that a particular competency "Problem Solving Skills" is listed as a competency requirement at all three levels - Organization "O", Job "J" as well as Position "P", but at different proficiency levels. Now, when running (say) the report "Find Suitable Work Opportunities: Work Opportunities" from Suitability matching, if you add these three O, J and P and click find, against what levels will the application compare the worker competencies to determine whether or not there is a match?

Response: This is determined by rules of precedence. So “P” has highest precedence, followed by J, and finally O. This means, if you have entered all three on the search page, the application will only return matches with P, even if there are no competence requirements defined at P (however, note that a Position will inherit competence from Job as well as Organization). If you have entered J and O, then application will return matches with J. If you have entered only O, then obviously, application will return matches with O.

Looking forward to EBS R12.2

Update:
On Sep 20th 2013 Oracle announced that Oracle E-Business Suite Release 12.2 is now generally available. Oracle E-Business Suite Release 12.2 includes new product functionality, new Fusion Middleware and database components, and introduces new tools for installing, configuring, and maintaining E-Business Suite environments.

************************************
I recently wrote an article for POIT Support news letter, which you can find here.

I have also reproduced this article below, for quick reference.

The general availability of the next release of Oracle Applications E-business Suite, Release 12.2, is on the horizon. Here is a quick summary of the some key changes and new features across HCM modules that will be part of this release:

From the HCM Applications perspective:

• Payroll: Enhanced Retropay is the only option available in 12.2. Retro by element, Aggregate & Run will no longer be supported.
• Payroll: A new self-service based interface will allow payroll administrators to enter element entries for multiple employees at a time. This transaction can be configured for approvals.
• OTL: A new Projects Layout is available for Actual Costing, which allows to process project labor transactions from actual payroll costs in addition to existing standard costing basis.
• CWB: The Compensation Workbench Backout Postprocess meant that all changes done in CWB are also backed out. This includes budget allocations, awards, as well as worksheet submission and approvals. A new feature being introduced in R12.2 provides the flexibility to backout only the updates to employee records, while allowing updates made through CWB to remain intact.
• iRecruitment: A new multi-location vacancy feature allows to associate multiple locations when creating a vacancy, rather than creating a separate vacancy for each location. With this feature, candidates will be able to search for jobs based on any of the locations identified for the vacancy.

For more features, please see the RCD (Release Content Document) available via “My Oracle Support (search for note ID - 1302189.1)

From a technology stack perspective, the two key changes are:

• OC4J will be replaced with WebLogic Server 11g, which is part of Fusion Middleware 11g
• Patches can be applied while the EBS production instance is operational, with only a short downtime required to complete the patching process. This is achieved through Edition-Based Redefinition feature available in 11gR2 Database. This online patching feature is targeted at maximising production uptime.

There were some concerns raised by customers about whether Oracle Reports will go away in R12.2. This is not true - Oracle Reports are a part of R12.2 technology stack. Also, this release will continue to use Oracle Forms 10g and OAF (Oracle Applications Framework). Thus, the newer Oracle ADF technology will not come until after R12.2 is in the market.

What can you do now to prepare for an eventual upgrade to R12.2? Well, for one, we recommend that you be on the latest release R12.1.3. Upgrading to R12.2 from R12.1.3 is a relative small effort. You can also ensure that your Application is running on 11gR2 database. Please contact the Presence of IT Support Centre for further information or assistance.

********************************
Should you require further information, please reference the E-Business 12.2 Product Information page located via MOS note below:
•        EBS 12.2 Product Information Center (Note 1581299.1)

Considerations for Multi country implementation of Oracle Apps

Best-practice framework in a multi-legislation, multi business group environment:

Below are a sample of our considerations and best practices while implementing Oracle Applications in a multi-national Company with employees across the globe:

1)      Understand business vision: Structured analysis of the current business operations and future growth plans.

2)      Finalize Organizational Modelling: Driven from the vision, plan for number of business groups, legal entities and set of books to be implemented. The best practice is that if there are multiple companies operating as different entities in the same country, their representation in Oracle should be as different Legal Entities within a single business group. Some of the other considerations which help in in making a decision on the number of business groups include:

a.      How many countries does the business operate in?

b.      How many of these countries have Oracle provided legislation?

c.       For countries for which Oracle does not deliver a legislative pack, how many employees does the business currently have and what are the future growth plans in these countries?

d.      Can one single business group be used for employees across multiple countries, each having a small number of employees? (Each additional business group represents additional maintenance costs over the lifecycle of the application)

e.       Are external payroll providers being used in any of the countries? If yes, what data needs to be provided to them to process payroll?

f.        Are there any specific legislative needs (in terms of reporting or privacy) for each country?, etc.

3)      KFF and DFF design: KFF (or Key Flexfield) is used to capture key company information, such as how are jobs and positions represented across the company. While each country may have differing requirements, it is important to consider global consolidated reporting requirements, which typically needs uniformity across countries. A typical approach to address global as well as local concerns is to have common global fields across all countries, followed by a flexible number of local or country specific fields. A similar consideration needs to be adopted for DFFs (Descriptive Flexfields), through defining appropriate “DFF contexts”.

4)      Instance strategy: How many instances should be deployed for Production? Whilst often overlooked in initial design, this is a key operational decision to make. While one instance is obviously the best strategy, there may be practical reasons for going for multiple production instances. This is mainly driven by how business-critical the application is, and how much regular maintenance downtime can be accommodated.

5)      Employee numbering: Should employee numbering be Global or local? Global numbering would mean that there are gaps in the sequence of any specific country. Local numbering would mean a repetition of employee numbers across countries. An alternate best practice approach to this scenario would be to use “unique” local numbering.

6)      Design Security: Understand who in the business would need access to which part of employee data and also to what population of employees. Data privacy laws are very different between countries and this drives the data security design. Also, current and future business processes should be analysed to understand whether data is maintained locally by each business unit or by shared services. The best practice to adopt here is the shared-services approach, which recommends centralization of resources for better operational efficiencies.

7)      Reporting: At the minimum, each country where the company operates as a registered business needs mandated legislative reporting. Rather than building a separate report for each country, a good practice is to analyse and group similar reports across countries. Next, build “master” database views that include all columns needed to produce all related reports across countries. Through use of XML Publisher templates or Discoverer Reports, each country can then easily customize the output from these views to consider only relevant columns for the country. This practice reduces maintenance and gives more flexibility in the hands of businesses to drive the format of report presentation.

Documents of Record vs. Save Attachment

In its release 12.1, Oracle has come out with a new feature to save attachments that are uploaded while submitting a transaction. This is achieved by enabling the "Save Attachment" checkbox on the review page via personalization. However, the Documents of Record (DOR) functionality overlaps to an extent with this "Save Attachments" functionality. What are the considerations in deciding which of these should be used? Read on for the points to be considered:

Feature	Save Attachment	Documents of Record (DOR)
Definition	Allows documents to be attached to Self Service Transactions. These attachments are visible during transaction approval.	DOR is independent functionality to capture documents as attachments, along with information associated with the document, such as date of issue or expiry, etc., and up to 20 additional customer defined fields per document type.
Enabled for	Absence, Qualification, SIT, Hire, Transfer, Personal Information, Competency, Worker Status Change, Pay Change, Termination, etc. Depending on the transaction type, the attachment is stored on different Core HR screens.	Seeded document types (provided by Oracle) are: Birth Certificate, Death Certificate, Degree Certificate, Driving License, ID Card, Medical Certificate, Passport, Visa, Residence Permit, Training Certificate, Work Permit. You can choose any of these or define a further unlimited number of document types to capture pertinent information
Attachment Creation	Attachment is created with the transaction that the attachment supports. E.g. Absence, Qualification, etc.	Attachment creation is independent of the transaction. E.g. Passport, Visa, etc.
Security	Same as Transaction security; i.e. employee having access to the transaction also has access to attachment.	What documents are visible can be controlled at a responsibility level.
Verification	Attachment is deemed verified when transaction is approved.	Verification status is separately tracked. Once document is submitted, it needs to be explicitely verified by Manager or HR Dept
Trace Back	Once transaction is approved, attachments are stored on Core HR screens and lose context with the transaction. Employee or Manager then cannot view such attachments.	As long as the documents are visible to their responsibility, employee or manager will be able to view the documents, even after the documents have been "verified"
Reporting	Not possible, or at best, a rudimentary reporting	Through "Search Documents of Record" function available to HR personnel, it is relatively easier to search for documents (say) expiring soon. Also, since DOR requires a number of fields to be captured along with the attachment, custom reports can later be built to pull out meaningful information