This appendix covers the following topics:
This appendix contains details, scenarios, and guidelines for dynamic field creation in RTF files.
Users can add multiple quotes to a proposal. Also, a single quote can have multiple lines. To represent this variance generically in the RTF file, Oracle Proposals seeds Structure Dynamic Fields. These dynamic fields are identified by the prefix PRPSTR in the dynamic field code.
The structure tokens enable users to indicate structure where multiple quotes, lines or other information is expected. Structure tokens are applicable only for designing quote related information in an RTF file.
While quote related dynamic fields can be used outside of control structures, doing so does not enable the parser to repeat the information for all the quotes associated with the proposal. Any quote related dynamic field placed outside the control structure is substituted using the first quote in the proposal.
A quote can be logically represented using the control structure in an RTF file in the following way:
Begin quote
Begin quote line
(Quote line related dynamic fields inserted here)
End quote line
Begin promocode line
(Promotional code related dynamic fields inserted here)
End promocode line
Begin contract
Begin Contract article
(Contract related dynamic fields inserted here)
End contract article
End contract
End quote
This structure, when represented in the form of dynamic fields in an RTF file, should be:
<@PRPSTR001:Begin Quote@>
(Quote related dynamic fields are inserted here.)
<@PRPSTR003:Begin Quote Line@>
(Quote and quote line related dynamic fields inserted here.)
<@PRPSTR004:End Quote Line@>
<@PRPSTR005:Begin Contract@>
(Quote related dynamic fields inserted here.)
<@PRPSTR007:Begin Contract Article@>
(Quote and Contract related dynamic fields are inserted here)
<@PRPSTR008:End Contract Article@>
<@PRPSTR006:End Contract@>
<@PRPSTR009:Begin Promocode@>
(Quote and Promotional code related dynamic fields inserted here.)
<@PRPSTR010:End Promocode@>
<@PRPSTR002:End Quote@>
Consider the following example:
Proposal: Business Network Proposal. Quotes in the proposal equal 2.
Quote #1:
Quote name: Simple Solution
Quote line 1= Laptop; Line selling Price = $2500
Quote line 2 = Desktop; Line selling Price = $2000
Quote #2:
Quote Name: Custom Solution
Quote line 1= Custom Laptop; Line Selling Price =$5000
Quote line 2 = Custom Desktop; Line Selling Price = $3500
Scenario 1: Quote Related Dynamic Field Without, or Outside of, the Control Structure
The following table outlines the RTF representation for a quote related dynamic field without, or outside of the control structure.
| Field | Token |
|---|---|
| Quote: <@PRPQOT001:Quote Name@> | Proposal: <PRP001:Proposal Name@> |
| <@PRPQOT044:Product Description@> | $<@PRPQOT052:Line Total Selling Price@> |
What to expect:
The following table outlines the output for the RTF representation listed earlier.
| Output Data | Output Data |
|---|---|
| Quote: Simple Solution | Proposal: Business Network Proposal |
| Laptop | $2500 |
Because there are no structure tokens, the parser does not know what section is a quote or what must be repeated. When the parser encounters a quote dynamic field it uses the values from the first quote (in this case Simple Solution) to substitute the quote name. For the product description and price, it selects the first line item from the quote.
Scenario 2: Quote Related Dynamic Fields Within the Quote Header Control Structure (But Without the Line Control Structure)
RTF representation:
<@PRPSTR001:Begin Quote@>
The following table outlines the RTF representation of quote related dynamic fields within the quote header control structure.
| Field | Token |
|---|---|
| Quote: <@PRPQOT001:Quote Name@> | Proposal: <PRP001:Proposal Name@> |
| <@PRPQOT044:Product Description@> | $<@PRPQOT052:Line Total Selling Price@> |
<@PRPSTR002:End Quote@>
Note the following changes between scenario 1 and 2: Scenario 1 did not have a begin and end quote header structure. So Oracle Proposals used the first quote information. In this case, the application knows that anything between PRPSTR001 and PRPSTR002 is a quote and must be repeated. Since there are two quotes on this proposal, this structure is repeated twice – once for each quote. But since the structure needed to repeat quote line is not there, Proposals uses the first line item for each quote while generating this RTF file.
The following table outlines the output for the RTF file structure outlined earlier.
| Output Data | Output Data |
|---|---|
| Quote: Simple Solution | Proposal: Business Network Proposal |
| Laptop | $2500 |
| Quote: Custom Solution | Proposal: Business Network Proposal |
| Custom Laptop | $5000 |
Scenario 3: Quote Related Dynamic Fields Within the Quote Header and Line Control Structure
RTF representation:
<@PRPSTR001:Begin Quote@>
The following table outlines Scenario 3: Quote Related Dynamic Fields Within the Quote Header and Line Control Structure.
| Field | Token |
|---|---|
| Quote: <@PRPQOT001:Quote Name@> | Proposal: <PRP001:Proposal Name@> <PRPSTR003:Begin Quote Line@> |
| <@PRPQOT044:Product Description@> | $<@PRPQOT052:Line Total Selling Price@> <PRPSTR004:End Quote Line@> |
<@PRPSTR002:End Quote@>
Note the following changes between scenario 2 and 3: Scenario 2 did not have a begin and end quote line structure. So Oracle Proposals used the first quote line information for each quote. In this case, the application knows that anything between PRPSTR003 and PRPSTR004 is a quote line, and must be repeated for each line in the quote. Since there are two quote line for each quote on this proposal, this structure is repeated twice for each quote.
The following table outlines the output for the preceding RTF file.
| Output Data | Output Data |
|---|---|
| Quote: Simple Solution | Proposal: Business Network Proposal |
| Laptop | $2500 |
| Desktop | $2000 |
| Quote: Custom Solution | Proposal: Business Network Proposal |
| Custom Laptop | $5000 |
| Custom Desktop | $3500 |
The following rules must be followed:
All control structures for a quote should be within begin quote and end quote structure.
If a quote related dynamic field is placed outside of the control structure, the substituted value is used from the first quote.
Control structure for quote line, promotional code, and/or contract placed outside of begin quote and end quote structure are invalid.
Every Begin structure should have its corresponding End structure.
Control structures should not overlap. For example, the following is invalid:
<begin quote line>
<begin promocode>
<end quote line>
<end promocode>
There should not be duplicate control structure within an existing one. For example:
<begin quote line>
<begin quote line>
<end quote line>
<end quote line>
Quote related dynamic fields can be placed anywhere within the begin quote and end quote structure.
If a promotional code dynamic field is placed outside <begin promocode> and <end promocode> structure, the first promotional code of the quote returned by the database is used during generation.
Similarly if a pricing dynamic field is placed outside the <begin quote line> and <end quote line> structure, the first quote line of the quote returned by the database is used during generation.
<Begin Contract Article> and <End Contract Article> structure fields can be used only within <Begin Contract> and <End Contract> structure.
Following is sample text for an RTF document containing dynamic fields. For this example, a simple cover letter has been created using proposal seeded dynamic fields and two user defined dynamic fields. The user defined dynamic fields enable the user to provide personalized text in the body section and a date dynamic field to add even further personalization.
July XX, 200X
<@PRP007:Contact Name@>
<@PRP006:Customer Name@>
Dear <@PRP007:Contact Name@>,
<@UDF004:Cover Text@>
As a Vision Enterprises customer, you already use our desktops to increase productivity in critical areas of your business. I invite you to review the attachments enumerating some of the key benefits of upgrading your systems. I can be reached at <@PRP013:Sales Rep Phone Number@> or through email at <@PRP015:Sales Rep Email@>.
I would appreciate if we can do a follow-up call on <@UDF006: Follow-up Date@>.
Sincerely,
<@PRP012:Sales Rep Name@>
Account Manager
Vision Enterprises
The following are not supported during the merging process and will result in errors. Please note the following:
Page Setup that distinguishes Odd, Even and First pages in a document are not supported.
When documents are merged, there is no way to determine where these specially formatted pages will appear in the final document. Parameter definitions for these types of pages within the individual documents will be lost.
Only one section is allowed within a document.
RTF does not support nested sections. Documents set up to be merged as individual sections in the final document are logically mapped. Definition of parameters for sections within the individual documents will be lost.
Headers and Footers must be carefully implemented.
Headers and Footers set in an individual document will be carried forward to subsequent documents in the merged document, unless they are overwritten by Headers and Footers defined in the subsequent documents.
Drawings and Images must be anchored.
To preserve the exact position of a drawing in the merged document, it must be anchored.
Table of Contents styles not supported
Table of Contents files throw errors during generation or during RTF file association with components - This happens because Oracle Proposals does not support components with RTF files that were created using standard Table of Content styles. You cannot include a table of contents as a component.
Be aware of the following common errors:
Make sure that structure tags are the first tokens for quote tokens.
There should not be any spaces between the token code and "<@" or ":"
For example, the following formats are valid:
<@PRP001: Proposal Name@>
<@PRP001:Proposal Name@>
<@PRP001:Proposal Name @>
The following formats are not valid:
<@PRP001 :Proposal Name@>
< @PRP001:Proposal Name@>
<@ PRP001:Proposal Name@>
<@PRP001: Proposal Name@ >
Invalid entries result in an error.
If the RTF document begins with a token, many word processing applications copy it into the document title. If the entered token contains an error, the document title will repeat that error. Eventually, when users correct the error, the token in the document title is not corrected by the word processing program. The parser will still display an error.
Certain characters are not valid file extensions and, if users try to download a file with an invalid extension, some operating systems create a system generated name for the file. This can cause other problems. Currently, a generated document picks up the name from the proposal name. This will be modified to replace all characters not valid in the operating system with a space.
If the code has been corrupted during file upload, you will receive an error message. This error message can contain extra characters that do not reflect the actual character set in your RTF file. This error occurs because a particular style has been applied to part of the token. To resolve this issue, you can perform one of the following:
Delete the particular token and re-enter it.
Or
Select the whole token and apply its style.