4. OM Architecture Source Destination New Engine Internet, Workflow, Objects Tailorable Order Forms Shipment Planning Electronic Demand Mgmt Advanced Configurator Reservations Credit Card Payments Sales Order Workbench Industry- specific faces i Store Self Service Tracking Warehouse High Volume EDI/XML Adv. Pricing & Deals Global ATP/CTP Telesales Field Sales Service Carriers Credit Agencies
What was Order Entry is now Order Management. In a broader sense the Order Entry functionality has been eclipsed by and expanded to include two base modules: - Order Management - Shipping Execution And, two optional modules: -Configuration Management - Advanced Pricing
Not only the name has changed. The architecture has been completely overhauled to support the web facing applications and take advantage of the Internet features of the 8i RDBMS. There is a new graphic user interface, enriched with more intuitive features developed to support other applications that service casual rather than professional users. The functionality has been expanded to encompass designed-in rather than bolt-on facilities Existing functionality has been enhanced to provide effective depth to the efficiencies of business process. A new pricing engine has been added; designed to support internet marketing. The SellingPoint configuration engine has been integrated into Order Management providing the capacity to configure products ranging from simple units to full systems. A Self-Service Web Application, Order Management Portal replaces the Web Customers application and provides access to view existing sales orders and returns, shipping information and item availability.
At the core of the Order Management architecture is a new engine to process orders. Once again, the term Order Management refers to the four components listed on the opening slide: Order Management Shipping Execution Configuration Management Advanced Pricing The center boxes with the white letters are the components of the OM engine, providing uniform single source services for inbound orders so that pricing for a given customer is consistent and accurate regardless of the order source. To the left of the OM engine are the various order capture vehicles. The new order management graphic user interface, Sales Order Workbench, is now referred to as the Order Organizer. Customers or vertical teams can develop their own front ends (industry-specific faces) to bring orders into the OM schema. iStore, Telesales, Field Sales and Service, all components of the CRM suite, push their orders through that same OM engine. To the right of the OM engine are the entities outside the firewall that access the OM engine for inquiry purposes or transact data with it.
This provides another perspective of the interaction between CRM and the Order Management engine to provide seamless back-office/front-office integration. Orders entered via the CRM suite shown in this slide are pushed through the Order Management API’s and the OM engine deploys workflow to manage, process and pass those orders on to Accounts Receivable for invoicing.
Order Management is built on a new schema . This new schema is simplified from the R10.7/R11 model (shown on the left) and designed to take advantage of the functions and features of Oracle 8i, especially those that are Internet-focused. The number of tables within the data model have been reduced. For example, in R11i, sales order demand now resides in the sales order tables themselves, and reservations data resides in the Inventory Reservations tables. Picking transactions are modeled as inventory movements. This simplified data model makes it easier to create extensions, should the need arise. From an upgrade perspective considerable effort may need to be expended to retrofit previous release extensions to the new schema. On a positive side, retrofitting some of those old extensions may not be necessary, as they may be eclipsed by the new functionality which will be discussed later in this presentation.
Workflow underwrites most of the processing in Release 11i and it is important that both user and technical support personnel have a minimal working knowledge of it. The hands-on Workflow class that has been scheduled later this week is a must for anyone involved in solution design. As will be shown later, workflow is represented through a graphic user interface which may be captured for compliance documentation purposes. As well as the Workflow embedded in the standard Release 11i processes, the opportunity exists for customized Workflows, which may be used to eclipse old release extensions by a native solution. Order cycles have been replaced by Workflow. Workflow provides more flexibility for users to add new processes and rearrange the processes involved in fulfilling a sales order, to adapt to the changes in business. Processing constraints replace security rules which permit authorized personnel to define security constraints by responsibility and by workflow stage that an order has reached. For example, a Supervisor perhaps can cancel an order after Pick Release, but a CSR can only cancel until Pick Release. Defaulting rules and line level independence replace the Standard Value Rules Set. Data that used to be on the header is now pushed down to the line - data like salesperson, payment terms, shipping and packing instructions - so it can be different for each line. Currency and sold-to customer are still maintained only at the header - most other fields are maintained at the line. Each line has its own workflow, so each line can be processed independently Defaulting rules can deploy PL/SQL scripts. This will discussed in more depth later.
As previously mentioned, workflows replace the Order Cycles and enhance the functionality. There are workflows for order-level processing, and separate workflows for line-level processing. The result is that different lines of an order go through different processing flows, based on line type. Users can modify the processing flows in the seeded workflows, and create their own flows to match their unique order processes. The approval cycle step of Order Entry has been eclipsed by workflow. An approval workflow activity may be placed within the workflow associated with the order or the order line. In which case, the process waits until an approval is received from the individual who is sent the notification. Order Management does not use an approval hierarchy (like Purchasing). The recipient of the approval notification is setup when the approval activity is defined. Workflow allows the creation of Notifications that inform the selected party when a particular event occurs. The selected recipient may be part of the company, such as a sales manager, or not part of the company, such as a supplier sales representative. For example: the sales manager could be notified automatically whenever an order is booked with at value greater than $100,000 a supplier sales representative could be e-mailed when whenever an order is booked with a particular product on it. The Workflow Monitor graphically presents the flow of a transaction through it’s cycles. Completed steps are highlighted with a green shadow and, should there be a halt in the process, a red shadow will appear.
Similar to many top-flight off-the-shelf personal computer based applications, the user interface includes a tree on the left, and summary data on the right. Users can create queries and save them in the tree for reuse. For example, a user responsible for a particular customer’s orders could save a query that found all of that customer’s open orders. That query would always be on that user’s ‘tree’ so they could just click on it to execute that query. The ‘Order Organizer’ is the new name for the Orders Workbench. It incorporates the Find Orders window, the tree and the Order Summary (or query results form) that will display when the user performs a query or clicks on a query in the tree. Forms 6 Tabular concept is deployed to show multiple related windows of data - tabs replace the ‘alternative region’ concept of Forms 4.5, and make the choices available to a user more visible. Folders have been added to every form in Order Management, so that users can rearrange data on the screen, hide fields or rename prompts. In short, users can customize the form to fit the functions they perform. Forms 6 allows for use of Folders even on single-record forms like the Order Header.
The new Order Header screen is based on the popular folder form functionality that was introduced in previous releases. Users can now tailor this often used form to suit their own perspective of the order entry process. For example, they can, if they wish, eliminate one or all of the monetary based fields and choose not to replace them or rather replace them with more pertinent information from the “Others” tab. Addresses have been made visible on the order form, making it easier for a user to immediately confirm that the correct customer and ship-to has been chosen eliminating the earlier requirement for additional navigation. There is a second tab in the order header, containing the other Order Header information. Just a reminder, each user’s forms can be independent of those forms deployed by other users. So, any given user can pull fields that are peculiarly critical to his/her business processes from the second ‘Other’ tab and put them on the ‘Main’ tab, rearranging the look and feel of the form that is displayed here without affecting what is displayed to the rest of the user community. Most fields on the order forms are right-mouse click enabled - and there are a variety of Order Management functions available at that click. These are some of the same functions that are available on the ACTION button. So, by using the right mouse click, a user can invoke this functionality without a lot of additional mouse movement. To go to the Lines area of the order, the user will click on the Line Items tab near the top left.
The Order Lines form. The tab at the top indicates that the lines are being displayed rather than the header. There’s a set of subordinate tabs for the lines region – Pricing, Shipping, and so forth. As with the header form in the previous slide, the folder icon indicates this form is, like many others now in Release 11i, folder enabled. So, once again, users can customize the look and feel to accommodate their business requirements and processes by changing the order in which data is presented and displaying and hiding fields. Should an additional window pop up, it will do so in the lower right hand corner, so as not to intrude on the user’s entry process and so as not to obscure the information currently being processed. Note the Sales representative field on the line -this is an example of ‘line level independence’ which means that each line is independent of each other line - most data elements that used to be on the header level are now down on the line, where they can be different from line to line. Note also that there is a running Order Total displayed at the top right of the folder.
As shown previously, the Standard Value Rules of previous releases have been eclipsed by a new Defaulting Rules structure which offers considerably more flexibility. The Defaulting Rules are based on each attribute on the Order Header and the Order Line rather than the order type. The rules can be invoked based on conditions allowing the defaulting of more fields from more sources than before: Order Type can be defaulted onto an order; Defaulting rules can be used for Return orders and lines Descriptive Flexfields can be inserted; Formulas can be used to calculate a default. For example, the request date can be defaulted in as today’s date + 7,but if the order type is rush, the request date can be today + 1 A PL/SQL package can promote the information via an API where additional conditional logic is required.
As mentioned previously, security constraints added to control who can change or cancel orders or lines and at what stage of the line’s process, may be established at the responsibility level . All the OM order and line forms have the multi-select functionality similar to that in Windows Explorer where the use of ctrl-click or shift-click combinations highlights information in groups. Once the group is selected, the new mass maintenance capabilities provide “action to one, applies to all” functionality. For example, select a group of lines from an order and change the sales representative or the price list on all of them in one quick operation. Similarly, select a group of orders, and cancel them all at once. For traceability, especially in customer service, the user can optionally choose to keep a history of all quantity reductions, and view them using the sales order form. If the constraints are setup to allow it, users can modify and cancel lines, even after pick release. There is no separate form for cancellations – the user can invoke the cancel window from the Action button. The cancel window requests a reason code and an optional comment. If the cancel request is made at the header level, the user is given the option to cancel all remaining items on an order, even if part of the order has been shipped - it will cancel whatever has not shipped.
Over and under shipment tolerances for orders and for returns are allowed in Release 11i based of setup parameters. Globally, these can be established within the OM profile options or they can be setup at the following points either as a standalones (no global setting) or as overrides to the global setting: At the customer or site level using Customer forms; The item level using PDM (Inventory) Master Items form; And, for customer and item combinations, using a new OM form. At ship confirm: The shipping clerk can confirm a quantity greater than the quantity on the line (over-tolerance) if it is within the over-shipment tolerance. The actual quantity shipped is recorded on the line. There is a new shipping profile option that controls whether or not a shipper can overship above the tolerance, with a reason code, or not at all. The shipping clerk can confirm a quantity less than the quantity on the line - but if the quantity shipped is within the under-shipment tolerance, then the line is closed once the shipment is processed. If the quantity shipped is outside the tolerance, the line is split into 2 lines - the one line representing the quantity shipped and the other containing the difference. The benefit of setting an under-ship tolerance is to eliminate having to cancel the remainder where industry practice is not to ship fractions. For invoicing purposes: Overshipments are controlled by a new profile option called OM: Overshipment Invoice Basis - which controls whether to invoice for quantity shipped or quantity ordered. There is a corresponding new attribute on the Customer and site level, which can be used if a customer or site needs to be treated differently from the global option. Undershipments are always invoiced at quantity shipped.
Initially quantities up to 9 decimal places will be supported for standard items. Subsequent versions of Release 11i will extend that functionality to models and option below models. Using a new Item attribute, called OM Indivisible in the Master Items setup form, Physical Attributes tab, the user is able to indicate if an item cannot be ordered in decimal quantities in its Primary UOM. If a user orders in a UOM that is not the primary UOM, an Inventory API is called which determines whether the ordered quantity and UOM conform to the divisibility of the item’s primary UOM. For example, an item with a Primary UOM of EA and the ‘OM Indivisible Flag’ equal to ‘Y’: A user cannot order 1.5 each; A user can order 1.5 dozen - convertible to an integer of primary UOM - 18 EA’s; A user cannot order 1.6 dozen - not convertible to an integer of primary UOM – 19.2 EA’s. During the R11i upgrade this flag is defaulted to null, effectively saying that all items can be ordered in decimals. Upgrade scripts are available to give users an easy way to update this flag for groups of items. Reports and documents have been modified to print quantities in decimals. There is a new report parameter controlling the maximum number of quantity decimal digits that are printed on reports.
This is set up within the PDM (Product Definition Management) module (formerly Inventory forms) and used by Order Management. All cross references set up in the Customer Part Number Cross References in PDM can be used by Order Management: Customer Item Numbers; UPC numbers; EAN; ISBN; User determined; Orders may be entered through the Order User Interface by specifying any of these item identifiers. Orders imported from legacy systems or via EDI, can be specified using any of the item identifiers. In the Customer and site tables there is an optional field that allows the user to specify what kind of item identifiers a customer or site typically uses. This will default to the line, and then any item identifier entered on the order is first assumed to be that kind of part number. This eliminates the need to search each time. Both the ‘ordered item’ (which can be a generic identifier, a customer part number, or the internal part number) and the actual internal item id that it relates to are retained on the order line. The ‘ordered item’ is printed on the Sales Order Acknowledgment, passed to Receivables for invoicing, and can be printed on internal reports.
Drop shipment refers to the business process where the requirement flow does not follow the normal supply chain of inventory minimum to purchase order to vendor inventory to NCR inventory to customer order to customer inventory. Instead, the requirement flow is customer order to purchase order to vendor inventory to customer inventory. Vendor drop shipment functionality was introduced in Release 11. In R11, because of the separate data models of OE and PO, it was necessary for users to maintain the customer address in two places - the AR tables and the HR tables. In Order Management, there is now a single point of maintenance of the customer addresses/PO locations. There is no longer a need for dual address maintenance. In addition, OM’s Workflow streamlines the process of loading order information into the Purchasing requisition import tables, eliminating the need to run the Purchase Release concurrent program.
There is new functionality in the area of scheduling and reservations. Sourcing rules are defined in Oracle Advanced Supply Chain Planning to determine from which warehouse an order should ship. A new workflow activity is available to source lines that have not been sourced at entry. The user can specify through a new attribute whether the request date required by a specific customer represents a ship date or an arrival date. Then, as orders are entered into the system, Oracle Order Management and Oracle Planning work together to determine the time in transit to calculate the ship date given the arrival date, or the arrival date given the ship date. Oracle Order Management now has a new feature called Auto-scheduling, which lets the user check ATP or display availability automatically as soon as a line is entered. From the availability window, the user can press a button to go to APS’s Global ATP window to view availability across the global supply chain. Order Management users can set up the system to reserve the inventory at entry, if the request date is within a user-specified window of time. If the request date is further into the future, an automatic workflow process will perform the reservation as soon as the requested ship date moves within the allocation window.
With Release 11i, changes were made to the Global Tax Engine to support various complex taxing requirements that arose in the area of international shipping. Vendor Drop Shipments made the tax situation even more complicated, as it introduced a third entity, the supplier, into the equation. The tax engine now allows users to define Tax Groups where users can specify rules to determine which tax codes should apply. Tax can be based on data entities such as ship-to, ship-from, FOB, etc. For Order Management, the change is transparent - the Tax Engine is passed additional parameters and the appropriate tax is automatically calculated using the Tax Groups. Bottom line, the tax on orders will be correct, even in the most complex and esoteric cross-border shipping situations.
Order Management supports credit card payment and authorization through integration with Oracle’s iPayment server much as iStore does. iPayment interfaces with the credit card clearing authority via third party software such as PaylinX or Cybercash. In R11i, Order Management supports payment via one credit card at the header level. If an order type is set up with a ‘validate payment’ rule at Booking or Shipping (formerly called ‘credit check rule’) and the payment type is credit card, then the system will attempt to obtain authorization of the full amount of the order through iPayment. Authorization code is stored on the order header. If authorization is denied, or an unacceptably high risk factor is returned, the order will be placed on hold. A user can key in a different credit card number, or change to a different payment type to clear the hold. Credit card and authorization information can be masked from visibility to users based on the value of a new user-level profile option. The actual capture of funds from the credit card is done in the Receivables module, once the order is ship confirmed and interfaced to Receivables.
Carrier integration is not available in the current version of Release 11i. This is emerging functionality which will integrate Oracle Application with the various first tier carriers. The anticipated capabilities are self evident from the test Portal display.
In 11i’s release 2 the carrier integration functionality will be introduced with UPS. DHL and Federal Express integration is expected to follow soon after. Integrating with UPS Online shipping technology provides quick access to information about UPS shipments. Customers and customer service representatives will have the ability to rate, track and validate service information about shipments through the Order Management and Shipment Execution forms.
Holds and Releases are an integral part of the order process, be they driven by credit restrictions or customer requirements. Holds can be applied and released from the Sales Order form. Separate forms are available to create ‘hold sources’ that can be used to define criteria to place orders on hold automatically if they qualify for that hold. Hold sources can now be defined using two entities, instead of just one, for example: a customer and item combination; an item/warehouse combination; a customer site/warehouse combination; providing more flexibility in setting up these automatic holds. When an order or line is released from hold, the user is required to enter a reason code, and may also enter comments. As in R11, the history of holds for an order or line can be viewed - and this history includes when the hold was placed, and when it was released, by whom, and also the reason and comments.
The order copy function was a recognized problem in 10.7 character. That issue has been resolved and additional functionality provided. First, there is no longer a separate Copy Order form - all copying can now be done directly from the Sales Order form or the Order Organizer. In Release 11, the user was capable of copying one entire order to a new order. That functionality has been extended, the user can: copy only selected lines from an order to a new order; copy multiple orders into one order; choose lines from across multiple orders; append lines to an existing order. The user initiates a copy by selecting the order, orders or lines that need to be copied, then chooses COPY from the ACTION list. A small window will pop up that offers various copy options. The user can choose what order type the new order will be and assign the order number if that order type has manual numbering (another new feature!). For pricing of the new order, the user chooses whether to keep the prices from the ‘copied from’ lines, or to re-price at today’s prices.
There are no separate forms for returns - they’re entered using the Sales Order form. That allows the user to enter order lines and return lines on the same order - to support such processes as trade-ins or exchanges. This functionality can be specific to certain order types by choosing a category of Regular, Return or Mixed at the time the order type is set up. Returns receipts are no longer an order entry concern. RMA’s are received in Purchasing using the receiving forms in Purchasing. The obvious benefit is that receiving clerks are not forced to flip back and forth to receive against PO’s and RMA’s. Also, the need to set up an order entry function in what should be an already limited function menu is eliminated. When entering Return lines for lot controlled or serial numbered product, the user can record the lot(s) and serial number(s) expected. This data is not validated against Inventory, to support returns of product shipped from a legacy system. During receiving, the receiver will have visibility to expected lots and serial numbers, but will record what is actually received. There is a discrepancy report to identify the differences between what was expected and what was actually returned. Customers can be notified of the receipt of their return through a return acknowledgement which functions in a similar fashion to the order acknowledgement. Obviously, the facility also exists for acknowledgement of orders which contain both returns and orders.
Order Management has expanded capabilities in the area of Line Set processing. In addition to Ship Sets, which were available in previous releases of Order Entry, Order Management now also supports Arrival Sets and Fulfillment Sets. Ship Sets are defined as a group of order lines that the user would like to ship together. Attributes that have to be identical across all lines in a ship set are shipping warehouse, ship date, and freight carrier. Arrival Sets are defined as a group of order lines that the user would like to arrive together, although they do not have to ship from the same warehouse. Attributes that have to be identical across all lines in an arrival set are ship-to location and requested arrival date. Fulfillment Sets are defined as a group of order lines that get fulfilled together. Items that are not shippable can be in fulfillment sets with shippable items, and then will not be fulfilled (and therefore invoiced) until the shippable items are fulfilled. Users can assign user names to sets, in order to improve communications with the customer. Set functions are accessible thru the right mouse menu. The partial shipment flag has been replaced by two new Customer and site attributes: automatically place order lines into ship sets; automatically place order lines into into arrival sets. The need for a group attributes window in order entry has been eliminated; the user can change attributes common to sets by just changing them in the Sales Order form. If a set is released for picking but, when the lines involved are picked, one of the set is missing, the shipping clerk has the option to break the set at ship confirm and release for shipment whatever is available.
Notes may be manually created during the entry of an order: Select the paper clip icon in the toolbar Select the note category and data type Enter a note or link to notes and attachments required. As well as text, attachments can be a web page, image and document and can be affixed at either the header or line level. For Certificates of Conformance, etc., notes can be deployed automatically based on rules. Notes can be attached to both orders and returns.
Internal orders are now treated almost just like other orders: most of the restrictions that used to be enforced against internal orders have been eliminated; users can maintain an internal order line, based on security constraints established in setup; changes can be restricted, once again based on preset constraints; internal order lines are identifiable by a unique line type. There is a callback function between OM and PO so that changes in quantity that are made in OM get communicated back to PO. One important consideration peculiar to internal order lines. Regardless of whether there is an invoicing step in the order’s workflow or not, they will not be invoiced.
In anticipation of the emerging functionality in carrier integration, enhancements have been made in the area of Freight and Special Charges. The Order Management User Interface now supports entry and display of multiple charges at the header and at the line. Charges can also be introduced through Order Import. Qualifying rules that would cause a charge to get automatically applied to an order or line can be established. Charges are different from Costs, which are entered during Ship Confirm. All Costs are entered at shipping, and there is a way to indicate that a cost should be automatically converted to a charge. All charges are invoiced. There are simple calculation methods available for charges, and an API can be called to accommodate more sophisticated charge calculations.
The transfer of information between Order Management and Accounts Receivable has been expanded providing more detail for the invoice printing process: a new Order Management profile option identifies whether discount details are to be passed to AR. If the user chooses to send details, OM will send the line item to AR at list price, then send an additional line for each individual discount applied to that line. Order Management now passes detailed Freight and Special Charges information to Receivables, as well. Although the data is passed in detail all tests currently indicate that the information is summarized as one line on the invoice. The expanded functionality of printing details of charges is expected to be launched in an upcoming release. If an item has been ordered using a customer item number or a generic item identifier, and the item identifier has a description different from the internal item description, OM will pass the ordered item description to AR for printing on the invoice. Invoicing is now a workflow activity which can be placed at the Order Header level to interface an entire order to AR at the same time, or at the line level to interface each shipment line when it is shipped. The Receivable Interface concurrent program no longer exists.
In Release 11, the shipping function was expanded to accommodate the functionality as shown under column labeled Current Release. In release 11i that strategic direction has been expanded to the capabilities identified on the right which provide for outbound planning. A Trip is carrier-specific such as UPS. It contains deliveries and departs from a particular location and must make at least 2 stops. These stops can be for picking up or dropping off deliveries. A Stop is a point along the route that a trip makes to it’s final destination. This point may have some activity associated with it such as picking up a delivery, dropping off a delivery or both. A Delivery is defined as a rules-based consolidation of sales order lines by attributes. It is based on user-defined criteria: Mandatory grouping of criteria consists of: Customer Ship-from location Ultimate ship-to location Optional grouping criteria include: Carrier Freight Terms FOB Intermediate ship-to location Freight terms Ship method Currency Items can now be packed into containers and the containers can be assigned to deliveries along with their associated freight costs.
Transaction Form dramatically decreases navigation complexities by assembling shipping information and providing the visibility required for efficient and effective decision making. The shipping or traffic department can control outbound shipments and take advantage of consolidation opportunities by using the Trip feature to coordinate shipment activity within the transportation network. The Stops feature allow the traffic department to manage what is to be picked up and dropped of by an internal fleet or hired transportation carrier. Container Management functionality improves the efficiency in filling containers. The user can automatically: elect to pack multiple containers with multiple lines based on percentage or physical container constraints, create a container without assigning it to a delivery, assign lines to the container, specify a License Plate Number (LPN) to the container, Pick Release the lines within the container.
Order Import has new Error Correction capability. Orders and lines that did not import due to errors, can be reviewed along with detailed error messages indicating the problem. The user can correct those errors using the same forms and then re-import the data. Order Import now also supports the importing of returns as well as orders. Some enhancements have been made to Order Import in direct response to requests by the EDI trading community. If Order Import detects differences in the system calculated price and the user-provided price , Order Import will return an appropriate warning or error message. Similarly, if there is a difference in the system generated payment terms and the user-provided payment terms, Order Import will return a warning message to the user. Oracle Order Management now supports the processing of the inbound Order Change (860/ ORDCHG) transaction for automated changing of order shipment quantities, dates and location information. Order Management also supports the creation of the outbound Purchase Order Acknowledgment (855/ORDRSP) transaction, and the outbound Purchase Order Change Acknowledgment (865/ORDRSP) transaction for those customers whose trading partners require such ability. Finally, all the OM transactions are fully XML-enabled.
Oracle Advanced Pricing provides the functionality to handle pricing situations where a combination of pricing attributes determines the price, for example, distance, age of a related product, customer class, product family group, and level of service. When orders are entered, the pricing engine evaluates the combinations of attributes specified during pricing setup to arrive at the correct price. Oracle Advanced Pricing provides the capability of defining pricing qualifiers that, once set up, can be used to inform the Oracle Advanced Pricing Engine of the necessary information about when it is appropriate to use a price list or a price modifier. A qualifier can be used to qualify multiple price lists and modifiers. The user can set up, copy, query, and delete pricing qualifiers through specific forms provided in Oracle Advanced Pricing. Any attribute of the customer or item master can be used as a dimension or qualifier in pricing. Flexfields may be used to store user-defined pricing attributes. The user can define flattened hierarchical structures to which customers and items belong, and use membership in them as a pricing qualifier. Oracle Advanced Pricing provides the capability to define multiple customer and item hierarchies. Price lists contain the basic information that associates price and currency with an item, service, group of products or services, or sub-component. Each price list combination contains one or more item lines. In a price list, the user can define the price of an item or service to be any one of the following: An absolute list price. A generated price in a price list formula. A percentage based on the price of (derived from) a different line appearing on the order. Users can specify when price lists are to be used by the pricing engine by linking them with pricing qualifiers. Oracle Advanced Pricing gives you a consistent manner for defining qualifiers for price lists, price formulas, and price modifiers. An item may be on multiple price lists and a priority setting technique can be established to break ties in pricing. Price lists may be loaded from external sources via an API which must be called from within a user provided program. Using price lists, the user can: Define price breaks based on attributes such as product unit quantity, volume, weight, or value ordered by your customer. Define a price at a higher level in the product hierarchy. Designate price lists as either for use with customer sales orders or internal sales orders. Define rounding factors for pricing. Define pricing units of measure and pricing conversions based on units of measure. Enter a currency code for a price list. Price list formulas provide the ability to create a price as the result of a computation. This provides an alternative means for setting prices other than entering a price in a price list. As with price lists, the use of a price list formula may be tied to qualifiers. These formulas can be deployed to: Calculate the price of a product. Determine the price of a product or service derived by combining pricing components. Compute a price in a price list that is dependent on the price in another list. As orders are processed, Oracle Advanced Pricing first locates or computes a price for an order line using a price list, or alternatively a price list formula. Once this price has been computed, the pricing modifiers can be used to provide discounts, free goods, or other benefits and/or to compute charges. When price modifiers are defined, the user specifies one or more pricing benefits or charges that the customer should receive. Oracle Advanced Pricing allows the user to define several different types of pricing benefits, including: Discounts Free goods or other item discounts Item upgrades Accrual of benefit, but without payment mechanism Special payment terms Special freight terms Lump sum payments Coupon issue Use of promotional price lists
Basic pricing, part of core Order Management, is sufficient for many business purposes and includes the above capabilities which were reviewed previously.
Oracle Advanced Pricing supports a broad complement of deals and promotions used in consumer goods sales. These include: off invoice promotional discounts, deferred accrued discounts that may be either monetary or in the form of points, cross order discounts, free goods, item upgrades, special freight, prompt payment promotions. Deals and promotions can be set up to be either asked for or automatically applied, depending on the business needs. Controls required for effective administration of deals and promotions are provided. Eligibility requirements can be tied to: effectivity date, first and last order date, first and last shipment, The user is provided flexibility in defining the calculation basis for deals, with available methods including: dollars per unit, percentage of unit value, dollars per total order, percent of total order, lump sum.
This and the following two slides provide examples of modifiers. They are self explanatory.
Oracle Order Management integrates with the Oracle Configurator to provide configuration functions for both Pick-to-Order and Assemble-to-Order models. Oracle Configurator is based on the SellingPoint configuration engine. The SellingPoint engine provides next-generation, state-of-the-art configuration for all types of products - from simple units to full systems or assemblies, including engineer-to-order products. Oracle Configurator supports configuration rules written against model structures provided by Oracle Bill of Materials. A default user interface is automatically derived from the configuration model using a predefined layout template. Oracle Configurator also provides the ability to create custom user interfaces to meet the unique needs of any end user or selling channel. Product specialists can quickly and easily build intuitive user interfaces using simple drag-and-drop techniques, eliminating the need for technical programming skills. To reinforce brand identity, corporate branding elements such as logos, colors and typefaces can be included. Oracle Configurator provides prices for models, option classes and options during the configuration session. Available to Promise (ATP) checks can be performed to provide an estimate on the product availability date based on material and resource constraints. Product selection guides the user through a series of features and options that meet his/her stated requirements. All options are color coded to show which are currently valid and which are invalid. As selections are made, the configurator progressively validates the integrity of each choice. If an invalid selection is made, it is either rejected outright or the user is provided with the ability to accept the selection, potentially overriding previous options or redefining the constraints set through the guided selling process. Oracle Configurator's interactive configuration engine provides real-time feedback about each selection's impact in the form of prompts and warning messages that guide the buyer to a solution that meets their requirements. Oracle Configurator's guided selling and product selection screens are automatically generated from the configuration model and lead the user through the entire progression of selections to arrive at a complete and valid configuration. To maximize ease of use, the feature and option selection information is initially presented as a tree view. This allows the customer to understand the big picture before proceeding to make detailed inter-dependent selections. As the tree is expanded, additional nodes are exposed representing the levels of detail. Each node of the tree has a corresponding screen that provides the feature and option selection interface
The Order Management Portal is a Self-Service Web Application designed to replace the old Web Customers product. It will allow a user to view existing sales orders and returns using just a standard web browser. One will be able to query by criteria such as a purchase order number, project number, and sales representatives. The user will also be able to view shipping information through a tracking number. A user can also view item availability from the portal. The portal will also allow the user to view AR information such as credit memo, invoice, debit memo or payment history. The target customer for the portal is initially an external customer who needs to view existing information about their order or account. The secondary target customer is an internal customer who needs to view or transact using the OM portal e.g sales representative.
![Order Management ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)