Tuesday, 22 May 2018

Fusion HCM Roles

Role:
A role is some kind of privilege that you can assign to the user allowing them to perform certain type actions in the application.

Role-Based Access Control

Role-based security in Oracle Fusion Applications controls who can do what on which data.

Role Types: 

Oracle Human Capital Management Cloud (Oracle HCM Cloud) defines five types of roles:

Data roles

Abstract roles

Job roles

Aggregate privileges

Duty roles

Data Roles
Data roles combine a worker's job and the data that users with the job must access. For example, the HCM data role Country Human Resource Specialist combines a job (human resource specialist) with a data scope (country). You define the data scope of a data role in one or more HCM security profiles. HCM data roles aren't part of the security reference implementation. You define all HCM data roles locally and assign them directly to users.

Abstract Roles

Abstract roles represent a worker's role in the enterprise independently of the job that you hire the worker to do. Three abstract roles are predefined in Oracle HCM Cloud:

Employee

Contingent Worker

Line Manager

You can also create abstract roles. All workers are likely to have at least one abstract role. Their abstract roles enable users to access standard functions, such as managing their own information and searching the worker directory. You assign abstract roles directly to users.

Job Roles
Job roles represent the job that you hire a worker to perform. Human Resource Analyst and Payroll Manager are examples of predefined job roles. You can also create job roles. Typically, you include job roles in data roles and assign those data roles to users. The IT Security Manager and Application Implementation Consultant predefined job roles are exceptions to this general rule because they're not considered HCM job roles. Also, you don't define their data scope in HCM security profiles.

Aggregate Privileges

Aggregate privileges combine the functional privilege for an individual task or duty with the relevant data security policies. The functional privileges that aggregate privileges provide may grant access to task flows, application pages, work areas, reports, batch programs, and so on. Job and abstract roles inherit aggregate privileges directly. Aggregate privileges don't inherit other roles. All aggregate privileges are predefined and you can't edit them. Although you can't create aggregate privileges, you can include the predefined aggregate privileges in custom job and abstract roles. You don't assign aggregate privileges directly to users.

Duty Roles
Each predefined duty role represents a logical grouping of privileges that you may want to copy and edit. Duty roles differ from aggregate privileges as follows:

They include multiple function security privileges.

They can inherit aggregate privileges and other duty roles.

You can create duty roles.

Job and abstract roles may inherit duty roles either directly or indirectly. You can include predefined and custom duty roles in custom job and abstract roles. You don't assign duty roles directly to users.


Written By: Duggireddy Narendra

Saturday, 2 December 2017

FUSION HCM : NEW FEATURES IN FUSION HCM R13

NEW FEATURES IN FUSION HCM R13
HCM Common Features Secure Access to Position Records Using Areas of Responsibility or the HCM Position Hierarchy

Anytime Feedback
Applications Security Database Resource Perspective of Data Security Policies

Enhanced Role Comparison
Global Human Resources : Improved Self-Service Contact Effective Dates

Define Employee Assignment Hours

Add Eligible Jobs for a Worker Assignment

Statutory Dependent Field for Contacts

Convert Button Replaced with Actions Menu on the Pending Workers Tab

Option to Indicate Inclusion of Pending Worker in Automatic Conversion

Automatic Conversion of Pending Workers Using a Scheduled Process

Change Legal Employer Guided Process

Two Tier - Multiple Contract - Single Assignment Employment Model

Add Contracts for Contingent Workers

Read-Only Contract Region in Promote and Transfer Processes

Manage Worker Unions

Manage Collective Agreements

Seniority Dates Enhancements

Ability to Add Multiple National Identifiers for the Same Type for the Same Country

Synchronization of Assignment Flexfields from Position Flexfields

Synchronization of Line Manager Based on HCM Position Hierarchy

Create Document Records for Future Hires

Ability to Cancel Work Relationship of Pending Workers

Pending Worker Work Relationships for Persons Existing in Oracle Fusion HCM

HCM Position Hierarchy

HCM Position Hierarchy Support in My Team Page
Time and Labor : Increased Time Management Efficiency

Group Membership Evaluation Enhancements

Manager Time Card Layout Introduction

Time Card Approval Enhancements

Enhanced Overtime Calculation

Overtime Period Introduction

Expanded Integration

Unit of Measure Enhancement

Time Allocation Introduction

Scheduling

Third-Party Scheduling Integration Introduction
Talent Management : Email Notifications Based on Reports
Career Development Add Development Goal Action in the Person Smart Navigation Window

Update Career and Work Preferences in Career Development

New Security Privileges for Securing Career Developement

User Access to a Worker Development Plan on the Person Spotlight Page

User Access to the Person Spotlight Page of Colleagues

Application Context Passing to Embedded Reports

Increased Size of Success Criteria and Comments Fields of the Goal Object
Profile Management: Person Profile Security Enhancements

Profiles Search Page Enhancements
Talent Review Deep Link Support

Duplicate Talent Review Meeting Configuration

Meeting ID Parameter Support
Succession Management Succession Plan Descriptive Flexfield Support

Succession Plan Filtering

Consume Profiles Security

Notes Component

Person Spotlight in Talent Review

Succession Planning Name Change on Employment Card
Goal Management Submit Goal Plans for Approvals Without the Preview Step

Goal Plan Set Assignment Algorithm Changes

Extended Set of Person Search Fields in Administrative Tools

Development Goals in the Performance Document

Goal Weights Update from Goal Management to Performance Document

Add Performance Goal Action in the Person Smart Navigation Window

Increased Size of Success Criteria and Comments Fields of the Goal Object

Application Context Passing to Embedded Reports

Selection of a Worker Goal Plan in the Organization Goal Assignment

Enable Inclusion into Performance Document No Longer Available

Profile Option to Restrict Entry of Decimals for Goal Weights

Productivity Enhancements for Administrative Users

Administer Goals Task Enhancements

Manage Goal Plans Task Enhancements

Manage Goal Plan Sets Task Enhancements

Mass Assign Goals Task Enhancements
Performance Management New Notifications for Share Action in Task to Set Goals

Update in Use Performance Templates

Add Participant Process Simplification

Auto-Submit Approval Tasks

Control Edits to Manager Evaluations when Submitted

Anytime Document

Feedback in Performance Documents

Populate Model Profile Competency Weights in Performance Documents
Learning and Development Offline Learning on Your Mobile Device

Manage Learning Catalog for Courses and Classes

E-Learning with Support for SCORM 1.2 and 2004

Managing Learning Assignments and Track Completions

Contextual Learning
HCM Data Loader : Ability to Load Multiple Owners for a Bank Account

Extract Integration and User Key Values

Test HCM Data Loader Process Flow and Connections

Automatic Calculation of the Optimal Load Group Size

Message Display in User’s Language


OTBI : HR Transactional Business Intelligence :

New Dashboard - Line Manager Dashboard

New Subject Area - Health and Safety

Enhanced Subject Area for Learning

New Metrics in Workforce Trend Subject Area

Reporting on Worker's Manager History

New Subject Area: Payroll- Rate Calculation Results Real Time

New Subject Area: Payroll - Element Entries History Real Time

New Subject Area: Workforce Succession Management - Talent Pools Real Time

New Subject Area: Time Collection Devices Real Time

Enhanced Subject Area: Workforce Talent Review - Talent Review Meeting Real Time

Enhanced Subject Area: Workforce Profiles - Person Profile Real Time

Enhanced Subject Area: Workforce Learning - Learning Management Real Time

Enhanced Subject Area: Workforce Management - Reported Time Cards Real Time

Enhanced Subject Area: Workforce Performance - Performance Document Eligibility Real Time

Enhanced Subject Area: Workforce Performance - Performance Rating Real Time

Enhanced Subject Area: Compensation - Workforce Compensation Real Time

Enhanced Subject Area: Compensation - Workforce Compensation Budgets Real Time

Enhanced Subject Area: Benefits – Enrollments Real Time

New Dimensions – Time and Labor Subject Areas

New Dimensions – Assignment Hours Details

New Dimensions – Seniority Dates

Enhanced Dimensions – Costing Segments

Enhanced Dimensions – Payroll-Related Dimensions

Enhanced Dimension – Compensation Manager - Performance Improvement

New Descriptive Flexfields – Absence Subject Area

New Metric – Accrual Balance

New Attributes – Global HR Dimensions

New Report – Benefit Element Report

Time and Labor Audit Reporting

Absence Management:

New Attribute for Absence Real Time to Determine Block Leave Candidate

New Dimensions – Assignment Hours Details

New Metric – Accrual Balance

New Descriptive Flexfields – Absence Subject Area

New Subject Area for Time & Labor

Enhanced Subject Areas for Time and Labor: Time Entry UOM

New Metrics in the Time and Labor Subject Areas

New Subject Area: Time Collection Devices Real Time

Enhanced Subject Area: Workforce Management - Reported Time Cards Real Time

New Dimensions – Time and Labor Subject Areas

Time and Labor Audit Reporting

Performance Management:

Enhanced Subject Area for Goal Management and Performance Rating

Learning Management:

Enhanced Subject Area for Learning Management - Legacy Learning Items

Sample Reports for Learning Management

Enhanced Subject Area for Learning

Wednesday, 15 November 2017

FUSION HCM: Absence management:Fast formula scenarios

Absence management:Fast formula scenarios:

1)Global Absence Accrual Event :
The Global Absence Accrual Event fast formula can be used to capture information  about events that occur during a calendar year which would cause a change in the  accrual band that the worker belongs to. This formula can capture such dates and  return to the accrual matrix formula which would automatically fetch the respective  band values as of each of the dates fed into the accrual matrix formula.
Example: An organization might have a vacation plan in which enrolled workers can  accrue a certain number of days every year based on their grade. When the grade of  a worker changes in the middle of the calendar year, the organization might want to  prorate their total accrual balance. You can configure this pro-ration rule using the  accrual event formula to capture the dates when such changes occur.

 2)Global Absence Accrual Matrix Formula :
The Global Absence Accrual Matrix fast formula can be used in conjunction with the  accrual matrix to implement requirements such as band change pro-ration, FTE pro-ration etc.
 For example, an organization might have a vacation plan in which workers enrolled into  the plan can accrue days every year based on their grade. If the grade changes mid-period, 
 then the total accrual needs to be pro-rated based on the amount of time that the worker  spends in each band. This can be achieved by defining an accrual matrix that is based on  grades and using a combination of accrual event formula and accrual matrix formula.
  
 3)Global Absence Carryover :
The Global Absence Carryover fast formula can be used in cases where a single carryover rule  does not apply to the entire population that belongs to the accrual plan.
 For example, an organization might have a carryover rule that generally allows a maximum of 5 days to be carried over. However, the workers in a particular department are allowed to carryover 
 an additional 2 days due to the nature of their work. In such cases, this logic can be composed into the fast formula so that when carryover is calculated, the application dynamically allocates 
 different carryover limits to different workers depending on their department.

 4)Global Absence Carryover Proration:
The Global Absence Carryover Proration fast formula can be used in cases where a pro-ration factor  (or a multiplication factor) needs to be applied onto the maximum carryover limit.
 For example, an organization might have a rule which asks for the carryover to be pro-rated  based on FTE or even their job. In such a case, after the carryover rule is defined, the carryover  proration rule can be composed to return a proration factor which will be multiplied onto the carryover  amount before returning the final value against the worker’s enrollment data.

 5)Global Absence Ceiling :
The Global Absence Ceiling fast formula can be used in cases where a single ceilingr rule does not apply to the entire population that belongs to the accrual plan.
  For example, an organization might have a ceiling rule that generally allows a maximum of 30 days to be accrued by an worker in a plan. However, the workers in a particular department are allowed to accrue an additional 5 days due to the nature of their work. In such cases, this logic can be composed into the fast formula so that when ceiling limit is determined, the application dynamically allocates different limits to different workers depending on their department.
  
 6)Global Absence Ceiling Proration :
The Global Absence Ceiling Proration fast formula can be used in cases where a pro-ration  factor (or a multiplication factor) needs to be applied onto the maximum ceiling limit.
  For example, an organization might have a rule which asks for the ceiling limit to be pro-rated based on FTE or even their job. In such a case, after the ceiling rule is defined, the ceiling proration rule can be composed to return a proration factor which will be   multiplied onto the ceiling limit before returning the final value against the worker’s enrollment data.

7)Global Absence Partial Period Accrual Rate :
The Global Absence Partial Period Accrual Rate fast formula is where any logic required  for pro-ration of accrual balance during enrollment year and un-enrollment year needs to be entered.
  For example, if the annual accrual that a worker is eligible for every year is 20 days  and the worker has enrolled into the plan mid-year, the organization would like to grant the worker on 10 days for the year of enrollment since he was participating in the plan  only for half the year. Similarly, if a worker un-enrols from a plan mid-year, the total accrual for that year would need to be reduced from 20 to 10 – again because the worker was  enrolled into the plan for only half the year.
  This formula is invoked when enrollment or un-enrollment dates fall within the repeating period for which the accrual is being processed.

8)Global Absence Plan Duration :
The Global Absence Plan Duration fast formula can be used to over-ride the default duration calculation logic for daily accrual duration entries against accrual plans. 
  For example, if the accrual deduction to be considered for an absence entry in an  accrual plan in an organization depends on the location of the worker, then this formula can be leveraged to specify this dynamic calculation logic. This formula will be invoked  once for each day of absence.
     Configuration Point in Fusion:
      If you have created this formula, you can attach this formula to the absence plan definition. 
      This is currently available only for plans whose UoM is Days or Hours.

9)Global Absence Plan Enrollment End :
The Global Absence Plan Enrollment End fast formula can be used to over-ride the default enrollment end date rule for the absence plan when workers are being terminated from  the organization or when the Update Accrual Plan Enrollments batch job is being run.
   For example, in an organization the absence plan un-enrollment rule could be such that for termination, workers have to serve a notice period of one month during which time the worker should not be enrolled into any absence plan. In such a case a Global Absence Plan Enrollment End formula can be composed to derive this alternate enrollment end date.
   
10)Global Absence Plan Enrollment Start :
The Global Absence Plan Enrollment Start fast formula can be used to over-ride the default enrollment start date rule for the absence plan when workers are being hired into the organization or when the Update Accrual Plan Enrollments batch job is being run.
   For example, in an organization the absence plan enrollment rule could be such that only Workers are allowed to enroll into the plan from the hire date, whereas Interns and Graduates have to complete a waiting period of 1 month before being enrolled into the plan. In such cases, the Plan Enrollment Start formula can be used to derive the alternate enrollment date (one that is different from the hire date or the date passed into the parameter when submitting the Update Accrual Plan Enrollments batch job).

11) Global Absence Plan Use Rate :
The Global Absence Plan Use Rate fast formula can be used to dynamically specify the rate definition associated with the accrual plans depending on custom conditions. 
  This formula type is applicable for Absence Payment Rate Rule, Final Disbursement Rate Rule, Discretionary Disbursement Rate Rule and Liability Rate Rule definitions.
  For example, if the Absence Payment rate definition associated with the same accrual plan varies depending on the location of the Worker being evaluated, a Global Absence Plan Use Rate can be composed to associate the corresponding rate definition to the Worker

12)Global Absence Proration :
The Global Absence Proration fast formula can be used to apply a pro-ration factor  (or a multiplication factor), onto the final accrual calculated and returned by the accrual calculation rules in an accrual based absence plan.
   For example, if an organization has an accrual plan where the accrual rate varies based on Worker grades, and on top of that if a multiplication factor such as 0.75 needs to be applied depending on the Worker work location, then the band based on grades can be defined in the accrual matrix and the multiplication factor of 0.75 based on work location can be defined in the Global Absence Proration formula.
   
13)Global Absence Vesting Period :
The Global Absence Vesting Period fast formula can be used to enforce a custom vesting period (a period during which the Worker is enrolled into the plan and accruing balance but cannot use them) 
  logic while defining an absence plan.
  For example, an organization might have a vesting period rule for new joiners where-in Workers  who are hired as Interns or Graduates should complete 30 days of employment before they can use their vacation balance. Here the vesting period formula can be composed to look at the person type to determine the period applicable for the particular enrollment.

14)Global Absence Band Entitlement :
The Global Absence Band Entitlement fast formula can be used to define the bands of entitlement duration and percentage of payment that is applicable against a qualification plan entitlement.
  For example, an organization might have a rule that gives Workers in a certain location additional fully paid days of Maternity entitlement when compared to Workers working in any other location.
  
15)Global Absence Plan Enrollment Start Date :
The Global Absence Plan Enrollment Start Date fast formula can be used to specify the Qualification  date for the absence plan.
  For example, an organization might have a rule for Maternity entitlements according to which the qualification date is on the absence start date if actual dates are entered or if it is not entered, 
  then the qualification date needs to be the event date (actual if available, or else, the planned date). 
  For including such conditional logic to determine the qualification date, formulas of this type can be used.

16)Global Absence Plan Entitlement :
The Global Absence Plan Entitlement fast formula can be used to define the entire entitlement structure for a qualification plan for cases where matrix architecture does not fit the bill.

17)Global Absence Plan Roll Backward End :
The Global Absence Plan Roll Backward End fast formula is to be used to determine the start date of a plan term that uses the Roll Backward term rule.
   For example, if the start date for plan term in a roll backward period needs to be 365 days prior to the absence end date, required logic can be composed into this formula and the reference date returned.

18)Global Absence Plan Roll Forward Start :
The Global Absence Plan Roll Forward Start fast formula returns the reference date till which the existence  of a roll forward term is searched for.
  For example, if a rolling forward term needs to be searched for 365 days prior to the absence start date, required logic can be composed into this formula and the reference date returned.

19)Global Absence Plan Use Rate :
The Global Absence Plan Use Rate fast formula can be used to dynamically specify the rate definition associated with the qualification plan depending on custom conditions.
  For example, if the rate definition associated with the same qualification plan varies depending on the location of the Worker being evaluated, a Global Absence Plan Use Rate can be composed to associate the corresponding rate definition to the Worker.

Written By: Duggireddy Narendra

Friday, 3 November 2017

FUSION HCM : FAST FORMULAS FAQ'S

What are Fast Formulas?

Fast formulas are generic expressions of calculations or comparisons that you want to repeat with different input variables. Fast Formula is a way to customize the existing functionality in Oracle Fusion Payroll.

Fast formulas are used to:

Calculate payrolls
Define the rules for paid time off accrual plans
Define custom calculations for benefits administration
Validate element inputs or user-defined tables
Edit the rules for object group population for elements or people
Calculate absence duration
Define custom configuration for compensation

What is the scope of the support of custom fast formulas?

Fast formulas are considered a customization to the seeded application. Oracle support services will assist with troubleshooting formula issues, but Oracle Support Services is not responsible for writing any custom fast formula code.

Oracle Fusion Payroll allows for the use of fast formulas on the forms and processes, and if the application does not recognize the fast formulas, then further investigation from Oracle Support Services is necessary.

However, if the issue is with the specific custom formula or custom function, Oracle Support Services will provide you with some steps for you to troubleshoot your custom fast formula or function issue, or you will need to contact your technical expert onsite or Oracle consulting services for further assistance, as this is outside the scope of support.

This document will not assist with the creation of either a formula or a function, but will give you steps to follow to troubleshoot fast formulas and/or functions that you have created.

Which HCM products use fast formulas?

Oracle Fusion Payroll
Fusion HCM Extract
Oracle Fusion Advanced Benefits
Oracle Fusion Workforce Compensation

What are the seeded fast formulas and how to determine seeded ones?

Oracle Fusion Payroll delivers seeded fast formulas for legislation taxation calculation. Formulas which were created for the user-defined elements will have legislative data group populated. Seeded fast formulas have effective start date 01-JAN-0001 and their Edit field is set to not editable.

Fast formulas that were created for the user created element will have Legislation Data Group populated, Effective Start Date set to the implementation date, Edit action is enabled.

Why are the seeded formulas failing after an install or applying a patch?

You must compile all seeded formulas after an install or patch by selecting the “Submit a Process or Report” task from the Payroll Checklist work area and then running the “Compile Formula” process.


Database Items related issues :

 No DBIs are created for elements with input values of "Char"

a) run the above sql to check if the database item was created

b) If the element is multiple entry allowed then the DBI will not be generated to get the entry values.

c) There is a formula called GET_ELEMENT_ENTRY_VALUES which should provide with the functionality required to access the input values of an element from another element.  It is documented in the formula header that they can review in the Formula Editor screen - the mode to use would be mode: 2 - ENTRY_VALUE.
Note: The formula can access other element entries that are also being processed in the payroll run.


No DBIs are create for Cost Allocation Flexfield

a) Please regenerate the flexfield again and run SQL below which show the generated list of DBIs:

select * from FF_ROUTE_TO_DESCR_FLEXS
where DESCRIPTIVE_FLEXFIELD_CODE='COST';

select * from FF_USER_ENTITIES_VL
where creator_id in
  (select ROUTE_TO_DESCR_FLEXS_ID
   from FF_ROUTE_TO_DESCR_FLEXS
   where DESCRIPTIVE_FLEXFIELD_CODE='COST');

select * from FF_DATABASE_ITEMS_VL
 where USER_ENTITY_ID in
  (select USER_ENTITY_ID from FF_USER_ENTITIES_VL
    where creator_id in
     (select ROUTE_TO_DESCR_FLEXS_ID
        from FF_ROUTE_TO_DESCR_FLEXS
           where DESCRIPTIVE_FLEXFIELD_CODE='COST'));


Generate Database Item process errors: 
'A record with this combination of values already exists'

When Log into Fusion Application and Navigate to the Scheduled Processes and run the Generate Payroll Data Base Items, the following error occurs: 'A record with this combination of values already exists'.
You need to run it for the context you needed it. The issue may be it is trying to create a DBI another context, which might have been seeded and DBI already exists.


Tips for resolving Fast Formulas performance issues :

When experiencing slow performance issues in fast formulas there are a number of techniques to follow to ensure your formulas are easy to read, use, understand, and process efficiently.

Variable Names and Aliases

To improve readability, use names that are brief yet meaningful. Use aliases if the names of database items are long. Name length has no effect on performance or memory usage.

 Inputs Statements :

Use INPUTS statements rather than database items whenever possible. It speeds up the running of your payroll by eliminating the need to access the database for the input variables.

An example of inefficient formula without INPUTS statement is:

SALARY = SALARY_ANNUAL_SALARY / 12

RETURN SALARY

An example of efficient use of INPUTS statements is:

INPUTS ARE ANNUAL_SALARY

SALARY = ANNUAL_SALARY / 12

RETURN SALARY

Database Items :

Do not refer to database items until you need them. Users sometimes list at the top of a formula all the database items the formula might need, thinking this helps the formula process more quickly. However, this in fact slows processing by causing unnecessary database calls.

An example of an inefficient use of database items is:

S = SALARY

A = AGE

IF S < 20000 THEN

IF A < 20 THEN

TRAINING_ALLOWANCE = 30

ELSE

TRAINING_ALLOWANCE = 0

An example of an efficient use of database items is:

IF SALARY < 20000 THEN

IF AGE < 20 THEN

TRAINING_ALLOWANCE = 30

ELSE

TRAINING_ALLOWANCE = 0

The first example always causes a database fetch for AGE whereas the second only fetches AGE if salary is less than 20000.

Balance Dimensions :

Wherever possible, use balance dimensions for single assignments only in formulas. Multiple assignments require more calculation time, leading to slower processing time. The number of multiple assignments in a payroll is not normally high, and the presence of a small number does not lead to any significant increase in overall processing time. However, there could be a problem if you unnecessarily link balance dimensions for multiple assignments into general formulas.

Here are some of the things for enhancing the performance of Fast Formula (in no particular order):

The more elements entered for an assignment, the longer its processing time.
The longer the formula, the longer its processing time.
One element associated with a longer formula usually processes faster than two related elements each associated with short formulas.
The number of elements per assignment affects processing time more than the number of elements and formulas.
Use balance dimensions for single assignments whenever possible. (ASG_GRE vs. PER_)
Do not refer to database items until needed.
Do not default unnecessary database items.
Using an ALIAS instead of assigning a database item to a local variable is more efficient.
Input statements are up to 10x faster than using database items.
Assign date constants using DATE component instead of the TO_DATE function.
Review generated formulas and remove unnecessary or poor logic coding.
Create elements with the correct input values instead of having a separate element for each input value. As you can see from item #9 above, Input statements are up to 10x faster than referencing database items.
Assign smaller fast formulas to each of these elements that only reference necessary database items for that specific element. Allows for easier maintenance and debugging.
Formula code is converted to PLSQL. The 200+ ALIAS lines are not converted to executable code - the alias statement is there so that you can use an alternative name for a database item within Formula text. The defaulting lines are only executed if defaulting is necessary i.e. when the corresponding database item is executed, but the underlying SQL returns no rows or a null row. 

In the scenario stated above, the formula has at least 200+ variables referred to (database items etc) - this can cause a performance hit due to network traffic because all these variables are exchanged between the payroll process and the database server whether or not they get used. This is because a Formula execution is a PLSQL procedure call. The number of parameters to this process is related to the number of different variables in the formula (inputs, outputs, database items, local variables).

Formula Errors :

Types of Fast Formula compilation errors

Compilation errors display in the Manage Fast Formulas page when you compile the formula. The formula compiler returns line numbers starting at 1 from the beginning of a formula, and character positions starting at 1 from the beginning of a line in its error messages. The compiler aborts compilation when an error is encountered.

This list contains the types and descriptions of several common formula compilation errors.

Syntax Error - The formula text violates the grammatical rules for the formula language. An example is using IF1 instead of IF for an IF statement.

Incorrect Statement - Order ALIAS, DEFAULT, or INPUT statements come after other statements.

Misuse of ASSIGNMENT Statement Occurs when any of these conditions occurs:

• An ASSIGNMENT assigns a value to a database item.

• A context is assigned a value externally to a CHANGE-CONTEXTS statement.

• A non-context variable is assigned a value within a CHANGE-CONTEXTS statement.

Misuse of ALIAS Statement - An ALIAS statement may only be used for a database item.
Missing DEFAULT Statement - A database item with defaulting specified must have a DEFAULT statement.
Misuse of DEFAULT Statement - A DEFAULT statement is specified for a variable other than an input or database item.
Uninitialized Variable - The compiler detects that a variable is uninitialized when used. The compiler cannot do this in all cases. This error often occurs when you want to use a database item, but a database item is not available in the formula.
Missing Function Call - A function call is not recognized. The combination of return type, function name, and parameter types does not match any available function.
Incorrect Operator Usage - An instance of a formula operator use does not match the permitted uses of that operator. For example, the + operator has two permitted uses. The operands are both of data type NUMBER, or both of data type TEXT.
Inconsistent Data Type Usage - A formula variable is being used as if it is of more than one data type. Or a database item or context is being used with the wrong data type. For example, Variable A is assigned a NUMBER value at the start of the formula, but a TEXT value later in the formula.
EXIT Statement Not Within WHILE Loop - A condition that eventually becomes false, or an EXIT call for exiting the loop does not exist.
Misuse of Context - A variable is used as a context, or a context is used as a variable. For example, AREA1 is assigned a value as an ordinary variable, but later in the formula AREA1 used as a context in a GET_CONTEXT call.

Error: “Local value used before initialized”

a) Error can mean that a database item is not available and is being treated as a local variable.

b) Remove the quotes around the Database Items (DBIs) that you are wishing to utilize (HRT_PERSON_PREV_WORKEXP....)
c) As these DBIs are of type 'array', you must use the proper syntax to default and to use them 
    i) Use 'DEFAULT_DATA_VALUE' for the HRT_PERSON_PREV_WORKEXP.....DBIs rather than 'DEFAULT'
    ii) Using the Fast formula User Guide as an aid, select a method of looping to loop through the DBI values.

          A simple example is below:

       DEFAULT_DATA_VALUE FOR HRT_PERSON_PREV_WORKEXP_EMPLOYER_NAME IS ' '
       DEFAULT_DATA_VALUE FOR HRT_PERSON_PREV_WORKEXP_START_DATE IS '01-JAN-0001' (date)
       DEFAULT_DATA_VALUE FOR HRT_PERSON_PREV_WORKEXP_END_DATE IS '01-JAN-0001' (date)
       DEFAULT_DATA_VALUE FOR HRT_PERSON_PREV_WORKEXP_PERSON_ID IS ' '
       DEFAULT FOR S_DT1 IS '01-JAN-0001' (date)
              for
           /* 1 is the starting index for an array database item. */
               I = 1

             WHILE HRT_PERSON_PREV_WORKEXP_START_DATE.EXISTS(I) LOOP
             (
               S_DT1 = HRT_PERSON_PREV_WORKEXP_START_DATE[I] /* Do some processing with element at index I. */
               I = I + 1 /* Array database items indexes go up in steps of 1. */
              )
        ACCRUAL = 3
        RETURN ACCRUAL


Types of Fast Formula Execution Errors

Fast formula execution errors occur when a problem arises while a formula is running. The usual cause is a data problem, either in the formula or in the application database. These errors contain the formula line number where the error occurs.

This list contains the types and descriptions of several common formula execution errors.

Uninitialized Variable - Where the formula compiler cannot fully determine if a variable or context is initialized when it is used, it generates code to test if the variable is initialized. When the formula executes and the variable or context is not initialized an error is raised.

Divide by Zero - Raised when a numeric value is divided by zero.

No Data Found - Raised when a non-array type database item unexpectedly fails to return any data. If the database item can return no data then it should allow defaulting. This error is also raised from within a formula function. The cause is an error in the formula function code.

Too Many Rows - Raised when a non-array type database item unexpectedly returns more than a single row of data. The cause is an incorrect assumption made about the data being accessed. This error can also be raised from within a formula function. The cause is an error in the formula function code.

NULL Data Found - Raised when a database item unexpectedly returns a NULL data value. If the database item can return a NULL value then defaulting is allowed.

Value Exceeded Allowable Range - Raised for a variety of reasons, such as exceeding the maximum allowable length of a string.

Invalid Number - Raised when an attempt is made to convert a non numeric string to a number.

User Defined Function Error - Raised from within a formula function. The error message text is output as part of the formula error message.

External Function Call Error - A formula function returned an error, but did not provide any additional information to the formula code. The function might have output error information to the logging destination for the executing code.

Function Returned NULL Value - A formula function returned a NULL value.

Too Many Iterations - A single WHILE loop, or a combination of WHILE loops, has exceeded the maximum number of permitted iterations. The error is raised to terminate loops that could never end. This indicates a programming error within the formula.

Array Data Value Not Set - The formula attempted to access an array index that has no data value. This is an error in the formula code.

Invalid Type Parameter for WSA_EXISTS - An invalid data type was specified in the WSA_EXISTS call.

Incorrect Data Type For Stored Item - When retrieving an item using WSA_GET, the items actual data type does not match that of the stored item. This is an error within the calling formula.

Called Formula Not Found - The called formula could not be resolved when attempting to call a formula from a formula. This could be due to an error in the calling formula, or because of installation issues.

Recursive Formula Call - An attempt was made to call a formula from itself. The call could be directly or indirectly via another called formula. Recursive formula calling is not permitted.

Input Has Different Types In Called and Calling Formulas - When calling a formula from a formula, the actual formula input data type within the called formula does not match the data type specified from the calling formula.

Output Has Different Types In Called and Calling Formulas - When calling a formula from a formula, the actual formula output data type within the called formula does not match the data type specified from the calling formula.

Too Many Formula Calls - There are two many formula from formula calls. This is due to a problem with the formulas.

Error: Formula XYZ_HR_TO_PAY, line 45, database item or local variable HR_RELATIONSHIP_ID used as a context

Issue:

Need to to fetch HR DBIs for checking the "With Match 401k" Eligibility: PER_REL_DATE_START, PER_REL_ADJUSTED_SVC_DATE.

Used "Payroll Access to HR" Formula Type and wrote the following formula. But it gives the following error message : Formula XYZ_HR_TO_PAY, line 45, database item or local variable HR_RELATIONSHIP_ID used as a context.

Formula Name : XYZ_HR_To_Pay
Formula Text :
default for ForPay_REL_ADJUSTED_SVC_DATE IS '1951/01/01 12:00:00' (date)
default for ForPay_REL_DATE_START is '1951/01/01 12:00:00' (date)

default for PER_REL_ADJUSTED_SVC_DATE IS '1900/01/01 12:00:00' (date)
default for PER_REL_DATE_START is '1900/01/01 12:00:00' (date)

default for TERM_HR_RELATIONSHIP_ID is 0
default for HR_RELATIONSHIP_ID is 0

INPUTS ARE hr_assg_id (number)

l_HR_RELATIONSHIP_ID = 0
l_TERM_HR_RELATIONSHIP_ID = 0

CHANGE_CONTEXTS (HR_ASSIGNMENT_ID=hr_assg_id)
l_TERM_HR_RELATIONSHIP_ID = TERM_HR_RELATIONSHIP_ID
l_HR_RELATIONSHIP_ID = HR_RELATIONSHIP_ID

CHANGE_CONTEXTS (HR_ASSIGNMENT_ID=hr_assg_id, HR_RELATIONSHIP_ID = l_HR_RELATIONSHIP_ID)
ForPay_PER_REL_DATE_START = PER_REL_DATE_START

RETURN ForPay_REL_DATE_START
  

Solution:

The formula running at assignment level and the PAYROLL_TERM_ID context is set.


1. Change the calculator formula as follows:

At the start add:

DEFAULT FOR TERM_HR_RELATIONSHIP_ID IS -1

/*
* Only if you need HR_TERM_ID database items in Payroll Access To HR
formula.
*/
DEFAULT FOR TERM_HR_TERM_ID IS -1
  

Change the call to the Payroll Access To HR formula as follows:


CALL_FORMULA
('XYZ_HR_To_Pay'
,TERM_HR_RELATIONSHIP_ID > 'HR_RELATIONSHIP_ID'
/* Only if you need HR_TERM_ID database items in Boz_HR_To_Pay. */
,TERM_HR_TERM_ID         > 'HR_TERM_ID'
/* Only if you need HR_ASSIGNMENT_ID database items in Boz_HR_To_Pay. */
,ASG_HR_ASG_ID           > 'HR_ASSIGNMENT_ID'
,ForPay_REL_DATE_START < 'ForPay_REL_DATE_START'
                         default '1901/01/01 12:00:00' (date)
,ForPay_REL_ADJUSTED_SVC_DATE  < 'ForPay_PER_REL_ADJUSTED_SVC_DATE'
                                 default '1901/01/01 12:00:00' (date)
)
  

2. The Payroll Access To HR formula should be as follows because the contexts will get set from the CALL_FORMULA call in the parent formula so no need for CHANGE_CONTEXTS:

default for PER_REL_ADJUSTED_SVC_DATE IS '1900/01/01 12:00:00' (date)
default for PER_REL_DATE_START is '1900/01/01 12:00:00' (date)

ForPay_REL_DATE_START = PER_REL_DATE_START
ForPay_REL_ADJUSTED_SVC_DATE = PER_REL_ADJUSTED_SVC_DATE

RETURN ForPay_REL_DATE_START, ForPay_REL_ADJUSTED_SVC_DATE
  

a) Legal Employer Level Seniority Date PER_ASG_REL_ADJUSTED_SVC_DATE returns a seniority date in a Legal Entity (LE) relationship seniority date.
b) Enterprise Seniority Date PAYROLL_INTERFACE_ORIGINAL_DATE_OF_HIRE  returns you first original date of hire irrespective of LE. Ensure necessary contexts are set before use.

PAYROLL_INTERFACE_ORIGINAL_DATE_OF_HIRE also uses PERSON_ID context and this is set in payroll formulas so should be able to use without the Payroll Access to HR formula.

For formulas running at term level, extra work would need to be done to be able to set the HR_ASSIGNMENT_ID contexts in the Payroll Access To HR formula.

For formulas running at relationship level, extra work would need to be done to be able to set the HR_ASSIGNMENT_ID and HR_TERM_ID contexts in the Payroll Access To HR formula.


Error: Formula TD US SECOND SHIFT HOLIDAY_EARN, line 432, no data returned.(3=GET_TABLE_VALUE) 

Issue:

The formula is being called by this call in formula TD_US_SECOND_SHIFT_HOLIDAY_EARN_ff:

l_table_rate = get_table_value(             'SECOND_SHIFT_RATES',
                                           'SHIFT_RATE',
                                           l_location_name,
                                           PAY_EARN_PERIOD_START)


GET_TABLE_VALUE function call appears to be returning multiple values, hence the the error.

Solution:

Ensure that:

    (1) Table Name must be unique,
    (2) Row Title must be Unique,
    (3) Column Name must be Unique, and
    (4) Sequence Numbers of Rows must be Unique


1. There are 2 formats for the function call:

GET_TABLE_VALUE(table_name, column_name, row_value [,default_value])
GET_TABLE_VALUE(table_name, column_name, row_value, effective date)

2. You cannot provide a null column_name or row_value to GET_TABLE_VALUE.

3. When defining UDTs, the table_name must be unique

4. When defining UDTs, the column_name must be unique within a specific table

5. When defining UDTs, the row_name must be unique within a specific table

6. The row name/value and the column name must be unique for the given table - they do not need to be unique across all UDTs.

7. The User Table must be visible in the legislative data group of the payroll process. This means that it must exist at enterprise level or in the same legislative data group.

8. GET_TABLE_VALUE matching matches against internal (base table) values. These are non-modifiable values from when the user table is constructed. The UI values are translation table translatable values. These are initially the same as the internal values but can be updated and in different languages - this is why internal values must be used.

So it is possible that the translated value on the UI and the internal base value don't match. BI queries could be run by the customer against FF_USER_TABLES,  FF_USER_COLUMNS and FF_USER_ROWS_F to get the correct values.

GET_TABLE_VALUE does upper case matching with UPPER function i.e. 'abc', 'Abc', and 'ABC' are the same thing.

9. The internal user tables names are unique i.e. it should be impossible to select 2 user tables called 'ABC' within the same legislative data group. Also, for each user table the internal user column and user row names are unique.

It is possible that the UI does not do translated name uniqueness checking so that the UI could show duplicate names.

10. The effective date ranges of the user rows and user column instances must cover the effective date of formula execution.


Error: ‘Context Payroll_Assignment_ID was not set’

If you use the dimension _ASG_RUN in your formula (which uses the context PAYROLL_ASSIGNMENT_ID) and your formula gets executed at the payroll relationship level then your formula will error out because this context is not automatically set at this level and there is no way the balance call will successfully complete.

Use the RUN_INCLUDED_PAYROLL_ASGS DBI to resolve the issue. That is in the Calculator formula so that a call to CHANGE_CONTEXTS sets the PAYROLL_ASSIGNMENT_ID context values to derive HR_ASSIGNMENT_ID and pass that into a called formula.


Error: 'Contexts HR_ASSIGNMENT_ID was not set' for Element Input Validation type Fast Formula

Issue: Custom Fast Formula of type Element Input Validation is attached to Elements at => Element Details -> Default Entry Values and Validation -> Calculation Formula.

Application does not set contexts.

Adding the Element to a test employee.
Put some value in the Amount field and Save.
The application throws an error and the entry is not saved.

The application is not setting the Contexts HR_ASSIGNMENT_ID, DATE_EARNED which it should ideally.
The Fast Formula user guide says these contexts are available to this type of Formula.

Solution: The element is setup at Term/Relationship level. HR_ASSIGNMENT_ID context will not get set because there can be multiple assignments per relationship / term. Create element at Assignment level and then create the calculation formula.  Attach element to employees.


Error: Context PAYROLL_TERM_ID was not set when used at line 65 of formula XYZ_CHG_DEDN_CALCULATOR

Element is defined at the Payroll relationship level.  Under a payroll relationship level there could be one or more terms.  You can not access a DBI that uses the context PAYROLL_TERM_ID at this level because naturally the context would not automatically be set.

In this situation the issue was resolved by using another DBI RUN_INCLUDED_PAYROLL_ASGS.


Error: Array data value missing. (3=RUN_INCLUDED_PAYROLL_ASGS) (4=1)

This line of the formula is in error:

CHANGE_CONTEXTS(PAYROLL_ASSIGNMENT_ID = RUN_INCLUDED_PAYROLL_ASGS[1])

The error is that the RUN_INCLUDED_PAYROLL_ASGS database item is returning nothing so there is no value at RUN_INCLUDED_PAYROLL_ASGS index 1 hence the
error when accessing RUN_INCLUDED_PAYROLL_ASGS[1].

Looking at the formula, the preceding code block:

CHANGE_CONTEXTS (DIR_CARD_COMP_ID = l_comp_id)
(
  l_index = ALL_ASGS_LINK_TO_DEDUCTION_COMPONENT.first(-1)
  if (ALL_ASGS_LINK_TO_DEDUCTION_COMPONENT.exists(l_index) ) then
  (
....

  )
  else
  (
    l_log = PAY_INTERNAL_LOG_WRITE('(VAC_ACCRUAL_LIAB_CAL) Error.. Assignment
id is missing')
    l_error = PAY_LOG_ERROR('PAY:PAY_ASG_ID_MISSING')
  )
)
  
The log file shows the formula has entered the first part of the if-statement because there are messages from there like the following in the log file:

(VAC_ACCRUAL_LIAB_CAL) : l_accrual_unit 50
(VAC_ACCRUAL_LIAB_CAL) : l_accrual_uom H_DECIMAL3
(VAC_ACCRUAL_LIAB_CAL) Initialize the call for GET_PAY_SALARY_BASIS
(VAC_ACCRUAL_LIAB_CAL) : PAYROLL_ASSIGNMENT_ID 300000002161842
  
Alter the formula and include

l_assignment_id = ASG_HR_ASG_ID
l_hire_date = ACP_HIRE_DATE
  
into the earlier code code block where PAYROLL_ASSIGNMENT_ID is set.


How does formula caching effect formula execution?

a) If a formula's (non-comment) code is changed and it is compiled the code that is executed for the formula is changed.

b) For certain processes (e.g. Payroll run) the formula implementation (C) does cache the formula executable code for performance. If the formula were
changed and compiled in the middle of such a process then the changes would not be seen by the executing process. However, this caching only lasts for
the life-time of the process (the cache is within the process memory, not in an external sub-system e.g. JVM, database, web server).

c) Other processes e.g. Extracts have formula execution implemented differently (PLSQL) do some caching but the changed executable part would be
used if the formula were changed and compiled in the middle of the process. In this case the process formula execution would raise errors (unless the
changes were done in a restricted way). This information is cached as PLSQL package global values, but correctly written consuming code should clear the
caches at the start of execution.