This section describes the steps involved in migrating historical Personal Time and Expense (PTE), Project Time and Expense (ProjTE), and Oracle Internet Time (SST) timecard date Oracle Time & Labor.
To migrate existing timecard data to Oracle Time & Labor (OTL), a SQL script provided with OTL should be run as described below. All timecards entered via one of the existing applications mentioned, must be submitted and approved before they are eligible for migration.
During the migration to OTL, the system will prompt you to input parameter values that specify the historical data migrate. All of the selected online timecards (created from one of the applications mentioned) will be migrated to Oracle Time & Labor. After migration, these timecards will be visible from Oracle Time & Labor as historical records.
The migration script contain parameters you can use to select the transactions to migrate from ProjTE/PTE/Oracle Internet Time to Oracle Time & Labor. The parameters include:
Operating Unit ID (organization ID of the operating unit)
Incurred by Person Number (Employee Number)
Incurred by Organization Name
ONLINE_SST_OR_BOTH (1=PTE and OTE, 2+SST, 3=ALL)
Starting Expenditure Date (format DD/MM/YYYY)
Ending Expenditure Date (format DD/MM/YYYY)
The following parameters are required:
Operating Unit ID (for multiple organization installations)
Incurred by Person Number or incurred by Organization Name
ONLINE_SST_OR_BOTH
All other parameters are optional.
To Migrate Timecard data to Oracle Time & Labor
Log on to your server
Change your directory to:
$PA_TOP/patch/115/sql
Run the following migration script:
$ sqlplus <apps username>/<apps password> @ paxtmotl.sql <operating Unit ID> <Incurred by Person Number> <Incurred by Organization Name> <1 = PTE and OTE; 2 = SST; 3 = ALL> <Starting Expenditure Ending Date> <Ending Expenditure Ending Date>
An Example: the following command migrates Oracle Internet Time (SST) timecards for the operating Unit ID 458, incurred by person number 205, for week ending dates from 12-Dec-1999 through 21-Jan-2001, inclusive:
$ sqlplus <apps username>/<apps password> @ paxtmotl.sql 458 205 NULL 2 12.01/1999 21/01/2001
Note: The expenditure item comments will be truncated to 150 characters during the migration.
As part of the business rules for various legislations, absences may or may not be paid by the employer. In OTLR, these absences are any hours defined as Absences in the Element Time Information window. Cost for such hours recorded in the timecard may or may not be borne by the employer. In OTLR, paid absences are just like any Regular/Overtime hours that must be counted to Overtime Cap. Unpaid absences, usually are not included in Overtime Cap. In this note, you will see a couple of examples of timecard explosion with holiday/absence/overtime hours.
For the standard 40 hours work week, lets assume the following time entry pattern:
Days | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday |
---|---|---|---|---|---|---|---|
Time Worked | 10 | 10 | 10 | 10 | 10 | - | - |
Explosion | - | - | - | - | - | - | - |
Regular | 10 | 10 | 10 | 10 | - | - | - |
Overtime | - | - | - | - | 10 | - | - |
The table above depicts the explosion for the typical 40 hours work week, where the 10 hours of time worked on Friday is exploded into overtime, while the hours till then remains regular. This accounts for the legislative rule that anything over 40 hours of regular work, is to be paid as overtime.
If one of the days worked is a holiday, the explosion changes as follows:
Days | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday |
---|---|---|---|---|---|---|---|
Time Worked | 10 | 10 | 10 | 10 | - | - | - |
Paid Leave | - | - | - | - | 10 | ||
Explosion | - | - | - | - | - | - | - |
Regular | 10 | 10 | 10 | - | - | - | - |
Overtime | - | - | - | 10 | - | - | - |
Paid Leave | - | - | - | - | 10 | - | - |
Note the explosion here. Paid Leave is an element that cannot be exploded into another type of element, for example regular or overtime, hence for the purpose of Payroll processing, it is retained as paid leave. However, Paid Leave must be counted to Overtime Cap, and the total number of hours in the week (including worked hours and paid leave) is 50 hours, and this implies 10 hours of overtime. In the example above, the last day is paid leave. The application automatically picks up an entry from the earlier day, originally paid as Regular and explodes it as Overtime.
Let us look at the following example where an employee recording 50 hours in the work week, with Friday, being recorded as paid leave. In this case, the application tries to reverse explode the 10 hours of paid leave to Thursday. However, Thursday is a previous timecard and it is not within the same payroll period - it might even have been processed in a different way. In such a scenario, the application displays an error:
To ensure that no overtime hours that must be accounted because of absence or other overridden hours are exploded into previous timecards, when they fall in the same work week, and that such time entries are processed without an error, if the payroll periods are Semi Monthly or Monthly while the timecard periods are weekly, the time entry must explode as shown in the following table:
Date/Days | 27 June Monday | 28 June Tuesday | 29 June Wednesday | 30 June Thursday | 1 July Friday | 2 July Saturday | 3 July Sunday |
---|---|---|---|---|---|---|---|
Time Worked | 10 | 10 | 10 | 10 | - | - | - |
Paid Leave | - | - | - | - | 10 | ||
Explosion | - | - | - | - | - | - | - |
Regular | 10 | 10 | 10 | - | - | - | - |
Overtime | - | - | - | 10 | - | - | - |
Paid Leave | - | - | - | - | 10 | - | - |
To ensure the explosion happens as defined in the table above, ensure you set the profile option HXT: Adjust Overtime To Previous Timecard Within Same Workweek to Yes.
See: Profile Options
See: Earning Group
See: Earning Policy
Note: Note: For CBS enabled projects, the Task list displays the task and cost code combination. For further information, See: Oracle Projects User and Implementation Guide.
You can customize the Projects Timecard Layout in Oracle Time & Labor by:
Controlling Access to Oracle Projects data
Using Oracle Projects Client Extensions
You can configure List of Values for Project, Task, Type, and Overriding Approvers to meet your requirements. To do this, modify the WHERE clause in the corresponding view listed in this section.
Views are associated with the timecard preparer (that is, the person logged into the system). Because these views are used for validation and display, be sure to set up the view so that the timecard preparer can select the projects for which he is entering hours.
You can customize the following views:
Projects View
Task View
Expenditure Type View
Overriding Approver View
View and Internal Name | |
Project View PA_ONLINE_PROJECTS_V |
NA Default allows user to view all projects. Sample code specifies that projects selected must be within the user's organization. Do not modify the base view PA_PROJECTS_EXPEND_V |
You can use Oracle SQL Developer to replace the predefined view.
See: Notes on Terminology and File Locations
By default, the user can view all projects when selecting the Project LOV. In large implementations, this list may be very long, and by customizing this view the values returned by the Project LOV can be reduced to those applicable to the business processes implemented in your enterprise and to the preparer of the timecard.
For example, some implementations may have thousands of projects, but many workers will only be working on a few. By customizing the view, the list of projects displayed is restricted to only those that are valid for the user.
View and Internal Name | Notes |
Task View | |
PA_ONLINE_TASKS_V | Default allows user to view all tasks. Sample code specifies that tasks selected must be within the user's organization. Do not modify the base view PA_TASKS_EXPEND_V |
You can use Oracle SQL Developer to replace the predefined view.
See: Notes on Terminology and File Locations
By default, the user can view all tasks when selecting the Task LOV. In large implementations, this list may be very long, and by customizing this view the values returned by the Task LOV is reduced to those applicable to the person preparing the timecard.
For example, some tasks in the work breakdown structure of a project may not be chargeable. The view may be customized to return only those tasks that are chargeable.
View and Internal Name | Filename of Scripts* and Notes |
Expenditure Type View PA_ONLINE_EXPENDITURE_TYPES_V |
pavw742.sql Default allows user to view all expenditure types. Sample code specifies that users in the Consulting organization (organization_id=1) can enter only transactions of type Straight Time. Do not modify the base view PA_EXPENDITURE_TYPES_EXPEND_V |
* Scripts are located in the $PA_TOP/patch/115/sql directory.
See: Notes on Terminology and File Locations
By default, the user can view all expenditure types when selecting the type LOV. In some situations it may be desirable to restrict this list.
For example, you may not want all users to have access to all expenditure types. By customizing the Expenditure Type View, the Type LOV can return only those expenditure types appropriate for the person preparing timecard.
View and Internal Name | Filename of Scripts* and Notes |
Overriding Approver View PA_EXP_OVRRDE_APPROVER_V |
pavw685.sql * Default allows user to view all supervisors in the preparer's business group. Sample code specifies that users can only select overriding approvers who belong to the user's organization. |
* Scripts are located in the $PA_TOP/patch/115/sql directory.
See: Notes on Terminology and File Locations
The Overriding Approver view allows user to view all supervisors in the preparer's business group. By customizing this view, the values returned in the Overriding Approver LOV can be tailored to return only those approvers applicable to the business processes implemented in your company and the users entering their time.
Terminology: In the 11i version of Oracle Projects, the overriding approver is called the approver.
File locations: Print and review the files before modifying an extension. The files are located in the following Oracle Projects directory: $PA_TOP/patch/115/sql
You can modify the following client extensions to route and approve timecards according to your requirements and to enforce any custom business rules. Client extensions are PL/SQL procedures that Oracle Projects uses when processing timecards. For more information, see: Client Extensions in the Oracle Projects User Guide.
You can use the following client extensions with Oracle Time & Labor:
Extension and Reference | Package Body and Package Specification Files | Package and Procedure |
Approval | PAXTRT1B.pls PAXTRT1S.pls |
PA_CLIENT_EXTN_RTE check_approval |
AutoApproval | PAXPTEEB.pls PAXPTEES.pls |
PA_CLIENT_EXTN_PTE get_exp_autoapproval |
Business Message Display | PAPSSTCB.pls PAPSSTCS.pls |
PA_TIME_CLIENT_EXTN display_business_message |
Routing | PAXTRTEB.pls PAXTRTES.pls |
PAROUTINGX route_to_extension |
Summary Level Validation | PAXTGTCB.pls PAXTGTCS.pls |
PAGTCX Summary_validation_extension |
Transaction Control | PAXTTCXB.pls PAXTTCXS.pls |
PATCX tc_extension |
The following Oracle Projects client extensions are used by Oracle Time & Labor:
The default for this extension returns the value of the profile option PA:AutoApprove Timecard. You can configure this extension to meet your needs. For example, you may want timecards to be approved automatically unless they contain overtime. Those with overtime must be routed to the employee's supervisor.
Timecard line level validation via Transaction Control extensions allow you to define your own rules to implement company-specific time entry policies for individual time entries.
Use the summary - level validation extension to check the validity of one or more items in a submitted expenditure. For example, you could automatically reject any timecard that contains more (or less) than 40 hours.
The extension includes the following items:
Item | Name |
Body template | PAXTGTCB.pls |
Specification template | PAXTGTCS.pls |
Package | PAGTCX |
Procedure | summary_validation_extension |
Print and review the files before writing the extension.
See: Notes on Terminology and File Locations
The extension uses the following parameters:
Parameter | Usage | Type | Description |
X_expenditure_id | IN | NUMBER | Identifies the expenditure. |
X_incurred_by_person_id | IN | NUMBER | Identifies the employee that submitted the expenditure. |
X_expenditure_end_date | IN | DATE | Ending date of the expenditure period. |
X_exp_class_code | IN | VARCHAR2 | Identifies the expenditure class (OT for timecards). |
X_status | OUT | VARCHAR2 | Denotes the status of the expenditure (APPROVED or REJECTED). See the About the status Parameter section. |
X_comment | OUT | VARCHAR2 | Comment to be passed back to the employee who submitted the expenditure. Stored as an expenditure routing comment. |
P_Timecard_Table | IN | PL/SQL Table | PL/SQL table holding the expenditure item information for the timecard. Only populated when P_Module = OTL. |
P_Module | IN | VARCHAR2 | Name of source product calling the routine. |
About the status parameter
Use the Status parameter (X_status) to handle error conditions for your procedure. This parameter indicates the processing status of your extension.
x_status = 0 The extension executed successfully
x_status < 0 An Oracle8 error occurred
x_status > 0 An application error occurred. Your extension must return an error message code.
Use the routing extension to set the business rules for routing timecards for approval. For example, timecards that contain overtime could be routed to the project manager of the charged project. By default, this extension returns the immediate supervisor of the employee who created the timecard.
The extension includes the following items:
Item | Name |
Body template | PAXTRTEB.pls |
Specification template | PAXTRTES.pls |
Package | PAROUTINGX |
Procedure | route_to_extension |
Print and review the files before writing the extension.
See: Notes on Terminology and File Locations
The extension uses the following parameters:
Parameter | Usage | Type | Description |
X_expenditure_id | IN | NUMBER | System-generated identifier of the expenditure |
X_incurred_by_person_id | IN | NUMBER | Identifies the employee who performed the work |
X_expenditure_end_date | IN | DATE | Ending date of the expenditure week |
X_exp_class_code | IN | VARCHAR2 | Identifies the expenditure type (OT for timecards) |
X_previous_approver_person_id | IN | NUMBER | Employee to whom the timecard was previously routed |
X_routed_to_person_id | OUT | NUMBER | Identifies the employee to whom expenditure is to be routed |
P_Timecard_Table | IN | PL/SQL Table | PL/SQL table holding the expenditure item information for the timecard. Only populated when P_Module = OTL |
P_Module | IN | VARCHAR2 | Name of source product calling the routine |
This extension determines if additional approval is required for the timecard. By default, there is no restriction on approval.
The extension includes the following items:
Item | Name |
Body template | PAXTRT1B.pls |
Specifies template | PAXTRT1S.pls |
Package | PA_CLIENT_EXTN_RTE |
Procedure | check_approval |
Print and review the files before writing the extension.
See: Location of Client Extension Files
The extension uses the following parameters:
Parameter | Usage | Type | Description |
X_expenditure_id | IN | NUMBER | System Generated identifier of the expenditure. |
X_incurred_by_person_id | IN | NUMBER | Identifies the employee who performed the work. |
X_expenditure_end_date | IN | DATE | Ending date of the expenditure week. |
X_exp_class_code | IN | VARCHAR2 | Identifies the expenditure type (OT for timecards). |
X_amount | IN | NUMBER | Amount of expenditure in hours. |
X_approver_id | IN | NUMBER | Application user ID of employee attempting to approve the expenditure. |
X_routed_to_mode | IN | NUMBER | Responsibility of approving employee (either SUPERVISOR or ALL). See: About the routed_to_mode Parameter. |
X_status | OUT | VARCHAR2 | Status of procedure. See: About the status Parameter. |
X_application_id | OUT | NUMBER | Short name of application defined in AOL. (PA for Oracle Projects). |
X_message_code | OUT | VARCHAR2 | Message code |
X_token_1-5 | OUT | VARCHAR2 | Message tokens passed back to use in a message. |
P_Timecard_Table | IN | PL/SQL Table | PL/SQL table holding the expenditure item information for the timecard. Only populated when P_Module = OTL. |
P_Module | IN | VARCHAR2 | Name of source product calling the routine. |
Depending on the navigation path, the routed_to_mode parameter contains the value SUPERVISOR (Review and Approve) or ALL (Review and Approve ALL).
You can use this parameter to allow the approver to circumvent the rules enforced by the approval extension. For example, you might want to use this parameter for a supervisor who needs to approve hours regardless of any special logic in your extension.
The billable percentage is calculation of the percentage of the hours in a timecard that are marked as billable. This extension contains an example that returns a message displaying the billable percentage for the timecard (the example is preceded by the comment character). If this example meets your requirements, remove the comment characters from the example code after enabling the profile. This displays the billable percentage message in Oracle Time & Labor.
Important: The example code does not return a message. You must set the profile option PA: Enable Business Messages on Time Entry to Yes to see your custom business message as defined in the Business Message Display extension.
The extension includes the following items:
Item | Name |
Body template | PAPSSTCB.pls |
Specification template | PAPSSTCS.pls |
Package | PA_TIME_CLIENT_EXTN |
Procedure | display_business_message |
Print and review the files before writing the extension.
See: Notes on Terminology and File Location
This package contains default logic to return a blank message.
The extension uses the following parameters:
P_Expenditure_Id | IN | Number | System-generated number that uniquely identifies the expenditure |
P_person_id | IN | NUMBER | Identifier of the person entering timecard information |
P_week_ending_date | IN | DATE | Period for which time is being entered |
X_message_application_name | OUT | VARCHAR2 | Short name of the application that "owns" the message |
X_mesg_name | OUT | VARCHAR2 | Message Name |
X_msg_token1_name | OUT | VARCHAR2 | Name for Token1 |
X_msg_token1-Value | OUT | VARCHAR2 | Token for message |
X_msg_Token2_name | OUT | VARCHAR2 | Name for Token2 |
X_msg_Token2_value | OUT | VARCHAR2 | Token for message |
X_msg_Token3_name | OUT | VARCHAR2 | Name for token3 |
X_msg_token3_value | OUT | VARCHAR2 | Token for message |
X_return_status | OUT | VARCHAR2 | Indicates the status of the procedure. Possible values include NULL, (Success), U, (Unexpected Error), or E, (Expected Error). |
X_message_data | OUT | VARCHAR2 | Contains the error message is Return_status is U, or E. Is Null if return_status = Null |
P_timecard_table | IN | PL/SQL Table | PL/SQL table holding the expenditure item information for the timecard. Only populated when P_module = OTL |
P_module | IN | VARCHAR2 | Name of source product calling the routine |
Oracle Time and Labor integrates with Oracle Payroll and Oracle Projects, enabling employees to enter and submit work based projects and payroll related timecards, using Oracle Time and Labor. To enable this integration, Oracle Time and Labor provides additional attributes in the work based projects and payroll layouts for the timecards.
You can use the timecards that you import from OTL to Oracle Projects to calculate project labor costs or distribute payroll costs to projects as labor costs. Using work based projects and payroll timecard layouts in OTL, you can capture time card attributes that Oracle Projects uses to derive actual payroll rates from project rate schedules or Oracle HR's Rate by Criteria pay matrices when your labor costing method requires a standard rate. You can also use the attributes to derive a rate using your own custom extension as a rate source.
OTL supports two types of project time card layouts: existing project and payroll time cards or work based Project Payroll layouts time cards. Only the work based time card layouts support the additional rate determination attributes. To use the work based layouts you must enable the Projects Payroll Integration preference in your OTL preferences.
If OTLR is enabled for the integration, then to transfer timecards to Oracle Projects, you must first transfer them to OTLR and then use the transfer to Projects Accounting/Transfer to Porj Act (Retro) concurrent programs to complete the process.
Expenditure Type and SLF details entered using the Time Entry window are transferred to Oracle Projects as they are entered in the application. Alternatively, if you use elements generated by OTLR such as overtime or premium, you can associate the Expenditure Type and SLF to an element using the element time information window.
See: Default Preferences
See: Timecard Layouts
See: Timecard Templates
See: Integrating with Oracle Time and Labor, Oracle Projects User Guide
Oracle Time and Labor integrates with Absences to provide an additional method to capture absence information in addition to the existing ways. With the integration of OTL with the Absences module, the OTL application automatically imports absence entries created in Self Service HR or HR Absences module onto a worker's timecard when the worker opens a timecard for time booking. You can capture/edit absences from OTL timecard and you do not require to use different applications to record absence information and to record time worked.
The OTL Administrators or OTL Application Developers set up the integration feature. Once this integration is set up, the OTL application automatically imports absence entries created in Self-Service HR or HR absences modules onto a worker's timecard when the worker opens the timecard for a time booking.
Important: If you use absence integration, then you cannot create or update the absence type from Self-Service or HR if a timecard exits for that time period.
A brief overview of how the integration works is depicted in the following diagram:
Once you enable and set up Absences Integration, absence entries from Oracle HR and the Self-Service Absences modules automatically display on the OTL timecard. Workers can view and update the timecard with time entries directly from their OTL timecards. When workers save these entries, the OTL application validates the timecard based on time entry rules and other existing checks. The timecard containing absence entries and time entries is then stored in the OTL time store. When the timecard is submitted for approval, the approval system triggers and sends the timecard for approval. Absences are posted to Oracle HR automatically with timecard actions (Save, Submit or Approve) based on the online retrieval preference.
Important: The OTL transfer process excludes absence entries time entries when moving the data to workers' assignments.
If OTL Rules Evaluation preference is set to Yes, then the application transfers the absence entries populated or entered in the timecard to the Entry/Validation/Approval window to enable time processing based on time management structures and policies. Such absences are view only and cannot be edited in the Entry/Validation/Approval window.
To set up OTL Absence Integration, complete the following steps:
Set the HR: OTL Absence Integration Setup Profile Option to Yes.
Set the HR: Schedule Based Absence Calculation Profile Option to Yes.
Set the HR: Absence Duration Auto Overwrite Profile Option to Yes.
Create a new Preference node for absences. Ensure you select Time Store Absence Integration Setup for Worker as the preference, and select Yes as the Preference Values to integrate absences with OTL.
See: Defining Preferences
Set up Elements for absence integration. OTL Administrators must create as many elements as required for payroll with the input value Days to capture day based absences or with input value Hours to record hour based absences.
Note: Ensure that you use the Days element input value for those elements that you link to absence attendance types only. Do not use this input value for regular payroll time worked elements.
Ensure Absence Attendance Type is set up.
See: Defining an Absence Type, Oracle HRMS Compensation and Benefits Management Guide
Create an element set with the type Run Set and include all absence elements.
See: Defining an Element or Distribution Set, Oracle HRMS Compensation and Benefits Management Guide
Run the Generate Flexfield and Mapping Information concurrent program ensuring you select the element set you created and selecting Yes in the Include Absences Information list to import absences into OTL.
See: Running the Generate Flexfield and Mapping Information Process
Configure absences types in OTL. Set the absences to View only or View and Edit per business requirements. Additionally you can create new Alternate Name Definition or append to the existing Alternate Name Definition.
In the Payroll Preferences node, select Self Service Timecard Alternate Name Set Defined for a User. Add the Alternate Name Definition you used in the Configure Absences Type page to the Timecard Alternate Name parameter. If you use the Timekeeper functionality, then you must append the new absence types to the existing alternate name definition with the help of the new absence types screen.
See: Default Preferences
Use the integrated features from Oracle HRMS and Common Application Components (CAC) to set up information such as shifts, schedules, and calendar events to help you determine a worker's availability.
See: Setting up Availability, Oracle HRMS Workforce Sourcing, Deployment, and Talent Management Guide
You use the Configure Absence Types page to set the absences to View only of View and Edit per your business requirements. You can also use this page to create a new Alternate Name Definition or append to the existing Alternate Name Definition.
To configure absence types:
Enter the search criteria for the absence type and click Go.
Set the absence type to View Only or View and Edit based on your requirements.
From the search results, select the absences to create an alternate name definition. Alternatively, append the absences to an existing alternate name. If you use the Timekeeper functionality, then you must use this page to append the new absence types to the existing alternate name definition.
From the search results, select the absence type and an option to create a time category. Alternatively, append the absence type and option to an existing time category name.
To use absence types with time management structures, you must define an additional step of element time information. Define an absence type with Absence Earnings as the earning category. Provide day based absence type with Days to Hours conversion factor.
For more information, see: Timecard – HR Absences Integration My Oracle Support Note: 1122794.1.
Preferences allow you to assign rules and options to your workers. It also lists the values that are predefined as default preferences. You can override the defaults by creating new preferences hierarchies.
In the Preferences window, you can see the Default Preferences by expanding the Preference Tree node.
The following table shows the preference values when using the nodes Default Preferences and Default Preferences - EAM.
The Self Service node contains the predefined preferences of Worker. The Worker preferences relate to functionality directly associated to an individual.
Preference Name in Tree (Preference Name) | Description | Value in Default Preferences Hierarchy |
---|---|---|
Append Templates on Timecard (Self Service Functionality to Append Templates on Timecard) | Y/N. If set to Yes, then the worker can select more than one template and the data from all the selected templates appears on the timecard. | No |
Business Messages (Self Service ability to show a business message) | Y/N. If set to Yes, then business messages from time entry rule validation display to the worker on the timecard | Yes |
Create Personal Templates (Self Service create template functionality) | Y/N. If set to Yes, then workers can create their own personal timecard templates. A Create Template button displays on the Template page. | No |
Date Formats (Self Service date format functionality | Determines the display of date formats for the timecard. You can choose the date format for the Period List, Timecard Table Day Header, and Timecard Details Page Day Header. | December 31, 2002.Tue, Dec 31.Tuesday, December 31, 2002 |
Default Approver (Worker Default Approver) | If the Enter Override Approver preference is set to Yes, then you can select any supervisor in the business group to be the default value in the Override Approver field. | [None] |
Disconnected Entry (Self Service disconnected entry option for worker) | Import, Import/Export, or None. Determines whether workers can enter time and labor data using a spreadsheet (import) and whether they can download data to the spreadsheet (export). | [None] |
Enter Negative Hours (Self Service ability to enter negative hours) | Y/N. If set to Yes, then workers can enter negative hours on their timecard. | No |
Enter Override Approver (Worker Preference to enter an overriding Approver) | Y/N. If set to Yes, workers can enter an override approver on the timecard. Note:You must also set the Override Approval Style segment of the Approval Style preference to Projects Override Approver. | No |
Number of Empty Rows on the Timecard (self Service number of empty rows on the timecard) | Determines the number of empty rows to display on the worker's default timecard. | 1 |
Number of Recent Timecards Displayed (Self Service number of recent timecards on Time Entry screen) | Determines the number of previously entered timecards to display. | 5 |
OTL Rules Evaluation (Self Service preference to allow Rules Evaluation) | Y/N. Set the Evaluate OTL Rules segment to Yes for workers whose time is subject to OTL rules based on a rotation plan and earnings policy. If set to Yes, then use the Approval Rules for Rules Evaluation segment to select the applications that must approve the data before you can run the Transfer to BEE process. You may also select an Overtime Recurring Period to calculate overtime for non-weekly payrolls. | No |
Save as Template on Timecard (Self Service save as template functionality on timecard) | Y/N. If set to Yes, the Save As A Template button displays on the worker's timecard. | No |
Self Service Flow | Audit or Standard. If set to Audit, you would also use the Change and Late Audit Preference node. If set to Standard, you choose not to use Change and Late Audit. | [None] |
Template Assigned Value - Administrator (Self Service Default Template assigned by Sys Admin) | Determines default template assigned by the system administrator. | [None] |
Template Assigned Value - End User (Self Service Default Template Selected by User) | Determines default template selected by worker. Check the Editable by User check box if you want workers to be able to select their own default template. | [None] |
Template Functionality (Self Service Template Functionality for a Worker) | Y/N. If set to Yes, then workers can use templates. | No |
Timecard Alternate Names (Self Service timecard alternate name set defined for a user) | Determines the set of alternate names used to configure list of values on workers' timecards. You must define Timecard Alternate Names | [None] |
Timecard Delete Allowed | Yes/No. If set to Yes, workers can delete timecards. | [None] |
Timecard Layout (Self Service Timecard, review, and confirmation layout pages for a worker) | Determines which timecard layouts workers use for data entry, review, confirmation, detail page, and for export. If you leave the Export segment blank, then you use the Timecard entry layout for export. | EAM Timecard Layout, EAM Review Layout, and EAM Confirmation Layout. |
Timecard Period (Self Service timecard Period for worker) | Determines which recurring time period workers use for timecard entry. | Weekly - Starts Sunday |
Timecard Unit of Measure (Self Service Unit of Measure to be used on a timecard) | Determines the units in which workers enter time and labor data, such as days, hours, pieces, and time units as well as the format for entering time. | Hours HH:mm |
timecard Status Allowing Edits (Self Service timecard status that allows user edits) | Determines which timecards can be edited, according to their status and their date. In the Status Allowing Edits field, select a status: New_Working_Rejected - Workers can only edit unsubmitted timecards, or those in a working or rejected status. Submitted - Workers can edit new, working, rejected and submitted timecards. Approval Initiated - Workers can edit new, working, rejected, and submitted timecard, plus those with an initiated approval process. Retro - Workers can edit all timecards, including submitted, approved, and processed. Adjustments made at this point create a Retro Time Adjustment. In the Past Number of Days fieldenter the age, in days, or the oldest timecard a worker can edit. Timecard for the period in which this day falls can be edited. In the Future Number of Days fieldenter how many days in advance a worker can enter a timecard. For example, if you enter 28, a worker can enter timecards for all periods up to and including the period that includes the 28th day. Note: A timecard can be edited if it has a status that allows edits AND it is for a timecard period that falls within the date limits set by this preference. |
New, Working, Rejected Day fields are blank, meaning there is no time limits on entering and editing timecards. |
The time store hierarchy contains the preferences that relate to the functionality of the time store and applications.
Preference | Description | Default Value |
---|---|---|
Application Set (Time Store Application Set) | Determines which applications retrieve workers' timecards - you must define at least one application set. | Enterprise Asset Management. |
EAM Approval Periods (Time Store Approval Periods) | Determines the approval time periods for each application. | Weekly Periods - Starts Sunday |
EAM Approval Style (Time Store Approval Style) | Determines the approval rules and method for each application | OTL Auto Approve |
Auditing Requirements (Time Store Audit Requirements) | Determines whether entries will be audited using Change and Late Audit. If Change and Late Audit is selected, you must enter your Change and Late Audit rules. | [None] |
Entry Level Processing Rule Groups | Defines the entry level processing time entry rules to be used to validate the worker's timecard | [None] |
Retrieval Rule Groups (Time Store Retrieval Rule Groups) | Determines the retrieval rules for each application's retrieval process. The retrieval rules define the approval status data must achieve before it can be retrieved. You must define a Retrieval Rule Group. Note: Ensure that a worker's retrieval rule group does not contain rules for applications that are not in the application set. |
EAM Retrieval Rule Group |
Timecard Required (Time Store Time Required for Worker) | Lists any applications that do not require a timecard | [No applications] |
Time Entry Rule Groups (Time Store Time Entry Rules) | Defines the time entry rules to be used to validate the worker's timecards | [None] |
Oracle Time and Labor integrates with Oracle Services Procurement to provide visibility into Services Spending, controlling input of overtime and shift differentials of contingent workers, and validation of purchase orders against pre-authorized amounts.
See: Oracle Procurement - Services Procurement Technical Brief on My Oracle Support Note: 567411.1