260 likes | 435 Views
OTL and NON-Payroll Hours. Presented for Atlanta Oracle Application User Group on Nov 18, 2005. Ajoy A. Devadawson & Sheryl A. Bishop CIBER Inc. 1) Profile of the Company.
E N D
OTL and NON-Payroll Hours Presented for Atlanta Oracle Application User Group on Nov 18, 2005 Ajoy A. Devadawson & Sheryl A. Bishop CIBER Inc.
1) Profile of the Company • Manufacturing Company in businesses like slag and steel mill services, construction, aggregate production and distribution, concrete, asphalt manufacturing, road construction, trucking and transportation logistics. • More than 1000 employees. • Most of the business systems were either on home-grown technology or manual. • Mostly blue collar employees, with limited access and exposure to computers. • Locations in more than 2 dozen sites all over the country
2) EXPECTATION OF OTL AND NON-PAYROLL HOURS • To transfer Payroll Hours through timekeepers’ time entry. • To track the equipment usage hours to Project Accounting for costing and billing. • To track labor hours for Enterprise Asset Management (EAM) Work orders to optimize the fixed assets. • To track labor hours for Batch Operations in Process Manufacturing (OPM).
4) SAMPLE TIMECARD • There are some hidden fields to the right of Project and Task, which • are part of DFF.
5) TIMECARD CONFIGURATION • A timecard has to be configured through the flexfield • and other OTL screens to be used as a EAM or Projects • or OPM Timecard. • The flexfield contexts can be used to construct different types • of timecards, namely EAM, Projects, Process • Manufacturing etc. • Layout of timecard revolves around the DFF – OTL Information • Types.
Figure 3a – Timecard Context • The example shows the configuration for EAM Context. Please note that there is no need for Value set here. • Time elements can be configured.
Figure 3b – Timecard Segments • Additional segments can be added to the existing contexts. • The Generate Flexfield and Mapping Information process can generate • contexts and segments, after the changes.
Figure 4 – Mapping Components • The Mapping Components link the DFF segments to the timecard • layout fields. • The mapping component specifies where it is stored in TimeStore and • it is needed whenever new segments and contexts are created. • All the seeded DFF contexts come with seeded mapping components.
Figure 5 – Alternate Name Mapping • Alternate Name Mapping maps values in a Value Set to a Mapping • Component. • All the Value Set Values, Meaning, ID are available for mapping.
Multiple segments can be populated with one value set. • Alternate Name mapping serves both as a LOV and also as a validation. • In this example we are mapping EAMWORKORDER component with the wip_entity_id column which represents released Work Orders.
Figure 6 – Alternate Name Definitions • Alternate Names definition maps an Alternate Name to a timecard • layout field. • Specifies the prompt on timecard.
Figure 7 – Preferences / Timecard Fields • Individual timecard preferences. • Individual worker preferences. • Individual timekeeper preferences.
Figure 8 – Eligibility Criteria Rules • Assign preference hierarchies to people via eligibility rules. • Link by responsibility, location, organization, all people, single • person etc. • Precedence used when person eligible for more than one hierarchy.
6) TIMECARD LAYOUT STEPS • The following steps have to be followed, if a new Application module needs data or if existing modules need additional data. • Create a new context for data not captured by new contexts. E.g. OPM Context for Oracle Process Manufacturing data to be sent OPM module. • Create new segments for existing contexts which lack individual data items. E.g. Timestamp for Projects and EAM contexts, which is not part of the seeded context. • Run Generate Flexfield Mapping Process, which adds context to mapping components. • Create Value set for validation and LOVs. • Create Alternate Name Mapping • Create an Alternate Name Definition • Add Alternate Name definition to a Timecard Layout • Assign Layout to people / responsibilities.
7) RECIPIENT APPLICATION SETUPS • The recipient applications like Enterprise Asset Management, Project Accounting, Process Manufacturing need some setups within OTL to transfer and validate data.
Figure 9 – Time Categories • Time Categories identifies groups or categories • of fields that will be analyzed by time entry rule formulas.
Figure 10 - Application Sets • Specifies one or more applications that receive a worker’s • timecard data. • Can create custom application sets, if seeded applications • does not satisfy the requirements. • OTL checks worker’s set against approval, retrieval and entry • level processing rules.
Figure 11 - Preference Hierarchy - Application Sets • Assign application set to worker time store preference. • Link groups of people or individuals to application set via • hierarchy branch.
8) VALIDATIONS • OTL has robust set of validations which can be done at the Timestore itself, before it is transferred to receiving applications. • The validations can be both for Payroll and other receiving modules.
Figure 12 – Entry Level Processing Rules (ELPR) • OTL uses seeded validation processes specific to receiving modules. • The Entry Level Processing Rules can associate recipient • application with time category (time fields).
The Eligibility Criteria Rules link group of people or individuals to ELPR. • Example : “if any field in EAM time category is populated, then • execute the EAM seeded validation process.
Figure 13 - Time Entry Rule Groups • Custom validations can be introduced through Time Entry Rules • (TER), which can be enforced through a Fast Formula and a package. • TERs work on a specific time entry categories. • Example : EAM/PAY timecard • - When entering any work order related field, require all work order • related fields. • - Require payroll element to be entered
9) RECIPIENT APPLICATION IMPORTS • The Recipient applications have their own import interfaces. • The recipient applications are Projects, Enterprise Asset Management and Process Manufacturing. • The seeded ‘Transaction Import’ process creates expenditure records for the labor cost in the Projects expenditure tables, which transfers the labor hours into Projects • The custom process ‘OTL Equipment Usages’ transfers the equipment usage hours to Projects. The equipment usage hours have to be transferred for project costing for both in-house and customer projects and customer billing. • The seeded process for EAM transfers Work Order labor hours for asset management. • The custom process for OPM transfers labor resource hours to batch operations to determine the final product cost.
10) PITFALLS / CHALLENGES IN IMPLEMENTATION • The timecard screen rolled-up all the lines of a worker with multiple records on the sameday. A timestamp has to be created to avoid the rollup. • For example, a worker who has worked on multiple machines on the same day would have full 8 hours posted in 1 record, ignoring the machine he worked on. • There was a disconnect between validations of receiving modules like Projects and OTL. • We moved the Projects validation to OTL itself, to avoid the disconnect. • The initial design of timekeepers and approvals was a time-consuming process because of human, ease-of-use and political issues.
QUESTIONS & ANSWERS CONTACT : adevadawson@ciber.com sbishop@ciber.com