Scribd
Upload
13K views77 pages

OTL Setup

The document provides steps to set up Oracle Time and Labor (OTL) to process payroll through timecard entries. The key steps include: 1. Defining recurring and non-recurring time elements, salary basis, and linking elements. 2. Creating employees with hourly salary basis and defining their payroll and statutory information. 3. Setting up OTL responsibilities, approval periods, and time entry rules. 4. Creating an OTL preference and assigning it to define timecard layout, approvals, and validations. The full setup is required to create, approve, and process timecards all the way to the general ledger for payroll processing.

Uploaded by

rahulkatarey
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
13K views77 pages

OTL Setup

The document provides steps to set up Oracle Time and Labor (OTL) to process payroll through timecard entries. The key steps include: 1. Defining recurring and non-recurring time elements, salary basis, and linking elements. 2. Creating employees with hourly salary basis and defining their payroll and statutory information. 3. Setting up OTL responsibilities, approval periods, and time entry rules. 4. Creating an OTL preference and assigning it to define timecard layout, approvals, and validations. The full setup is required to create, approve, and process timecards all the way to the general ledger for payroll processing.

Uploaded by

rahulkatarey
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
  • Setup for OTL: Processing payroll through OTL entries: Covers the process of handling payroll using Oracle Time and Labor entries, including the setup of time elements and recurring elements.
  • Introduction: Provides an overview of the setup process for Oracle Time and Labor, detailing the necessary steps and purpose.
  • Create Employee: Instructions on setting up employee profiles with specified salary bases in the system.
  • Defining Four Non-recurring Elements: Sets rules for non-recurring elements such as overtime and premium hours that contribute to payroll.
  • Defining Absence Type: Describes how to create and attach non-recurring elements to payroll or HRMS based on absence types.
  • Assigning OTL Responsibility: Covers the assignment of responsibilities within Oracle Time and Labor setup for payroll processing.
  • Defining Recurring Periods: Defines the recurring periods used in timecards within Oracle Time and Labor.
  • Define Approval Periods: Establishes approval periods within the application for consistent validation of time periods in use.
  • Defining Time Entry Rules: Explains rules that govern the entry and validation of timecard data.
  • Approval Style: Outlines the hierarchy and workflow for approving time entries in Oracle systems.
  • Defining Time Entry Rule Groups: Organizes time entry rules into groups for efficient management and validation.
  • Creating Preference: Develops preferences for timecard settings including sections defining alternate names and approval periods.
  • Defining Where Preferences are Used: Explains the applicability of various preferences set within the system to businesses or individuals.
  • Look of the Time Card: Describes the visual and functional aspects of the employee time card interface.
  • Write Formula: Covers the formulation of calculations for payroll factors like regular hours and overtime.
  • Creating Time Card: Guides the creation of time cards for recording employee work hours.
  • Approval Notification: Details the notification process for supervisors when timecard approvals are required.
  • Sending Approved Timecard to Payroll: Explains the transfer process of approved timecards to payroll processing systems.
  • Batch Created: Describes the batch processing of payroll data once timecards are approved.
  • Transfer the Timecard: Instruction on how timecards are transferred to HRMS for final payroll integration.
  • Generating SOE for Time Card: Outlines the process to create a Statement of Earnings for employees' timecards processed through payroll.
  • Payroll Processing: Multiple Employees: Explains processing payroll for multiple employees simultaneously using Oracle systems.
  • Prepayment: Details prepayment procedures and methods like checks or bank transfers for payroll delivery.
  • Check Writer Process: Describes the process for generating checks for employee payments and 3rd party transactions.
  • Process to Generate Covering Letter: Producing covering letters that summarize payment and payroll details as required in output reports.
  • Run Deposit Process to Generate SOE: Uses the deposit process for generating a Statement of Earnings effectively in payroll systems.
  • Associating Custom Set of Hook to GL Responsibility: Links payroll entries to the General Ledger for financial tracking and recording.
  • Costing: Defines credit and debit account details tied to payroll entries during costing.
  • Costing Reports: Provides reports showing costing summaries to aid financial analysis and compliance.
  • Transfer to GL: Describes the technical transfer of payroll data to the General Ledger system.

SETUP FOR ORACLE TIME AND

LABOR: Processing Payroll through


OTL Entries

Created By Ritu Shukla


Date 22-Feb-2007
Version 1.0
Introduction
This document explains the full set up of Oracle Time and Labor that is required
to create a Time card and process it all the way through GL. It also explains the Time
store Deposit API’s. Time store deposit API is a technical way of creating the timecard.

SETUP for OTL: Processing payroll through OTL entries


Payroll processing of the workers that are getting daily wages, is done through Time card
entries from Time and Labor Responsibility.

To enter a Time card we need minimum of one recurring element and n(1..n) number of
non recurring elements.

Time Elements (Non Recurring)


Hours, Rate, Multiple

1. Define Recurring Element


Responsibility: Super HRMS
Navigation: total Compensation-> Basic-> Earnings

Since these employees get paid on the basis of number of hours they worked, we define
the salary basis for these employees as ‘Hourly Basis’
2. Defining Salary Basis

Responsibility: US Super HRMS


Navigation: Total Compensation-> Basic -> Salary Basis

Pay Annualization factor: It indicates the factor, by which when per hour income is
multiplied it gives the annual salary.

Now we attach the recurring element created above to this salary basis.

3. Create Link
Create Link for the element created above so that this element becomes available
for the payroll processing.

Responsibility: US Super HRMS


Navigation: Total compensation -> Basic -> link
4. Create Employee
Create the employee with the salary basis as ‘Hourly Basis’
Define supervisor for this employee
- Define Payroll
- Define GRE under Statuory Tab
- Define salary for this employee:
Remember to define the salary on hourly basis, annual salary will be calculated
automatically.
In this case: 50 *2080 (Pay annualization factor defined while defining element)
is the annual salary
5. Defining four non recurring elements
Time of the wage earners will be charged against these non recurring elements.

Earning elements are classified into three categories:


Earning categories and the lookup defined for them are as follows:
- Earnings : US_EARNINGS
- Supplemental earnings : US_SUPPLEMENTAL_EARNINGS
- Imputed Earnings : US_IMPUTED_EARNINGS

Element1: Regular Hours


Responsibility: US super HRMS
Navigation: Total Compensation-> Basic -> Earnings
Element2: Overtime
Responsibility: US super HRMS
Navigation: Total Compensation-> Basic -> Earnings
Element3: Premium Hours (Something that employee gets above overtime work)
Responsibility: US super HRMS
Navigation: Total Compensation-> Basic -> Earnings
Element4: Hours not Worked
Responsibility: US super HRMS
Navigation: Total Compensation-> Basic -> Earnings
6. Defining Absence Type:

Depending on the type of element, entries are passed to payroll or HRMS or Payroll and
HRMS both.

First three non recurring elements defined above are passed just to payroll.
‘Hours not worked’ is passed to both payroll and HRMS.
To see this in HRMS, we need to define absence type and attach this element to this
absence type.

7. Create Link for non recurring element


In order to use the above created elements for payroll processing we create link
for all the elements:
Define the links for all the elements above and define the input values:

Responsibility: US super HRMS


Navigation: Total Compensation-> Basic -> Links

Define input values as follows:

Overtime: Multiple-1.5
Premium: Multiple- 2

8. Assigning OTL Responsibility

Assigning OTL Responsibility to the User to do further setup for OTL:

Define a security profile

Responsibility: US super HRMS


Navigation: Security -> Assign Security profiles.

9. Defining Alternate Names


Responsibility-> US OTL Application developer
Navigation: Alternate names -> Alternate Name Definition
10. Recurring Periods

Number of days or columns appearing in the timecard screen are controlled by


something called as Recurring Period

Responsibility: US OTL Application Developer


Navigation: Recurring Period.

Period Type: Defines the number of columns or number of days


Eg; period type ‘Week’ will define the number of columns as 7
Start Date: It defines which day of week the timecard will start from like Monday
, Tuesday and so on.
As in the example below, 3-feb-2003 falls on Monday, so all the timecards will start from
Monday to Sunday.
11. Define approval periods:

It is required to define what all applications will be using these periods

Responsibility: US OTL Application Developer


Navigation: Approval -> Define Approval Periods

Contingent workers cannot be paid through payroll.


They are paid through purchasing
Human Resource- Absence
Payroll- Hours
Project-Expenditure
12. Defining Time Entry Rules

By Mapping we control the mandatory fields. If time card is for payroll purpose we
enter mapping as ‘BEE Retrieval Process’. This is the standard process. We can also
apply some custom rules.

Responsibility: US OTL Application Developer


Navigation: Time Entry Rules -> Define Time Entry Rules
Creating Custom Controlling Rules using Fast Formulas
Maximum Hours: Cannot work more than that (example cannot work more than 50 hours
in this case)
Reference Period: In a week type of recurring period there can be maximum two weeks
in which the duration can span.
Formula used above is defined in a DFF: OTL Formulas
13. Defining Time Entry Rule Groups

Time entry rule groups are defined to associate all the rules together and define
the outcomes of each rule if it is violated.

Responsibility: US OTL Application developer


Navigation: Time Entry Rules-> define Time Entry Rule Groups

14. Approval Style:

This defines in each application what would be the approval hierarchy. Who is going
to approve the time card of the employee.

In the Example below, in both the responsibilities HR and payroll, immediate supervisor
will approve the timecard.

Responsibility: US OTL Application Developer


Navigation: Approval -> Define Approval Style
15. Creating Preference

After all the above things are defined, its now time to decide how the timecard
will look like, what all validations will be applied on the time card.
To do this we create Preferences and attach this preference to certain business group or
organization or may be the employee depending on the requirements.

Create Preference

Responsibility: US OTL Application Developer


Navigation: Preferences
We don’t need to disturb the existing preference. We will create our own new custom
preference.
Right Click on the preference tree and select new.
Enter the name of the preference u want to create.
For any timecard to work and function properly there are 9 mandatory preference
attributes that should be defined.

15.1 Creating Alternate Names

Right click on the new preference created and select new.


Enter the name as Alternate names.
Select the seeded preference as ‘Self Service Timecard Alternate Name set Defined for a
user’
Now enter the preference values as alternate name defined above.
15.2 Approval Periods

Preference: Time Store Approval Periods


Value: Approval period that was defined above.

15.3 Recurring Period

Preference: Self service timecard Period for Worker


Value: Recurring period that was defined above.
15.4 Application set

Preference: Time Store Application Set


Value: Human Resources and Payroll
15.5 Time entry rule group

Preference: Time Store Time Entry Rules


Value: Time entry rule group that was defined above.
15.6 Layout

Preference: Self service Timecard, review and confirmation Layout Page


Value: Timecard Layout: Payroll Timecard Layout
Review Layout : Payroll Review Layout
Confirmation layout: payroll confirmation Layout
Notification Layout: patrol notification Layout
15.7 Approval Style

Preference: Time Store approval Style


Value: approval style that was defined above
15.8 Retrieval Group

Preference: Time Store Retrieval Rule Groups


Value: Human Resources and Payroll retrieval rule group
15.9 Allow status edit

Preference: Self Service timecard status that allows user edits


Value: Status allowing Edit: RETRO
Past number of days: 60
Future number of days: 60
15.10No of empty rows

Preference: Self service Number of empty rows on the timecard


Value: Number of empty rows:0
16. Defining where all this preference will be used

This preference can be attached to a business group, Organization or to a person.


Precedence defines which rule will be used for the preference
17. Look of the time card

Responsibility: Employee, self service -> Time Entry


18. Write formula

To calculate regular hours, premium hours, overtime, work not worked amount
on the basis of annual salary

Responsibility: US super HRMS


Navigation: Total Compensation-> Basic -> Write Formula
DEFALULT FOR ASG_HOURLY_SALARY IS 0
DEFAULT FOR Hours is 0
default FOR Multiple IS 0

INPUTS ARE Hours, Multiple

IF Multiple = 0 then
(
PAY=ASG_HOURLY_SALARY* Hours
)
ELSE
(
PAY=ASG_HOURLY_SALARY* Hours*Multiple
)

RETURN PAY

19. Formula result rule


Attaching this formula to all the non recurring elements
Responsibility: US super HRMS
Navigation: Total Compensation-> Basic -> Formula Result
19. Creating Time Card

Responsibility: Employee, self service-> Time Entry


20. Approval notification

Since approval rule is set as HR Supervisor , Notification will go to the immediate


supervisor for the timecard approval.

Responsibility; Manage, self service-> FYI


Approved
21. Sending Approved timecard to Payroll

This is done by running the process: Process: Transfer time from OTL to BEE
Responsibility: US OTL Application Developer
22. Batch Created

As a result of the above process a batch gets created with the name supplied for
transaction code in the above process.

Responsibility: US Super Human Resource


Navigation: Mass exchange info-> batch element entry
23. Transfer the Timecard

Still the timecard entry has not reached to payroll, but they are sitting in the
interface(batch) table.
To push these entries to HRMS, in the batch Element Entry screen, click process
to process the records.
Process-> Transfer
24. After transferring the batch entries get created in payroll and HRMS both:

Entries in HRMS:
Absence Details: Employee-> Others->Absence
25. Generating SOE(Statement of Earning) for the period time card is created

Run quick pay to generate SOE(Statement of Earning) for the period u created your time
card.
Navigation: Employee -> Assignment-> Others-> Quickpay
26. Viewing SOE

View result to see the entry in pay slip


27. Payroll Processing: Multiple Employees

Above we processed just one employee by running the quick pay run. In practical
scenario we have to process payroll for n number of employees. For this instead of
processing each employee separately we run the payroll process that processes multiple
employees in one go.

Process Name: Payroll process

Payroll process spawns further sub processes


28. View the Log of payroll process

29. Prepayment
Once the payroll entries are created, payment has to be done. There are various
modes of payment like check, cash etc. So, before doing the payment we group the
employees on the basis of the payment method attached to them. This is done by running
the process Prepayments.

View the detail for each employee from payroll run result
30. Check Writer Process

There are various modes of payment. We have different processes defined for
doing different types of payments.
To do the payment by check we need to run the process called Check Writer.

The output of this process will generate the check for each employee whose payment
method was selected as check.

31. 3rd party Check Payment.

If the payment is done by some third party, then run the check writer process with
the payment method as 3rd party payment method instead of check.
Checks will be generated in the output file of this process.

32. NACHA: Payment method


An output file is generated as a result of this process. This output file is used to
directly credit the amounts in the account numbers specified in the report.

33. NACHA: Flat File Output


34. Process to generate the covering letter.
Above process generates Summary or detailed report based on the ‘Totals Only’
Parameter specified above. If parameter is set to ‘yes’ it generates summary report and if
it is set to ‘No’ then it generates Detail Report.

Summary Report Output


Detail Report Output
35. Run Deposit Process to generate SOE

Unlike check writer process NACHA report does not generate SOE. In order to
generate that we run another process called as Deposit Advice.
Report Output: SOE
36. Associating custom set of book to GL Responsibility

By this point all the processing has been done at the payroll side. Now it is
required to transfer the payroll entries to General Ledger.
For this we create a Set of book. Create a custom responsibility which is derived from the
General Ledger. To attach SOB to GL responsibility, we assign custom SOB created to
the profile option ‘GL set of books’ at responsibility level.

37. Open the GL period.

In order to transfer the payroll entries to GL, We need to open the GL periods in
which payroll transactions are present.
38. Costing

Costing Information for the payroll entries are defined while creating the link of
element. We define credit and debit account.
Report generated after costing
39. Costing Reports

Costing details can be viewed by running the costing Summary and detail reports.

Costing Summary Report


Costing Summary Report Output
Costing Detail Report

Costing Detail Report Output


40. Transfer to GL

Now the entries can be transferred from payroll to GL by running the transfer to
GL process.
Log of Transfer to GL
41. Journal Import from GL

Payroll journals can be imported by running the journal import.


Output of Journal Import
42. Archival Process

Run Archival Process to view the pay slip in the self service screen.
Process name; External Process archival
43. Viewing Pay slip in Self service screen:

Employee self service screen -> payslip


Time Store Deposit API
DECLARE
----------------------------------------------------------
-- Constant declarations
----------------------------------------------------------
-- This is the appl_id for OTL, do not change
c_otl_appl_id CONSTANT NUMBER (3) := 809;
c_proj_attr1 CONSTANT VARCHAR2 (7) := 'Task_Id';
c_proj_attr2 CONSTANT VARCHAR2 (10) := 'Project_Id';
c_proj_attr3 CONSTANT VARCHAR2 (16) := 'Expenditure_Type';
c_proj_attr4 CONSTANT VARCHAR2 (19) := 'Expenditure_Comment';
c_proj_attr5 CONSTANT VARCHAR2 (23) := 'SYSTEM_LINKAGE_FUNCTION';
----------------------------------------------------------
-- Variable declarations
----------------------------------------------------------
-- declare the PL/SQL Table that will hold the complete timecard (all the BBs)
l_tbl_timecard_info hxc_self_service_time_deposit.timecard_info;

-- declare the PL/SQL Table that will hold all the attributes
l_tbl_attributes_info hxc_self_service_time_deposit.app_attributes_info;

-- declare the PL/SQL Table that will hold the messages returned by the API
l_tbl_messages hxc_self_service_time_deposit.message_table;

-- person ID that this TC belongs to, Replace with your own


l_person_id per_all_people_f.person_id%TYPE := 9389;

-- Replace with your own IDs


l_task_id VARCHAR2 (3) := '221';

-- (l_project_id is NOT the same as task id, they just happen to have the
-- same ID on our database)
l_project_id VARCHAR2 (3) := '221';

-- Replace with your own values


l_expenditure_type VARCHAR2 (15) := 'Professional';

l_ot_expenditure_type VARCHAR2 (15) := 'Overtime';

l_system_linkage_id VARCHAR2 (15) := 'ST';

l_ot_system_linkage_id VARCHAR2 (15) := 'OT';

-- Will hold TC_ID, returned by the deposit process


l_new_timecard_id NUMBER;

-- Will hold TC ovn, returned by the deposit process


l_new_timecard_ovn NUMBER;

l_message fnd_new_messages.message_text%TYPE;

l_start_time DATE
:= fnd_date.canonical_to_date ('2002/11/11 00:00:00');

l_stop_time DATE
:= fnd_date.canonical_to_date ('2002/11/17 23:59:59');

l_tc_bb_id hxc_time_building_blocks.time_building_block_id%TYPE;

l_day_bb_id hxc_time_building_blocks.time_building_block_id%TYPE;

l_detail_bb_id hxc_time_building_blocks.time_building_block_id%TYPE;

l_time_attribute_id hxc_time_attributes.time_attribute_id%TYPE;

BEGIN

-- First initialize your session, this needs to be done for internal reasons so
-- the TimeStore knows who is trying to deposit the information. When you log
-- into SS, the same is done for you by the framework, here however we have to do
-- it manually.

FND_GLOBAL.APPS_INITIALIZE( user_id => 12345 -– Replace with your own ID


,resp_id => 56789 -– Replace with your own ID
,resp_appl_id => 809 );-- This is the appl_id for OTL, do not change

----------------------------------------------------------
-- PART 1: POPULATE TABLES --
----------------------------------------------------------
-- First populate the timecard PL/SQL table:
----------------------------------------------------------
-- Start with the TIMECARD BB
----------------------------------------------------------
hxc_timestore_deposit.create_timecard_bb (
p_start_time=> l_start_time,
p_stop_time=> l_stop_time,
p_resource_id=> l_person_id,
p_comment_text=> 'Created using API: Weekly Project TC',
p_app_blocks=> l_tbl_timecard_info,
p_time_building_block_id=> l_tc_bb_id
);

-- Now we create the DAY BB, 7 in total, and since they are all the same we
-- will loop 7 times

FOR i_day IN 0 .. 6
LOOP

hxc_timestore_deposit.create_day_bb (
p_day => TRUNC (l_start_time)
+ i_day,
p_parent_building_block_id=> l_tc_bb_id, -- returned by create_timecard_bb
p_comment_text=> 'Created using API',
p_app_blocks=> l_tbl_timecard_info,
p_time_building_block_id=> l_day_bb_id
);

-- The next call would also work but we choose to use the first one
-- since we know the TIMECARD's Id. If you do not know the ID you should
-- use this next call commented out here.

/* hxc_timestore_deposit.create_day_bb (
p_day => TRUNC (l_start_time)
+ i_day,
p_resource_id=> l_person_id,
p_comment_text=> 'Created using API',
p_app_blocks=> l_tbl_timecard_info,
p_time_building_block_id=> l_day_bb_id
); */

-- We can attach the DETAIL BB for every DAY BB that represents 'normal'
-- work hours as well here as they are all the same
-- We only need to do this for weekdays though

IF i_day < 5
THEN
hxc_timestore_deposit.create_detail_bb (
p_type=> 'MEASURE',
p_measure=> 8,
p_parent_building_block_id=> l_day_bb_id,
p_comment_text=> 'Created using API: NT',
p_app_blocks=> l_tbl_timecard_info,
p_app_attributes=> l_tbl_attributes_info,
p_time_building_block_id=> l_detail_bb_id
);

-- The next call would also work but we choose to use the first one
-- since we know the DAY's Id. If you do not know the ID you should
-- use this next call commented out here. In fact we use it ourselves
-- later to add the overtime.

/* hxc_timestore_deposit.create_time_entry (
p_measure=> 8,
p_day => TRUNC (l_start_time)
+ i_day,
p_resource_id=> l_person_id,
p_comment_text=> 'Created using API: NT',
p_app_blocks=> l_tbl_timecard_info,
p_app_attributes=> l_tbl_attributes_info,
p_time_building_block_id=> l_detail_bb_id
); */

-- We can also attach the attributes to every BB that represent


-- 'normal' work hours

-- Attribute1
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr1,
p_attribute_value=> l_task_id,
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute2
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr2,
p_attribute_value=> l_project_id,
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute3
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr3,
p_attribute_value=> l_expenditure_type,
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute4
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr4,
p_attribute_value=> 'Expenditure Comment created by API',
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute5
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr5,
p_attribute_value=> l_system_linkage_id,
p_app_attributes=> l_tbl_attributes_info
);

END IF; -- Only for weekdays

END LOOP; -- End creating normal working days + time

-- And now we add the Overtime to Tuesday and Wednesday


-- We have to use create_time_entry here because we do not have the ID
-- for the Wednesday TBB anymore, using create_time_entry we do not need it
-- Tuesday

hxc_timestore_deposit.create_time_entry (
p_measure=> 1,
p_day => TRUNC (l_start_time)
+ 1,
p_resource_id=> l_person_id,
p_comment_text=> 'Created using API: OT',
p_app_blocks=> l_tbl_timecard_info,
p_app_attributes=> l_tbl_attributes_info,
p_time_building_block_id=> l_detail_bb_id
);

-- Attribute1
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr1,
p_attribute_value=> l_task_id,
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute2
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr2,
p_attribute_value=> l_project_id,
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute3
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr3,
p_attribute_value=> l_ot_expenditure_type,
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute4
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr4,
p_attribute_value=> 'Expenditure Comment created by API',
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute5
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr5,
p_attribute_value=> l_ot_system_linkage_id,
p_app_attributes=> l_tbl_attributes_info
);

-- Wednesday
hxc_timestore_deposit.create_time_entry (
p_measure=> 2,
p_day => TRUNC (l_start_time)
+ 2,
p_resource_id=> l_person_id,
p_comment_text=> 'Created using API: OT',
p_app_blocks=> l_tbl_timecard_info,
p_app_attributes=> l_tbl_attributes_info,
p_time_building_block_id=> l_detail_bb_id
);

-- Attribute1
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr1,
p_attribute_value=> l_task_id,
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute2
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr2,
p_attribute_value=> l_project_id,
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute3
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr3,
p_attribute_value=> l_ot_expenditure_type,
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute4
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr4,
p_attribute_value=> 'Expenditure Comment created by API',
p_app_attributes=> l_tbl_attributes_info
);

-- Attribute5
hxc_timestore_deposit.create_attribute (
p_building_block_id=> l_detail_bb_id,
p_attribute_name=> c_proj_attr5,
p_attribute_value=> l_ot_system_linkage_id,
p_app_attributes=> l_tbl_attributes_info
);

----------------------------------------------------------
-- END OF PART 1: POPULATE TABLES --
----------------------------------------------------------
----------------------------------------------------------
-- PART 2: DEPOSIT TIMECARD --
----------------------------------------------------------
-- Now we call the deposit process, passing in the PL/SQL tables we just
-- created and populated

hxc_timestore_deposit.execute_deposit_process (
p_validate=> FALSE,
p_app_blocks=> l_tbl_timecard_info,
p_app_attributes=> l_tbl_attributes_info,
p_messages=> l_tbl_messages,
p_mode=> 'SUBMIT',
p_deposit_process=> 'OTL Deposit Process',
p_timecard_id=> l_new_timecard_id,
p_timecard_ovn=> l_new_timecard_ovn
);

----------------------------------------------------------
-- END OF PART 2: DEPOSIT TIMECARD --
----------------------------------------------------------
END;

Common questions

Powered by AI

Setting up Oracle Time and Labor (OTL) involves several key steps, including defining a recurring element with responsibilities like Super HRMS and associating it with an 'Hourly Basis' salary. Next, create a link for payroll processing, define non-recurring elements such as Regular Hours and Overtime, and then map these to respective payroll functions. Assign OTL responsibilities, define alternate names, and manage recurring periods by setting start dates and defining approval periods to determine usage across applications. Additionally, create time entry rules and group them, establish approval styles, and finalize preferences for timecards. Finally, run processes like the Time Store Deposit API to handle time entry submissions and link them to payroll and HR functions .

Oracle Time and Labor facilitates flexible timecard entry and validation through its configurable framework. Users can define alternate names and assign preferences for specific business units or employee groups, providing a customized time entry experience. It enables settings such as timecard layout, approval periods, periodic entry types, and customized approval routes, which cater to diverse organizational needs. Additionally, timecard entry rules are controlled with mapping processes like 'BEE Retrieval Process' to ensure that mandatory fields are completed according to company-specific requirements. This adaptability ensures that timecard entries and their validations reflect the unique requirements of various workforce segments within different business functions .

Recurring periods and timecard layouts in Oracle OTL are interconnected and significantly impact time entry processes. Recurring periods define the structure of timecards, specifying the number of days or columns represented on the timecard screen, which in turn affects data entry and review workflows. For example, setting the period type to 'Week' ensures a consistent layout of seven days starting from a given start date. This structured design influences how data is captured and managed, impacting approval workflows and ensuring data aligns with organizational scheduling standards. Together, these configurations harmonize timecard operations with employee schedules and organizational policies, facilitating accurate time capture .

The setup of 'Approval Style' in Oracle OTL is crucial for defining the hierarchy and workflow necessary for timecard approvals. It establishes who within the organization possesses the authority to approve submitted timecards, thereby directly influencing the efficiency and accountability of timecard workflows. Typically, it might prescribe the immediate supervisor within HR and Payroll responsibilities to approve timecard entries. By defining approval hierarchies, organizations ensure that approvals are handled promptly and by appropriate personnel, thus mitigating delays and enhancing the integrity of time management processes .

Oracle Time and Labor ensures accurate payroll accounting by using several integrated processes. First, timecard entries feature both recurring and non-recurring elements that are linked to define payroll outcomes. These elements are validated through defined time entry rules groups, which ensure compliance with payroll policies. The system controls mandatory fields via mappings such as 'BEE Retrieval Process' and custom time entry rules. After timecard processing, transactions are transferred from payroll to the General Ledger (GL) using the 'Transfer to GL' process. Journal Import processes within GL assimilate these entries, offering a comprehensive accounting view, while costing details further refine payroll entries into accurate accounting records .

Oracle Time and Labor handles payroll adjustments for daily wage workers by categorizing time elements into recurring and non-recurring entities. For daily wage earners, salary is computed based on the hourly wage setup alongside defined salary basis calculations. Adjustments are precisely managed through non-recurring elements like Regular Hours and Overtime, which are processed according to specific business rules. Furthermore, time entry rule groups ensure adherence to these payroll conditions. For special wage categories like 'Premium Hours' or 'Hours not Worked', tailored configurations allow for nuanced payroll calculations. These setups facilitate the automated transition of timecard details into comprehensive payroll adjustments specific to wage types and hours worked .

The Time Store Deposit API in Oracle OTL is a crucial tool for managing timecard information programmatically. It allows for the creation, modification, and submission of timecard entries through PL/SQL tables. The API enables detailed configurations, such as creating building blocks for timecards and assigning project attributes. This flexibility allows organizations to integrate custom logic and validations into timecard processing, enhancing control over how timecard data is managed and used. Additionally, the Time Store Deposit API supports large-scale automation of timecard submissions, ensuring efficient handling of timecard data while maintaining accuracy and consistency across the system .

Oracle OTL manages approvals via functionalities such as 'Approval Style' and 'Approval Periods.' 'Approval Style' dictates the hierarchy and roles responsible for timecard approvals, often delegating responsibilities to immediate supervisors in both HR and Payroll functions. 'Approval Periods' define the specific times during which approval processes are active, allowing organizations to streamline approval workflows by coordinating timing with business cycles. Together, these functionalities ensure a structured and efficient approval management system, enhancing accountability and compliance across timecard processing operations .

Oracle OTL customizes payroll elements to accommodate different earning structures by allowing for the definition of both recurring and non-recurring elements like Regular Hours, Overtime, Premium Hours, and Hours not Worked. Each element is linked to payroll processing setups and categorized under earnings types such as US_EARNINGS and US_SUPPLEMENTAL_EARNINGS, permitting differentiated handling of workers' salaries. This customization extends to establishing unique salary bases like 'Hourly Basis' for daily wage earners and defining salary calculations via multipliers. By allowing organizations to tailor these elements, Oracle OTL supports diverse pay structures and integrates them seamlessly into the payroll system, ensuring comprehensive salary management .

Time Entry Rules in Oracle OTL play a vital role in enhancing payroll processing accuracy by enforcing strict compliance with business rules during timecard entry. These rules determine mandatory fields and establish parameters like maximum allowable hours to ensure entries conform to specified conditions. By organizing rules into groups and defining outcomes for rule violations, the system minimizes errors and automates checks that improve data integrity. Additionally, these rules facilitate the seamless mapping of timecard data to payroll elements, allowing for precise payroll computations and reducing discrepancies during payroll processing .

You might also like