This tutorial deals with Fusion Payroll, and how it functions. In this part, we will discuss about the step-by-step instructions dealing with Balances, Balance Exceptions, and Balance Exception Reports.

Balances

As discussed in the previous part of the tutorial, a balance is a value that is accumulated over a period of time. The end result of a balance is always a value - money, hours, or any other numerical value. It is mainly used to calculate the net salary payable, any earnings accumulated (like PF, GF, etc.), deductions (social insurance, tax, etc.) for the employees.

There are two main aspects to a balance: the period of time over which it is to be accumulated or calculated, called the Balance Dimensions; and the input (feed) required for the calculation of the balance, called the Balance Feeds.

The task associated with it is Manage Balance Definitions.

The following steps instruct on how to manage balances in Payroll:

Go to the Manage Balance Definitions task under Define Balance Definitions.

1. Search for a balance’s name and click on the Search button. Click on the name of the required balance.

2. On the Balance Details page, click on Balance Dimensions on the left side (pictured in the screenshot below) to edit the respective components.

3. A list of Balance Dimensions will be shown. To edit the items, click on the Edit button and you will be provided with icons to edit them.

4. You can use the Add or Remove icons (circled in the screenshot below) to either add a new Dimension or to remove an existing Dimension.

5. To add a Dimension, click on the Add icon. On the Search and Add window that pops up, search for the required dimension’s name and select it. Then, click on the Apply button to add that Dimension to the Balance.

6. After you are done editing, click on the Submit button, followed by the Done button.

7. Click on Balance Feeds on the left side to view the list of Balance Feeds in the Balance.

Fig. 1 - The Manage Balance Definitions task

Fig. 2 - List of balances

Fig. 3 - The balance details

Fig. 4 - The Balance Dimensions

Fig. 5 - Editing the Dimensions

Fig. 6 - Adding a Dimension

Fig. 7 - The Balance Feeds

Balance Exceptions and Reports

Balance Exceptions are a mechanism to find any deviations or variances in calculations through the dimensions of the balance. You can define the criteria to be used in balance exception reports to identify overpayments, underpayments, and trends.

For instance, Balance Exception Reports can be used to find the deviations (or) variances in the balance of Net Pay of the employees for the past three months. The instructions below discuss the Balance Exceptions and Reports based on this example.

The following steps discuss the creation of a Balance Exception:

1. Go to the Manage Balance Exceptions task under Define Balance Definitions.

2. Click on the New icon (circled in the screenshot below) to create a new Balance Exception.

3. Select the Legislative Data Group from the dropdown list and click on the OK button.

4. Enter the details of the exception. For the Balance Name, use the Search… option to search and add the Balance Name to the exception.

5. Click on the Save button, followed by the Submit button. The Balance Exception will now be created.

Fig. 8 - The Manage Balance Exceptions task

Fig. 9 - The Manage Balance Exceptions page. The New icon is circled

Fig. 10 - Selecting a Legislative Data Group

Fig. 11 - Entering the details of the exception

Fig. 12 - Searching and adding the Balance Name

The following steps discuss the creation of a Balance Exception Report:

1. Go to the Manage Balance Exception Reports task under Define Balance Definitions.

2. Click on the New icon (circled in the screenshot below) to create a new Balance Exception Report.

3. From the dropdown list, select the Legislative Data Group and click on the OK button.

4. Enter the details of the Balance Exception Report and click on the Save button.

5. To add a Balance Exception, click on the Add icon (circled in the screenshot below). Select the required Balance Exception that is to be run by the report and click on the OK button.

6. Click on the Save button, followed by the Submit button.

Fig. 13 - The Manage Balance Exception Reports task

Fig. 14 - The Manage Balance Exception reports page. The New icon is circled

Fig. 15 - Selecting the Legislative Data Group for the report

Fig. 16 - Entering the details of the report

Fig. 17 - Adding a Balance Exception to the report

Fig. 18 - The exception shows up after its addition

Once the Balance Exception and Balance Exception Report are created, the report has to be run through the Reports module of Fusion. The Balance Exception process will then be run, and the Balance Exception Report will fetch you a list of results that satisfy the Balance Exception that you created.

Objective:

This article covers how to install Oracle Entitlements Server (OES) 11g, release 2, including the OES Administration. This also covers how to create a sample Oracle WebLogic Server (WLS) domain that is OES -enabled.

Oracle Entitlement Server (OES) is a fine grained authorization engine from Oracle and is part of Oracle Identity Management Suite.

Software Required for OES 11gR2:

There are two parts of OES:

1. Server side component(OES Administration console or Authorization policy manager-APM)

2. Client side component (Security Module-SM): There are various different types of security module (OES client side components). Weblogic security module is most common hence we are going to do the installation and configuration in Weblogic SM series.

In order to install OES 11gR2 server side component, you would need following softwares:

• Oracle Database (10.2.0.4+ or 11.1.0.7+ or 11.2.0.1+)

• JDK (1.6.29+)

• Oracle WebLogic Server (10.3.6 or 10.3.5)

• Oracle Repository Creation Utility RCU (11.1.2)

• Oracle Identity & Access Management Software (11.1.2)\

In order to install OES 11gR2 (11.1.2) client side component (WebLogic Security Module), you would need following software:

• Oracle WebLogic Server

• OES Client Software

OES Installation steps:

1. Install Database: This database will be used to create OPSS schema to store Authorization Policies. OPSS : Oracle Platform Security Services. For Database installation steps click here

2. Create OPSS schema using Repository Creation Utility(RCU). For RCU installation steps click here.

NOTE:  Select Oracle platform security services and Metadata Services from list of available schemas.

3. Install JDK 1.6

NOTE: JDK will be used to install WebLogic in next steps and also to run Application on Java Virtual Machine (JVM).

4. Install Weblogic server:

NOTE: You must install Identity & Access Management Software (this also contains OES software) inside MW_HOME.

5. Install Oracle Identity and Access Management(OIAM) software:

   runInstaller -jreLoc <Location_of_JDK

Note: When prompted for Middleware Home, provide directory that you used for Middleware Home in previous step. This step will create ORACLE_HOME containing OES software.

After installing the softwares, next step is to configure Weblogic Domain that will host Oracle Entitlement server(OES) Administration Console (also known as Authorization Policy Manager-APM).

NOTE: OES Administration Console (aka APM) is used to manage (create, modify, delete) policies.

     6.     Run Fusion Middleware configuration wizard to configure Weblogic Domain.

1]  Start Weblogic Domain creation Screen at

   $ORACLE_HOME/common/bin/config.sh and select Create New WebLogic Domain

    2] Now select the following Templates:

a) Oracle Entitlement Server for Admin Server (This will deploy APM application on              WebLogic Admin Server) and

b) Oracle Enterprise Manager (This will deploy EM application on WebLogic Admin Server)

NOTE: Installer will automatically select Oracle Platform Security Service (required by OES Admin Server) and Oracle JRF (required by Enterprise Manager).

3] Select WebLogic Domain directory – This directory will contain all WebLogic Server related Configuration  and run time files.

NOTE: WebLogic Domain Directory can be anywhere on server and need NOT to be inside middleware home (MW_HOME).

4] Provide OPSS schema details that you created while installing OPSS schema.

Note: This OPSS schema will hold OES policies and WebLogic domain related application policies.

5] Select WebLogic Administration Server and Managed Server

NOTE: There will not be any managed server for OES   

Now before migrating the weblogic Domain security store(containing applications, policies and credentials) from XML files to Database in (OPSS schema).

$MW_HOME/oracle_common/common/bin/wlst.sh $ORACLE_HOME/common/tools/configureSecurityStore.py

/oracle/apps/oes/mw/oracle_common/common/bin/wlst.sh /oracle/apps/oes/mw/iam/common/tools/configureSecurityStore.py -d $DOMAIN_HOME -t DB_ORACLE -j cn=jpsroot -m create -p welcome1

Here,

a) ORACLE_HOME is /oracle/apps/oes/mw/iam

b) MW_HOME is  /oracle/apps/oes/mw

c) Replace $DOMAIN_HOME with complete path of your WebLogic Domain Directory

d) welcome1 is password of OPSS schema

Once this is done, the output can be seen as,

Credential with map Oracle-IAM-Security-Store-Diagnostics key Test-Cred stored successfully!

Credential for map Oracle-IAM-Security-Store-Diagnostics and key Test-Cred is: GenericCredential

Info: diagnostic credential created in the credential store.

Info: Create operation has completed successfully.

Start WebLogic Admin Server (More on WebLogic Server Start-up here)

$DOMAIN_HOME/bin/startWebLogic.sh (When prompted, enter user weblogic and password you supplied during domain creation)

6]Access OES Administration Server Console (Authorization Policy Manager – APM)

http://hostname:admin_server_port/apm

NOTE: Here admin_server_port is the port that you configured during WebLogic Domain creation step

Login using

User ID- weblogic

password- which you have entered during WebLogic Domain Creation Step.

Objective :

In this article we will learn how to add custom attribute  in OIM .

OIM Customization :

OIM 11g R2 new user interface is probably one of the most expected new features of this release. The main reason for that is the great customization capability provided by the underlying technologies: Oracle ADF and Oracle WebCenter Composer.
OIM user interface customizations are easier now, and they 'survive' patch applications (there is no need to reapply them after patching). 

1) Following steps will show how the users are searched in OIM , and what are the basic attributes displayed after search to get an idea  of basic attributes already present .

->To search for user Click On Administrator>Users

-> Click on Search button

-> Click on User Login to Edit the user as shown in below screenshot .

-> Click on Modify User

Now suppose I want to add an extra field here like SSN or Salary or any other attribute in the basic information of the user . . Also for example in My Profile I want to add some extra attribute to appear . This same thing we will be implementing

-> Salary is one of the attribute which is not displayed in My Profile or while trying to edit the user . To make it appear we need to add it in user form , If we add a attribute there it creates a new column in the user table and entity objects get updated automatically based on the new column added. So let’s modify a user form .

2) To modify the user form  you need to go to System Admin Console and create a Sandbox. Customizations are not allowed without a sandbox so we need to create a sandbox first .

-> To create a new Sandbox click on Sandboxes

-> Click on Create Sandbox

-> Enter Sandbox name sb4custom , check Activate Sandbox option and click on Save & Close

3) Once Sandbox is created Click on Form Designer option available under Configuration .

4) Select Type as User and click on Search button  in the User Form

5) Click on User Form Name that appears in Search Result

User form holds all the attributes available for that user .In this the custom attribute is to be added .

6)  ->To create a custom field/attribute click on Custom button

-> Select Field Type(Text, Number,Checkbox,Date,Lookup). Since we want to add Salary attribute we will select Number as Field type.

-> Enter the value for Display Label as Salary .(This is the text that will appear on user form ). Display Width be 10 digits . Also give the Name of field  Salary which will be for internal use only and is never displayed to the users .

Once you click on Save & Close button the custom attribute is added to the user form .Users table get modified with new column and you will find  attributes gets updated in entity object and as well as  in VO objects .

7) No go and publish the activated sandbox .

Click on Yes

8) Again we will create and publish a sandbox (sb4cf) since it will not allow any customization without  sandbox . After this the new attribute will be available to all .

Following error will arise if Sandbox is not created :

9) Now we will add new attribute Salary . For that we need to customize the screen , no need to go to JDeveloper .

Go to Identity Self Service Console  and navigate to My Profile > My Information

->Click on Customize

→  View the source code  

→ I will select Basic Information area which I want to edit

→ Click on Edit

→ In the basic information section we want to add salary component for which you need to click on Add Content :

→ Search for Data Component  - My Information  and open it

→ If you have added attribute newly so you need to refresh it here to make it appear . Now Open UserVO1

Search for Salary attribute and click on Add( Since it’s a custom attribute c will be appended to it at last )

After clicking on Add select ADF Input Text w/ Label option .

Salary attribute will be added as the first component , we can move it and place it after last name . We can do this in panelFormLayout

Select panelFormLayout and Click on Edit to move the Salary after laft name .

Under child component you can move the attributes by clicking the up and down arrows .  Keep on clicking on down arrow until the Salary attribute appears after Last Name

Click on Ok once done you can close the source window .

→ Now you can see that Salary attribute appears at the required position

So we have completed the task of adding custom attribute to OIM.

.

Objective:

In the previous article we seen the Introduction of Middleware and different types of Web services. In this article we will learn about the Oracle Fusion Application architecture.

Oracle FMW Architecture:

It mostly comprises of Fusion Application and Fusion Middleware

Fusion Middleware:

It comprises of oracle application server. Middleware is a family of middleware products covering all the areas such as: BI(Business Inclusion), IDM(Identity Management), Content, SOA, BPEL.

Fusion Application:

Fusion application is build on top of Fusion middleware technology. It uses Fusion architecture as the Blueprint. Modules of Fusion Applications are:

Any of these applications can be installed. If you face any issues in installing any of these applications, then install HCM before installing that application.

Simplified Architecture of Fusion Middleware:

This is a 3-tier architecture:

1. Database tier:

Oracle Internet Directory

Oracle Virtual Directory

Oracle Database

2. Oracle Weblogic Server

Oracle SOA suite

Oracle Webcenter

Oracle Web cache

3. Web tier

Oracle Web centre

Web http server

HTTP 80- it is a simple HTTP request

HTTP 443- Secured request.

Objective:

This training article is intended to provide an overview of Legislative Data Group (LDG), why it is a prerequisite setup while configuring Procurement module. We will also see LDG implementation in details.

Legislative Data Group (LDG):

Legislative data group (LDG) is required if we want to create Employees. In procurement we need Employees because Buyer defined in this module has to be an Employee. We cannot directly create user and use it in the procurement module unlike other modules like financials, Cash Management, etc where we can define user and can use that user in various functionality. In case of procurement we have to create Employees and Buyers. For that LDG is a mandatory setup. LDG is normally used in HR setup. It is grouping the data for payroll purpose. For each country we must have at least one LDG. Then only we can hire the employees for the country and would be able to process the payroll.

Implementing Legislative Data Group (LDG):

Before configuring LDG we need to setup the Legal Entity and Legal Entity Registration. To create Legal Entity Navigate>Procurement>Define common applications configuration for Procurement> Define Enterprise structure for procurement > Define Legal Entities for Procurement> Manage Legal Entity

Click on Task

Select Create New and Click on Apply and Go to Task

Click on Create Icon

Input the Legal Entity Name and Registration Information. Enable the check box for payroll statutory unit and Legal employer, reason already discussed. Click on Save and Close.

The next step is to Create the Legal Entity Registration. For which we need to select the scope as 16PO_AM_LE which we just created.

Click on Select

Choose on Select and Add and Click on Apply and Go to Task as shown above

Select the legal entity created and Click on Save and Close

So from above screen shot we can see that the system automatically creates LE Registration details. In case we want to add another registration click New Icon and in case we need some changes in the default we can use edit icon. Click on Done button.

Let us now create Legislative data group.Navigate>Define Legal Entities for Procurement> Manage Legislative data Groups.

Click on Task

Click on Create Icon

Input the LDG name, Country and Currency and click on Submit button.

Now its important to associate LDG created with Legal Entity HCM information. For which Navigate>Define Legal Entities for Procurement> Manage Legal Entity HCM Information

Click on Task

From Click on Correct. Its to be noted the Correct will update the records and Update will end date previous record and create a new record. So in this case we need to select the option Correct.

Under Payroll Statutory Unit tab associate the LDG created and Click on Submit.

Click on Done

Objective:

This training article is intended to provide an overview of Legislative Data Group (LDG), why it is a prerequisite setup while configuring Procurement module. We will also see LDG implementation in details.

Legislative Data Group (LDG):

Legislative data group (LDG) is required if we want to create Employees. In procurement we need Employees because Buyer defined in this module has to be an Employee. We cannot directly create user and use it in the procurement module unlike other modules like financials, Cash Management, etc where we can define user and can use that user in various functionality. In case of procurement we have to create Employees and Buyers. For that LDG is a mandatory setup. LDG is normally used in HR setup. It is grouping the data for payroll purpose. For each country we must have at least one LDG. Then only we can hire the employees for the country and would be able to process the payroll.

Implementing Legislative Data Group (LDG):

Before configuring LDG we need to setup the Legal Entity and Legal Entity Registration. To create Legal Entity Navigate>Procurement>Define common applications configuration for Procurement> Define Enterprise structure for procurement > Define Legal Entities for Procurement> Manage Legal Entity

Click on Task

Select Create New and Click on Apply and Go to Task

Click on Create Icon

Input the Legal Entity Name and Registration Information. Enable the check box for payroll statutory unit and Legal employer, reason already discussed. Click on Save and Close.

The next step is to Create the Legal Entity Registration. For which we need to select the scope as 16PO_AM_LE which we just created.

Click on Select

Choose on Select and Add and Click on Apply and Go to Task as shown above

Select the legal entity created and Click on Save and Close

So from above screen shot we can see that the system automatically creates LE Registration details. In case we want to add another registration click New Icon and in case we need some changes in the default we can use edit icon. Click on Done button.

Let us now create Legislative data group.Navigate>Define Legal Entities for Procurement> Manage Legislative data Groups.

Click on Task

Click on Create Icon

Input the LDG name, Country and Currency and click on Submit button.

Now its important to associate LDG created with Legal Entity HCM information. For which Navigate>Define Legal Entities for Procurement> Manage Legal Entity HCM Information

Click on Task

From Click on Correct. Its to be noted the Correct will update the records and Update will end date previous record and create a new record. So in this case we need to select the option Correct.

Under Payroll Statutory Unit tab associate the LDG created and Click on Submit.

Click on Done

How to Work with Logical Dimension Objects in BMM Layer of Oracle BI Repository

Introduction

This chapter explains how to work with logical dimension objects using level-based hierarchies in the Business Model and Mapping (BMM) layer of the Oracle BI Repository.

This chapter contains following topics:

Working with logical dimensions

Create logical dimensions with level-based hierarchies

Creating level-based measures

1. Logical Dimension

1. Objectives of Logical Dimension

Introduce formal hierarchies into a business model, enabling Oracle BI Server to calculate useful measures and enabling users to drill down to more detail.

• Establish level of data groupings and calculations.

• Provide paths for drill down.

The graphic illustrates a Time dimension hierarchy, where Grand Total is the level representing the grand total for the dimension, Years is the first parent level, Quarters is a child level of Years, Month is a child level of Quarters, and Days is a child level of Months.

• A logical dimension represents a hierarchical organization of logical columns belonging to a single logical dimensional table.

• Common logical dimensions used in a business model are time periods, products, customers, suppliers and so on.

• Logical dimensions are created in the Business Model and Mapping Layer (BMM) and can be used in the presentation layer for use in analysis and dashboards.

• In each dimension, you organize dimension attributes into hierarchical levels which represent the organizational rules and reporting needs required for your business.

• They provide the structure that Oracle BI Server used to drill into and across dimensions to get more detailed views of the data.

• Dimension hierarchy levels are used to perform aggregate navigation, configure level-based measure calculations, and determine which attributes appear when Oracle BI users drill down in their data requests.

In 11g, you can add that hierarchy to the presentation level. Every hierarchy have certain levels and every attribute is associated with the certain hierarchy.

2. Types of logical dimension

There are two types of logical dimensions:

1. Dimensions with level-based-hierarchies (structured hierarchies)

Members of the same type occur only at a single level.

Oracle BI Server supports unbalanced (ragged), skip-level, and time hierarchies.

E.g. Time dimension Year is the highest level and quarter is the second level. Every level has number as the common type and they occur only at the year level. Each level is distinct. With 11g, the BI server actually supports unbalanced hierarchy.

An unbalanced hierarchy is a hierarchy in which the leaves (members without children) do not necessarily have the same depth. For example, a site can choose to have data for the current month at the day level, previous month’s data at the month level, and the previous five years of data at the quarter level.

A skip-level hierarchy is a hierarchy in which there are members that do not have a value for a particular ancestor level. For e.g., in a Country-State-City-District hierarchy, the city “Washington, D.C.” does not belong to a state. In this case, you can drill-down from the Country level (USA) to the City level (Washington,D.C.) and below.

Time hierarchies provide special functionality for modelling time series data.

Dimensions with parent-child hierarchies (value hierarchies)

All members have the same type (for e.g. an organizational reporting hierarchy).

Manage employee hierarchy.

2. Pictorial representation of Ragged & Skipped Hierarchies

Ragged: All leaf nodes are not at the same level.

Skipped: A level is skipped between the two levels.

3. Database and OBIEE Representation

4. Creating Logical Dimension

Right-click the on business model and Select Logical Dimension->Dimension with Level-based hierarchy.

Alternately, right-click a logical dimension table and select Create Dimension.

1. Add a parent Level Object

• The hierarchy should be created after adding the logical dimension to the business model.

• The highest level of the hierarchy should be created first. Right-click the logical dimension and select New Object->Logical Level.

• Typically the first level you create is Grand Total level. Give the name for the level and select the Grand total level checkbox to indicate that this is the grand total level.

2. Add child level objects

Add subsequent levels in the hierarchy by right-clicking the level and select New Object->Child level.

3. Specify level columns

After creating the parent object and child objects, columns must be created for each level. Then the logical columns are associated with logical levels in the hierarchy.

The quickest way is to drag one or more columns from the logical dimension table to each level (except grand total level). The first time you drag a column to the dimension, it associates the logical table with logical dimension.

• All the columns in the dimension table must not be associated explicitly with a level. If it is not associated, the BI server considers it as detail level.

• No column can be associated with more than one level, although it may be the part of the level key of a lower level.

• If column pertains to more than one level, associate with highest level to which it belongs.

• No column except the Grand Total level can exist without one column associated with it.

• The Detail level (lowest level) must have the logical key of the dimension table that is associated with it, and the logical key of the dimension table must be the level key for the Detail level.

• The aggregate table holds time data at month level. The content level setting is very important in case of hierarchy and helps BI Server to process the query efficiently.

4. Create Level Keys

• Level keys define the unique elements in each level and provide the context for drill down.

• Each level except the Grand Total level must have one or more attributes that compose a level key.

• If a level has more than one key, you must specify which key is the primary key of that level.

• All dimension sources that have aggregate content at a specified level must contain the column that is the primary key of that level.

To create a level key follow the steps below:

1. Double-click a level to open the level properties window.

2. Click the keys tab.

3. Enter a name for the key and select the appropriate column or columns.

4. Each level should have one level key that is displayed when a user clicks to drill down. This may or may not be the primary key of the level.

5. To set the level key to be displayed, select the “Use for Display” check box in the Logical Level Key dialog box.

Alternate method is by right-clicking a level column and selecting New Logical Level Key.

In this example, there are two separate keys namely Month and Month Code. It is possible to create composite keys consisting of multiple columns.

Month code is the primary key and “Use for Display” is selected for the Month key. Therefore, when users drill down in a report from the next highest level, the default is to drill down to the month column rather than the Month code column.

5. Set the preferred drill path

• Different dimensions have different hierarchies. You can drill down from one dimension to another dimension by setting preferred drill path.

• You can use the Preferred Drill Path tab to identify the path to use when Oracle BI Presentation Services users drill down in their data requests.

• You should use this to specify only a drill path that is outside the normal drill path defined by the dimension level hierarchy.

• It is used to drill down from one dimension to another. For example, from the Customer Detail level you set the preferred drill path to Product Type so that users can drill down to see products ordered by customers.

5. Level-Based Measure

A level-based Measure is a column whose values are calculated to a specific level of aggregation. For e.g., a company want to measure its revenue based on the year, quarter, month, or day.

To achieve this, you could set up logical columns to measure Total Revenue, Year Revenue, Quarter Revenue, Month Revenue and Day Revenue.

The total revenue measure is an example of a level-based measure at the Grand Total level. This would calculate all revenues across all years.

Level-based measures allow a single query to return data at multiple levels of aggregation. For e.g. single query can return total revenue by year, quarter, month, and day for a single customer.

1. To Create Level-Based Measure

A level based measure is created for example Grand Total level which refers to an existing logical fact column.

6. Share Measure

Level-based measures are used for creating share measures, which are calculated by taking a measure and dividing it by a level-based measure to calculate a percentage.

For example, you can divide “salesperson revenue for a specific month” divided by “total revenue for a particular month” to calculate the share of the monthly revenue that is generated by each salesperson.

Example:

In this example, the logical dimension is named Product and is identified by the icon with multiple arrows. The hierarchy contains five levels: Product Total, Type, Subtype, Generic, and Product Detail.

Level-based measures are associated with two levels of the hierarchy. Product Type Dollars is associated with the Type level. There are also other columns and keys associated with each level.

Introduction

This article explains how to work with logical dimension objects using parent-child hierarchies and creating calculated measures.

This chapter illustrates the following topics:

Create logical dimensions with parent-child hierarchies

Create calculated measures 

1. Create Presentation Hierarchy

To create a presentation hierarchy, drag a logical dimension hierarchy from the BMM layer to a table in the presentation layer.

1. Test Measures and Hierarchies

Run analysis to test results. Drill down to check relative recalculations.

2. Parent-Child Logical Dimension

A parent-child logical dimension is a hierarchy of members that all have the same type.

This contrasts with level-based hierarchies, in which members of the same type occur only at a single level of the hierarchy.

The real-world example of a parent-child hierarchy is an organizational reporting hierarchy chart, in which the following conditions are applied.

• Each individual in the organization is an employee

• Each employee, apart from the top-level managers, reports to a single manager.

• The reporting hierarchy has many levels.

1. Parent-Child Logical Table

A parent-child hierarchy is typically based on a single logical table e.g. Employees table.

Each row in the table contains two identifying keys: one to identify the member itself and the other key to identify the parent of the member. 

2. Relationship Table

For each Oracle BI Server parent-child hierarchy defined on a relational table, you must explicitly define the inter-member relationships in a separate parent-child relationship table.

• A column that identifies the member.

• A column that defines the ancestor of the member (The ancestor may be the parent of the member or a higher-level ancestor).

• A "distance" column that specifies the number of parent-child hierarchy levels from the member to the ancestor.

• A "leaf" column that indicates if the member is a leaf member (1=Yes, 0=No).  A leaf column is a dimension member without descendants.

3. Creating a Parent Child Dimension

In Oracle BI, you generally create scripts to create and populate the parent-child relationship table through an Administration tool wizard that you can choose to use to define the parent-child hierarchy.

You can then use these scripts as often as required to reflect the current state of the data in the parent-child hierarchy. If you do not choose to use the wizard, then you must have previously created the parent-child relationship table, and you can then manually associate it with the parent-child hierarchy.

In the latter case, it is also your responsibility to populate the table with the data required to describe the inner member relationships in the parent-child hierarchy.

4. Create Logical Dimension Object

Perform either of the following steps listed below:

• Right-click the business model object and select New Object -> Logical Dimension -> Dimension with Parent-child hierarchy.

• Right-click the logical dimension table and select Create Logical Dimension -> Dimension with Parent-Child hierarchy.

To set Member Key

Click Browse next to the Member Key field to view or set the member key.

To set the Parent Column

The parent column is the column that identifies an ancestor of the member in the logical table. The ancestor may be the parent of the member or a higher-level ancestor. In the example below, the ancestor is the Manager ID column.

To set Parent-Child Relationship

If the logical table that you have selected was not from a relational table source, you can click OK to finish the process of creating the dimension. However, because the logical table in the following example is from a relational table source, you must continue the dimension definition process to set up the parent-child relationship table for the hierarchy.

You must define a parent-child relationship table for parent-child hierarchies based on relational tables. When you create the parent-child relationship table, you must choose one of the following methods.

1. Use a wizard that generates scripts to create and populate the parent-child relationship table.

2. Select a previously created parent-child relationship table.

5. Parent-Child Table Script Information

Script Location is the initial screen in Generate Parent-Child relationship Table wizard that generates SQL scripts for creating and populating parent-child relationship table.

In the Script Location screen, enter the names and locations for the DDL scripts to create and populate the parent-child relationship table.

At the end of the wizard, Oracle BI Server stores the scripts in directories selected during the wizard session. The scripts, when executed, create and populate the parent-child relationship table in the physical data source.

To Enter Parent-Child Table Details

In the parent-child Relationship Table Details screen, provide details for the table that is generated by the scripts.

To Preview Scripts

In the Preview Script screen, click View Script to view either or both of the scripts

6. To confirm Parent-Child settings

When the wizard is completed, the parent-child relationship table details are populated.

7. To confirm BMM layer changes

After the wizard is completed, the parent-child logical dimension is added to the BMM layer.

8. To confirm changes to physical layer

When the wizard is completed, the parent-child relationship is added to the physical layer.

9. To modify changes to physical layer

After adding the parent-child relationship table to the physical layer, you must make some modifications in both the physical layer and the BMM layer.

For example, you must create join relationships with the other tables related to the parent-child relationship table. Here the Dim_EMP_PARENT_CHILD alias table is created and then joined to the DIM_EMPLOYEE and Fact_DI_ORDER_AGG1 tables.

There is a one-to-many join from Dim_EMPLOYEE to Dim_EMP_PARENT_CHILD to Fact_D1_ORDER_AGG.

10. To modify changes in BMM layer

Map the logical table source (LTS) in the business model to the parent-child relationship table in the physical layer.

11. Presentation hierarchy

Add the hierarchy to the corresponding table in the Presentation layer to make the hierarchy available for queries.

Add the hierarchy to an analysis and check the results.

12. Calculated Measures

A calculated member is a user-defined dimension member whose measure values are calculated at run time.

You define a calculated member within a dimension through a formula that references other members of the same dimension. If a dimension has multiple hierarchies, all members referenced in the formula must belong to one hierarchy.

Within a calculated measure, the members do not have to be at the same level in the hierarchy.

Three standard components of a calculated member are listed below:

1. Presentation hierarchy on which the calculated member is based (in this example, “Customer-Region”).

2. Name to identify the calculated member and to distinguish it from other members in the dimension (in this example, “West-Desert-Northwest”).

3. Formula used to calculate the calculated member, which consists of one or more examples of a “member clause” connected by standard arithmetic operations. In this example, you calculate total dollars for the West region and then subtract dollars for the Desert and Northwest districts. Because there are only three districts in the west region, the remainder represents total dollar for the “California district”, “Fact-Sales”. Dollars provide the formatting for the SQL results.

Introduction

This article describes aggregate tables and their purpose in dimension modelling. It explains the modelling of aggregate tables and to set the number of elements for a hierarchy level

1. Aggregates

1. Business challenge in using Aggregates

• Data in fact and dimension sources is stored at the lowest level of detail.

• Data often needs to be rolled up or summarized during analysis.

• Based on the amount of data, performing calculations at the time of the query can be resource intensive and can delay results to the user.

2. Business Solution for the usage of Aggregates

Aggregate tables store pre-computed results, which are measures that have been aggregated (totally summed) over a set of dimensional attributes. Using aggregate tables is a very popular technique for increasing the speed query response time in decision support systems. This eliminates the need for run-time calculations and delivers faster results to users.

Note that the below tables are physical tables. The calculations are done ahead of time and the results are stored in the tables. The key point is that the aggregate table should have fewer rows than the non aggregate table and, therefore, processing should be quicker.

3. Oracle BI Aggregate Navigation

If you are writing SQL queries or using a tool that understands the existence of physical tables, the aggregate tables become more difficult if the number of tables increases.

The aggregate navigation capability of Oracle BI Server, however, allows queries to use the information stored in the aggregate tables automatically, without query authors or query tools having to specify aggregate tables in their queries.

Specific metadata in the repository should be configured so that the Oracle BI Server has enough information to navigate to aggregate tables.

4. Aggregated Facts

Each aggregate table column contains data at a given set of levels. For example, an aggregate sales fact table might contain a pre-computed sum of the revenue for each product type for each sales representative during each month.

The graphic indicates that there is more data at lower levels in a hierarchy. As you move higher in the hierarchy, there is less data because the results are aggregated.

5. Modelling Aggregates

The aggregate tables are modelled in the same way that you model other source data.

The aggregate tables are modified in three layers as follows:

In Physical Layer

• Create data source connection and import physical sources.

• Create physical joins.

In BMM Layer

Add sources to logical tables and specify aggregation content.

In Presentation Layer

No changes are necessary. Aggregate navigation is important of the presentation layer objects.

Example for an aggregate

• The prebuilt aggregate tables can be used to improve performance of the server.

• The matching levels of aggregation should be done for fact and dimensions.

6. Aggregate Navigation Implementation

The known techniques are used to import fact and dimension tables to the Physical layer and create aliases. Both the Aggregate and Fact tables should be imported because you need to create logical dimension sources at the same level of detail as the fact sources.

1. Creation of Join

The Physical diagram should be used to create joins between the aggregate fact table aliases and the aggregate dimension table aliases.

7. Fact LTS Mappings

The known techniques are used to create a new LTS within the current logical fact table that points to the aggregate table. For example, drag physical columns from the fact aggregate physical table to the corresponding columns in the business model to map existing logical columns to the new LTS.

In this example, the new LTS is named Fact_D1_ORDER_AGG1.

Note that these four columns now map to both the Fact_D1_ORDERS2 table and the Fact_D1_ORDER_AGG1 table. In this step you configure the model to choose the appropriate table during a query based on how content is specified in the content tab.

1. Set Aggregation Content

Use the content tab of LTS dialog box to specify the aggregation content of new aggregate LTS. You set the aggregation content for the fact table to the corresponding levels in the dimension hierarchies.

Later, when a user queries against a particular level, Oracle BI Server will automatically know that it should access the aggregate tables instead of the detail tables. In a subsequent step, you set similar levels for the dimension table aggregate sources.

For example, if a user queries for total sales by Month by Sales Rep, the server accesses the Fact_D1_ORDER_AGG1 aggregate fact table and the corresponding aggregate dimension tables Dim_MONTHS and Dim_D1_SALESREP. If a user queries for a level lower than the levels specified here, for example instead of Month, or Customer instead of Sales Rep, the Server accesses the detail tables (Fact_D1_ORDERS2, Dim_D1_CALENDAR2, and Dim_D1_CUSTOMER2).

If a user queries for a higher level (Year instead of Month, District instead of Sales Rep), the aggregate tables are used as well, because whenever a query run against a logical level or above, the aggregate tables are used.

Hint: Click the More button in LTS dialog box to have the server help determine the levels.

2. Specify content for Detail LTS

The levels of the fact detail source should be set to the lowest in the hierarchies. This is because you want the server to access the detail tables when queries are against lower levels than those specified for the aggregate tables.

The content of all sources should be specified for the documentation purposes. This helps prevent another administrator from interpreting the lack of an aggregation content statement as an inadvertent omission of information.

3. Create Dimension LTS and Mappings

A new LTS can be created within the current logical dimension tables that point to the aggregate tables.

This example shows the Dim_Customer logical dimension table. A new LTS named Dim_D1_SALESREPS is added. It maps to the Dim_D1_SALESREPS physical aggregate table. The logical columns District, Region, and Sales Rep now map to both physical tables Dim_D1_Customer2 and Dim_D1_SALESREPS.

4. Specify Dimension Aggregation

Specify the aggregation content for the aggregate LTS for Dim_Customer table so that the Oracle BI Server knows what level of data is stored in the aggregate tables. The Dim_D1_SALESREPS table contains data at the Sales Rep level within the Customer hierarchy.

5. Set Content for Dimension LTS

The levels of the dimension detail source should be set to the lowest in the hierarchies. This is because you want the server to access the detail tables when queries are against lower levels than those specified for the aggregate tables.

The content of all sources should be specified for the documentation purposes. This helps prevent another administrator from interpreting the lack of an aggregation content statement as an inadvertent omission of information.

6. Test Results

In the example below, the analysis requests data at the levels stored in the aggregates. As expected, the Dim_D1_SALESREPS, and the dollar data is retrieved from the fact aggregate, Fact_D1_ORDER_AGG1.

In the example shown below, the analysis request data at levels above or below those stored in the aggregates. When data is requested by Sales District, which is above the Sales Rep level, the DIM_D1_SALESREPS and Fact_D1_ORDER_AGG1 aggregate tables are still used. When data is requested by the customer that is below the Sales Rep level, the Dim_D1_CUSTOMER2 and Fact_D1_ORDERS2 detail tables are used.

8. Setting the Number of Elements

The number of elements is used by Oracle BI Server when selecting aggregate sources. Setting the number of elements is necessary only when there are two or more aggregate sources that could be accessed by an Oracle BI query.

Aggregate fact sources are accessed based on the combination of the fields selected as well as the number of elements of the levels in the logical dimensions to which they map. The number does not have to be exact, but ratios of numbers from one logical level to another should be accurate.

In the example shown below, there are two aggregate sources for the Fact-Sales logical table: Fact_D1_ORDER_AGG1 and Fact_D1_ORDER_AGG2.

Logical levels are set differently for each aggregate source; however, both sources have logical levels set to Month for the Time logical dimension. Despite the fact that both aggregate sources have their aggregation content set to the Month level for the Time Logical dimension, the query uses Fact_D1_ORDER_AGG1. This is because Oracle BI Server determines that it is more economical to access Fact_D1_ORDER_AGG1 instead of Fact_D1_ORDER_AGG2 based on the levels specified in the dimension hierarchies.

For example, to access Fact_D1_ORDER_AGG2, it calculates 35,712 potential rows (12 districts*6 Months*186 Generic products). To access Fact_D1_ORDER_AGG1, it calculates 11,968 potential rows (34 sales rep * 16 Months * 22 product types). Therefore, Fact_D1_ORDER_AGG1 is the more economical aggregate source.

This tutorial deals with Fusion Payroll, and how it functions. In this part, we will discuss about Earnings and Deductions.

Earnings and Deductions

The following tasks are associated with Earnings and Deductions in Payroll: Manage Element Classifications, Manage Elements, Manage Calculation Value Definitions, Manage Payroll Calculation Information, Manage Component Group Rules, Add Eligibility Rules for Predefined Elements, Manage Rate Definitions.

First, we shall look into the basic terms and components that comprise the Earnings and Deductions.

Elements

Elements are building blocks of Payroll that help determine the payment of base pay, benefits, absences, and other earnings and deductions. Apart from within Payroll (for bonuses, overtime earnings, etc.), this is also used in Compensation Benefits (on the basis of the base pay) and Absence Management (for absence payments like in the case of maternity leaves and other long leaves).

Fig. 1 - Elements for different types of earnings and deductions

Element Classifications

They are a mechanism by which you classify the Element as Earnings or Deductions and defines a default processing priority for the element in payroll runs.

There are three types of element classifications:

• Primary Classifications - They are given by the payroll and enabled at the country-specific module. They meet the legislative requirements of your country or territory, so you cannot change them.

• Secondary Classifications - They are subsets of the primary classifications. They are used to manage wage basis rules for deductions and taxes.

• Subclassifications - they are a way to feed balances depending upon some criteria.

The Costing information and Frequency Rules are the components that can be modified.

Element Creation

In Fusion Payroll, the organisation or legislation provides a set of predefined elements either for regulatory purposes or deductions. The first thing to be done is to identify these predefined elements and make them eligible to all employees.

For the creation of elements, templates are used. Primary Classification, Payroll Product Usage, and Category determine the templates that are used. Any number of elements can be created depending on your requirement.

For elements, there are certain Critical Child Entities: Input Values, Element Eligibility Records, Status Processing Rules, and Formula Result Rules. These need to be active for the earnings.

Upon element creation, Related Formulas, Related Elements, and related Balances are created based on the template used in the creation wizard.

Input Values

An element’s input values define the entry values available on each entry of that particular element. In Fusion, any number of input values can be created depending upon your requirement. In most cases, the template will create the input values for you.

The critical attributes for input values are:

• Special Purpose - the purpose of the value

• Unit of Measure - can be currency, hours, weeks, etc.

• Display Sequence - the level in which the value needs to come up

• Create a Database Item - to create a separate item for the value

• Required - whether yes/no during element entry

• Validation Formula - validation criteria

• Validation Source - the source of the validation

• Lookup Type - for the appropriate lookup to be displayed

Element Eligibility

Element eligibility determines which people are eligible for an element. To determine eligibility, you have to select a specific criteria that people must have to receive entries of that particular element.

The eligibility criteria can be selected from the following:

• All payrolls or for specific payrolls

• Payroll Statutory Unit

• Legal Employer

• Payroll relationship type

• Department in which the person works

• Location of person’s office

• Job (e.g. associate professor or secretary)

• Position

• Grade

• People group

Status Processing Rules and Formula Result Rules

These identify the formula that the payroll run uses to process the element for workers with a specified assignment status. The formulas return formula results such as the amount to be paid or a message.

These results can update the current element entry or another target element entry with a lower processing priority, which means that it is processed later in the payroll run.

There are different types of formula results:

• Direct Result - updates the entry after calculation

• Indirect Result - updates the entry of a non-recurring element

• Message - gives a message to the entry value

• Order Indirect - lowers priority within the element based on the calculation

• Stop - omits an entry from further calculation

Payroll Calculation Information

The following flowchart explains how the payroll earnings and deductions are calculated:

Fig. 2 - Payroll Calculation Information

The Payroll Component is enabled and has rules and rates defined for a particular classification. Depending upon the primary and secondary classifications, the Wage Basis Rules are seeded at the legislative level.

At the calculation level, the calculation value definitions are derived from the calculation factors, telling which values are to be utilised for the calculation.

INTRODUCTION

This topic explains about aggregate persistence wizard that is used for creating and modelling aggregate tables. It further illustrates the concepts of fragmentation or partitioning which are the most powerful features of OBIEE and method of creating and using variables.

1. Aggregate Persistence Wizard

There is a wizard that creates parent-child relationship and tells the BI Server that which is the parent and child. The wizard will create aggregate tables and model it.

1. Open the wizard

• Select Tools->Utilities->Aggregate Persistence to open the wizard and click Execute button.

• Specify a file and location where the output script should be saved.

2. Specify Business Model and Measures

• In the top pane of the Select Business Measures screen, select the Business Model. When there are multiple models, only one Business model can be selected.

• In the bottom pane, select the fact table. When there are multiple fact tables, only one fact table can be selected.

• Expand the fact table and select desired measures.

3. Select Dimension Levels

Select corresponding aggregate dimensions and levels.

4. Select Connection Pool

• In the top pane of the Select Connection Pool screen, select the repository database object.

• In the expand pane, expand the database object and select the desired schema. In this example, there is only one schema SUPPLIER2.

• In the third pane, select the connection pool. In this example, there is only one, SUPPLIER CP.

• In the Aggregate table in name field, select the default name or create a new name for the aggregate table. In this example, the default name is ag_Fact_Sales.

Note: The parameters provided here are for output, which could be to a different database than where the detail table reside.

5. Review Aggregate Definition

7. View Aggregate Script

7. Verify script is created

Navigate to the directory where the file was saved and verify that the script was created as expected.

8. Run script using nqcmd

Use the nqcmd utility to run the aggregate persistence script.

9. Verify Aggregates in the physical layer

Verify that the aggregates are created in the physical layer of the repository as desired.

10. Verify Aggregates in BMM Layer

Verify that the aggregates are created in the BMM layer of the repository as expected.

11. Verify in Database

Verify that the aggregate tables are created in the database.

12. Activate the aggregate table

13. Run an analysis

Check the log and verify that the aggregate tables are accessed as expected.

14. Troubleshooting Aggregate Navigation

If aggregate navigation is not working or not creating the correct aggregate table, the cause might be one of the following:

• Aggregate content is not specified correctly for one or more sources.

• Aggregate dimension sources are not physically joined to aggregate fact tables at the same level.

• A dimensional source does not exist at the same level as the fact table source.

• Aggregate dimension sources do not contain a column that maps to the primary key of the dimension hierarchy level.

• The number of elements is specified correctly for dimension hierarchy levels.

Best Practices

• Using aggregates comes with a price

• Additional time is required to build and load these tables.

• Additional storage is necessary.

• Build only the aggregates you need

• Look at query patterns and build aggregates to speed up common queries that require summarized results.

• Ensure that enough data is combined to offset the cost of building aggregates.

• Monitor and adjust to account for changing query patterns.

2. Partition and Fragments

1. Business Challenge

Data is often partitioned into multiple physical sources for a single logical table in a business model

When a logical table source does not contain the entire set of data at a given level, you need to specify the portion or fragment of the set that it contains.

For example, there are situations in which data may be fragmented or partitioned. When individual sources at given level contain information for a portion or fragment of the domain, an application needs to know the content of the sources to pick the appropriate source for the query.

This should not have impact on the end-user experience. The way of data access should be completely transparent to the end-user.

2. Business Solution

When there are multiple sources, the metadata can be built so that Oracle BI Server handles navigation to the appropriate source. Oracle BI Server do seamlessly access and process data from multiple sources efficiently to satisfy user requests.

Partitioning can be done by building smaller separate databases or by splitting larger selected elements into smaller ones (For example, splitting one larger table into many smaller tables). When a user requests data, it may be necessary to consolidate data from different partitions to complete the request.

3. Complex Partitioning

Partitioning strategies can be mixed. For example, data can be partitioned by level and value so that at any given intersection of levels, multiple aggregate tables may exist. Moreover, at any given intersection of levels, not all values might be stored.

For example, at a Brand, Month, and Market aggregate level, just the important brands might be stored. Certain queries at this level can use the aggregate tables; other queries, with different constraints, have to use more detailed tables.

Example

Replace the current, single source for order data with two value-based partitions.

4. Specify Fragmentation Content

When a LTS does not contain the entire set of data at a given level, you need to specify the portion, or fragment, of the set that it contains. Describe the content in terms of logical columns, using the “Fragmentation content” edit box on the Content tab of LTS window. Click the button next to the “Fragmentation content” box to open the Expression Builder to build the expression.

This is similar to the steps used to define aggregates. For aggregates, you specified the content by using the level indicator. Here you use an expression to serve the same purpose – to identify what data the source contains. In this example, the Facts-Historical table contains data for orders on or before December 31, 2008.  In a request for order data, this source may need to be combined with data from other sources at this level. In this example, that would be the Facts-Recent table, which contains the remaining order data.

1. Partitioning by Level

Data can also be partitioned by level. This occurs when the same facts are stored in separate tables at different levels of aggregation. The use of aggregate tables is a common practice in data warehouse design because it is a very effective tool for improving query performance.

However, the number of aggregate tables in a data warehouse can be very large. As such, data warehouse designer prefer to follow an incremental approach to create aggregations. They look for the best performance, creating the aggregate tables that are going to be used most frequently and that offer the most data compression.

2. Partitioning by Fact

Data can be stored in such a way that different facts are in different tables. For example, companies usually store sales quotas in tables separate from the actual sales history. Inventory data is also commonly found stored in a database separate from sales history.

This is sometimes referred to as vertical partitioning because a theoretical all-encompassing fact table can be thought to be sliced “vertically”, with different columns going to different fact tables.

3. Partitioning by Value

Data can be partitioned into separate tables according to the values of the data.

Examples:

East region sales data may be in a different table from West region sales data.

Inventory data may be in separate tables segregated by warehouse.

The data for the current year may not be in the same table as the data for prior years, or data could be separated by month, so that last three years of data are in 36 separate tables.

This type of partitioning creates complexity in the query environment. One of the important benefits of Oracle BI Server is that it can do this type of navigation and consolidation automatically, preserving a simple logical model of the data with which users interact.

3. Variables

• Contain values in memory that are used by Oracle BI server during its processing

• Variables are created and managed using the Variable Manager feature in the Administrator tool.

• The variables are categorized into two types namely session variables and Repository variables.

1. Variable Manager

It is a utility in the Administration tool that is used to define variables.

2. Types of Variables

There are two classes of variables namely repository variable and session variable.

1. Repository Variable

A repository variable has a single value at any point in time. There are two types of repository variables: static and dynamic. Repository variables are represented by a question-mark icon (?).

• It persists from the time Oracle BI Server is started until it is shut down.

• It can be used instead of literals or constants in the Expression Builder in the Admin tool.

• Oracle BI Server substitutes the value of the repository variable for the variable itself in the metadata.

1. Dynamic Repository Variable

You initialize dynamic repository variable in the same way as static variables, but the values are refreshed by data returned from queries. When defining a dynamic repository variable, you create an initialization block or use a pre-existing one that contains a SQL query. You also setup a schedule that Oracle BI Server follows to execute the query and refresh the value of the variable periodically.

When the value of the dynamic repository variable changes, all cache entries associated with the business model that reference the value of that variable are purged automatically. Each query can refresh several variables- one variable for each column in the query. In this example, the query returns three columns (YYYYMMDD, MONTHCODE, YEAR) that refresh the variables: CurrentDay, CurrentMonth and CurrentYear.

A common use of the variables is to set column filters in analyses. For example, to filter the column on the value of the dynamic repository variable CurrentMonth, set the column filter to the variable CurrentMonth.

3. Session Variables

Session variables are created and assigned a value when each user logs on. There are two types of session variables namely system and non-system. System and non-System variables are represented by a question-mark icon (?).

Initialization blocks are used to initialize dynamic repository variables, system session variables, and non-system session variables. The icon for an initialization block is a cube labelled with letter i.

Objective:

In this training article we will discuss all about Business Unit in Fusion Procurement and how to configure it in the instance. 

Business Unit

Business unit (BU) is a unit of an organization /enterprise that performs one or more business functions that can be rolled up in the management hierarchy. A business unit can perform transactions on behalf of many legal entities.

• Business Unit is assigned to one primary ledger
• Business unit as securing mechanism of transactions.

Procurement Business Unit

• A business unit with the procurement business function
• Establishes a relationship with a supplier through the creation of a site, which maintains internal controls for how procure to pay transactions are executed with the supplier.
• Manages, owns, and is responsible for purchasing transactions.

Requisitioning Business Unit

• A business unit with the Requisitioning business function.
• Manages and owns requisitioning transactions.

Sold-to Business unit

• A business unit with the Payables Invoicing business function
• Responsible for invoicing transactions.
• Assumes the liability for the purchases made on behalf of a client business unit.

Business Functions

A business function represents a business process, or an activity that can be performed by people working within a business unit and describes how a business unit is used. The following business functions exist in Oracle Fusion Applications

• Billing and revenue management
• Collections management
• Customer contract management
• Customer payments
• Expense Management
• Incentive compensation
• Marketing
• Material management
• Inventory management
• Order fulfilment orchestration
• Payable invoicing
• Payable payments
• Procurement
• Procurement contract management
• Project accounting
• Receiving
• Requisitioning
• Sales

Service Provider Model

Allows a business unit to act as a service provider to client business units, so that the personnel in a shared service center can process transactions on behalf of client business units. Use the service provider model to centralize the procurement business function. Define business units with requsitioning and Payables Invoicing business functions as a clients of a business unit with the Procurement business function. The benefit of shared service is that the enterprise as whole can have a better negotiation with the customers for procurement of a certain goods/services.

Creating Business Unit

In order to implement Business Unit Navigate> Procurement > Define Common Aplications Configuration for Procurement > Define Enterprise Structure for Procurement > Define Business unit for Procurement > Manage Business Unit 

Click on task

Click on Create Icon

Imput the name of business unit, select default set as Common and Click on save and Close

Now we need to assign the business function with the BU

For that click on Assign Business Unit Business function task bar

Select Scope and click on apply and Go to task

Select the BU and Click on Save and Close

Select the relevent business functions and the ledger/LE and click on Save and Close. It is important to note that the selection of Material management is important if we want to create Inventory Organisation. So we can see how we created the business unit and associated the business function with the BU.

This tutorial deals with Fusion Payroll, and how it functions. In this part, we will discuss about the following topics:

• Formulas

• User Defined Tables

Formulas

Formulas are generic expressions of calculations or comparisons that you want to repeat within different input variables. It is a means of defining any business logic for performing functions that may not be provided by the Human Capital Management (HCM) app itself. Formulas are extensively used across HCM.

Formulas are used in the following components of HCM:

• Payroll - Calculation, input value validations, skip rules for elements, etc.

• Benefits - Date calculations, eligibility and participation evaluation, etc.

• Object Groups - Payroll Relationship Groups

• Compensation - Person selection, currency selection for workforce compensation plans, etc.

• HCM Extracts

The Formula Type is provided by Global Payroll. Any formula requires specific inputs and outputs (to be generated) for the functioning of the formula.

Formulas can be written either by using the Expression Editor (by using the Fast Formula UI) or through Formula Text (writing the pseudocode). The Expression Editor only has a limited number of Formula Types available, mainly the Payroll Relation Groups. For the other Formula Types, their formula’s pseudocode is written through formula text.

Once a formula is written, it has to be compiled first. Upon successful compilation, the formula can be attached to a business application so that it gets executed when running that particular application.

The task associated with it is Manage Fast Formulas.

Database Items

Database Items are a mechanism used to retrieve a value from the database through a code. These codes are used extensively in formulas to get values required for the output. They are Read-Only variables that are used in formulas.

There are two types of Database Items:

• Static - They are seeded and predefined, like: Birth Date, Payroll Relationship Number, etc. (e.g. PAYROLL_REL_NUMBER)

• Dynamic - They are created when you create Elements, Input Values, Balances, and Flexfields. In case of flexfields, you need to run the Generate Flexfield Database Items process. In the case of Elements or Input Values, the name yu give to the element or input value gets converted to a dynamic database item; spaces are converted into underscores (e.g. MONTHLY_EARNINGS)

Fig. 1 - The Expression Editor with the Payroll Relationship Group Formula Type

Most of the formulas are written through Formula Text. Taking the example of Element Input Validation, the following table explains the field, purpose, and the time of execution of the formula:

Fig. 2 - Formula Text for Element Input Validation

The following table depicts the formula usage and the input variables required for the formula for Element Input Validation:

Fig. 3 - Input variables for formula usage

The following table depicts the formula usage and the return variables that the formula produces as output for Element Input Validation:

Fig. 4 - Return variables

In the following example formula, entry_value is the input variable. The formula is used to identify valid entries in the database based on the entry_value being greater than 2000:

Fig. 5 - An example formula

Compilation and Execution Errors

Since formulas essentially consist of code, there is the possibility of them throwing up compilation or execution errors.

Compilation Errors

Upon compilation of the formula, the possible compilation errors are:

• Syntax Error

• Misuse of the ASSIGNMENT statement

• Misuse of the DEFAULT statement

Execution Errors

If the formula is compiled successfully, it may have some other type of mistakes that result in execution errors while running the formula:

• Uninitialised Variable

• Divide by Zero

• No Data Found

User Defined Tables

User Defined Tables are a feature by which users can create their own table structure to store values. They are used when a table structure is required for values depending on the user’s needs.

There are four components to a user-defined table: basic details (datatype, unit of measure, etc.), columns (column headings), rows (number of rows in the table), and values (values of the rows).

There are two types of row values: Matched Row Values, where you define a specific value to be matched for each row and column; and Range of Row Values, where you specify a range of values that the rows and columns take.

For example, there might be a hike or bonus applicable for employees depending on their years of service. User defined tables can be used to assign a value for the hike or bonus applicable to a certain range of values for years of service. For instance, a hike of 20% could be applied to the years of service ranging from 3-5.

The values can be validated through User Table Validation Formula.

The task associated with it is Manage User-Defined Tables.

Fig. 6 - The User Defined Tables UI

After performing the various functions related to Payroll, you can visit the Payroll Calculation Work Area to get an overview of all the elements in your Payroll.

Fig. 7 - The Payroll Calculation Work Area

Having dealt with the Part 1 of Oracle Fusion Payroll - Formulas and User Defined Tables, this tutorial deals with Fusion Payroll, and how it functions. In this part, we will discuss about the UIs of the following topics:

• Formulas

• User Defined Tables

• Payment Methods

• Object Groups and Process Configuration

Formulas

As discussed in the previous part, formulas are generic expressions of calculations or comparisons that you want to repeat within different input variables. It is a means of defining any business logic for performing functions that may not be provided by the Human Capital Management (HCM) app itself.

The task associated with it is Manage Fast Formulas.

1. Go to the Manage Fast Formulas task under Define Fast Formulas.

2. On the Manage Fast Formulas page, select your Legislative Data Group and click on the Search button.

3. From the search results, click on a formula name.

4. The formula text for that particular formula is displayed on the screen. You may edit the formula text (the pseudocode) by clicking on the Edit button and selecting Correct. After editing the formula, click on the Save button followed by the Submit button.

Fig. 1 - The Manage Fast Formulas task

Fig. 2 - The Manage Fast Formulas page

Fig. 3 - The formula text

Fig. 4 - Editing a formula

To the right of the formula text, there are three tabs visible: Database Items, Functions, and Globals.

To view the Database Items, follow the below steps:

1. Use the arrow button (circled in the screenshot below) to adjust the formula text area in order to expand the Database Items tab’s view.

2. Use the search box in the Database Items tab to search for the Database Items that can be used in the current formula.

3. Click on the Add to Formula button to add a particular Database Item to the formula.

4. Similarly, you can add functions and global variables to the formula text by using the relevant tabs.

5. After editing the formula text and adding any database items, functions, and globals as required, click on the Compile button on the top-right corner to compile the formula text’s code.

Fig. 5 - Searching for a Database Item

Fig. 6 - Searching for Database Items

Fig. 7 - The Compile button is circled

Fig. 8 - Compiling the formula text

To view the element under Payroll Calculations, follow the below steps:

1. Click on the Navigator icon (circled in the screenshot below) and go to Payroll -> Payroll Calculations.

2. On the Payroll Calculations page, click on Manage Elements under Earnings and Deductions.

3. Search for the element name with the Legislative Data Group and click on the Search button.

4. From the search results, click on the name of the element.

5. In the Element Overview, you can view the formulas attached to the element under Related Formulas.

Fig. 9 - The Navigator menu. The Navigator icon is circled

Fig. 10 - The Payroll Calculations homepage

Fig. 11 - The Manage Elements page

Fig. 12 - The Element Summary

User Defined Tables

As discussed in the previous part of this tutorial, User Defined Tables are a feature by which users can create their own table structure to store values. They are used when a table structure is required for values depending on the user’s needs.

The task associated with it is Manage User-Defined Tables.

1. Go to the Manage User-Defined Tables task under Define Fast Formulas.

2. Search for the required Legislative Data Group using the dropdown (circled in the screenshot below) and click on the relevant name from the search results.

3. Click on the Edit button on the top right-hand corner (circled in the screenshot below). After selecting the column to be edited, click on the Next button.

4. Click on the New icon (circled in the screenshot below) to add a row to the column.

5. Select the required row table value to be added and click on the OK button.

6. Once the row gets added to the column, enter a table value and click on the Save button followed by the Submit button.

Fig. 13 - The Manage User-Defined Tables task

Fig. 14 - The Manage User-Defined Tables page. The Legislative Data Group dropdown is circled

Fig. 15 - The page of a User Defined Table

Fig. 16 - Editing the table. The New icon is circled

Fig. 17 - Adding a row

Fig. 18 - Adding a table value

In the screenshot below, a User Table Validation Formula has been added to the User Defined Table:

Fig. 19 - A validation formula added to the table

1. Click on the Navigator icon and go to Payroll -> Payroll Calculations.

2. On the Payroll Calculations screen, click on Manage Fast Formulas under Manage Payroll Process Configuration present on the left.

3. Type in the name of the formula in the field and select the Legislative Data Group from the dropdown. Click on the Search button.

4. From the search results, click on the formula name.

5. The formula text (the pseudocode) is then displayed. You can edit the formula as per your needs.

Fig. 20 - The Payroll Calculations homepage

Fig. 21 - Searching for a formula

Fig. 22 - The formula text

Fig. 23 - Error shows up if invalid value (as per formula text) is added to the table

This tutorial deals with Fusion Payroll, and how it functions. In this part, we will discuss about Payment Methods in Payroll.

Payment Methods

Once the components of Payroll like balances, earnings and deductions, etc. are set up, there has to be a mechanism by which the actual payment takes place for the Payroll.

Payment Methods are the definition of how the payments are handled through organisations and employees.

There are three types of payment methods:

• Organisation Payment Methods - related to payments with the organisation.

• Personal Payment Methods - related to the employees.

• Third Party Payment Methods - related to payments to third parties that do business with the organisation.

The Payment Distribution Mechanism varies depending on the country in which the organisation is operating. There are three types of payment distribution mechanisms:

• Electronic Fund Transfer (EFT)

• Check

• Cash

Organisation Payment Methods

It is the definition of how the payments are handled from the organisation’s perspective. At least one Organisation Payment Method has to be defined for each combination of the Legislative Data Group, Payment Type, and Currency that you use to distribute the wages and other compensations.

The payment types available for an organisation Payment Method are: Electronic Fund Transfer, Check, and Cash.

For any payment method through Electronic Fund Transfer (EFT), a bank account has to be set up in Payroll initially (for instructions, please see the tutorial on Accounts and Bank Setup).

For Payroll processing, at least one payment source has to be defined for each organisation payment method. This can be a bank account or any other source of funds. In Oracle Fusion Cash Management, it is associated with an active bank account.

For multiple payment sources, payment rules are used to determine the appropriate payment source based on the tax reporting unit (TRU).

The task associated with it is Manage Organisation Payment Methods.

Personal Payment Methods

It is the definition of how the payments are handled from the employee’s perspective (those within the organisation).

If an employee does not have a bank account, then a personal payment method has to be attached to him/her, and it is usually either Check or Cash.

A Personal Payment Method can be created only when the Payroll is assigned to a person and valid payment methods are assigned to the Payroll. It is possible to assign multiple Personal Payment Methods for a single person. For example, an employee can be assigned two personal payment methods as follows: 50% of his/her payment through EFT (a bank account is required for this) and the other 50% through Check.

In case a personal payment method is not assigned to an employee, the Default Payment Method that is provided at the time of Payroll Definition will be utilised for that employee.

An important aspect of the personal payment method is that it has to be associated with an organisation payment method in order to specify the payment source. As with the organisation payment method, a bank account is required for EFT payment.

Other aspects are:

• Processing Order - in the case of multiple payment methods, the order in which those methods have to be processed is to be specified

• Amount Type - the type of payment to be done

• Amount - the actual amount of payment

The task associated with it is Manage Personal Payment Methods.

Third Party Payment Methods

It is the definition of how the payments relating to external organisations and people who are not on the Payroll are handled. Third parties can include suppliers, professionals, or organisations that are hired by the organisation for their products and/or services.

When Third Parties are created, corresponding records for them are created as trading community members in the trading community application. Third parties can either be persons (individuals) or organisations:

• Third Party Persons - the application automatically assigns a party usage code for the External Payee

• Third Party Organisations - you assign a party usage code specifying whether it is a Pension Provider, a Professional Body, or simply an External Payee.

After creating the required third parties, payment methods can be created for the third parties so that they can be utilised in Payroll processing.

When creating a Third Party Payment Method for an organisation, an Organisation Payment Method has to be provided. For a Third Party Payment Method to a third party person, an Organisation Payment Method has to be provided along with the relationship with any employee within the organisation.

A bank account is needed if the Payroll Organisation Payment Method is EFT.

Payment methods are associated with the Payment Distribution Work Area. The task associated with it is Manage Third Party Payment Methods.

Fig. 1 - The Payroll Distribution Work Area

This tutorial deals with Fusion Payroll, and how it functions. In this part, we will discuss about the UIs related to Payment Methods and Organisational Payment Methods in Payroll.

Payment Methods

As discussed in the previous part of the tutorial, Payment Methods are the definition of how the payments are handled through organisations and employees. They are the means by which the actual payment takes place, once the components of Payroll like balances, earnings and deductions, etc. are set up. There are three types of payment methods: Organisation Payment Methods, Personal Payment Methods, and Third Party Payment Methods.

Note: For any payment method done through Electronic Fund Transfer (EFT), a bank account has to be set up in Payroll. Use the Set Up Banks, Branches, and Accounts set of tasks to do this. You can refer to the tutorial on Oracle Fusion Payroll - Accounts and Bank Setup for the instructions to do so.

Fig. 1 - The Set Up Banks, Branches, and Accounts tasks

First, a default payment method has to be attached to your Payroll. The following steps instruct how to do so:

1. Click on Payroll -> Payroll Calculations from the Navigator menu.

2. Click on Manage Payroll Definitions under Manage Payroll Process Configuration in the Payroll Calculations Work Area.

3. Search for a Payroll from your Legislative Data Group and click on the name of the Payroll.

4. Click on Edit -> Correct on the top right-hand corner to edit the Payroll definition.

5. Select a default payment method from the dropdown (as shown in the screenshot below).

6. Click on the Add icon under Valid Payment Methods (circled in the screenshot below) and add the required valid payment methods from the dropdown.

7. Click on the Submit button on the top right-hand corner.

Fig. 2 - Managing Payroll Definitions

Fig. 3 - Editing a Payroll Definition

Fig. 4 - Adding a default payment method

Fig. 5 - Adding valid payment methods. The Add icon is circled

Note: The steps below instruct on how to create and edit payment methods through the Payment Distribution Work Area. In the case of Organisational and Third Party Payment Methods, this can also be done through Setup and Maintenance by using the Manage Organisation Payment Methods, Manage Third Parties, and Manage Third-Party Payment Methods tasks under Define Payment Methods.

Fig. 6 - The Organisation Payment Methods, Manage Third Parties, and Manage Third-Party Payment Methods tasks

Organisation Payment Methods

It is the definition of how the payments are handled from the organisation’s perspective. For any payment method through Electronic Fund Transfer (EFT), a bank account has to be set up in Payroll initially (for instructions, please see the tutorial on Accounts and Bank Setup).

The task associated with it is Manage Organisation Payment Methods.

1. From the Navigator menu, click on Payroll -> Payment Distribution to go to the Payment Distribution Work Area.

2. From the Payment Distribution Work Area, click on Manage Organisation Payment Methods under Payment Methods (circled in the screenshot below).

3. Select your Legislative Data Group and click on the Search button.

4. From the search results, click on the name to view or edit the required payment method.

5. To create a new payment method, click on the New icon (circled in the screenshot below).

6. The Legislative Data Group will already be selected. Enter the Effective Date and click on the Continue button.

7. Enter the details of the payment method. You can view the instructions for each field by clicking on them. After the details are entered, click on the Save button.

8. Click on the Add icon (circled in the screenshot below) to add a payment source to the payment method.

9. Enter the details of the payment source. Use the dropdown list to add a bank account as the source. After entering the details, click on the Continue button to add the payment source to the payment method.

10. By default, a payment rule will be created without a specified Tax Reporting Unit (TRU) for all operations in the organisation. To add a specific payment rule, use the Add icon under Payment Rules.

11. Click on the Submit button on the top right-hand corner.

Fig. 7 - The Navigator menu

Fig. 8 - The Manage Organisation Payment Methods task

Fig. 9 - Organisational Payment Methods

Fig. 10 - The page of an organisation payment method

Fig. 11 - The New Payment Method icon is circled

Fig. 12 - Creating a new organisation payment method

Fig. 13 - Entering the details of the payment method. The Add icon is circled

Fig. 14 - Adding a payment source

Fig. 15 - The added payment source shows up in the payment method page

Fig. 16 - Default payment rule gets added

This tutorial deals with Fusion Payroll, and how it functions. In this part, we will discuss about the UIs related to Personal Payment Methods and Third Party Payment Methods in Payroll.

Payment Methods

As discussed in the previous part of the tutorial, Payment Methods are the definition of how the payments are handled through organisations and employees. They are the means by which the actual payment takes place, once the components of Payroll like balances, earnings and deductions, etc. are set up. There are three types of payment methods: Organisation Payment Methods, Personal Payment Methods, and Third Party Payment Methods.

Personal Payment Methods

It is the definition of how the payments are handled from the employee’s perspective (those within the organisation).

In case a personal payment method is not assigned to an employee, the Default Payment Method that is provided at the time of Payroll Definition will be utilised for that employee. (Please see the previous part of the tutorial for instructions on how to set a default payment method for a Payroll).

The task associated with it is Manage Personal Payment Methods.

1. Click on Manage Personal Payment Methods under Person in the Payment Distribution Work Area.

2. Search for the name of the person, i.e. the employee, and select the Legislative Data Group, then click on the Search button.

3. From the search results, click on the name of the person.

4. Click on the New icon (circled in the screenshot below) to add a personal payment method to the person.

5. Enter the details of the payment method. Use the dropdown to select the Organisation Payment Method (to specify the payment source). Click on the Save button followed by the Submit button on the top right-hand corner.

6. In case the Organisation Payment Method is through EFT, a bank account has to be added to the person. Use the New icon (circled in the screenshot below) to do so.

7. Enter the bank account details and click on the Save button.

Fig. 1 - The Manage Personal Payment Methods task

Fig. 2 - Searching for a person (employee)

Fig. 3 - Adding a new personal payment method. The New icon is circled

Fig. 4 - Entering the details of the payment method

Fig. 5 - Adding an EFT payment method

Fig. 6 - Entering the bank account details

Fig. 7 - The two payment methods are added to the person

Third Party Payment Methods

As discussed before, it is the definition of how the payments relating to external organisations and people who are not on the Payroll are handled.

When creating a Third Party Payment Method for an organisation, an Organisation Payment Method has to be provided. For a Third Party Payment Method to a third party person, an Organisation Payment Method has to be provided along with the relationship with any employee within the organisation.

Fig. 8 - The Manage Third Parties and Manage Third-Party Payment Methods tasks

First, any third party has to be added by using the Manage Third Parties task:

1. Click on Manage Third Parties under Payment Methods in the Payment Distribution Work Area.

2. To create new third parties, use the New icon. To edit third parties, search for their name and click on the Edit icon.

3. After editing any necessary details, click on the Save button followed by the Submit button.

Fig. 9 - Managing third parties

Fig. 10 - Editing third party information

After the creation of the third parties, they are now ready for a payment method to be attached to them. The following steps instruct on how to do so:

1. Click on Manage Third-Party Payment Methods under Payment Methods in the Payment Distribution Work Area.

2. Search for the required third party using the name and Legislative Data Group and click on the Search button.

3. To create a new third-party payment method, click on the New icon (circled in the screenshot below).

4. Select the third-party type (Organisation or Person) and click on the Continue button.

5. Enter the details of the payment method. Use the dropdowns to select the Third-Party Name and the Organisation Payment Method. Then click on the Save button followed by the Submit button on the top right-hand corner.

6. In case of a third-party person, the Payroll Relationship has to be attached for the third-party person to an employee. Use the dropdown to select the required employee.

7. To add another Payroll Relationship, click on the Add icon (circled in the screenshot below) to add a new employee as a relationship to the third party.

8. Click on the Save button followed by the Submit button on the top right-hand corner.

Fig. 11 - Creating a new payment method

Fig. 12 - Selecting the party type

Fig. 13 - Entering the details of the payment method

Fig. 14 - Creating a third-party person payment method

Fig. 15 - Entering the details of the third-party person payment method. The Add icon is circled

Fig. 16 - The list of third party payment methods after creation

This tutorial deals with Fusion Payroll, and how it functions. In this part, we will discuss about Object Groups and Process Configuration.

Object Groups

Object Groups are user-defined sets of elements or people that restrict the items that are included in various processes and reports. It is a mechanism by which you can set up a definition to retrieve an appropriate set of entities (elements or people) which would be used for payroll calculation or other processes.

There are four types of object groups:

• Element Group - It limits the elements processed for payroll, reporting, or cost distribution processes. There are two element groups:

  • Run Group - specifies the elements to use in a process.

  • Distribution Group - defines the grouping of elements to distribute element costing results.

• Payroll Relationship Group - It limits the persons processed for payroll, data entry, and reporting.It can be Static (relationships are defined directly) or Dynamic (relationships are assigned through formulas).

• Work Relationship Group - It limits the persons processed for human resources and reporting. It can be Static or Dynamic.

• Deduction Card Group - It is a grouping of calculation cards for year-end processing based on the legislations.

The task associated with it is Manage Object Groups.

1. Go to the Manage Object Groups task under Define Object Groups.

2. Click on the Search button to view a list of Object Groups that have been created.

3. To create a new object group, click on the New icon (circled in the screenshot below).

Fig. 1 - The Manage Object Groups task

Fig. 2 - The Manage Object Groups page. The New icon is circled

To create an Element Group, follow the below steps:

1. Type in a name for the object group and select the object group type as Element Group from the dropdown. Then, click on the Continue button.

2. Click on the magnifying glass icon (circled in the screenshot below) next to the Usage Type.

3. Search for the required object group parameter and click on its name from the search results. The parameter will then get added to the object group. Click on the Next button on the top right-hand corner.

4. Click on the Add icon (circled in the screenshot below) to add an element classification inclusion or exclusion.

5. Search and select the required element classification.

6. After adding the element classifications, click on the Save button followed by the Submit button on the top right-hand corner.

Fig. 3 - Creating a new object group

Fig. 4 - The details of the object group being created

Fig. 5 - Searching and selecting the parameter

Fig. 6 - Parameter added to the object group

Fig. 7 - Adding an element classification

Fig. 8 - Searching and selecting an element classification

Fig. 9 - The element classification is added to the object group

To create a Payroll Relationship Group, follow the below steps:

1. Type in a name for the object group and select the object group type as Payroll Relationship Group from the dropdown. Select whether the object group is to be static or dynamic by using the appropriate radio button. Then, click on the Continue button.

2. Click on the magnifying glass icon (circled in the screenshot below) to add an object group parameter.

3. Search for the required object group parameter and click on its name from the search results. the parameter will then be added to the object group.

4. Click on the Add icon (circled in the screenshot below) to add a Payroll Relationship Rule to the object group from the dropdown.

5. Click on the Save button followed by the Submit button.

Fig. 10 - Creating a Payroll Relationship Group

Fig. 11 - Adding an object group parameter

Fig. 12 - Searching and selecting the object group parameter

Fig. 13 - Adding a Payroll Relationship Rule. The Add icon is circled

Similarly, Work Relationship Groups and Deduction Card Groups can be created by following steps similar to those mentioned above.

Process Configuration

Process Configuration is a mechanism by which you can configure the Payroll Process and Reports Execution.

There are two action parameters in Process Configuration:

• Logging - Detailed information about the process that is used for investigating problems. By default, there is no logging.

• Maximum Errors Allowed - The number of consecutive actions that can return an error before the entire process is given a status of ‘Error.’ By default, the maximum number of errors allowed is CHUNK_SIZE or 20. The minimum value for it is 0 (zero).

By default, there is a Default Group created,which will be used by default for all executions. The action parameters attached to the default group have default values assigned to them. These can also be changed if needed.

You can also create a User-Created Group, where you have to attach the action parameters along with their values.

Upon the execution of the processes, the process configuration groups will be used. In case of default groups, the default action parameters will be used to provide information on the process. In case you required more detailed information on the processes executed, you can use the user-created groups for better and more detailed information.

The task associated with it is Manage Payroll Process Configuration.

1. Go to the Manage Payroll Process Configuration task under Define Object Groups. (Note: In case the task isn’t visible on the task list, use the Add icon to search and add the task to the list)

2. Click on the Default Group tab on the top left-hand corner of the page.

3. Click on the New icon (circled in the screenshot below) to add action parameters.

4. Choose the Logging Category parameter from the dropdown list. Enter a default value for the parameter and click on the Save and Close button.

5. Click on the New icon again.

6. Choose the Maximum Errors Allowed parameter from the dropdown list. Enter the default maximum number of errors and click on the Save and Close button.

7. Click on the Done button. The Default Group is now created.

Fig. 14 - The Manage Payroll Process Configuration task

Fig. 15 - The Manage Payroll Process Configuration page

Fig. 16 - The Default Group tab. The new icon is circled

Fig. 17 - Adding the Logging parameter to the default group

Fig. 18 - Adding the Maximum Errors Allowed parameter to the default group

Fig. 19 - The parameters are added to the default group

To create a user-created group, follow the below steps:

1. In the Group Overrides tab of the Manage Payroll Process Configurations page, click on the arrow (circled in the screenshot below) and then the Add icon.

2. Type in a name for the configuration group and click on the Save and Close button.

3. The configuration group will be created with the default parameters. To edit a parameter, select it and click on the Edit icon (circled in the screenshot below).

4. Enter a value to override the default value and click on the Save and Close button.

5. Click on the Done button. Your user-created configuration group is now created.

Fig. 20 - Adding a new group

Fig. 21 - Creating a new configuration group

Fig. 22 - Editing the default parameters. The Edit icon is circled

Fig. 23 - Specifying an override value

Objective:

This training article is intended to provide step by step implementation of Inventory organization (IO). In the first part we will see the prerequisite setup for IO and the configuration of Inventory org in the second part.

Inventory Organization (IO):

Inventory Organization (IO) can be a physical or logical unit. It can be warehouse where we can maintain all the inventories which will follow some shift and have some schedule. Inventory organization is always specific to a legal entity.

Prerequisite setup for IO:

As we have discussed that the Inventory Organization will follow some shift and have some schedule. So, before configuring IO we need to define few prerequisite setup like Shifts, workday pattern and schedules. In order to configure the same Navigate>Procurement>Define common applications configuration for Procurement> Define Enterprise structure for procurement > Define facilities for Procurement

Click on Manage facility Shifts Task

Click on Create Icon

Create time shifts let say for 8 hrs and click on save and Close

The next step is to create Workday pattern. For that click on Manage facility Workday patterns

Click on Create Icon

Give the name of WP and click on add button

Mention the start day and the end day. In this case we have choosen 5 days a week. Attach the shift already created. Click on save and close.

The next step is to manage the schedule. For that click on Manage facility Schedules

Click on Create Icon

Name the schedule and click on add icon

Attach the workday pattern created. We can also create exceptions which would exclude leaves if we require. Click on

Save and close.

What do I mean when I say Transaction Write-Offs?

If a customer’s transaction is outstanding for a longest period and we have no clue as to if the customer is going to pay or not, we cannot trace the customer and now we want to write-off that transaction. This is also called as Bad Debts.

How to enter bad debts in Oracle Receivables?

As per Oracle Receivable’s standard functionality: There is no such term in Receivables as Bad Debts. Receivables suggests that we “adjust” the particular transaction.  Adjustments is type of write off that will address our Bad Debt scenario.

These are setup and transactions steps for creating and entering Bad Debt Adjustments

Setup Steps:

1. Create a Receivables Activity with Adjustment type, adjustment is called a receivable activity because it write offs the outstanding balance on customer.
2. Assign Approval Limit of user to write off amounts. Obviously we cannot let anyone just write off the outstanding balance so we have to define the user’s limit.

Transaction Steps:

1. Query the transaction to write off
2. Adjust the transaction

Here are the details for Setups: