11g Release 1 (11.1.3)
Part Number E20372-03
Contents
Previous
Next
|
Oracle® Fusion
Applications Marketing Implementation Guide 11g Release 1 (11.1.3) Part Number E20372-03 |
Contents |
Previous |
Next |
This chapter contains the following:
Define Resource Organization Information
Define Resource Role Information
Define Products: Define Basic Items
Define Products: Define Advanced Items
Manage Calendar Profile Option
Define Sales Prediction Configuration
Source systems are used to import data into Oracle Fusion Applications, and are used within the application to identify source data information. You can specify whether the source system is a Spoke system, such as a legacy system, or a Purchased system, such as data from a third party provider. You can also specify what type of data will be imported using the source system, for example, you can specify that a source system will import trading community members.
You can configure the following for a source system:
Source system code, name, and description
Source system type
Enable for Items, Trading Community Members, Order Orchestration and Planning, and Assets
You can create a source system code to uniquely identify the source system. Source system codes are used by the application when creating references between source IDs and the Oracle Fusion Applications database IDs. You can create a source system name and description to provide information that is more descriptive than the source system code.
Note
You cannot update the source system code once you have created the source system.
You must set up a source system as either a Spoke system, such as a legacy system, or a Purchased system, such as data from Dun & Bradstreet.
You should select which types of entities will be imported from the source system into the Oracle Fusion Applications database from the following:
Items
Trading Community Members
Order Orchestration and Planning
Assets
You can select one or more of these entity types as required for the source system. It is important to enable the correct entity types because each import UI filters source systems based on their entity type. For example, if a source system is enabled for Trading Community Members, Items, and Assets, then the source system can be selected as a data source in the Trading Community Members, Items, and Asset import UIs, but the source system cannot be selected in the Orchestration and Planning import UI.
Source System Entities are the entities, such as addresses and parties, which can be imported using a specified source system.
When you import data from a source system, all of the entities in the source system data will be imported. Within the Source System Entities UI, you can chose to allow multiple source references, which allows multiple records from a source system to map to a single trading community record.
Allowing multiple source system references means that when you import data from a source system you can merge multiple, or duplicate, source system records and create one record in the Oracle Fusion Applications database.
If you do not allow multiple source system references then an Oracle Fusion Applications database record will be created for every source system record. This means that you could potentially create duplicate records in the Oracle Fusion Applications database.
You can set up additional identifier types to provide extensions to organization, person, or group 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, and these can be either a person, organization, or group party type, or a combination of these party types. You can also choose whether the value of the identifier type has to be unique, for example you can specify that each entry of a passport number has to be unique by selecting Yes for Unique Within Type.
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 web service Trading Community Member Name and Identifier Setup
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.
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.
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.
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.
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.
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.
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.
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 in Functional Setup Manager.
The Import Item task in Functional Setup Manager 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.
In Functional Setup Manager, access the All Tasks tab on the Overview page, and search for the Import Item task with the name of your ESS process definition, then 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.
Access Monitor Item Imports in Functional Setup Manager 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 different instances of an item.
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 are two examples of applications currently using transactional item attributes. 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 TIA 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 TIA would not get inherited. Multiple records with same date range can exist if they belong to different domains. For example, TIA Memory is associated with Domain DOO 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 TIA 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 a item class may be allowed for item creation. For example:
This will prevent items from being created in Computers and Desktop and allow 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.
Item classes can be set up for item numbers and descriptions so that they are automatically generated when net items are created. This ensures that new items created in item classes have a consistent numbering scheme. Versioning control allows new versions to be created for all items of item class. An integrated workflow definition allows creation of custom new item request definition for new items created. This definition workflow enables you to route the definition and approval of an item using various steps. When creating a new item, various aspects of an item like base operational attributes, user-defined attributes, structures, attachments, categories associated, organization assignments, are defined by various people in the organization using a workflow process.
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 on 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 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.
An additional attribute is an extension to what is already provided in the application. For example, the currency attribute can be used if you wish to add an additional field to capture dollar values from the catalog and pass it to the consuming application. You may want to capture how much your customer is willing to pay for a product and send this information to an opportunity or a quote. You can expose this attribute with the value Customer Bid. In the runtime application, this field appears and the user enters an amount that she is willing to pay, say $90.
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
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.
File-based import supports the import of data from an external text or xml file to interface tables and then from interface tables to target application tables.
File-based import includes the following:
Source files with import data
Import objects with available import attributes
Mappings between source files and interface table columns
Import Activities to define import options, a processing schedule, and monitor progress
External data can be obtained in various ways and formatted in a text or xml file. The source file data is mapped to interface table columns using a Mapping. The source file is identified on an Import Activity, along with other import processing details. The file processing component of the file-based data import consists of reading the source file, parsing the data, and inserting the data into the appropriate interface tables.
Import objects are defined where interface tables exist and external files can be used to import data into the interface tables. Import Object definitions for Oracle objects that support file-based import are predefined and can be accessed with the appropriate security privilege. Individual object attributes represent the interface table columns and are used to map source file data or constant values in Mappings and Import Activity definitions. Use the Import Object definition to manage the display of attributes that can be mapped, to indicate required mappings, and to set site level default values as required.
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.
An Import Activity definition provides the instructions for the import processing. It includes the source file or file location and mapping, plus import processing options and schedule. You can monitor the progress of the Import Activity processing and view completion reports for both successful records and errors.
The file-based data import process includes processing the source file data and inserting it into the interface tables, moving the interface table data into the destination application tables, and then processing the attachments for the imported objects. Processing factors are subject to the settings defined for the Import Activity, Mapping, and Import Object. You can monitor the processing steps and view process reports for each Import Activity.
This topic describes the following:
Inserting Data in the Interface Tables
Interface Table Data Validation and Error Counts
Interface Table to Destination Application Table Processing
Importing Attachments
Viewing Import Results
Data exists in various sources and in various formats. The file import processing starts with reading the source data, parsing the data, and inserting into the appropriate interface tables. The source of the data comes from the following:
Source file values mapped to target object attributes in the Import Activity.
Constant values defined for target object attributes in the Import Activity.
Default values defined for target object attributes in the Import Object.
The data is initially validated against the predefined Import Mapping and the Import Object settings as the interface tables are being populated by the initial file import process. The interface table data is validated again before importing into the destination application tables.
Validation includes:
Missing required values
Values that exceed the attribute length
Invalid values
Duplicates to existing records in the destination application tables based on the combination of attributes selected for duplicate validation in the predefined Import Mapping.
Note
For the Lead import object, the duplicate checking is only done for existing leads created within the look back days setting of the Import Activity.
Duplicates to existing records in the destination application tables for Customer Data Management objects based on Matching Configurations.
Errors
Most validation issues are recorded as errors, with the exception of Customer Data Management duplicates found during the Matching Configuration process. In this case, matched records are only considered as errors if:
Customer Management Duplicates option is set to Do Not Import for the Import Activity and
The main object of the Import Activity is a consumer, customer, or legal entity object
Allowable Error Count Threshold
The validation of the interface table occurs before any records are imported into the destination application tables. Once the validation process has completed, the count of records with errors is compared to the Allowable Error Count Threshold value specified for the Import Activity. A count above the threshold will stop the import process for all records. If the count is below the threshold, records without errors will import. In either case, records with errors will be reported in the Error and Exception files.
The import process orchestrates the import for each of the component objects that make up the overall main objects of the Import Activity.
Once the objects have imported successfully, the attachments are processed. The import process matches the source file attachment name to the file name included in the compressed file entered on the Import Activity. The attachment file is imported into Universal Content Manager and then associated as an attachment to the imported object.
You can monitor all file-based 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. Once an Import Activity process has completed, the following processing reports are added as attachments to the process:
Log file. Includes the records that were successfully imported plus the unique destination application table identifiers for the objects.
Exception file. Includes the records that were not imported plus a reference to an error for each record that failed validation.
Error file. Includes all the errors for each record that failed validation.
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. |
Many objects can have multiple documents attached to it. The File Import Activity process allows you to import the documents attached to a specific object.
In the Summary section enter an import activity name and description and the primary object for which you want to import data from a source file. The list of objects displayed is controlled by your data security privileges. This topic describes how to define the attachment options pertaining to the import activity.
As part of the file attachment import process setup, you must:
Provide the relationship between the attachment file or files and the object in the source file with multiple columns each referencing a file name pertaining to the attachment.
Provide file names in the source file columns for attachment corresponding to each object record (row)
Select all the files associated with all the objects targeted in the current file import activity process
Map the columns related to file names to specific object and attribute pertaining to the common attachment interface such as category, file name, file title and file description
Monitor the process for uploading attachments that is activated as part of the file import activity process
You define the parameters for the import activity to include the primary object for which the data is included in the source file. If the object being imported has attachments, you will need perform an additional step of selecting documents that serve as attachments for each record being imported in the Attachments section. Select the Multiple Files option and then click on Browse to display the Universal Content Manager (UCM). From here you can select individual documents that serve as attachments or a single file that contains all these documents as follows:
Select a pre-configured compressed file in Zip or Jar format that contains all the individual attachment documents. If the compressed file contains hierarchy of folders then the attachment import process will traverse through the hierarchy to search for specific file name.
Select individual attachment documents which UCM automatically compresses into a Zip format. In this case, the individual document cannot be a compressed file.
Browse through the file system and select multiples files from across various folders. You must select all attachments in one operation. For example, you cannot select a few files now and then return later to select more attachments files.
The File 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 import options defined in the Import Activity that are used by the import process to interpret source file data and import interface table data into the target application tables.
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. |
The following options are used when importing the interface table information to the target application tables:
|
Option |
Description |
|---|---|
|
Import Mode |
Determines if the Import Activity process should create new records or update existing records. If updating existing records, the record IDs must be provided in the source file. If an existing record is not found, a new record is created. Update mode is not supported for all import objects. Consequently, the Import Mode is set to Create and is not updatable for those objects. If creating new records, the import process evaluates the data in the interface tables with existing objects in the target application tables for possible duplicates. Customer Data Management objects are evaluated using the rules defined in the set of Matching Configurations. All other objects are evaluated using the combination of attributes selected for duplicate validation in the predefined Import Mapping. |
|
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 |
Consumer, customer, and legal entity objects imported by themselves or as components of another object are subject to duplicate verification. 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.
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.
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.
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.
Select as many view objects as required to be export objects for the export process. Choose the individual attributes required from each export object.
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.
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 tasks noted below in the Set and Maintenance area to accomplish these tasks.
Note
When creating the calendar, the first calendar date should be the first date of the period of the oldest historical data on which you will be reporting. For example, if you were to select January 1, 2010 as your first calendar date, you would only be able to enter or import historical data associated with this date and beyond.
The CRM calendar profile option needs to be associated with the new accounting calendar. Follow these steps:
Note
While the Common Financial Calendar feature of Oracle Fusion Applications supports creation of more than one calendar, 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 once it is set.
Predictive models analyze sales data to evaluate buying patterns and selling win or loss rates. The model can be used to identify customer profiles with a greater likelihood to buy certain target products. After evaluation of model results, lead generation can be scheduled in order to disseminate lead recommendations to users who can benefit from the insight gathered. Each lead recommendation includes win likelihood in addition to the average expected revenue and sales cycle duration from past similar deals for the same product to similar customers.
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.
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.
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.
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
Consumer
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. 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 consumer is a person who is a qualified paying individual. A consumer can have one or more sales accounts or sales prospects. A consumer is not an organization sales account or sales prospect. A consumer is by definition also a legal entity.
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 five types of Oracle Fusion Customer Center trees. Each tree displays slightly different nodes, and 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 five types of Customer Center trees are:
Customer
Consumer
Contact
Legal Entity
Account Plan
The customer tree displays nodes for business-to-business entities such as sales account and sales prospect. 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, discussion forums, classifications, assessments, notes and, account assessments. 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 consumer tree displays nodes for business-to-consumer entities such as sales accounts and sales prospects. All nodes on the consumer tree are visible to all users. Since consumers are individuals rather than organizations, there are fewer nodes displayed in the consumer tree than in the customer tree. For example, you will not see nodes for organization chart, contacts, assessments, or others that are pertinent to organizations.
The contact tree displays nodes for contacts with the contact profile and other related information such as the customer (the organization) to whom the contact belongs, interactions with the contact, notes, and so on. All nodes on the contract tree are visible to all users.
The legal entity tree displays nodes for business-to-business entities that are marked with a party usage of Legal Entity. Because legal entities are typically a parent or root node in a customer hierarchy, legal entity tree has a subsidiaries node. All nodes on the legal entity tree are visible to all users.
An account plan is a plan to sell to a certain set of accounts in a coordinated way. There is a specific set of assigned resources. This tree shows associated contacts, assets, Opportunities and member accounts of the plan.
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.
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
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 primarly 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.
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 rules for the sales account work object, your chosen attributes are available for your rule conditions. In other words, you could configure a rule for sales account using the Named Account Flag attribute, and set a condition where the assignment engine looks for sales accounts that have their Named Account Flag equal to Yes.
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 you need to specify the order in which these attributes will 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.
Note
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.
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.
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, to set up the resources that can be assigned, and to create the rules and mappings that dictate the selection and assignment of those resources. 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
Resources
Assignment disposition
Attributes
Mappings and 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 of a resource 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.
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, you will 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, you will 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 sales representative to a business object like opportunity based on the product skill of the sales representative. In this case, when you create the opportunity work object and the sales representative candidate object, you will select the attributes of opportunity and sales representative that correspond with product skill. 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 business objects to work objects.
Assignment mappings drives territory-based assignment. These mappings identify the dimensions, attributes, and territory filtering used in territory-based assignment processing. A default set of mappings are seeded. This seeding assumes that opportunities, leads, and sales accounts use the same territory hierarchy. 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.
You create the mappings and rules using the work objects, candidate objects, and attributes that you already established. When designing your mappings and rules, carefully consider how you want to match candidates to work objects. For example, would you want resources assigned based on their geographic location, or their product knowledge, or their skill level, 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 mappings and 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. |
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.
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.
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 the product dimension as the
mapping type. 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 ProdSeqLow.
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 ProdGrpSeqLow.
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 are finalized (for example, territory status equals FINALIZED).
Rule-based assignment requests that identify matching candidates or scores for matching candidates use candidate data such as resources. This candidate data is loaded into a cache and used for each assignment request until the cache is refreshed. Oracle Fusion Assignment Manager supports the ability to refresh the candidate data cache at regular intervals. The Fusion Enterprise Scheduling Service (ESS) process Refresh Cache is used to set an indicator that the candidate data should be refreshed the next time there is an assignment request using that candidate.
Note
This feature affects rule-based assignment using the rule set types of matching candidates or matching candidates with scoring only.
Implementations may schedule this process daily, weekly, and so on, as required by the frequency of changes to the candidates. Consider how often the candidate data will change and how critical it is to have the changes available for use in assignment. For example, resource details may change daily and therefore the resource candidate data cache for Lead Management may need to be updated once per day.
As indicated in the note above, the Refresh Cache process should be defined for each candidate object and application that uses Rules-based Assignment candidate matching or candidate matching with scores. The process has the following parameters:
Owner Module, such as sales, or leadMgmt
Candidate Object Code, for example Resource_Candidate_Object.
For example, there would be one ESS process scheduled
for Lead Management with the parameters: leadMgmt
/ Resource_Candidate_Object_Lead. Sales would need two processes
scheduled: One with parameters sales /Resource_Candidate_Object and the other with the parameters sales/Credit_Allocation_Template_Candidate_Object.
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.
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 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.
The question weight, response score, and response rating are the assessment template components that fit together to calculate and display the overall assessment score, rating, and feedback text.
A question weight is multiplied by a response score to achieve a weighted score for an assessment template response. The weighted scores for all responses are added together to determine the total assessment score. This score will fall within a precalculated score range that is associated with a response rating and feedback text. Therefore, the score range within which the total assessment score falls determines the rating and feedback text to display for a completed assessment.
The question weight is the relative importance of a question within an assessment template, and it is expressed as a percentage. All of the question weights within a template must total to exactly 100. When an assessment template is used to perform an assessment, a question's weight is multiplied by the score of the response given for the question to produce a weighted score for that response.
A response score is the score assigned to a possible response to a question in the template. The template administrator sets response scores with no upper or lower bounds, and each score is normalized in order to accurately score an assessment that uses the template. The response scores are normalized by assigning a score of 100 to the highest response score, and then all other responses are assigned a normalized score relative to that highest score.
When an assessment template is used to perform an assessment, the normalized score of the response given for the question is multiplied by the question's weight to produce a weighted score for that response.
A response rating is the rating assigned to a possible response to a question in the template. A rating is a textual qualification like Excellent or Poor that provides a metric other than a numerical score for qualifying the outcome of an assessment. A response rating is directly related to a response score, and this relationship should ensure that a higher score will translate to a higher rating.
Early in the template creation process, the administrator configures ratings to assign to responses. The administrator then assigns scores and ratings to responses, and the system calculates score ranges based on those entries. Each rating is assigned to a score range, and the administrator is given the opportunity to apply feedback text to the rating-score range combination.
When an assessment template is used to perform an assessment, the weighted scores from all responses are added to determine the total assessment score. That score will fall somewhere within the calculated score ranges, which then determines which rating is assigned to the assessment and what feedback text to display. The maximum total assessment score is 100.
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.
In Oracle Fusion Customer Center, you can customize the Sales Account region on the customer profile page using Oracle Composer. To access Oracle Composer, navigate to the customer profile page and select to customize the page from the Administration menu in the global area. You can also access Oracle Composer by selecting Customization Manager from the Administration menu.
When you select to customize a page from the Administration menu in the global area, you launch Oracle Composer.
The customizations that you make to the customer profile are applied based on your layer selection:
Site
Your customizations are visible to all users.
External or Internal
Depending on your selection, your customizations are visible to either external or internal users.
External users could be your partners or anonymous users. Internal users could be your employees.
Job Role
Your customizations are visible to users who have the selected job role.
If a user has more than one job role, then the sequence in which customizations are applied is alphabetically ordered by job role name.
Oracle Composer provides two views for working with page content: Design View and Source View. Design View provides a WYSIWYG rendering of the page and its content, where controls are directly selectable on each component. Source View provides a combined WYSIWYG and hierarchical rendering of page components, where controls are available on the header of the hierarchical list. Source View provides access to page layout components that are otherwise not exposed on the page, and therefore not available in Design View.
This table lists the types of customizations available for the customer profile page. You can perform most of the basic customizations in either Design View or Source View. Some customizations, however, must be completed only in Source View.
|
Oracle Fusion Customer Center Page |
Customization Task |
|---|---|
|
Customer profile |
Show and hide components on a page:
Tip You might have to scroll down to see the Show Component check box. |
|
Customer profile |
Move components on a page:
|
|
Customer profile |
Make an updateable field read only by selecting the Read Only check box on the Display Options tab in the Component Properties dialog. |
|
Customer profile |
Make a field required by selecting the Show Required check box on the Display Options tab in the Component Properties dialog. |
The customizations that you can make using the Oracle Composer Source View are available to you only if your assigned job role includes the Page Composer Source View Access Duty duty role. Contact your security administrator for details.
Note
Your assigned job role must also include the Administration Link View Duty duty role to access Oracle Composer at all, even if only the Design View. This duty role exposes the Administration menu in the global area.
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.
Create the task template with a subtype of Assessment.
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 or rule defined using the object or attribute.
Attribute Mapping: This mapping enables you to compare and match attribute
values between a work object attribute and a candidate attribute.
When the candidate 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 criteria is: select Sales Territories where Sales Territory.TerritoryLocation
equals Sales Opportunity.OpportunityLocation The 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, use the Function Code field to specify a unique identifier
for the dimension. This identifier will be passed to the translation
function, in case the same function is used for multiple dimensions.
Literal Mapping: Literal Mapping is used almost exclusively to filter the candidate objects. This forma 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.
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 will be passed to the translation function, in case the same function is used for multiple dimensions.
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.
A merge request is made when duplicate records
that point to the same customer are found, and you want to consolidate
those records into one. When a merge request is approved, there is
one survivor record. All other duplicate records are considered victims,
and they are marked with the status of Merged. In customer center,
you can mark two or more customer records for merge request from customer
list in the Customer home page or in the customer search result. Merge
requests will be processed by the customer data hub. The customer
data hub must be implemented and the profile option Merge Request
Enabled set to YES for
this feature to be available.
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.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
