11g Release 1 (11.1.2)
Part Number E20381-02
Contents
Previous
Next
|
Oracle® Fusion
Applications Incentive Compensation Implementation Guide 11g Release 1 (11.1.2) Part Number E20381-02 |
Contents |
Previous |
Next |
This chapter contains the following:
Define Source Systems for Incentive Compensation
Define Import for Incentive Compensation
Source systems are used to import data into Oracle Fusion Applications, and are used within the application to identify source data information. You can specify whether the source system is a Spoke system, such as a legacy system, or a Purchased system, such as data from a third party provider. You can also specify what type of data will be imported using the source system, for example, you can specify that a source system will import trading community members.
You can configure the following for a source system:
Source system code, name, and description
Source system type
Enable for Items, Trading Community Members, and Order Orchestration and Planning
You can create a source system code to uniquely identify the source system. Source system codes are used by the application when creating references between source IDs and the Oracle Fusion Applications database IDs. You can create a source system name and description to provide information that is more descriptive than the source system code.
Note
You cannot update the source system code once you have created the source system.
You must set up a source system as either a Spoke system, such as a legacy system, or a Purchased system, such as data from Dun & Bradstreet.
You should select which types of entities will be imported from the source system into the Oracle Fusion Applications database from the following:
Items
Trading Community Members
Order Orchestration and Planning
You can select one or more of these entity types as required for the source system. It is important to enable the correct entity types because each import UI filters source systems based on their entity type. For example, if a source system is enabled for Trading Community Members and Items, then the source system can be selected as a data source in the Trading Community Members and Items import UIs, but the source system cannot be selected in the Orchestration and Planning import UI.
Source System Entities are the entities, such as addresses and parties, which can be imported using a specified source system.
When you import data from a source system, all the entities in the source system data will be imported. Within the Source System Entities UI you can then choose to allow multiple source references, which allows mappings between one Oracle Fusion Applications database ID and multiple source IDs from the same source system.
Allowing multiple source system references means that when you import data from a source system you can merge multiple, or duplicate, source system records and create one record in the Oracle Fusion Applications database.
If you do not allow multiple source system references then an Oracle Fusion Applications database record will be created for every source system record. This means that you could potentially create duplicate records in the Oracle Fusion Applications database.
Address cleansing provides a way to validate, correct, and standardize addresses that are entered in a user interface. Geography validation only validates the geography attributes of an address, for example, State, City, and Postal codes; address cleansing validates both the geography attributes and the address line attributes.
Address cleansing can only be used through the Oracle Fusion Trading Community Data Quality product, because the feature is delivered using Data Quality integration. You need to ensure that you have a license for the countries that will use Trading Community Data Quality data cleansing.
You can specify the real time address cleansing level for each country by choosing either None, meaning that there is no real time address cleansing, or by choosing Optional, meaning that you will have the choice to cleanse addresses. Once you have enabled address cleansing for a country a Verify Address icon appears at address entry points in the application. You can then click the icon to perform address cleansing and receive a corrected, standardized address. If Trading Community Data Quality does not find a matching address the application will alert you.
There are three components that are dependent on each other when defining a country: geography structure, geography hierarchy, and geography validation. Every country has to have the geography structure defined first before the hierarchy can be defined, and the geography hierarchy has to be defined before the validation can be defined.
Firstly, you need to create a geography structure for each country to define which geography types are part of the country structure, and how the geography types are hierarchically related within the country structure. For example, you can create geography types called State, City, and Postal Code. Then you can rank the State geography type as the highest level within the country, the City as the second level, and the Postal Code as the lowest level within the country structure. Geography structure can be defined using the Manage Geographies task, or can be imported using tasks in the Define Geographies activity.
Once the geography structure is defined, the geographies for each geography type can be added to the hierarchy. For example, below the United States you can create a geography called California using a State geography type.
As part of managing the geography hierarchy you can view, create, edit, and delete the geographies for each geography type in the country structure. You can also add a primary and alternate name and code for each geography. A geography hierarchy can be created using the Manage Geographies task, or can be imported using tasks in the Define Geographies activity.
After defining the geography hierarchy, you need to specify the geography validations for the country. You can choose which address style formats you would like to use for the country, and for each selected address style format you can map geography types to address attributes. You can also select which geography types should be included in geography or tax validation, and which geography types will display in a list of values during address entry in other user interfaces. The geography validation level for the country, such as error or warning, can also be selected.
A geography structure is a hierarchical grouping of geography types for a country. For example, the geography structure for the United States is the geography type of State at the top, then followed by the County, then the City, and finally the Postal Code.
You can use the geography structure to establish:
How geographies can be related
The types of geographies you can define for the country
You can determine how a country's geographies are hierarchically related by creating the hierarchy of the geography types in the geography structure. When you define a country's structure the country geography type is implicitly at the top of the geography structure, and the numbering of the subsequent levels start with 1 as the next geography level after country.
You must add a geography type as a level in the country structure before you can define a geography for that geography type in a country. For example, before defining the state of California, the State geography type must be added to the United States country structure. Only one geography type can be used for each level, you cannot define more than one geography type at the same level.
Note
After you first define a country structure you can only add geography types below the current lowest level, and delete geography types without defined geographies.
To simplify the creation of a country structure you can copy a structure from another country, and then amend the geography type hierarchy for the country.
The application provides you with a set of available master reference geography types. If required, you can create a geography type before adding it to the country structure. Each geography type is added below the current lowest level.
Note
If you want to delete a geography type that is not at the lowest level in the country structure, then you have to delete the geography type level and all the levels below it.
A geography type that you create within the country structure can be used for other country structures as well.
Geography hierarchy is a data model that lets you establish conceptual parent-child relationships between geographies. A geography, such as Tokyo or Peru, describes a boundary on the surface of the earth. The application can extrapolate information based on this network of hierarchical geographical relationships.
For example, in the geography hierarchy the state of California is defined as the parent of San Mateo county, which is the parent of Redwood City, which is the parent of the postal code 94065. If you enter just 94065, the application can determine that the postal code is in California, or that the corresponding city is Redwood City.
The application leverages geography hierarchy information to facilitate business processes that rely on geography information, for example, tax calculation, order sourcing rules, sales territory definition. The geography hierarchy information is centrally located in the Trading Community Model and shared among other application offerings.
The top level of the geography hierarchy is Country, so the hierarchy essentially contains countries and their child geographies. Other aspects of the geography hierarchy include:
Geography
Geography type
Geography usage
Master reference geography hierarchy
User defined zones
A geography is a boundary such as a country, state, province or city. It is a physical space with boundaries that is a defined instance of a geography type. For example, San Jose is a geography of the City geography type.
Geography types are a divisional grouping of geographies, which can be either geopolitical (for example, City, Province, and District) or user defined (for example, Continent, Country Regions, Tax Regions).
Geography usage indicates how a geography type or geography is used in the application. A master reference geography always has the usage of Master Reference. User defined zones can have the usages of Tax, Shipping, or Territory, based on what is relevant for their purpose.
The geography hierarchy data is considered to be the single source of truth for geographies. It is all the data, including geography types and geographies, that you define and maintain in the Trading Community Model tables.
The geography usage for the entire hierarchy is the master reference, and defined geography types and geographies are considered as master reference geography types and geographies. For example, Country is a universally recognized geography type, and United States is considered a master geography.
User defined zones are a collection of geographical data, created from master reference data for a specific purpose. For example, territory zones are collections of master reference geographies ordered in a hierarchy. Tax and shipping zones are collections of master reference geographies without a hierarchical grouping.
Geography validation determines the geography mapping and validation for a country's address styles, as well as the overall geography validation control for a country.
The No Styles Format address style format is the default address style format for a country. By defining the mapping and validation for this format you will ensure that validations can be performed for any address in the country. After the No Styles Format is defined you can set up additional mapping for specific address styles.
For each address style format, you can define the following:
Map to attribute
Enable list of values
Tax validation
Geography validation
Geography validation control
For every address style format, you can map each geography type to an address attribute. For example, you can map the State geography type to the State address attribute for the United States, or map the State geography type to the County address attribute for the United Kingdom. The geography types that appear are based on how the country structure is defined. The list of address attributes that appear are based on address formats delivered with the application, or your customer defined address formats.
Note
You only need to map geography types that you want to use for geography or tax validation purposes.
Once a geography type is mapped to an attribute, then you can specify whether the geography type will appear in a list of values during address entry in user interfaces. It is very important to review carefully if you want to enable a list of values. You should only enable a list of values if you have sufficient geography data imported or created for that geography. Once you have enabled a list of values for an address attribute, you can only select the geography data available for the geography type. This means that if a specific geography value is not available in the geography hierarchy, you cannot create an address with a different geography value.
You can also specify whether a geography type will be included in tax validation. For example, for the United States North America address style format you specify that County, State, and City are used for tax validation. This will mean that when a transaction involves an address with the North America address style, the address must have the correct county, state, and city combination based on the geography hierarchy data, to be considered valid for tax calculation.
You can specify whether a geography type will be included in geography validation. This will mean that, for example, when the user enters a United States address using the North America address style format, the address must have the correct country, state, and postal code combination based on geography hierarchy data to be considered geographically valid.
If an address element is mapped to a geography type, but not selected for geography validation usage, then suggested values can be provided for that address element during address entry, but that element is not validated.
Note
For either the tax or geography validation, do not skip more than one consecutive level unless you are certain that the selected geography types can uniquely identify geographies. For example, the United States country structure is: State, County, City, and Postal Code, and you want to select just State and Postal Code for geography or tax validation. However, for the combination of California and 94065, the city can be either Redwood Shores or Redwood City. In this case, you should also select at least the City geography type for geography or tax validation.
You can select the geography validation level for a country. Validation will check if the entered address maps to the geography hierarchy data available for the country, and the geography validation control determines whether you can save an address that did not pass validation during address entry. For example, if the validation level is Warning, then an address can still be saved if the values do not match the geography hierarchy data.
These are the geography validation levels you can choose:
Error - only completely valid addresses can be saved, with all mandatory address elements entered.
No Validation - all addresses can be saved including incomplete and invalid addresses.
Warning - invalid addresses are saved after warning users.
Regardless of the result of validation, the validation process will try to map any address attribute to a geography of the country, and store any mapping it could establish based on the available data. This is called Geography Name Referencing and it is executed as part of validation. The result of this referencing is used in several business processes in the application to map an address to a specific geography or zone.
You can create zone types and zones for the use of defining boundaries to be used in, for example, tax or shipping zones.
In order to create a zone boundary you need to define the following:
Zone types
Zones
Zone types categorize and group zones together, for example, the zone types of Income Tax and Shipping Regions.
Zone types need to be created before you define a zone for the geographical boundary. You can create a zone type which will contain geographical boundaries from anywhere in the world, or you can create a zone type that will only contain geographies from within a specified country. When you create a zone type that is bounded by a country you can define which geography types or geographies you will be able to choose when you create a zone.
After you have created the zone type click Next and you will be able to add zones. Zones are geographical boundaries for a zone type, for example, the San Jose Tax zone. Zones are based on the master reference geography hierarchy data.
Zones are created within a zone type, and you can associate geographies to define the zone. For example, for the Shipping Regions zone type you can create a West Coast zone which has the state of California as one of its geographies. Within a geography you can specify a postal range. So for the state of California, for example, you can specify that the zone spans from postal code 90001 to 90011.
Using the territory manager zone hierarchy you can build a zone hierarchy by creating zones and zone types, and by adding master reference geographies. The zones, master geographies, and hierarchies can then be used, for example, by Territory Management to define a sales region or geographical boundary that is allocated to a salesperson.
In a zone hierarchy you can do the following:
Create zone types
Create zones and add to a hierarchy
Move zones or geographies
Add geographies to a hierarchy
When you are creating a zone you need to specify a zone type. Zone types categorize and group zones together, for example, an APAC zone type. You will need to choose if the zone is part of an existing zone type, or if not, then you will need to create a new zone type. After you have created or added a zone type to the zone you can enter the zone name, the zone code name, and the zone's effective dates
You can create zones to describe geographical boundaries, for example, the Singapore Sales zone and the Southwest Sales Region zone. Zones can be placed below another zone or geography in the hierarchy, and geographies can be placed below a zone.
You can move existing zones or geographies into your hierarchy. You can select the zone or geography you want the zone to appear below, and then select an existing zone that you want to move. The zone and all its child records will appear below the zone or geography you selected.
You can create a hierarchy using the geographies from the master reference geography hierarchy data, and you can also add geographies to hierarchies created from zones.
When you are adding a geography to a hierarchy you have the option of either adding just the geography, or you can add the geography and selected child geographies. All the child geographies you select will automatically be added to the hierarchy, and will reflect the master reference geographical hierarchy. For example, when adding the United Kingdom geography to a hierarchy you can select that all the counties and postal codes will be added. When the hierarchy is generated the counties will be the level above the postal codes.
Note
You cannot have the same geography in more than one hierarchy.
Import objects are business entities that can be imported into the trading community model registry, for example, competitors, partners or resource teams. When you create a data import batch you should choose which business entity, or object, you are importing from the batch into the trading community model registry. For example, if you are responsible for resource management, you might want to import objects such as employee resource and resource team.
The import process flow will change according to which object you have selected. There are two import process flows for the following sets of objects:
Customer, reference, competitor, and custom party.
Employee resource, resource team, partner, and partner contact.
When you select these objects you will receive the option to check for duplicates within the import batch before the import, and the option to check for duplicates between the import batch and the trading community model registry before import. You will also be able to choose to preview data before it is imported, specify if addresses will be cleansed before import, and set the how many errors you will allow before the import is terminated.
If you choose to import these objects you will not be able to deduplicate the batch or registry data. However, you will be able to choose to preview data before it is imported, specify if addresses will be cleansed before import, and set the how many errors you will allow before the import is terminated.
You can use the import process to import a batch from the interface tables into the Trading Community Model registry. Before the data is imported into the registry you need to decide if you want to use the data quality services and if so, how you want to configure the data quality services. The data quality services are:
Batch deduplication
Registry deduplication
Import to registry options
Within the batch deduplication page you can decide if you want to identify and resolve duplicates within the batch that you are importing from the interface tables. If you want to check for duplicates you need to choose what match configuration rule you want to use to identify duplicates for each entity. Then you need to specify what action will be taken on the persons, organizations, and address duplicates found within the batch. Your specified actions will be performed on the batch before the data is imported into the registry.
Similar to batch deduplication, registry deduplication identifies duplicates between the data in the batch and the data in the registry before the data is imported into the registry. If you want to check for duplicates you need to choose what match configuration rule you want to use to identify duplicates for each entity. Then you need to specify what action will be taken on the persons, organizations, and address duplicates found in the registry deduplication check. Your specified actions will be performed when you import the batch into the registry.
When defining an import process you can decide whether to run the import process in preview mode, or you can choose to load the data directly into the registry without previewing the data. You can also choose to cleanse addresses prior to import, and you can define an error limit for the batch.
You can choose to run the import batch in preview mode, or you can skip the preview and load the data directly into the registry.
If you select to run the batch in preview mode you will be able to review information about the level of duplicates or incorrect addresses in the batch data before the data is actually imported. You will also be able to preview how many records will be created and how many records will be updated for each entity. You can then continue to import the batch, or you can amend the match configuration rules and actions to be taken on the identified duplicates and then rerun the batch to review the data again.
If you do not want to review the batch data before it is imported into the registry, then you can choose to skip the preview and allow the data to be loaded into the registry as soon as preprocessing is complete. You may prefer not to preview the batch data if the data source is frequently used.
Note
The Define Import: Import to Registry page is the only place that you can specify if you want to run the batch in preview mode. Once the option to skip the preview mode is selected, and you submit the batch for processing, you will not be able to review the batch data before it is imported.
You can choose to validate the addresses in the interface tables before importing them into the registry. The addresses are validated using an integrated third party service that verifies addresses and corrects them if they are incorrect.
You can define how many process errors can be generated by the import batch process before the process terminates automatically. Error reports are generated by the application for you to review.
This example demonstrates how to perform What-If analysis on a data import batch that has been processed and has completed with a status of pre-import completed. The match configuration is redefined and the import process is resubmitted. The batch deduplication actions are then amended, and the batch import is completed.
The following table summarizes key decisions for this scenario.
|
Decisions to Consider |
In This Example |
|---|---|
|
Do you want to redefine batch deduplication match configuration? |
Yes, a different match configuration is selected for the organizations entity. |
|
Do you want to redefine registry deduplication match configuration? |
Yes, a different match configuration is selected for the persons entity. |
|
What actions do you want to take on Persons, Organizations, and Addresses duplicates? |
|
The results of the batch and registry deduplication are not as expected and so the match configurations need to be redefined.
You want to view the What-If analysis for the new match configurations that you selected for the batch.
There are prerequisite setup tasks that you must perform in Oracle Fusion Incentive Compensation before importing and collecting the first set of transactions. You must also map the source data columns to the staging table columns.
Prerequisite Setup Tasks
|
Entities |
Description |
|---|---|
|
Calendars |
Before running the Collection process, you must define your calendars and intervals as well as open the period for which you want to collect data. |
|
Parameters |
Determine whether to set up and use the incentive compensation Crediting process as well as when you will run the Classification process. Also set up processing and payment currency options. |
|
Currency Conversions |
You can credit, calculate, and pay in either the participant's home currency or process using a single currency within each incentive compensation business unit. Even if you process in a single currency (operating currency), you may still pay using each participant's home currency. To process transactions without error, you must define currency conversion rates in the Application Setup work area. Also, you must associate home currency to each participant. If using operating currency for processing and payment, then default the participant's home currency to Operating Currency during participant import. |
|
Earning Types |
Define any unit of measure that you use for processing, other than monetary amount (already defined). |
|
Flexfields |
There are 150 additional transaction entity attributes for use in processing. Configure these descriptive flexfields for use as your business dictates. For example, if you want to include Customer on the transaction, then define one of the flexfields for this, as well as point to a data source (if other than Oracle Fusion Trading Community Architecture) to provide lookups to use for validation. |
|
Tables and Columns |
Enable any additional attributes as well as disable relevant attributes used in the Crediting or Classification processes as well as the calculation expression builder. |
Use the Oracle Data Integrator Mapping screens to set up the transaction sources and mappings between various columns to the Oracle Fusion Incentive Compensation staging table (CN_TP_TRANSACTIONS_STAGING_T). This table has the same schema as the transaction table (CN_TP_TRANSACTIONS_ALL), including the column called CHANGED_TRX_FLAG, which distinguishes whether a transaction is new or updated. You are responsible for maintaining the logic for importing new or updated source application transactions into the staging table using Oracle Data Integrator or another extraction, transformation, and load tool. Track transactions adjusted in the source application using the change data capture mechanism supported by Oracle Data Integrator, or any other custom logic. In staging, the application compares the composite key transaction number and transaction type to determine if the transaction is present before performing the Obsolete process.
Restriction
You cannot customize the Oracle Data Integrator mappings that are delivered with the product and used to load the data from the staging table into the transaction table. You can create your own custom script to use instead.
Yes. If the data is still available in the interface tables and the batch status is Preimport Completed, Completed with Errors, Error, or Terminated when Error Limit Reached, then you can redefine the data import process and reimport the batch. However, once a batch has been successfully imported then you will not able to reimport the batch, even if the data is present in the interface tables.
You can view any errors that occurred after submitting the batch for import by selecting the batch in the data import batches Overview page, and then click Report.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
