1) Test script for Exception Management Enhancement:
Check for the activities in sales order workflow which have errored out or create workflow errors in 2 to 3 sales orders and then run the concurrent program Retry Activities in Error . It enables you to retry activities which have errored out in workflow. These activities can be retried in batch and you need to write an item type (Lines, Closed orders, Order header Lines) as one of the parameters.
2) Test Script for Mass Scheduling:
Check for the sales order lineswhich have failed workflow scheduling and manual scheduling, Lines which are manually entered and are in Entered status, Lines which are imported in to Order Management in Entered status. Run the Schedule Ordersconcurrent program. After that check whether it schedules above lines and check whether this program sort scheduled orders.
3) Test Script for Scheduling ATO items without BOM (Bills of Material):
For performing scheduling actionson them, earlier the ATO items required an attached Bills of Materialsin either Ship from Organization or in Master Organization. Now, set profile option, OM: Schedule ATO Item Without BOM =Yes and then check Scheduling of ATO items in Order lines. It should allow you to schedule lines without BOM attached with ATO items.
4) Test script for Multi-Organization Access Control:
Check/test:
a)Whether from one OM responsibility you can enter transactions in multiple/other operating units of OM module (It is assumed that rules are set up in those individual operating units).
b)Several different users can share the same OM responsibility and a single user can have multiple responsibilities.
c)Whether a new profile option MO: Security Profile has been set .If yes,then check if it controls access for one responsibility to one, all or multiple Operating Units.
d)Also check whether you have assigned a default operating unit by entering an operating unit name in the profile option MO: Default Operating Unitand the same operating unit acts as a Default operating unit for that OM responsibility.
5) Test script for Partial Period Revenue Recognition:
Check/test:
a)You must use service type items only for this test script.
b)Check in AR module about 2 new accounting rule types – the daily revenue rate for all periods and the daily revenue rate for partial periods.
c)Define revenue recognition rules from these 2 new rule types.
d)These new rules calculates the revenue at a daily rate and for partial periods accurately thus enabling Revenue Managers to handle the strict standards for Revenue Recognition.
d)Create 2 sales order by using these 2 new accounting rules (using new rule types) and check the accuracy of calculated revenue.
e)Within Order Information Portal (OIP)check whether you can view the name and address of the End Customer, as captured at the time of processing the order, at both at the header and line levels. Order Information is a web-enabled, self-service Oracle application that allows you to view detailed sales order and delivery information online. It also provides a variety of web inquiries, order processing flows, and workflows. The standard order inquiry flows enable you to go through web pages to access order related information.
6) Test Script for Improved Order Management, Install Base, and Service Contracts module Integration:
Check/test:
a)A Warranty contract is created when a Serviceable product is shipped to the customer. A Warranty contract is also created when serviceable product with bill of material contains a warranty clause. Whenever possible, where multiple products are sold on one sales order, one warranty is created for all the products. Each different warranty item on a sales order creates a separate warranty line on the Warranty contract.
b) Service Contracts module has an API which pulls information from the Install Base for newly created customer records and creates an ownership record.
c)An Extended Warranty contract is created when an Extended Warranty is sold on a sales order. Extended Warranty contracts can also be consolidated.
d) Order Management interfaces to Service Contracts via the Fulfillment workflow activity (Fulfill Line). This activity populates the Service Contracts interface table. You need to run the Service Contracts Order Processing concurrent program to process the interface records .It created Extended Warranty contract
e) When a serviceable item is returned for credit, whether the customer is credited for the extended warranty depends on the setting of a particular OKS profile option.
f) Create sales order in OM and create an Extended Warranty contract as above .Also return the serviceable item to service provider and see/check whether credit is created for that.
7) Test script for Payment Due with Order (Pay Now Pay Later):
Check/test:
a) When selling services and equipment to customers, the customer may be required to pay for a portion of the total order amount as a deposit when the order is placed, based on the business logic specified by the service provider. You may create a sales order for equipment or service items with 10% advance amount, freight and shipping charges, installation charges and other charges.
b) The Pay Now Total can include any of the following amounts in the iStore cart, quotation, or sales order:? Equipment Charges, freight & shipping charges, and taxes. ? One-Time Charges such as Activation Fees, Installation Fees, or Change Fees. ? Deposits taken due to poor credit or other reasons. ? The first installment of an installment payment for equipment. ? Prepayment charges for the first month’s service. Check whether the Pay Now Total shows amount as expected in cart, Quotation or sales order.
8) Test Script for Credit Card Encryption:
Check the credit card fields in the sales orders window whether they are encrypted during entry. If you have specified any masking format, the actual credit card field value does not appear. This credit card information is stored in a central Payments repository and is accessible to all other calling applications like Order Management, iStore etc.
9) Test Script for Credit Card Security Code:
The Credit Card Security Code is a 4 digit code printed on the back of the credit card and it is used by merchants/dealers to verify that the buyer actually has the card with him/her when performing remote buy/sell transactions such as transacting over the Internet. The sales orders window contains a field for the security code and this code, will appear in that field. This code like the credit card number is also verified by the Oracle Payments central repository. Check this field and security code when you create a sales order against credit card payment.
10) Test Script for Sales Contracts Workbench:
Check
a)Whether a Sales Contracts Workbench in an HTML page has been provided,
b)Does it enable you to organize and keep track of your r sales contracts,
c)Are simple and advanced search capabilities enabling you to view contracts?
d)Are you able to display contracts according to criteria you specify?
e) Are you able to do actions like adding clauses, export etc on contracts in the Workbench?
f) Are you able to open a quote or a sales orders window from the Workbench too?
g) Are the Notifications about contracts are placed in a Notifications Bins and are able to personalize these too?
11) Test script for Customer Acceptance:
In order fulfillment flows of previous version 11i, the goods were shipped to the customer and were then invoiced and interfaced to AR module, but now in 12i the flow includes an additional step of customer acceptance. Here, the customer accepts the goods received either before or after billing takes place. The revenue recognition process is deferred and is linked to customers’ accepting the shipped goods during post-billing acceptance. In pre-billing acceptance, the customer accepts the goods first and then invoicing takes place. For both pre-billing and post-billing customer acceptances, you can accept the goods explicitly or implicitly. You should not confuse with Quotation customer acceptance with this customer acceptance.
Check/test:
a)Check whether OM System parameter ‘Enable fulfillment Acceptance’ under’ Generic Category Parameters ‘ is set=Yes.
b)Check whether function security for the given responsibility for the following two functions has been enabled
1. Sales Orders: Fulfillment Acceptance – This ensures that the action attribute Fulfillment Acceptance is available in the Actions LOV.
2. Sales Orders: Update Acceptance Attributes – This allows for updating the acceptance attributes of Acceptance Name and Acceptance Expire days. These are attached to the sales order menu – ONT_ Sales_Order
c)Check Whether Customer Acceptance i.e. appropriate Deferral reason for pre-billing (removal event as Invoicing) and Post-billing Acceptances (reason removal event as Customer Acceptance) is set up in AR’s Revenue Management module. At order entry, Order Management defaults the customer acceptance deferral reason and its attributes from Receivables onto the sales order line.(Others Tab-folder enabled functionality ) .The deferral reason defined in AR’s Revenue Management setup page is actually used as Acceptance Name in Order Management.
d)Create sales orders that need to be accepted by the customer and this acceptance is to be recorded by the Customer Sales Representative. View/update Acceptance fields on the order line- others tab. These are folder enabled Acceptance fields. Sales Order Acknowledgment Report prints Acceptance Required. (Check this). Ship Confirm the items – view the line status ‘Pending Pre-Billing / Pending Post-Billing Acceptance’. Perform Acceptance/Rejection.–Explicit Acceptance is done through Order Information Portal (click on Sales Order Actions – Fulfillment Acceptance) from Header or Lines OR through Order Import. Implicit Acceptance is done by defining Deferral reason in AR with event attribute as Ship Confirm date and expiration days. Run an Implicit Acceptance Request set that records Implicit Acceptance .It consists of the concurrent programs:
1)Generate Pre-billing Acceptance Program for Pre-billing, Implicit Acceptance
2) Revenue Contingency Analyzer for Post-billing, Implicit Acceptance
e) Customer Acceptance: If an order line is to be explicitly accepted (Pre-Billing or Post-Billing), OIP displays an Accept/Reject LOV and a Status field to perform an acceptance/rejection of the line. Additionally an Acceptance Details page has been added to OIP to record the acceptance details like Acceptance Date and Signature.
f)The customer can accept the goods in any or in combination of the following ways:? Pre-Billing Acceptance (goods are accepted before Invoicing) – Implicit or Explicit? Post-Billing Acceptance (goods are accepted after Invoicing) – Implicit or Explicit in Pre-Billing Customer Acceptance, once the goods are accepted, invoicing is carried out. In Post-Billing Acceptance, the revenue recognition process is deferred and linked to customers accepting the shipped goods. Only full acceptance is recorded; partial acceptance is not recorded. Post-billing acceptance is not supported for lines with deferred accounting rules,
G)Check/View Acceptance Details in Sales Orders line.
h)You may repeat this procedure for
12) Test script for Recurring Charges:
a) A recurring charge is a fixed charge that will be repetitively applied to an account on a periodic basis. Recurring charges are most commonly associated with subscription services such as Internet Service Provision, Bank Account Fees, and Credit Card fees. Charge periodicity is the interval by which the price for a recurring charge has been set up on a price list (e.g. Monthly, Quarterly, Yearly).
b)Charges are classified into 3 types: One-time, Recurring, and Usage for service items. O.M. module now provides the Recurring Charges functionality in release 12 to order and price products with recurring and one-time charges. This functionality is limited to TSO Ordering. (Telecommunications Service Ordering).
c)The MACD (Move Add Change Disconnect) feature of Order Management has been enhanced with the addition of the Recurring Charges functionality, and is now referred to as TSO (Telecommunications Service Ordering).
d) Charge Periodicity column displays the charge periodicity for recurring charges. The column is enabled only when the system parameter Enable Recurring Charges is set to Yes. It can be made visible on the page by using personalization. You need to heck this.
e)Check whether the Profile option OM: UOM Class for Charge Periodicity is set. It determines what domain will be used to hold the allowable charge periodicities. The domain is a UOM class in Inventory. Inventory has seeded a UOM class called ‘Period’ that will hold UOMs: Daily, Weekly, Monthly, And Quarterly and so on. The profile option is seeded with the value ‘Period’. Inventory has further seeded a value set INV_CHARGE_PERIODICITY that will hold UOMs: Weekly, Monthly, Quarterly, Yearly and so on.
f)Check whether System Parameter ‘Enable Recurring Charges ‘ is set to yes.
g)Check whether Defaulting rule for retrieving the correct charge periodicity has been defined for the item in Item Master. If MACD is not installed, you require installing it first and then setup the Recurring
h)Check whether price for recurring charge has been set up on a price list .Create a TSO sales order for a service item and check whether recurring charges of all the 3 types are applied
13) Test script for Creating Orders in Contact Center:
a)The Contact Center is the central window where TSO (Telecommunication Service Orders) orders entered and updated,
b)MACD ( Move, add, change, disconnect) activities are carried out in this window for facilitating the customer support representatives (CSR) to enter and maintain service items ordes.You need to check whether you are able to carry out these activities in this window.
c)Check whether the profile option OM: Contact Center Actions Menu Name has been set. The default value will be the value of the Order Management seeded menu ‘ONT_CONTACT_CENTER_SUB_MNU’ Agent actions are defined as functions. Depending on the functions that have been mapped to menus, the corresponding associated agent actions are available from the Line Items sub-tab page. This profile option holds the name of that menu.
d)You may check whether the credit card information can be viewed in the Contact Center window (in the Orders tab),
e)You may also check whether the security code field is also displayed in the in the Payment windows invoked from Order Information Sub-tab and Line Items sub-tab under Orders tab of Contact Center window
14) Test Script for Telecommunication Service Orders with Equipment:
a) Some of the applications that the Telecommunications with Service Orders (TSO) functionality spans across are Oracle Order Management, Oracle Configurator, and Install Base. You can do Order entry, configuration of items/services, and item/service tracking (Using Install Base).Please check these points once by one. By creating a sales order entry, by configuring a sales order by using oracle configurator and by creating a service order for say warranty item and then customer cancelling the same
b)The enhanced TSO with Equipment functionality enables you to order telecommunications products and services from a single window and also perform the service related activities like Move, Add, Change or Disconnect a service..You may check this by creating one sales order for handsets along with services (like call forwarding) by using iStore and also from OM.
15) Test Script for Vertex Tax Engine and Related Enhancements:
a) Order Management supports the third-party tax vendor Vertex .A new tax engine called Vertex Engine has been incorporated into the AR/OM Tax application to assist the calculation of taxes for the sales orders. All previous tax calculations and tax-related activities which were done in OM are now done in Release 12 in the Tax application run by the Vertex Engine.
b) Ensure that in the AR Transaction Type window (Receivables > Setup > Transaction Types), the Tax Calculation check box is checked, otherwise tax calculation will not occur in the order lines,
c) Verify that the Setup > Tax menu options have been changed to include the Location window,
d) Please make sure that your Receivables transaction type, invoice source and non delivery invoice source in the line type refer to the same legal entity as the order type. This is because E-Business Tax allows legal entity-related tax setup and Order Management requires that all lines in the same order belong to the same legal entity.
e) Also the Receivables tax setup submenu included in Order Management setup menu has changed to not allow setup of tax Codes, Authorities, Sales Tax Rates, Exceptions, Exemptions, Tax Groups, General Ledger Tax Assignments and Tax Reporting Ledger. You need to check and verify these.
f) New and changed/modified tax-related fields have been incorporated in the sales orders window and the Order Information Portal to enable you to interface with the Vertex tax engine. Check whether the OM fields such as Order Header: The fields Tax Exempt Number, Tax Handling and Exempt Reason remain the same. Also check whether Order Line: The field Tax Code in the Order Line has been renamed to Tax Classification Code. Verify that the field Tax Group is no longer used.
g)Some changes to Order Management include profile options change. Check whether you can enter values in the Exemption related fields, when the profile option EBTAX: Allow Override of Customer Exemptions is set to Yes,
h)Check whether you can enter values in the Tax Classification Code field, when the profile option EBTAX: Allow Override of Tax Classification Code is set to Yes,
I)When you click Actions > View Tax Details, the Tax Details window should display the following fields: Tax Regime, Tax, Tax Status, Tax Rate Code, Rate, and Amount. The Order Information Portal should also shows similar tax-related fields in the Additional Details page.
j)Check in the OM Transaction Types window, Finance tab, whether a Receivables Transaction Type and a Tax Event for tax calculation have been specified. Tax calculation should take place depending on the tax event set by you (Entered, Booked, Invoiced), specified in the Order Transaction Type window.
k)Create a sales order and use Actions > Calculate Tax to ensure that the correct tax calculation is carried out by Vertex Engine. Update information in the sales order line, the tax engine is called again and the tax is recalculated. Make sure this. Also if you change the tax classification code, the tax should be recalculated.
16) Test script for a new menu option-View Sales Order is on the Purchase or Release Shipment windows:
Create a drop ship sales order and then run the purchase release program to create requisition and then import requisition in to PO module.
a)A buyer can invoke this option to view Sales Order information such as customer or shipping details, if the Purchase Order Shipment references a requisition line associated with a Drop Ship Sales Order line.-Check this
b)Following new status details have been created for order tracking:1)PO Req Requested,2)PO Req Created,3)PO Created,4)PO Received. These requisition or purchase order statuses are available on the Drop Ship tab of the Additional Line Information window.-Check these statuses.
c)The buyer cannot change the following data elements on purchase requisitions that are linked to a Drop Ship Sales Order:-Check these.
1) Inventory Item
2) Ship To Location (Deliver to in PO)
3)UOM
4) Quantity
5) Need By Date
6)Warehouse (Ship To Org)
7)Project and Task Information.
d)Drop Ship Purchase Requisitions cannot be returned to the requestor. Splitting the purchase requisition is also not allowed for the buyer. Purchase requisitions linked to a sales order cannot be canceled or finally closed. You need to check all these 3 points.
17) Test script for Oracle Process manufacturing users:
a)You can access fields like dual quantities, grade, unit of measure in the sales orders line and the Order Organizer windows. The fields are folder enabled in both windows.-You need to check these.
b)If the item in the organization, in which it’s being transacted, is tracked in Primary and Secondary or if the pricing source for the item is secondary, then the Secondary Quantity field is enabled and required. The secondary UOM field is defaulted from the item’s secondary inventory UOM and is a view-only field. You may check these by creating one sales order for OPM items
c) The Grade field has been added to the sales order line to enable you to specify a preferred quality grade for a grade controlled item. You can enter grade for any item that comes from a discrete or a process inventory organization. You can enter grade in the sales order line, and is displayed in the delivery line, however you cannot update it in shipping. –Define a grade controlled item in Inventory module and assign it to both discrete and OPM organizations. Check whether you can enter grade in sales order line and it is displayed in delivery lines. Try to update it in shipping.
d) Defaulting rules enable the value of the grade field to be defaulted on the order line. -Create one defaulting rule for grade and see if it defaults on order line
e)The Grade field has now been extended to 150 characters. Check this by defining grade of more than 150 characters.
f)When performing ATP check for Oracle Process Manufacturing items, a Process Manufacturing warehouse must be selected within the Ship From field for an order line. ATP for Process Manufacturing items can be specifically performed for a grade-controlled item if a grade is selected; in this case, on hand available quantity is shown for the grade of the item. You may check this in one of the sales order for OPM grade controlled item.
g) If Oracle Process Manufacturing is installed and a process item is ordered, then the Additional Information icon is enabled. Select this icon to access additional process order information. In the Additional Information page, you can see Secondary Quantity, Secondary Unit of Measure and Grade information. You need to check these.
18) Test script for checking profile options:
The following profile options have become obsolete in release 12.All the functionalities which were provided by these profile options in 11i is now controlled by Oracle payment modules. Please check these and confirm that the statement holds true.
a) Om; Estimated Authorization Validity period.
b) OM: Number of Days to Backdate Bank Account Creation,
c) OM: Payment Method for Credit Card Transactions. Control is now available at the Payment Type level in the Define Payment Types window.
d) OM: Process Payment Immediately at Booking. Control is now available at the Payment Type level in the Define Payment Types window.
e) OM: Risk Factor Threshold for Electronic Payments Further, check the profile options given below which have been converted to Oracle Order Management system parameters with the same names without prefixes. The only difference is for the profile OM: Employee for Self-Service Orders is replaced by the system parameter called Requestor for Drop Ship Orders created by external user. It is necessary to check these changes.
a) OM: Credit Memo Transaction Type
B)OM: Credit Salesperson for Freight on Sales
c) OM: Employee for Self-Service Orders
d) OM: GSA Discount Violation Action
e) OM: Invoice Source
f) OM: Invoice Transaction Type
g) OM: Non-Delivery Invoice Source
h) OM: Overshipment Invoice Basis
I) OM: Reservation Time Fence
j) OM: Schedule Line on Hold
k) OM: Show Discount Details on Invoice
L)Tax: Inventory Item for Freight
M)Tax: Invoice Freight as Revenue.
19) Test script for Defaulting Rules:
In 11i , seeded defaulting rules defaulted the Order Type and Salesrep from the Customer. These defaulting rules have been deleted in release 12.. The sources Customer. Order type and Customer. Salesrep are also disabled, so all custom defaulting rules that used these source are deleted You can still default the Order Type and Salesrep values from other sources, such as the Customer Ship-to and Customer Bill-to. You need to check these statements.
20) Test script for Pre-Payments:
In 11i release, OM stored credit card information locally. In this release 12, the integration with Oracle Payments provides a centralized data model within Oracle Payments for credit card and bank account information and services to process payments. Vital and sensitive data such as credit card numbers, credit card security codes (CVV2), and bank accounts are encrypted and stored within this centralized model. Of Oracle Payments. You need to check this.
21) Test script for shipping reports:
In this release 12, printing of reports in Shipping is not limited to text output but PDF format is now also available on various Shipping reports through the use of report templates created in Oracle XML Publisher. The names of shipping reports available for PDF output are given below. a) Pick Slip) Packing Slip) Mailing Labeled) Bill of Lading) Master Bill of Lading) Commercial Invoicing) Vehicle Load .Sheet Summary. You need to check and verify these. Also, many new attributes have been added to the XML output of the Pick Slip, Packing Slip, and Commercial Invoice reports which includes: a) Secondary Quantity) Secondary UOM, c) Lot number, d) Grade, FOB terms and Freight terms have been added to the Bill of Lading and the Master Bill of Lading reports. Please verify all these statements and facts by taking out reports. This new information does not appear on the report’s seeded layout but it is part of the XML data structure available to build the templates within XML publisher. Verify this also.
22) Test script for Workflow-enabled Shipping Transactions:
In release 12, the Shipping Transactions form and Quick Ship window allow you to view Workflow-enabled shipping transactions. These transactions automate business processes by routing information according to user-defined business rules. You can use them to automate specific tasks and customize output based on attributes of business objects. If you any such requirements then you can test it.
23) Test Script for Parallel Pick Submission:
In release 12, Pick Release runs pick release processes in parallel which distributes the workload across multiple processors thus reducing the overall time required for a single pick release run. You can also specify the number of child processes spawned by Pick Release which depends on each individual pick release batch, and on the profile setting of the new seeded profile option WSH: Number of Pick Release Child Processes .It is used to determine the default number of child processes. However, it does not have a default value so the Pick Selection program considers this as “1.” Change this profile to the number of child processes that you want to run in parallel, depending on the hardware efficiency and other application constraints. Inventory module locks the organization/item combination and hence multiple parallel pick release processes do not process the same item in the same organization at the same time. Y you need to test and verify these facts by running pick release process and setting the above profile.
24) Test script for Quote menu option:
You may verify the following and create 2 quotes by using both options-Quote and Quick Quote.
a) A new menu option for quotes is given under the main menu Negotiation, and the windows are preconfigured to display quote attributes for the Order Management Super User.
b)Quote Number, version, Quote Name, Expiration Date, and Quote Date are displayed by default when the window is opened using the Negotiation menu option.
c)Transaction Phase, User Defined Status, and Comments fields are hidden and can be displayed using folders functionality. These fields are available in both the Main and others tab. The Negotiation menu has two windows – the Quote and the Quick Quote. You can create a quote from either of these two options. The transaction phase always defaults to Negotiation, independent of the defaulting rules when the window is opened through the Quote menu option.
d)Quotes also can be entered (11i functionality)using the existing Quick Sales Orders window or the standard Sale Orders window by displaying quote-specific attributes using folder functionality. All the quote specific attributes are hidden by default when the window is opened using this menu option. A folder can be saved in the Quick Sales Order window or the standard Sales Orders window with quote related attributes and the folder can be used for entering quotes through either of these two sales orders windows. The transaction phase will default either to Negotiation or Fulfillment based on Order Management defaulting rules when the Quick Sales Orders or standard Sales Orders window is opened.
25) Test Script for Catch Weights in Discrete Inventory:
a) Catch weight support in Order Management is available for inventory organizations that are enabled for Process Manufacturing. Currently when the process inventory organization is involved catch weights are supported, and the inventory processing is done by the converged inventory model
b) The functionality allows any discrete inventory item that is catch weight enabled being shipped from a WMS inventory organization, to also capture the secondary quantity and second UOM at time of shipping. The following are some differences for discrete inventory catch weight support compared to process item catch weight support • The Order Qty2 on the sales order line will be blank (currently for process inventory organizations it is calculated). • Only after the material has been picked for shipping will the Ship Qty2 be populated. This actual quantity will be used to determine the extended price and then it will be prorated back to determine the unit price per Qty1. • The Pricing UOM will be used to determine which quantity should be used for pricing the catch weight items.
c) You can specify a secondary quantity and secondary UOM at shipping and have that information fed back to the sales order line then re price and invoice the order based on that quantity. This is used for consumer goods where actual weight varies compared to its standard weight.
d) Once the secondary quantity and UOM is captured, the sales order line price is prorated based upon the ship quantity. Volume discounts are always calculated on the estimated qty2; but the actual price is based on the ship quantity.
e) To provide support for catch weights, you must define the item as being catch weight enabled in Inventory module. The WMS enabled flag on the inventor organization =Yes will determine the processing within Order Management and Oracle Shipping.
f) Once the item is properly defined, you can enter orders for the catch weight items in OM. When the actual material is picked from inventory, the secondary quantity and UOM2 are populated with the true weight/actual weight for WMS enabled inventory organizations.
g) When catch weight items are defined /created, a pricing unit of measure is defined. The pricing unit of measure can be defined as either the primary or the secondary unit of measure for the item. Price lists are then created for that item in its pricing unit of measure. All pricing calculations for catch weight items are done with respect to the pricing unit of measure defined for that item.
h) Define 2 items as above and make sure that you get results as mentioned above.
Recent Comments