11g Release 1 (11.1.4)
Part Number E20381-04
Contents
Previous
Next
|
Oracle® Fusion
Applications Incentive Compensation Implementation Guide 11g Release 1 (11.1.4) Part Number E20381-04 |
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, Order Orchestration and Planning, and Assets
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
Assets
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, Items, and Assets, then the source system can be selected as a data source in the Trading Community Members, Items, and Asset 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 of the entities in the source system data will be imported. Within the Source System Entities UI, you can chose to allow multiple source references, which allows multiple records from a source system to map to a single trading community record.
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 during address entry suggested values will be provided for the address element, but the address element will not be 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 Error, then an address cannot 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.
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.
A geography, such as Tokyo or Peru, describes a boundary on the surface of the earth. You can create new geographies by importing data through interface tables. There are two options for populating the interface tables: using the tool of your preference to load the data or using file-based data import. If you plan to provide the data details in a source file, use the file-based import feature. If you will populate the interface table directly, run the geography loader process to import the data. Having a good understanding of the import entity, interface table, and destination table will help you prepare your import data.
Consider the following when importing geographies:
File-based import option
Geography loader process option
Import object entity, interface table, and destination tables
The file-based import process reads the data included in your XML or text file, populates the interface tables, and imports the data into the application destination tables. The File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the geography import object, create source file mappings, and schedule the import activities.
Populate the interface table with your import data, then navigate to the Run Geography Loader Setup and Maintenance task to schedule the import of data from the interface table to the destination table.
The geography import object consists of one entity and interface table that forms the geography. If you are using file-based import, you can map your source file data to import entity attributes that correspond to the interface table columns. The import activity process populates the interface table based on the mapping and your source file. If using the geography loader scheduled process, populate the interface table directly using your preferred tool. If you need the unique IDs of existing application data for your import data, use the Define Data Export Setup and Maintenance task list to export the information.
Note
Spreadsheets containing detailed information about each interface table, including the import attributes, corresponding interface table columns, defaults, and validations, are available from the Oracle Enterprise Repository by searching on a specific interface table name or initiating a search using the FusionApps: Interface Table asset type.
The following lists the object entity, tables, and resulting application object:
|
File-Based Import Entities |
Interface Tables |
Destination Tables |
Application Object |
|---|---|---|---|
|
ImpGeography |
HZ_IMP_GEOGRAPHIES_T |
HZ_GEOGRAPHIES HZ_GEOGRAPHY_IDENTIFIERS HZ_GEOGRAPHY_TYPES_B HZ_HIERARCHY_NODES |
Geography |
This example demonstrates how to import data using the File-Based Data Import tool. In this particular example you have a source file containing geography data that you want to import into the application, so that the geography data can be used for uses related to locations, such as real time address validation and tax purposes.
The following table summarizes the key decisions for this scenario:
|
Decisions to Consider |
In This Example |
|---|---|
|
What type of object are you importing? |
Geography |
|
What file type are you using for your source data? |
Text file |
|
Where are you uploading your source data file from? |
Your desktop |
|
What data type is your source data file? |
Comma separated |
|
Which fields are you importing into Oracle Fusion applications? |
All, except for the RecordTypeCode field |
|
When do you want to process the import? |
Immediately |
These are the steps that are required to create an import activity and submit the import:
Determine what information is in the source file.
Create and schedule the import activity.
Monitor the import results.
|
Geography Level |
Name |
Source ID |
Parent Source ID |
|---|---|---|---|
|
1 (Country) |
US |
1 |
|
|
2 (State) |
CA |
11 |
1 |
|
3 (County) |
Alameda |
111 |
11 |
|
4 (City) |
Pleasanton |
1111 |
111 |
|
4 (City) |
Dublin |
1112 |
111 |
You create an import activity, enter the import details, and schedule the import. An import activity definition provides the instructions for the import processing - this includes selecting the source file, or file location; mapping fields from the source file to the Oracle Fusion object and attribute; and scheduling the import.
|
Field |
Value |
|---|---|
|
Name |
Master Reference Geographies |
|
Object |
Geography |
|
File Type |
Text File |
|
File Selection |
Specific file |
|
Upload From |
Desktop |
|
File Name |
Choose relevant file from desktop |
|
Data Type |
Comma separated |
Note
Ensure that the file type that you select in the Create Import Activity: Set Up page matches the file type of the source data file.
|
Column Header |
Example Value |
Ignore |
Object |
Attribute |
|---|---|---|---|---|
|
Primary Geography Name |
Primary Geography Name |
United States |
Imp Geography |
Primary Geography Name |
|
Country Code |
US |
No |
Imp Geography |
Country Code |
|
Record Type Code |
0 |
Yes |
Imp Geography |
Record Type Code |
|
Source ID |
10265 |
No |
Imp Geography |
Source ID |
|
Parent Source ID |
1053 |
No |
Imp Geography |
Parent Source ID |
If you do not want to import a column in the text file you can select Ignore.
Note
If you have any difficulties mapping the fields from your source file to the relevant Oracle Fusion applications object, you can use the import object spreadsheets for reference.
Instead of immediately importing the data, you can choose a date and time to start the import. You can also specify if the import will be repeated, and the frequency of the repeated import.
You monitor the progress of the Import Activity processing, and view completion reports for both successful records and errors.
Once the import activity has completed, the Status field value will change to Completed.
Territory geography zones are geographical boundaries that you can set up to replicate your organization's regions, such as a Pacific Northwest sales region.You can set up territory geography zones in one Oracle Fusion applications instance, and then after the territory geography zones are defined you can export the territory zones and import them into another Oracle Fusion applications instance.
To define your territory geography zones and then import your territory zones into another Oracle Fusion applications instance, you need to complete the following steps:
Import the master reference geography data into the Oracle Fusion application.
Define your territory geography zones using the Manage Territory Geographies task.
Export the territory geography zones.
Import the territory geography zones into another Oracle Fusion applications instance.
Firstly, you need to import the master reference geography data. Master reference geography data consists of geography elements such as country, state, and city, and is required for any geographical information you store in the application, such as address information used in customer and sales records. For more information, refer to the Geography Hierarchy: Explained topic listed in the related topics section. Master reference geography data can be imported into the application using the Manage File Import Activities task in Setup and Maintenance - refer to the Importing Master Reference Geography Data: Worked Example topic listed in the related topics section for more information.
Once the master reference geography data has been imported, you can then create your territory geography zones in the application using the Manage Territory Geographies task in Setup and Maintenance. For more information, refer to the Managing Territory Geographies: Worked Example topic listed in the related topics section.
Once you have completed importing the master reference geography data and defining your territory geography zone tasks, you can create a configuration package to export the territory zone data. For more information, refer to the Exporting Setup Data demo listed in the related topics section.
Once you have downloaded your configuration package for your territory geography zone setup, you can import the territory zones into another Oracle Fusion application instance. For more information, refer to the Importing Setup Data listed in the related topics section.
Note
Ensure that you import your master reference geography data into the new Oracle Fusion instance before you import the configuration package.
This example shows how to start the configuration of the geography structure, hierarchy, and validation for the country geography of the United Kingdom.
The following table summarizes the key decisions for this scenario.
|
Decisions to Consider |
In This Example |
|---|---|
|
Copy an existing country structure? |
No, create a new country structure. |
|
What is the structure of the geography types? |
Create geography types with the following ranking structure:
|
|
What is the geography hierarchy? |
Create the following hierarchy:
|
|
Which address style format will you use when mapping geography validations? |
The default address style format, called the No Styles Format. |
|
Are you using Oracle Fusion Tax for tax purposes? |
No, do not select Tax Validation for the geography types. |
Add the County and Post Town geography types to the geography structure. Then add the geographies for the County and Post Town geography types to define the geography hierarchy. Finally, specify the geography validations for the geography types you have added to the geography structure.
You add the County and Post Town geography types to the United Kingdom geography structure.
You want to begin to create the geography hierarchy for the United Kingdom, so you add the geographies for the County and Post Town geography types using the geography hierarchy User Interfaces. You can also use the Manage File Import Activities task to import geography hierarchies using a csv or xml file.
Now you want to specify the geography validations for the geography types you have added to the United Kingdom. You define the geography mapping and validation for the United Kingdom default address style format. You map the geography types to attributes, enable the geography types for Lists of Values and Geography validation, and set the geography validation level.
When address data entered into the application needs to conform to a particular format, in order to achieve consistency in the representation of addresses. For example, making sure that the incoming data is stored following the correct postal address format.
You can only update a geography structure by adding existing geography types, or by creating new geography types and then adding them to the geography structure. You can only copy an existing country structure when you are defining a new country structure.
If a geography exists for a country geography structure level then you cannot delete the level. For example, if a state geography has been created for the United States country geography structure, then the State level cannot be deleted in the country geography structure.
Yes. However, the geography type for the geography that you want to add must be already added to the country geography structure.
Yes. In the Manage Geography Hierarchy page you can edit details such as the geography's date range, primary and alternate names and codes, and parent geographies.
Select the geography that you want your geography to be created below, and then click the Create icon. This will allow you to create a geography for a geography type that is the level below the geography type you selected. The structure of the country's geography types are defined in the Manage Geography Structure page.
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-2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
