10 The PSR Order Entry API

Bypass PSR API Switch Validation for TN assignment

This system level preference is a check box that can be deselected (N) or selected (Y):

• N: The PSR API switch validation is performed for a TN Assignment.

• Y: The PSR API switch validation is not performed for a TN Assignment.

Bypass Selected PSR API Import Structure Validation

This system level preference is a check box that can be deselected (N) or selected (Y):

• N: The software does not bypass any PSR API import structure validation.

• Y: Selected PSR API validation is not as strict. This functionality currently exists only for values and label validations. When a structure fails validation, it is not processed by the APIs and the incorrect information is not entered into the MetaSolv Solution database. However, the PSR is still saved in the system. The PSR is subject to validation at the time of completion.

Note: You must be using the PSR Order Entry API for this preference to affect MetaSolv's software.

Override Default Value on PSR API Import When Label Exists on Import Structure

This system level preference is a check box that can be deselected (N) or selected (Y):

• N: You must populate the default values and an activity code for delete.

• Y: The importNGNPSR and importPSR_v3 methods overwrite the default values before making the API call when the PSROrderItemValue2 structure is populated.

You do not have to populate the value structure with the default value and an activity code for delete. You can populate it with the preferred value and an activity code of New.

Note: You must be using the PSR Order Entry API for this preference to affect MetaSolv's software.

Use Copy Item When Importing PSR Order

This system level preference is a check box that can be deselected (N) or selected (Y):

• N: When an item is copied during the import of a PSR order, the item, as well as all child items, are copied.

• Y: When an item is copied during the import of a PSR order, only the item itself is copied.

Using Metasolv Solution Inventory as the Primary Inventory for Telephone Numbers

This system level preference is a check box that can be deselected (N) or selected (Y):

• N: You can create a WTN while you are creating a service request.

• Y: You can assign the working telephone number (WTN) from the telephone number inventory to a service request, but you cannot create a WTN during service request entry.

Sample Unsolicited Process Flow for Importing a Customer

The overall process flow for importing a customer is as follows:

1. The third-party application binds to the MetaSolv Solution Application Server to get a WDIRoot object reference.

2. The third-party application invokes the startPSRSession operation of the WDIManager interface to get a PSRSession object reference.

3. The third-party application invokes the connect operation of the WDIRoot interface, which yields a WDIManager object reference.

4. The third-party application invokes the startTransaction operation of the WDIRoot interface to get a WDITransaction object reference.

5. The third-party application instantiates a WDINotification object.

6. The third-party application invokes the importNewCustomer operation on the PSRSession interface, providing WDITransaction, WDINotification, and PSRCustomerAccount objects.

7. The MetaSolv Solution Application Server processes the invoked PSRSession operation and invokes the appropriate callback operation on the input WDINotification. In this example, the operations are PSRCustomerExportSucceeded or PSRExportFailed for exporting, and PSRImportSucceeded or PSRImportFailed for imports.

8. If the PSRImportSucceeded operation is invoked, the third-party application invokes the commit operation of the WDITransaction interface. If the PSRExportFailed operation is invoked, a WDIError sequence describing the error is returned to the third-party application. The third-party application then performs the appropriate error handling routine. In the case of an import failing, the third-party application should rollback the transaction.

9. The third-party application invokes the destroyPSRSession operation of the WDIManager interface.

10. The third-party application invokes the destroyTransaction operation on the WDIManager interface.

11. The third-party application invokes the disconnect operation of the WDIRoot interface.

Item Types

Think of item types as the MetaSolv Solution rules. These are items and relationships that MetaSolv Solution has predefined for products and services. Examples include line products, which can have attributes such as lines, system options, and features. These attributes allow the MetaSolv Solution code to determine what kind of service a product is and ensure certain data is collected and specific processing occurs. For example, circuits are built (in the background) for dial tone lines so they can be designed later.

Product Specifications

Product specifications are engineering rules defined by technical staff in conjunction with product management. These specifications are supported by engineers and network designers for specific implementations. Using the item type examples above (line products, with attributes of lines, system options, and features), a customer could create a product specification for dial tone (POTS) service as a line product with lines that have a system option of Hunt Groups. Each line may have several features such as call waiting, call forwarding, caller identification, three way conferencing, and so on. These specifications are building blocks that have pre-defined relationships designed so that a product catalog can be built using these building blocks. People creating the product catalog need not be worried about the provisioning/designing aspects of a product.

More About Product Specifications

Figure 10-2 describes the basic process flow for setting up product specifications.

Figure 10-2 Standard Item Setup

Description of ''Figure 10-2 Standard Item Setup''

Figure 10-1 shows the standard item setup data model.

Figure 10-3 Standard Item Setup Data Model

Description of ''Figure 10-3 Standard Item Setup Data Model''

The item type and item relationship type entities are preloaded with MetaSolv Solution. These two entities define the common characteristics that are handled in the application. An item type and its characteristics are pre-defined. Characteristics might include an item category (such as product, option, line, trunk, etc.), whether the item type must have a premise, and the item type's processing path. (The processing path defines the processing that must take place for an item type.)

Table 10-6 describes the item types's processing path.

For instance, a type of item might be ”line product,” which would be characterized as a product. Another type might be ”line”, which would be characterized as a physical item (meaning a circuit will be created for design purposes) with a premise. The relationship between these two item types would be defined in the item type relationship table with line product being the superior item and line being the subordinate item.

When users define the product specifications, they delineate the actual items that can be sold. For instance, a product specification of basic business line might be set up with a type of line product. Some rules of use are defined here. For example, if you want a disconnect reason to be entered when this item is disconnected, you could set that here. Line types are another product specification that can be set up with a basic business line. The rules that can be defined for this item include the disconnect reason must be entered, and when the item is ordered the question ”how many do you want?” must be asked.

Table 10-7 lists the characteristics that you must define if you use the Arbor/BP billing system or flow through provisioning with PSR.

Next the standard item relationship must be defined. If basic business is set up as the highest item in the hierarchy (a product), it would be defined in this table with basic business having no superior item. Basic business line would be set up as a subordinate to basic business. Valid values may also be specified during the product specification setup process. If you have an item that requires one or more values to be collected, a name (label) is setup for each value collected and a list or range of valid values defined. A default value may also be defined. An example illustrating this feature might be an item called Start Type. A product specification of Start Type would have a label of ”Type” and a value list of ”ground” or ”loop.”

More About Product Catalogs

Figure 10-4 describes the basic process flow for setting up product catalogs (things to sell). All references to specifications in this flow refer to product catalogs. References to items refer to product specifications.

Figure 10-4 Specification Setup

Description of ''Figure 10-4 Specification Setup''

Figure 10-1 shows the item specification data model.

Figure 10-5 Item Specification Data Model

Description of ''Figure 10-5 Item Specification Data Model''

When creating a product catalog for a product, choose the product you want to set up from a list of standard items. The relationship (product specifications) of these items must have no superior items, for example, basic business. Once you have chosen the level one item, the next level of items may be selected from a list of standard items whose relationship has basic business as the superior item. In our example, basic business lines may be selected. This process sets up the product catalog relationship. For level one items there is other information that needs to be collected such as type of service, offering type (wholesale, resell, and retail), taxing information, and tariff information. A product catalog name may be entered. Other information may be specified about any item including information describing the availability of the item (by Network Area), the from and to effective dates, and whether or not it is required or standard. Pricing information may also be entered at this time (see the pricing area of this document for specifics).