Configuring Oracle Proposals

This chapter covers the following topics:

Overview

The proposal administrator is the user who is responsible for creating and maintaining proposal templates. This responsibility is not the same as the system administrator responsibility. Proposal administration tasks must be performed before users can create proposals. Administrators must set up:

Prerequisites

Only those users whose responsibility has been assigned the Proposal Main Menu, or have the Oracle Proposals Administrator responsibility, are able to perform the tasks outlined in this chapter.

When configuring Oracle Proposals, there are three phases of development:

Planning

The planning phase involves three major steps:

The Proposals administrator must review the proposal and determine the primary and common elements of the proposals sent out by a company's sales force. These components form a template that a designated group of salespeople can use as their basis for creating proposals for their customers. Within each component, the proposals administrator can also determine if there should be several different versions to use. For example, if the user determines that there are multiple versions of a cover letter, those variations can all be saved under the cover letter component. Also, the proposals administrator can determine which sections of the component can be personalized. For example, in the cover letter version A, the proposals administrator determines the potential customer's address and salutation are customizable areas. The proposals administrator should then mark that this is where dynamic fields should be entered on the RTF file that is created for each component version.

Implementation

Implementation tasks include:

The implementing phase occurs after the proposals administrator has determined which components should comprise the template, how many versions of each component should be saved, and where the dynamic fields in each component version should be placed. The proposals administrator now creates the pieces of information needed in the Proposals application. First, the dynamic fields that are inserted into RTF file created for each component version should be registered. The component versions should then be created as RTF files. Next, The proposals administrator must associate them with components. For instance, Cover Letter version A must be associated with the Cover Letter component. After the components have been created, the proposals administrator can then create a template and associate the components with the template. The template must also be assigned to a category, which determines access to that particular template. End users can filter groups of proposals by category when they select a template to use to create a proposal.

Maintenance

The maintenance phase includes:

As Oracle Proposals is used by the company's sales force, the administrator must be sure to make updates to dynamic fields, components, translated versions and templates as required.

Note: To access Oracle Proposals, you must be a FND user and defined as a Resource in the Resource Manager.

Template Categories

Template categories define groups of templates by purpose or usage, enabling users to select the appropriate template while creating a proposal. Use the Template Categories page to view template category details and to create template categories. Use the Create Template Category page to create template categories. Use the Template Category Detail page to view and modify template category information.

Notes

Defining Quoting and Proposals Dynamic Fields

Dynamic fields are placeholders for text information that are used in standard RTF files and are substituted with information specified during proposal creation.

There are three types of dynamic fields that are understood by the proposal generator:

These dynamic fields are seeded into the application and reference specific information related to Oracle Quoting and Oracle Proposals. Sales administrators can use these dynamic fields in their component content, but cannot create their own. Dynamic fields that are related to the Quote and Proposal objects within Oracle's eBusiness Suite are exposed as dynamic fields.

These dynamic fields are defined by administrators. Values for these fields are obtained:

After defining the dynamic fields, the next task is to create the components that use those dynamic fields.

Related Topics

Dynamic Fields: Proposal and Quote Pages

Oracle Proposals exposes quote attributes as seeded dynamic fields. Administrators can insert these fields in the RTF files. Seeded Oracle Quoting dynamic fields include those for items, pricing, customers, product category, charges, attachments, terms and conditions, and tax information.

Oracle Contracts is a conditional dependency for Oracle Proposals if being pulled in as a part of a quote through Oracle Quoting. If Oracle Contracts is enabled, Oracle Proposals does not support table tokens in Contracts templates.

Notes

References

Oracle Proposals Conditional Dependencies, Oracle Proposals Implementation Guide

Setting Up User Defined Dynamic Fields

You can create dynamic fields any time, but the fields must exist before the RTF file, into which the dynamic field is later inserted, is created. When creating a user defined dynamic field, administrators can register them as:

Creating User Defined Dynamic Fields

Use the Create Dynamic Field: General Details page to enter general details when creating a user defined dynamic field. Access the Dynamic Field Detail page for the appropriate dynamic field type:

Notes

Inserting Dynamic Fields in RTF Files

After you create a field, insert the code and field name into the corresponding RTF file for the component. Place your cursor in the exact position in the RTF file where the dynamic field should be inserted. Insert the field by entering: <@DFC123:Author@>, where DFC123 is the dynamic field code, and Author is the field name. The RTF parser understands any string starting with <@ and ending with colon (:) as a code, and replaces the string starting with '<@' and ending with '@>' with its value.

There must not be any spaces between the dynamic field code and the '<@' or colon '(:)'.

Related Topics

Creating RTF Files Guidelines

Editing Dynamic Fields

The following dynamic field attributes are editable at any time:

The following dynamic field attributes are editable only if not in use (are not referenced by an RTF file):

Notes

Deleting Dynamic Fields

Seeded dynamic fields cannot be deleted. You can delete user defined dynamic fields that are not used. Dynamic fields are in use if a component's file references them. You cannot delete drop-down dynamic field values if they are used in a proposal. Dynamic fields are in use whenever an RTF file references them.

Setting Up Proposal Components

Components help administrators divide their proposal content into independent elements, which can then be reused in different proposals.

Components are individual content elements that are combined into a template that is used to generate a comprehensive proposal. Content elements can include a Cover Letter, Cover Sheet, or Data Sheet.

A component can contain multiple files. For example, a component named Cover Letter can contain several types of cover letter files such as Cover Letter - Simple, Cover Letter - Expanded. Each file points to a separate RTF file, with its own individual content style. These files hold the actual content including standard text, graphs, or tables that are used as standard text for the proposal. Each individual file is a separate RTF file that represents a style type for the component.

The RTF files contain dynamic fields. During the component creation process, their corresponding files are associated with RTF files. The RTF files must be uploaded to the component.

When a component is created, it is created in all of the installed languages. For example, if English and Spanish are the installed languages, and you need to create two different versions of a cover letter, you could create the following two files:

Then associate two RTF files for each type of cover letter, one RTF file being in English and one being in Spanish:

When you upload a new version of a template component file, the end users are notified that there is a new version of the file when they next access a proposal that uses that component. However, this does not affect generated proposals.

Note: If you attempt to upload a proposal component that is in use, you will receive a message to that effect.

Then you translate the file name appropriate to the language (the code is not translatable).

Problems might occur with customized styles when using some word processing programs/editors to create your RTF file content. When the proposal is generated, the parser reads the customized document style definition for the latest document, and then applies it to all components if the customized style names are the same. For example, let us assume you create a customized style named Internal Use for the first component with the specification that it use the Font face Times New Roman and Size 12. The second component also contains a customized style called Internal Use but with a different specification of Font face Arial and Size 10. When the proposal is generated, it overrides the definition in the first component and converts the style Internal Use to have the specification of Font face Arial and Size 10.

Notes

Related Topics

Multi-Language Functionality

Creating Proposal Components

Proposal components are pieces of standard content that are included in templates, such as cover letters and data sheets. Administrators can define components and create multiple files for each component. For example, the component Cover Letter can include the files Simple Cover Letter and Professional Cover Letter.

Components are created and then individual RTF files are associated with them. You can associate files from your desktop, and if the PRP: Use Oracle Content Manager profile option is set to Yes or Optional, you can also associate files from the Oracle Content Manager Folders or Library. In all three flows, you select the file and associate it to a component. You can add only RTF files to a component. Oracle Proposals parses and validates any files before they are added.

Note: Files are parsed to check for all valid dynamic fields and RTF construction.

You can create proposal components by adding files from the desktop, or from Oracle Content Manager Folders or the Oracle Content Manager Library.

Oracle Proposals can only access files in Oracle Content Manager that are of RTF type, live, approved, and in the user's current session language. To associate a file for a different language, change the session language and select the component and associate the file.

Notes

Editing Components

You can do the following at any time:

To edit proposal components, log in to Oracle Proposals with the Proposals Administrator responsibility and navigate to the Components page.

Notes

Deleting Components

You cannot delete components that are 'in use' in a proposal. Components included in proposals or templates are considered 'in use'.

Notes

Setting Up Proposal Templates

Templates provide a standard structure for proposal generation that users can customize.

Template structure consists of components which in turn point to RTF format content, containing standard text, images, tables, and/or dynamic fields.

Administrators can:

While the creation of all other objects, such as dynamic fields and components automatically makes them available for use, templates are not automatically made available when created. Administrators need to publish templates to make them available for use.

The setup of categories, dynamic fields and components are prerequisites of template setup.

Setting up templates is the last step in the administration process.

Multi-Language Functionality

Even when published, a template is made available only in the language in which it is published. Publishing criteria for a given language is based on whether all components in the template have files associated with them. Templates are created for all languages. Template names and descriptions are translatable, but template codes, component lists, and structures are common across all languages.

When creating templates, you must decide on the supported language for your templates. Usually, different templates are used for different regions. For example, if you have two corporate regions, North America and Asia-Pacific, you could use different templates for each in a specific set of languages. North America would need templates in English, French, and Spanish, and Asia-Pacific would need templates in Chinese, Japanese, and English.

When you create a template, the components' content must have been created in the same languages as the published template. Templates are published if all the components have content associated with them. For a template to be used in North America, component content is created in English, French, and Spanish so that it is published in these three languages. The Template Detail page displays a list of languages in which a template has been published.

Create Proposal Template

Creating templates is a four-step process:

Notes

Header Region Notes

Apply and Publish in Current Language: Click to publish the template for current session language.

Personalization Region Notes

Components Region Notes

Editing Proposal Templates

You can edit the following template elements at any time:

Notes

Allowing Users to Add External Files to Proposals Created from the Proposal Template

The administrator has the option to specify whether users can add external files to proposals created from the template.

Notes

Adding Components to Proposal Templates

Components can only be added if the template is unpublished in all languages. When a template is unpublished, and components are added, the changes are reflected in all new proposals created using this template. Existing proposals are not affected.

Notes

Removing Components from Proposal Templates

Components can only be deleted from unpublished templates. To delete components from a published template, unpublish it in all languages first. After you have removed the component, the change is reflected only for new proposals. Proposals already using this template are not affected.

Changing Component Order in Proposal Templates

When you change the component order in a proposal template, it is applicable only to new proposals. Existing proposals already using this template are not affected.

Changing Default Document and Mandatory Attributes

Changes to default files can only be made if the template is unpublished. If a change must be made to a default file in a published template, you must first unpublish the template in all languages before you can make the change.

Notes

Publishing Proposal Templates

Creating a template does not automatically make it available to users. Administrators must publish a template to make it available. Only unpublished templates display a Publish in Current Language button. After a template is published in a language, the list of languages the template is published in displays on the Template Detail page.

You cannot add a component or change a default file in a template that is published in any language. To add components or change the default file, you must unpublish the template in all languages.

Note: Templates can only be published in a language when all components have an associated file for the default file in that language.

Navigation

Oracle Proposals > Administration > Templates > Templates page > Template Name hyperlink > Template Detail page > Components section > Publish in Current Language button

Deleting Proposal Templates

You can delete only templates that are not used in proposal generation.

Delete proposal templates in the Templates page, by selecting the Delete icon for the template you want to delete.

Navigation

Oracle Proposals > Administration > Templates > Templates page

Working with Proposal Templates from Campaign Activities

To perform the procedures listed in this section, you must log into the Campaign Activity Workbench under Oracle Applications' Self-Service mode. Consult the Oracle Marketing User Guide for details.

Notes

Associating Proposal Templates in Campaign Activities

A lead from a campaign activity, when executed, might become an opportunity. Campaign managers can associate proposal templates which can later be used by the sales representative when working on an opportunity created from the campaign. Users can publish and associate a template with a campaign activity.

Notes

Viewing Proposal Templates associated with Campaign Activities

You can view any existing proposal templates that are associated with a campaign activity.

Notes

Deleting Proposal Templates associated with Campaign Activities

Deleting proposal templates in Oracle Proposals that are associated with campaign activities can affect multiple campaigns. Before deleting a template, check to see if it is associated with any campaign. If there is an association, inform users about the association before deleting the template.

Unpublishing Proposal Templates associated with Campaign Activities

If a template that is associated with a campaign activity is unpublished in Oracle Proposals, the template is no longer made available to users through the campaign activity for the language in which it is being unpublished. When such a template is unpublished, it does not impact the campaign activity association and therefore no further action is necessary.

RTF Files Overview

The RTF files are the proposal files that contain the actual content (text, graphics, or tables) that represent proposal components. You create these files in your preferred editor/word processing application and save them as RTF files. After you create the files, upload and map them to individual proposal components. These RTF files make up the individual sections of the proposal.

This section provides guidelines, suggestions, and information on creating RTF files.

RTF 1.8 Support

Oracle Proposals supports certain features of the RTF 1.8 specification. These features are:

See Oracle Proposals Implementation Guide and the Microsoft Word 2003 Rich Text Format (RTF) Specification, version 1.8 for details.

Note: Oracle Proposals supports only RTF files created using Microsoft Word.

Creating RTF Files Guidelines

Please note the following important guidelines for RTF file creation:

The following formats are not valid:

Invalid entries result in errors during the RTF file upload.

Note: All files must be named with an RTF extension to be correctly processed in Oracle Proposals.

Dynamic Field Structure in RTF Files

Oracle Proposals provides seeded Structure Dynamic Fields to accommodate the addition of multiple quotes to a proposal as well as those proposals with quotes containing multiple lines. These structure dynamic fields enable users to designate the structure where multiple quotes, lines or any other data must be inserted into the file. These are only used for organizing quote-related information in RTF files.

Any quote related dynamic field placed outside the control structure are substituted using the first quote in the proposal.

Related Topics

Other Administrative Tasks

Setting Profile Options

When implementing Oracle Proposals, you must set specific profile options. See the Oracle Proposals Implementation Guide for details.

Creating Proposals Using Unpublished Templates

Only users with the appropriate profile option settings can create proposals using unpublished templates. See the Oracle Proposals Implementation Guide for details on profile option settings.

Concurrent Program for Offline Generation

Whether proposals are generated offline or online is determined by thresholds set in profile options. See the Oracle Proposals Implementation Guide for details on profile option settings.