Oracle Applications
My learnings and views on Oracle Applications, Human Resource Management System, Oracle Time & Labor, Oracle Applications Framework, Business Process Execution Language and Service Oriented Architecture.

Change and Late Audit is one of the most important functionalities of Oracle Time & Labor. Change and Late Audit feature known as CLA allows system to identify the time or attribute information on Timecard which should be audited and requires to enter an explanation/comment of why a change was made to the timecard or why the entry is late. It is an optional feature and doesn't fall into the mandatory setups of OTL.

What is a CHANGE entry and what is a LATE entry? Change and late rules are not fixed entities and can be configured through the appropriate OTL preferences and Time Entry Rules. Even the list of reasons for auditing is configurable. Change and Late audit enables you to track all changes to new Timecards, as well as previously saved and submitted Timecards. These changes include modifying a saved or submitted timecard and saving timecards after a defined due date. For example, you may wish to have workers enter a reason why they changed their hours worked on Friday from 4 to 6, or why an hours type was changed to overtime from regular.

CLA feature was added to OTL to comply with the US Defense Contractor Audit Agency [DCAA]. As in a change and audit scenario, you have to track all the changes , a basic building block upon which our tracking attributes are based on can't be deleted. Hence a Timecard once created, can't be deleted. An hour entry made against a day for a particular receiving application attribute can't be deleted. So what's the solution in a scenario where audit is enabled and a Timecard has to be deleted or a wrong hour entry value has to be deleted? Only option, set the hour entries to zero.

Considering the above fact, the very first preference change for CLA setup is to disable the "Delete Timecards". This will disable the delete icon on the Recent Timecard Page.

Next preference to be modified is the "Self Service Process Flow" preference. This preference needs to be set to "Audit" from the default value of "Standard" which will add the CLA logic to the normal timecard processing flow and will prompt for Change & Late reasons if they are required to be entered as per setup.

As CLA functionality will require a new screen to show the change, late entries and prompt user to provide reason/comment, this new screen is provided through the Audit Layout. Hence Audit Layout needs to be added to "Self Service Timecard Layout" preference. This preference will already have the values for the Timecard, Review and Confirmation layouts at a minimum. When CLA is enabled for employees, you definitely would like to show those audit information to approver also. That means you also need to set the CLA Approver layout.

Now to determine which entry is late and which is a change, we need to create time entry rules. Attach these rules to a Time entry rule group and assign the rule group to a person through the preference. Existing seeded rules can be used a starting point for any custom rule development.

CLA feature was initially enabled for Self Service Time Entry only and later on was developed for Timekeeper also.

 

In the previous post Timecard Layout Modification, we saw the basic setup changes required for the addition of new Context OHUGLOCATION in the OTL Time Store and the further steps to create/add the corresponding mapping component.

Lets see now, how do we modify the timecard layout LDT files.

Step 1. Define the data source for New Location Field

OTL provides 10 custom view objects which save the effort of creating/managing new database object.


Name : CustomXVO
Class Path : oracle.apps.hxc.selfservice.timecard.server.CustomXVO
View : HXC_CUI_CUSTOMX_V where X stands for 1 to 10

We will use Custom1VO for location choice list. Make sure that this view is not already in use.

create or replace view HXC_CUI_CUSTOM1_V as
select
STATE_NAME display_value,
STATE_CODE value
from
PAY_US_STATES
Step 2. Define AK Attribute

This attribute will be used to provide the column heading for the location field on timecard. OTL is not fully migrated to MDS and some aspects of it are still dependent on the AK.


Step 3. Layout Changes

Change the following layouts
  • Timecard : Timecard Entry Screen.
  • Review : Timecard Review Screen.
  • Confirmation : Timecard Confirmation Screen.
  • Notification : Notification screen as seen by the Approver.
Optional Layouts
  • Details : To capture extra details like DFF fields.
  • Export : For Disconnected Time Entry.
  • Approval Fragment : Used when multiple applications are used in single Timecard like Project and Payroll.

Make the following changes to each of the seeded layouts mentioned above
  • Change the HXC_LAYOUT field value
  • Change the DISPLAY_LAYOUT_NAME field value
  • Do a Search and Replace All for the old DISPLAY_LAYOUT_NAME with the new name
  • To add a new Choice List, copy the seeded Cost Center component and paste below Cost Center.
  • Comment off the Cost Center field. # sign can be used to comment out the lines from layout files.

Ensure the following fields are set properly for the new component. These setting will change based on the type of component used.
  • Component header name
  • Component_Value
  • Attribute_Code set to AK Attribute created above
  • Sequence : Determines the sequence of components on Timecard
  • Parent_Component
  • Comp_Qualifier Header
  • Attribute1 : Custom1VO
  • Attribute10 : Custom1VO class path
  • Attribute26 : OTL Information Type DFF Context
  • Attribute27 : Corresponding Segment from the Attribute26 context
  • Attribute30 : Y for all the layouts except Timecard entry. A value of Y makes this component as Read Only
Location component LDT entry should look like below:
BEGIN HXC_LAYOUT_COMPONENTS "OHUG Payroll Timecard Layout - Locationr"
OWNER = "ORACLE"
COMPONENT_VALUE = "OHUGLOCATION"
REGION_CODE = "HXC_CUI_TIMECARD"
REGION_CODE_APP_SHORT_NAME = "HXC"
ATTRIBUTE_CODE = "OHUG_HXC_LOCATION_PROMPT"
ATTRIBUTE_CODE_APP_SHORT_NAME = "HXC"
SEQUENCE = "195"
COMPONENT_DEFINITION = "CHOICE_LIST"
RENDER_TYPE = "WEB"
PARENT_COMPONENT =
"OHUG Payroll Timecard Layout - Day Scope Building blocks for worker timecard matrix"
LAST_UPDATE_DATE = "2004/05/24"


BEGIN HXC_LAYOUT_COMP_QUALIFIERS "OHUG Payroll Timecard Layout - Locationr"
OWNER = "ORACLE"
QUALIFIER_ATTRIBUTE_CATEGORY = "CHOICE_LIST"
QUALIFIER_ATTRIBUTE1 = "Custom1VO"
QUALIFIER_ATTRIBUTE4 = "N"
QUALIFIER_ATTRIBUTE8 = "DisplayValue"
QUALIFIER_ATTRIBUTE9 = "Value#NUMBER"
QUALIFIER_ATTRIBUTE10 =
"oracle.apps.hxc.selfservice.timecard.server.Custom1VO"
QUALIFIER_ATTRIBUTE17 = "OraTableCellText"
QUALIFIER_ATTRIBUTE20 = "N"
QUALIFIER_ATTRIBUTE21 = "Y"
QUALIFIER_ATTRIBUTE22 = "L"
QUALIFIER_ATTRIBUTE25 = "FLEX"
QUALIFIER_ATTRIBUTE26 = "OHUGLOCATION"
QUALIFIER_ATTRIBUTE27 = "Attribute1"
LAST_UPDATE_DATE = "2004/05/24"
END HXC_LAYOUT_COMP_QUALIFIERS
For a complete understanding of the above fields, go through the Timecard Configuration Whitepaper.

Step4. Upload Layouts to Database

FNDLOAD username/password@DBNAME 0 Y UPLOAD $HXC_TOP/patch/115/import/hxclaytlayoutsld.lct CustomLDT.ldt

After using the upload command, make sure to check the content of the log file generated from the upload process. If anything is wrong with the layout structure, that will be displayed in this log otherwise a success message will appear.


Step 5. Assign New layouts to User through Preferences


Step 6. Login as the user and verify the modification on each of the layouts.

Timecard Entry Page

Timecard Review Page


Timecard Confirmation Page

Mass Timecard Approval Page

Worklist Notification Page

 

Whenever it comes to OTL discussions, the following two questions are always on the top:

1. Why do we need to configure the Timecard Layout?

Well, talking of configuration requirement, every business has different requirements which a seeded layout can't fulfill. The standard attributes provided on the seeded layouts are more of as a way for quick testing of the setup and a template for further modification. As an example, on the Payroll Timecard, your business rule might require you to provide Accounting Group or Supervisor or a day by day comments information apart from the Hours Type, Cost Center attributes and the hours value.

Along with business requirements, there might be scenarios to capture extra information to satisfy the legislative rule. One such rule which comes to my mind is Consultant taxation wherein if a person works in a state away from his home state for a specific number of days, he should be taxed as per the worked state rules also. Hence we will have to capture the Location information also while entering the Time and transfer that location information as the Geocode value in one of the input values of the Hours Element. Rest payroll will take care of :)

There are also business requirements where you would like to show/hide some components on the timecard based on the responsibilty or role. This also calls for layout modifications.

2. Are you crazy, do we need to modify the LDT files manually to add/remove/modify any components like LOV, Choicelist, DFF, Text Field etc? Can't I use OAF personalization and extension?

It really sounds crazy enough but this is the real strength of OTL Timecard Configuration functionality. What OTL offers is a way of adding new components on the Timecard, be able to validate those values, save them in the Time Store and transfer to the Receiving Application and all this without writing any code.

All the changes without writing any code? Now this must be sounding good :)
How do we do that? I will be covering it in a separate article.

You can't use OAF personalization and extensions on OTL Timecard matrix.

And I know the OTL enthusiastics will be asking what about the OTLR questions? Another article sometime later.

 

This article is going to cover the steps required to make changes to OTL Timecard Layouts.

Goals of this exercise are:

1. Add a new field on Timecard Entry page which will allow users to select State value while entering the time. This location information should be stored as Attribute1 of the OHUGLOCATION context in OTL Time Store.

2. Cost Center field is to be removed.

3. State location information should be available to the Approver on Mass Timecard Approval screen and the Workflow notification page.


To keep the changes simple, In this entry I will cover only the steps required for the addition of new Context OHUGLOCATION in the OTL Time Store and the further steps to create/add the corresponding mapping component which will allow this value to get stored in proper place in Time Store without any code change. As we are talking about cost center attribute, its clear that it is a Payroll Time Card.

Before we start changes related to Time Card, have a look at the below image and understand the basic parts of a Time Card.


Step 1. Define a new Context, Segment in OTL Information Type Descriptive Flexfield

  • Navigate to System Administration -> Application -> Flexfield -> Descriptive -> Segments
  • Query for “OTL Information Type” in the Title field.
  • Unfreeze Flexfield Definition.
  • Create a new Context named OHUGLOCATION.
  • Create a segment with values
Name : Location Id
Column : Attribute1


Step 2. Generate Flexfield and Mapping process
  • From OTL Application Developer responsibility, run ‘Generate Flexfield and Mapping Information’ Process with the parameters
Delete Definitions : No
Effective Date : Current Date
  • Other parameters are optional.

Step 3. Mapping Components

Create a mapping component with values as shown in the screenshot


Step 4. Add Mapping component to Deposit Process


In case you want to save the new attribute information in the existing context, segment of the OTL Time Store like Dummy Element Context or Cost Context, then above steps are not required. Similarly, the mapping components can be modified to change the storage location of the time attributes.

We will see the Time Card layout related changes in the next blog entry.

 

In this article, I am going to show how to add the Hours Type in the Hours choicelist field on the Self Service Timecard. This process requires only a few setups and involves no code or layout change. I am assuming that the basic preferences setup like Timecard Layout, Approval Style, Approval Period, Timecard Period, Application Set, Retrieval Group etc are done.

It is often one of the most basic requirements to enable a different list of Hours type to employee Self Service Timecard based on some criteria like assignment, people group, etc....

Step 1. Create Elements and make sure that the Earnings Type is defined and one of the input values is "Hours". I am defining a regular and an overtime earning element. Earning type selection will decide a lot of things when we come to Time Management Rules like overtime, shift calculation etc.






Step 2. Link the elements to proper payroll.


Step 3. Create the Element set as per your requirement to build different sets of Hours Types.


Step 4. Run the Generate Flexfield and Mapping Information concurrent request. This process will take the Element Set created in the previous step.


Step 5. Create the Alternate Names. Here you can provide your custom, readable names to elements which will appear as hours type. Like I have given the name Shiv Regular Earning to element Shiv Regular. Make sure that records in Alternate Name section are enabled.


Step 6. Attach the above Alternate name to the Self Service Timecard Alternate Name Set Defined for a User node in the preference tree.



Step 7. Create an Eligibility Rule to attach the above preference to the test person.


Step 8. Login with the test person's credential and check the Hours Type list of values. Both the hours should be visible now on the Hours Type choicelist.