Chapter 11
Configuration and Customization
This chapter provides guidelines on implementing customizations as well as instructions on customizing some of the BuyerXpert/SellerXpert features for your operation.
This chapter contains the following sections:
About Administering Customizations
An administrator is generally concerned with the following aspects of customization:
Doing customizations that do not require programming skills, such as:
Verifying customizations that do require programming skills and thus, have been written by a developer, such as:
Adding new fields to a data object
Modifying look and feel of the graphical interface
Adding new fields to the inbound/outbound file for ECXpert
Creating new reports; modifying existing reports
Implementing customizations to production.
As the administrator, you are responsible for verifying that developer-level customizations have been tested on a staging system (testing can be done by the developer or you), and for implementing the customization to the BuyerXpert/SellerXpert production system
Setting Up Interface to an API
If an application program interface (API) has been written for your BuyerXpert/SellerXpert system, you will need to establish an interface to the API. A typical situation for creating an API related to product data is when your organization has an existing enterprise resource planning (ERP) database and you want the accounting and/or commodity codes that already exist in your ERP to be validated when line items are added to a requisition. Without an API, BuyerXpert/SellerXpert has no way of interfacing with your ERP system.
Testing and Implementing Customizations
After any customization work is completed, you will need to test the results and the impact of the customizations on BuyerXpert/SellerXpert. Even if you or the developer has already done some testing in the staging environment, you will need to verify the testing. While the developer is responsible for creating customizations that work, you are responsible for the operation of BuyerXpert/SellerXpert, so it is very important that you are careful about anything that impacts your production system.
To test customizations in the staging environment:
Load customization files to the staging system.
Test the behavior of the files
Verify success.
Get requester sign-off, if applicable.
After you are satisfied that the customizations work correctly in the BuyerXpert/SellerXpert staging environment, you are ready to implement them to production.
When a customization is ready for testing (or for implementation, if the developer has done the staging testing), the following information should be provided by the person who did the customization:
Location—where the files are located
Documentation—Readme file and any other documentation that explains the customization and how to use it
Testing done—description of what testing has been done in the development or staging environment
Impact areas—description of what BuyerXpert/SellerXpert areas will be impacted by this customization
Requester sign-off—verification by the requester that the customization is what was requested
To implement developer customizations to production, follow these guidelines:
Schedule implementation.
Load customization files to the production system.
Test behavior of the customization.
Verify success.
Notify users.
Archive source files.
Configuring Additional Information Fields (AIFs)
By default, AIFs are presented as text fields. You can change them into list boxes with predefined values by configuring certain NTV files.
The following scenario shows how to create a list box for a field named Size, with list box options of Small, Medium, Large, and Extra Large
Use the Admin interface to create an AIF called Size.
Modify the repository.ntv file located in following directory, adding an entry for the field Size:
$IASROOT/buyer/buyer/config/aif/repository.ntv
"Size" NTV {
"datatype" Str "String",
"type" Str "List",
"codecategory" Str "Size_options",
}
Modify the codes.ntv file located in the same directory, adding the list box options for Size as follows:
$IASROOT/buyer/buyer/config/aif/codes.ntv
"size_options" NTV {
"small" Str "Small",
"medium" Str "Medium",
"large" Str "Large",
"extra_large" Str "Extra Large",
}
*Configuring Non-Catalog Fields
For non-catalog items, you can configure the fields for which information entry is mandatory. Exceptions to this are:
Estimated Price—Always mandatory. Users must enter some value.
Unit of Measure—Always mandatory. You can set a default value for the BuyerXpert/SellerXpert instance.
The fields configured to be mandatory will have a blue star (*) symbol displayed against of them. This symbol is configurable.
To make a non-catalog field mandatory, follow these steps:
Modify the following file:
<IAS_ROOT>/buyer/buyer/config/oms/omsInfo.ntv
Modify the NTV of a particular non-catalog field to set "optional" to false. This makes the field mandatory. For example:
"Product Code" NTV {
"optional" Bool "true",
"default" Str "MyCode",
},
-
To make the Product Code field mandatory and to set a default value of "ABC1000", modify the above NTV as follows:
"Product Code" NTV {
"optional" Bool "false",
"default" Str "ABC1000",
},
To configure the symbol displayed against a mandatory field, follow these steps:
Modify the following file:
<IAS_ROOT>/ias/APPS/buyer/com/iplanet/buyer/templates/en/US/catalog
/EnterEntry.jsp
|
Note
|
The above file is for the en/US locale. For other locales, replace en/US appropriately.
|
For configuring the symbol displayed against the Product Code field, look for the following section:
<% if (!Config.getBool("NonCatalog.Product Code.optional")) { %>
<!-- begin required marker -->
<font size="+2" color="blue"><tt><b>*</b></tt></font></td>
<!-- end required marker -->
<% } %>
Modify the parameters for font size, color, and symbol. For example, to display a # symbol against a mandatory field in red, with a font size of 3, you would change the above section as follows:
<% if (!Config.getBool("NonCatalog.Product Code.optional")) { %>
<!-- begin required marker -->
<font size="+3" color="red"><tt><b>#</b></tt></font></td>
<!-- end required marker -->
<% } %>
Configuring Intelligent Choosers
To configure a particular chooser to provide drop-down list, follow these steps:
Modify the following NTV file:
<IAS_ROOT>/buyer/buyer/config/oms/chooser.ntv
For an NTV of a particular chooser, set the value for "maxShortList". When the possible values to choose from for this field is less than the set number, a drop-down list will be generated.
For example, for the line item accounting code chooser, set maxShortList to 20 and set dropDownList to True.
// accounting codes chooser
"LineAccountingCodeChooser" NTV {
"id" Str "Code",
"title" Str "Accounting Codes Chooser",
"template" NTV {
"maxShortList" Int "20", \
"dropDownList" Bool "true"
..
..
When the possible values for an accounting code segment are less that 20, a drop-down list displaying those values will be generated for that accounting code segment. If the possible values are more than 20, the segment will display a chooser as it did in BuyerXpert/SellerXpert 4.0. If you want to display a drop-down regardless of the possible values for the accounting code segment, then set maxShortList to -1
If you do not want dropdown list under any circumstances, set dropDownList to false. In that case, BuyerXpert/SellerXpert will always display chooser and the value set to maxShortList will be used as explained in the following example:
// accounting codes chooser
"LineAccountingCodeChooser" NTV {
"id" Str "Code",
"title" Str "Accounting Codes Chooser",
"template" NTV {
"maxShortList" Int "200", \
"dropDownList" Bool "false"
..
...
"pageSize" Int "10",
...
...
If the possible values for an accounting code segment are less than 200 (value set to maxShortList), then a chooser initially displaying first 10 (value set to pageSize) of the possible 200 values will be generated.
You can display more or less values by changing the value of pageSize. If the possible values for the accounting code segment are more than 200, a chooser with no initial values will be displayed. When a user does a search for codes using the normal or advanced search, results will be displayed in sets of 10 (value set to pageSize) per page. You can display more or fewer values for the search result by changing the value of pageSize.
To force to chooser to behave like BuyerXpert/SellerXpert 4.0, set the maxShortList to 0. To force it to turn it into a drop-down list, set maxShortList to -1.
*Configuring for Attribute-Based Manager
By default, BuyerXpert/SellerXpert associates managers for users through the organizational unit. It is also possible to associate manager information with individual users as an attribute of the user, as opposed to the indirect representation through organizational units.
To enable attribute-based manager functionality, you must toggle the config setting in the following NTV file as shown:
<iasroot>/buyer/config/com/iplanet/ecommerce/membership/config/appInfo.ntv.
NTV-ASCII {
"membership" NTV {
...
// defaulted to false for the org unit based manager
"useManagerAttr" Bool "true",
...
},
}
This enables administration of the manager from the user identification screen and as a user attribute when using the Import utility.
By default, the approval process is set to walk the manager chain through organizational units. When using the attribute-based manager, you might need to configure the approval process also to the attribute-based manager chain.
To enable this:
Launch the Builder.sh application from the <IASROOT>/builder/ directory.
Open the prototype_req_mercurycom application.
Open the calc_manager_approval function located under Scripts Dictionary/Automation Scripts.
Go to the following line:
var manager = req.getManager(creator.getHandle(), 1, false);
-
(The last parameter value, false, gets managers from the organizational unit chain.)
Change this line to:
var manager = req.getManager(creator.getHandle(), 1, true);
-
(The last parameter value, true, gets managers based on user attribute.)
After making the change, click OK.
Save the process by clicking Save.
For these changes to take effect, deploy the process by clicking Deploy.
|
Note
|
Although it is not required that the approval process setting for walking the manager chain be synchronized with the manager information setting, it might be required that the approval process walk the preferred representation of the manager chain. Therefore, it is recommended that both settings above be synchronized.
|
*Customizing Invoice Matching
The invoice matching functionality of BuyerXpert/SellerXpert allows a developer to customize your site to do the following:
Receive an invoice into BuyerXpert/SellerXpert via XML document
Run the invoice through an invoice matching algorithm, which may be customized
Present a user interface to modify the invoice if the matching algorithm fails
Generate a payment voucher XML document out of BuyerXpert/SellerXpert on success.
The invoice matching algorithm is implemented in iPlanet Process Manager with JavaScript. The Process Manager interface exposes data from the invoice header, invoice lines, and associated order lines, including receiving information. This allows for customization of the invoice matching routine if the delivered algorithm does not meet the requirements of your BuyerXpert/SellerXpert operation.
The following sections discuss customizing the invoice matching feature:
*Customizable Fields
The invoice matching feature provides customizable fields that can be tailored to for your BuyerXpert/SellerXpert operation. For example, if you are manually entering invoices, you may want to track when the invoices were entered and by whom.
The customizable fields include a set of String, Date, and Amount type fields for the invoice header and invoice lines. Customizable fields function in the following way:
Customizable fields may be included in the invoice XML file for entry into BuyerXpert/SellerXpert.
Customizable fields are saved in permanent store in BuyerXpert/SellerXpert.
Customizable fields are made available to the Process Manager invoice matching algorithm JavaScript.
Customizable fields may be exposed in the user interface for viewing and editing.
Customizable fields are included in the outbound payment voucher XML file.
*Delivered Algorithm
BuyerXpert/SellerXpert is delivered with a Process Manager process for invoice matching which may be useful to your operation as it is. If not, this delivered algorithm can be customized. The invoice matching algorithm is divided into two phases:
Phase 1 does validation on the invoice itself, that is, determining whether the invoice total matches the total of the lines.
Phase 2 matches the invoice lines against the associated order lines, that is, the price on the order compares correctly to the price on the invoice.
The source contains pseudo-code documentation of the functionality of the delivered algorithm, which is accessed using the Process Builder tool.
*Access to BuyerXpert/SellerXpert Data
Access to the BuyerXpert/SellerXpert data is provided using the invoice object to access invoice header, invoice line, and associated order line data. To get the invoice object, use the following code in your Process Manager JavaScript (you will see this in the sample code):
var pi = getProcessInstance();
var invoice = pi.getData("invoice");
The following methods of the invoice object show how to access invoice header, invoice line, and associated purchase order line data respectively:
// Get invoice total from the invoice header
var invoiceTotal = invoice.getDec("order_total");
// Get the total number of invoice lines
// Invoice lines are accessed sequentially starting with a zero index invoice.getTotalLines();
// Get invoice line total from the invoice line "i"
invoiceLineTotal = invoiceLineTotal.add(invoice.getLineDec(i, "line_total"));
// Get the unit price for the PO line associated with invoice line "i" var unitPrice = invoice.getPOLineDec(i, "net_price");
The following sections document the methods and data available for accessing invoice header, invoice line, and associated order line data. In addition, there are some utility methods available.
*Functions to Retrieve Invoice Header Values
getStr(String name) get a String value
getInt(String name) get an int value
getLong(String name) get a long value
getBool(String name) get a boolean value
getFloat(String name) get a float value
getDec(String name) get a BigDecimal value
Table 11-1 Available Invoice Header Values
|
Name
|
Type
|
Description
|
|
inv_number
|
String
|
Invoice number
|
|
inv_date
|
Date
|
Invoice date (from the invoice)
|
|
inv_desc
|
String
|
Invoice description
|
|
buying_company_name
|
String
|
Name of buying company
|
|
selling_company_name
|
String
|
Name of selling company
|
|
currency_code
|
String
|
Currency code
|
|
order_total
|
BigDecimal
|
Total invoice amount
|
|
group_freight
|
BigDecimal
|
Total group freight
|
|
group_dcap
|
BigDecimal
|
Total group DCAP
|
|
group_tax
|
BigDecimal
|
Total group tax
|
|
invoice_url
|
String
|
Invoice URL provided
|
|
other_date1
|
Date
|
For custom-use date1
|
|
other_date2
|
Date
|
For custom-use date2
|
|
other1
|
String
|
For custom-use string1
|
|
other2
|
String
|
For custom-use string2
|
|
other3
|
String
|
For custom-use string3
|
|
other4
|
String
|
For custom-use string4
|
|
other5
|
String
|
For custom-use string5
|
|
other_amount1
|
BigDecimal
|
For custom-use currency amount1
|
|
other_amount2
|
BigDecimal
|
For custom-use currency amount2
|
|
other_amount3
|
BigDecimal
|
For custom-use currency amount3
|
*Functions to Retrieve Invoice Line Values
getLineStr(int lineNumber, String name) get a String value
getLineLong(int lineNumber, String name) get a long value
getLineInt(int lineNumber, String name) get an int value
getLineFloat(int lineNumber, String name) get a float value
getLineDouble(int lineNumber, String name) get a double value
getLineDec(int lineNumber, String name) get a BigDecimal value
Table 11-2 Available Invoice Line Values
|
Name
|
Type
|
Description
|
|
inv_line
|
long
|
Invoice line number
|
|
order_code
|
String
|
Order code
|
|
line_item_number
|
int
|
Order line item number
|
|
product_code
|
String
|
Product code
|
|
product_description
|
String
|
Product description
|
|
contract_number
|
String
|
Contract number
|
|
quantity_uom
|
String
|
Unit of measure for quantity
|
|
net_quantity
|
long
|
Quantity
|
|
unit_price
|
BigDecimal
|
Unit price
|
|
line_total
|
BigDecimal
|
Total for line
|
|
total_tax
|
BigDecimal
|
Total tax for line
|
|
freight_amount
|
BigDecimal
|
Total freight for line
|
|
dcap_on_amount
|
BigDecimal
|
Total DCAP for line
|
|
other_amount1
|
BigDecimal
|
For custom-use currency amount 1
|
|
other_amount2
|
BigDecimal
|
For custom-use currency amount 2
|
|
other_amount3
|
BigDecimal
|
For custom-use currency amount 3
|
|
other_amount4
|
BigDecimal
|
For custom-use currency amount 4
|
|
other_amount5
|
BigDecimal
|
For custom-use currency amount 5
|
|
other_amount6
|
BigDecimal
|
For custom-use currency amount 6
|
|
other_date1
|
Date
|
For custom-use date1
|
|
other_date2
|
Date
|
For custom-use date2
|
|
other1
|
String
|
For custom-use string1
|
|
other2
|
String
|
For custom-use string2
|
|
other3
|
String
|
For custom-use string3
|
|
already_invoiced
|
long
|
Quantity already invoiced
|
*Functions to Retrieve PO Line Values
There are purchase order lines associated with a particular invoice line. The lineNumber is the invoice line number.
getPOLineStr(int lineNumber, String name) get a String value
getPOLineLong(int lineNumber, String name) get a long value
getPOLineInt(int lineNumber, String name) get an int value
getPOLineFloat(int lineNumber, String name) get a float value
getPOLineDouble(int lineNumber, String name) get a double value
getPOLineDec(int lineNumber, String name) get a BigDecimal value
Table 11-3 Available Purchase Order Line Values
|
Name
|
Type
|
Description
|
|
seller_company_name
|
String
|
Name of the selling company
|
|
line_number
|
int
|
Order line number
|
|
allow_partial_ship
|
boolean
|
Whether partial shipment is allowed
|
|
product_code
|
String
|
Product code
|
|
commodity_code
|
String
|
Commodity code
|
|
product_description
|
String
|
Product description
|
|
inventory_identifier
|
String
|
Inventory identifier
|
|
external_product_code
|
String
|
External product code
|
|
external_product_description
|
String
|
External product description
|
|
order_code
|
String
|
Order code
|
|
quantity_uom
|
String
|
Unit of measure
|
|
quantity_requested
|
String
|
Quantity requested
|
|
quantity_sold
|
long
|
Quantity sold
|
|
quantity_shipped
|
long
|
Quantity shipped
|
|
quantity_received
|
long
|
Quantity received
|
|
total_tax
|
BigDecimal
|
Total tax
|
|
net_price
|
BigDecimal
|
Net price per unit
|
|
net_total
|
BigDecimal
|
Net total price
|
|
net_tax
|
BigDecimal
|
Net tax
|
|
total_tax
|
BigDecimal
|
Total tax
|
|
line_total
|
BigDecimal
|
Total of line
|
|
is_off_catalog
|
boolean
|
Off catalog flag
|
|
base_total
|
BigDecimal
|
Base total
|
|
gross_total
|
BigDecimal
|
Gross total
|
|
catalog_code
|
String
|
Code from the catalog
|
|
is_price_overridden
|
boolean
|
Whether price was over-ridden
|
|
line_currency_code
|
String
|
Currency code
|
|
matching_algorithm
|
String
|
Matching algorithm as set by rule
|
*Utility Methods
Most of the utility methods are accessed using the BuyerXpert/SellerXpert EJB. Obtain access to the BuyerXpert/SellerXpert EJB through the process instance handle, as follows:
var handle = pi.getData("handle");
var home = ejbLookup("ejb/com/iplanet/buyer/BuyerEJB");
var buyer = home.create();
The following utilities are provided using the BuyerXpert/SellerXpert EJB:
// Clear the processing errors list
// This should be called at the beginning of each phase of checking
a case
// See the usage in the sample invoice matching process
buyer.clearIMErrors(handle);
// Add an error condition to the processing errors list
// This routine is called whenever your invoice matching processing
detects an error condition
// handle: The case handle as obtained above
// invoice_line_index: the zero-based index of the invoice line
items
// Use -1 if the error is not associated with a particular invoice
line
// code: Currently unused. Pass a zero value.
// description: Free text description of the error. This text is
presented to the user.
// field: The name of the field with which the error is
associated (optional)
//
// Error messages are displayed to the end user in the problem
invoice UI
// Errors associated with a particular invoice line index will be
displayed with that line
// Other errors are displayed with the invoice header
//
buyer.createIMError(handle, invoice_line_index, code, description,
field);
// Check for valid currency code
buyer.isValidCurrency(handle, currencyCode)
// Check for valid UOM code
buyer.isValidUOM(handle, uomCode)
// Notify BuyerXpert group via problem invoice task list
// group_name is the name of an existing BuyerXpert group
buyer.notifyIMGroup(handle.toString(), group_name);
// Change the status of the invoice matching case
// "VALIDATION_EXCEPTION"
// "PENDING_APPROVAL
buyer.changeIMCaseState(handle.toString(), status);
The following utilities are provided using the invoice object:
// Create a BigDecimal variable with an initial value
var decZero = invoice.resetDec(0.0);
*Custom-Use Fields
The custom-use fields may be included in the input invoice XML file. (See the invoice DTD for the names of the fields.) They are also accessible in the invoice user interface and the Invoice Matching Process Manager Process JavaScript. This section documents the names and the types for the fields.
Use in Invoice User Interface
The custom-use fields can be displayed and edited in the invoice user interface by modifying the following templates:
InvoiceView.jsp—The display of the invoice header and line information. Shows edit buttons in edit mode.
InvoiceEditHeader.js—The invoice header edit screen.
Invoice AddEditLine.jsp—The screen for adding a new line or editing a line.
The templates are in two locations. You should make sure your modifications are applied to the templates in both locations:
You will see sections for existing fields in each of the templates. You should copy a section which will begin with a <TR> tag and end with a </TR> tag, then change the label and data retrieval for your new field. Be sure that the data access method matches the type of the field you are using. The following fields are available:
|
Header
|
OTHER_DATE1
|
Date
|
|
|
OTHER_DATE2
|
Date
|
|
|
OTHER1
|
String
|
|
|
OTHER2
|
String
|
|
|
OTHER3
|
String
|
|
|
OTHER4
|
String
|
|
|
OTHER5
|
String
|
|
|
OTHER_AMOUNT1
|
BigDecimal
|
|
|
OTHER_AMOUNT2
|
BigDecimal
|
|
|
OTHER_AMOUNT3
|
BigDecimal
|
|
|
|
|
|
Line
|
OTHER_DATE1
|
Date
|
|
|
OTHER_DATE2
|
Date
|
|
|
OTHER1
|
String
|
|
|
OTHER2
|
String
|
|
|
OTHER3
|
String
|
|
|
OTHER4
|
String
|
|
|
OTHER5
|
String
|
|
|
OTHER_AMOUNT1
|
BigDecimal
|
|
|
OTHER_AMOUNT2
|
BigDecimal
|
|
|
OTHER_AMOUNT3
|
BigDecimal
|
|
|
OTHER_AMOUNT4
|
BigDecimal
|
|
|
OTHER_AMOUNT5
|
BigDecimal
|
|
|
OTHER_AMOUNT6
|
BigDecimal
|
Use in Process Manager Process JavaScript
Similarly, these fields can be accessed in the process manager Java Script. To access invoice header fields, use the following methods on the JavaScript invoice object:
Date invoice.getDate("name");
String invoice.getStr("name");
BigDecimal invoice.getDec("name");
To access invoice line fields, use the following methods on the JavaScript invoice object:
Date invoice.getLineDate(line_index, "name");
String invoice.getLineStr(line_index, "name");
BigDecimal invoice.getLineDec(line_index, "name");
The field names for the header and line, respectively are:
other_date1, other_date2, other1, other2, other3, other4, other5, other_amount1, other_amount2, other_amount3.
other_date1, other_date2, other1, other2, other3, other_amount1, other_amount2, other_amount3, other_amount4, other_amount5, other_amount6
*Customizing Seller Performance
The seller performance feature of BuyerXpert/SellerXpert allows a user to capture quality data during the receiving process. This data is meant to be a measure of the quality of a seller's performance.
Customizing the seller performance feature involves customizing the amount and type of quality data that a user is required, or allowed, to enter while receiving items against a purchase order.
Customizing the seller performance feature involves the tasks described in the following sections:
*Creating a Template (JSP Template)
Creating a template requires knowledge of the following:
Java Server Page and Servlet programming
JSP programming in the BuyerXpert/SellerXpert framework
BuyerXpert/SellerXpert data and object repository and how it works
APIs provided by the VendorPerformance servlet
The following sample templates are provided to aid in developing custom templates:
Data that is entered as quality data is stored in the database in a table called quality_entry_data as described in Table 11-4.
Table 11-4 Quality Data Table
|
Name
|
Null?
|
Type
|
|
ID
|
NOT NULL
|
NUMBER(19)
|
|
NAME
|
NOT NULL
|
VARCHAR2(80)
|
|
LINE_ITEM_ID
|
NOT NULL
|
NUMBER(19)
|
|
DATA_TYPE
|
NOT NULL
|
NUMBER(10)
|
|
STRING_DATA
|
|
VARCHAR2(1024)
|
|
NUMERICAL_DATA
|
|
NUMBER(19)
|
|
DECIMAL_DATA
|
|
NUMBER
|
|
SELLER_HANDLE
|
NOT NULL
|
VARCHAR2(80)
|
|
OWNER_HANDLE
|
NOT NULL
|
VARCHAR2(80)
|
The important fields to note are STRING_DATA, NUMERICAL_DATA, and DECIMAL_DATA, one of which stores the actual data. DATA_TYPE identifies which of these fields contains the data.
Each data field on the JSP has one row in the quality data table. With these fields in the database, the datatypes listed in Table 11-5 are supported for the user interface.
Table 11-5 User Interface Datatypes
|
Name
|
Description
|
|
QualityTextLine
|
Text box 25 columns wide
Data stored in STRING_DATA
DATA_TYPE = 10
|
|
QualityTextBlock
|
Text box 40 columns wide and 5 rows
Data stored in STRING_DATA
DATA_TYPE = 11
|
|
QualityFactorLong
|
Drop-down list containing long values
Data stored in NUMERICAL_DATA
DATA_TYPE = 20
|
|
QualityFactorDouble
|
Drop-down list containing decimal values
Data stored in DECIMAL_DATA
DATA_TYPE = 21
|
|
QualityFactorString
|
Drop-down list containing String values
Data stored in STRING_DATA
DATA_TYPE = 22
|
|
QualityMailList
|
Drop-down list allowing user to choose email targets
Data stored in STRING_DATA
DATA_TYPE = 30
|
The user interface datatypes are Data and Object Repository (DOR) entries and can be found in the following file:
$APPS/com/iplanet/buyer/config/srm/repository.ntv
Minimum JSP Requirements
Every JSP should have the following lines at the beginning of the JSP:
<%@ include file="/com/iplanet/buyer/templates/bx_prolog.jsp"%>
<%@ include file="/com/iplanet/buyer/templates/bx_format.jsp"%>
In addition, the following line should be at the end of the JSP:
<%@ include file="/com/iplanet/buyer/templates/bx_epilog.jsp"%>
|
Note
|
You can use the SampleDaysLate.jsp or SampleMultiPart.jsp as a template for creating your own custom JSPs.
|
Creating an HTML FORM
In the BuyerXpert/SellerXpert framework, create an HTML FORM as follows:
<% fc = oc.getForm
(VendorPerformance.VENDOR_PERFORMANCE_FORM,
"buyer/VendorPerformance"); %>
<%= fc.beginForm ("METHOD=post") %>
This is equivalent to the <FORM ...> tag in HTML.
|
Note
|
You should not change the FORM name or the name of the Servlet which is going to handle this form.
|
A hidden field containing the primary key of the line item has to be added to each FORM. To add this field:
<%
String id = oc.getStr(SRMServletConstants.OBJECT_ID);
pc = fc.getPC("Hidden", SRMServletConstants.OBJECT_ID);
pc.setValue(id);
%>
<%= pc.getHtml() %>
The FORM should be terminated as follows:
<%= fc.endForm() %>
This is equivalent to the </FORM> tag in HTML.
Putting a Submit Button on the HTML FORM
Each button you put on a JSP is a DOR entry defined in the following file:
$APPS/com/iplanet/buyer/config/srm/repository.ntv
The buttons which are available to you are:
Save Quality Data—Used to submit the FORM. Instructs the Servlet to save data edited by the user. The label on this button is Save.
Done Quality Data—Used to configure the Servlet to ignore user edits. The label on this button is Done Editing.
Example
To add a button:
<% pc = fc.getPC( "SaveQualityData", SRMServletConstants.ACTION); %>
<% pc.setHtmlAttrs("border=0"); %>
<%= pc.getHtml() %>
Adding One of the UI Elements to a JSP
To create and place one of the above user interface elements on a JSP, you will have to use the FormContext objects getPCHtml() method and a static method in VendorPerformance servlet.
Code samples for the user interface elements:
<%= fc.getPCHtml("QualityTextLine",
VendorPerformance.createTextLineName("<NAME>")) %>
<%= fc.getPCHtml("QualityTextBlock",
VendorPerformance.createTextBlockName("<NAME>")) %>
<%= fc.getPCHtml("QualityFactorLong",
VendorPerformance.createQualityFactorLongName("<NAME>")) %>
<%= fc.getPCHtml("QualityFactorDouble",
VendorPerformance.createQualityFactorDoubleName("<NAME>")) %>
<%= fc.getPCHtml("QualityFactorString",
VendorPerformance.createQualityFactorStrName("<NAME>")) %>
<%= fc.getPCHtml("QualityMailList",
VendorPerformance.createMailActionName("<NAME>")) %>
Where <NAME> is a string that gets stored in QUALITY_ENTRY_DATA.NAME
Constructing the email List for an email Field in the JSP
The entities to whom emails are sent can be computed in the JSP itself giving you the flexibility of customizing the email recipients.
QualityMailList DOR entry:
"QualityMailList" NTV {
"extends" Str "Listbox",
"codecategory" Str "QualityMailList",
"rows" Int "1"
},
The following CodeCategory setting can be found in the $APPS/com/iplanet/buyer/config/srm/codes.ntv file:
"QualityMailList" NTV {
"0" Str "-none at this time-",
"1" Str "Send E-Mail to Manager",
"2" Str "Send E-Mail to group('s)",
"3" Str "Send E-Mail to individual('s)",
},
The DOR name (QualityMailList) happens to be the same as the CodeCategory name (QualityMailList). However, this need not be the case. The DOR name can be different from the CodeCategory name.
|
Note
|
You cannot add entries to the QualityMailList code category.
|
As a result of the above DOR entry and CodeCategory entry, the user will see a drop-down list containing the four choices listed in the CodeCategory entry. Now you have the task of creating an email address (or a list of email addresses) corresponding to each of the three email actions the user will be able to select. The following code snippet is code that you can change to suit your customization needs.
Example
SampleMultiPart.jsp
<%
// set up actual groups to mail,
String name = "Mail";
// note manager does not need a name list
// The Managers email address is computed automatically
// The manager of the organizational unit to which the current user
// belongs will be the one to receive an email.
// Add any UserGroup that you wish to receive email
// You may add/delete UserGroups
String[] groups = { "CatalogBrowsers","CatalogManagers"};
// Add the user ids of individual users
// You may add/delete users
String[] indivuduals = { "admin", "bugsbunny11"};
// NTV used to pass information to the Servlet
CXNTVList passDataList = new CXNTVList();
passDataList.setNTVList(VendorPerformance.createMailGroupListName(n
ame),
VendorPerformance.createMailList(groups));
passDataList.setNTVList(VendorPerformance.createMailIndividualListN
ame(name),
VendorPerformance.createMailList(indivuduals));
%>
<% // passData() can be called only once per Form %>
<%= fc.passData(passDataList) %>
|
Note
|
The code snippet above is code that you can change to suit your customization needs. The rest of the code should not be changed.
|
*Deploying the Template
To deploy your templates, copy them to the following directories:
$APPS/buyer/com/iplanet/buyer/templates/en/US/srm/vendorperf
$APPS/com/iplanet/buyer/templates/en/US/srm/vendorperf
Where:
$APPS refers to the APPS subdirectory under your iAS installation.
The en/US directory is the locale-specific subdirectory that contains templates for the en/US locale. If you support other locales, you can put the localized versions of these templates into the respective directories.
The srm/vendorperf directory is the recommended subdirectory where you should put the template, but you can choose a different subdirectory. You will need to know this sub-directory when you set the QUALITY_ENTRY_FORM policy.
*Setting the Templates Selection Rule
You can create and deploy as many templates as you want. However, this is not sufficient to ensure that the user will see the proper template while receiving items. To control which user sees which template, and under what conditions, you must set the QUALITY_ENTRY_FORM business rule, using the Import utility. Instructions for using the Import utility are contained in Chapter 8 "Importing Data."
Rule Synopsis
Name—QUALITY_ENTRY_FORM
Specify the name of the template along with the path relative to the locale sub-directory.
Roles—USER_CREATED_FOR, PRODUCT, SELLER_COMPANY
Value—srm/vendorperf/CustomizedTemplate.jsp
Specify the template you have created as the rule value.
*Configuring Mail Settings
You can configure mail settings by editing the srmInfo.ntv file, which is located in the following directory:
$APPS/com/iplanet/buyer/config/srm
This file has an NTV which looks like this:
"SRMMailSetting" NTV {
"smtphost" Str "<smtp_mailserver_hostname>",
"subject" Str "<subject line for email
notifications sent on Quality data updates>",
"cc" Str "<email addresses, seperated by commas,
to be copied on email notifications>",
}
*Javadoc for Seller Performance
Refer to the Class VendorPerformance Javadoc for details on the servlet.