11g Release 7 (11.1.7)
Part Number E20372-07
Home
Contents
Book
List
Contact
Us
|
Oracle® Fusion Applications Marketing Implementation Guide 11g Release 7 (11.1.7) Part Number E20372-07 |
Home |
Contents |
Book List |
Contact Us |
 Previous |
 Next |
This chapter contains the following:
Manage Public Unique Identifier Profile Options
Define Resource Organization Information
Define Resource Role Information
Define Resource Team Information
Define Products: Define Basic Items
Define Products: Define Advanced Items
Manage Calendar Profile Option
Define Sales Prediction Configuration
You can set up source systems to enable users to identify the source of the data they are importing into the Oracle Fusion database. 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 types of entities the source system contains, for example, you can specify that a source system will contain trading community member data.
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 to create 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; however, the source system won't be able to 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.
Oracle Fusion applications generate thousands of rows of data that require unique identifiers (UIDs). These automatically generated, 18-digit numbers are not easily read or used by humans. A cogent example is an electronic airline ticket whose numbers can be 13 digits long, such as, 0162128736572. There are also confirmation or itinerary numbers that relate directly to that ticket that are only six digits long, such as QDLG9S; these can be used interchangeably with the ticket number. These shorter confirmation numbers are much easier to read and process by passengers and employees alike. A separate Public Unique ID (PUID) is also generated by the document sequencing feature and is available for encoding into a more user-friendly, alphanumeric ID.
The Oracle Fusion default setup shows the automatically generated numeric private UIDs and PUIDs for data rows. To use an alphanumeric PUID instead of the delivered numeric, navigate to the Setup and Maintenance task Manage Public Unique Identifier Profile Options to enable the encoding process. There are two profile options to configure the PUID:
CRM Public Unique ID String Encoding controls the characters used in the encoding of the PUID based on a radix, or base number.
CRM Public Unique ID Prefix defines the optional prefix value for the PUID.
Document sequencing typically begins with the number one. You may choose to start the sequences of your PUIDs at a specific value. See the related links below to determine the document sequencing.
This profile option determines the set of numbers and letters to be used in encoding the PUID generated by the document sequencing feature. The PUID is delivered with the encoding set to none. To enable the encoding of the PUID, choose a radix, or base conversion algorithm. The available values are stored in the lookup type ZCA_PUID_ENCODING. These encoding methods convert the PUID into user readable IDs using alphanumeric characters rather than just numeric digits. For example, if BASE_26 is chosen, only the upper case letters of the alphabet will be used.
There are seven delivered base values. These are not extensible.
|
RADIX |
Values |
|---|---|
|
BASE_16 |
Numbers 0-9, letters A-F |
|
BASE_26 |
Letters A-Z, Upper Case |
|
BASE_29 |
Numbers 2-9, letters BCDFGHJKLMNPQRSTVWXYZ |
|
BASE_31 |
Numbers 0-9, letters ABCDEFGHJKLMNPQRTUWXY |
|
BASE_36 |
Numbers 0-9, letters A-Z upper case |
|
BASE_62 |
Numbers 0-9, letters A-Z, letters a-z |
|
NONE (default) |
No Encoding |
A prefix may be defined as a site-level profile option. This profile option is delivered with no prefix defined. When defined, the inserted text is prepended to the PUID base encoded document sequence value. For example, if the PUID was CLE123 and the Prefix was ORA, the new PUID would be ORACLE123. Any delimiters or separation characters desired must be defined in the prefix itself. Ensure that the prefix length is short enough so that the concatenated PUID and prefix do not exceed the defined field length, usually no more than 30 characters. For example, you may want the records for the pharmaceutical divisions of your company to be denoted with PUIDs and the prefix Pharma- or Pharma1, Pharma2, and so on.
Party usages describe how a party is used in the context of the implementing organization. For example, a person in the business community may be a consumer or contact. Rules can be associated to a party, and these rules determine when a party usage can and cannot be used.
These are the following rules that can be defined for a party usage:
Assignment rules
Exclusivity rules
Incompatibility rules
Transition rules
Assignment rules are used to define how the party usage can and cannot be assigned to parties. You can choose to allow unconditional party usage assignment, enabling the assignment to be manually created, or updated, by an administrator.
Alternatively, you can restrict the manual assignment and update of a party usage, which will mean that the party usage can only be created, or updated, by a business event. For example, creating an account for a party record can automatically assign the Customer party usage to that record.
You can also specify whether the party usage assignment can also be created or updated by the assignment of a party relationship. For example, the party relationship Contact Of can assign a party usage of Organization Contact.
Exclusivity rules enable you to restrict party usage assignment, so that between a specified date range the party usage can be the only usage allowed to be assigned to a party. For example, you can set up an exclusivity rule that between January 1 2011 and February 1 2011 parties that have the Manufacturer party usage cannot have any other party usage assigned to them.
You can specify which party usages cannot be assigned concurrently to a party between a defined date range. For example, you can specify that you cannot assign a Sales Account usage to a party with a Sales Prospect usage, during January 1 2011 and December 31 2030.
You are able to define which party usages can transition to the party usage you are creating or editing. Once a party has transitioned to the current party usage, the previous party usage is set with an end date. For example, when a party with the Prospective Partner party usage is assigned the Partner party usage, the Prospective Partner usage is set with an end date.
Define additional name types to capture alternative names for parties.
For example, create an additional name type NICK_NAME to capture the nick names of parties of type Person.
While creating an additional name type, specify the party type to which it applies. From then on, the additional name type will be available as a naming option for all parties of that party type within the deploying company. You can use additional name types to capture language-specific names as well.
Create additional identifier types to provide extensions to party attributes. For example, you can create an additional identifier type to record a person's passport number.
You can choose which party types can use the additional identifier type. These party types can be Person or Organization, or both. You can also specify whether the value of an identifier type must be unique. For example, the passport number listed under each person's profile must be unique.
Additional identifier types do not automatically appear in the user interface. If you want to use identifier types in the application you will need to call the Trading Community Member Name and Identifier Setup web service.
A relationship type categorizes relationship phrases and roles that determine the nature and purpose of a relationship. A relationship type defines the aspects of a relationship such as the roles of the subject and object, business rules, and phrases that describe the relationship. A relationship, uses the relationship type, to define how a party is related to another party.
The components of a relationship type are:
Relationship phrase pair and role pair
Relationship characteristics
A relationship type contains a relationship phrase pair and a role pair. Relationship phrase pair and role pair define the mutual roles that the two parties play in a relationship. For example, for relationship type Employment the phrase pair contains Employee of and Employer of; and, the role pair contains Employee and Employer.
The role pair describes the roles of the entities immaterial of the direction of the relationship. For example, in an Employment relationship Bill has the role of an employee and Oracle Corporation has the role of an employer.
The phrase pair describes the roles of the entities in the relationship. For example, in an Employment relationship if Bill is the subject and Oracle is the object, then the phrase would be Employee of. Similarly, if Oracle is the subject and Bill is the object, then the phrase would be Employer of.
Relationship types include characteristics or rules that define how the relationship type can be used.
While defining a relationship type, you can define if the relationship can be:
Circular
Related to self
Circular relationships have two parties related in a circle of relationships. For example, you can create a Competitor relationship type to link two organization parties. In this scenario, ABC Corp is a competitor to XYZ Corp, and XYZ Corp is also a competitor to ABC Corp.
You can create a self-relating relationship type, where the subject and the object of the relationship are the same. For example, you can create a Subsidiary relationship type, where a subsidiary organization ABC is linked to a parent organization XYZ. The parent organization XYZ, in turn, could be linked to itself as a subsidiary using the same relationship type.
This example demonstrates how to create a relationship type, and add relationship roles and phrases to the relationship type.
The following table summarizes key decisions while relationship types.
|
Decisions to Consider |
In This Example |
|---|---|
|
What are the subject and object party types for the relationship? |
The subject type and object type is organization. |
|
Is the relationship circular? |
Yes |
|
Can the subject related to self in this relationship? |
No |
You must search for the relationship type to make sure it does not already exist, before you create a relationship type.
|
Field |
Operator |
Value |
|---|---|---|
|
Relationship Type |
Equals |
Vendor |
|
Subject Type |
Equals |
Organization |
|
Object Type |
Equals |
Organization |
Review the search results. Ensure that there is no existing Relationship Type for the criteria.
|
Field |
Value |
|---|---|
|
Subject Type |
Organization |
|
Subject Phrase |
Vendor of |
|
Subject Role Singular |
Vendor |
|
Subject Role Plural |
Vendors |
|
Object Type |
Organization |
|
Object Phrase |
Vendee of |
|
Object Role Singular |
Vendee |
|
Object Role Plural |
Vendees |
This example demonstrates how to create a relationship group. Relationship groups are used to categorize relationship roles and phrases, based on the user interfaces they appear in.
In this scenario, you will create group for relationship types that link an organization to an external organization.
|
Field |
Value |
|---|---|
|
Name |
Related External Organizations |
|
Code |
REL_EXT_ORGS |
|
Description |
Indicates a group of relationships that link the organization to external entities. |
|
Subject Type |
Subject Role |
|---|---|
|
Organization |
Supplier |
|
Organization |
Vendor |
|
Organization |
Competitor |
Relationship groups categorize relationship phrase and role pairs for functional purpose. For example, you can assign the relationship phrase Subsidiary Of to a group, and assign the phrase Headquarters Of to a different group.
Relationship groups are used to determine which relationship roles and phrases are displayed in specific user interfaces of the Oracle applications. A relationship group can correspond to one or more Oracle Applications user interfaces. For example, you can configure an Oracle application to display only the relationship types that pertain to the Party Contacts information.
This example demonstrates how to create a relationship group. Relationship groups are used to categorize relationship roles and phrases, based on the user interfaces they appear in.
In this scenario, you will create group for relationship types that link an organization to an external organization.
|
Field |
Value |
|---|---|
|
Name |
Related External Organizations |
|
Code |
REL_EXT_ORGS |
|
Description |
Indicates a group of relationships that link the organization to external entities. |
|
Subject Type |
Subject Role |
|---|---|
|
Organization |
Supplier |
|
Organization |
Vendor |
|
Organization |
Competitor |
The classifications model provides you with a flexible tool to categorize entities such as parties, projects, tasks, and orders. Classifications enable you to classify an entity, such as a party, in a way that the rest of the world sees it, in addition to the way that it is referenced within your organization.
The major components of classifications are:
Classification categories
Classification rules
Classification codes
Classification code hierarchy
Entity assignment
Classification categories give you the ability to classify entities under a broad subject area. For example, you can classify organizations based on the industries they operate in. Classification categories are a logical grouping of one or more classification codes and allow classification code rules to be defined.
Classification categories can have rules that define how classifications can be assigned to entities. When you set up classification categories specific rules can be created, such as allowing the parent classification code to be assigned to a party, and allowing multiple classification codes to be assigned to an entity.
The individual values within the classification category are called classification codes. For example, in the 1987 SIC classification category there is a classification code of software that can be assigned to a party in the software industry. You can organize classification codes into a hierarchical tree, with a parent classification code at the top of the tree and child classification codes branching off from the parent code or other classification codes.
You can create hierarchies of classification codes within a classification category. For example, you can set up a classification category of IT containing the classification codes hardware, keyboards, and printers. You can then set up the classification code of hardware as the parent code at the top of the tree, with the classification codes of keyboards and printers as child codes underneath. You can create further child classification codes, such as dot matrix, ink-jet, and laser below the printer classification code.
Define which entities can be assigned to a classification category by entering the entity table name and creating a Where clause in SQL. Only entities that satisfy the Where clause are assigned the classification category. For example, a classification category called industries with the Where clause of where "party_type = ORGANIZATION" would have the result that only organizations can be classified with the industries classification category.
You can assign the parent classification code to an object, as well as the child classification codes. The parent classification code is the code at the top of the classification code tree.
If you don't allow parent classification codes to be assigned to an object, then you can assign only child classification codes, or codes that are below another classification code in the tree, to an object.
You can assign more than one classification code from this classification category to an object.
If you don't allow multiple classification codes to be assigned to an object, then you can assign only one classification code from this classification category to an object.
No. You can delete the entity assignment rule and create a new one.
Telephone Numbering Plans allow you to define the telephone number format for a country. You can have multiple formats for a country, depending on the requirements.
Phone number format, along with the other country-specific location information such as address and name formats, defines geographic-specific data formats. The Manage Telephone Numbering Plans page allows you to create and manage telephone number plans. Oracle Fusion uses the telephone number formats to display phone number in the appropriate style, and to validate phone numbers. You can define country-specific components of phone numbers, display format styles, and area codes. Oracle Fusion uses the phone formats to correctly parse phone numbers and determine the correct format style for displaying phone numbers in user interfaces.
Oracle Fusion validates phone numbers for a country, based on the format defined for the country. The phone numbers are also validated against a common set of rules that apply to all countries. You can also enter time zone information for a country, at the country code and area code level. The time zone information entered with phone number is validated against the time information defined for the country.
A telephone numbering plan defines the expected number and pattern of digits for a country phone number. It defines the country-specific components of phone numbers, display format styles, and codes. This includes country codes, international prefixes, area codes within a country, and mobile prefixes. You can specify country-specific mobile prefixes to determine if a phone number is mobile or not.
You can also create multiple telephone number display formats for a country. For example, for the US phone format, you define the phone country code as 01, fixed area code as three numbers in length, and subscriber number as seven digits in length. You can then create a telephone format for domestic display, such as (999) 999-9999. You can also create a telephone format for international display, such as 999-999-9999.
You can update telephone number plans from the Edit Telephone Number Plan page. You cannot edit the country information if the country has area codes, mobile prefixes, or phone formats defined.
In the Edit Telephone Number Plan page, you can:
Edit Scheme
Edit Regional Information
You can edit the country-specific phone information in the Scheme section. You can edit the following fields in the section:
Trunk Prefix: The code to dial before long distance numbers within the country, for example 1 for the US
International Prefix: The code to dial before international numbers when calling from the country that you are setting up, for example 011 for the US
Subscriber Number Length: The length of the subscriber number for countries where the subscriber length is fixed.
Area Code Length: The length of the area code for countries where the area code length is fixed.
You can edit the regional phone number information for the country in the Regional Information section.
The Regional Information section contains the following tabs:
Area Codes: Allows you to define area codes that you want to use for the country.
Mobile Prefixes: Allows you to define mobile prefixes that you want to use for this country. Mobile prefixes contain the area code and possible prefixes of the subscriber number. For example, the mobile prefix of 650506 consists of the 650 area code and the 506 subscriber number prefix.
Telephone Number Formats: Allows you to define multiple telephone number display formats for a country.
You cannot update the country information for a country if the regional information such as area codes, mobile prefixes, and phone formats are defined for the country. For example, if area codes, mobile prefixes, and phone formats are defined for the United States, then you cannot edit the country information.
Data Formats help you define address formats and name formats within your organization, and assign them to specific geographies. These data formats can be used to capture and validate party name and address information. In order to use geography-based validations for addresses, you must set up geography data in addition to the address formats.
You can define new styles for name and address, which would categorize a name and address style format. A Data Style, such as Mailing Address or Concatenated Name, categorizes name and address style formats. Oracle Fusion uses Data Styles to identify a particular manner or situation for which an entity, such as name or address, is formatted. The application can be customized so that, for example, only certain name and address styles are displayed in the user interface.
Use Data Formats to ensure party address and party name data quality. The format is used to present the address elements in the country specific formatting, and help users during address entry. This also provides the flexibility to specify the scope of address validation. Address formats are linked to the geographic data in order to provide address verification, at the data-import level. For example, when creating or editing an address for a party, selecting a country displays the address format for that country.
The use of Name formats ensures that name components are stored in a decomposed manner. This allows you to construct name representations from components in a variety of different styles. Name formats also allow you to store phonetic names that are required for certain geographies.
Data Formats simplify the storage of party address and party name, by storing them as components. Once you setup the address and name format for a geography, you can use the format to validate address and name data.
Data Formats determine how names and addresses are displayed in the Oracle Fusion application. Name and address formats vary depending on usage, country, and language. You can create name formats and address formats, customize them to display the address and name components, and assign them to specific locales. This allows you to create data formats for various countries, languages, and usages. Additionally, you can create variations of the formats, with each variation having its own layout. For example, an address format may have variations of a general address, rural address, and military address.
There are two types of data formats.
Address format
Name format
Address formats specify the layout of an address, including the address components and their position in the layout. For example, an address format for US postal address can include address, city, state, and zip code. Similarly, the address format for UK would include address, city, county, and post code.
Name formats, such as Informal or Mailing, allow you to specify how a name is displayed in the application, based on the usage, language, and country. A name format includes name elements, their position, and formatting. You can create a name style format for either an organization name or a person name.
This example shows how to create an address style format for a specified address style.
Specify the address style format name and address style, create the format variation layout, and assign a locale.
Create the address style format code and name, choose which address style you want to use to define this address style format, and specify if you want this address style format to be the default format for the selected address style.
|
Field |
Value |
|---|---|
|
Code |
CA_POSTAL_ADDR |
|
Name |
Canadian Postal Address Format |
|
Address Style |
Postal Address |
|
Default |
No |
Specify the address lines you want in the address and the position of the lines in the address layout. You also want to specify if the address lines will be mandatory, whether the address lines will render in uppercase, and whether there will be blank lines after the address line.
|
Field |
Value |
|---|---|
|
Line |
1 |
|
Position |
1 |
|
Prompt |
Address line 1 |
|
Address Element |
Address line 1 |
|
Required |
Yes |
|
Uppercase |
No |
|
Field |
Value |
|---|---|
|
Line |
2 |
|
Position |
2 |
|
Prompt |
City |
|
Address Element |
City |
|
Required |
Yes |
|
Uppercase |
Yes |
Specify the relevant countries for this address style format.
This example shows how to create a name style format for a specified name style.
Specify the name of the name style format and name style, create the format variation layout, and assign a locale.
You create the name style format code and name, and choose which name style you want to use to define this name style format. You also specify if you want this name style format to be the default format for the selected name style.
|
Field |
Value |
|---|---|
|
Code |
CONCAT_NAME_US |
|
Name |
United States Concatenated Name Format |
|
Name Style |
Concatenated Name |
|
Default |
No |
Specify the name parts you want in the name, and the position of the name parts in the name layout. You also want to specify if the name parts will be mandatory, define whether the name parts will render in uppercase, and whether there will be blank lines after the name part.
|
Field |
Value |
|---|---|
|
Line |
1 |
|
Position |
1 |
|
Prompt |
Person First Name |
|
Name Element |
First Name |
|
Required |
No |
|
Uppercase |
No |
|
Field |
Value |
|---|---|
|
Line |
2 |
|
Position |
2 |
|
Prompt |
Person Last Name |
|
Name Element |
Last Name |
|
Required |
No |
|
Uppercase |
No |
Specify the relevant countries for this name style format.
Click New in the Manage Address Formats page and add address lines in the Format Variation Layout section. If you require more than one address style format layout, then you can create a format variation and add a different address format layout.
You can create different variations of an address style format, with each variation having its own layout. For example, a country's postal address may have variations such as general postal address, rural address, and military address. When you create an address style format, the layout defined for the format is assigned as the default variation. Click Add in the Format Variation region of the Edit Address Style Format page, for the address style format, to add a variation of the Address style. For each address style format variation, you can enter a variation rank to define the priority of the variation.
Click New in the Manage Name Formats page and add line entries for each part of the full name in the Format Variation Layout section, within the Create Name Style Format page. If you require more than one name style format layout, then you can create a format variation and add a different name format layout.
You can create different variations of a name style format, with each variation having its own layout. For example, different regions in a country may have different name style formats. Click Add in the Format Variation region in the Edit Name Style Format page, for the name style format, to add a variation of the name style. For each name style format variation, you can enter a variation rank to define the priority of the variation.
A note is a record attached to a business object that is used to capture nonstandard information received while conducting business. When setting up notes for your application, you should consider the following points:
Note Types
Note Type Mappings
Note types are assigned to notes at creation to categorize them for future reference. During setup you can add new note types, and you can restrict them by business object type through the process of note type mapping.
After note types are added, you must map them to the business objects applicable to your product area. Select a business object other than Default Note Types. You will see the note types only applicable to that object. If the list is empty, note type mapping doesn't exist for that object, and default note types will be used. Select Default Note Types to view the default note types in the system. Modifying default note types will affect all business objects without a note type mapping. For example, you have decided to add a new note type of Analysis for your product area of Sales-Opportunity Management. Use the note type mapping functionality to map Analysis to the Opportunity business object. This will result in the Analysis note type being an available option when you are creating or editing a note for an opportunity. When deciding which note types to map to the business objects in your area, consider the same issues you considered when deciding to add new note types. Decide how you would like users to be able to search for, filter, and report on those notes.
Note
Extensibility features are available on the Note object. For more information refer to the article Extending CRM Applications: how it works.
The Resource Directory offers detailed information about all the resources within the deploying organization. The Resource Directory also enables you to find and communicate with other resources, and to network and collaborate with them.
Use the Resource Directory to perform the following tasks:
View and modify your profile
View your organization and team membership information
View information related to other organizations and teams
View the profiles of other resources
Communicate with other resources
Setting up resources involves identifying a person as a resource and specifying optional profile details as needed. This is an important step because until you identify users as resources, you cannot assign work objects to them.
While identifying a resource is the only mandatory task in resource setup, you may also need to perform some of the following tasks while setting up resources.
Specify the end date for a resource's engagement with the deploying company
Assign roles to resources
Assign resources to organizations
Assign resources to teams
The Identify Resources step in the Manage Resources task is only needed to identify an existing employee, contingent worker, or partner member as a resource. Usually they are identified as resource in the Manage Users task, or in the Partner Center. If you have created partner members or internal users in the system without making them resources, you can identify them as resources in the Identify Resources step. Until you identify employees, contingent workers, and partner members as resources, you cannot assign them work objects.
Note
Resources need not necessarily belong to an organization, nor do they need to have specific roles assigned. However, it is best to always associate resources with an organization either as managers or as members. Similarly resources should also have at least one role as part of their organization membership. When you identify users as resources, all you indicate is that these new resources can now be assigned work within the deploying company.
Resource skills help you assign resources to organizations and teams which can best utilize a specific set of skills. For example, if a resource is skilled in a specific technology, product, or business domain, you can assign the resource to teams and organizations that need resources possessing such skills. Use skill-based resource assignment to get the best out of the resources available to the deploying company.
You can include resources from different resource organizations to work together on a work object as members of the same resource team. You can also include entire resource organizations into a resource team. Generally what resources can do is controlled by their resource organization membership and their hierarchy. Resource teams provide a flexible way of bringing resources together without any organizational or hierarchy-based restrictions.
You can assign identified resources to teams and assign them roles within the team. Each resource can have a specific role within a team. Thus, a resource may play different roles in different teams.
When you add a resource to an organization, the resource becomes a member of the organization. This positions the resource within the organization hierarchy.
Organization membership information is part of the publicly visible details of a resource profile. This means that a resource's organization membership and reporting structure are visible to all active resources within the organization.
If you assign the entire organization to a resource team, all member resources are automatically assigned to the team. This information also becomes part of the resource's publicly visible profile.
When you delete a resource, the resource is deleted from the Resource Directory and from the organizations and teams with which the resource was associated. It is always best, though, to check a resource's usage and remove the resource from all teams and organizations before deletion from the resource directory.
The main difference between an internal resource and a partner resource is the company for whom each works. While the internal resource is an employee or contingent worker of the deploying company, the partner resource is an employee of the partner company.
The methodology used to create resources of these two types is also different. While the partner administrator or channel manager creates a new partner resource through the Oracle Fusion Partner Management applications, internal resources are added using the Manage Users, Hire Employee, or Import Person and Organization task.
Another difference between partner resources and internal resources is that partner resources cannot access the Resource Directory while internal resources can.
No. You can only identify existing employees and contingent workers as resources in the Manage Resources task, but you cannot create a new employee or contingent worker in the Manage Resources task.
You can create an employee or contingent worker using Manage Users task, Hire Employee task, or Import Person and Organization task.
When resources quit, their status is set to inactive. This automatically removes these resources from all organizations and teams in the deploying company, and no new work objects can be assigned to them.
To identify specific employees, contingent workers, or partner contacts as resources, you need to search for them and enable them as resources. Once these new resources have been identified, you can assign them to organizations and teams as needed.
Oracle Fusion CRM or MDM Application Administrators can use the Manage Users setup task to create new employees or contingent worker users. New employees or contingent workers can also be identified as resources similarly.
You can assign organization usage information to resource organizations to classify them based on how they can be used. For instance, resource organizations engaged in sales activities can be assigned the Sales Organization usage. This enables you to sort organizations based on their usage, simplifying your task of working with them.
A resource can belong to multiple organizations, and can be assigned different resource roles for each organization. However, a resource can be assigned to one resource organization that becomes the primary organization for the resource as far as a specific usage is concerned.
A resource organization can be said to be a primary resource organization by usage for a resource if the following criteria are met.
The resource must be a member of the concerned organization.
The resource organization must be classified as an organization with the specific usage.
For example, a resource organization can be listed as a primary resource organization for marketing for a particular resource if the resource organization is classified as a marketing organization by usage, and has the concerned resource as a member.
As organizations evolve, you may need to make changes to the existing organization hierarchy. Create organization hierarchies to capture these changes without impacting active hierarchies.
Depending on the urgency and nature of the changes within the deploying company, organization hierarchy changes can either be immediate or planned.
In case of immediate changes in the organization hierarchy, either make changes directly to the hierarchy or create a new version of the existing hierarchy and set it to become active when the new organization structure needs takes effect.
Note
Changes made to existing hierarchies are saved automatically and updated immediately.
Create a new version of the active hierarchy and specify the date on which the new version needs to become active. Once the new version is saved, you can make and save the changes needed. Ensure that you have made all the changes needed to the new version before the date on which the new version needs to become active.
When you assign a resource to an organization, you should also specify the role the resource needs to play in the organization. This ensures clarity on the kind of tasks that can be assigned to a resource, apart from defining where the resource is situated within the organization's hierarchy.
Note
There can be only one manager in an organization. However, a resource can be a member of multiple organizations if needed.
This example demonstrates how to create a resource organization with sales usage.
you have two choices while creating resource organizations with sales usage:
Create an organization from an existing department
Create a new organization
These tasks can be accomplished using the Manage Sales and Marketing Organizations screen in the Setup and Maintenance section. To navigate to this screen, perform the following tasks.
Click the Navigator link at the top-left section of the Oracle Fusion screen.
Click the Setup and Maintenance link in the Navigator. This displays the Setup and Maintenance screen.
If the Manage Sales and Marketing Organization task is listed in the Assigned Implementation tasks, click the Go To Task button against it to access the Manage Sales and Marketing Organizations screen. You can also choose to search for the task in the All Tasks tab.
You need to create an organization with sales usage from an existing department if the concerned department needs to be reused as a sales organization.
This example describes how you can add a sales organization to a sales organization hierarchy.
As new sales organizations are created within your company, you need to add these organizations to your company's sales organization hierarchy. To do so, perform the tasks detailed below.
Once you have identified a resource, you can assign the resource to organizations within the deploying company. This example explains how you can assign resources to organizations.
You need to assign a resource to an organization. It is important to state here that a resource can belong to multiple organizations at the same time. This means that even if chosen resources already belong to organizations, you can assign them to other organizations as needed.
To assign a resource to an organization, perform the following tasks.
Search for the resource using the Search controls in the Resource Directory.
Display the concerned resource's profile by clicking on the resource's name in the search results.
Click the Organizations tab in the Resource Profile Details screen. This displays the list of organizations to which the resource belongs.
Click the Create button to display the Create Organization Membership popup screen. Use this screen to search and assign organizations to the concerned resource's profile.
Click the Organization field and select the organization you need from the drop-down list displayed. You can also enter part of the name of the organization you need and search for it. You can also search for organizations using a range of search options available in the search screen. Click the OK button to add the organization you need to the Create Organization Membership screen.
Click the Add Row button in the Create Organization Membershipscreen. This adds a row to the screen, enabling you to specify the role the resource needs to play in the organization.
Click the Role field and, from the drop-down list displayed, select the role the resource needs to play in the organization. Depending on the role settings created for the selected role, the role type is automatically indicated by a tick mark under the appropriate column.
The From Date field is automatically set to the current date. You can change this date to reflect the actual assignment date as required.
The To Date is empty by default. This means that the resource is assigned to the organization you chose infinitely. You can set the date to the actual end date by entering the required value in the mm/dd/yy format.
Click the OK button to save your changes. This assigns the resource to the organization you chose. You can add the resource to as many other organizations as needed.
You can also assign resources to organizations by searching for organizations and adding members to the concerned organization. To assign resources to organizations by searching for organizations, perform the following operations.
Click the Search field and, from the drop-down list displayed, select Organizations.
Search for the organization you need and click on the name of the required organization from the search results. This displays the Organization screen, where all the details of the selected organization are displayed.
Click the Members tab to edit the list of members assigned to the organization.
Click the Create button to assign a new resource to the organization. This displays the Add Resource Member popup screen.
Search for the resource by entering the resource's name in the Resource field. From the search results displayed, select the resource you wish to assign to the organization and click OK. This displays the Add Resource Member popup screen with the resource's name added.
Click the Add Row button to add a role to the newly-added resource.
Click the Role field and, from the drop-down list displayed, select the role the resource needs to play in the organization. Depending on the role settings created for the selected role, the role type is automatically indicated by a tick mark under the appropriate column.
The From Date field is automatically set to the current date. You can change this date to reflect the actual assignment date as required.
The To Date is empty by default. This means that the resource is assigned to the organization you chose infinitely. You can set the date to the actual end date by entering the required value in the mm/dd/yy format.
Click the OK button to save your changes. This assigns the resource to the organization you chose. You can add as many resources to the organization similarly.
Note
The date from which a resource is a member of an organization must be on or after the date on which the resource was hired.
If a resource was previously a member of the selected resource organization with an end date later than the current date, and if the resource was removed from the organization before the end date, you cannot reassign the resource to the same organization.
Yes. You can create new organizations using the Manage Sales and Marketing Organizations option in the Functional Setup Manager or the Oracle Fusion Partner Management user interface. You can also create new resource organizations from the User Management interface. You can also use the interface to manage user accounts and roles, and to create employee and partner-member users.
To delete a resource from an organization, you need to delete the concerned resource's membership from the organization.
To manage the membership of an organization, navigate to the Manage Resource Organization and select the organization concerned. Once the organization's membership details are listed, you can add, delete or edit them as required.
When you delete a resource from an organization, you effectively delete the concerned resource's membership with the organization. This also removes the resource from the organization hierarchy.
A resource organization displays the relationships between the resource organizations of the deploying company. The resource organization hierarchy is visible to all resources within the company.
No. All organizations within your deploying company are part of a large overarching global hierarchy. Therefore, new organization hierarchies cannot be created. You can, however, move existing organizations or attach new organizations to the existing hierarchy and create a new version of the hierarchy. Once you have created a new version, specify the date from which the new version needs to become active and, on the specified date, your new hierarchy version replaces the older hierarchy.
No. You can only have one resource organization hierarchy active at a time within a deploying company. If you need to create a hierarchy for an organization, you will need to specify the reporting structure within the concerned organization and then make the organization a part of the existing hierarchy.
Yes. To create a new hierarchy version, navigate to the hierarchy whose new version you wish to create and click on the Actions button. From the drop-down list displayed, select Create Hierarchy Version. make the changes to the hierarchy as required, specify the dates between which the organization hierarchy needs to be active, and click Save and Close to save your changes and exit the screen.
There is always one resource organization hierarchy for internal resource organizations and also one partner organization hierarchy for each partner company. You can have one active version and multiple inactive versions of resource organization hierarchies. Resource organizations can be included into any of the active or inactive organization hierarchies.
No. An organization can have only one manager.
Defining resource roles involves defining and configuring the roles that a resource plays as an individual or within a resource organization or resource team in the deploying company. This requires you to specify who a resource is within the enterprise and what specific role the resource performs within the context of an organization or team.
You can assign defined roles to resources directly or to resources within an organization or team context. This action simplifies the task of individually assigning complex roles to resources within the organization.
You can also set several flags while defining roles. Use these flags along with the organization hierarchy information to define the reporting hierarchy of resources. Use the Manager flag to tag a role as a supervisor role. Similarly, attach a Member tag to a role to make it a subordinate role in the hierarchy. Tag roles as Administrator or Lead to indicate the roles that the resource roles have within the hierarchy. Additionally, you can use these flags along with the organization hierarchy information to maintain manager-to-manager relationships within the organization.
Resource role types organize roles into logical groups. This simplifies role assignment and assignment tracking. For example, the Partner resource role type defines a set of partner-specific roles such as partner sales representative and partner sales manager. Use the Partner resource role type to determine the roles that are appropriate for partner members. Similarly, use the Sales resource role type and the Marketing resource role type to categorize the appropriate sales and marketing roles for internal employees or contingent worker resources.
Security role provisioning is the process of automating the provisioning and de-provisioning of security roles based on resource role assignment to resources. Once security roles are provisioned to resources, they can access the tasks and data enabled for the security role.
Resource roles indicate who a person is to the deploying company. As such, resource roles are used for filtering resources and for generating reporting hierarchies in addition to being used to define security policies. A key difference between a security role and resource role is that a resource role may be assigned to a resource without a user account, while a security role can only be provisioned to a resource who has a user account. So while in some cases the resource role may be defined at the same granularity as the security role and used to automate security role provisioning, the resource role concept remains separate from security roles.
In the Manage Resource Roles task, you can establish job mapping for a resource role. Job-to-resource-role mapping enables you to associate HCM jobs with specific resource roles. This mapping simplifies the task of assigning resource roles to new employees or contingent workers, resulting in time and costs efficiency.
For example, suppose a new employee joins the IT department as a data quality manager. If the new employee's job is already mapped to a resource role like Data Steward Manager, the resource role is automatically assigned when the employee is identified as a resource in the system. This enables you to place new employees faster in organizational and reporting hierarchies. If security roles are also associated with the resource role, then the new employee's access privileges are also granted automatically.
Resource role assignment is the task of assigning roles to active resources within the deploying company. These roles are previously set up, and have associated security privileges. Thus, when you assign a specific role to resources, they automatically receive access to specific business functions within the company.
You can assign different roles to the same resource in different organizations. Thus, the same resource can have access to different business functions depending on the security roles associated with the resource roles assigned to them.
Resources who are team members can be assigned different roles within the team. These roles do not necessarily need to reflect the roles these resources may play in resource organizations. Depending on the requirements of the tasks assigned to the team, resources may be assigned resource roles, and can accordingly access data related to the tasks in which the team is engaged.
A resource can belong to multiple teams depending on the needs of these teams and the skills that the resource offers. This does not affect the resource's membership with organizations within the deploying company.
Resources have specific roles to play in every team to which they are assigned. Each of these roles can be different. Also, these roles can be different from the roles assigned to the same resources in resource organizations. Thus, a resource can be a manager in one team, and a member in another simultaneously.
Yes. While a resource can have only one resource role within a resource organization, a resource can have multiple roles in different organizations across the deploying company.
No. One resource can only have one role within an organization. However, a resource can belong to more than one team, and can have multiple roles in each.
Setting up resource roles helps you define the various roles within your organization so that they can be assigned to resources.
Use the Resource Role Setup tasks to define specific roles that best reflect the way responsibilities are distributed within the deploying company. If your resource roles are created before you start setting up your resources, you can easily assign roles to resources, simplifying task assignment. Resource roles that are tagged as manager or member roles also determine how eventually the reporting hierarchy gets built.
Later, when you need to assign resources to organizations, resource roles can help you specify the precise roles that resources need to play within the organizations to which you assign them.
Resource roles also simplify security provisioning for resources. You can define security roles corresponding to resource roles using the role mapping interface. Once such mapping rules are setup, you can provision security roles by assigning the corresponding resource roles to resources.
A resource team is a group of resources formed to work on work objects. A resource team may comprise resource organizations, resources, or both. A resource team cannot be hierarchically structured and is not intended to implement an organization structure. You can also use resource teams as a quick reference to groups of related resources that you can quickly assign work objects to.
Note
Members of teams can either be reassigned separately, or entire teams can be assigned to other tasks as required.
A duty role is a set of privileges associated with an aspect of a resource role, and one or more duty roles roll up into a resource role. Basically, resource roles can be said to comprise a set of duties, and each duty has its own set of privileges. Thus, privileges roll up into duty roles, and duty roles roll up into resource roles.
Value sets are specific to the application in which they will be used. In the Oracle Product Information Management application, value sets are used primarily for defining attributes where the values that an attribute can have is limited to a specific set of values.
Value sets can be edited or new value sets can be created from the Manage Product Value Sets page. The Edit icon launches the Edit Value Sets page, which redraws in the same region of the local area. The Create icon launches the Create Value Sets page, which redraws in the same region of the local area.
A value set is defined by the value set code and is specific to the module of an application in which the value set is to be used, such as Item Class.
The validation type determines how the value of field is validated for the assigned value set. The following are the seeded values:
Format Only
Independent
Dependent
Subset
Table
The value data type determines the data type for the value set. The following are the seeded values:
Character
Number
Date
Date/Time
The Manage Product Child Value Sets task uses the same page as the Manage Product Value Set task.
A child value set is used to define variants for stock-keeping units or SKUs. A SKU contains the common properties for an item. For example, a shirt can be produced with colors; white, red, yellow, and blue. The variant is used to represent the colors of the shirt.
You define child value sets as follows:
Create a value set with validation type of independent, for example All Colors.
Select the new value set in the Manage Product Value Sets results table, for example All Colors.
Click Manage Values, create several values, for example Blue, Red, Green, Yellow, and Black.
Create a value set with validation type of Subset and enter the first value set you created for the independent value set, for example: Summer Colors.
Select the value set Summer Colors in the Manage Product Value Set result table.
Click Manage Values and then click the Add icon. The dialog will show a list of values based on the value set named Summer colors. Select two of them.
The value set Summer Colors is a child of All Colors.
The Root Item Class is seeded and all item classes are created as children of the Root Item Class. For Oracle Fusion Product Model customers, only the Root Item Class is available. The Manage Default Item Class task enables Product Model customers to manage item class templates, descriptive flexfields, attachment categories and lifecycle phases. The Manage Default Item Class task launches an edit page for the Root Item Class.
The functionality for the Root Item Class is defined using three tabs:
The Basic tab enables descriptive flexfields and attachment categories to be viewed and managed for the Root Item Class.
The Lifecycle Phases tab enables one or more lifecycle phases of a lifecycle to be associated with an item class.
The Templates tab is where you define and manage item templates for the item class.
In the Item Status table, select a status code to display the associated attribute groups and attributes as well as control information.
You can create or edit or delete item statuses on the Manage Item Statuses page. Inactive dates are used to specify the date after which the item status will no longer be active. Operational attribute groups and attributes corresponding to the selected item status are displayed in the Details section. Select a value for the status from choice list for the attribute. Whenever the status is applied to the item, the value of the attribute may change. If the status will have no value, select No.
Select the Usage value of None or Defaulted or Inherited in the choice list for the Usage field that corresponds to how the attribute value will change based on the item status value:
Defaulted-Sets the values of the item status attributes when the status value changes, but allows the overriding of the value during import and update of item.
Inherited-Sets the values of the item status attributes when the status value changes, but overrides cannot occur.
None-The item status attribute values will not be changed.
Any change made to an item status is not applied automatically to existing items, but will be applied during the editing of an item when the item status value is changed.
Item types are managed on the Manage Item Types page.
There are 32 seeded item types and you can edit them or create additional item types.
Item types are date-enabled and are made active or inactive by adjusting the Start Date and End Date.
To benefit from the use of item types, you must enable them by selecting the Enable checkbox.
Cross-References provide the functionality to map additional information about an item in the form of a value and cross-reference type. For example, the cross-reference can map between an item and an old part number, where the value is the value for the old part number and the type is Old Part Number. Cross-Reference Types are part of item relationships where the item relationship type is Cross-Reference. There are no values seeded for cross-reference types. You define the values using the Manage Cross Reference Types task. Cross-reference types are date-enabled and can be made active or inactive by adjusting the values of the Start Date and End Date. To benefit from using item relationship for cross-reference, you must enable cross-reference types by checking the Enable checkbox.
You can import items and item-related information using interface tables. This import data is loaded into the production tables using the Import Item task.
The Import Item task creates an Enterprise Storage Server (ESS) process that takes the data that is loaded in the interface tables and uses the import process to move the data to the production tables. The import processes will perform all of the validations necessary to ensure the data imported is correct prior to moving the data into the production tables.
Access the Enterprise Storage Server and provide a process name (job definition) such as Item Import Process.
Select Setup and Maintenance from the Navigator.
Access the All Tasks tab on the Overview page, and search for the Import Item task with the name of your ESS process definition.
Click the Go to Task icon in the search results for that Import Item task.
The parameters for the item import process are
Batch ID: Associate the interface table to an item batch definition.
Organization: Select an organization to be used for the import.
Process Only: Determines how the data is processed. The choices are:
Create
Sync
Update
Process All Organizations: Select Yes if the import contains items that will be imported to multiple organizations.
Delete Processed Rows: Select Yes to delete rows that are imported without errors
Click Submit and the Request Number will be displayed.
Select Setup and Maintenance from the Navigator, then access Monitor Item Imports to search for specific Enterprise Storage Server processes and monitor their status in the search results table.
A related item is an item relationship between two existing items. How the two items are related is defined by a subtype. Multiple subtypes for related items are seeded, and you define additional subtypes on the Manage Related Item Subtypes page.
You can use descriptive flexfields to capture additional information about items beyond what is provided by the predefined set of operational attributes in Oracle Fusion Product Model.
If you are not using Oracle Fusion Product and Catalog Management, then you cannot create user-defined attribute groups and attributes. However you can use descriptive flexfields associated at Item level to create fields to capture information about items. Like other descriptive flexfields, item descriptive flexfields have context segments and context-sensitive segments whose values are validated on entry by value sets. You can define the value sets to control what values users can enter in a descriptive flexfield segment. Examples of information that you might capture are size and volumetric weight.
Manage this flexfield type by using the Manage Item Descriptive Flexfields task, which you can access by searching for flexfield tasks on the Setup and Maintenance Overview page.
Use descriptive flexfields associated at Item Revision level to capture item revision information whose values may differ between revisions of the same item.
Manage this flexfield type by using the Manage Item Revision Descriptive Flexfields task, which you can access by searching for flexfield tasks on the Setup and Maintenance Overview page.
When defining descriptive flexfields associated with item relationships, you must use certain prefixes when naming the context segments, in order for the segments to be displayed for the respective relationships.
The prefixes required for naming the context segments
are listed in the following table, with their corresponding item relationship
types. For example, if you define an item relationship descriptive
flexfield with a context segment named RELATED_RELATIONSHIP_ATTRIBUTES, then the value segments of this context will be displayed for Related
Item Relationships when users conduct transactions in that context.
For another example, when users navigate to a UI of a particular object,
such as a Competitor Item, they see the contexts whose internal name
has the prefix COMP.
|
Relationship Type |
Prefix for Context Segment |
|---|---|
|
Competitor Item Relationship |
COMP |
|
Customer Item Relationship |
CUST |
|
Item Cross-reference Relationship |
XREF |
|
GTIN Relationship |
GTIN |
|
Manufacturer Part Number Relationship |
MFG |
|
Related Item Relationship |
RELATED |
|
Source System Item Relationship |
SYS |
Manage this flexfield type by using the Manage Item Relationship Descriptive Flexfields task, which you can access by searching for flexfield tasks on the Setup and Maintenance Overview page.
When defining descriptive flexfields associated with trading partner items, you must use certain prefixes when naming the context segments, in order for the segments to be displayed for the respective trading partner type.
The prefixes required for naming the context segments
are listed in the following table, with their corresponding trading
partner types. For example, if you define a trading partner item descriptive
flexfield with a context segment named COMP_TPI_ATTRIBUTES, then the value segments of this context will be displayed for Competitor
Item when users conduct transactions in that context..
|
Trading Partner Type |
Prefix for Context Segment |
|---|---|
|
Competitor Item |
COMP |
|
Customer Item |
CUST |
|
Manufacturer Item |
MFG |
Manage this flexfield type by using the Manage Trading Partner Item Descriptive Flexfields task, which you can access by searching for flexfield tasks on the Setup and Maintenance Overview page.
Lifecycle phase types are seeded and describe the type of lifecycle phase. They are Design, Obsolete, Preproduction or Prototype, and Production.
Lifecycle phases must be created by the user by selecting one of the seeded lifecycle phase types.
Define units of measure, unit of measure classes, and base units of measure for tracking, moving, storing, and counting items.
The Quantity unit of measure class contains the units of measure Box of 8, Box of 4, and Each. The unit of measure Each is assigned as the base unit of measure.
Unit of measure classes represent groups of units of measure with similar characteristics such as area, weight, or volume.
Units of measure are used by a variety of functions and transactions to express the quantity of items. Each unit of measure you define must belong to a unit of measure class.
Each unit of measure class has a base unit of measure. The base unit of measure is used to perform conversions between units of measure in the class. For this reason, the base unit of measure should be representative of the other units of measure in the class, and should generally be one of the smaller units. For example, you could use CU (cubic feet) as the base unit of measure for a unit of measure class called Volume.
Each unit of measure class must have a base unit of measure.
This table lists examples of unit of measure classes, the units of measure in each unit of measure class, and the unit of measure assigned as the base unit of measure for each unit of measure class. Note that each base unit of measure is the smallest unit of measure in its unit of measure class.
|
Unit of Measure Class |
Units of Measure |
Base Unit of Measure |
|---|---|---|
|
Quantity |
dozen box each |
each |
|
Weight |
pound kilogram gram |
gram |
|
Time |
hour minute second |
second |
|
Volume |
cubic feet cubic centimeters cubic inches |
cubic inches |
A unit of measure standard conversion specifies the conversion factor by which the unit of measure is equivalent to the base unit of measure.
This table lists examples of unit of measure classes, one unit of measure included in each class, the base unit of measure for the unit of measure class, and the conversion factor defined for the unit of measure.
|
Unit of Measure Class |
Unit of Measure |
Base Unit of Measure |
Conversion Factor |
|---|---|---|---|
|
Quantity |
dozen |
each |
12 (1 dozen = 12 each) |
|
Weight |
pound |
gram |
454 (1 pound = 454 grams) |
|
Time |
minute |
second |
60 (1 minute = 60 seconds) |
A unit of measure standard conversion defines the conversion factor by which the unit of measure is equivalent to the base unit of measure that you defined for the unit of measure class. Defining a unit of measure standard conversion allows you to perform transactions in units other than the primary unit of measure of the item being transacted. The standard unit of measure conversion is used for an item if an item-specific unit of measure conversion has not been defined.
A UOM interclass conversion defines the conversion between the source base unit of measure ("From Base UOM") in one unit of measure class ("From Class") and the destination base unit of measure ("To Base UOM") in a different unit of measure class ("To Class").
For example, the item is gasoline. The From Base UOM (of the From Class called "volume") is liters. The To Base UOM (of the To Class called "quantity") is Barrels. The conversion is 158.76 liters (volume) to 1 barrel of oil (quantity).
A UOM intraclass conversion specifies the conversion between a unit of measure (the "From UOM") and the base unit of measure of the same class.
For example, the item is soda pop. The unit of measure class is Quantity. The From UOM is Case (CS). The base unit of measure is Each (EA). The conversion is 24, to specify that 1 CS = 24 EA.
Attributes that exist for each instance of an item and the values for the attributes can be different.
For example:
The number of megabytes (MB) or gigabytes (GB) of e-mail storage on a digital subscriber line (DSL) account.
The monogram text on a shirt pocket.
The color of a music player.
These attributes are defined at the item class and their attribute value is captured at the time of a transaction by downstream applications. The metadata values of these attributes are maintained at the item class. Order orchestration and order capture systems are two examples of downstream use. All transactional attributes must be associated with a value set.
The following metadata values can be defined for an attribute.
Required: Indicates whether the attribute value is required at the transaction.
Default Value: Indicates the default value of the attribute.
Value Set: Indicates the value set associated with the attribute.
Read Only: Indicates whether the attribute value is read only.
Hidden: Indicates whether the attribute is not shown.
Active: Indicates whether the attribute is active or inactive.
Transactional attributes are inherited across the item class hierarchy. The metadata is data-effective. Changes in the metadata will be reflected immediately at the item level. For example:
Any of the metadata of a transactional item attribute belonging to a specific domain, if modified in the child item class would break the inheritance. Any changes done at the parent item class for this transactional item attribute would not get inherited. Multiple records with same date range can exist if they belong to different domains. For example, the transactional item attribute Memory is associated with aDomain and order capture. Each of the domains may use a different set of metadata for its own purpose. Hence, for the same date range, two different records can exist. Only Start Dates for a transactional item attribute would be entered by a user. End date would be calculated automatically based on the next Date Effective record.
Users can modify (either Start Date and metadata) of a future effective record. Records with Starting date as Past cannot be modify or edited.
Only start dates can be set to permit updating by a user, and the end date of a record will automatically be pulled from the next record.
Any changes performed in the parent item class would be inherited by the child item class. If the corresponding record is modified in the child, then these changes will not be inherited.
Item pages provide a mechanism with which to customize the user interface.
Pages and attribute groups enable you to structure your data.
Benefits include:
You can combine and sequence attribute groups into pages.
There is no limit on the number of attribute groups associated with a page
Pages can be created at item class and are inherited down the item class hierarchy.
Attribute groups can be added to pages sequentially and based on this sequence, these attribute groups are shown in items
Attributes groups can be added for an inherited page at the child item class.
Functional Item pages are another type of special pages which are used to associate pages already created for use in the application. Application scope indicates the application which uses these pages and the usage indicates the specific use of the configured pages.
You can associate attributes for the purpose of standardization and matching, to be performed when items are created. You restrict the attributes to be processed for standardization or matching or both. Selecting Standardization allows the data quality engine to return the standardized values for these attributes. Matching allows the data quality engine to return any existing items which matches the value of these attributes and are potential duplicates.
Sequential lifecycles phases enable you to track and control the lifecycle phases of items. Each phase represents a set of tasks and deliverables that are required before promoting the item to the next phase. You can associate lifecycle phases to an item class which are created elsewhere. Lifecycle phases are inherited down the item class hierarchy and new lifecycle phases can be added to child item classes. For example, the lifecycle phases for a computer component item class might be: Concept, Prototype, Production, and Retirement.
Template is a defined set of attribute values used during item creation. When you apply a template to an item, you overlay or default-in the set of attribute values to the item definition. For example, every time users in a particular organization create new items, the attributes, as defined and approved by the organization appear in the appropriate fields. No user guesswork is required, and time is saved during the creation of items with a similar form, fit and function. Templates are created for each item class. Templates are specific to organization. Templates are inherited down the item class hierarchy. You can define both operational attributes and user defined attributes for each template.
Search formats provide a convenient way to save frequently used search criteria. Search formats created at item class will be available to all users. Search formats are always created in the context of item class. Display formats enable you to predefine search display views. You can use these views to look at different sets of item attributes that are returned by the search. Display formats created at item class will be available to all users. Display formats are always created in the context of item class.
An import format identifies the base and user-defined attributes in an item class that are imported into the application using a spreadsheet. Consequently, when you import item business entities from a spreadsheet, the items are all imported into the particular item class defined in the import format. These imported item business entities inherit all the attribute groups defined for the specific item class. You cannot edit the layout of an import format once it is created.
When you are ready to create or edit an item class, you must decide whether to allow items to be created under the item class.
To create an item class, perform the following steps:
Create a list of all items.
Classify or categorize these items (item classes).
Define any parent-child relationships (item class hierarchy).
Gather the unique types of specifications required for each type of classification at a high level (user-defined attribute groups).
Gather the unique specifications required within the group (user-defined attributes).
If there are specified values that must be used, define them (value sets and values).
Item classes can be used for classification purposes and in some case, item creation may not be allowed. By optionally setting the Item Creation Allowed attribute to No, item creation under an item class can be prevented. However, a child item class of such an item class may be allowed for item creation. For example:
This prevents items from being created in Computers and Desktops, but allows items to be created for Green Desktops and Gaming Desktops. Optionally, specify a date on which the item class will become inactive. You cannot specify an inactive date that is later than the inactive date of an item class parent, nor can you specify an inactive date that has already passed. Also, all children of a parent item class with an inactive date should be made inactive at the same time or earlier.
Attachment categories enable you to categorize and classify attachments to an item. To classify item attachments, associate attachment categories with item catalog categories. Associated attachment categories are inherited down through the item class hierarchy.
Version control allows new versions to be created for all items in an item class. An integrated workflow definition permits the creation of custom new item request definitions. This workflow definition establishes a multistep process for routing the definition and approval of items. When a new item is created, various people in the organization use the workflow to define aspects of the item, like base operational attributes, user-defined attributes, structures, attachments, categories associated, and organization assignments.
Note
Versioning an item and creating a new item request are independent of each other. Versions can be added to a new item request and routed for approval if there is a business need.
When setting up definition steps for a new item request at the item class, you can identify various item details as mandatory, at each step. Definition of entire entity can be made mandatory or just certain attributes. This ensures that the item information required for a downstream step is defined and available for use.
Required attributes can be inherited from parent and assignee access is validated.
You can control item creation, viewing and update access by assigning a role on the item class to a principal or group of users. Security allows a person or a group to have privileges to an item of item class in each organization. This is inherited and hence a person who has a privilege in a parent item class will automatically have the same privilege in the child item classes.
The item class hierarchy provides a logical classification and grouping of similar products, and also acts as a template for product definition by enabling the association and inheritance of data elements and policies that are shared by products.
To create an item class, select a parent item class on the Item Class Search Results page and select Create. Provide the required information, and optionally include additional details, such as attribute groups, pages, templates, and search and display formats.
You can set various options to customize the runtime instance of your product catalog.
The Functions and Miscellaneous tabs have several built-in features and options for you to choose from.
Select certain functions and specify how they should run depending on your processes.
|
Name |
Description |
Value |
Description |
|---|---|---|---|
|
Availability Engine |
Determines the availability of a product in stock. |
Do not run |
Do not call the availability service. |
|
|
Quick availability |
Show whether the product is available or out of stock |
|
|
Detail availability |
Show the number of quantity available. Example 25 in stock. |
|
Eligibility Engine |
Determines the eligibility of a product or product group for a customer or a geographical area. |
Do not run |
Do not call the eligibility service. |
|
|
Run and hide |
Call the eligibility service but hide the ineligible products, product groups and promotions. |
|
|
Run and sShow |
Call the eligibility service and show the ineligible products, product groups and promotions with the appropriate message. |
|
Pricing Engine |
Determines the price for a product. |
Do not run |
Do not call the pricing service. |
|
|
Complex |
Show the List Price, Your Price, Discount, and so on. |
|
|
Simple |
Show the List Price only. |
|
Territory Engine |
Determines the products in a territory. |
Do not run |
Do not check for territory information. |
|
|
Enforce territory |
Always show the products and product groups that are part of the territory. |
|
|
Display user choices |
Provides the user with the choice to toggle between all product or product groups and the ones that belongs to the territory only. |
Set preferences such as button label, sort by text, number of products per page, and so on.
|
Name |
Description |
|---|---|
|
Add item button label |
The selected value is shown next to the product in the runtime interface. |
|
Add category button label |
The selected value is shown next to the catalog or category in the runtime interface. |
|
Add category enabled flag |
Allows buttons to be shown next to the catalog or categories. |
|
Records per page |
Number of records to be displayed per page. |
|
Sort by format text |
Sort format of the entire label that you want displayed in the runtime interface. The default pattern is {ATTR}: {SORT_ORDER}. Example: Name: A to Z. |
|
Sort by product label prefix |
Sort format of the prefix label that you want displayed. Example: If the default is Name: A to Z, you can select an alternate label for Name. It could be Item: A to Z. |
|
Sort by sequence product ascending label |
Sort format of the ascending suffix label that you want displayed. Example: If the default is Name: A to Z, you can select an alternate for A to Z. It could be Name: Ascending. |
|
Sort by sequence product descending label |
Sort format of the descending suffix label that you want displayed. Example: If the default is Name: Z to A, you can select an alternate for Z to A. It could be Name: Descending. |
|
Sort by sequence ascending first flag |
Select Yes to display ascending labels first in the Sort By LOV. |
|
Show immediate child products only |
Shows immediate products of a given category disregarding the standard behavior of showing all products (including child categories) if narrow by is defined on the category. |
|
Image server |
Identifies the source of images for products and product groups. |
|
Image server alternate path |
Identifies an alternate image source location (URL) |
|
Enable transactional attribute |
Allows transactional attributes to show up in product detail page. Transactional attributes are attributes that can be selected such as color and size of shirt. |
|
Hidden category optional attribute list |
You can specify the attributes you would like to hide from the category UI here. This could be a comma separated list of attributes that needs to be hidden from the category list page. |
|
Hidden product optional attribute list |
You can specify the attributes you would like to hide from the product UI here. This could be a comma separated list of attributes that needs to be hidden from the product pages. |
|
Hide quantity |
Set this to Yes, to hide the quantity field shown in the product page. |
|
Hide unit of measure |
Set this to Yes, to hide the unit of measure field shown in the product detail page. |
Megan and the marketing team notice that when they browse the ComfyGooseCatalog, availability information is shown against each product. Since they have no visibility around the Loveseats product, the marketing team suggests to hide the availability information for the Loveseats category alone. Megan remembers from the training that Fusion Sales Catalog provides the ability to override the default behavior.
Megan recalls that she has to make this change from the Display Options for the Loveseats catalog.
Megan chooses the Loveseats catalog.
Megan creates a record and names it Hide Availability.
Megan selects the Base usage.
Megan validates the effect of this change at runtime.
Use the display options to control various aspects of the published product group.
You can make small but significant changes to a product group from these tabs. The changes here override default settings.
Applies To
Select the usage that this product group is applicable to. Usage defines the department or function within your organization for which this catalog is created.
Apart from usage, you can also select the mode within the usage. Mode defines the department or function within your organization that uses the same catalog but with minor changes from other consumers.
Narrow By
Select Narrow By attributes and their appearance. These attributes appear as filters to narrow searches at runtime.
Template
Select templates for category, product list, and so on.
Functions
Define the changes to specific settings in certain functions such as pricing and eligibility.
Miscellaneous
Change basic settings for the product group such as button label, number of items per page, invocation of the configurator, and so on.
This example demonstrates how to create a sales catalog. In this example, ComfyGoose Inc is a state of the art outfit in the business of selling chairs and sofas. As part of their expansion plans, they recently bought Oracle Fusion CRM and are uptaking the best business practices and all the functionality it brings.
Megan works in the product marketing department and is excited about the sales catalog and the ease with which she can create products and catalogs. She gathers information about the categories to be created and the products that need to be associated to each category. She is familiar with the layouts and the navigation paradigm in the application.
As a first step, Megan decides to create a sales catalog.
Megan enters the following details for her catalog.
|
Field |
Sample Data |
|---|---|
|
Name |
ComfyGooseCatalog |
|
Display |
Comfy Goose Catalog |
|
Description |
Contains ergonomic chairs for your home or office needs, chairs for businesses such as call centers and offices; at attractive prices. |
|
Root Catalog |
Select to make this a root catalog.Only root catalogs can be added to a usage in Product Group Usage Administration. |
Megan creates the following subgroups for the ComfyGoose Catalog product group.
|
Field |
Sample Data |
|---|---|
|
Subgroup Name |
|
Megan creates further categories within some of the subgroups.
|
Parent Subgroup |
Sample Data |
|---|---|
|
Chairs |
|
|
Sofas |
Sofas and Loveseats |
|
Sofas and Loveseats |
|
A published catalog is available for use by different departments which is done via Usage Administration
Megan selects the Base usage and adds ComfyGooseCatalog to this usage.
This example demonstrates how you can reuse a sales catalog. In the scenario used in this example, ComfyGoose Inc is a state of the art outfit in the business of selling chairs and sofas. As part of their expansion plans, they recently bought Oracle Fusion CRM and are uptaking the best business practices and all the functionality it brings. Megan works in the product marketing department.
Megan gets a call from another division of the company, after a few months of deploying the ComfyGooseCatalog. They have heard of the new catalog that she helped build for the marketing team and enquire if they can have a similar subset for their division. They want to leverage as much as possible having a consistent look-and-feel.
An application developer must create an application and should be able to consume the sales catalog task flows to achieve this example. This task is similar to what the Sales module has done to consume the task flows provided by the sales catalog team.
Megan gathers the necessary information and identifies that this division primarily needs what is in the Chair category of the ComfyGooseCatalog. She is very excited because she knows that she can simply reuse the Chairs category. In the past, she would have had to create another catalog repeating the same data, a maintenance overhead.
Megan creates the Call Center Division usage
You can choose only product groups that are catalogs by themselves here. In other words, the catalog must be a root catalog.
Megan realizes that the Chairs catalog that she wants to reuse is a subgroup of the ComfyGooseCatalog. To make it a root catalog, she follows these steps:
Navigate to the Product Group Administration page
Select the product group Chairs from the Product Group pane
From the Details tab, select Root Catalog
Save and publish the catalog.
The Chairs catalog is now available for the Call Center Division.
This example demonstrates how to enable filtering by attributes. In the scenario used in this example, ComfyGoose Inc is a state of the art outfit in the business of selling chairs and sofas. As part of their expansion plans, they recently bought Oracel Fusion CRM and are uptaking the best business practices and all the functionality it brings. Megan works in the product marketing department. She has created the ComfyGooseCatalog and tried changing some usage attributes.
Megan now reviews the ComfyGooseCatalog with the team and decides that it will be nice to provide the user with few narrow by filters. After reviewing the definition of products associated to the Chairs category and its subcategories, it is decided that attributes Color and Material can be used for filtering.
The attributes must already be registered in the Product Group Attribute Administration page. These attributes must be present and associated in the Item Master.
Megan selects the Chairs category.
Note
The attribute is already registered in the Product Group Attribute Administration page.
Megan selects the Color and Material attributes.
Megan creates Blue, Pink and Black as the values for the chair color. She also creates values for the chair material.
Megan validated the changes in the graphical catalog. She can see the attributes that she created and their values in the Advanced Search, Narrow By and Sort options of the catalog.
This example demonstrates how to use a new template in a catalog. Megan informs the marketing team that the IT department has created a new template that gives a cool web 2.0 feeling and asks their permission to try it out. She informs them that it gives a carousel effect which is quite common while browsing songs, DVDs, and so on. The marketing team agrees to give it a try.
Using Fusion JDeveloper, application developers have to create a task flow using the Fusion ADF component and all necessary VOs to support the task flow. The task flow must be registered in the template administration.
Megan decides to use the template ComfyGoose Carousel template in the ComfyGoose Catalog's browsing categories.
Megan creates a record and names it Carousel.
Megan selects the Base usage.
Megan selects the Category List Template as the type and the ComfyGoose Carousel template as the template.
Megan verifies the change in the catalog at runtime. The marketing team loves this cool effect and agrees to adopt it for the final catalog roll out.
This example demonstrates how you can modify attributes for an application's usage. In this scenario, the Call Center division only deals with call centers across the world, they have not seen if any product they have sold is not applicable to call center companies. Therefore, they decide to switch off the eligibility and availability messages that show up in their side of the catalog.
Megan knows that this is a fairly simple task because she can do these settings from the Product Group Usage Administration page.
Megan selects the Call Center usage.
|
Name |
Value |
|---|---|
|
Availability Engine |
Do not run |
|
Eligibility Engine |
Do not run |
Megan accesses the catalog and finds that the availability and eligibility messages do not appear anymore for the Call Center division's catalog.
An eligibility rule can be a physical eligibility rule or a marketing eligibility rule
Some points to remember when you create an eligibility rule:
An eligibility rule can determine one of the two kinds of eligibility for a product group, physical or marketing. They cannot be combined.
A rule can be of two types: Available and Not Available. If contradictory rules are defined for the same product group, the Not Available rule will prevail.
All children of a product group inherit rules from the parent product group.
Eligibility rules set at the product level have precedence over the rules set at the product group level.
When you create a physical eligibility rule, select attributes from these: Country, State or Province, City and Postal Code.
When you create a marketing eligibility rule, select a value for Customer Type.
You can add custom labels for your catalog by specifying them in the Miscellaneous tab of Display Options. For example, you can change the default Add to Cart label and can select a different label such as Add to Shopping Cart. You can add an additional value for the button label from the Manage Product Group Lookups page from the Setup and Maintenance Overview page. You can enter a new value using the lookup Add Item Label Values. Once done, you can navigate to the product group administration to either override the button label for the entire catalog via the usage functions or to a specific product group from the display options tab.
Apart from customizing button labels, you can also set the number of items to display per page from the Miscellaneous tab.
A rollup catalog does not have the same product appearing multiple times within its hierarchy. The primary purpose of a rollup catalog is to create a hierarchy more tailored to forecasting purposes where a particular product appears only once in the entire hierarchy.
A sales catalog can have the same product appearing multiple times within its hierarchy. For example, the product Toys can be part of the Children category as well as the Electronics category within the same catalog.
Note
The Allow Duplicate flag distinguishes between a rollup catalog and a sales catalog. By default, the flag is selected making it a sales catalog. The Allow Duplicate flag is in the Details tab of the Product Group Administration page.
Products in your catalog are active for a specified period. Once the period expires, the product becomes inactive and does not appear as part of the published catalog. Activate the products from the Products tab of the Product Group Administration page.
Related groups shows the relationship between two different product groups. For example, a group that contains extended warranty products is related to a group that contains laptops. There are various relations types supported such as revenue, service and so on. This relationship is used in the other applications.
Eligibility is the condition of being qualified or being entitled for a purchase or enrollment.
There are two types of eligibility.
Physical eligibility: Determines whether a service is available in a given area.
Marketing eligibility: Determines whether a company is willing to sell a product, service, or promotion to a customer.
Some examples of eligibility are:
Video Conferencing is available in California.
Liquor is not available to minors.
ESPN pay-per-view Requires HD Package
In the Filter Attributes tab of the Product Group page, change the value for the Display of the attribute. The attribute can have an internal name but the name displayed at runtime can be more meaningful and customer friendly.
For example, if the attribute name is Laptop Color, you can change the display to Available Colors. This will display in the narrow by or advanced search options at runtime.
To modify a product group, you must first lock it. Click Lock in the Product Group page. If the product group is locked by another user, the Lock button is not visible and the Locked flag is enabled in the Details tab.
There may be several promotions running at any given time. You can associate active promotions to a product group from the Promotions tab. Coupons are a part of promotions and are added to the product group along with the promotion. You can also view the promotion's effective period.
A product group can have two versions, Administration and Published. The Published version is visible to the end user in the graphical sales catalog. The administrator must make any changes to the product group in the administration version.
After publishing the administration version, the changes are made available to the published version and to the consuming applications
Use product group mapping in the following situations:
If a product group is reused, find it in the target hierarchy.
Identify the right product group in the target hierarchy when the source product group is not recognized.
Do a reverse mapping by passing the target product group to get the source product group.
You can set exceptions for a usage from the Modes tab of the Product Group Usage Administration page. Exceptions can be made when you need minor modifications for different departments in your organizations, for the same usage. The following modes are available: Lead Management, Campaign Management, Opportunity Management, Territory Management, Opportunity Landscape and Sales Prediction.
You can get this information from the Product Groups Shared With region in the Product Groups pane. By default, all product groups are shared.
The Define File-Based Data Import group of tasks relies on integration with different Oracle Fusion Applications and architecture components, such as interface tables and application base tables. This topic provides an overview of these components to help you understand the import process and the different import activity statuses.
The following figure provides an overview of the major application components used when you import data from a file. These components include
Import object
Import mapping
Import activity
File repository
Oracle Fusion CRM Application Composer
Interface tables
Application tables
The import objects you select when you create an import activity are provided by Oracle. They are managed using the Manage File Import Objects task.
When you create an import activity, you must specify a mapping of the fields in your file to the attributes of the import object You can create the mapping either while creating an import activity or separately using the Manage File Import Mappings task. The mapping is stored and managed as a separate object.
The text or XML data file you upload for import is stored in a file repository so that it is available for import processing when you schedule an import activity. Any attachments you upload are stored in the same repository.
When you create additional attributes for import using Oracle Fusion CRM Application Composer, these extensions are stored in a separate repository and are available when you create your mapping.
The import activity populates the application interface tables with your data. This is an intermediate holding area for your data that permits you to correct any import errors. Oracle Fusion CRM application data is not changed at this point.
The import activity loads your data into Oracle Fusion CRM application tables to complete the import.
The tasks in the Define File-Based Data Import task group, available from the Setup and Maintenance work area, enable you to import data from text or XML files. This topic explains the role each task plays in the import process.
The following figure provides an overview of the File-Based Data Import group of tasks and their relationships. Each task is explained in the sections that follow.
Use this task to import your data by creating import activities and monitoring their progress. Creating an import activity involves completing the following steps:
Set up the import options.
You select the object you are importing, specify the file format and different import options, and upload the file with your data. The options that are available depend on the object you are importing. Some import objects, for example, permit you to upload a ZIP or Java archive (JAR) file of attachments that will be attached to the records in the application after the data file import is complete.
Map the fields.
For this task, you create a mapping of the data in your file and the attributes in the application. You can also reuse a mapping you have created in past import activities or use the Manage File Import Mappings task. Any mapping you create in an activity is automatically saved and can be reused in subsequent imports and managed using the Manage File Import Mappings task.
Schedule the import.
You can schedule to run the import at a time you specify or run it immediately.
Review and activate the import activity.
You activate the import activity by clicking the Activate button.
This task permits you to do the following:
Manage existing mappings between the data in your import file and the application attributes. For example, you can lock a mapping so that it cannot be modified or edit the mapping to skip attributes during import.
Create new mappings without a data file.
Creating a mapping using the Manage File Import Mappings task is equivalent to creating it in the import activity, but you must enter any import file column names manually. When you create a mapping as part of the import activity, you upload the file, and the column headings in your file are populated automatically.
This task lets you view all the import objects that have been created for you. All of the objects you can import are already created for you, so you do not have to create more import objects. Creating new objects is reserved for programmers.
Using the Define File-Based Data Import group of tasks available from the Setup and Maintenance work area, you can import application data from text or XML files. Your import can be used to create or update records. The data you can import ranges from geography reference data, used to validate addresses in your application, to CRM transaction or legacy data, including customers, accounts, opportunities, and leads. This topic provides an overview of what you must understand to plan your import and prepare your import files. You must read the help topics for each specific import object to learn how to import it.
This topic covers:
What objects you can import
Tasks involved in import
Application business logic associated to the object you are importing
How data is split into objects and what IDs you must include in your file
What attributes are available for you to import and their validation
Using file import, you can import a wide range of data listed in the following table. Which of these objects are available to you for selection when you import depends on the applications you have licensed and your security permissions.
Note
To obtain specific information on how to import each of these objects, search help on the term import followed by the object name.
|
Import Object |
Description |
|---|---|
|
Advertising Marketing Activity |
Specific instances of an advertising activity for a marketing campaign. |
|
Agreement |
Legacy service agreements for use in opportunities and the Oracle Fusion Sales Prediction Engine. |
|
Asset |
Legacy customer assets for use in opportunities and the Oracle Fusion Sales Prediction Engine. |
|
Campaign |
Marketing campaigns. |
|
Campaign Members |
The contacts identified to receive the marketing message for an instance of a marketing campaign activity. |
|
Click-to-Dial Agents |
Click-to-Dial agents, including telemarketers, salespersons, and customer service representatives, who use the Click-to-Dial feature. |
|
Click-to-Dial Agents Connector Parameters |
Agent connection parameters to access Click-to-Dial functionality. |
|
Consumer |
Individuals who are customers or prospects. |
|
Contact |
Individuals who are contacts for an existing customer or consumer, or contacts that do not yet have an established association with a customer or a consumer. |
|
Contract |
Contracts header information for Oracle Fusion Enterprise Contracts. |
|
Country Structure |
Geographical structures for a country. |
|
Customer |
Organizations who are sales accounts or prospects. |
|
Customer Hierarchy |
Hierarchical structures for customers, such as branches, subsidiaries, and paying relationships. |
|
Customer Hierarchy Member |
Identifies the members of the hierarchical structures for customers. |
|
Employee Resource |
Use this object to import new users into your CRM organization. You must create users as resources to make it possible for them to participate in CRM business processes. |
|
Event Marketing Activity |
Specific instances of a marketing event for a marketing campaign. |
|
Geography |
The geographical data for a country. |
|
Group Customer |
A group of organizations or persons, such as a household or co-op, with whom you have a selling relationship or a prospective selling relationship. |
|
Incentive Compensation Transactions |
Sales compensation data. |
|
Interaction |
Records of contacts or communications between internal and external contacts. |
|
Interaction Marketing Activity |
Specific instances of an outbound marketing message for a marketing campaign. |
|
Lead |
The interest or the potential interest of prospects or existing customers in a product or service being sold. |
|
Legal Entity |
Legal entities that have rights and responsibilities under commercial law through the registration with the country's appropriate authority. A legal entity can represent your internal legal structure or dependent authorities such as tax authorities. |
|
Marketing Budget |
Business objects that are used to manage funds set aside to fund partner incentives. |
|
Note |
Notes associated with objects, such as leads, customers, and opportunities. |
|
Opportunity |
Pending sales stored in the application. Opportunities are based on customer interest in a product or service, and can be forecasted. |
|
Partner |
Sales partners: independent companies that provide sales and services on behalf of the vendor. In Oracle Fusion Partner Relationship Management, a partner must also be enrolled in a partner program and must be active. |
|
Partner Contact |
Contacts for a sales partner. |
|
Product Group |
Product group hierarchies that represent the sales catalog for marketing and sales. |
|
Program Enrollments |
The enrollment of partners in partner programs, selling programs that provide benefits and incentives for partners. |
|
Promotion |
Promotions and coupons which are used to track the effectiveness of marketing campaigns. |
|
Resource Team |
Temporary group of resources formed to complete a business task. A resource team can contain both individual resources and resource organizations. A resource team cannot be hierarchically structured and is not intended to implement an organization. |
|
Response |
Responses to a marketing campaign. |
|
Sales Account Resource |
Employee or partner resources assigned to a customer. |
|
Task |
Task that can be assigned to a resource for business objects that support tasks. |
Importing data involves multiple tasks including the mapping of your data to Oracle Fusion CRM and preparation of the data files to make them ready for import.
The following figure lists the tasks you must perform to import data into Oracle Fusion CRM:
You must:
Perform a data comparison.
Compare the data you are importing with the attributes and valid values expected by Oracle Fusion CRM.
Customize Oracle Fusion CRM if required.
If you want to import attributes that do not have an equivalent in Oracle Fusion CRM, then you may be able to add additional fields by using Oracle Fusion CRM Application Composer. For some validated fields, you can change the range of values available for import by editing the lookup types where those values are stored.
Prepare the source data.
This includes cleaning the data, removing duplicates, and splitting your data into files that correspond to the available import objects. You must ensure that the data meets the specifications required by the attributes in Oracle Fusion CRM, and that the files include the appropriate unique IDs required for import of the object.
Import the data.
This involves creating import activities by using the Manage File Import Activities task from the Setup and Maintenance work area and creating maps between the columns in your files and the attributes in the application.
Validate the imported data
After the data is imported, you must validate the import by viewing the data in the application.
You must understand how the data you want to import is used in Oracle Fusion CRM by reviewing the user interfaces, data sheets, and application documentation. If you are importing geography information, for example, you must understand how that geography information is used to validate addresses and what role it plays in sales territories. If you are importing customer data, then you must understand that a sales account in Oracle Fusion applications is a customer with a sell-to address. A customer without a sell-to address is considered a prospect.
Tip
Some of the key business logic pertinent to import is described in the help topics that you can review by searching help or implementation guides on the term import followed by the object name.
Applications help is available as a selection in the Help menu on any application page.
Before you import, you must also understand how the information you import is represented in Oracle Fusion CRM application objects. Some objects have a simple structure, but others include many child objects, which can be shared with other objects. You must review documentation for each object to understand how to import it.
Importing geography information that forms the basis of address validation, for example, is relatively simple because the relationships between the geographical data is determined within the data itself and the number of attributes that determine an address is small.
Importing customer data is much more complex, requiring you to understand how customer information is broken down into different objects and how those objects must reference each other in your file.
Some legacy applications store information about customers and competitors as separate entities. If a competitor becomes a customer, you have to copy the information about the organization and create a customer record. In Oracle Fusion, you indicate a competitor is now a customer. Similarly, contact information is often part of the customer information so you must reenter the information about that person each time he changes employers. In Oracle Fusion, every individual and organization is a party in the model. If a contact moves to work for a different customer, you simply indicate that the contact works for someone else. You get to keep all the information you have about that contact. This means that customer data is split into many objects that all have to reference each other.
For example, customer contacts with phone numbers are made up of a hierarchy of three objects: the customer, the contact, and the phone number. Each object must have a unique ID and has to refer to the objects above it in the hierarchy when you import.
The following figure provides an illustration with a simple example.
Oracle is the customer at the top of the hierarchy with its unique organization ID.
The Oracle contact, John Tanaka, has its own unique ID and must also reference the organization ID for Oracle.
The contact's phone number, +1310-555-1212, must have its own ID and reference both the contact and the customer.
Splitting data into multiple objects impacts the content of the import file:
Your file must include many columns of IDs
If your legacy data does not already contain the required IDs, you can create them manually in Microsoft Excel.
Each row of your file must include the unique ID of the object you are importing and the IDs of all the parent objects.
You must import data in a specific order to make sure that a parent object exists before you import the child object or you must include the parent object information in the same file.
For example, if you want to import customer contacts, then you must ensure that all the customer records already exist or that you include the customer data in the same file.
Having multiple reusable objects also affects the way you create the mapping between your file and the application attributes:
When you create an import activity and map the attributes in your file to the attributes in the application, you must select the child objects you are importing before selecting the attributes.
You will need to review separate documentation for each object to find out which attributes are available for import and what values are accepted.
You must also understand what attributes you can import for each object, which attributes are required and must be present in your file, and what attributes values are permitted.
The list of attributes, their descriptions, and information about valid values are provided in application help topics by import object and in documentation available in the Oracle Enterprise Repository.
Note
The valid values that must be present in your import file are not necessarily the same as those you see in the application. For example, values stored in lookup types, require you to include the lookup code for each value rather than the meaning displayed in the user interface.
To obtain the list of valid import values for validated fields, you must consult the lookup types where those values are set. If the lookup type is extensible, then you can edit it to match the values you are importing.
Some import objects permit you to add additional attributes using Oracle Fusion CRM Application Composer. For these objects, you first create the additional attributes in the composer and then create your mapping.
Using the Define File-Based Data Import group of tasks available from the Setup and Maintenance work area, you can import a wide range of application data from text or XML files. Your import can create or update application records. Use the steps outlined in this topic as a general guide only. Import options and other details differ by the type of data you are importing. Before you import, you must also understand how the data in your file will map to the attributes in the application and what values are expected as described in the related topics.
To help you get started, you can use the example templates provided in Document ID 1503223.1 on My Oracle Support. The templates include columns for the most common application attributes and reference numbers. To simplify mapping of source data to the target table columns, each template column is labeled with the combination of the target object and attribute you must select.
To import data from a file:
In the Navigator menu, click the Setup and Maintenance link located under the Tools heading.
The Setup and Maintenance work area appears.
From the All Tasks tab in the Overview region, search for the Manage File Import Activities task.
Click the Go to Task button for the task.
The Manage Import Activities page appears.
Tip
You can also navigate to the Manage Import Activities page by selecting the import task in the work areas for objects that support importing data.
Click the Create button.
The Create Import Activity: Enter Import Options page appears.
In the Name field, enter a name for your import.
In the Object field, select the object you are importing.
In the Source File region, select one of the Upload From options.
Note
If you are importing a file into one of the Oracle Cloud services, then you must upload files from your desktop.
Desktop
After you select this option, you must browse for the file.
URL
Network
Enter the path with the following preface file://
For example, if the file is located at /tmp/sample.csv , then your entry is file:///tmp/sample.csv. Note the extra slash in the entry.
If your data file includes a header row, then select the Header Row Included option.
While you can upload files without header rows, doing so makes it more difficult to complete the mapping between the data in your file and the application.
If your file does not use a comma to separate values, then select the correct delimiter in the Data Type field.
The import requires you to create a mapping between the data in the import file and the target attributes in the application. If you previously imported a file with the same format as the file you are importing now, then select an existing mapping from the Import Mapping list. By default, the application saves the import mapping under the import activity name appended with the activation date and time. If you are importing a file in this format for the first time, then you must create the mapping in the next step.
If you are importing one of the following objects, you can import attachments by selecting the Browse option in the Attachments region and selecting a Zip or JAR file of the attachments.
The following import objects support the import of a single attachment for each record:
Assets
Interactions
Opportunities
Partners
The following import objects support multiple attachments for each record:
Leads
Tasks
Note
You must include a column with the names of individual attachments in your import file as described in the Importing Attachments with File-Based Data Import: Explained topic.
In the Import Options region, some of the options in the following table may be available depending on the object you are importing
|
Option |
Description |
|---|---|
|
Import Mode |
For importing leads and employee resources only, you have the option of specifying if you want to create and update records or update only. If you select update, then any new records will be ignored by the import process. For all other import objects, both create and update are available. |
|
Allowable Error Count |
The maximum number of errors before you terminate import. Below the threshold, all records without errors are imported. Above the threshold, no records are imported. |
|
Notification E-Mail |
The e-mail address of the individual who will receive import processing notifications. |
|
Customer Data Management Duplicates |
This option is available only if you have licensed Oracle Fusion Trading Community Data Quality. You can select different options for handling duplicates when you are importing customers, consumers, and legal entities either alone or as part of another object. |
|
Decimal Separator |
Decimal separator used in your import file. |
|
Date Format |
The formatting of the date fields in your file. |
|
Time Stamp Format |
The formatting of time fields in your file. |
|
File Encoding |
The overall encoding for your file. |
Click Next.
The Create Import Activity: Map Fields page displays the attributes in your file with some sample data. If you are reusing an import mapping, then both the Source and Target columns are already populated. The Source columns represent your file. If you are creating a new mapping, then the Target Object and Attribute columns are blank.
For each column in your file that you want to import, select the target object and one of its attributes. Each import object comes with its own set of attributes.
You can choose not to import a column in your file by selecting the Ignore check box.
If you want to specify a constant value for an attribute in the application, you can add the object, the attribute, and its value in the Set Constant Values region.
Note
If you are importing data using the import templates provided on My Oracle Support, then each column header in your template includes the names of both the target object and the target attribute to simplify your mapping process.
Click Next
The Create Import Activity: Schedule page appears.
By default, the import will start immediately after you click Activate in step 19. You can instead start the import at a time you specify by selecting Specific Date from the Schedule list and entering a start date.
Click Next.
The Create Import Activity: Review and Activate page appears.
Click Activate.
You return to the Manage Import Activities page where you can view the status of your import.
An import activity with the status of Completed indicates that your data was loaded into the application tables.
If the process completes with the status of Completed with Errors, click the status link.
You can view the errors at the bottom of the View Import Status page and by selecting the Attachments link in the Files Processed region.
Import objects represent the application and attribute information for business objects that can be imported using external source files.
This topic describes the following:
Import object management options
Custom objects
A single import object can have multiple associated components that are considered objects by themselves. An object and associated objects that can be imported within the same source file are grouped together within the application module class.
Note
Each object includes the Import Activity object (MktImpJobs1). The Import Activity object is a required component of the application module but is not mapped to a source file. All values for this object are derived from the Import Activity definition. Consequently, do not update the Map, Required, and Default Value settings for the Import Activity object.
The following table includes information about the import object:
|
Option |
Description |
|---|---|
|
Attributes |
A view-only listing of object attributes that represent each column in the interface table for the object. |
|
Length |
A view-only listing of widths for the columns in the interface tables. If the source file values for the attribute have more characters than the attribute length, the source file row will not be imported. |
|
Default Value |
Optionally, specify an attribute value to use if a value is not available from the source file or Import Activity constant value. |
|
Map |
Enable the list of attributes that can be mapped to a source file or constant value in the Import Mapping and Import Activity Map Fields step. |
|
Required |
Specify the list of attributes that must be mapped to source file columns. Consequently, if you have selected an attribute as required, you must also enable the Map option for that attribute. When mapping the external source file, the required target attribute defined for the object are displayed with an asterisk. |
To use the file-based import feature for custom objects, you must first generate the artifacts required for import. You generate these required artifacts within Oracle Fusion CRM Application Composer, after making your object model extensions.
Import mapping enables you to predefine a mapping between the columns provided in a source file and the attributes pertaining to the objects being imported. Once you create a mapping, it can be reused in the Import Activity definition.
This topic contains the following sections:
Import options
Source file options
Target options
The following attributes pertain to the import mapping.
|
Attribute |
Description |
|---|---|
|
Object |
The business object to be imported. |
|
Name |
The name that identifies the mapping in the Import Mapping and Import Activity UIs. If the mapping was initially created while mapping fields directly in the Import Activity user interface and automatically saved without providing a user-defined mapping name, the mapping name is derived from the Import Activity name and date. |
|
Decimal Separator |
The format of the fractional portion of numerical values in columns mapped to attributes with a decimal attribute type. |
|
Date Format |
The format of values in columns mapped to attributes with a date attribute type. |
|
Timestamp Format |
The format of values in columns mapped to attributes with a time stamp attribute type. |
|
Lock |
If selected, prevents any user, other than the creator of the mapping, from editing the mapping. |
Map each column that the source file is expected to contain with a specific attribute.
The following table describes the details pertaining to columns provided in the source file:
|
Source Column |
Description |
|---|---|
|
Sequence |
The sequence number in which the columns are expected to be provided in the source file. Two rows cannot have the same sequence number. |
|
Column Name |
The column name expected in the source file if a header row is included, or more generic values such as Column A, Column B, and so on, if the header row is not included for Text file types. The tagging structure is represented for XML file types. |
|
Column Width |
Use when the delimiter value is fixed width for Text file types only. |
|
Ignore |
Ignore the source file column to exclude the data from being imported. |
|
Required |
If selected, a value must exist in the source file or the row will not be imported. |
The following table describes the details pertaining to corresponding attributes in the target application table:
|
Target Attributes |
Description |
|---|---|
|
Object |
The group of import objects that represent the components of the business object being imported. |
|
Attribute |
The attribute name that represents the corresponding interface table column for the object. |
|
Duplicate Validation |
If selected, the attribute, along with other selected attributes, determines what constitutes a duplicate object when comparing objects in the interface tables and existing objects in the target application tables. For example, to validate the uniqueness of an object in the target application tables by the combination of an object's name and date, select Duplicate Validation for both attributes in the mapping. |
The Import Activity consists of a step by step guided process to assist you with creating an import activity for a given object.
This topic describes the source file options defined in the Import Activity that are used by the import process to locate and parse the source file data.
Enter attribute details pertaining to the source file as follows:
|
Option |
Description |
|---|---|
|
File Type |
Source file must be either Text or XML. |
|
Data Type, Delimiter, and Header Row Included |
A Text file type can further be defined based on how the data is delimited and if the source file is expected to include a row of headings for each column. |
|
Import Mapping |
Displays a list of predefined mappings for the object selected for this import activity. The selected mapping will be used as the basis for mapping your source file in the next Import Activity step. |
The following outlines the options that are available to you when locating your source file for import.
|
Option |
Description |
|---|---|
|
File Selection |
Select from the following file selections:
|
|
Upload From |
You can upload the source file from three locations:
If you select Desktop, a File Name field with an associated Update button is displayed. Click Update and browse to search for and select the file you want to upload. If you select URL, enter the address location as in
the following example format: If you select Network, enter the file name path as
in the following example format: Note If you selected the Specific File as your file selection option, then you will have to include the file name for both URL and Network file path locations. |
When you import data from a file using the Manage File Import Activities task, you can include attachments for a subset of import objects, including leads, opportunities, tasks, and other objects. This topic lists the objects that support attachment import, explains how the import works, and provides guidelines.
A subset of import objects supports importing attachments. Some objects permit you to import only one attachment for each record. A few objects permit the import of multiple attachments.
The following table lists the import objects that support the import of attachments. A subset of these supports the import of multiple attachments for each record, as indicated in the following table.
|
Import Object |
Single or Multiple Attachments for Each Record |
|---|---|
|
Assets |
Single |
|
Interactions |
Single |
|
Leads |
Multiple |
|
Opportunities |
Single |
|
Partners |
Single |
|
Tasks |
Multiple |
To import attachment, you:
Create a ZIP or JAR file of the attachment files.
Note
The attachments can be organized in nested folders.
Add an additional column to the data file you are importing, and enter the names of the attachment files. The header of this column must always be: ATTACHMENT_FILE_NAME.
This reference column specifies which attachment file belongs to which record. Other optional columns listed in the following table can be used to upload other attachment information, such as a brief description.
The following table lists all of the available attributes with the header names you must use.
|
Column Header |
Required or Optional |
Description |
|---|---|---|
|
ATTACHMENT_FILE _NAME |
Required |
Captures the file names in the ZIP file. |
|
ATTACHMENT_FILE _DESC |
Optional |
Short description of the file. |
|
ATTACHMENT_FILE _TITLE |
Optional |
File title. If you do not import a file title, then the application uses the file name as the title. |
|
ATTACHMENT_CATEGORY _NAME |
Optional |
Attachment category. |
Upload the ZIP or JAR file with the attachments when you create the file import activity.
You do not map the attachment attributes. The application identifies the special names in the column headers.
Note
You must upload one ZIP file of all the attachments. You cannot upload attachments in multiple files or add additional attachments after you upload the ZIP file the first time.
The following example illustrates the steps required for importing one attachment for each record.
Create a ZIP or Java archive (JAR) file of all of your attachments, for example: myfiles.zip:
file_1.doc
file_2.doc
file_3.doc
file_4.doc
Note
The numbers in the file names are provided for this example. They are not required.
In the import file, add the additional columns to capture the attachment information.
At a minimum, you must include a column with the header name: ATTACHMENT_FILE_NAME to capture the attachment file names. You must use this header name without variation so that the application will identify it.
Unlike the other attributes in your import file, you do not map the attachment columns to import objects and attributes when you create an import activity. The application does the mapping automatically. The mapping is based on the column name.
Your import file might contain data similar to that shown in the following table.
|
LeadName |
StatusCD |
Score |
ATTACHMENT _FILE _NAME |
|---|---|---|---|
|
Lead 1 |
QUALIFIED |
7 |
file_1.doc |
|
Lead 2 |
QUALIFIED |
8 |
file_2.doc |
|
Lead 3 |
QUALIFIED |
3 |
file_3.doc |
|
Lead 4 |
QUALIFIED |
7 |
file_4.doc |
When you create the import activity to import your file, you upload the ZIP or JAR file from your desktop by cllicking the Browse button in the Attachments region in the Import Options page.
The ZIP or JAR file is imported at the same time as the data file.
Note the following:
If a record does not have an attachment, then leave the column value blank.
You can specify a single file to be the attachment for more than one or for all records you are importing. For example, if you wanted the same file to be attached to all the four leads, then your import file structure would be like the data in the following table.
|
LeadName |
StatusCD |
Score |
ATTACHMENT_FILE _NAME |
|---|---|---|---|
|
Lead 1 |
QUALIFIED |
7 |
file_1.doc |
|
Lead 2 |
QUALIFIED |
8 |
file_1.doc |
|
Lead 3 |
QUALIFIED |
3 |
file_1.doc |
|
Lead 4 |
QUALIFIED |
7 |
file_1.doc |
For import objects that support multiple attachments, you repeat the column header names.
Note
If you are adding any of the optional attachment columns, then you must repeat all the columns in the same order.
Suppose you are importing four leads:
Lead 1 includes attachments file_1.doc, file_2.doc, file_3.doc.
Lead 2 includes the attachment file_4.doc.
Lead 3 includes attachments file_5.doc, file_6.doc, file_7.doc.
Lead 4 has no attachments.
Your data file might look like the data in the following table.
|
LeadName |
StatusCD |
ATTACHMENT _FILE _NAME |
ATTACHMENT _FILE _NAME |
ATTACHMENT _FILE _NAME |
|---|---|---|---|---|
|
Lead 1 |
QUALIFIED |
file_1.doc |
file_2.doc |
file_3.doc |
|
Lead 2 |
QUALIFIED |
file_4.doc |
|
|
|
Lead 3 |
QUALIFIED |
file_5.doc |
file_6.doc |
file_7.doc |
|
Lead 4 |
QUALIFIED |
|
|
|
This topic describes the import options available while creating import activities.
The following options are used to identify the formatting of source file data so the data can be correctly interpreted and transformed by the import process:
|
Option |
Description |
|---|---|
|
Decimal Separator |
The format of the fractional portion of numerical values in columns mapped to attributes with a decimal attribute type. |
|
Date Format |
The format for values in columns mapped to attributes with a date attribute type. |
|
Time Stamp Format |
The format for values in columns mapped to attributes with a time stamp attribute type. |
|
File Encoding |
The overall encoding of the characters within the file. |
Depending on the object you are importing and the application modules you have implemented, you can select one or more of these options.
|
Option |
Description |
|---|---|
|
Import Mode |
For importing leads and employee resources only, you have the option of specifying if you want to create and update records or update only. If you select update, then any new records will be ignored by the import process. For all other import objects, both create and update are available. |
|
Allowable Error Count |
An error count above the threshold will stop the import process for all records. If the error count is below the threshold, records without errors are imported. In either case, records with errors will be reported in the Error and Exception files. Validation errors include:
Duplicates found using matching configurations for Customer Data Management objects do not contribute to the error count. |
|
Notification E-Mail |
The e-mail of the intended recipient of import processing notifications. |
|
Customer Data Management Duplicates |
Using this option, which is available only if you have licensed Oracle Fusion Trading Community Data Quality, you can select different options for handling duplicates when you are importing customers, consumers, and legal entities either alone or as part of another object. The duplicates are determined using the following matching configurations:
You can select from one of the following:
|
|
Duplicate Look Back Days |
This option applies only to the Lead import object. Only existing leads created within the period determined by the look back days value are evaluated for duplicates based on the attributes selected for duplicate validation in the predefined import mapping. If a duplicate is found, the lead will not be imported and the duplicate record will be reported on the Exception report. Duplicate leads are included in the calculation of the allowable error count threshold. |
After entering your import options, the second step of the import activity process is to map fields in the source file to the corresponding target attributes.
This topic explains:
Map Fields
Saving the Import Mapping
Constant Values
The Map Fields section can be subdivided into source file columns and target attribute columns.
The source column header value is derived from one of the following:
Predefined mapping, if one is selected
The source file, if the Header Row Included option is selected in the first step of the Import Activity definition (for Text file type only)
Generic values of Column A, Column B, and so on, if the Header Row Included option is not selected (for Text file type only)
XML tagging structure (for XML file type only)
The following table outlines the source columns:
|
Source Column |
Description |
|---|---|
|
Column Header |
Represents the column header for Text file types and the tagging structure for XML file types. |
|
Example Value |
Values are derived from the first source file saved with the predefined mapping. If you did not select a predefined mapping, the example values are taken from the first data row in the source file selected in the first step of the Import Activity definition. |
|
Ignore |
Select this option if you do not want to import the source file data in that column. |
The following table outlines the target columns:
|
Target Column |
Description |
|---|---|
|
Object |
The group of import objects that represent the components of the business object being imported. |
|
Attribute |
The attribute name that represents the corresponding interface table column for the object. |
The mapping between source file information and target attributes is saved as a reusable mapping when the Import Activity is saved, using the import activity name and date to derive a mapping name. If you selected a predefined mapping, modifications made in the Import Activity to an unlocked mapping will update and save to the predefined mapping. If the predefined mapping is locked, a modified mapping will be saved as a new mapping. To specify a mapping name for new mappings, select the Save As option from the Map Fields Actions menu.
Constant values provide a way to specify a value for a target attribute that all imported objects will inherit. For example, if a source file does not contain a column for business unit and all of the objects in the file belong to the same business unit, enter a constant value for the object and business unit attribute.
This topic explains the meaning of the different import activity statuses when you import data from a file using the Manage File Import Activities task.
The following table lists and describes the import activity statuses.
|
Status |
Description |
|---|---|
|
No status displayed for the activity |
The new import activity definition is not complete. |
|
New |
The import activity definition is complete, but the activity is not yet scheduled to run. |
|
Scheduled |
The import activity definition is complete and scheduled to run later. |
|
Interface table upload in progress |
The data file is being loaded into the interface tables. |
|
Base table upload in progress |
The data file is being loaded from the interface tables into the application tables. |
|
Completed |
All records were processed and loaded into the application tables. |
|
Completed with errors |
The import activity found errors in the data file that you must correct. You can view details about the errors by clicking the status link. |
You can monitor all file import activities that are currently scheduled to run, have completed successfully, or failed with errors. For each import activity, you can view the details pertaining to each underlying process and make necessary updates for any failed records to import again.
You can view the list of import activities from the Manage Import Activities page. Select the import activity that you want to monitor by clicking on the hyperlink in the corresponding Status column. The View Import Status results page is displayed which contains the following sections:
Files Processed
Import Processes
The Files Processed section displays a row for each source file that is processed.
The import processing details are summarized and displayed for each source file and include the following:
|
File Processing Summary Information |
Description |
|---|---|
|
Records Read From File |
The number of records read from the source file. |
|
Format Errors |
The number of errors found when processing data to insert into the interface tables from the source file, Import Activity constants, and Import Object value default values. View the error details in the Exception and Error files attached to the process. |
|
Load Errors |
The number of errors found when importing data from the interface tables to the destination application tables. View the error details in the Exception and Error files attached to the process. |
|
Successfully Loaded |
The number of import objects imported to the application destination tables. If the import object is made up of multiple components, each component is counted as successfully loaded. Consequently the Successfully Loaded count may be larger than the Records Read From File count. View the successful record details in the Log file attached to the process. |
|
Attachments |
Once an Import Activity process has completed, processing reports are included in the Attachments column. The Log file includes the records that were successfully imported plus the unique destination application table identifiers for the objects. The Exception file includes the records that were not imported plus a reference to one of the errors for each record that failed. The Error file includes all the errors for each record that failed validation. |
From the Import Processes section, you can view details pertaining to each process involved in importing the objects in the source file. A listing of brief messages provides information on processing steps within each underlying process.
This example demonstrates how to resolve errors found in source file data used for importing into interface tables and destination application tables.
The following table summarizes key decisions for this scenario:
|
Decisions to Consider |
In This Example |
|---|---|
|
Should the errors be corrected and submitted again for import? |
Yes, for an invalid value error. No, for a duplicate record found. |
|
Is the Import Activity processing source files on a repeating schedule? |
Yes. An Import Activity is defined to process a new source file weekly. A second Import Activity is defined to process corrections to errors in the weekly file. |
Review the Import Activity status and reports.
Correct the exception file data and save to your desktop.
Import the file with the corrected data.
A single import object can have multiple associated components that are considered objects by themselves. Whether or not an associated object can be grouped as a component of another object for the purpose of file import is determined by the complexity of the object structure and how it is stored in the data model. Oracle Fusion provides import objects predefined to meet the file processing import requirements. Consequently, in some cases, more than one source file may be required to capture all associated components of an object.
The Import Activity will not stop the currently running process. However, it will stop the next process that has not started plus any future repeating file import activities. You can always activate the process at a later stage.
File-based data import enables you to record consumers and organization contacts in a marketing list when importing consumer, lead, and response import objects. Select an existing list or create a new one. A marketing list is assigned the list type value of Imported if created while defining an import activity. After the objects are imported successfully, the consumers and contacts are added as members of the marketing list.
This topic provides an overview of the types of help available for importing legacy and other data into Oracle Fusion CRM using File-Based Data Import.
There are three main sources of information for import:
Help topics about using the File-Based Data Import tool are linked to the application pages and available by clicking the help icon.
These topics provide general information about import.
Help topics on individual import objects are available by searching Oracle Fusion Help Application.
Help topics provide information on the import objects, list the reference guides you must consult for information on individual attributes, and provide examples.
You can navigate to help by selecting Applications Help from the Help menu at the top right of every application page.
There you can view individual help topics or download implementation guides. In the implementation guides, you can find the import topics grouped under the File-Based Data Import heading in the Define Common CRM Configuration task group.
Oracle Enterprise Repository, which contains reference guides with detailed information on individual attributes.
You can search for the reference guides
by name in the repository, which is available at the following URL: https://fusionappsoer.oracle.com/oer/index.jsp
To understand what attributes are available for import for each object, follow these steps:
Start by searching help using the
key word importing and the name of the
object you are importing.
For example, to get help
on importing customers, enter importing customers.
Depending on the complexity of the import, your search will return one or more of the following help topic types:
|
Help Topic Title |
Description |
|---|---|
|
Importing <import object name>: Explained |
High-level topic that inform the user how each Oracle Fusion business object is structured and explains its relationship to the import object. |
|
<import object name> Import Objects: How They Work Together |
This type of topic lists the target objects associated with each import object and provides the names of the Oracle Enterprise Repository reference guides that describe the attributes for those target objects. Target objects are the objects you select when you create the import activity mapping. |
|
Importing <import object name>: Conceptual Example |
This type of topic provides an example of how to import the object without detailed steps. |
|
Importing <import object name>: Worked Example |
This type of topic walks you through an example step by step. |
Using the names of the reference guides listed in the <import object name> Import Objects: How They Work Together topic, search for and download the reference guides from the Oracle Enterprise Repository.
These guides include detailed descriptions of attributes and permitted values.
This topic explains how to prepare and import Appointment data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
An appointment is a business object that is used to record scheduled meetings, including participants and references to specific objects of interest such as a sales lead or an opportunity.
Consider the following questions when importing your data:
How does your legacy system or source system represent an appointment compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your appointment data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. To start, you must understand how Oracle Fusion Applications represent the structure of an appointment.
In Oracle Fusion Applications, a single appointment contains information such as the date and time, subject, description, and reminder setting. Additionally, a single appointment can include one or more internal and external participants and one or more references to the objects of interest.
To facilitate the import of appointments, Oracle Fusion Applications incorporates the structure of the appointment into a single import object: Appointment.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the appointment.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Appointments |
Appointment Import Objects: How They Work Together |
Hint: You can use the keyword importing appointments to search for related topics in Oracle Fusion Applications Help.
Oracle Fusion Applications does not support extensible attributes for the appointment object.
For the appointment business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables. The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import object, to create source-file mappings, and to schedule the import activities.
To associate appointments with internal and external participants and business objects, you must include in your source file the unique internal identifier for each participant and business object. Therefore, the associated participants and business objects must be entered or imported before submitting the Appointment import activity. The File-Based Data Import Activity log file typically includes the internal identifier for internal resources, external contacts, and business objects imported using the File-Based Data Import feature. Optionally, you can obtain the internal identifier for existing resources, contacts, and business objects by using the Manage Bulk Data Export, Schedule Export Processes Setup and Maintenance task.
Importing attachments is not supported for the appointment import object.
You must be assigned the Customer Relationship Management Application Administrator to access and submit the import activities for appointments.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Participants can view their appointments using the Fusion calendar. Users with access to the related business objects or sales accounts can also view the associated appointments.
The File-Based Data Import feature supports importing appointment data from an external data source into Oracle Fusion Applications. You use the Appointment import object to submit a file-based import activity. This topic describes the following about the Appointment import object:
Target import object concepts
Target objects for the Appointment import object
Target import object attributes
Target object attribute reference guide files
The Appointment import object is used to import records containing information about appointments representing scheduled meetings, including participants and references to specific objects of interest such as a sales lead or an opportunity.
The Appointment import object is split into separate target import objects for organizing the individual attributes of the appointment and to manage the one-to-many appointment structure. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects in the Appointment import object are generally grouped into information about the appointment, references to the internal and external participants, and references to the objects of interest. The following figure shows the target import objects included in the Appointment import object, each represented by their familiar name and their formal target import object name, shown in parentheses.
The AppointmentImport target object includes the attributes for the majority of the information captured for an appointment, such as the date and time, subject, description, and reminder setting. To import appointment participants, you will use the ActivityAssigneeImport target object to associate internal resources and the ActivityContactImport target object to associate external contacts. When appointments pertain to specific business objects, such as a sales lead or opportunity, the attributes pertaining to the association of the business objects for the appointment are included in the AppointmentAssociationImport target object.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
To access the reference guide files for the Appointment's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Appointment File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
AppointmentImport |
Appointment information |
ZMM_ACTIVITIES_Reference |
|
ActivityAssigneeImport |
Appointment internal resource participants |
ZMM_ACT_ASSIGNMENTS_Reference |
|
ActivityContactImport |
Appointment external contact participants |
ZMM_ACT_CONTACTS_Reference |
This topic explains how to prepare and import Click-to-Dial agent and agent connector parameter data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
Click-to-Dial Agent is a business object that enables the users to sign in to click-to-dial as an agent, establish the connection with their telephony system, then make or receive calls using the Click-to-Dial toolbar.
Consider the following questions when importing your data:
How does your source system represent the agent compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
Before you import your legacy or source system agent information, you must understand how the Agent data correlates to Oracle Fusion. This starts with an understanding of how Oracle Fusion represents the structure of the data for a Click-to-Dial agent and the agent connector parameters.
The Oracle Fusion click-to-dial object structure is essentially flat as opposed to a deeply hierarchical structure. For any one agent there can be several connectors, each with one-to-many agent parameters.
The Click-to-Dial Agent contains the basic information about the agent and how the agent connects to the telephone system, such as the connector name, the Agent ID, Agent Group, Agent Password, a description, and the status of the agent.
Each agent can have several connector parameters. This information is also contained in the Click-to-Dial Agent import object. It includes such items as the Connector Reference First and Last Name (the agent name), the connector name, any agent connector parameters and their values, for example, the agent user ID or extension.
To facilitate the import of the click-to-dial agent, Oracle Fusion has organized the structure of the Agent information into import objects. The import object for the agent and the agent connector parameters is the Click-to-Dial Agent.
Each import object is a collection of attributes that help to map your data to the Oracle Fusion Applications data and support one-to-many relationships between the structural components that make up the click-to-dial agent and connectors.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used to select default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, see Click-to-Dial Agent and Agent Connector Parameter Components: How They Work Together.
Oracle Fusion Applications do not support extensible attributes for click-to-dial objects. You can import only data for click-to-dial objects that already exist by default in Oracle Fusion Applications.
For the click-to-dial business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables. The Define File-Based Data Import Setup and Maintenance task list includes the tasks to configure the import objects, create source-file mappings, and schedule the import activities. You submit file-based import activities for each import object. When creating an agent, you import the Agent object.
You must be assigned the Customer Relationship Management Application Administrator or Sales Administrator role to access and submit the import activities for Click-to-Dial.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with either the Customer Relationship Management Application Administrator or Sales Administrator role can also navigate to the Click-to-Dial work area to view the imported agents and agent connector parameters.
You use the Click To Dial Agents import object to submit a file-based import activity to import your agents and agent connector parameters. This topic describes the following:
Target import object concepts
Target objects for the Agent import object
Target import object attributes
Target object attribute reference guide files
The Click To Dial Agents import object is split into separate target import objects for organizing the individual attributes of the agent and to manage the one-to-many agent connector parameter structure. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object. The Agent import object is used to import click-to-dial agents and information to create or update associated connector parameters specific to the agent.
The target import object in the Agent import object contains information about agents and information about the agent parameters used by the named connector. The agent connector parameters relate to an agent and connector pairing. The following figure shows the target import objects included in the Click-to-Dial Agent import object, each represented by their familiar name and their formal target import object name, shown in parentheses.
Click-to-Dial Agent (ImpCommUser) is made up of the attributes that define that agent, such as Agent
ID, Agent Group, Agent First Name, Agent last name, a Description,
status and Connector name. The Agent Connector Parameter import object
(ImpConnUserParamValue) is associates
with the Agent and consists of the Connector Reference First and Last
names (the agent names), Connector Name, Connector User Parameter
Name and Value, as well as the Connector Record Language Code. User
parameters can be designated, such as the agent's extension (AcdExtension) and it's value (ImportTestAcdExtension) or the User ID, (AcdUserid), and its value, (ImportTestAcdUser).
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
To access the reference guide files for the agent and agent connector parameter target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Agent and Agent Connector Parameter File-Based Data Import asset.
|
Target Import Objects (Seeded) |
Description |
Associated OER Attribute File |
|---|---|---|
|
ImpCommUser |
Agent information, such as Agent ID, Agent Group and so on. |
MCT_IMP_COMM_USER_Reference |
|
ImpConnUserParamValue |
Agent connector parameters, such as the users ID or extension. |
MCT_IMP_CONN_USR_PAR_VAL_Reference |
This topic explains how to prepare and import consumer data from an external data source into Oracle Fusion Applications, using the File-Based Data Import feature. A consumer is a person who intends to purchase goods and services. Within Oracle Fusion Applications, a person with a selling relationship is referred to as a consumer. A consumer import object allows you to import all information about a consumer, such as the consumer profile, consumer address information, consumer contact point information, and consumer contact preference information.
You must consider the following questions before importing consumer information:
How does your legacy or source system represent the consumer information compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map them to your existing data values?
Do you have to customize Oracle Fusion Applications to capture attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do I verify my imported data?
You must understand how your consumer data corresponds with the data in Oracle Fusion Applications to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a consumer.
The Oracle Fusion Applications consumer structure is hierarchical. The root of the hierarchy is the consumer profile, which must exist before you can import lower-level entities, such as e-mail, sell-to address, sales account profile, and fax. These child entities can have other entities as their child entities. This hierarchical structure supports one-to-many relationships between the components that make up the consumer.
The following figure shows the consumer and its child entities.
The person profile contains basic information about the consumer, such as the first name, last name, and party usage. For each consumer, you can have other information, such as sell-to addresses, phone details, and sales account profile.
Note
All entities referring to contact information, such as primary phone or e-mail, include a child entity that captures the contact preference. For example, the Primary Phone Contact Preference entity captures the contact preference of the consumer for the contact method primary phone.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the consumer.
A good understanding of the import objects and attribute details is critical to preparing your import data. Oracle Fusion Applications attribute details are available for your reference in the Oracle Enterprise Repository. The reference guide files contain descriptions, default values, and validations for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correspond to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values.
If you have to extend the Oracle Fusion Applications import object to import your legacy or source data, then you must use Oracle Fusion Applications CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the consumers business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks required to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a consumer, you use the Consumer import object. An import activity defines the instructions for processing the import data, including the source file, import mapping from the source file to the Oracle Fusion Applications object and attribute, and the import schedule.
When importing consumer information, you first import the basic person profile information and then the child entities for the consumer. When importing child entities, you must provide the parent reference information for all parent levels for the entity. You must provide the PartyOrigSystem and PartyOrigSystemReference of the consumer when importing contacts for the consumer. PartyOrigSystem is the source system code that identifies the source of the information being imported. PartyOrigSystemReference is unique for each row of data within a single import, and is a combination of PartyOrigSystem and a unique reference. For example, you first import basic profile details, such as first name, last name, party type, and party usage. You then import other information, such as additional names, e-mail, sell-to address, and primary phone for the consumer.
You can view the list of import activities from the Manage Import Activities page. You can verify your imported data by clicking the Status column for your import activity. Alternatively, you can also navigate to the Customer Center work area to view the consumer information that you have imported.
The Consumer import object allows you to import consumers, their detailed information, and contacts related to the consumer. This topic describes the Consumer import object and introduces the following:
Target import object concepts
Target objects for the Consumer import object
Target import object attribute
Target object attribute reference guide files
The Consumer import object imports consumer information, and is split into separate target import objects for organizing the individual attributes of the different aspects of the consumer. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects included in the Consumer import object are grouped into information about the consumer. The person profile is the target import object containing attributes to import information about the consumer. When updating an existing consumer with additional information, you must provide the parent reference information for the existing consumer.
To update the information for an existing consumer or to create a consumer record, you can import consumer profile information, addresses, and contact points, such as phone and fax number. The following target import objects are for creating and updating the corresponding consumer information: PersonProfile, PersonAddress, PrimaryPhone, Fax, Mobile, AdditionalName, e-mail, SellToAddress, and SalesAccountProfile.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target import object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes that you want to import do not have an equivalent target object attribute, then review the Oracle Fusion Applications CRM Application Composer extensibility features for the consumer.
To access the reference guide files for the consumer target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Consumer File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
PersonProfile |
Includes detailed person information such as person name, relationship type, gender, and marital status. Sample attributes: PersonFirstName, PersonLastName, DateOfBirth, PersonAcademicTitle, and PlaceOfBirth. Reference attributes: PartyId, PartyOrigSystem, PartyOrigSystemReference, RelOrigSystem, RelOrigSystemReference, and RelationshipId. |
HZ_IMP_PARTIES_T_Reference |
|
SellToAddress |
Includes consumer addresses and party sites information. If party site usage of an address is not defined, then the import process sets it to Sell-To. In case there are multiple addresses without party site usage information, then the import process designates one of the addresses as the Sell-To address. Sample attributes include Address1, Address2, City, Country, County, State, and PostalCode. Reference attributes for location: LocationOrigSystem, LocationOrigSystemReference, and LocationId1. Reference attributes for party sites: SiteOrigSystem and SiteOrigSystemReference, and PartysiteId1. Reference attributes for party site use: SiteuseOrigSystem, SiteuseOrigSystemRef, and PartySiteUseId. |
HZ_IMP_PARTYSITES_T_Reference |
|
PrimaryPhone |
Indicates the primary phone number of the consumer. If the consumer has multiple phone numbers, one of the phone numbers is designated as the primary phone number. Sample attributes: PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, and PhoneNumber. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
Mobile |
Indicates the mobile phone number of the consumer. Sample attributes: PhoneAreaCode, PhoneCountryCode, and PhoneNumber. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
Fax |
Indicates the fax number of the consumer. Sample attributes: PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, and PhoneNumber. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
|
Indicates the e-mail of the consumer. Sample attributes: ContactPointPurpose, EmailAddress, and StartDate. Reference attributes: CpOrigSystem and CpOrigSystemReference |
HZ_IMP_CONTACTPTS_T_Reference |
|
InstantMessenger |
Indicates the instant messenger or social networking information of a consumer. Sample attributes: ContactPointPurpose, EndDate, InstantMessagingAddress, and InstantMessengerType. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
SalesAccountProfile |
Includes detailed information about a consumer sales account. A sales account is a specific sell-to entity within a given consumer. A consumer can have multiple sales accounts and sales account profiles. Sample attributes: AccountDirectorId, CreationDate, NamedAccountFlag, and AssgnExceptionFlag. Reference attributes: OwnerOrigSystem and OwnerOrigSystemReference. |
ZCA_IMP_SALES_ACCOUNTS_Reference |
|
AdditionalName |
Indicates alternative name of a consumer. Sample attributes: NameId, PersonFirstName, PersonLastName, and PersonTitle. Reference attributes: AdditionalNameOrigSystem and AdditionalNameOrigSystemReference. |
HZ_IMP_ADDTNLPARTYNAMES_T_Reference |
|
Classification |
Incudes classification information for a consumer. Classification allows you to categorize entities such as parties, projects, tasks, and orders as hierarchies. Sample attributes: ClassificationCode, ClassificationCategory, PrimaryFlag, and Rank. Reference Attributes: ClassificationOrigSystem and ClassificationOrigSystemReference. |
HZ_IMP_CLASSIFICS_T_Reference |
|
AdditionalIdentifier |
Includes detailed information about an additional identifier for a consumer. Sample attributes: IdentifierValue, IdentifierType, Country, and IssuingAuthorityName. Reference attributes: IdentifierValue, AdditionaldentifierOrigSystem and AdditionalldentifierOrigSystemReference. |
HZ_IMP_ADDTNLPARTYIDS_T_Reference |
|
Relationship |
Includes information about a relationship between the consumer and another entity, such as an organization or a person. Sample attributes: RelationshipCode, RelationshipType, and DependentFlag. Reference attributes: RelationshipID, RelOrigSystem and RelOrigSystemReference. |
HZ_IMP_RELSHIPS_T_Reference |
|
PrimaryPhoneContactPreference |
Indicates the consumer's preference about being contacted through phone. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference Attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
MobileContactPreference |
Indicates the consumer's preference about being contacted through mobile phone. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference Attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
FaxContactPreference |
Indicates the consumer's preference about being contacted through fax. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode, Reference Attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
EmailContactPreference |
Indicates the consumer's preference about being contacted through mobile phone. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference Attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
This topic explains how to prepare and import contact data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
A contact is a person party related to a customer, and the contact object contains information that identifies the contact and offers the contact points of the contact. Contact points can be geographical addresses, phone numbers, e-mail IDs, URLs, messenger IDs, and so on. The contact object also contains contact preference information for the contact.
You must create or import contacts before you can associate them with customer objects. You must consider the following questions before importing contact information:
How does your legacy system or source system represent the contact compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your contact data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a contact.
In Oracle Fusion Applications, one table stores the contact information and another table optionally stores contact point details for that contact. A contact point is an identified means to contact a party. Contact points can be phone numbers, e-mail IDs, Web site addresses, or instant messenger IDs.
The following figure shows the contact object and its child entities.
The contact profile contains basic information about the contact, such as the contact name, party type, and party usage. For each contact, you can assign classifications, phone details, and additional names. If the contact is a consumer, then the contact relationship of the consumer includes other child entities that capture information about the consumer contact, such as contact job, contact phone, contact address, and contact e-mail.
Note
All contact-related entities, such phone or e-mail, include a child entity that captures the contact preference. For example, the Phone Contact Preference entity captures the contact preference of the consumer for the contact method phone.
To facilitate the import of contacts, Oracle Fusion Applications incorporate the structure of the contact business object into import objects. The import object for contacts is Contact.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the contact.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Contact |
Contact Import Objects: How They Work Together |
Hint: You can use the keyword importing contacts to search for related topics in Oracle Fusion Applications Help.
If you need to extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the Contact business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a new contact, you import the Contact object. You must be assigned the master Data Management Administrator job role to access and submit the import activities for contacts.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. You can also navigate to the Customer Center work area to view the contact information that you have imported.
You can import all your contact information using the Contact import object. This topic describes this import object and introduces the following
Target import object concepts
Target objects for the Contact import object
Target import object attributes
Target import object attribute reference guide files
The Contact import object is used to import a contact's profile information, such as first name, last name, address, and so on, and contact point information, such as phone numbers, fax, e-mail IDs, and so on. The Contact import object is split into separate target import objects for organizing the individual attributes of the different aspects of the contact's profile and contact points. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects included in the Contact import are grouped into information about the contact and the contact's relationship with other parties. The contact profile is the target import object containing attributes to import information about the contact. You can have multiple contact relationships associated with a contact. There are multiple target import objects that include attributes to import contacts and their related information.
When updating an existing contact, you must provide the parent reference information of the existing contact. When importing contact profile or contact point information for a contact, you must provide relationship reference information in addition to the parent reference. You must provide this information because a contact can have multiple relationships with an organization, such as employee or board member. When importing information about a contact, you must refer to the specific relationship that you want to import information for. For example, you must specify whether you want to import information for John Smith the employee or John Smith the board member. If you do not include the reference information for a contact relationship, then the import process creates a new relationship.
To update the information for an existing contact or to create a contact record, you can import contact profile information, addresses, and contact points. The following target import objects are for creating and updating contact information: PersonProfile, Fax, PrimaryPhone, Url, SalesAccountProfile, Classification, AdditionalName, Relationship, and AdditionalIdentifier.
To update or create a contact point, use the following target import objects: ContactRelationship, ContactJob, ContactAddress, ContactEmail, ContactPhone, ContactMobile, ContactInstantMessenger, and ContactFax. All contact-point-related entities, such as phone or e-mail, include a child entity that captures the contact preference. For example, the ContactPhoneContactPreference entity captures the contact preference of the primary phone contact method.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes that you want to import do not have an equivalent for the target object attribute, then review the Oracle Fusion CRM Application Composer Extensibility features for the marketing response.
To access the reference guide files for the response's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Response File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
PersonProfile |
Includes information that identifies a contact. Sample attributes: PersonFirstName, PersonLastName, DateOfBirth, gender, HouseholdIncome, and PlaceOfBirth Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_PARTIES_T_Reference |
|
Fax |
Indicates the fax number of the contact. Sample attributes: PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, and PhoneNumber. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
FaxContactPreference |
Indicates the contact's preferences about being contacted through Fax. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
Phone |
Indicates the phone number of the contact. If the contact has multiple phone numbers, then the first phone number is designated as the primary phone number. The attributes of PrimaryPhone, Fax, and URL are the same. However, the value of the attribute ContactPointType is different for each of these contact point related entities. Sample attributes: PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, and PhoneNumber. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
PhoneContactPreference |
Indicates the contact's preferences about being contacted by phone. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
|
Indicates the e-mail of the contact. Sample attributes: ContactPointPurpose, EmailAddress, and StartDate. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
EmailContactPreference |
Indicates the contact's contact preferences about being contacted through e-mail. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
InstantMessenger |
Indicates the instant messenger information of a contact. Sample attributes: ContactPointPurpose, EndDate, InstantMessagingAddress, and InstantMessengerType. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
Mobile |
Indicates the mobile number of a contact. Sample attributes: ContactPointPurpose, ContactPointType, PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, PhoneNumber, and PrimaryFlag. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
MobileContactPreference |
Indicates the contact's preferences about being contacted through mobile phone. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
Classification |
Includes classification information for a contact. Classification allows you to categorize entities, such as parties, projects, tasks, and orders as hierarchies. Sample attributes: ClassificationCode, ClassificationCategory, PrimaryFlag, and Rank. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CLASSIFICS_T_Reference |
|
Address |
Indicates the address of a contact. If the contact has multiple addresses, then the first address is designated as the primary address. Sample attributes: Address1, Address2, City, Country, County, State, and PostalCode. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_PARTYSITES_T_Reference |
|
AddressContactPreference |
Indicates the contact's preferences about being contacted at the primary address. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
AdditionalName |
Indicates the alternative name of a contact. Sample attributes: Additional Name, Additional Name Type, and GlobalPreferredNameFlag. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_ADDTNLPARTYNAMES_T_Reference |
|
AdditionalIdentifier |
Includes the basic information about an additional identifier for the contact. Sample attributes: IdentifierValue, IdentifierType, Country, and IssuingAuthorityName. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_ADDTNLPARTYIDS_T_Reference |
|
ContactRelationship |
Includes information about a relationship between the contact and other parties. Sample attributes: RelationshipCode, RelationshipType, and DependentFlag. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_RELSHIPS_T_Reference |
|
ContactEmail |
Indicates the e-mail contact point of the contact. Sample attributes: ContactPointPurpose, EmailAddress, and StartDate. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactEmailContactPreference |
Indicates the contact's preferences about being contacted through the e-mail contact point. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactFax |
Indicates the number of the fax contact point of the contact. Sample attributes: ContactPointPurpose, ContactPointType, PhoneAreaCode, PhoneCountryCode, and PhoneExtension. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactFaxContactPreference |
Indicates the contact's preference about being contacted through the fax contact point. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactInstantMessenger |
Captures information about a contact's instant messenger contact point. Sample attributes: ContactPointPurpose, EndDate, InstantMessagingAddress, and InstantMessengerType. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactMobile |
Indicates the number of a contact's mobile contact point. Sample attributes: ContactPointPurpose, ContactPointType, PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, PhoneNumber, and PrimaryFlag. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactMobileContactPreference |
Indicates the contact's preferences about being contacted through the mobile phone contact point. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactPhone |
Indicates the number of the contact's phone contact point. If the contact has multiple phone numbers, then the first phone number is designated as the primary phone number. Sample attributes: ContactPointPurpose, ContactPointType, PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, PhoneNumber, and PrimaryFlag. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactPhoneContactPreference |
Indicates the contact's preferences about being contacted through the phone contact point. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactAddress |
Indicates the address of a contact's address contact point. If the contact has multiple addresses, then the first address is designated as the primary address. Sample attributes: Address1, Address2, City, Country, County, State, and PostalCode. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_PARTYSITES_T_Reference |
|
ContactAddressContactPreference |
Indicates the contact's preferences about being contacted at the address contact point. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactJob |
Includes the job information of a contact. Sample attributes: Comments, ContactNumber, Department, DepartmentCode, JobTitle, and JobTitleCode. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_CONTACTS_T_Reference |
This topic explains how to prepare and import country structure data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature. A country structure is a hierarchical grouping of geography types for a country. For example, the geography structure for the United States has the geography type of State at the top, followed by the County, then the City, and finally the Postal Code.
You can use the country structure to set up the following:
The relationships between geographies within a country
The types of geographies that you can define for a country
Consider the following questions when importing your data:
How does your legacy system or source system represent the country structure compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your country structure data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a country structure.
You must import a separate country structure import object for each country. Each of these import objects must contain the geography types that are used in the country's structure, organized in a hierarchy using geography level numbers. For example, if you are importing the country structure of Australia, the country structure could be the following: 1: Country, 2: State, 3: County, 4: Town, 5: ZIP.
To facilitate the import of country structures, Oracle Fusion Applications incorporate the structure of the country structure into import objects. The import object for country structures is GeoStructureLevel.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the country structure.
A good understanding of the attribute details of the import objects is critical to preparing your import data. For information about the Oracle Fusion Applications attributes, see the Oracle Enterprise Repository. The reference files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Country Structure |
Country Structure Import Objects: How They Work Together |
If you need to extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the country structure business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a new country structure, you import the Country Structure object.
You must be assigned the Master Data Management Administrator job role to access and submit the import activities for country structures.
You can view the list of import activities from the Manage Import Activities page. You can verify your imported data by clicking the Status column for your import activity.
This topic describes the Country Structure import object. You use the Country Structure import object when you submit a file-based import activity to import your country structure information. This topic introduces the following:
Target import object concepts
Target objects for the Country Structure import object
Target import object attributes
Target object attribute reference guide files
The Country Structure import object is used to import a country structure hierarchy, including details, such as geography type, geography type name, parent geography type, geography level numbers, and so on. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The Country Structure import object contains one target import object that organizes the individual attributes of the different aspects of the geography structure. When updating an existing country structure, you must provide the parent reference information of the existing country structure. This reference information connects the imported geography structure to the existing one. Use the ImpGeoStructureLevel target import object to create and update country structure information.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import does not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for country structures.
To access the reference guide files for the country code's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
For detailed information on importing geographies using file-based import, refer to Document No. 1481758.1, Importing Master Reference Geography Data, on the Oracle Support site.
The following table lists the reference guide files that are available from the Documentation tab for the Country Code File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
ImpGeoStructureLevel |
Contains information that specifies a country's geography structure. Sample attributes: GeographyType, GeographyTypeName, LevelNumber, and ParentGeographyType. Reference attribute: CountryCode |
HZ_IMP_GEO_STRUCTURE_LEVELS_Reference |
This topic explains how to prepare and import customer data from an external data source into Oracle Fusion Applications, using the File-Based Data Import feature.
A customer is an entity with whom you have a selling relationship. Oracle Fusion Applications refer to sales account and sales prospects collectively as a Customer. A customer business object allows you to capture all information about a customer, such as the customer profile, customer contact relationships information, and customer contact points.
A sales account is a specific sell-to entity within a given customer. You can create leads and opportunities for sales accounts. An entity with a sales account in Oracle Fusion Applications can be one of the following:
Sales Prospect: A prospective entity or person who does not have a sell-to address. This entity is used to define leads.
Customer: A sales account or sales prospects.
Legal Entity: A legal entity is a party that can enter into legal contracts or a business relationship. It can be sued if it fails to meet contractual obligations.
You can use the Customer import object to import sales accounts or sales prospects of the type organization. You can use the Group Customer import object to import customers of the type group, and the Consumer import object to import customers of the type person.
You must consider the following questions when importing your data:
Did you identify the records that should be imported as sales prospects, and the records that should be imported as sales accounts?
How does your legacy or source system represent the customer information compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map your existing data values to the Customer import object?
Do you have to customize Oracle Fusion Applications to capture attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do I verify my imported data?
Before you can import your customer data from the legacy or source system, you must first analyze the data and see how it corresponds to the customer object structure of Oracle Fusion Applications. You must understand how Oracle Fusion Applications represent the structure of the data for a customer.
The Oracle Fusion Applications Customer import object structure is hierarchical. The root of the hierarchy is the organization profile, which must exist before you can import lower-level components, such as classifications, contacts, and sales account profiles. These child entities can have other entities as their child entities. This hierarchical structure supports one-to-many relationships between the components that make up the customer.
The following figure shows the customer object and its child entities.
The organization profile contains basic information about the customer, such as the customer name and party usage. For each customer, you can assign classifications, contacts, sell to addresses, phone details, and additional names. The contact of the customer, in turn, includes other child entities that capture information about the contact, such as contact job, contact primary phone, contact primary address, and contact e-mail.
Note
All contact entities, such as primary phone or e-mail, include a child entity that captures the contact preference. For example, the Primary Phone Contact Preference entity captures the contact preference of the customer for the contact method primary phone.
After you understand the structure of the data, the next step is to compare the detailed attribute values of your data with the Oracle Fusion Applications data. Each import object is a collection of attributes organized to assist you when mapping your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the customer.
A good understanding of the import objects and attribute details is critical to preparing your import data. The reference guide files contain descriptions, default values, and validations for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correspond to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values.
To extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the customer business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Import Setup and Maintenance task list includes the tasks required to configure the import objects, to create source file mappings, and to schedule the import activities. You submit file-based import activities for each import object. An import activity defines the instructions for processing import data including the source file, import data mapping from the source file to the Oracle Fusion Applications object and attribute, and the import schedule.
When importing customer information, you first import the basic customer profile information, followed by the child entities for the customer. When importing child entities, you must provide the parent reference information for all parent levels for the entity. For example, you first import basic profile details, such as customer name, party type, and party usage. You then import contacts and contact information, such as phone, address, contact points, and fax for the customer. You must provide the PartyOrigSystem and PartyOrigSystemReference of the customer when importing contacts for the customer. PartyOrigSystem is the source system code that identifies the source of the information being imported. PartyOrigSystemReference is unique for each row of data within a single import, and is a combination of PartyOrigSystem and a unique reference. When importing contact information for a customer, you must provide the relationship reference information. This information is required because a contact can have multiple relationships with a customer.
You can view the list of import activities from the Manage Import Activities page. You can verify your imported data by clicking the Status column for your import activity. Alternatively, you can also navigate to the Customer Center work area to view the customer information that you have imported.
The Customer import object allows you to import customers, their detailed information, and contacts related to the customer. This topic describes the Customer import object. It introduces the following:
Target import object concepts
Target objects for the Customer import object
Target import object attribute
Target import object attribute reference guide files for evaluating and mapping source file data
The Customer import object imports customer information and contacts related to customer. The Customer import object is split into separate target import objects for organizing the individual attributes for the different aspects of the customer and customer contact. Before you import customer information, you must understand how the target objects are related and what attributes are included in each object. This understanding helps you create the appropriate mapping between the source data in your import file and the target attributes.
The target import objects included in the Customer import object are grouped into information about the customer and the customer contact. The organization profile is the target import object containing attributes to import information about the customer. You can have multiple contacts associated with a customer. The Customer import object has multiple target import objects that include attributes to import customer contacts and their related information.
When updating an existing customer with additional information, you must provide the parent reference information for the existing customer. When importing customer contacts or contact information for a customer, you must provide relationship reference information in addition to the parent reference. This information is required because a contact can have multiple relationships with an organization, such as an employee or board member. When importing information about a contact you must refer to the specific relationship that you want to import information for. For example, you might want to import information for John Smith the employee or John Smith the board member. If you do not include the reference information for a customer-contact relationship, then the import process creates a relationship.
To update the information for an existing customer or to create a customer record, you can import customer profile information, addresses, and contact points, such as a phone and fax. The following target import objects are for creating and updating the corresponding customer information: OrganizationProfile, Fax, PrimaryPhone, Url, SalesAccountProfile, Classification, AdditionalName, Relationship, SellToAddress, and AdditionalIdentifier.
To update or to create a customer contact, use the following target import objects: ContactPersonProfile, ContactJob, ContactPrimaryAddress, ContactEmail, ContactPrimaryPhone, ContactMobile, ContactInstantMessenger, and ContactFax. All contact-related entities, such as primary phone or e-mail, include a child entity that captures the contact preference. For example, the Primary Phone Contact Preference entity captures the contact preference of the legal entity for the contact method primary phone.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion Applications CRM Application Composer extensibility features for the customer.
To access the reference guide files for the customer target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Customer File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
OrganizationProfile |
Includes detailed customer information, such as, organization name and organization type. Sample attributes: OrganizationSize, UniqueNameAlias, CeoName, and CertificationLevel. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_PARTIES_T_Reference |
|
PrimaryPhone |
Indicates the primary phone number of the customer. If the customer has multiple phone numbers, one of the phone numbers is designated as the primary phone number. Sample attributes: PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, and PhoneNumber. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
Classification |
Includes classification information for a customer. Classification allows you to categorize entities such as parties, projects, tasks, and orders as hierarchies. Sample attributes: ClassificationCode, ClassificationCategory, PrimaryFlag, and Rank. Reference attributes: ClassificationOrigSystem and ClassificationOrigSystemReference. |
HZ_IMP_CLASSIFICS_T_Reference |
|
AdditionalName |
Indicates alternative name of a customer. Sample attributes: Additional Name, Additional Name Type, and GlobalPreferredNameFlag. Reference attributes: AdditionalNameOrigSystem and AdditionalNameOrigSystemReference. |
HZ_IMP_ADDTNLPARTYNAMES_T_Reference |
|
Fax |
Indicates the fax of the customer. Sample attributes: PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, and PhoneNumber. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
FaxContactPreference |
Indicates the customer preference about being contacted through Fax. Sample attributes: PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
Url |
Indicates the Url of the customer organization. Sample attributes: ContactPointType, PrimaryFlag, Url, and WebType. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
SalesAccountProfile |
Includes detailed information about a customer sales account. A sales account is a specific sell-to entity within a given customer. A customer can have multiple sales accounts and sales account profiles. Sample attributes: AccountDirectorId, NamedAccountFlag, and AssgnExceptionFlag. Reference attributes: OwnerOrigSystem and OwnerOrigSystemReference. |
ZCA_IMP_SALES_ACCOUNTS_Reference |
|
SellToAddress |
Includes customer addresses and party sites information. If party site usage of an address is not defined, then the import process sets it to Sell-To. If there are multiple addresses without party site usage information, then the import process designates one of the addresses as the Sell-To address. Sample attributes: Address1, Address2, City, Country, County, and State. Reference attributes for location: LocationOrigSystem, LocationOrigSystemReference, and LocationId1. Reference attributes for party sites: SiteOrigSystem, SiteOrigSystemReference, and PartysiteId1. Reference attributes for party site use: SiteuseOrigSystem, SiteuseOrigSystemRef, and PartySiteUseId. |
HZ_IMP_PARTYSITES_T_Reference |
|
AdditionalIdentifier |
Includes detailed information about an additional identifier for the customer. Sample attributes: IdentifierValue, IdentifierType, Country, and IssuingAuthorityName. Reference attributes: IdentifierValue, AdditionaldentifierOrigSystem, and AdditionalldentifierOrigSystemReference. |
HZ_IMP_ADDTNLPARTYIDS_T_Reference |
|
Relationship |
Includes information about a relationship between the customer and another entity, such as an organization or a person. You must enter a relationship code in the RelationshipCode column, when creating a relationship. Sample attributes: RelationshipCode, RelationshipType, and DependentFlag. Reference attributes: RelationshipID, RelOrigSystem and RelOrigSystemReference. |
HZ_IMP_RELSHIPS_T_Reference |
|
ContactPersonProfile |
Includes detailed information, such as, person name, relationship type, and marital status, of a customer contact. Sample attributes: Gender, MaritalStatus, PartyType, PartyUsageCode, PersonFirstName, and PersonLastName. Reference attributes: PartyID, PartyOrigSystem, PartyOrigSystemReference, RelOrigSystem, RelOrigSystemReference, and RelationshipId. |
HZ_IMP_RELSHIPS_T_Reference |
|
ContactAdditionalName |
Indicates alternative name of a customer contact. Sample attributes: NameId, PersonFirstName, PersonLastName, and PersonTitle. Reference attributes: AdditionalNameOrigSystem and AdditionalNameOrigSystemReference. |
HZ_IMP_ADDTNLPARTYNAMES_T_Reference |
|
ContactEmail |
Indicates the e-mail of the customer contact. Sample attributes: ContactPointPurpose, EmailAddress, and StartDate. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactInstantMessenger |
Indicates the instant messenger or social networking information of a customer contact. Sample attributes: ContactPointPurpose, EndDate, InstantMessagingAddress, and InstantMessengerType. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactPrimaryAddress |
Indicates the primary address of a customer contact. If the contact has multiple addresses, one of the addresses is designated as the primary address. Sample attributes: Address1, Address2, City, Country, County, and State. Reference attributes for loaction: LocationOrigSystem, LocationOrigSystemReference, and LocationId1. Reference attributes or party sites: SiteOrigSystem, SiteOrigSystemReference, and PartysiteId1. |
HZ_IMP_PARTYSITES_T_Reference |
|
ContactFax |
Indicates the fax of the customer contact. Sample attributes: ContactPointPurpose, ContactPointType, PhoneAreaCode, PhoneCountryCode, and PhoneExtension. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactJob |
Includes job information of a customer contact. Sample attributes: Comments, ContactNumber, Department, DepartmentCode, and JobTitleCode. Reference attributes: RelationshipID, RelOrigSystem and RelOrigSystemReference |
HZ_IMP_CONTACTS_T_Reference |
|
ContactMobile |
Indicates the mobile number of a customer contact. Sample attributes: ContactPointPurpose, ContactPointType, PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, PhoneNumber, and PrimaryFlag. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactPrimaryPhone |
Indicates the primary phone number of the customer contact. If the customer has multiple phone numbers, one of the phone numbers is designated as the primary phone number. Sample attributes: ContactPointPurpose, ContactPointType, PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, PhoneNumber, and PrimaryFlag. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
PrimaryPhoneContactPreference |
Indicates the customer contact preference about being contacted through phone. Sample attributes: PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactEmailContactPreference |
Indicates the customer contact preference about being contacted through e-mail. Sample attributes: PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactFaxContactPreference |
Indicates the customer contact preference about being contacted through Fax. Sample attributes: PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactMobileContactPreference |
Indicates the customer contact preference about being contacted through mobile phone. Sample attributes: PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactPrimaryAddressContactPreference |
Indicates the customer contact preference about being contacted at the primary address. Sample attributes: PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
ContactPrimaryPhoneContactPreference |
Indicates the customer contact preference about being contacted through the primary phone number. Sample attributes: PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
This topic explains how to prepare and import employee resource data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
Employee resources are employees within the deploying company who can be assigned work objects. You must create or import employee resources before you can associate them with resource organizations, resource teams, or work objects. You enter your employee resource information using the Setup and Maintenance work area, Manage Resources task, or you can import data to create new or update existing employee resources.
Consider the following questions when importing your data:
How does your legacy system or source system represent the employee resource compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your employee resource data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for an employee resource.
In Oracle Fusion Applications, one table stores the employee resource definition and other tables optionally store profile details for that employee resource. Profile details for a resource include information about an employee resource's organization and team memberships.
The following figure illustrates the structure of the Employee Resource object.
The worker profile contains basic information about the employee resource, such as the employee resource's primary address and resource profile details.
To facilitate the import of employee resources, Oracle Fusion Applications incorporate the structure of the employee resource into import objects. The import object for the employee resource is Employee Resource.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the employee resource.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Employee Resource |
Employee Resource Import Objects: How They Work Together |
Hint: You can use the keyword importing employee resources to search for related topics in Oracle Fusion Applications Help.
If you need to extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the employee resource business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a new employee resource, you import the Employee Resource import object.
You must be assigned the Master Data Management Administrator job role to access and submit the import activities for employee resources.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with either the Master Data Management Administrator job role can also navigate to the Manage Resources work area to view the imported employee resources.
Employee resources are employees to whom you can assign work objects, for example, service agents, sales managers, and so on. You can import all your employee resource information using the Employee Resource import object. This topic describes this import object.
This topic introduces the following:
Target import object concepts
Target objects for the Employee Resource import object
Target import object attributes
Target import object attribute reference guide files
The Employee Resource import object is used to import an employee resource's worker profile information, such as first name, last name, address, and so on, and the employee resource's resource profile information, such as resource organization and resource team memberships. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects included in the Employee Resource import object are grouped into information about the employee resource's profile and the employee resource's address information. The Worker profile is the target import object containing attributes to import information about the employee resource.
When updating an existing employee resource, you must provide the parent reference information of the existing employee resource. When importing an employee resource's resource team information, you must provide relationship reference information in addition to the parent reference, because an employee resource can belong to more than one team simultaneously.
To update the information for an existing employee resource or to create an employee resource record, you can import employee resource profile information and addresses. The following target import objects are for creating and updating employee resource information: WorkerProfile, ResourceProfile, and PrimaryAddress.
To update or create an employee resource's resource profile, use the following target import objects: ResourceOrganizationMembership and ResourceTeamMembership.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for the marketing response.
To access the reference guide files for the employee resource's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Employee Resource File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
WorkerProfile |
Contains information that identifies an employee. Sample attributes: ResourceProfile and PrimaryAddress. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HRC_LOADER_BATCH_LINES_Reference |
|
ResourceProfile |
Contains information about a resource. Sample attributes: PartyId, FirstName, LastName, Department, and JobCode. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_RESOURCES_Reference |
|
PrimaryAddress |
Indicates the address of a resource. If the resource has multiple addresses, then the first address is designated as the primary address. Sample attributes: Address1, Address2, City, Country, County, State, and PostalCode. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_PARTYSITES_T_Reference |
|
ResourceOrganizationMembership |
Contains the employee resource's resource organization membership information. Sample attributes: RequestId, PartyId, ParentOrganizationName, OrganizationId, OrganizationName, and OrganizationUsage. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_GROUP_MEMBERS_Reference |
|
ResourceTeamMembership |
Contains the employee resource's resource team membership information. Sample attributes: RequestId, TeamMemberId, TeamId, and TeamNumber. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_TEAM_MEMBERS_Reference |
This topic describes the tasks you must perform to import geography information. A geography is any region with a boundary around it, regardless of its size. It might be a state, a country, a city, a county, or a ward. You must create or import geographies before you can associate them with custom zones and addresses.
Consider the following questions when importing your data:
How does your legacy system or source system represent the geography compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your geography data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a geography.
You must import a separate country structure import object for each country. Each of these import objects must contain the geography types that are used in the country's structure, organized in a hierarchy using geography level numbers. For example, if you are importing the country structure of Australia, the country structure could be the following: 1: Country, 2: State, 3: County, 4: Town, 5: ZIP.
To facilitate the import of geographies, Oracle Fusion Applications incorporate the structure of the geography into import objects. The import object for the geography is ImpGeography.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the geography.
A good understanding of the attribute details of the import objects is critical to preparing your import data. For information about the Oracle Fusion Applications attributes, see the Oracle Enterprise Repository. The reference files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
ImpGeography |
Geography Import Objects: How They Work Together |
Hint: You can use the keyword importing geographies to search for related topics in Oracle Fusion Applications Help.
Oracle Fusion Applications do not support extensible attributes for geographies. You can only import data for attributes provided by Oracle Fusion Applications.
For the geography business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a new geography, you import the Geography object. You must be assigned the Master Data Management Administrator job role to access and submit the import activities for geographies.
When importing geography information, you must provide the parent reference information for all parent levels for the entity.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with the Master Data Management Administrator job role can also navigate to the Manage Geographies work area to view the imported geographies.
This topic describes the Geography import object. You use the Geography import object to import geography information.
This topic introduces the following:
Target import object concepts
Target objects for the Geography import object
Target import object attributes
Target import object attribute reference guide files
The Geography import object is used to import geography hierarchy information to create or update the geography data of a country. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects in the Geography import object contain information about the geography hierarchy. When updating an existing geography, you must provide the parent reference information of the existing geography, which connects the geography to the country of which it is a part.
Use the ImpGeography target import object to create and update geography information.
Note
Before you import geography data for a country, you must define the country's geography structure.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
To access the reference guide files for the geography's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
For detailed information on importing geographies using file-based import, refer to Document No. 1481758.1, Importing Master Reference Geography Data, on the Oracle Support site.
The following table lists the reference guide files that are available from the Documentation tab for the Geography File-Based Data Import asset.
|
Target Import Object |
Description |
Attribute Reference Guide File Names |
|---|---|---|
|
ImpGeography |
Contains information that captures a country's geography hierarchy details. Sample attributes: CountryCode, GeoDataProvider, GeographyType, PrimaryGeographyCode, PrimaryGeographyCodeType, and PrimaryGeographyName. Reference attribute: CountryCode |
HZ_IMP_GEOGRAPHIES_T_Reference |
This topic explains how to prepare and import group customer data from an external data source into Oracle Fusion Applications, using the File-Based Data Import feature.
A group customer is a party consisting of a collection of persons and organizations. A group, similar to a person or organization, can enter into a business relationship with other parties and can be assigned to opportunities and leads. A group can have members of party type person or organization. You can maintain group customers information in Oracle Fusion Applications CRM to create leads and opportunities for a group, or capture information about a group to know them better. However, maintaining this information may not let you assign all sales and marketing activities to a group.
You must consider the following questions before importing group customer information:
How does your legacy or source system represent the group customer information compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map your existing data values to the Group Customer import object?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do I verify my imported data?
You must understand how your group customer data corresponds with the data in Oracle Fusion Applications to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a group customer.
The Oracle Fusion Applications Group Customer structure is hierarchical. At the top level is the group profile, which must exist before you can import lower-level components, such as classifications, additional names, additional identifier, and members. These child entities can have other entities as their child entities. This hierarchical structure supports one-to-many relationships between the components that make up the group customer.
The following figure shows the Group Customer import object and its child entities.
The group customer profile contains basic information about the group customer, such as the group name, group type, and the group-party usage. For each group customer, you can assign classifications, members, relationships, additional identifier, and additional names.
Note
All entities referring to contact information, such as primary phone or e-mail, include a child entity that captures the contact preference. For example, the Phone Contact Preference entity captures the contact preference of the group for the phone contact method.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the group customer.
A good understanding of the import objects and attribute details is critical to preparing your import data. Oracle Fusion Applications attribute details are available for your reference in the Oracle Enterprise Repository. The reference guide files contain descriptions, default values, and validations for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correspond to a choice list in Oracle Fusion Applications, then the validation information for that attribute will provide the task name in the Setup and Maintenance work area where you can define your values.
If you want to extend the Oracle Fusion Applications object data to import your legacy or source data, then you must use Oracle Fusion Applications CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the group customer business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks that are required to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. An import activity defines the instructions for processing import data, including the source file, import mapping from the source file to the Oracle Fusion Applications object and attribute, and the import schedule.
When importing group customer information, you must first import the basic group customer profile information, followed by the child entities for the group customer. When importing child entities, you must provide the parent reference information for all parent levels for the entity. You must provide the PartyOrigSystem and PartyOrigSystemReference of the group customer when importing contacts for the group customer. PartyOrigSystem is the source system code that identifies the source of the information being imported. PartyOrigSystemReference is unique for each row of data within a single import, and is a combination of PartyOrigSystem and a unique reference. For example, you first import basic profile details, such as first name, last name, party type, and party usage. You then import contact information, such as phone, address, contact points, and fax for the group customer.
Oracle Fusion Applications provide File-Based Import activity reports, which you can use to verify imported data. You can view the list of import activities from the Manage Import Activities page. You can verify the status of the import activity by clicking the Status column for your import activity. Alternatively, you can also navigate to the Party Center work area to view the customer information that you have imported.
The Group Customer import object allows you to import group customers, their basic information, and members of the group. This topic describes the Group Customer import object and introduces the following:
Target import object concepts
Target objects for the Group Customer import object
Target import object attributes
Target import object attribute reference guide files for evaluating and mapping source file data
The Group Customer import object imports group customers and its members. The Group Customer import object is split into separate target import objects for organizing the individual attributes for the different aspects of the group customer. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects in the Group Customer import object are grouped into information about the group customer and information about the member. The group profile is the target import object containing attributes to import information about the group customer. You can have multiple members associated with a group customer. You can assign only an organization or a person as a member of a group. You cannot assign a group as a member of another group.
When updating an existing group customer with additional information, you must provide the parent reference information for the existing group customer. When importing contacts or contact information for a group customer, you must provide relationship reference information in addition to the parent reference. When importing information about a member, you must refer to the specific relationship that you want to import information for. For example, you might want to import information for John Smith the employee or John Smith the board member. If you do not include the reference information for a relationship, then the import process will create a relationship.
To update the information for an existing group customer or to create a group customer record, you can import group customer profile information, addresses, and contact points, such as phone and fax. The following target import objects are for creating and updating the group customer information: GroupProfile, Fax, Mobile, Phone, e-mail, InstantMessenger, Relationship, Member, Address, Classification, AdditionalName, and AdditionalIdentifier.
All contact-related entities, such phone or e-mail, include a child entity that captures the contact preference. For example, the Phone Contact Preference entity captures the contact preference of the group customer for the contact method primary phone. Additionally, the Address import object for a group customer includes another child entity, AddressPurpose, that captures the purpose of the current group customer address.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion Applications CRM Application Composer extensibility features for the group customer.
To access the reference guide files for the group customer target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Group Customer File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
GroupProfile |
Includes detailed group customer information, such as, group name and group type. The default party usage for a group customer is SALES_PROSPECT. Sample attributes: AnnualIncome, NumOfDependents, MedianAge, and CertificationLevel. Reference attributes: PartyOrigSystem, PartyOrigSystemReference, and PartyId. |
HZ_IMP_PARTIES_T_Reference |
|
Relationship |
Includes information about the relationship between the group customer and the group member. You must enter a relationship code in the RelationshipCode column, when creating a relationship. Sample attributes: RelationshipCode and RelationshipType. Reference attributes: RelOrigSystem RelationshipID, and RelOrigSystemReference. |
HZ_IMP_RELSHIPS_T |
|
Member |
Includes information about the group customer member. Sample attributes: ObjectKey and SubjectId. Reference attributes: RelOrigSystem RelationshipID, and RelOrigSystemReference. |
HZ_IMP_RELSHIPS_T |
|
Classification |
Includes classification information for a group customer. Classification allows you to categorize entities such as parties, projects, tasks, and orders as hierarchies. Sample attributes: ClassificationCode, ClassificationCategory, PrimaryFlag, and Rank. Reference Attributes: ClassificationOrigSystem and ClassificationOrigSystemReference. |
HZ_IMP_CLASSIFICS_T |
|
AdditionalIdentifier |
Includes detailed information about an additional identifier for the group customer. Sample attributes: IdentifierValue, IdentifierType, Country, and IssuingAuthorityName. Reference attributes: IdentifierValue, AdditionaldentifierOrigSystem, and AdditionalldentifierOrigSystemReference. |
HZ_IMP_ADDTNLPARTYID_T |
|
AdditionalName |
Indicates alternative name of a group customer. Sample attributes: Additional Name, Additional Name Type, and GlobalPreferredNameFlag. Reference Attributes: AdditionalNameOrigSystem and AdditionalNameOrigSystemReference. |
HZ_IMP_ADDTNLPARTYNAMES_T |
|
Url |
Indicates the Url of the group customer. Sample attributes: ContactPointType, PrimaryFlag, Url, and WebType. Reference attributes: CpOrigSystem and CpOrigSystemReference |
HZ_IMP_CONTACTPTS_T_Reference |
|
InstantMessenger |
Indicates the instant messenger or social networking information of a customer contact. Sample attributes: ContactPointPurpose, EndDate, InstantMessagingAddress, and InstantMessengerType. Reference attributes: CpOrigSystem, CpOrigSystemReference, and Objectkey. |
HZ_IMP_CONTACTPTS_T_Reference |
|
Fax |
Indicates the fax of the group customer. Sample attributes: PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, and PhoneNumber. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
FaxContactPreference |
Indicates the group customer preference about being contacted through fax. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
Mobile |
Indicates the mobile number of group customer. Sample attributes: ContactPointPurpose, ContactPointType, PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, PhoneNumber, and PrimaryFlag. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
MobileContactPreference |
Indicates the group customer's preference about being contacted through mobile phone. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
Phone |
Indicates the primary phone number of the group customer. If the group has multiple phone numbers, one of the phone numbers is designated as the primary phone number. Sample attributes: PhoneAreaCode, PhoneCountryCode, PhoneExtension, PhoneLineType, and PhoneNumber. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
PrimaryPhoneContactPreference |
Indicates the group customer's preference about being contacted through phone. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
|
Indicates the e-mail of the group customer. Sample attributes: ContactPointPurpose, EmailAddress, and StartDate. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPTS_T_Reference |
|
EmailContactPreference |
Indicates the group customer's preference about being contacted through e-mail. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem and CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
Address |
Indicates the address of a group customer. If the group has multiple addresses, one of the addresses is designated as the primary address. Sample attributes: Address1, Address2, City, Country, County, State, and PostalCode. Reference attributes for location: LocationOrigSystem, LocationOrigSystemReference, and LocationId1. Reference attributes or party sites: SiteOrigSystem, SiteOrigSystemReference, and PartysiteId1. |
HZ_IMP_LOCATIONS_T, HZ_IMP_PARTYSITES_T |
|
AddressContactPreference |
Indicates the group customer's preference about being contacted at the primary address. Sample attributes: ContactType, PreferenceCode, PreferenceEndDate, PreferenceStartDate, and ReasonCode. Reference attributes: CpOrigSystem, CpOrigSystemReference. |
HZ_IMP_CONTACTPREFS_Reference |
|
AddressPurpose |
Indicates the purpose of a group customer's address. Sample attributes: SiteUseType, EndDate, and StartDate. Reference attributes: SiteOrigSystem and SiteOrigSystemReference. |
HZ_IMP_PARTYSITEUSES_T |
This topic explains how to prepare and import Interaction data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
An interaction is a business object that is used to record interactions between your internal resources and external contacts, including references to specific objects of interest such as a sales lead or an opportunity. You enter your interaction information within the same user interface as the associated business object or sales account, or you can import data to create new or update existing interactions.
Consider the following questions when importing your data:
How does your legacy system or source system represent the interaction compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your interaction data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. To start, you must understand how Oracle Fusion Applications represent the structure of an interaction.
In Oracle Fusion Applications, a single interaction contains information such as the date and time, customer, description, and outcome. Additionally, a single interaction can include one or more internal and external participants and one or more references to the objects of interest. You can attach a file to your interaction using the Attachment feature.
To facilitate the import of interactions, Oracle Fusion Applications incorporates the structure of the interaction into a single import object with the name of Interaction.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the interaction.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Interaction |
Interaction Import Objects: How They Work Together |
Hint: You can use the keyword importing interactions to search for related topics in Oracle Fusion Applications Help.
If you need to extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the interaction business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, imports the data into the application destination tables, and associates any attachments. The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import object, to create source-file mappings, and to schedule the import activities.
To associate interactions with internal and external participants and business objects, you must include in your source file the unique internal identifier for each participant and business object. Therefore, the associated participants and business objects must be entered or imported before submitting the Interaction import activity. The File-Based Data Import Activity log file typically includes the internal identifier for internal resources, external parties, and business objects imported using the File-Based Data Import feature. Optionally, you can obtain the internal identifier for existing resources, parties, and business objects by using the Manage Bulk Data Export, Schedule Export Processes Setup and Maintenance task.
Importing attachments is supported for the Interaction import object, however, you are limited to one attachment per interaction. You include the attachment file name in your source file along with the other data about the interaction. You select the files when defining your Interaction File-Based Import Activity for import processing.
You must be assigned the Customer Relationship Management Application Administrator to access and submit the import activities for interactions.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with access to the associated business objects or sales accounts can also view the interactions.
You use the Interaction import object to submit a file-based import activity to import your Interactions. This topic describes the following:
Target import object concepts
Target objects for the Interaction import object
Target import object attributes
Target object attribute reference guide files
The Interaction import object is used to import records containing information about interactions between your internal resources and external contacts, including references to specific objects of interest such as a sales lead or an opportunity.
The Interaction import object is split into separate target import objects for organizing the individual attributes of the Interaction and to manage the one-to-many relationship structure. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects in the Interaction import object are grouped into information about the interaction, references to the internal and external participants, and references to the objects of interest. The following figure shows the target import objects included in the Interaction import object, each represented by their familiar name and their formal target import object name, shown in parentheses.
The InteractionImport target object includes the attributes for the majority of information captured for an interaction, such as the date and time, customer, description, and outcome. The InteractionParticipantImport target object includes the attributes to associate internal resources and external contacts who participated in the interaction. When interactions pertain to specific business objects, such as a sales lead or opportunity, the attributes pertaining to the association of the business objects to the interaction are included in the InteractionAssociationImport target object.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for the Interaction.
To access the reference guide files for the Interaction target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Interaction File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
InteractionImport |
Interaction information |
ZMM_INTER_INTERACTIONS_Reference |
|
InteractionAssociationImport |
Interaction business objects |
ZMM_INTER_ASSOCIATIONS_Reference |
|
InteractionParticipantImport |
Interaction participants |
ZMM_INTER_PARTICIPANTS_Reference |
This topic explains how to prepare and import marketing budget data from an external data source into Oracle Fusion Applications using the File-Base Data Import feature.
A marketing budget is a business object that is used to manage funds set aside to fund partner incentives. You enter your budget information using the Budgets work area or you can import data to create or update marketing budgets.
Consider the following questions when importing your data:
How does your legacy system or source system represent the budget compared to how Oracle Fusion Applications represent same data?
Do you have to configure values in Oracle Fusion to map to your data values?
Do you have to customize Oracle Fusion to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your marketing budget data corresponds with the data in Oracle Fusion Applications to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a marketing budget.
In Oracle Fusion Applications, the marketing budget structure is hierarchical. At the top level is the marketing budget summary, which must exist before you can import lower level components such as notes and attachments. This hierarchical structure supports one-to-many relationships between the components that make up the marketing budget. For example, a marketing budget can have many notes.
The marketing budget summary contains basic information about the budget such as the type, start and end dates, and budget amount. For each marketing budget, you can post notes and attach documents relevant to the budget.
To facilitate the import of marketing budgets, Oracle Fusion Applications incorporate the structure of the promotion into import objects. The import objects for the marketing budget are shown in the following table.
|
Import Objects |
Structure |
|---|---|
|
Marketing Budget |
Marketing Budget |
|
Note |
Note |
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and so support one-to-many relationships between the structural components that make up the marketing budget.
A good understanding of the attribute details of the import objects is critical to your import data. The reference guide files contain descriptions, logic used to select default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Marketing Budget |
Marketing Budget Import Objects and Attributes: How They Work Together |
|
Note |
Note Import Objects and Attributes: How They Work Together |
Hint: You can use the keyword "importing marketing budgets" to search for related topics in Oracle Fusion Applications Help.
If you need to extend the Oracle Fusion object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both custom attributes and the standard import object attributes.
For the marketing budget business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a marketing budget, you first import the Marketing Budget object, follow by subsequent import activities for each of the other import objects (in this case, notes). The exception is attachments, which are imported by including the file names in your source file for the Marketing Budget object and selecting the files when defining the import activity.
You must be assigned the Channel Account Manager, Channel Sales Director, or Channel Sales Manager job role to access and submit the import activities for marketing budgets.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with the Marketing Budget Maintenance Duty role can also navigate to the Budgets work area to view the imported marketing budgets. Oracle Fusion Applications assign this role to the following predefined job roles: Channel Account Manager, Channel Sales Director, and Channel Sales Manager.
You use two main import objects, Marketing Budget and Note, when you submit a file-based import activity to import your marketing budgets. This topic describes the Marketing Budget import object. It introduces the following:
Target import object concepts
Target objects for the Marketing Budget import object
Target import object attributes
Target object attribute reference guide files
The Marketing Budget import object is used to import marketing budgets. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import object in the Marketing Budget import object is ImportBudgets1. The target import object includes information about the budget, such as the budget type, initial amount, currency, and fund request submission deadlines.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for the marketing response.
To access the reference guide files for the marketing budget's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Marketing Budget File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
ImportBudgets1 |
Marketing budgets of interest |
MKT_IMP_BDT_BUDGETS_Reference |
This topic explains how to prepare and import marketing campaign data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
A marketing campaign is a business object that is used to capture the plan and design that allows a marketer to achieve a specific marketing goal or objective through customer interaction, strategic advertisements, and lead generation. You enter your campaign information using the Campaigns work area or you can import data to create or update campaigns.
Consider the following questions when importing your data:
How does your legacy or source system represent the marketing campaign compared to how Oracle Fusion Applications represent the same data?
Do you need to configure values in Oracle Fusion Applications to map to your data values?
Do you need to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your marketing campaign data corresponds with the data in Oracle Fusion Applications to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a campaign.
In Oracle Fusion Applications, the marketing campaign structure is hierarchical. At the top level is the campaign summary, which must exist before you can import lower level components such as team members, tasks, and stages. This hierarchical structure supports one-to-many relationships between the components that make up the campaign. For example, a campaign can have many team members, tasks, and stages.
The campaign summary contains basic information about the campaign such as the planned dates, owner, and overall purpose. For each campaign, you can assign team members, assign tasks and due dates, attach documents relevant to the campaign, and post notes for the campaign or for specific tasks.
Each campaign can have one or more stages. A stage is a unit of the marketing campaign design representing a single purpose that contributes to the overall objective of the campaign. The stage purpose can be for events, advertising, and outbound communication, such as e-mail, direct mail, or automated lead generation. Campaign members are the intended recipients of the marketing message and lead follow-up.
To facilitate the import of marketing campaigns, Oracle Fusion Applications incorporate the structure of the campaign into import objects. The import objects for the marketing campaign are shown in the following table.
|
Import Objects |
Structure |
|---|---|
|
Campaign |
Campaign Summary Team Members Attachments |
|
Interaction Marketing Activity |
Outbound Communication Stages |
|
Event Marketing Activity |
Event Stages |
|
Advertising Marketing Activity |
Advertising Stages |
|
Campaign Members |
Campaign Members |
|
Task |
Team Tasks Notes |
|
Note |
Notes |
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the marketing campaign.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used to select default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Campaign |
Campaign Import Objects and Attributes: How They Work Together |
|
Campaign Members |
Campaign Members Import Object and Attributes: How They Work Together |
|
Task |
Task Import Object and Attributes: How They Work Together |
|
Note |
Note Import Object and Attributes: How They Work Together |
|
Interaction Marketing Activity |
Interaction Marketing Activity Import Object and Attributes: How They Work Together |
|
Event Marketing Activity |
Event Import Object and Attributes: How They Work Together |
|
Advertising Marketing Activity |
Advertising Marketing Activity Import Object and Attributes: How They Work Together |
Hint: You can use the keyword "importing campaigns" to search for related topics in Oracle Fusion Applications Help.
If you need to extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both custom attributes and the standard import object attributes.
For the campaign business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables based on your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks required to configure the import objects, to create source file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a marketing campaign, you first import the Campaign object, followed by subsequent import activities for each of the other import objects. The exception is attachments, which are imported by including the file names in your source file for the Campaign object and selecting the files when defining the import activity.
You must be assigned the Customer Relationship Management Application Administrator or the Marketing Operations Manager job role to access and submit the import activities for marketing campaigns.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with the Marketing Analysis Duty role can also navigate to the Campaigns work area to view the imported campaigns. Oracle Fusion assigns this role to the following, predefined job roles: Marketing VP, Corporate Marketing Manager, Marketing Operations Manager, and Marketing Analyst.
You use the following main import objects when you submit file-based import activities to import your marketing campaigns:
Campaign
Campaign Members
Advertising Marketing Activity
Event Marketing Activity
Interaction Marketing Activity
This topic describes each of these import objects . It introduces the following:
Target import object concepts
Target objects for the campaign import objects
Target import object attributes
Target object attribute reference guide files
Two additional import objects, Note and Task, are described in separate topics.
The campaign import objects are used to import marketing campaign information. The main import objects are split into separate target import objects for organizing the individual attributes of the different aspects of the campaign. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The Campaign import object is broken down into two target import objects: Campaign Summary and Campaign Team. The Campaign Summary includes three stages: Outbound Communications, Event, and Advertising, each of which includes its own import object: Interaction Marketing Activity, Event Marketing Activity, and Advertising Marketing Activity, respectively. The following figure shows the hierarchy of the import objects and target import objects for the marketing campaign, each represented by their familiar name and their formal target import object name, shown in parentheses.
A single campaign summary includes specific information about the stages of the campaign and the marketing team members. The multiple campaign stages can include information about outbound communications and the campaign members to whom the communications are sent, events associated with the campaign, and campaign advertising.
The Interaction Marketing Activity import object includes two target import objects: InteractionStage and AllocationActivity.
The Event Marketing Activity import object includes two target import objects: EventStage and EventActivity.
The Advertising Marketing Activity import object includes two target import objects: AdvertisingStage and AdvertisingActivity.
The Campaign Members import object includes information about campaign members to whom the communications are sent, and includes a single target import object, StageMembers. You must import the Interaction Marketing Activity import object before importing the Campaign Members import object.
The Campaign import object includes one additional target import object, Campaign Team, which includes information about the marketing team members associated with the campaign.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for the marketing response.
To access the reference guide files for the campaign's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Campaign File-Based Data Import asset.
|
Import Object |
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|---|
|
Advertising Marketing Activity |
AdvertisingStage |
The association with the campaign and the advertising activity dates. |
MKT_IMP_STAGES_Reference |
|
Advertising Marketing Activity |
AdvertisingActivity |
The advertising treatment. |
MKT_IMP_ADVTG_ACTIVITY_Reference |
|
Campaign |
Campaigns |
Campaigns of interest. |
MKT_IMP_CAMPAIGNS_Reference |
|
Campaign |
CampaignTeam |
Marketing team members associated with the campaign. |
MKT_IMP_CAMP_TEAM_Reference |
|
Campaign Members |
StageMembers |
Campaign members to whom outbound communications are sent. |
MKT_IMP_STG_MEMBERS_Reference |
|
Event Marketing Activity |
EventStage |
The association with the campaign and the event activity dates. |
MKT_IMP_STAGES_Reference |
|
Event Marketing Activity |
EventActivity |
The event venue information. |
MKT_IMP_EVT_ACTIVITY_Reference |
|
Interaction Marketing Activity |
InteractionStage |
The association with the campaign and the outbound communication activity dates. |
MKT_IMP_STAGES_Reference |
|
Interaction Marketing Activity |
AllocationActivity |
Information about the allocation of treatments to audiences. |
MKT_IMP_ALLOC_ACTIVITY_Reference |
This topic explains how to prepare and import marketing response data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
A marketing response is a business object that is used to record the reaction of a prospect or customer to a marketing activity. You enter your response information using the Response Management work area or you can import data to create or update responses.
Consider the following questions when importing your data:
How does your legacy or source system represent the response compared to how Oracle Fusion Applications represent the same data?
Do you need to configure values in Oracle Fusion Applications to map to your data values?
Do you need to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your response data corresponds with the data in Oracle Fusion Applications to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a marketing response.
An Oracle Fusion marketing response consists of two import objects: Response and Notes. You import your marketing response, followed by a subsequent import activity for any associated notes.
The Oracle Fusion marketing response structure is hierarchical. At the top level is the response summary, under which are lower level components such as products, surveys, and notes. This hierarchical structure supports one-to-many relationships between the components that make up the response. For example, a response can have many products, surveys, and notes.
The response summary contains basic information about the response such as the response method, marketing source code, and responder information. For each response, you can associate products and surveys, attach documents relevant to the response, and post notes for the response.
To facilitate the import of responses, Oracle Fusion Applications incorporate the structure of the response into import objects. The import objects for the marketing response are shown in the following table.
|
Import Objects |
Structure |
|---|---|
|
Response |
Response Summary and Responder Details Note You can create customers, consumers, and contacts or associate existing ones to capture your responder information. Products Surveys Attachments |
|
Note |
Notes Attachments |
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the response.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used to select default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Response |
Response Import Object and Attributes: How They Work Together |
|
Note |
Note Import Object and Attributes: How They Work Together |
Hint: You can use the keyword "importing responses" to search for related topics in Oracle Fusion Applications Help.
If you need to extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both custom attributes and the standard import object attributes.
For the response business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source file mappings, and to schedule the import activities. You submit file-based import objects, create source file mappings, and schedule the import activities. You submit file-based import activities for each import object. When creating a marketing response, you first import the Response object, followed by subsequent import activities for any associated notes. The exception is attachments, which are imported by including the file names in your source file for the Response object and selecting the files when defining the import activity.
You must be assigned the Marketing Operations Manager or the Customer Relationship Management Application Administrator job role to access and submit the import activities for marketing responses.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with the Marketing Response Data Review Duty role can also navigate to the Response Management work area to view the imported responses. Oracle Fusion assigns this role to the following predefined job roles: Marketing VP, Corporate Marketing Manager, Marketing Operations Manager, and Marketing Analyst.
You use two main import objects, Response and Note, when you submit a file-based import activity to import your marketing responses. This topic describes the Response import object. It introduces the following:
Target import object concepts
Target objects for the Response import object
Target import object attributes
Target object attribute reference guide files
The Response import object is used to import marketing responses and information to create or update associated organization or person information for the customer, consumer, or contact who responded. The Response import object is split into separate target import objects for organizing the individual attributes of the different aspects of the response and respondent. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects in the Response import object are generally grouped into information about the response and information about the respondent. The respondent information is further broken down, depending on whether the respondent is a customer organization, a person who is a consumer, or a person who is a contact of the customer or consumer. The following figure shows the grouping and the target import objects included in the Response import object, each represented by their familiar name and their formal target import object name, shown in parentheses.
A single response includes specific information about how the customer, consumer, or contact responded to a marketing activity. The response can include one or more products of interest and survey questions and answers, such as a telemarketer script. The Response, ResponseProducts, and ResponseSurvey target objects include the attributes to import this information for your marketing response.
If the respondent is an organization and an existing customer, then you can associate the customer with the response by using the Response target object. However, if you want to update the information for an existing customer or create a customer record, then you musts use additional target objects to import customer profile information, addresses, and contact points, such as a phone and fax number. The following target import objects are for creating and updating customer information for a respondent: OrganizationProfile, OrganizationAddress, PrimaryPhone, Fax, and Url.
Similarly, you can associate an existing consumer with the response by using the Response target object. To update the information for an existing consumer or create a consumer record, use the following target import objects: PersonProfile, PersonAddress, Email, PrimaryPhone, Mobile, InstantMessenger, and Fax.
To associate an existing contact for the responding consumer or customer with the response, you use the Responses target object. To update or create a contact, use the following target import objects: ContactPersonProfile, ContactJob, ContactPrimaryAddress, ContactEmail, ContactPrimaryPhone, ContactMobile, ContactInstantMessenger, and ContactFax.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for the marketing response.
To access the reference guide files for the response's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Response File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
ResponseProduct |
Response products of interest |
MKT_IMP_RESP_PRODUCT_T_Reference |
|
ResponseSurvey |
Response survey questions and answers |
MKT_IMP_RESP_SVY_LOG_T_Reference |
|
Response |
Response summary and associated respondent information |
MKT_IMP_RESPONSES_T_Reference |
|
OrganizationProfile |
Customer profile information |
HZ_IMP_PARTIES_T_Reference |
|
PersonProfile |
Consumer summary information |
HZ_IMP_PARTIES_T_Reference |
|
ContactPersonProfile |
Contact summary information |
HZ_IMP_RELSHIPS_T_Reference |
|
OrganizationAddress |
Customer address |
HZ_IMP_PARTYSITES_T_Reference |
|
PersonAddress |
Consumer address |
HZ_IMP_PARTYSITES_T_Reference |
|
ContactPrimaryAddress |
Contact address |
HZ_IMP_PARTYSITES_T_Reference |
|
ContactJob |
Contact job information |
HZ_IMP_CONTACTS_T_Reference |
|
PrimaryPhone |
Customer primary phone |
HZ_IMP_CONTACTPTS_T_Reference |
|
PrimaryPhone |
Consumer primary phone |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactPrimaryPhone |
Contact primary phone |
HZ_IMP_CONTACTPTS_T_Reference |
|
Mobile |
Consumer mobile |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactMobile |
Contact mobile |
HZ_IMP_CONTACTPTS_T_Reference |
|
|
Consumer e-mail |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactEmail |
Contact e-mail |
HZ_IMP_CONTACTPTS_T_Reference |
|
InstantMessenger |
Consumer social network |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactInstantMessenger |
Contact social network |
HZ_IMP_CONTACTPTS_T_Reference |
|
Fax |
Customer fax |
HZ_IMP_CONTACTPTS_T_Reference |
|
Fax |
Consumer fax |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactFax |
Contact fax |
HZ_IMP_CONTACTPTS_T_Reference |
|
Url |
Customer Web site URL |
HZ_IMP_CONTACTPTS_T_Reference |
This topic explains how to prepare and import Note data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
A note is a business object that is used to record notes, including references to specific objects of interest such as a sales lead or an opportunity. You enter your note information within the same user interface as the associated object or you can import data to create new notes.
Consider the following when importing notes:
How does your legacy system or source system represent the note compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your note data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a note. In Oracle Fusion Applications, the structure is a single level (non-hierarchical) and contains information about the note such as the note type, text, author, and associated object.
To facilitate the import of notes, Oracle Fusion Applications incorporates all the data elements of the note into a single import object: Note.
Each import object has one or more target import objects. A target import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data. For the Note import object, all the attributes are contained in the ImportNote target object.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To access the reference guide file for the Note's target import object, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com). The following table lists the reference guide file that is available from the Documentation tab for the Note File-Based Data Import asset.
|
Import Object |
Target Import Object |
Reference Guide File Name |
|---|---|---|
|
Note |
NoteImport |
ZMM_IMP_NOTES_Reference |
If you need to extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the note business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables. The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source-file mappings, and to schedule the import activities.
To associate notes with business objects, you must include the unique internal identifier for each business object in your source file. The File-Based Data Import Activity log file typically includes the internal identifier for imported business objects or you can obtain the internal identifier for an existing business object by exporting it using the Manage Bulk Data Export, Schedule Export Processes Setup and Maintenance task.
You must be assigned the Customer Relationship Management Application Administrator to access and submit the import activities for notes.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with access to the associated business objects can view public notes and note authors can view all of their notes.
This topic explains how to prepare and import product group data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
A product group is a business object that groups related products, so that you can work with them together. You can use product groups to create a multilevel hierarchy that can be used as a sales catalog, a rollup hierarchy, or a promotion catalog. For example, you might create a product group named Consumer Electronics that includes all of your consumer electronics products so that customers can browse through all the products in this group in your product catalog.
Consider the following questions when importing your data:
How does your legacy system or source system represent the promotion compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your promotion data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a promotion.
The structure of the Oracle Fusion Applications product group is hierarchical. At the top level is the product group, which must exist before you can associate lower-level components, including products, promotions, and subgroups. A subgroup is another product group that is lower in the hierarchy).
The hierarchical structure of product groups import objects supports one-to-many relationships between the root product group and the subgroups and products for that product group. For example, a product group can have many subgroups and products. The subgroups can have many subgroups and products. The following diagram shows that product groups can contain products or can contain other product groups.
To facilitate the import of product groups, Oracle Fusion has incorporated the structure of the product group into import objects. The import object for the product group is Product Group.
If you want products (also known as items) to be visible in a catalog that is represented by a product group hierarchy, then those products must be imported before the product groups are imported, or they must already exist in the Oracle Fusion Product Information Model. In other words, products must be present in Oracle Fusion before you import the product groups with which those products are associated. The objects of the product group hierarchy do not have to be imported in any specific order. However, you must make sure that all product groups referenced in a product group hierarchy are imported.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the product group.
For information about the Oracle Fusion attributes, see the Oracle Enterprise Repository. The reference files contain descriptions, logic used in choosing default values, and validation information for each of the Oracle Fusion attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion. For example, if you have values in your data that correspond to a choice list in Oracle Fusion, then the validation information for that attribute provides the task name in the setup work area where you can define your values. For additional information including a list of reference file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Product Group |
Product Group Import Object and Attributes: How They Work Together |
If you need to extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the promotion business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a new promotion, you import the Promotion object.
You must be assigned the Sales Catalog Administrator or Customer Relationship Management Application Administrator job role to access and submit the import activities for product groups.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with either the Customer Relationship Management Application Administrator or Marketing Operations Manager job role can also navigate to the Product Group work area to view the imported product groups.
You use one main import object, Product Group, when you submit a file-based import activity to import your product groups. This topic describes the Product Group import object. It introduces the following:
Target import object concepts
Target objects for the Product Group import object
Target import object attributes
Target object attribute reference guide files
A single product group can include associated products and subgroups. You can use product groups to create a multilevel hierarchy of product groups and products that can be used as a sales catalog, a rollup hierarchy, or a promotion catalog.
The Product Group import object is used to import product groups and associated subgroups. The Product Group import object is split into separate target import objects for product groups, product group products, and product group subgroups associated with the product groups. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects in the Product Group import object are generally grouped into information about the Product Group, Product Group Products, and Product Group Subgroups business objects, which are represented by the ProductGroupBulkImport, ProductGroupItemBulkImport, ProductGroupRelationBulkImport target import objects, respectively. The Product Group Item business object holds the products in the product group, and the Product Group Relation business object holds other product groups that are subgroups of the product group. The following figure shows the grouping and the target import objects included in the Product Group import object, each represented by their familiar name and their formal target import object name, shown in parentheses.
Before importing product groups, ask yourself the following questions:
Do you have a product group to import? ProductGroupBulkImport includes the basic definition of the product group, such as name, description, active flag, dates, and so on.
Do you have any product associated with this product group? ProductGroupItemsBulkImport allows you to identify the products that must be associated with the product group. It includes the product ID that must be associated with the product group.
Do you have any product groups that are subgroups of this product group? ProductGroupRelationsBulkImport allows you to identify the product groups that must be associated with this product group as its children.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for the product group.
To access the reference guide files for the product group's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Product Group File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Name |
|---|---|---|
|
ProductGroup BulkImport |
Product Group |
QSC_IMP_PROD _GROUPS_ Reference |
|
ProductGroup ItemBulkImport |
Product Group Product |
QSC_IMP_PROD _GROUP_ITEMS_Reference |
|
ProductGroup RelationBulkImport |
Product Group Subgroup |
QSC_IMP_PROD _GROUP_REL_ Reference |
This topic explains how to prepare and import marketing promotion data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
A promotion is a business object that is used to offer special pricing to your customers to promote products, such as a percentage discount, free shipping, or a coupon. For details of how promotion information can be imported into Oracle Fusion Applications, see "Importing Promotions Using File-Based Import: Example."
Consider the following questions when importing your data:
How does your legacy system or source system represent the promotion compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your promotion data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a promotion.
In Oracle Fusion Applications, one table stores the promotion definition and another table optionally stores coupon details for that promotion. A coupon is an entitlement to a specific discount, which businesses give to their customers as part of a promotion. Zero, one, or many coupons can be associated with any given promotion.
To facilitate the import of promotions, Oracle Fusion Applications incorporate the structure of the promotion into import objects. The import object for the promotion is Promotion.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the promotion.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used in choosing default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Promotion |
Promotion Import Object and Attributes: How They Work Together |
Note
You can use the keyword importing promotions to search for related topics in Oracle Fusion Application Help.
Oracle Fusion Applications do not support extensible attributes for promotion objects. You can import data only for promotion model objects that already exist by default in Oracle Fusion Applications.
For the promotion business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a new promotion, you import the Promotion object.
You must be assigned the Customer Relationship Management Application Administrator or Marketing Operations Manager job role to access and submit the import activities for promotions.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with either the Customer Relationship Management Application Administrator or Marketing Operations Manager job role can also navigate to the Promotions work area to view the imported promotions.
You use one main import object, Promotion, when you submit a file-based import activity to import your promotions. This topic describes the Promotion import object. It introduces the following:
Target import object concepts
Target objects for the Promotion import object
Target import object attributes
Target object attribute reference guide files
The Promotion import object is used to import promotions and coupons associated with the promotions. The Promotion import object is split into separate target import objects for the promotion and the coupon. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects included in the Promotion import object and the business objects that each target import object represents are shown in the following table.
|
Import Object |
Business Object |
|---|---|
|
PromotionBulkImport |
Promotions |
|
PromotionCouponBulkImport |
Coupons |
A single promotion includes specific pricing that is used as part of a marketing promotion and may also include coupons offered to customers as part of that promotion.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for the promotion.
To access the reference guide files for the response's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Promotion File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
PromotionBulk Import |
Promotions |
MOP_IMP_ PROMOTIONS_ Reference |
|
PromotionCoupon BulkImport |
Coupons associated with promotions |
MOP_IMP_ PROMO_COUPONS_Reference |
This topic explains how to prepare and import resource team data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature. A resource team is a temporary group of resources that is formed to work on work objects. A resource team may contain a resource organization or resources or both. A resource team cannot be hierarchically structured and is not intended to implement an organization. You enter your resource team information using the Setup and Maintenance work area, Manage Resource Teams task, or you can import data to create new or update the existing resource teams.
Consider the following questions when importing your data:
How does your legacy system or source system represent the resource team compared to how Oracle Fusion Applications represent the same data?
Do you have to configure values in Oracle Fusion Applications to map to your data values?
Do you have to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your resource team data corresponds with the data in Oracle Fusion Applications in order to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a resource team.
In Oracle Fusion Applications, one table stores the resource team definition and other tables optionally store profile details for that resource team. Profile details for a resource include information about a resource team's organization and team memberships.
To facilitate the import of resource teams, Oracle Fusion Applications incorporate the structure of the resource team into import objects. The import object for the resource team is Resource Team.
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the resource team.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used to choose default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for that attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Resource Team |
Resource Team Import Objects: How They Work Together |
Hint: You can use the keyword importing resource teams to search for related topics in Oracle Fusion Applications Help.
If you need to extend the Oracle Fusion Applications object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both extensible custom attributes and the standard import object attributes.
For the resource team business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source-file mappings, and to schedule the import activities. You submit file-based import activities for each import object. When creating a new contact, you import the Resource Team object.
You must be assigned the Master Data Management Administrator job role to access and submit the import activities for resource teams.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with the Master Data Management Administrator job role can also navigate to the Manage Resource Teams work area to view the imported resource teams.
This topic describes the Resource Team import object. You use two main import objects, ResourceTeam and ResourceTeamUsage, when you submit a file-based import activity to import resource team information.
This topic introduces the following:
Target import object concepts
Target objects for the Resource Team import object
Target import object attributes
Target object attribute reference guide files
The Resource Team import object is used to import resource teams and information to create or update associated organizations or persons. The Resource Team import object is split into separate target import objects for organizing the individual attributes of the different aspects of the resource team and the resource team's usage. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects in the Resource Team import object are generally grouped into information about the resource team and its usage. The ResourceTeam target import object contains information that identifies the resource team, such as the team's name, ID, active dates, and so on. The ResourceTeamUsage target import object contains information that captures the usage of the resource team.
To import or update a resource team, use the ResourceTeam target import object. To import or update a resource team's usage, use the ResourceTeamUsage target import object.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for the marketing response.
To access the reference guide files for the resource team's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.oracle.com).
The following table lists the reference guide files that are available from the Documentation tab for the Resource Team File-Based Data Import asset.
|
Target Import Object |
Description |
Reference Guide File Names |
|---|---|---|
|
ResourceTeam |
Captured information that identifies a resource team. Sample attributes: TeamId, TeamName, TeamDescription, and Language. |
HZ_IMP_TEAMS_Reference |
|
ResourceTeamUsage |
Contains information that indicates the usage of the resource team. Sample attributes: RequestId, TeamUsageId, TeamId, and Usage. |
HZ_IMP_TEAM_USAGES_Reference |
This topic explains how to prepare and import sales lead data from an external data source into Oracle Fusion Applications using the File-Based Data Import feature.
A sales lead is a business object that is used to represent the interest of a new prospect or existing customer in a product or service being sold. You enter your lead information using the Lead Qualification work area or you can import data to create or update sales leads.
Consider the following questions when importing your data:
How does your legacy system or source system represent the sales lead compared to how Oracle Fusion Applications represent the same data?
Do you need to configure values in Oracle Fusion Applications to map to your data values?
Do you need to customize Oracle Fusion Applications to capture additional attributes that are critical to the way you do business?
What import features are available for importing your business object?
How do you verify your imported data?
You must understand how your sales lead data corresponds with the data in Oracle Fusion Applications to be able to map your legacy data to the data needed by Oracle Fusion Applications. First, you must understand how Oracle Fusion Applications represent the structure of the data for a sales lead.
In Oracle Fusion Applications, the sales lead structure is hierarchical. At the top level is the lead summary, which must exist before you can import lower level components such as team members, tasks, and appointments. This hierarchical structure supports one-to-many relationships between the components that make up the lead. For example, a lead can have many sales team members, tasks, and appointments.
The lead summary contains basic information about the lead such as the customer or prospect, status, and deal size. For each lead, you can add contacts, assign sales team members, and associate products. As you pursue the lead, you can track appointments and interactions, assign tasks and due dates, attach documents relevant to the lead, and post notes for the lead or for specific tasks.
To facilitate the import of sales leads, Oracle Fusion Applications incorporate the structure of the sales lead into import objects. The following table lists the import objects for the lead.
|
Import Object |
Structure |
|---|---|
|
Lead |
Contacts Note You can create new customers, consumers, and contacts or associate existing ones. Sales Team Products Attachments You can optionally create marketing responses that are associated with the leads. |
|
Task |
Tasks Attachments Notes |
|
Note |
Notes Attachments |
|
Appointment |
Appointments Attachments |
|
Interaction |
Interactions Attachments |
Each import object is a collection of attributes that helps to map your data to the Oracle Fusion Applications data and to support one-to-many relationships between the structural components that make up the sales lead.
A good understanding of the attribute details of the import objects is critical to preparing your import data. The reference guide files contain descriptions, logic used to select default values, and validation information for each of the Oracle Fusion Applications attributes. The validation information includes the navigation to the task where you can define values in Oracle Fusion Applications. For example, if you have values in your data that correlate to a choice list in Oracle Fusion Applications, then the validation information for the attribute provides the task name in the Setup and Maintenance work area where you can define your values. For additional information, including a list of reference guide file names and locations that you need to complete this task, see the following table.
|
Import Object |
Related Import Object Topic |
|---|---|
|
Lead |
Lead Import Object and Attributes: How They Work Together |
|
Task |
Task Import Object and Attributes: How They Work Together |
|
Note |
Note Import Object and Attributes: How They Work Together |
|
Appointment |
Appointment Import Object and Attributes: How They Work Together |
|
Interaction |
Interaction Import Object and Attributes: How They Work Together |
Hint: You can use the keyword "importing leads" to search for related topics in Oracle Fusion Applications Help.
If you need to extend the Oracle Fusion object to import your legacy or source data, you must use Oracle Fusion CRM Application Composer to design your object model extensions and to generate the required artifacts to register your extensions and make them available for importing. The corresponding import object is updated with the extensible attributes, which can then be mapped to your source file data. You can use the same source file to import both custom attributes and the standard import object attributes.
For the lead business object, you must use the File-Based Data Import feature. You prepare XML or text source data files in a form that is suitable for file-based import. The file-based import process reads the data included in your source file, populates the interface tables according to your mapping, and imports the data into the application destination tables.
The Define File-Based Data Import Setup and Maintenance task list includes the tasks needed to configure the import objects, to create source file mappings, and to schedule the import activities. You submit file-based import objects, create source file mappings, and schedule the import activities. You submit file-based import activities for each import object. When creating a marketing lead, you first import the Lead object, followed by subsequent import activities for each of the other import objects. The exception is attachments, which are imported by including the file names in your source file for the Lead object and selecting the files when defining the import activity.
You must be assigned the Corporate Marketing Manager, Marketing Analyst, Marketing Manager, Marketing Operations Manager, Marketing VP, or Sales Lead Qualifier job role to access and submit the import activities for sales leads.
Oracle Fusion Applications provide File-Based Import activity reports, which can be used to verify imported data. Users with the Sales Lead Data Access Duty role can also navigate to the Lead Qualification work area to view the imported lead. Oracle Fusion Applications assign this role to the following predefined job roles: Marketing VP, Corporate Marketing Manager, Marketing Operations Manager, and Marketing Analyst.
You use two main import objects, Sales Lead and Note, when you submit a file-based import activity to import your sales leads. This topic describes the Sales Lead import object. It introduces the following:
Target import object concepts
Target objects for the Lead import object
Target import object attributes
Target object attribute reference guide files
The Sales Lead import object is used to import sales leads and information to create or update associated organization or person information for the customer, consumer, or contact associated with the lead. The Sales Lead import object is split into separate target import objects for organizing the individual attributes of the different aspects of the lead. To map the source data in your import file to the target attributes in Oracle Fusion Applications, you must understand how the target objects are related and what attributes are included in each target object.
The target import objects in the Lead import objects are generally grouped into information about the lead, the originating marketing response, and the contact, consumer, or customer associated with the lead. The following figure shows the grouping and the target import objects included in the Lead import object, each represented by their familiar name and their formal target import object name, shown in parentheses.
A single lead includes information about the lead such as the interested party, lead rank, and qualification status. The lead can include one or more products of interest. You can add specific resources to the sales team responsible for the lead or use assignment rules to assign resources.
The Lead, LeadProduct, and LeadResource target objects include the attributes to import this information for your sales lead.
If the lead customer is an organization and an existing customer, then you can associate the customer with the lead by using the Lead target object. However, if you want to update the information for an existing customer or create a customer record, then you must use additional target objects to import customer profile information, addresses, and contact points, such as a phone and fax number. The following target import objects are used for creating and updating customer information for a lead respondent: OrganizationProfile, OrganizationAddress, PrimaryPhone, Fax, and Url.
Similarly, you can associate an existing consumer with the lead by using the Lead target object. To update the information for an existing consumer or create a consumer record, use the following target import objects: PersonProfile, PersonAddress, Email, PrimaryPhone, Mobile, InstantMessenger, and Fax.
To associate an existing contact for the responding consumer or customer with the lead, you use the Lead target object. To update or create a contact, use the following target import objects: ContactPersonProfile, ContactJob, ContactPrimaryAddress, ContactEmail, ContactPrimaryPhone, ContactMobile, ContactInstantMessenger, and ContactFax.
You can also import the marketing response that is the source for your lead. The response can include one or more products of interest and survey questions and answers, such as a telemarketer script. The Response, ResponseProduct, and ResponseSurvey target objects include the attributes to import this information for your marketing response. If you are importing the lead contact and the customer or consumer, the same information is used as the respondent information for the marketing response.
You must compare the attributes that you want to import with the target object attributes that are available and their valid values. To evaluate your source data and Oracle Fusion Applications attributes for mapping and validation, you use an Oracle Enterprise Repository reference guide, which is available for each target import object. The reference guide file includes attribute descriptions, default values, and validations performed by the import process. Review the validation for each attribute to determine whether there are functional prerequisites or setup tasks that are required.
To import your source file data, you define a mapping between your source file data and the combination of the target object and target object attribute. You can predefine and manage import mappings using the File-Based Import Mapping task, or you can define the mapping when you define the import activity using the File-Based Import Activity task. Both tasks are available in the Setup and Maintenance work area.
Note
If any of the attributes you want to import do not have an equivalent target object attribute, then review the Oracle Fusion CRM Application Composer extensibility features for the sales lead.
To access the reference guide files for the lead's target import objects, see the File-Based Data Import assets in Oracle Enterprise Repository for Oracle Fusion Applications (http://fusionappsoer.com).
The following table lists the reference guide files that are available from the Documentation tab for the Lead File-Based Data Import asset.
|
Target Import Object |
Short Description |
OER Attribute Reference File Name |
|---|---|---|
|
Lead |
Sales lead summary information |
MKT_IMP_LEADS_T_Reference |
|
LeadProduct |
Lead products of interest |
MKT_IMP_LEAD_PRODUCT_T_Reference |
|
LeadResource |
Lead sales team |
MKT_IMP_LEAD_RESOURCES_Reference |
|
Response |
Response summary and associated respondent information |
MKT_IMP_RESPONSES_T_Reference |
|
ResponseProduct |
Response products of interest |
MKT_IMP_RESP_PRODUCT_T_Reference |
|
ResponseSurvey |
Response survey questions and answers |
MKT_IMP_RESP_SVY_LOG_T_Reference |
|
OrganizationProfile |
Customer profile information |
HZ_IMP_PARTIES_T_Reference |
|
OrganizationAddress |
Customer address |
HZ_IMP_PARTYSITES_T_Reference |
|
ContactPersonProfile |
Contact summary information |
HZ_IMP_RELSHIPS_T_Reference |
|
ContactPrimaryAddress |
Contact address |
HZ_IMP_PARTYSITES_T_Reference |
|
ContactEmail |
Contact e-mail |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactFax |
Contact fax |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactInstantMessenger |
Contact social network |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactJob |
Contact job information |
HZ_IMP_CONTACTS_T_Reference |
|
ContactMobile |
Contact mobile |
HZ_IMP_CONTACTPTS_T_Reference |
|
ContactPrimaryPhone |
Contact primary phone |
HZ_IMP_CONTACTPTS_T_Reference |
|
Fax |
Customer fax |
HZ_IMP_CONTACTPTS_T_Reference |
|
PrimaryPhone |
Customer primary phone |
HZ_IMP_CONTACTPTS_T_Reference |
|
Url |
Customer Web site URL |
HZ_IMP_CONTACTPTS_T_Reference |
|
PersonProfile |
Consumer summary information |
HZ_IMP_PARTIES_T_Reference |
|
PersonAddress |
Consumer address |
HZ_IMP_CONTACTPTS_T_Reference |
|
|
Consumer e-mail |
HZ_IMP_CONTACTPTS_T_Reference |
|
Fax |
Consumer fax |
HZ_IMP_CONTACTPTS_T_Reference |
|
InstantMessenger |
Consumer social network |
HZ_IMP_CONTACTPTS_T_Reference |
|
Mobile |
Consumer mobile |
HZ_IMP_CONTACTPTS_T_Reference |
|
PrimaryPhone |
Consumer primary phone |
HZ_IMP_CONTACTPTS_T_Reference |
The Bulk Export application provides a mechanism to extract large volumes of data from Fusion CRM objects. These extracts can be the full set of records for an object or incremental extracts. For example, data extracted for a specific period of time, from the hosted CRM system to an on-premise database that resides behind a user's fire-wall. The system will create comma separated variable or tab delimited files with the extracted data, which will be available to users as attachments to the batch records that have been executed.
The following figure depicts the process of selecting data for export, scheduling and finally delivering the exported data file.
This solution provides a mechanism to extract large volumes of data from Fusion CRM objects, both as extracts of a full set of records for an object as well as incremental extracts. The system will create comma or tab delimited files with the extracted data which will be available to users as attachments to the batch records that have been executed.
In order to create the extracts, two steps must be completed. First, mapping files for the full and incremental extract processes must be defined in the Fusion CRM system. These maps will specify which columns and filters will be applied to each export process for each export object. For the incremental extracts, filters can be created that leverage time stamps to determine which rows will be queried out of the system. All mapping files will be saved in the system and reused for each extract.
Next, the hourly and weekly data export processes
are scheduled in the Fusion export tool. For any required incremental
and scheduled export, the export task should either exist or created
through the UI. Oracle Web Services would only be used to schedule
the export and start it. After each export process executes and completes,
a comma or tab delimited data file will be created and stored in the
Fusion system as an attachment. The formatted file can be downloaded
by using the getAttachment() web service
or by using the interactive UI in the export tool.
There are no transactional steps for this process in the Fusion CRM application, there are only prerequisite setup steps. Once these steps are complete the process should run automatically. The prerequisite steps in Fusion are to create an export map and export job schedule for each object to be extracted (this only needs to be done once).
The Bulk Export Process Definition is made up of the Export Map and the processing schedule. See the steps below.
The export object is the Fusion data base object where the data resides. It is made up of attributes. If you need to export data from a custom table, you must register the object as an export object. This is accomplished from the Manage Export Process UI, Manage Export Objects action. All the delivered tables and their attributes are available for export.
The export object is made up of attributes. These attribute may be selected for export or not included. You can edit the header text of the attribute to make its meaning more clear to other users of this process.
Each attribute may have limits or conditions enforced. Various operators are available for selecting the data to precisely select the data required for the export. You can save the filter criteria and then modify the criteria and save it under a new name. You can then change the filter by coming here to select an alternate filter name. Because the filters are related to the export object, if you reuse a map and change the filter, you are changing it for any Export Process Definition that uses that map. The attributes you use for the map have no bearing on what is available in the filter. All fields from the VO are available for use in the filter. For example, you can filter by TYPE but not show TYPE in the output.
Once defined, the export process is scheduled. You can run the process immediately or at the time and date of your choosing. If you decide to schedule the job at a later date you can also choose to set up a recurring schedule of extracts.
By clicking on the Activate button, you make the job available to be run. It does not start an export process.
In the two step process used by Oracle Fusion Bulk Export, the first is the mapping of files for the full and incremental extract processes. The second step is the scheduling of the export. You create a process definition that includes both of these steps.
The process definition has three components that together make exporting data easier by leveraging the export maps that you have already built. The process name, the export process ID and the export map ID all serve to identify the specific process definition as well as leverage your work with reusable export maps
A user-supplied, natural language way to refer to the Export Process Definition. This enables you to refer to the export process definition easily rather than using the machine generated ID. For example, use Customer or some other meaningful name as the export process name instead of the export process ID 100000019897192.
A unique, system generated identifier for the export process definition that ties together the export map, with its export objects and filters, and the defined export schedule.
A unique identifier for the export map itself. You can name the export map or leave the field blank for a system generated map name to be entered. You can reuse the export map in different process definitions. For example, you could create a process definition to export all the data from the Customer export object. You could then reuse that export map and apply a new filter on the data to create an incremental export, such as data accrued since the last export date.
Review the requirements for the data to be exported and determine the source view object that holds the attributes you want.
Full sets of data are not always required for export. To create a subset of data, use filter criteria to determine the time frame or scope of data, based on values of the attributes. For example, to find activities for a certain period, use a project start date from 1/1/11 through 3/31/11, navigate to the Export Objects Detail Sub Page and click the filter icon. Fill in the filter criteria dialog for the project start dates to select the data to be exported.You run the export by navigating to the Setup and Maintenance menu, selecting Manage Task Lists and Tasks. Then, search for Schedule Export Processes and click the Go to Task icon on the line for this task.
You can look on the Schedule Export Processes, Overview page to see the History subpage. The column Exported Data File shows a hyperlink to your output file This file will be a comma separated variable or a tab delimited file. Click that link to open the file and see the exported data.
You can use your own defined view objects as a source for Bulk Export. To register your view objects for export, select Setup and Maintenance from the Tools menu and search for the Manage Export Objects task. Click the Go to Task icon and on the Manage Export Objects page click the Create icon to add your View Object, making it available for use.
Changing the sequence number changes the order of the attributes in the exported data file. Changing the header text enables you to give a more intuitive meaning to the attribute and the associated data.
Select as many view objects as required to be export objects for the export process. Choose the individual attributes required from each export object.
The Oracle Fusion Customer Relationship Management (CRM) common calendar is used across CRM applications. The calendar utilizes the Accounting Calendar Default profile option that is not set when the delivered product is installed. First, create an accounting calendar with calendar periods appropriate for your CRM needs, and give it a unique name, CRM Calendar, for example. Then, you must specify that calendar in the Accounting Calendar Default profile option. Use the following tasks to set up the CRM calendar.
Manage Accounting Calendars will show up in the results box.
Note
When creating the calendar, the first calendar date must be the first date of the period of the oldest historical data on which you will be reporting. For example, if you select January 1, 2010 as your first calendar date, then you would only be able to enter or import historical data associated with this date and later.
The CRM calendar profile option must be associated with the new accounting calendar. Follow these steps:
Note
While the Common Financial Calendar feature of Oracle Fusion Applications supports the creation of more than one calendar, Oracle Fusion CRM may only be associated with one calendar. Many features of Fusion CRM utilize this common calendar profile option and changing it could result in the loss of data for one or more applications. Oracle strongly recommends that you do not change the selected Accounting Calendar Default (ZCA_COMMON_CALENDAR) profile option calendar value when it is set.
Oracle Fusion Sales Prediction Engine enables organizations to capture and leverage predictive sales intelligence. Predictive models analyze sales data to evaluate buying patterns. After the evaluation of model results, lead generation can be scheduled to disseminate lead recommendations to users. Each lead recommendation includes win likelihood, average expected revenue, and sales cycle duration.
The key features of Oracle Fusion Sales Prediction Engine include the following:
Application Home Page: The application home page provides sales analysts with a summary of the prediction model results. Additionally, reports on the dashboard provide overviews of model performance and leads adoption.
Predictive Model Learning: Model learning uncovers hidden selling patterns in complex business environments. Salespeople can replicate sales success using historical insight generated through model training.
Rule-based Recommendations: When new products are launched or during initial deployment, historical data is sparse. In such cases, the sales analyst can create customer-, industry-, or product-specific rules to drive the recommendation of new products.
Higher Lead Adoption Rate: By utilizing a combination of data mining, segmentation, prediction and business rules, Sales Prediction Engine ensures that the recommendations have a higher likelihood of being converted to a win.
Analyze Recommendation Performance: Built-in analytical reports verify whether the recommendations are being accepted by the sales organization. If adoption is low, then the predictive models can be fine-tuned by selecting different attributes for model learning or editing the rules. Simulation can then be performed to assess the impact of these new changes before publishing new recommendations.
Usage across CRM Applications: The recommendations generated are integrated with and can be viewed in other CRM applications and features, such as Opportunity Landscape, Customer Center, Territory Management, and Lead Qualification. In Opportunity Landscape, the recommendations can be ranked and qualified as leads after being reviewed. In Customer Center, recommended products display next to a customer, and the rationale for the recommendations is provided in the context of creating a deal for the customer. Territory managers can use the metrics output to set sales targets by territory and assign them to salespeople. The metrics ranking determines whether leads can be qualified in Lead Qualification.
To run the Oracle Fusion Sales Prediction Engine in Oracle Fusion Applications Customer Relationship Management (CRM), perform the following post-installation tasks if you deployed Oracle Business Intelligence Applications and have created the Oracle Business Analytics Warehouse. For information on deploying and setting up Oracle Business Intelligence Applications, refer to the Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Applications.
However, if you deployed only Oracle Transactional Business Intelligence, you need not perform these steps to run the Oracle Fusion Sales Prediction Engine.
You can create the Data Warehouse objects using the Sales Predictor Repository Creation Utility (RCU). To run the Sales Predictor RCU , ensure that the Oracle Business Intelligence Application (OBIA) Data Warehouse database and the related schema including database objects such as tables, are available. The Sales Predictor RCU creates Sales Predictor related Data Warehouse database objects such as Oracle Data Mining tables, views, packages, Oracle Real-time Decisions (RTD) Inline Service Processing tables, and the purge package in the existing OBIA schema.
Initiate the Sales Predictor RCU following these instructions.
Access the rcuBIZSPApps.zip file from the following location, and extract its contents to a local directory.
In Windows NT, the location is FAINTEG_BASE/fainteg/shiphome/rcu/nt/rcuBIZSPApps.zip
In Linux, the location is FAINTEG_BASE/fainteg/shiphome/rcu/linux/rcuBIZSPApps.zip
Run the following command pointing to the BIN folder within the local directory:
In Windows NT, use rcu -variables BI_SCHEMA_NAME=<OBIA Schema name>
In Linux, use ./rcu -variables BI_SCHEMA_NAME=<OBIA Schema name>
Note
<OBIA Schema name> refers to the name of the OBIA schema that is used, and is an input parameter for the Sales Predictor RCU.
The Sales Predictor RCU wizard appears.
On the Welcome page, click Next and on the Create Repository page, ensure that the default option Create is selected and click Next.
On the Database Connection Details page, provide the following information and click Next.
Host Name: Name of the server where the database is located.
Port: The database port number.
Service Name: The service name of the database.
Username: SYS. It is the user name associated with an administrative role.
Password: Password used in combination with the user name to access the database.
Role: SYSDBA. It is the role with administrative access rights.
The provided information is processed through a prerequisite check.
On the confirmation dialog box, click OK.
On the Select Components page, select the Oracle Application Components, and click Next.
On the confirmation dialog box, click OK.
On the Schema Passwords page, ensure that the Use same passwords for all schemas option is selected. Selecting this option provides the password used with the existing OBIA Schema Name.
Enter the password again to confirm it, and click Next.
On the Map Tablespaces page, click Next and on the confirmation box that subsequently appears, click OK.
On the Summary page, review the database information provided until this point. If necessary, click Back to change details in the previous pages.
Click Create to create the Data Warehouse objects. The Completion Summary page confirms the successful creation of the objects.
The Data Warehouse requires a Java Naming and Directory Interface (JNDI) data source connection named DWDS that points to the Online Analytical Processing (OLAP) database residing on Oracle BI server. To create the data source using the RTD WebLogic Server console, follow these instructions.
In the WebLogic Server console, open Services - JDBC - Data Sources and click New.
On the JDBC Data Source Properties page, provide the following details and click Next.
Name: Fusion_OLAP_DS
JNDI Name: DWDS
Database Type: Oracle
Database Driver: Oracle Driver (Thin) for Instance connections
On the Transaction Options page, ensure that the default property Supports Global Transactions is selected, and click Next.
On the Connection Properties page, provide the following values, and click Next.
Database Name: The Unique System ID (SID) of the database
Host Name: The name of the computer that hosts the database
Port: The port number of the database
Database User Name: User credential to access the database
Password: The password used in combination with the Database User Name to access the database
On the Test Database Connections page, review the details provided until this point, test the connectivity to the database, and click Next.
Select the Oracle BI Server where you want to make the data source available, and click Finish.
To enable connectivity to Data Warehouse, you must set the value for the profile option.
Note
You can set the value for this profile option using Applications Core Setup, if you have roles allowing access to do so. The Application Implementation Administrator abstract role provides the necessary access.
Sign in to the Oracle Fusion Applications Core Setup.
Under the Tasks menu on the left side of the page, click Manage Administrator Profile Values. The Manage Administrator Profile Values tab appears.
In the Profile Option Code field, enter ZCA_WAREHOUSE_ENABLED_BI and click Search. The profile option appears in the search results.
In the Profile Values region, select the result item associated with the searched profile option, and under the Profile Value column, set the value to Yes.
Click Save.
The Sales Predictor Inline Service within RTD uses the profile option to point to the Data Warehouse tables.
You can point RTD to the Data Warehouse in one of the following ways:
Restart the RTD application server. The Sales Predictor Inline Service is reloaded and points to the Data Warehouse.
Manually redeploy the Sales Predictor Inline Service if restarting the RTD application server does not work. Before you manually redeploy, ensure that the following prerequisites are met:
You have roles allowing access to deploy the Sales Predictor Inline Service.
Java Development Kit (JDK) 1.6 or higher version is available and running on the same server
You must have access to the command line tool zip file rtd-deploytool-11.1.1.zip. The zip file resides within the RTD client zip file (rtd_client_11.1.1.3.0.zip), which is available in the BI_MW_HOME/Oracle_BI1/clients/rtd directory.
To manually redeploy the Sales Predictor Inline Service, follow these instructions.
Extract the contents of the file rtd_client_11.1.1.3.0.zip to a local directory.
In the local directory, go to the folder ./client/CommandLineDeploy, locate rtd-deploytool-11.1.1.zip and extract its contents to a folder.
In that folder, locate ./OracleBI/RTD/deploytool folder and within that folder, open a command prompt terminal.
Note
Ensure that the JDK classpath is set for the command prompt terminal.
Run the command: java -jar deploytool.jar -deploy -server <Server Host> -port <Port>
-terminateSessions true <Full path of Directory/ Zip File>.
When prompted, provide the user name and password to connect to the RTD server.
The message Deploymentstateid: id. Deployed SPE_ILS.zip to server port in state: Development appears indicating completeness of deployment of the Sales Predictor Inline Service.
The Oracle Fusion Sales Prediction Engine can also use data from the following Data Warehouse entity tables to make more accurate predictions:
Assets
Service Agreements
Orders
Also, it is necessary to load either Assets or Orders tables into the corresponding Data Warehouse table. Once the data in the Data Warehouse entity tables are ready, you can go to the Schedule Predictive Model Training page to run the model training process.
For more information on OBIA, see Oracle Fusion Middleware Configuration Guide for Oracle Business Intelligence Applications.
Oracle Fusion Sales Prediction Engine leverages the power of predictive analytical models to identify patterns and correlation of data for the purpose of identifying what products to consider positioning next to your customers. The application leverages multiple mathematical models in order to formulate the likelihood a given customer will purchase a specific product, the estimated revenue which can be expected, and the duration of the estimated sales effort.
After the statistical model generates against the historical sales data based on the selected entities and attributes, summary and detail reports show critical insights as to what customers buy and can be used to predict the right products for the right customers. You can then use these insights to refine the process of generating leads based on what the customers are more likely to buy. Moreover, the same model can be used to predict the win likelihood of current opportunity revenue based on analysis of similar opportunities in the past. Also, product domain or market experts can write prediction rules to recommend products based on a set of rules conditions, utilizing all available customer profile attributes as well as other metrics.
The statistical analysis will identify which data has an influence in determining a likelihood to buy. After the statistical model generates against the historical sales data based on the selected entities and attributes, summary and detail reports show critical insights as to what customers buy and can be used to predict the right products for the right customers. As such, the decision regarding the selection of entities and attributes is critical. While the selection of certain entities and attributes may seem logical based on the awareness of sales behavior (customers in certain industries have a stronger affinity for certain products, for example), where there is uncertainty, the statistical model analysis will provide the necessary insight into whether patterns and correlation emerge. As such, as much available data as possible should be leveraged for the purpose of evaluation. Some factors which weight into the decision include the availability and accuracy of the data.
While selecting attributes, you must not select similar attributes for model training. For example, Annual Revenue and Annual Revenue Category. Your customer's annual revenue might range from 250,000 dollars to 50 million dollars. However, for efficient management, you decide to target only five customer types based on the Annual Revenue Category such as, Nano (250,000 dollars to 1 million dollars), Small (1-5 million dollars), and so on. The Annual Revenue Category uses Annual Revenue for this classification. Therefore, you must use either Annual Revenue or Annual Revenue Category but not both as they are redundant. Similar duplicate attributes could manifest in multiple areas such as Number of Employees and Company Size, Location and Zip Code, and so on.
Additionally, the application allows for the inclusion of expert insight from product management and sales and marketing operations. These expert insights can be captured via prediction rules. The same data made available to and leveraged by the predictive model, is also available for rule authoring.
Your company sells a service that appeals mostly to larger companies, and another service that targets smaller customers. If a customer purchased one of your product packages, then the customer already has all service needs covered by the package. You want to know, given a product recommendation, if credit score, asset, and customer size are important predictors when it comes to recommending this particular product.
You select the following entities and attributes:
Customer Profile
Annual Revenue
Credit Score
Customer Size Code
Past Purchased Products or Services
Assets and Service Contracts
These entities and associated attributes entail the data available to the enterprise which the predictive models can evaluate for identifying correlation, and which you can use to create prediction rules. Over time, you can further refine the selections based on availability of data and the cost to integrate that data for evaluation.
Before using the Oracle Fusion CRM for Microsoft Outlook application, several setup tasks must be performed. Some of these are Fusion-specific tasks that are done by the environment hosting team or the customer implementation team. Other tasks are related to setting up the users' computers to use the application, including the install and initialization of the extensions to Microsoft Outlook (Outlook). These tasks are described in more detail in the sections that follow.
For information on supported software versions, see the related topic, Supported Software for Oracle Fusion CRM for Microsoft Outlook: Explained.
At a high level, the following are the Oracle Fusion-specific setup tasks involved in implementing CRM for Microsoft Outlook:
Required: Install Fusion CRM, including the CRM for Microsoft Outlook application.
Required: Perform Fusion setup tasks for Oracle Fusion Common Components, Oracle Fusion Customer Center, Oracle Fusion Sales, and Oracle Fusion Marketing.
Optional: Perform customization and security changes for CRM for Microsoft Outlook, after initial setup.
At a high level, the following are the setup tasks required for each computer that will run CRM for Microsoft Outlook:
Required: If not already present, install Microsoft .NET framework version 3.5 SP1 (or later).
Required: Download and install the Fusion CRM server certificate.
Required: Download and run the CRM for Microsoft Outlook installer.
Required: Complete First Run Assistant to set up application options and perform initial synchronization to get Outlook configuration and user data from the Fusion CRM application.
The overall process flow for implementing CRM for Microsoft Outlook is shown in this section.
Following are the CRM for Microsoft Outlook implementation tasks specific to Oracle Fusion.
Install Oracle Fusion CRM Applications suite
As a prerequisite setup task, provision the server environment and install the Fusion CRM Applications suite. This task is typically completed by the hosting operations team or customer implementing the Oracle Fusion CRM Applications suite and is the basis for the rest of the setup steps described in this section.
Perform CRM setup tasks for functionality used by CRM for Microsoft Outlook
Because CRM for Microsoft Outlook allows users to access and manage their CRM data in Microsoft Outlook, it is necessary to complete the required setup tasks for the relevant CRM functionality. For example, the following setup tasks must be completed before using CRM for Microsoft Outlook:
Set up reference data, such as: address and phone formats, currencies, geographies, and resources.
Set up CRM functional areas exposed in CRM for Microsoft Outlook, such as: calendar and task management, customer and contact management, lead management, and opportunity and revenue management, including the sales product catalog.
Optionally, CRM for Microsoft Outlook can be configured by completing these Outlook-specific setup tasks:
Configure CRM for Microsoft Outlook client configuration files: Configure only if Outlook client customizations are needed
Configure CRM for Microsoft Outlook client deployment packages: Configure only if Outlook client customizations are needed
Configure CRM for Microsoft Outlook server configuration file: Configure only if Outlook configuration includes references to new services
Other, security-related tasks, performed in Oracle Fusion Authorization Policy Manager (APM), may be necessary depending upon your applications configuration. Perform these tasks after initial setup, as needed. If new job roles are created, you will need to associate these new roles with the predefined data privileges and Outlook configuration packages. If you create custom Outlook deployment packages, there are additional steps required. See the "Related Topics" section at the end of this topic for more information.
Following are the non-Fusion implementation tasks for CRM for Microsoft Outlook.
Verify Microsoft .NET Framework 3.5 SP1 or higher is installed on all computers that run CRM for Microsoft Outlook.
Verify each user has a Microsoft Exchange mail profile configured with Cached Exchange Mode (which supports offline storage in an .OST file format) or has a separate personal folders storage (in .PST file format) to store CRM data.
Deploy the Fusion public certificate into users' Personal and Trusted Root Certificate Authorities directories on users' computers. The certificate is provided by the environment hosting team or the group implementing Fusion CRM. See the related topic, Options for Deploying the Public Certificate: Explained, for steps describing how users can import the certificate themselves or how to automate the process.
Verify that each user can access the CRM for Microsoft Outlook installer from the download page in the Sales application. The download page is accessible from the application preferences menu.
Each user must run the CRM for Microsoft Outlook installer on his/her computer. See the related topic, Deploying and Installing Oracle Fusion CRM for Microsoft Outlook: Explained, for more information.
In Oracle Fusion CRM for Microsoft Outlook, deployment packages contain metadata files that describe the CRM application extensions deployed to users' computers. To provide users access to a new client configuration, you can either create a new deployment package or create a new instance of an existing package, as discussed in the following sections.
When you create a new package, in addition to activating it, you must configure a data security policy that allows users to access the package. This secondary task is done in Oracle Fusion Authorization Policy Manager (APM) and involves the following steps:
In the top left section of the APM
application window, use global search to search for Database Resources
using search criteria equal to Outlook. This should return the result, Outlook Edition Metadata Package.
Select the Edit button on the Search Results pane to edit the Outlook Edition Metadata Package database resource.
In the Edit Database Resource tab,
select the Condition tab and create a new condition on the database
resource. Specify any unique name/display name, and set the SQL predicate
to package_name = '<name_of_deployment_package>' (for example, package name = 'NewOutlookPackage').
Select the Submit button to commit the change.
Repeat step 2. In the search results pane, select Edit to reopen the Edit Database Resource page to edit the Outlook Edition Metadata Package database resource.
In the Edit Database Resource tab, select the Policy tab, and select the policy that should have access to the new package (for example, ZOE_SALES_MGR_OUTLOOK_DUTY), and then select Edit.
In the lower section of the page, select the Rule tab.
Select the lookup control next to the condition field and select the new condition created in step 3.
Select Submit to commit the changes.
When you use an existing package, you create a new instance of the package with different configuration files. When using this method, you must inactivate the previous instance and activate the new instance. There is no need to configure a data policy when creating a new instance of an existing deployment package.
Before using the Oracle Fusion CRM for Microsoft Outlook application, several setup tasks must be performed. One of these tasks is to deploy the Fusion Public Certificate to each user's machine in order to support secure exchange of data between Outlook and Oracle Fusion CRM during synchronization. The Fusion CRM application public certificate is available from the CRM for Microsoft Outlook preference page in the Oracle Fusion Sales application.
If users have sufficient privileges and knowledge to import the certificate themselves, they need to make sure the certificate is imported to both the Personal and Trusted Root Authority certificate stores. This can be done by following these steps:
In the Windows Start menu select Run, and type mmc to open the Microsoft Machine Console application.
In the console window, select File, then Add/Remove Snap-in.
In the Add/Remove Snap-in window, select Add, and then select the Certificates snap-in. Select the Add button to add it.
Select the option to manage certificates for My user account and select Finish.
Select Close and OK to complete adding the Certificate snap-in.
Expand the Certificates - Current User group to review all the certificate stores.
Expand the Personal store, right-select the Certificates child folder and select All Tasks - Import.
In the next several windows, find the certificate file and complete the import into the Personal certificate store.
Repeat step 7 using the Trusted Root Certification Authorities store, and repeat step 8 to import the certificate file.
Alternatively, to automate the installation of the public certificate into the appropriate certificate stores on the users' computers, deploy the CertMgr.exe program available from Microsoft in the Windows SDK to users' computers, along with the certificate file, and a batch script that implements the following commands:
certmgr.exe -add -c <cert_name> -s root -r localMachine
certmgr.exe -add -c <cert_name> -r CurrentUser -s My
In the script above, the placeholder for the certificate name would be replaced with the name of the certificate file (for example, oracle.cer).
Oracle Fusion CRM for Microsoft Outlook includes a Microsoft Outlook add-in that must be deployed and installed on each user's computer. The installer file is available from the CRM for Microsoft Outlook preference page in the Oracle Fusion Sales application.
Users can complete the installation by running the Oracle Fusion CRM for Microsoft Outlook.msi file on their computers. The Outlook application must be closed during this process. During the install, the user will specify:
The install directory
The Outlook mail profile to use
An alternative to users installing CRM for Microsoft Outlook themselves is for the installer to be deployed to user computers by the administrator using Windows Group policies, Microsoft System Center Configuration Manager (SCCM), or other desktop software deployment mechanisms. In this case, the administrator will access the installer file from the appropriate preference page in the Oracle Fusion Sales application and write a batch script to run the installer with several default parameters, such as the install directory, the mail profile to install to, and all of the elements of the connect string.
The following sample batch script shows how the installer installation can be automated:
msiexec /i "Oracle Fusion CRM for Microsoft Outlook.3.00.50.msi" OL_PROFILE=$DEFAULT FUSION_SERVER_HOST="hostedappserver.com" FUSION_SERVER_PORT="443" FUSION_SERVER_SUFFIX="outlookEditionConnector/OutlookRequestHandlerService" FUSION_SERVER_PROTOCOL="https" /QR
The parameters in the script include the following:
The name and relative path to the installer file. In the example, the script assumes that the .msi file is in the same directory as the batch script.
OL_PROFILE: This is the name of the user's Outlook mail profile. Besides the mail profile name itself, predefined values can be provided (for example, $DEFAULT and $PREFERRED). When using $DEFAULT, the default mail profile will be selected. When using $PREFERRED, the installer will try to use the default profile first, but if it doesn't satisfy the mail profile configuration requirements (if it doesn't use Cached Exchange Mode or use Personal Folders storage) then the installer will try to use another profile.
FUSION_SERVER_HOST: This is the server name or IP address.
FUSION_SERVER_PORT: This is the port that CRM for Microsoft Outlook is configured to use.
FUSION_SERVER_SUFFIX: This is the URL suffix for accessing the CRM for Microsoft Outlook Web services. The one provided in the example above is the default deployment path for the CRM for Microsoft Outlook application, and it will typically be used.
FUSION_SERVER_PROTOCOL: This is either "http" or "https", depending on whether the application is deployed with SSL enabled or not.
Note that the script is using the standard switches provided by the Microsoft Installer executable, msiexec.exe. Documentation of the switches can be reviewed by typing msiexec.exe /?at the command prompt.
Once the installer finishes, the first time the user opens Outlook there will be additional dialogs that prompt the selection of various application options. This process is called the First Run Assistant, and each user will specify:
The Fusion CRM username and password.
The CRM for Microsoft Outlook connect string. Note that if the installation was completed with the various FUSION_SERVER_* variables, the connect string will be pre-filled and the user will not need to specify those details.
Once the user credentials and connect string are provided, the application will connect to Fusion to download and apply the Outlook configuration available to the user. Once the configuration is applied the user is presented with additional First Run Assistant dialogs to complete the personalization process and perform an initial synchronization. In this second phase of the First Run Assistant, the user will specify:
Synchronization settings, including the default synchronization frequency and synchronization filters. The application synchronizes data based on synchronization filters, and will automatically initiate a syncronization on the specified frequency.
Whether to share new Appointments, Contacts, and Tasks in CRM for Microsoft Outlook by default.
Whether to convert his contact list to Fusion contacts.
Once the user completes the First Run Assistant, the application will begin the first synchronization.
Before using the Oracle Fusion CRM for Microsoft Outlook application, several setup tasks must be performed. One of these tasks is to verify each user's computer has the necessary supported software prior to installing CRM for Microsoft Outlook.
The following are the supported client computer operating systems:
Microsoft Windows XP SP3 (32 bit) and higher
Microsoft Vista SP1 (32 and 64 bit) and higher
Microsoft Windows 7 and higher
The following are the supported Microsoft Office versions:
2007 SP2 and higher
2010 and higher
The following are the supported Outlook profiles:
Profile with a Microsoft Exchange e-mail account configured in cached mode with single mailbox. Outlook needs to be run with this profile at least once.
Profile with an Internet e-mail account. Outlook needs to be run with this profile at least once.
Note
CRM for Outlook can only be installed into one of the Outlook profiles.
Depending on what data file is set as the default mail delivery location in the Outlook profile selected for CRM for Outlook installation, it can be either:
.ost file
.pst file
Only POP protocol is supported. IMAP is not supported for the following reasons:
The IMAP protocol has a unique structure. Whether or not a custom folder can be created in this protocol depends on the mail server. The CRM for Outlook platform requires the ability to add custom folders, and needs to be able to syncronize custom CRM objects (for example, accounts or opportunities) with Outlook.
The IMAP protocol cannot be made the default mail delivery location in Outlook, and the CRM for Outlook platform installs to the default mail delivery location in the profile. Either Exchange mailbox or POP .pest can be made the default mail delivery location. A default mail delivery location is required for the platform, as all Outlook activity processing happens there (for example, meeting participants receive notification from the organizer only in this location).
Note
Changing the default mail delivery location in the Outlook profile where CRM for Outlook is installed is not supported because doing so will cause the CRM for Outlook add-in to fail.
The following are the supported versions of Microsoft Exchange Server:
Microsoft Exchange Server 2003
Microsoft Exchange Server 2007
Microsoft .NET Framework 3.5 SP1 or higher is required to support the client application.
Oracle Fusion CRM for Microsoft Outlook is a composite application that allows users to work with Oracle Fusion CRM data inside Microsoft Outlook. The application is deployed to Outlook using the add-in framework and extends the Outlook data model and UI framework in order to store and render CRM data to the user.
Oracle Fusion CRM data is synchronized to users' computers and maintained in native Microsoft Outlook storage. While working in Outlook, users access CRM data that is stored locally, even when connected to the corporate network. The changes made to the CRM data are periodically synchronized with the Oracle Fusion CRM application. There are two options for storing the CRM data:
A Microsoft Outlook mail profile configured to use a Microsoft Exchange service with the Use Cached Exchange Mode enabled to allow data to be stored in an offline storage file (.ost file format)
A Microsoft Outlook mail profile configured to use the Internet E-Mail service with personal folder storage (.pst file format)
Because CRM data is maintained in Outlook storage, it can be displayed and accessed like any other Outlook item. For instance, CRM data types will appear in the folders for the user's mailbox alongside other native Outlook types, and users can select the CRM folder and view the CRM records there as they would work with other Outlook information. Within a given folder, the user can select and open a single record to view the data. In this case, the user will have access to CRM data that appears within an Outlook form or inspector window.
In addition to accessing CRM data in Outlook explorer views and inspector windows where the CRM data is the primary focus, users will also be able to access CRM context when viewing standard Outlook items like appointments, e-mails, and tasks. For these Outlook types, the user will be able to specify the CRM customer, related sales item, contacts, and resources associated with the Outlook item, and will be able navigate to the related CRM item to review additional details.
Data that is stored in either cached Exchange mode in .ost file format, or in personal folders in .pst format, is accessible to the CRM for Microsoft Outlook user while disconnected. The user interacts with the CRM data that is stored locally on his computer and periodically synchronizes data between Outlook and the Fusion CRM server. Synchronization happens when the user is connected to the corporate network and can access the CRM application server. Because the user always works with the local set of CRM data, he will have access to the data from the server immediately following the synchronization process, but doesn't directly access or update the data on the server. Changes are made to the local data set, and then the synchronization process takes care of making changes to the local or server data sets to align the two.
After CRM for Microsoft Outlook is installed, the user must perform an initial synchronization to retrieve his accessible CRM data. Several synchronization settings are configured as part of the First Run Assistant process that influence the initial synchronization. These include the frequency of automatic synchronization, the synchronization filters to use, and which objects are enabled or disabled from synchronization. These settings can be changed by the user after the initial synchronization. Once the user completes the First Run Assistant process, the initial synchronization will begin. The duration of the synchronization process will depend on the number of records that will be synchronized, network bandwidth, load on the server, as well as processing speed and memory available on the user's computer. A rule of thumb is to try to configure synchronization filters so that no more than five to ten thousand records are synchronized.
During the synchronization process, the application performs the following steps:
Connects to the Fusion CRM server CRM for Microsoft Outlook synchronization services using SOAP over HTTP and authenticates the user.
Performs a check to determine the configuration for which the user possesses access. Access to an Outlook configuration is established based on a privilege associated with a user's job role that allows access to an Outlook client deployment package.
If a user has access to a deployment package, it is downloaded, and the configuration is applied to the Outlook mailbox.
The final step is to synchronize data. The records that are retrieved depend on the internal filters configured on the server, data security applied to the objects that are synchronized, and the user filters.
Subsequent synchronization cycles follow a process that includes these steps:
CRM for Microsoft Outlook sends a request to the Fusion CRM server with a list of objects and the current user filters and requests a snapshot of IDs and timestamps for all records that are within the scope of the object list and specified filters.
The server sends a response with the requested information.
CRM for Microsoft Outlook makes a local snapshot of IDs and timestamps and compares that to the server snapshot.
The differences between the local snapshot of IDs and timestamps and the server snapshot result in a few possible actions:
Inserts, updates, or deletes data on the Fusion server based on changes that occurred in CRM for Microsoft Outlook since the prior synchronization.
Inserts, updates, or deletes data in CRM for Microsoft Outlook based on changes that occurred on the Fusion server since the prior synchronization.
In all cases, changes that are made to data locally in the CRM for Microsoft Outlook client are only sent to the Fusion server during the subsequent synchronization session; however, users who want to synchronize a change or set of changes immediately can start the synchronization cycle manually to avoid waiting for the next scheduled synchronization.
The synchronization process on the Fusion server is supported by CRM for Microsoft Outlook accessing Web services. CRM for Microsoft Outlook accesses two Web services directly -- one that provides access to data during synchronization processing, and one that provides access to metadata. The synchronization process is initiated by CRM for Microsoft Outlook within the Outlook application, and the Fusion server accepts synchronization requests, routes them to the appropriate services within the service, and returns the appropriate responses. The work that each part of the synchronization architecture performs is summarized as:
CRM for Microsoft Outlook synchronization engine and connector that are deployed to Microsoft Outlook perform the following:
Initiates a new synchronization request based on a preconfigured automatic synchronization interval or by an ad hoc user request to start a new synchronization cycle.
Uses the stored details about username, password, server connection information, and CRM public security certificate stored on the user's computer to format and send requests to the CRM application server.
Based on the configuration deployed to a user's computer (including object types deployed), fields defined as part of those objects, synchronization filters and the like, the application generates the appropriate SOAP message content and expects the corresponding response when using the HTTP or HTTPS transport to communicate with the CRM applicaiton server.
The Fusion server hosts an application that listens for CRM for Microsoft Outlook synchronization requests, and the synchronization services perform the following:
The OutlookRequestHandlerService Web service processes all incoming requests for data synchronization, and the OutlookMetadataService Web service handles requests to retrieve metadata.
Incoming SOAP messages are routed to the appropriate service. These messages include one or more requests to invoke a method on the target service.
Requests sent to the OutlookRequestHandlerService in particular are routed to other services to perform the action expected from the synchronization process. For instance, a request to get appointment data sent to the OutlookRequestHandlerService will be routed to the appointment Web service that will process the request and return the requested data, and the OutlookRequestHandlerService will send this back to the CRM for Microsoft Outlook client that sent the request.
A synchronization cycle will include requests to get a server snapshot, and can then include many additional requests to query, insert, update, and delete data based on the changes detected when CRM for Microsoft Outlook compares the local and server snapshots.
Each of these requests is processed based on the type of request, and is either managed within the OutlookRequestHandlerService processing directly or is routed to the appropriate target service to be fulfilled.
In addition to standard Outlook data storage mechanisms and the synchronization engine, several extensions to the standard Outlook user interface provide a way to access and manage CRM data inside of Outlook. Examples of extensions to the standard Outlook user interface include custom toolbar buttons, menu items, inspectors that display Fusion CRM data, controls that are embedded on standard Outlook item inspectors, the personalization options dialog box, and so forth. The CRM for Microsoft Outlook client can use these extensions to perform a variety of tasks.
The following are some examples of tasks that the user can perform:
Create, view, and edit CRM data in Outlook.
Mark an Outlook item to be shared with CRM Desktop and associated sales data.
Initiate a standard Outlook action, such as sending an e-mail or scheduling a meeting in the context of a sales item.
The behavior of the extended Outlook user interface is influenced by custom CRM business logic that performs a variety of validations during data entry. The following are some examples of validation that are performed:
Confirm that the data type is valid for a given field.
Make sure fields that are required are populated.
Prevent changes to fields or records that are configured to be read-only.
Validate field values based on comparisons with other fields or static values.
Apply conditional validation so that a field may be required or read-only based on other criteria.
Following are the major physical components that CRM for Microsoft Outlook uses:
CRM Database
This is the database accessed by the CRM application that stores data about customers, contacts, business opportunities, and so on.
CRM Application Server
This is the server that hosts the CRM for Microsoft Outlook application and the related Outlook Web services, and therefore is the main entry point for synchronization requests coming from the CRM for Microsoft Outlook add-in running on users' computers.
Laptop or Desktop
This is the computer where the CRM for Microsoft Outlook add-in is installed, and where users are working with CRM data in Outlook. The Outlook add-in will install binary files that support synchronization of CRM data and integration with Outlook, including support to extend the Outlook data model and user interface, and resource files containing images and strings to initialize the application. The CRM for Microsoft Outlook add-in will connect to the CRM application server and download the appropriate configuration and CRM data for the user which are also stored on this computer.
Corporate Messaging Infrastructure
The corporate messaging infrastructure encompasses all of the server computers and other network topology that support the transmission of e-mail messages, and other personal information management capabilities such as the corporate calendar, contact and task lists.
Following are the CRM for Microsoft Outlook functional components:
CRM Extensions in Outlook
Extensions integrate with Outlook data storage and deliver additional business logic and extensions to the Outlook user interface to allow users to access and modify CRM data. CRM data is viewed with extensions to the Outlook user interface. Changes to CRM data are controlled by business logic and custom controls and then finally stored in Outlook data storage (for example, in a user's mailbox storage file). The user works with a version of the CRM application, as defined in the configuration deployed to the user's computer. Changes to CRM data since the last synchronization cycle are calculated by the synchronization engine during data synchronization with the CRM application server.
Synchronization Engine
The synchronization engine handles requests to initiate a synchronization cycle and is responsible for structuring the requests that are sent to the server. For the initial and incremental synchronization cycles, the synchronization engine manages requests to count records available to the user; sends a request to generate a server snapshot; initiates the process to generate a local snapshot; compares the results; and calculates the necessary requests to be sent to the CRM application server to complete the synchronization of local and server data sets. The synchronization engine works in tandem with the connector to correctly format and transmit messages with the CRM application server.
CRM Connector
This part of the CRM for Microsoft Outlook add-in is responsible for knowing how to connect and communicate with the CRM application server. The connector uses details such as the username, password, connect string, public security certificate, and client metadata to interpret requests from the synchronization engine to correctly format and send requests to the CRM application server. All details of the requests to send to the server are orchestrated by the synchronization engine, but the transmission of the requests and retrieval of the responses is done by the connector. The connector uses the details in the connect string to know where to send requests to the CRM application Web services.
CRM Application Web Service
CRM Web Service provides functionality to handle the user session, and to add, delete, modify, count, and list data objects that are required by the Web service connector.
You can customize the product name displayed by the Oracle Fusion CRM for Microsoft Outlook client, by modifying the package_res.xml client configuration file.
Use an XML editor to open the package_res.xml client configuration file. Create or modify any of the following attributes, as required:
<str key="app_name">CRM for Microsoft Outlook</str>
<str key="pim_name">Outlook</str>
<str key="remote_app_name">Oracle Fusion</str>
For example, in the remote_app_name attribute, change Oracle Fusion to the name of your company.
When a user clicks Send Feedback on the Feedback tab within Oracle Fusion CRM for Microsoft Outlook, a new e-mail message is created, and the e-mail is automatically addressed to the support team. You can customize the support team's e-mail address by modifying the package_res.xml client configuration file.
Use an XML editor to open the package_res.xml client configuration file. In the following code, change email_address to the required e-mail address.
<!-- Feedback page -->
<str key="support_email">email_address</str>
For example:
<str key="support_email">support@your_company.com</str>
You can make Oracle Fusion CRM for Microsoft Outlook fields and forms read-only by modifying the forms.js client configuration file.
Use a JavaScript editor to open the forms.js client configuration file. Find the following code in the configuration file:
// LEAD FORM SCRIPTS //
function lead_form(ctx)
{
The example above shows how to make the Lead field read-only.
To make a field read-only, add the following code below the section of code you have just located:
ctx.form[control_id].enabled = false;
The control_id should be the identifier of the field that you want to make read-only.
To make a form read-only, add the following code below the section of the client configuration file you have just located:
ctx.form.enabled = false;
You can customize the text that appears in the Oracle Fusion CRM for Microsoft Outlook application, by modifying the text strings in the package_res.xml client configuration file.
Use an XML editor to open the package_res.xml client configuration file, and find the text string you want to change. For example, in the following code you want to change the text string "Customer name is required":
<str key="msg_customer_required">Customer name is required.</str>
You change the text string to "Enter a customer name for this organization", and so the code now appears as follows:
<str key="msg_customer_required">Enter a customer name for this organization.</str>
This example demonstrates how to display a custom Oracle Fusion field in a Oracle Fusion CRM for Microsoft Outlook form. This example specifically shows you how to display the Opportunity Number field on the Opportunity form.
Firstly, you need to make the field Opportunity Number available through the Oracle Fusion API, and then customize CRM desktop to synchronize and display the field.
<Type Key="OptyId" Label="#obj_opportunity"...>
<Field FieldName="OptyNumber" FieldType="xsd:string"></Field>
<type id="opportunity" display_name="#obj_opportunity_plural" folder_type="10">
<field id="OptyNumber">
<reader>
<mapi_user>
<user_field id="fsn Opportunity Number" ol_field_type="1"></user_field>
<convertor>
<string/>
</convertor>
</mapi_user>
</reader>
<writer>
<outlook_user>
<user_field id="fsn Opportunity Number" ol_field_type="1"></user_field>
<convertor>
<string/>
</convertor>
</outlook_user>
</writer>
<str key="lbl_opty_number">Opportunity Number:</str>
<!--end opportunity reason win
los-->on the Opportunity form.
<!-- opportunity number -->
<cell size="20">
<stack layout="horz" spacing="3">
<cell size="4"/>
<cell size="100">
<stack layout="vert" padding="2">
<cell>
<static id="lbl_opty_number" tab_order="150">
<text>#lbl_opty_number</text>
</static>
</cell>
</stack>
</cell>
<cell>
<edit id="opty_number" tab_order="151">
<field value="string">OptyNumber</field>
</edit>
</cell>
</stack>
</cell>
<!--end opportunity number-->
<!-- opportunity details -->
<cell size="197">
In Oracle Fusion CRM for Microsoft Outlook, a client configuration file describes a part of the application configuration that resides on the user computer, and it extends the desktop application. Client configuration files can either describe a portion of the application logic implemented as Java script, or can be a declarative configuration of items, such as UI components or synchronization mappings implemented as XML. Each configuration file has a particular type. There can be more than one version of any file type at one time as long as the names differ, and only one file of any given type can be included in a deployment package.
In Oracle Fusion CRM for Microsoft Outlook, a client deployment package is a collection of metadata files that describe the CRM application extensions deployed to users' computers. Access to a given deployment package is given to CRM application users through a privilege associated with their job role. When a user connects to the CRM application server to synchronize data from a desktop application like Microsoft Outlook, the application determines if any changes to the package have occurred, and if so, downloads any changes.
In Oracle Fusion CRM for Microsoft Outlook, the client configuration validation file (.xsd) describes the structure of a valid client configuration file (.xml). The application uses the client configuration validation file to check that any client configuration file imported to the server is structured correctly and complies with the requirements of the validation file. The validation process happens automatically during the import of any client configuration file, and helps catch misconfigured files.
The Oracle Fusion CRM for Microsoft Outlook application uses a file to identify and map services and view objects that are used when processing synchronization requests, and to correctly query, insert, update, and delete data on the server. There is only ever one of these files used at a given time, and changes made to it are recognized by the application and loaded immediately.
Oracle Fusion Customer Center enables the comprehensive management of customer information. Customer Center collects data from various systems and presents them for management in one location.
Following are some of the capabilities of Customer Center:
Create customers and contacts
Update customers and contacts
Maintain customer hierarchies
Maintain competitor information
When working with Customer Center, be aware of the following terminology used through out the application:
Sales prospect
Sales account
Customer
Legal entity
Billing account
A sales prospect is a prospective sell-to entity, or person, at an existing or potential customer used to define Leads. A prospect is the lowest level representation of a business entity that your company's marketing processes will track and act upon. The sales prospect does not have a sell-to address. You can create a sales prospect from a party that does not have a sell-to address when you create the first lead for that party. You can also create sales prospects in Customer Center and by importing them in bulk.
You can create leads against sales prospects, but a sales prospect must be qualified and converted to a sales account before you can create opportunities for it. To qualify and convert a sales prospect, a set of business criteria or rules must be satisfied. For example, the prospect may be required to meet the criteria for account assignment.
A sales account is a specific sell-to entity within a given customer. You can create leads and opportunities against sales accounts. A single customer might have a collection of sales accounts. To avoid confusion when assigning territories to the account, each sales account has only one sell-to address. Typically, a sales team manages a sales account. The sales team is comprised of resources assigned to the territories associated with the sales account. Additionally, a profile option determines whether a sales account is a named sales account, an existing sales account, and the account owner. Named sales accounts are typically strategic accounts assigned to dedicated territories. An existing sales account is one where there is an existing financial relationship or had previous installs. You can create sales accounts in Customer Center and by importing them in bulk.
Within Customer Relations Management (CRM), sales accounts and sales prospects are collectively referred to as Customers. There are three types of customers: Organization, Person, and Group. Additionally, a Customer also can have representations as a legal entity and a billing account that are expressed as root nodes in a hierarchy to the respective sales accounts for that customer.
View the Customer Hierarchy: A customer's hierarchy represents a holistic view of the customer's structure, showing you the customer type, the parent for the customer, the subsidiaries of the customer, as well as rolled up revenue analysis data.
A legal entity is a party that can enter into legal contracts or a business relationship, and be sued if it fails to meet contractual obligations. There are two types of legal entities: internal and external. A customer with a party usage of Legal Entity is considered an internal legal entity and is used for interdivisional selling within your own company. A customer with a party usage of External Legal Entity is any external customer who fits the definition of legal entity. Legal entities may also be used to group multiple sales accounts, sales prospects and other classes of entities or parties.
A billing account is a party that represents the financial account transactional entity for a given Customer.
There are two types of Oracle Fusion Customer Center trees. Each tree displays a different set of nodes based on party type. The information that you are able to view and edit on each node depends upon your security privileges and your membership status on the sales account team
The two types of Customer Center trees are:
Customer Tree
Contact Tree
The customer tree displays similar nodes for the three customer types, organization, person, and group, such as Profile, Contacts, Sales Account Team, or Assessment. If you are a member of the sales account team with at least Edit level access or you have the Sales Party Administration duty, you can update information on the following nodes: contacts, organization chart, classifications, assessments, and notes. Only those users with Sales Party Administration duty or Full level access on the sales account team and profile nodes can update the members of the sales account team
The contact tree displays nodes for contacts with the contact profile and other related information such as the Profile (contact details), interactions with the contact, notes, and so on. Leads and Opportunity applications can be accessed here. All nodes on the contract tree are visible to all users.
Customer center tree is a navigation paradigm which enables quick and easy access to various related information in one central place. Seen on the regional area of the page, the tree is made up of object nodes such as Profile or Contacts. These object nodes can be categorized into logical categories. Categories enable you to organize those object nodes to fit your needs, for example, the Sales category or Service category. Each implementation can customize the Customer Center tree by showing or hiding the various nodes as required, and configuring node names and other parameters. When saved, the personalizations for this view of the tree are kept for all users of the application. Individual users will have capability to further personalize the tree as desired.
Set these attributes for each node in the Customer Center Tree:
Name - the name shown in the customer center tree UI.
Visible - indicates whether the node will be visible in the customer center tree.
Important
All tree nodes that render portlets are delivered with the Visible check box unselected. To show the portlet, select the Visible check box.
Default - the node shown when a user drills down into the customer center tree.
Portlet - indicates whether the node is a portlet or a local task flow. A portlet is a non-local task flow residing in another business process. For example, when accessing the Opportunities node in the Lead Management application, the Opportunities node is a portlet because the Opportunities task flow resides in the Sales applications, outside of the local Lead Management application. Each Fusion application using Customer Center is delivered with the appropriate portal information already configured and should not be changed. All tree nodes that render portlets have the 'Visible' flag turned off. If the portlet is required to be visible, the 'Visible' flag needs to be changed to show the node.
Parameters - specify input variables and values for the node. There are only three nodes that require parameters. These nodes are specifically for third-party integration: OneSource Profile, Service Requests, and Snapshot:
OneSource
Profile parameters: token=#{'{OneSource
token}'}
Replace {OneSource token} with your OneSource access token. For
example, if your OneSource token is 'token', set the OneSource Profile parameter as: token=#{'token'}. Or, if you do not require a token to access OneSource, simply replace {OneSource token} with NULL; set the OneSource Profile parameter as: Token=#{''}
Service Requests
parameters: HostName=#{'{Siebel server
path}'};SSLEnabled=#{'[true|false]'};UserName=#{'{username}'};Password=#{'{password}'};System
Name=#{'{reference system name''}
Set host name to be your Siebel server
path, for example, HostName=#{'hostname.siebel.com/
CALLCENTER_enu/start.swe'}
Set SSLEnabled to true or false,
for example, SSLEnabled=#{'false'}.
Set UserName to be your Siebel system
login, for example, UserName=#{'USER'}.
Set Password to be your Siebel system
password, for example, Password=#{'PWD'}.
Set System Name to be your source
system name as defined in the Original System References mapping table,
for example, System Name=#{'SIEBEL'}. The default value is 'SIEBEL' if this parameter is not specified.
Example Service Requests parameter: HostName=#{'hostname.siebel.com/CALLCENTER_enu/start.swe'};SSLEnabled=#{'false'};UserName=#{'USER'};Password=#{'PWD'};System
Name=#{'SIEBEL'}
Snapshot
node parameter: HostName=#{'{Siebel
server path}'};SSLEnabled=#{'[true|false]'};UserName=#{'{username}'};Password=#{'{password}'};System
Name=#{'{reference system name''}
The Snapshot node parameter is the same as the Service Requests node and thus needs the same parameters as those for the Service Requests node.
Oracle Fusion Customer Center is a central location to access a comprehensive and multifaceted view of customer information. It unifies Fusion applications data as well as relevant third-party content.
OneSource and Siebel Service are two third-party integrations readily configured in Customer Center. This topic explains how third-party customer content is mapped to Fusion customer.
OneSource to Fusion Mapping
OneSource, an online source of business and company data, can be accessed directly from the OneSource node in Customer Center.
Customer Center conducts searches for OneSource company data in the following order:
Look up based on mappings defined
in HZ_ORIG_SYS_REFERENCES table where orig_system is ONESOURCE.
Look up based on Fusion customer
stock symbol. This is checked if mapping is not found in HZ_ORG_SYS_REFERENCES.
Look up based on Fusion customer name. This is checked if mapping is not found by stock symbol lookup. If there are multiple OneSource companies match the Fusion customer name, user can choose from the list of matching OneSource companies.
Siebel Service to Fusion Mapping
Mappings for Siebel
accounts to Fusion customers are maintained in the HZ_ORIG_SYS_REFERENCES table, where orig_system is SIEBEL.
Note
Customer Center does not include licenses for OneSource and Siebel applications. Third-party application licenses may be acquired separately. If you want to enable OneSource and you have a web proxy for external HTTP(S) traffic, you must select Enable Web Proxy on the Web Proxy Configuration screen and specify your web proxy configuration.
See Also: "Web Proxy Configuration" in the chapter "Creating a New Provisioning Plan" of the Oracle Fusion Applications Installation Guide
Personalizing the Oracle Fusion Customer Center tree enables you to have a more intuitive navigation experience. The tree, located in the regional area of the page, is made up of object nodes such as Profile or Contacts. To personalize the tree, use the Action menu located directly above the tree or right click on any tree node, and click Manage Customer Tree in the menu popup. The Manage Customer Tree window will pop up. Select the node you wish to modify. You can change the name, whether the node is visible or not and if it should the default node that will display upon opening the tree. When you save, the customization will be associated to your user name.
Assessment templates let you analyze the health of a business object, such as a lead or an opportunity, and suggest appropriate next steps based on its diagnosis. To best plan and create assessment templates, you should consider the following points:
Ratings
Questions, Question Groups, and Question Weights
Responses and Scores
Associated Task Templates
A rating is a textual qualification such as Excellent. There are three delivered ratings in the assessment template: Excellent, Average, and Poor. Ratings provide a metric other than a numerical score for qualifying the outcome of an assessment. Ratings are created at the beginning of the assessment template creation process. They are later applied to possible responses to questions in the template, which associates each rating with a score. An appropriate feedback will be displayed to you based on the completed assessment score once you submit an assessment. When setting up ratings and applying them to possible responses, it is important to remember that they and their associated feedback text will eventually display as part of the overall assessed health of a business object.
Questions are the main components of an assessment template. They are written such that they aid in systematically determining the health of a business object, and they are grouped into logical collections called Question Groups. Each question in the template is assigned a question weight, expressed as a percentage, which is the relative importance of the question within the template. When an assessment template is used to perform an assessment, a question's weight is multiplied by the normalized response score given for the question to produce a weighted score for that question. When setting up questions, question groups, and question weights, it is important to carefully analyze which factors determine the health of a particular business object (like a lead or an opportunity) in your organization. Use those factors to create your question groups; and then, for example, write three to five questions per group that are weighted according to your analysis. There is no limit to the number of questions that can be in a question group, but each question group must have at least one question.
Responses are attached to questions in the template. Each question should have at least two responses, unless it's a free-form only question. More than one response can be tied to the same rating but, between all of its responses, each question should accommodate at least two ratings, unless it's a free-form only question. For example, if your ratings are Excellent, Average, or Poor you may, for each question, include two responses that correspond to at least one of those ratings, such as average. There must be enough responses to cover at least two of the ratings such as Excellent and Average. You assign a score to each response for a question, and the application normalizes the score based on a standard scoring scale. When an assessment template is used to perform an assessment, a question's weight is multiplied by the normalized score of the response given for the question to produce a weighted score for that response. When adding responses to questions, ensure that the scores and ratings you assign to each response correlate. In other words, the higher the score you assign to the response, the higher the rating should be so that you have a strong quantitative relationship between the two. Also note that you can allow free-form responses for one or more questions in the template, but free-form responses are never scored.
A task template is an instruction to generate a group of related activities. You can associate task templates with an assessment template in order to recommend tasks that should be performed after an assessment has been done for a business object. When you associate task templates with an assessment template, you can indicate a score range for each task template, and based on the total score of any assessment that uses your template, one or more task templates will be recommended as follow-up activities. In order for a task template to be available to associate with an assessment template, it must be assigned to the same business object type as that assigned to the assessment template, and it must have a subtype of Assessment. Ensure that you have set up task templates correctly before attempting to associate them to assessment templates.
Throughout the life of an assessment template, it can be assigned several different status codes.
These status codes control the actions you are allowed to make against an assessment template.
In Progress
Active
Retired
This is the initial status of an assessment template. When an assessment template is at this status, you can edit any part of it. This is the only status at which you can delete a template. If the template is not deleted, it moves to the Active status next.
This is the status assigned when the assessment template has been deployed for general usage. When an assessment template is at this status, you can make only minor textual edits to it, including, but not limited to, template description, question text correction, question sequencing change, response description, and score range feedback. From this status, you can move the template to Retired; you cannot delete it.
When an assessment template is at this status, it is no longer available for general usage. You cannot edit any part of it, and you cannot move it to any other status; however, it can still be copied. Active templates that are deleted revert to this status.
The application calculates the score range for an assessment template using the question weights and the ratings and scores assigned to the possible responses for all the questions in the template. This topic explains when the score range is calculated and the components that are used in the calculation, so that you can make the best decision regarding the feedback text to apply to each score range. In addition to the automatic score range calculation, a manual method for adjusting score range is also available on the administration UI.
In order for the application to calculate the assessment template score range, you must:
Apply weights to all template questions.
Configure ratings and apply them to possible responses for all template questions.
Apply a score to each of the possible responses for all template questions.
The score ranges for each rating in an assessment template are determined using the lowest and the highest weighted response scores for each question. So for each rating score range, the lower end of the range starts where the previous rating range ended, and the higher end of the range is the sum of the highest weighted scores that can be attained for that rating.
This table displays a simple example of the components used in the score range calculation.
|
Question (Weight) |
Response (Normalized Score) |
Weighted Score |
Rating |
|---|---|---|---|
|
What is the customer win? (20%) |
Lower Operating Cost (100) |
20 |
Excellent |
|
Higher Revenues (80) |
16 |
Average |
|
Other (53) |
11 |
Average |
|
Don't Know (27) |
5 |
Poor |
|
What is our win? (80%) |
Reference (60) |
48 |
Average |
|
Resale (50) |
40 |
Poor |
|
Partnership (100) |
80 |
Excellent |
This table displays the score range calculation based on the components from the first table.
|
Rating |
Score Range |
|
|---|---|---|
|
Excellent |
65 - 100 |
|
|
Average |
46 - 64 |
|
|
Poor |
0 - 45 |
|
Note
If a template administrator does not use a particular rating while assigning ratings to possible responses, this could result in improper score range calculations. To counteract this problem, the score range calculation uses a built-in correction algorithm to ensure proper score ranges. The correction algorithm works like this: For a question where a particular rating is skipped, the low score for the skipped rating is calculated to be equal to the high score of the next lower ranked rating. The high score for the skipped rating is calculated to be equal to the low score of the next higher ranked rating.
Using the ratings displayed in the tables above, if the rating Average is not used for a question's possible responses, the score range calculation assigns a low score to Average for that question that is equal to the high score of Poor for that question. It also assigns a high score to Average for that question that is equal to the low score of Excellent for that question. This ensures that the overall template score range for Average is calculated to fall between the score ranges for Poor and Excellent.
A task is a unit of work to be completed by one or more people by a specific completion date. When using tasks in your application, you should consider the following points:
Tasks
Task Templates
A task is defined with a description, due date and category. Each task has an owner, who oversees or is responsible for the task, and one or more assignees who perform the work. The task can be related to a business object, such as an Opportunity, a customer or, one or more external contacts. Tasks may also have Notes for general information, Attachments for tracking e-mail or project documents and Interactions which record customer communications.
Often a set of Tasks are performed repeatedly for a particular process and to support this administrators can define Task Templates, which represent a group of tasks. These task templates can be invoked by users working on a particular business object, for example a lead, campaign, or an opportunity. The user selects the appropriate task template for the goal they want to achieve and this creates the tasks and associates them with the business object being worked on. This saves the user from creating multiple tasks when an Opportunity reaches a particular sales stage, or the same set of tasks each time a marketing campaign is created.
Note
Extensibility features are available on the Task object. For more details refer to the article Extending CRM Applications : How It Works
One of the steps for creating an assessment template is associating task templates. You would take this step if you want to recommend sets of tasks to be done after an assessment is performed using your template. You associate task templates to ranges of scores in the assessment template, and where the overall assessment score falls within those ranges determines the tasks that are suggested to be performed after the assessment.
An assessment template is a set of weighted questions and possible responses used to evaluate the health of a business object such as an opportunity or a lead. An assessment template can be associated with one or more task templates that are recommended based on the outcome of an assessment.
A task template is an instruction to generate a group of related activities. By marking a task template with a subtype of Assessment, you make that task template available for association with assessment templates. The task template's business object type should be the same as that assigned to the assessment template. When an assessment is performed using an assessment template that has associated task templates, one or more task templates are recommended based on the total score of that assessment and can be used to generate a list of activities to perform.
For example, you can associate a task template called Engage Business Development Manager with your assessment template called Potential for Win-Win. Associate the task template with the score range of 86 to 100, so if an assessment using the assessment template Potential for Win-Win scores within that range, the application recommends the Engage Business Development Manager task template and a list of follow-up activities based on that template can be generated.
A score of 0 is assigned for free-form responses.
A free-form response option will have no effect on the overall assessment score. The free-form response offers the opportunity to enter a textual response to a question that does not conform to any of the pre-populated responses provided by the assessment template.
A question group is a logical grouping of questions within an assessment template, and it is used strictly as a category header for those questions. Through careful naming of a question group, you can achieve the benefit of providing the user of the template with an approximate idea of the type of questions to expect in each group.
This step lists all of the assessment template questions in one place, and provides you with the opportunity to edit weights as necessary to ensure that the sum of all weights totals 100.
There are three types of sales account team memberships known as access levels.
These access levels control the team member's privileges for the sales account:
View Only
Edit
Full
When a resource is initially added to the sales account team, a profile option setting determines the member's default access level. If that member is removed from the sales account resource team, she no longer has access to the sales account, unless she is still a member of a territory that is assigned to the sales account. Resources in the management hierarchy of a newly added team member inherit the same access level of the subordinates.
View Only is the minimum level assigned to a sales account team member. This access level enables the team member to view the contents of the sales account child attributes such as sales account team, snapshot, assessments, discussion forums, notes, interactions, appointments, and tasks. This assumes, however, that the team member also has functional access to view that child attribute. If the team member's resource role does not provide functional access to view a particular child attribute of a sales account, that member cannot view the attribute, regardless of her sales account team access level. A team member with View Only access level for a sales account can view only the opportunities, leads, and revenue lines to which she has relevant data privileges.
Sales account team members with the Edit access level can view and edit all customer-related objects. They can view and edit only the opportunities, leads, and revenue lines to which they have the relevant data privileges. The Edit access level provides a sales account team member with the ability to run the territory reassignment process, but she cannot change the composition of the sales account resource team.
The Full access level allows team members to do everything that the Edit access level allows, with the addition of being able to change the composition of the sales account resource team. A team member with Full access can manually add and remove team members, change a member's access level, and mark the lock assignment setting for team members. When a sales account is created, only the sales account owner and sales administrators are granted the Full access level, but they can grant Full access to other team members.
Access for the Territory owners and members parallels that of the Sales Team members.
These access levels control the internal and partner territories privileges for the sales account:
Internal territory owner: Full access
Internal territory members (non-owner): Edit access
Partner territory owner and members: View-only access
Note
Territory Management must be implemented to utilize this feature.
The work object, candidate object, and attributes are components that fit together to create assignment objects that are used in rule-based and territory-based assignment. Work objects are business objects that require assignment, such as leads and opportunities. Candidate objects are business objects, such as resources and territories, that are assigned to work objects.
When you create candidate objects, you can select attributes for them that are later used in rules or mappings. These candidate objects also become candidates that are available for association when you create work objects. When you create work objects, you can select attributes for them also, as well as associating one or more candidates.
A work object is a business object that requires assignment such as a lead or an opportunity. Creating a work object involves entering its application information, selecting its attributes to use during assignment, and associating one or more candidates.
A candidate object is a business object, such as a resource or a territory, that is associated with one or more work objects for eventual assignment. Creating a candidate object involves entering its application information and selecting its attributes to use in rules or mappings. A special type of candidate object is a classification object. This type of candidate object does not represent a business object that gets assigned to a work object. It is used only with classification rules and is used primarily to rank or qualify leads.
Note
As candidate objects are created, they become available as candidates that can be associated with one or more work objects as part of the work object creation process.
The administrator needs to define the association between the work object and candidate object. For example, the Lead work object may have an association with both the Territory candidate object and the Resource candidate object. This implies that Assignment Manager can be used to assign Territories and Resources to a lead.
In the related Candidates tab for the Revenue work object an administrator can define the association between the work object and candidate object. For example, the revenue work object may have an association with both the territory candidate object and the credit allocation template candidate object. This association indicates that Assignment Manager can be used to assign both territories and credit allocation templates to revenue lines.
To relate a candidate object to a work object, use the following fields:
Assign Candidates: Indicates that Assignment Manager performs the assignment. If not set, then Assignment Manager is used to find the matching candidates, which are then passed to the calling application to update the work object.
Custom Logic: Indicates that Assignment Manager passes the result of the assignment matching to the callback function of the work object. For example, Opportunity Management uses custom logic that updates the sales team with the territory members. It stamps the territories onto the revenue line and adds the territory team members (resources) to the opportunity sales team.
Merge Assignment Candidates: Controls whether the matching assignment candidates identified from processing each set of mappings should be merged. This is used to drive the merging of matching candidates when multiple mapping sets are used in assignment processing. If the check box is checked, then the candidates are merged. The default is unchecked.
Keep Manual Candidates: Indicates that manually assigned candidates are retained during assignment processing. This option can be used to prevent the removal of manually added candidates during reassignment. Sales Account and Opportunity Management have implemented their own lock assignment features.
Replace Candidates: Determines whether unqualified candidates are removed from a team when an assignment runs. For example, the first time that Assignment Manager runs, a territory is assigned to a sales lead. When the reassignment process runs following a territory proposal activation, the territory is no longer valid. If Replace Candidates is set, then the territory is removed from the sales lead.
Candidate Exclusion: Sales leads have a related object, which stores the excluded candidates for each sales lead. Assignment Manager accesses this information, which prevents assignment of the work object to an excluded candidate.
Parent Attribute: Used by territory based assignment to determine the hierarchy of matching territories, eliminate all parent territories, and only return and assign the matching leaf node Territories. If this attribute is not used, then all matching territories (parent or leaf ) are returned and assigned.
Candidate Differentiation Attribute: Stores the attribute on the candidate object that is used for discriminating matching candidates. For example, in Revenue line assignment, this attribute enables matching leaf territories of many territory types (such as Prime, Channel Sales Manager, and so on) to be assigned. The Candidate Discriminator Attribute is only relevant for territory-based assignment and can only be selected if a parent attribute has been selected.
Coverage Attribute: The territory attribute used to denote whether the candidate in the matching candidate list has a regular, included, or excluded coverage.
Maximum Number of Candidates: The maximum number of candidates returned for the work object and candidate object combination. The default value is 100.
Manual Attributes: The attribute that identifies a candidate was manually assigned, rather than by the system. This attribute is used with the Keep Manual Candidates attribute.
Keep Manual Candidates: A flag to retain manually assigned candidates when assigning or re-assigning a work object. This option is only relevant if the manual attribute is defined and the Assigned Candidates option is checked.
Replace Candidates: Indicates whether non matching candidates will be removed when re-assigning a work object. In an example scenario, in the first time assignment runs, territory A is assigned to a sales lead and there is a change within the territory definition. When the sales lead is reassigned, territory A is no longer valid. If this option was selected, then territory A is removed from the sales lead.
Score Attribute: The score attribute in which the calculated score is stored.
System Attribute: The attribute that identifies a candidate was assigned by the system, rather than manually.
Attributes are elements in the view object defined for an assignment object. For each assignment object, you can select one or more attributes that you want to use when configuring assignment rules or mappings. For example, for a work object like sales account, you might choose the attributes of Named Account Flag, Customer Size, and Organization Type. When you configure assignment mappings for the sales account work object, your chosen attributes are available. You could create a mapping for Sales Account using the Named Account Flag attribute.
When selecting attributes for a candidate object, you will not only select the attributes you want to use when configuring assignment rules and mappings that involve that candidate object, but you also want to select the attributes for that candidate object that you want to appear in the screen that displays recommended candidates after assignment manager is run. For example, if a candidate object is resource (sales representative), and you want to show sales representatives' first names, last names, and phone numbers when they are recommended during assignment processing, you need to select the attributes for the resource candidate object that correspond to first name, last name, and phone number, and specify the order in which these attributes appear in the recommended candidates screen.
Note
This feature is not used by any CRM applications at this time.
The Manage Assignment Objects pages enable you to define and edit the Work and Candidate objects as well as define any territory-based mappings. The figure above shows the relationship between the work and candidate objects and the mapping of the matching candidates to work objects.
When you add or edit a work or candidate object there are several key pieces of information that are required in the definition:
Name: a unique name for the object with an optional description.
Code: a unique code used in processing the object.
Work/Candidate Object check boxes: indicates if the object is a work object, candidate object or both.
Application Module: an Oracle Application Development Framework (ADF) business component that encapsulates the business service methods and UI-aware data model for a logical unit of work related to an end-user task. Enter the fully qualified definition name of the consumer application, Application Module. Valid for top level Work and Candidate objects. Child objects automatically inherit this value from its parent.
Application Module configuration: Valid for Top Level Work and Candidate objects except Classification Candidate objects. Child objects will automatically inherit this value from its parent.
View Object Instance: used to define the data model of a view object component when designing an application module, for example, Opportunity. Valid for all levels of Work and Candidate objects except Classification Candidate objects.
View Criteria may be defined to filter the information for the rows of a view object collection. Valid for top level Work and Candidate objects except Classification Candidate objects.
Primary Key Attribute 1: First or only attribute that makes up the object primary key. Valid for top level Work and Candidate objects except Classification Candidate objects.
Refresh Interval: the number of minutes between refreshes of candidate object data. The default setting is 0 minutes. Valid for top level Candidate objects except Classification Candidate objects.
Initial Caches: The initial size of the cache when processing an object. This value will be used the first time the engine processes objects or following a server bounce. The default value is 2, and the maximum value is 20. Only valid for top level Candidate objects except Classification Candidate objects. All Work Objects that are used for scoring, Lead, for example, use the Product Level (MOW_SCORING_INITIAL_CACHES) Initial caches for scoring rules profile option value.
Maximum Caches: The maximum size of the pool/cache when processing the object. The default value is 5, and the maximum value is 25. Only valid for top level Candidate objects.
Note
All Work Objects that are used for scoring, Lead for example, use the Product Level (MOW_SCORING_MAX_CACHES) Maximum caches for scoring rules profile option value.
Score Attribute: The attribute on the object that stores the total calculated score after an assignment request has been processed. Valid for top level Work objects only.
Assignment Date Attribute: The attribute on the object that stores the assignment date after an assignment request has been processed. Valid for top level Work objects.
Exclude Assignment Attribute: The attribute on the object that stores the setting for excluding a work object from assignment. Valid for top level Work objects.
Assignment Manager allows users to specify a set of attributes from the assignment object VO to be used during the assignment evaluation. The assignment engine will load these Assignment Object Attributes for each assignment object VO row, in addition to any primary key or assignment attributes. This is designed to improve performance by not loading those attributes not used for the assignment evaluation.
Assignment Object Attributes should be defined for each work object and any child objects as well as each candidate object to be used by the Assignment Engine.
View Object Attribute: Name of each attribute in the view object defined for the assignment object. Assignment Rules or Mappings can be configured using these attributes. For Candidates Objects, the attributes that appear in the interactive assignment UI should also be selected.
Candidate Information Sequence: The sequence that this attribute is displayed in the Interactive Assignment UI.
Assignment mappings drive territory-based assignments. These mappings identify the dimensions, attributes, and territory filtering used in territory-based assignment processing. Dimension mappings and some attribute mappings have a sequence which controls the order in which these mappings are used during territory matching. Mappings that do not have a sequence are used together at the end of the matching process. A default set of mappings is seeded. This seeding assumes that opportunities, leads, and sales accounts use the same territory hierarchy.
Assignment Manager has an indicator in the related Candidates region to control whether to merge the matching assignment candidates identified from processing each set of mappings. This indicator is used to drive the merging of matching candidates when multiple mapping sets are used in assignment processing. If the box is checked, then the candidates are merged. The default is unchecked.
You can use the following assignment mappings:
Attribute Mapping: An example is assigning territories to a sales lead where the territory partner program ID is the same as the sales lead partner program ID. In this case, the territory is matched when the territory program ID is equal to the sales lead attribute program ID.
Dimension Mapping: An example is assigning territories to opportunity revenue lines based on the product associated with the revenue line. In this case, the product dimension is selected as the mapping type. The candidate object low attribute and high attribute correspond to the names of the low sequence and high sequence attributes for product on the territory. The work object low attribute and high attribute correspond to the names of the low sequence and high sequence attributes for product on the revenue line.
Mapping using alternative attributes: Using the same scenario, if a revenue line does not have a product assigned to it, but has a product group assigned, add the low sequence and high sequence attributes for product group are entered for the work object alternate low and high attributes.
Mapping using default values: Using the same scenario, if the low sequence and high sequence attributes for product on a specific revenue line do not contain values, then the low and high default values for the product attribute for all revenue lines are used.
Literal Mapping: A way of filtering
the matched territories based on specific values of a territory attribute.
For example, by only matching with territories that have a sales account
centric coverage model. For example, territory coverage model equals SALES_ACCOUNT_CENTRIC.
Assignment is the process for selecting a candidate as an object and executing the association to a work object. Assignment consists of two phases. The first phase is the matching phase, where matching rules or mappings are evaluated to find the right assignees from a list of possible candidates. The second phase is the disposition phase, where the disposition, or assignment, of matching candidates is handled. Assignment Manager is the tool used to establish the business objects that require assignment, and to create the rules and mappings that dictate the selection and assignment of resources and territories. Candidates are potential assignees for a work object. A work object is a representation of an application business object inside Assignment Manager. A work object captures the attributes of a business object and associated child objects to be used for matching purpose. To best plan the configuration of Assignment Manager, you should consider the following points:
Business objects
Attributes
Resources and territories
Assignment disposition
Mappings sets and mappings
Rules
A business object is a data entity or a collection of data treated as a unit, such as a sales account, an opportunity, or a lead. Any business object that requires the assignment to act upon it is considered a work object by Assignment Manager. The work object is a representation of the business object, and mappings and rules are developed to ensure timely and accurate assignment of candidates (for example, territories or resources) to those work objects. When configuring Assignment Manager, carefully consider which of your business objects require assignment, and create work objects only for those that do.
A set of business or assignment objects is seeded for the assignment of territories or resources to sales accounts, opportunities, and leads.
After you determine the business objects (work objects) that require assignment and the candidate objects that you will assign to them, you must decide how the matching candidate assignment disposition will be carried out. Consider these questions:
Do you want to assign a single resource or multiple resources?
Do you want to automatically assign matching candidates or run custom logic against matching candidates?
Do you want to record the matching candidate score on the work object?
Do you want to retain manually assigned candidates when assignments are processed?
Do you want to replace disqualified candidates when assignments are processed?
To ensure that candidates are properly assigned to work objects, create mappings and rules. These mappings and rules employ attributes to determine the best assignments. As you set up work objects and candidate objects in Assignment Manager, also select the attributes of those objects that you want to use in your mappings and rules. For example, you might want to assign a resource such as a specific sales representative to a business object, such as opportunity, based on the risk level of the opportunity. In this case, when you create the opportunity work object and the sales representative candidate object, you will select the attribute of opportunity that corresponds with risk level, and the attribute of the sales representative that corresponds with skill name or e-mail address. Selecting these attributes makes them available for mappings and for conditions on your rules, so ensure that you select the attributes that reflect the criteria that you want to use for matching candidate objects to work objects.
Assignment mapping sets and their related mappings drive territory-based assignment. The mapping sets determine which mappings are used and the sequence mapping sets are used in territory-based assignment. The mappings identify the dimensions, attributes, and territory filtering used in the assignment processing. Default mapping sets and their related mappings are seeded. This seeding assumes that opportunities, leads, and sales accounts use the same territory hierarchy.
Create the mappings using the work objects, candidate objects, and attributes that you already established. When designing your mappings, carefully consider the dimensions and attributes you use in your territory structure and how you want to match these territory candidates to work objects. Also consider the shape of the information used in the territory structure; this may affect the sequence of each mapping. The sequence of the dimension mappings used in territory matching can affect performance. The most selective dimension mapping should be given lowest sequence number. By default, this dimension is the Geography Dimension. By using the lowest sequence number, it is performed earliest in the matching process which results in the smallest number of territory matches. This same approach should be followed for the remaining dimension and applicable attribute mappings.
Rules are defined for the execution of rule-based assignment. Rules are designed to return candidates based on whether these candidates match a set of criteria, are within a defined scoring range, or are of a specific classification.
Create the rules using the work objects, candidate objects, and attributes that you already established. When designing your rules, carefully consider how you want to match candidates to work objects. For example, would you want resources assigned based on their geographic location, their product knowledge, on the status or score of an object, or a combination of any of these attributes? Do you want to match candidates only, or would you like to match candidates and score them? In a multiple-candidate scenario, do you want to assign all matching candidates or only those who achieve higher than a specific score? Consider these questions before creating rules.
Territory-based assignment is based on intelligent mapping of sales account assignment object attributes and sales territory dimensions. The Sales Account Assignment object is used by Assignment Manager to identify the sales accounts and then determine which territories to assign. The table below lists sales account assignment object attributes and corresponding customer attributes as shown in Customer Center Profile and Classification nodes. See Configuring Assignment Manager: Critical Choices for more information about the assignment process.
|
Sales Account Assignment Object Attribute |
Corresponding Customer Center Attribute |
|---|---|
|
Geography ID |
Sell-to Address |
|
Industry |
Primary Industry: the primary classification code for the classification category defined in profile option Industry Classification Category. |
|
Organization Type |
Primary Organization Type: the primary classification code for the classification category Organization Type defined in profile option Industry Classification Category. |
|
Customer Size |
Customer Size |
|
Named Account Type |
Named Sales Account Indicator |
|
Party ID |
Party ID |
|
Auxiliary Dimension 1 |
the primary classification code for the classification category defined in profile option Industry Classification Category for Auxiliary Dimension 1. |
|
Auxiliary Dimension 2 |
the primary classification code for the classification category defined in profile option Industry Classification Category for Auxiliary Dimension 2. |
|
Auxiliary Dimension 3 |
the primary classification code for the classification category defined in profile option Industry Classification Category for Auxiliary Dimension 3. |
For territory-based assignment, you create work-object-to-candidate-object mappings during assignment object creation. These mappings are used to make candidate assignments. You can create multiple types of mappings for assignments. The following scenarios illustrate these different mappings:
Creating an attribute mapping
Creating a dimension mapping
Creating a literal mapping
You want to assign territories to a sales lead when the territory program ID is the same as the sales lead program ID. Create a mapping where the work object is sales lead and the candidate object is sales lead territory. Select the territory when the attribute territory program ID is equal to the sales lead attribute program ID.
Another example would be if you want to assign territories
to a sales lead based when the territory manual account inclusion
or exclusion is the same as the account on the sales lead. Create
a mapping where the work object is sales lead and the candidate object
is sales lead territory. For this example, select the product attribute
as the mapping type and enter the value Acct for the function code.
Enter a value for the sequence which determines the order in which
the mapping is used when matching territories. The most selective
dimension or attribute mapping should be given lowest sequence number,
the next most selective dimension or attribute mapping should be given
the next sequence number. This mapping matches the territory when
the territory partner attribute account node integration ID, AccoutnNodeIntgId, is equal to the sales lead
attribute party ID.
You want to assign territories to opportunity revenue
lines based on the product associated with the revenue line. Create
a mapping where the work object is opportunity revenue line, and the
candidate object is territory. Select dimension as the mapping type
and enter the value Prod for the
function code. Enter a value for the sequence which determines the
order in which the mapping is used when matching territories. The
most selective dimension mapping should be given lowest sequence number.
The candidate object low and high attributes correspond to the names
of the low sequence and high sequence attributes for product on the
territory. The work object low and high attributes correspond to the
names of the low sequence and high sequence attributes for product
on the revenue line. For example, the low sequence attribute for product
on the revenue line might be called InventoryItemId.
Mapping using alternative attributes:
Using the same scenario of assigning territories to opportunity revenue
lines based on the product associated with the revenue line, you might
encounter a situation where a revenue line does not have a product
assigned to it, but it does have a product group assigned to it. Create
the same mapping that you created for the dimension mapping scenario,
and add the names of the low sequence and high sequence attributes
for product group for the work object alternate low and high attributes.
For example, the alternate low sequence attribute for product group
on the revenue line might be called ProdGrpId.
Mapping using default values: Using the same scenario of assigning territories to opportunity revenue lines based on the product associated with the revenue line, you might encounter a situation where the low sequence and high sequence attributes for product on a revenue line do not contain values when assignments are processed. Create the same mapping that you created for the dimension mapping scenario, and add low and high default values for the product attribute for revenue lines.
Literal mappings are a way of filtering the matched territories based on specific values of a territory attribute. You want to find only territories that have a sales account centric coverage model. For example, territory coverage model equals SALES_ACCOUNT_CENTRIC.
A task is a unit of work to be completed by one or more people by a specific completion date. When using tasks in your application, you should consider the following points:
Tasks
Task Templates
A task is defined with a description, due date and category. Each task has an owner, who oversees or is responsible for the task, and one or more assignees who perform the work. The task can be related to a business object, such as an Opportunity, a customer or, one or more external contacts. Tasks may also have Notes for general information, Attachments for tracking e-mail or project documents and Interactions which record customer communications.
Often a set of Tasks are performed repeatedly for a particular process and to support this administrators can define Task Templates, which represent a group of tasks. These task templates can be invoked by users working on a particular business object, for example a lead, campaign, or an opportunity. The user selects the appropriate task template for the goal they want to achieve and this creates the tasks and associates them with the business object being worked on. This saves the user from creating multiple tasks when an Opportunity reaches a particular sales stage, or the same set of tasks each time a marketing campaign is created.
Note
Extensibility features are available on the Task object. For more details refer to the article Extending CRM Applications : How It Works
The Sales Account assignments process can be scheduled and run on the Scheduled Process page. You need to have the 'Run Sales Party Batch Assignment' privilege to be able to define and run sales account batch assignment.
To access the Scheduled Process page, start on the Fusion Home page and click Navigator. Under the Tools heading, click Scheduled Processes.
Click Schedule New Process then click type Job. Choose the process named SalesAccountBatchAssignRequest. If needed, use the Search link at the bottom of the Search window.
Enter your process details. The following table shows the view criteria and its description, as well as any bind values that are required.
Work Object code: Sales_Account_Work_Object
Candidate Object Code: SalesAccountTerritory_Candidate_Object
Assignment Mode: Territory
View Criteria Name: (see table below)
View Criteria Bind Values: (see table below)
|
View Criteria Name |
View Criteria Description |
View Criteria Bind Values |
|---|---|---|
|
SalesAccountsUpdatedSinceVC |
Use this view criteria to assign sales accounts which
have not been previously assigned and have |
BindLastUpdateDate=[YYYY-MM-DD HH:MM:SS] |
|
SalesAccountsAssignedBeforeVC |
Use this view criteria to reassign sales accounts
which have been previously assigned and have |
BindLastAssignedDate=[YYYY-MM-DD] |
|
SalesAccountTerritoryBatchReassignmentVC |
Use this view criteria to reassign sales accounts impacted by the specified territory and territory dimensional realignment batch. This view criteria is also used internally to invoke immediate/automatic assignments after territory proposal activation and territory dimension updates. |
BindReassignmentBatchId=[Territory Reassignment Batch ID] |
|
SalesAccountBulkImportVC |
Use this view criteria to assign sales accounts created in a given customer import batch. This view criteria is also used internally to invoke immediate/automatic assignments after customer import. |
BindReassignmentBatchId=[Import Activity ID] |
|
SalesAccountDimsForPartyVC |
Use this view criteria to assign the sales account with the specified sales account ID. |
BindPartyId=[Sales Account ID] |
Define a schedule as needed using the Advanced button on the Process Details page. You can schedule the process to run as soon as possible, or to run at a given frequency and start date.
Submit your job and monitor it using the Scheduled Processes list, refreshing it to view the latest status updates.
When the assignment object inactive box is checked the selected work or candidate assignment object is not available for assignment processing. When the assignment attribute inactive box is checked the selected work or candidate object attribute is not available for assignment processing.
Note
The object or attribute cannot be set to inactive if there is a mapping set, mapping, or rule defined using the object or attribute.
Dimension Mapping: Dimension mapping should be used when the work object and candidate object attributes in the comparison are dimension attributes, such as Geography, Product, or Account. When creating the mapping, use the Function Code field to specify a unique identifier for the dimension. This identifier is passed to the translation function, in case the same function is used for multiple dimensions.
Attribute Mapping: This mapping enables you to compare and match attribute
values between a work object attribute and a candidate object attribute.
When the value of the candidate object attribute matches the work
object attribute the candidate is selected. Attribute mappings should
be used when the work object and candidate object attributes in the
comparison are non-dimensional attributes.For example,
consider a lead work object with a program ID attribute and the territory
object with program ID attribute. The selection criterion is: select Sales Lead Territories where Sales Lead
Territory.ProgramID equals Sales Lead.LeadProgramIDThe assignment
engine will use this mapping data to construct a query on the candidate
object that is equivalent to the selection criteria. When creating
the mapping, the Function Service and Function Code are only needed
if a translations function is used. The function code field is used
to specify a unique identifier for the attribute, and this identifier
is passed to the translation function.
Literal Mapping: Literal Mapping is used almost exclusively to filter the candidate
objects. This form of mapping enables the comparison of candidate
attributes against a specific value chosen by the user. The assignment
engine will compare the mapped candidate object attribute against
the specified literal value. For example, select the Territory Candidate
object that has the attribute TerrStatusCode that equals the value FINALIZED.
Note
For Literal Mappings ensure that the value entered corresponds to the Lookup Type Value code, not the meaning.
An internal, or deploying company, territory is defined, created, and assigned internal resources.
Examples of two internal territories are:
Sales Representative Territory (SRT) is the jurisdiction of responsibility of a sales representative over a set of sales accounts, leads and opportunities.
Lead Triage Territory (LTT) is the jurisdiction of responsibility of channel manager to triage partner Leads, that is approve leads and route to the right Partner.
A Partner territory is the jurisdiction of the reselling partner and contains partner resources. Specific Partner territories can be assigned to a sales account as needed.
Note
Territory Management must be implemented to utilize this feature.
Assignment Manager (part of Oracle Fusion Work Management) is used to determine matching territories for a given sales account. A sales account can also be assigned to one or more internal and partner territories.
All internal territories, such as Prime, Overlay and Sales Channel Manager territories, which match a given sales account's assignment attributes are assigned to the sales account. Internal territory assignment can be run immediately and automatically whenever sales account assignment or reassignment is required. For example, you can run assignment manager when a sales account is created or updated, or when territories are realigned. Internal territory assignment can also be scheduled to run in a batch, or it can be run on-demand via the Assign Territories action in the sales account team page.
Partner territories are applicable to Partner Relationship Management implementations. When a partner lead is approved, any partner territories associated to the lead are automatically assigned to the lead's sales account. Channel sales manager can also select specific partner territories to assign to a sales account via the Add Partner Territories action in the sales account team page.
Note
Territory Management must be implemented to utilize this feature.
Internal territories get assigned to sales accounts in the following scenarios.
When sales accounts are created.
When a sell-to address is added to an existing sales party.
When sales accounts are imported in bulk.
When certain attributes on sales accounts that correspond with territory assignment dimensions are updated.
When batch assignment is run.
When you select the Assign Territories menu action on the Sales Account Team node for the sales account
When territories are realigned or when personnel leave the territory or the company.
Note
The following profile options determine whether territory assignment and reassignment is automatic for sales accounts. The default setting for both is YES.
Sales Account Automatic Assignment on Create Enabled
Sales Account Automatic Assignment on Update Enabled
Automatic assignments are always enabled following an import, party merge and territory realignment.
During initial implementation and migration, it is
possible to create sales accounts before territories have been set
up in the system. These sales accounts will not receive any territory
assignment because there are no territories. These accounts need to
be explicitly assigned when territories are configured and activated
in the system. This is one exception which does not have immediate/automatic
assignment. The recommendation is to run a batch assignment to assign
these sales accounts created at the beginning of the implementation
using the view criteria SalesAccountsUpdatedSinceVC.
Partner territories get assigned to sales accounts in the following scenarios.
When a partner-generated lead is approved, all partner territories associated to the partner-generated lead are automatically assigned to the sales account.
Users with the privilege Manage Sales Party Partner Territory can assign partner territories from the sales account team UI.
Note
Territory Management must be implemented to utilize this feature.
This example illustrates how to create a task template that represents a business process.
A sales manager wants to create a task template for her department's client product demonstration process.
The client product demonstration process occurs regularly. The sales manager does not want to manually create tasks for this process every time it occurs, so she decides to create a task template that includes the business process activities. Each time she repeats the business process, she can use the task template to automatically generate the appropriate tasks that need to be performed.
The business process consists of the following activities:
Book a conference room.
Create an agenda.
Confirm the date and time with the client.
Make arrangements with presenters.
Deliver product demonstration.
Follow up with client.
Based on the analysis of the business process, the following task template is created:
Task Template Name: Client Product Demonstration
|
Task |
Category |
Lead Days |
Duration Days |
|---|---|---|---|
|
Book conference room |
Preparation |
1 |
1 |
|
Create agenda |
Preparation |
1 |
1 |
|
Confirm date and time with client |
Call |
5 |
1 |
|
Schedule presenters |
Preparation |
5 |
2 |
|
Deliver demonstration |
Demonstration |
7 |
1 |
|
Follow up with client |
Call |
10 |
1 |
A note is a record attached to a business object that is used to capture nonstandard information received while conducting business. When setting up notes for your application, you should consider the following points:
Note Types
Note Type Mappings
Note types are assigned to notes at creation to categorize them for future reference. During setup you can add new note types, and you can restrict them by business object type through the process of note type mapping.
After note types are added, you must map them to the business objects applicable to your product area. Select a business object other than Default Note Types. You will see the note types only applicable to that object. If the list is empty, note type mapping doesn't exist for that object, and default note types will be used. Select Default Note Types to view the default note types in the system. Modifying default note types will affect all business objects without a note type mapping. For example, you have decided to add a new note type of Analysis for your product area of Sales-Opportunity Management. Use the note type mapping functionality to map Analysis to the Opportunity business object. This will result in the Analysis note type being an available option when you are creating or editing a note for an opportunity. When deciding which note types to map to the business objects in your area, consider the same issues you considered when deciding to add new note types. Decide how you would like users to be able to search for, filter, and report on those notes.
Note
Extensibility features are available on the Note object. For more information refer to the article Extending CRM Applications: how it works.
Create the task template with a subtype of Assessment.
A score of 0 is assigned for free-form responses.
A free-form response option will have no effect on the overall assessment score. The free-form response offers the opportunity to enter a textual response to a question that does not conform to any of the pre-populated responses provided by the assessment template.
A question group is a logical grouping of questions within an assessment template, and it is used strictly as a category header for those questions. Through careful naming of a question group, you can achieve the benefit of providing the user of the template with an approximate idea of the type of questions to expect in each group.
This step lists all of the assessment template questions in one place, and provides you with the opportunity to edit weights as necessary to ensure that the sum of all weights totals 100.
Click-to-Dial is the feature that enables the user to initiate outgoing calls via hyperlinks. Extended Click-to-Dial enhances the click-to-dial experience by adding an agent communication toolbar. The communication toolbar is a real time dashboard for the agent's voice communications. It displays the agent's telephony state, current status of a call (during call setup and actual conversation) and provides a set of voice controls as well as ability to access and modify the current interaction. This toolbar displays when a call is made or received, allows the agent to transfer the call or consult with another agent and return to the original call.
When a call is received, Enhanced Click-to-Dial displays the identity of the inbound caller via a reverse directory search and can open an interaction page for logging the call. If a search fails for the contact name, the company may be identified and a search dialog will be displayed that enables you to search for your contact to initiate the interaction logging. If the company is not identified, you can still search all contacts to generate the interaction. You can manually call up the interaction dialog at anytime from the toolbar.
When a call is complete, the application can display a wrap up interaction dialog to record the results of the call.
The communications toolbar and the communication services provided use a slightly different infrastructure than previously delivered. To enable this infrastructure there are four tasks:
Manage Click-to-Dial Profile Options
Manage Communications Connectors
Manage Agent Connector Settings
Manage Contextual Navigation Rules
This is the first task for setting up the Oracle Fusion Enhanced Click-to-Dial feature.
These profile options determine if the feature is available, whether individuals have access to the toolbar, and the in and outbound logging preferences.
|
User Profile Option Name |
Description |
|---|---|
|
Enable Enhanced Click-to-Dial |
Enables the site wide Enhanced Click-to-dial functionality. It is recommended that this profile option be only enabled after completing associated setup tasks for Click to dial. |
|
Enable Click to Dial Toolbar |
Indicates whether the Click to Dial toolbar should be displayed for a user with a click-to-dial enabled job role. It is defaulted at the Site level to Yes. Individual users can be opted out of the toolbar display by adding a User level entry with the profile value set to No. |
|
Automatic Inbound Interaction Logging |
When set to Yes, interactions are automatically logged for inbound calls. If set to No, no wrap up dialog will be displayed at the end of a call. |
|
Inbound Interaction Logging Type |
When "Automatic Inbound Interaction Logging" is set to Yes, controls how interactions are logged for inbound calls. Can be set for All Communications or by the Party Usage Filter Rules, for example: all eligible customers. If left blank an interaction is created for all inbound calls. |
|
Automatic Outbound Interaction Logging |
When set to Yes, interactions are automatically logged for outbound calls. If set to No, no wrap up dialog will be displayed at the end of a call. |
|
Outbound Interaction Logging Type |
When "Automatic Outbound Interaction Logging" is set to Yes, controls how interactions are logged for outbound calls. Can be set for All Communications or by the Party Usage Filter Rules, or example: all eligible customers. If left blank an interaction is created for all outbound calls. |
|
Enable Inbound Screen Pop |
If set to Yes, the contextual navigation for inbound call is performed unless the toolbar option Contextual Navigation is set to no. If set to No, no screen pop or interaction dialog is displayed. |
|
Enable Outbound Screen Pop |
If set to Yes, the interaction dialog for outbound calls is displayed when an interaction is automatically logged, unless the toolbar option Contextual Navigation is set to no. If this profile option is set to No, the interaction dialog is not displayed. |
|
Click to Dial Toolbar Auto Login |
Click-to-Dial automatic log in is not used at this time. |
The communications connectors provide the parameter settings required to establish connectivity between the Fusion application and a telephony system. The Oracle Contact on Demand connector, and a software development kit (SDK) for developing additional connectors are delivered.
The Manage Communications Connectors user interface enables you to add other connectors and connector types as required by your specific communications needs.
Define the connector types before designating the connectors and parameters. You can add Agent specific connector parameters such as their agent ID or extension number. These parameters are passed to the connector and used as needed to communicate with the telephony system.
Define the connectors. There are four parameters that are provided to pass location information for the various downloads and servers. A fifth parameter is available to pass any connector specific parameters to the telephony system.
JavaScript Location - The location from where 3rd party JavaScript will be downloaded. The JavaScript will be run within the browser and can be either a transport library implementation for communication to a vendor specific connector or the actual connector itself. If left blank, Oracle's default transport library will be used.
Runtime Location - The connectors runtime location, an internet protocol (IP) address or domain name for the connector or URL. This is used by Fusion Click to Dial toolbar to communicate with a connector that runs outside the browser.
Download URL - The location /URL from where a connector will be downloaded and is reserved for the use of the Oracle Contact On Demand Connector.
Server Location - The telephony system server runtime location, an IP address or domain name.
Parameter String - Additional connector parameters for the specific telephony system in addition to the parameters above. This is reserved for the specific use of the connector.
An Agent is required to sign in to a connector to establish the connection to the telephony system to make and receive calls. This task establishes the relationship between the connector, the agent, the agent group, identifier and password.
After adding a new row to the connector settings,
you can search for the agent name using the orange glyph that opens
a search dialog. The assignment of the agent groups, an agent ID,
and password are usually defined and entered by the administrator.
An agent can also self-provision themselves through the agent sign
in dialog box. This dialog box is not available through the setup
UI. It can be launched in the transaction flow from the toolbar UI.
On the sign in dialog box, click on edit connector. User can then
create a connector for himself and also provide additional agent parameters
for the connector. These data values are used exclusively for an agent
signing in to a connector. There is also a sub-page for entering any
other parameters specific to that agent that are required by the third
party telephony system and not covered in the delivered configuration
parameters. Some examples required for Oracle Contact On Demand Connector
are the AcdUserID and AcdExtension. These two parameters are used in the agent
transfer scenario where a list of agents together with the Extension
will be available for the user to choose to which agent the call will
be transferred. AcdUserId is a special
id that Oracle Contact On Demand (COD) assigns to each COD user. AcdExtension is the virtual extension that COD
assigns to each user. Therefore, instead of knowing the exact number
to dial in order to reach out to an agent, the extension can be used.
COD determines the phone number to call from that virtual extension.
The agent connector parameters will differ from one connector to another.
Note
An Agent also has the ability to set this information through the Connect button in the toolbar. Therefore, the Manage Agent Connector Settings task can be skipped and delegated to each agent if so desired.
Upon receiving an incoming call, the connector will follow a set of rules to determine which UI to open upon connecting. This feature can be turned on or off on the Click-to-Dial toolbar by choosing the Yes or No radio button for Contextual Navigation.
Navigation rules are organized in Rule Sets. There can only be one active contextual Navigation rule set at a time. The navigation rules themselves are comprised of a Call Data Token and the Target Navigation Page. One way the call data token is set is by using the values returned by Automatic Number Identification (ANI) and the Dialed Number Identifier Service (DNIS) from the telephony system, in combination with IVR data provided by the caller such as Organization ID or account number. Call data token value or a default value are used as the value for task flow parameter in order to launch the target navigation page when the connection is established.
The Target Navigation Page is the page that will open upon accepting the call. Target Navigation Pages are defined by a name and a task flow identifier. Each navigation page, or task flow, can have one or more parameters. The parameter can be set with either a default value or set with a call data token so that a value is set at runtime using the call data token name.
Oracle Fusion Click-to-Dial is a user friendly way to receive calls from your customers and contacts and to record those interactions. Outgoing calls are made through the hyper-linked phone numbers seen displayed with customer and contact information and through contextual action dialogs. A Click-to-Dial tool bar is used as a dashboard for call status and taking actions on inbound and outbound calls. The tool bar is supported by an infrastructure of connectors and telephony systems that enable this to happen. A delivered generic application program interface (API) enables Click-to-Dial to work with any switch or telephony vendor. Oracle does not author or maintain these connectors, except for Oracle Contact Center On Demand (COD), which is also a reference implementation. For this release, the COD connector is supported only on Windows desktops and Linux. This restriction will be removed in later releases.
An agent initiates their availability for inbound voice communications by signing in to a connector via the tool bar. The agent signs in via a single connector for that toolbar session. Each connector is associated with an agent or agents. The agent has an assigned agent group, agent identifier and password for each connector. This enables the Agent to sign on to a connector and use the tool bar to receive and transfer calls to other agents and customers or contacts. There may also be other parameters required at this agent level for the telephony system. These can be designated at the agent connector parameter level and passed by the connector to the telephony system. Agents may also record each of these transactions via the Oracle Fusion Interaction features.
Connectors perform the linking of the agent to the telephony system that enables the outgoing and incoming calls via Click-to-Dial. The Oracle Contact on Demand Connector is delivered. Contact On Demand is a multichannel, all-in-one call center application that itself connects to the Public Switched Telephony Network (PSTN) to provide voice communication capability. Other connectors may be added using the delivered template.
These are third party systems used to establish telephone communications to and from the customer site. They can operate over the internet protocol layer or on hard wired telephony networks.
This user interface to the Click to Dial feature enables you to establish the connection with the software connector to the telephony system. You may receive, ignore, hold, or transfer a call from your customers and contacts. You can also consult with another agent with the calling party on the line or on hold.
The Oracle Fusion Interactions application can be used to record the particulars of the call using the interactions user interface. Upon receiving a call the tool bar will use the incoming phone number to identify the caller. If the caller is known, an interaction window will be created and opened. If the caller is unknown, the tool bar will popup a window allowing you to search the customers or contacts available to you. If the company is known but not the caller, the list of contacts available to you from that company will be searched. You can also manually open a search dialog. Once the call is completed the Interaction wrap-up screen can be programmed to popup at the end of the call enabling the Agent to finish noting any further call details.
