Order Management Overview Order Management provides you with the tools to manage your sales orders and control your operations. Order management applications can streamline and automate a business’s entire sales order management process, from order promising and order capture to transportation and shipment. Order management also includes EDI, XML, telesales and web storefronts. Some of the business benefits that can be achieved include reduced fulfillment costs, reduced order fulfillment cycle time, increased order accuracy and greater on-time delivery. Order Management Data Model
Transcript
Order Management Overview Order Management provides you with the tools to manage your sales orders and control your operations. Order management applications can streamline and automate a business’s entire sales order management process, from order promising and order capture to transportation and shipment. Order management also includes EDI, XML, telesales and web storefronts. Some of the business benefits that can be achieved include reduced fulfillment costs, reduced order fulfillment cycle time, increased order accuracy and greater on-time delivery.
Order Management Data Model
Order Management Summary Database Diagram
Order Management Tables
Order Headers
OE_ORDER_HEADERS_ALL:- Order Headers are stored in OE_ORDER_HEADERS_ALL.
1) Order Management uses workflow to track status.
2) Some core statuses are de-normalized onto the Header entity - OPEN_FLAG, BOOKED_FLAG.
3) The FLOW_STATUS columns store the Header Flow Summary Status, and its value changes as
the Header progresses in its flow.
4) The API OE_HEADER_STATUS_PUB provides information about various functional statuses and
when a header workflow activity was completed.
5) Order Entry used SVRID columns to manage defaulting attribute values and cascading attribute
value changes.
6) Order Management uses the PL/SQL based Defaulting Framework to provide initial default
values.
7) It does not retain an audit trail of how an attribute was defaulted.
The following table describes OE_ORDER_HEADERS_ALL in alphabetical order. Apart from the columns
specified here the OE_ORDER_HEADERS_ALL table also has the regular Descriptive Flex, Global
Descriptive, Trading Partner Descriptive Flex and Standard Who Columns
Column Description Used by
ACCOUNTING_RULE_ID Foreign Key to RA_RULES Invoicing
AGREEMENT_ID Agreement Pricing Contracts
BOOKED_DATE Date when Order was Booked Booking
BOOKED_FLAG Indicates whether order is booked Booking
CANCELLED_FLAG Indicates whether entire order is canceled Cancellations
CHANGE_SEQUENCE Controls sequence in which updates are done EDI Integration
CHECK_NUMBER Number of Check used to make payment on Order
Invoicing
CONVERSION_RATE Rate of currency conversion. General
CONVERSION_RATE_DATE Date for the rate used for currency conversion.
General
CONVERSION_TYPE_CODE Type of conversion used for currency conversion
CREDIT_CARD_HOLDER_NAME Credit Card Holder’s name I-Payment Integration
CREDIT_CARD_NUMBER Credit Card Number I-Payment Integration
CREDIT_CARD_EXPIRATION_DATE Credit Card Expiration Date I-Payment Integration
CUST_PO_NUMBER PO Number in the customer system which the customer specifies when placing order
Pricing Contracts
CUSTOMER_PREFERENCE_SET_CODE Determines default set: Arrival or Ship Scheduling
DELIVER_TO_CONTACT_ID Contact person for the organization that the product is finally delivered to.
DELIVER_TO_ORG_ID Organization / individual that would be the end consumer of the goods. Also deliver confirmations may be done using the deliver_to. Defaults to the order line.
General
DEMAND_CLASS_CODE Demand Class Planning
EARLIEST_SCHEDULE_LIMIT Inner limit of Schedule Date Window
EXPIRATION_DATE Future Use Future Use
FIRST_ACK_CODE Acknowledgment Code that is sent to the EDI trading partner when the order is acknowledged the first time
EDI Integration
FIRST_ACK_DATE The first day the order was acknowledged EDI Integration
FLOW_STATUS_CODE Order Header flow status summary General
FOB_POINT_CODE Point of ownership transfer General
FREIGHT_CARRIER_CODE Shipping Integration
FREIGHT_TERMS_CODE Freight Term Code, could be Absorb, buyer Pays, Cost to Charge, Fixed Charge
Shipping Integration
HEADER_ID Unique identifier for an order - system generated id
Process Order
INVOICE_TO_CONTACT_ID Contact person for the organization that will foot the bill
INVOICE_TO_ORG_ID Organization that should be invoiced for the order / who would pay for the order.
Invoicing Integration
Defaults to the order line.
INVOICING_RULE_ID Foreign Key to RA_RULES Invoicing Integration
LAST_ACK_CODE Acknowledgment Code that is sent to the EDI trading partner when the order was last acknowledged
EDI Integration
LAST_ACK_DATE Last Date the order was acknowledged EDI Integration
LATEST_SCHEDULE_LIMIT Outer limit of Schedule Date window Scheduling
LOCK_CONTROL Internal Use Process Order
OPEN_FLAG Indicates whether order is open General
ORDER_CATEGORY_CODE Category of Order (ORDER, RETURN or MIXED). Defaults from Order Type.
General
ORDER_DATE_TYPE_CODE Indicates whether Customer is ordering based on ship date or arrival date.
Scheduling
ORDER_NUMBER User displayed order number. Order Numbering
ORDER_SOURCE_ID Foreign key to oe_order_sources. This field will be used by OI to point to the order source e.g. EDI, Service etc.
Order Import
ORDER_TYPE_ID Foreign key to OE_Transaction_Types. General
ORDERED_DATE Date on which order was placed. General
ORG_ID Organization that is taking the order. (same assold_from_org_id).
General
sold_from_org_id).
ORIG_SYS_DOCUMENT_REF Used by Order Import - this field will contain the document number from the legacy or external Order Entry system.
PARTIAL_SHIPMENTS_ALL Flag to indicate whether partial quantities may be shipped for lines belonging to the order (when set to ‘Y’) or whether it should follow the all or none rule. (When set to ‘N’).
Shipping Integration
PAYMENT_AMOUNT Advance payment made by Customer Invoicing Integration
PAYMENT_TERM_ID Foreign Key to RA_TERMS Invoicing Integration
PAYMENT_TYPE_CODE Indicates type of Payment Invoicing Integration
PRICE_LIST_ID Foreign key to oe_price_lists. Indicates which price list should be used for the order.
Pricing
PRICING_DATE Date on which order was priced. Pricing
REQUEST_DATE Request Shipping / Arrival date communicated by the customer.
Defaulting Source
RETURN_REASON_CODE Defaulting source for Return Reason on the Line.
RMA
SALES_CHANNEL_CODE Sales Channel that was the source for this Order.
Reporting
SALESREP_ID Foreign key to RA_SALESREP Sales Credits,Tax Integration
SHIP_TO_CONTACT_ID Contact person for the organization that the products have been shipped to.
Defaulting Source
SHIP_TO_ORG_ID Organization to which the order items were sent and would take ownership of the product. Defaults to order lines.
Defaulting Source
SHIP_TOLERANCE_ABOVE Upper tolerance level for line quantities (expressed as percent of the originally ordered quantity). When quantities are shipped within this tolerance level, this won’t be considered as over shipment.
Defaulting Source
SHIP_TOLERANCE_BELOW Lower tolerance level for line quantities (expressed as percent of the originally ordered quantity). When quantities are shipped within this tolerance level, this won't be considered as under shipment.
TAX_POINT_CODE A point in the Order processing cycle at which tax payable by the customer is recorded and fixed in your financial system
Tax Integration
TRANSACTIONAL_CURR_CODE Currency code to be used for order transactions.
General
UPGRADED_FLAG Flag to indicate whether this record was upgraded from OE
Upgrade
Order Lines
1. OE_ORDER_LINES_ALL:- OE_ORDER_LINES_ALL stores information for all order lines in Oracle Order Management. Order Management schema is simplified compared to the Order Entry model. There are fewer tables, although each table is wider to offer enhanced functionality.
1) Shipments, Options, Included Items Lines and Configuration Item Lines are all stored in
OE_ORDER_LINES_ALL.
2) Every line is a shipment and is identified via a line number and a shipment number. The user
visible line number ties together all shipments belonging to a Line. To split a shipment further,
you can use the Split Lines window. The LINE_SET_ID internally ties together shipments from an
original line.
3) In Order Entry only a single attribute on SO_LINES_ALL stored the numbering. Depending on
the kind of line, it stood for the line number, the shipment number, the option number or the
service line number.
4) Now these are all de-normalized on to the line entity, you have separate columns for all of
these. Additionally component number helps track included items under a given Line.
5) The Category code on the line indicates whether it is an inbound (‘RETURN’) or an outbound
(‘ORDER’) one. It defaults from the Line Transaction Type.
6) Every line that is a part of the configuration will have the TOP_MODEL_LINE_ID pointing to the
top Model. The Model line will have the TOP_MODEL_LINE_ID value set to itself. The
LINK_TO_LINE_ID points to immediate parent for a line in a configuration. ITEM_TYPE_CODE
identifies an item to be a STANDARD, MODEL, CLASS, OPTION or INCLUDED ITEM. For a
subassembly (an ATO model within a PTO), the options, classes and included items under the
subassembly will have it’s ATO_LINE_ID column to point to its ATO Model line.
7) Order Entry used S and S Date columns to store Order Cycle Status. Order Management uses
workflow to track status. Some core statuses are de-normalized onto the Line - Open/ Closed,
Booked, Fulfilled. Some other columns can be used to derive specific status information e.g.: A
not null Shipped_quantity indicates that an outbound line is past shipping. The FLOW_STATUS
column stores the Line Flow Summary Status, and its value changes as the Line progresses in its
flow. The API OE_LINE_STATUS_PUB provides information about various functional statuses
and when a line activity was completed.
8) Order Entry used SVRID columns to manage defaulting attribute values and cascading attribute
changes. Order Management uses the PL/ SQL based Defaulting Framework to provide default
values for records and it does not retain an audit trail of how an attribute was defaulted.
9) The following table describes OE_ORDER_LINES_ALL in alphabetical order. Columns that are
new in this release are in BOLD. The table also has the regular Descriptive Flex, Global
Descriptive, Industry Attribute Flex, Trading Partner Flex and Standard Who Columns
2. MTL_ONHAND_QUANTITIES:- MTL_ONHAND_QUANTITIES is maintained as a stack of receipt records, which are consumed by issue transactions in FIFO order. The quantity on hand of an item at any particular control level and location can be found by summing TRANSACTION_QUANTITY for all records that match the criteria. Note that any transactions which are committed to the table MTL_MATERIAL_TRANSACTIONS_TEMP are considered to be played out as far as quantity on hand is concerned in Inventory transaction forms. All Inquiry forms and ABC compile are only based on MTL_ONHAND_QUANTITIES. MTL_ONHAND_QUANTITIES stores quantity on hand information by control level and location.
MTL_ONHAND_QUANTITIES has two columns, CREATE_TRANSACTION_ID and
UPDATE_TRANSACTION_IDs to join to MTL_MATERIAL_TRANSACTIONS.TRANSACTION_ID the
transactions that created the row and the transaction that last updated a row.
Order Price Adjustments & Line Price Adjustments
1. OE_PRICE_ADJUSTMENTS:- This table is used to store price adjustments that have been
applied to an order or a line. The column automatic flag indicates if the adjustment was applied
automatically or manually. Manual discounts are created with applied_Flag = Y. This entity stores Order and Line price adjustments information. It stores the benefits offered at header,
line or group of lines. Benefits can be discounts on other items, item upgrade, terms substitution,
coupons, discounts, surcharges etc. This table has a lot more columns than SO_PRICE_ADJUSTMENTS to
support the capabilities offered by Advanced Pricing. The entity also stores information for tax, freight
and special charges. The following table describes OE_PRICE_ADJUSTMENTS in alphabetical order.
Columns that are new in this release are in BOLD. The table also has the regular Descriptive Flex and the
Standard Who Columns.
Order Sales Credits
1. Line Sales Credits OE_SALES_CREDITS:- The Order Management Sales Credit entity is identical to its Order Entry counterpart. Order and Line Sales Credits are stored in oe_sales_credits. The following table describes OE_SALES_CREDITS in alphabetical order. The table also has the regular Descriptive Flex and the Standard Who Columns
2. PRICING ATTRIBUTES
OE_ORDER_PRICE_ATTRIBS:-With Order Management, Order and Line pricing attributes are stored in a different entity. The Order and Line Pricing Attributes Descriptive Flex Definitions are based
off this table. You now have 100 pricing attribute columns. With Advanced Pricing you can use multiple descriptive flex contexts for a given Order Line. With Basic pricing, when entering an Order you can select only one Context (excluding the Item and Volume Contexts which have special meaning).The following table describes OE_ORDER_PRICE_ATTRIBS in alphabetical order. The table also has the regular Descriptive Flex and the Standard Who Columns.
3. ADJUSTMENT ATTRIBUTES OE_PRICE_ADJ_ATTRIBS:- This is a new entity in Order Management. It stores the information on the qualifiers and pricing attributes a price adjustment line qualified for. The following table describes OE_PRICE_ADJ_ATTRIBS in alphabetical order. The table also has the regular Descriptive Flex and the Standard Who Columns.
4. ADJUSTMENT ASSOCIATIONS OE_PRICE_ADJ_ASSOCS:- This is a new entity in Order Management. It stores the association information between Order lines and price adjustments. One price adjustment might be result of benefit on another order line or a group of order lines might be responsible for a benefit. The following table describes OE_PRICE_ADJ_ASSOCS in alphabetical order. The table also has the regular Descriptive Flex and the Standard Who Columns
5. LOT AND SERIAL NUMBERS
OE_LOT_SERIAL_NUMBERS:-This is a new entity in Order Management. It stores lot and serial number information for return lines. Order Management lets you create returns using the original serial number as a reference. If you create a return using the original. Order or Invoice as a reference and the item being returned was under serial number control, the application automatically pulls up serial number information from Oracle Inventory.
The following table describes OE_LOT_SERIAL_NUMBERS in alphabetical order. The table also has the regular Descriptive Flex and the Standard Who Columns.
Attaching Documents
FND_ATTACHED_DOCUMENTS:- FND_ATTACHED_DOCUMENTS stores information relating a document to an application entity. For example, a record may link a document to a sales order or an item. Each row contains foreign keys to FND_DOCUMENTS and FND_DOCUMENT_ENTITIES. There is also a flag to indicate whether or not an attachment
was created automatically. Some important columns are:-
Demand
VISIBLE_DEMAND_FLAG IN OE_ORDER_LINES_ALL:-In Order Management Application (Release 11i), Demand Interface is no longer available. Order lines will serve as demand in Order Management Applications. Every line which has the VISIBLE_DEMAND_FLAG = 'Y', will be made available as demanded to planning. Every line which is scheduled will be visible to planning as demanded. So there is no Demand Interface Program, to put the order lines in the demand tables. The table MTL_DEMAND is obsolete. Demand is a process which makes an order line visible to MRP for planning purposes. From Release 11i, Scheduling is an engine owned by MRP.OE_ORDER_LINES will have a flag called VISIBLE_DEMAND_FLAG. If set to 'Yes', the MRP can see the line, if it is set to 'No' the line will just be ignored when performing Planning. When a line is scheduled it becomes visible to MRP, if the VISIBLE_DEMAND_FLAG is set to 'Yes'.
Once the Order is saved, data goes to MTL_SALES_ORDERS table: MTL_SALES_ORDERS exists for the purpose of mapping sales orders between other applications and Inventory. MTL_SALES_ORDERS is a key flexfield table with no structure defining column or set defining column. The flexfield code for this table is MKTS. Only one structure for the flexfield may be defined for any installation of Inventory. Inventory demand interface and demand manager will validate sales orders on segment values, and will create a new SALES_ORDER_ID when necessary.
MTL_SALES_ORDERS SALES_ORDER_ID NOT NULL NUMBER SEGMENT1 VARCHAR2 (40) => ORDER_NUMBER
This table stores reservation information. Each record is a reservation that ties an item/organization combination with a demand source and a supply source. Demand source information comprises demand source type (Sales Order, Account, Account Alias, Inventory), demand source header, demand source line and demand source name. Supply source information comprises supply source type (Inventory, WIP jobs), supply source header, supply source line, supply source name and inventory controls (revision, lot, subinventory, locator).
Shipping
1. Pick Release 1) WSH_PICKING_BATCHES:-After batch is created for pick release. mtl_reservations This is only soft reservations. No physical movement of stock. The information filled in the Pick Release form is inserted in this table. System creates one batch for the condition you specify in Pick Release Form. BATCH_ID CUSTOMER_ID HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID ORDER_HEADER_ID
After Pick Release records goes to WSH_DELIVERY_DETAILS for each line, which is picked or backordered. If Autocreate Deliveries is set to set ‘YES’ then record also goes to WHS_NEW_DELIVERIES and WSH_DELIVERY_ASSIGNMENTSbut Pick Release is only Reserving the Items against particular Sales Order Line.
2) WSH_DELIVERY_DETAILS:- The table is populated as soon as the order is booked. In reality it
is populated when the shipping interface runs which happens when the order is booked. On the table
oe_order_lines_all there is a column shipping_interface_flag. If it is set to 'Y' then the order line has a
record in wsh_delivery_details. Most of the data in the table is missing until pick release is run. At pick
release the delivey_detail is associated to a move_order_line and header in mtl_txn_request_headers
and lines if auto allocate was selected at pick release. Also if the user opted to automatically create the
delivery the delivery_details records would then be associated to a delivery in wsh_new_deliveries.The
association between delivery_details and deliveries found in the wsh_delivery_assignments table.
Remember that in the shipping transation form the user can un-assign and re-assign delivery_details to
different deliveries. The wsh_delivery_details table is the center piece for getting shipping information.
It always exists for each shippable order line and serves as the link to move order inforamtion, delivery
and pick slip information.
1) oe_order_headers_all (flow_status_code as booked ,booked_flag updated)
2) oe_order_lines_all (flow_status_code as awaiting shipping, booked_flag updated)
3) wsh_new_deliveries (status_code OP open)
4) wsh_delivery_details (released_status ‘R’ ready to release)
Same time, Demand interface program runs in background And insert into inventory tables
mtl_demand.
2. Reservations MTL_RESERVATIONS:- This table stores reservation information. Each record is a reservation that
ties and item/organization combination with a demand source and a supply source. Demand source
information comprises demand source type (Sales Order, Account, Account Alias, Inventory), demand
source header, demand source line and demand source name. Supply source information comprises
supply source type (Inventory, WIP jobs), supply source header, supply source line, supply source name
and inventory controls (revision, lot, subinventory, locator). Some important columns are:-
3. Create Deliveries After Auto creating the Delivery, records goes to WSH_NEW_DELIVERIES and WSH_DELIVERY_ASSIGNMENTS. If Autocreate Deliveries is set to set ‘YES’ then record goes to both the tables after Pick Release.
1) WSH_NEW_DELIVERIES:- Stores the Delivery Information.
2) WSH_DELIVERY_ASSIGNMENTS:- Assigns delivery details to a delivery and/or a parent
delivery detail (LPN). Some important columns are:-
4. Ship Confirm After Ship Confirm, Deliveries gets Closed i.e. STATUS_CODE in WSH_NEW_DELIVERIES changes to ‘CL’ and CONFIRMED_BY field gets updated with Apps User Name. RELEASE_STATUS in WSH_DELIVERY_DETAILS changes to ‘C’. SHIPPED_QUANTITY in WSH_DELIVERY_DETAILS and SHIPPED_QUANTITY in OL_ORDER_LINES_ALL get updated with quantity shipped.
Trips:- 1) WSH_TRIPS:- WSH_TRIPS has trip records. Some important columns are:-
2) WSH_TRIP_STOPS:- WSH_TRIP_STOPS has trip stop records. Some important columns are:-
3) WSH_DELIVERY_LEGS:- WSH_DELIVERY_LEGS maps deliveries to their pick up and drop off
stops. 1 leg is called as 1 trip.1 Pickup & drop up stop for each trip. Some important columns are:-
4. Rules 1) WSH_PICKING_RULES:- WSH_PICKING_RULES has picking rules for defaulting Pick Release
options. Some important columns are:-
2) WSH_PICK_GROUPING_RULES:- WSH_PICK_GROUPING_RULES has grouping rules for Pick Release. Some important columns are:
-
3) WSH_PICK_SEQUENCE_RULES:- WSH_PICK_SEQUENCE_RULES has sequence rules for Pick Release. Some important columns are:-
Inventory Interface
Inventory Interface puts the Deliveries, which are Closed and Ship Confirmed in MTL_MATERIAL_TRANSACTIONS_TEMP. Records are processed from this table into Inventory through the transaction processor.
MTL_MATERIAL_TRANSACTIONS:- MTL_MATERIAL_TRANSACTIONS stores a record of every material transaction or cost update performed in Inventory. Records are inserted into this table either through the transaction processor or by the standard cost update program. The columns TRANSACTION_TYPE_ID, TRANSACTION_ACTION_ID, TRANSACTION_SOURCE_TYPE_ID, TRANSACTION_SOURCE_ID and TRANSACTION_SOURCE_NAME describe what the transaction is and against what entity it was performed. All accounting journal entries for a given transaction are stored in MTL_TRANSACTION_ACCOUNTS, joined by the column TRANSACTION_ID.
If the item is under lot control then the lot records are stored in MTL_TRANSACTION_LOT_NUMBERS, joined by the column TRANSACTION_ID. If the item is under serial control then the serial records are stored in MTL_UNIT_TRANSACTIONS, joined by the column TRANSACTION_ID. The Item revision and locator control are stored in the columns REVISION and LOCATOR_ID respectively. Transfer transactions are represented as two single records in the table. They are related through the column TRANSFER_TRANSACTION_ID, which contains the TRANSACTION_ID of the other transaction in the transfer. The index MTL_MATERIAL_TRANSACTIONS_UPGD is used only during install and upgrade, and will be
dropped during the course thereof, but is included here for completeness. Some important columns
are:-
Receivables Interface & Data flow from Order
Management to Receivables
1) RA_INTERFACE_LINES_ALL & RA_INTERFACE_SALESCREDITS_ALL:- A multi-org view which will retrive data for your current operating unit and ignore data in other operating units. Some important columns are:-
Line_Type For Sales Order Line ‘Line’, For Freight Charges ‘Freight’, For Tax ‘Tax’ Sales_Order Oe_Order_Headers.Order_Number Sales_Order_Line Oe_Order_Lines.Line_Number Purchase_Order Oe_Order_Headers.Lines.Cust_Po_Number
Interface_Line_Context values from profile option OM: Source Code Interface_Line_Attribute1 Order Number Interface_Line_Attribute2 Transaction Type Interface_Line_Attribute3 Delivery Name (if Required) , for Non Shippable Line it is 0 Interface_Line_Attribute4 waybill Interface_Line_Attribute5
Interface_Line_Attribute6 Order Line ID(OE_ORDER_LINES.LINE_ID) Interface_Line_Attribute7 Interface_Line_Attribute8 Bill of Lading Interface_Line_Attribute9 Customer Item Num (If Required) Interface_Line_Attribute10 Oe_Order_Lines.Ship_From_Ord_Id Interface_Line_Attribute12 Oe_Order_Lines.Shipment_Number Interface_Line_Attribute13 Oe_Order_Lines.Option_Number Interface_Line_Attribute14 Oe_Order_Lines.Service_Number
Internal Order
1) PO_REQUISITION_HEADERS_ALL:-PO_REQUISITION_HEADERS_ALL stores information about requisition headers. You need one row for each requisition header you create. Each row contains the requisition number, preparer, status, and description. REQUISITION_HEADER_ID is the unique system-generated requisition number. REQUISITION_HEADER_ID is invisible to the user. SEGMENT1 is the number you use to identify the requisition in forms and reports. Oracle Purchasing generates SEGMENT1 using the PO_UNIQUE_IDENTIFIER_CONTROL table if you choose to let Oracle Purchasing generate requisition numbers for you. PO_REQUISITION_HEADERS_ALL is one of three tables storing requisition information.
PO_REQUISITION_HEADERS_ALL corresponds to the Header region of the Requisitions window. SEGMENT1 provides unique values for each row in the table in addition to REQUISITION_HEADER_ID.
In short:- PO_Requisition_Headers_All
SEGMENT1 - Requisition Number AUTHORIZATION_STATUS - Lookup code and can have values
o APPROVED Document has been Approved o CANCELLED Document has been Cancelled o IN PROCESS Document is still undergoing Approval o INCOMPLETE Document is not yet Complete o PRE-APPROVED Document is Approved but not yet Accepted o REJECTED Document as been Rejected o REQUIRES REAPPROVAL Requires Reapproval o RETURNED Document has been Returned
REQUISITION_HEADER_ID Unique Requisition ID (PK) TRANSFERRED_TO_OE_FLAG –Y TYPE_LOOKUP_CODE - INTERNAL, PURCHASE ORG_ID - Operating unit unique identifier
2) PO_REQUISITION_LINES_ALL:- PO_REQUISITION_LINES stores information about requisition lines. You need one row for each requisition line you create.
Each row contains the line number, item number, item category, item description, need–by date, deliver–to location, item quantities, units, prices, requestor, notes, and suggested supplier information for the requisition line.
LINE_LOCATION_ID identifies the purchase order shipment line on which you placed the requisition. LINE_LOCATION_ID is null if you have not placed the requisition line on a purchase order.
In short: - PO_Requisition_Lines_ALL
REQUISITION_LINE_ID -Requisition line unique identifier REQUISITION_HEADER_ID- Requisition header unique identifier LINE_NUM -Line number UNIT_PRICE -Unit price in functional currency QUANTITY -Quantity of Line item LINE_LOCATION_ID -Document shipment schedule unique identifier UNSPSC_CODE -Standard UNSPSC CODE ITEM_DESCRIPTION -Item description ITEM_ID -Item unique identifier DESTINATION_TYPE_CODE -Destination type(INVENTORY, EXPENSE, SHOP FLOOR) DESTINATION_ORGANIZATION_ID -Destination organization unique identifier DESTINATION_SUBINVENTORY -Destination subinventory name SOURCE_ORGANIZATION_ID -Inventory source organization unique identifier SOURCE_SUBINVENTORY -Inventory source subinventory name SOURCE_TYPE_CODE -Requisition source type of item(INVENTORY, VENDOR) NEED_BY_DATE -Date the requisition is needed internally ORG_ID-Operating unit unique identifier
1. Item 1) MTL_SYSTEM_ITEMS_B:- MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the definitions for inventory items, engineering items, and purchasing items. You can specify item-related information in fields such as: Bill of Material, Costing, Purchasing, Receiving, Inventory, Physical attributes, General Planning, MPS/MRP Planning, Lead times, Work in Process, Order Management, and Invoicing. You can set up the item with multiple segments, since it is implemented as a flexfield. Use the standard 'System Items' flexfield that is shipped with the product to configure your item flexfield. The flexfield code is MSTK. The primary key for an item is the INVENTORY_ITEM_ID and ORGANIZATION_ID. Therefore, the same item can be defined in more than one organization. Each item is initially defined in an item master organization. The user then assigns the item to other organizations that need to recognize this item. A row is inserted for each new organization the item is assigned to. Many columns such as MTL_TRANSACTIONS_ENABLED_FLAG and BOM_ENABLED_FLAG correspond to item attributes defined in the MTL_ITEM_ATTRIBUTES table. The attributes that are available to the user depend on which Oracle applications are installed. The table MTL_ATTR_APPL_DEPENDENCIES maintains the relationships between items attributes and Oracle applications. Two units of measure columns are stored in MTL_SYSTEM_ITEMS_B table. PRIMARY_UOM_CODE is the 3-character unit that is used throughout Oracle Manufacturing. PRIMARY_UNIT_OF_MEASURE is the 25-character Unit of Measure that is used throughout Oracle Purchasing. Unlike the PRIMARY_UOM_CODE, the Unit of Measure is language-dependent attribute, however, PRIMARY_UNIT_OF_MEASURE column stores value in the installation base language only. Items now support multilingual description. MLS is implemented with a pair of tables: MTL_SYSTEM_ITEMS_B and MTL_SYSTEM_ITEMS_TL. Translations table (MTL_SYSTEM_ITEMS_TL) holds item Description and Long Description in multiple languages. DESCRIPTION column in the base table (MTL_SYSTEM_ITEMS_B) is for backward compatibility and is maintained in the installation base language only. Some Important columns are:-
2) HR_LOCATIONS_ALL:- Work location definitions.
2) PO_LOCATION_ASSOCIATIONS_ALL:- PO_LOCATION_ASSOCIATIONS associates a location defined within an organization with an Oracle Receivables customer. For each organization, you need one row for each association you want to make between a location and a customer.
You define location associations using the Business Purposes region of the Customer Addresses window. You first pick the customer along with a customer site and then enter the location and organization that you want to create an association with.
3) PO_SYSTEM_PARAMETERS_ALL:- PO_SYSTEM_PARAMETERS_ALL stores default, control, and option information you provide to customize Oracle Purchasing to your company's needs. PO_SYSTEM_PARAMETERS_ALL corresponds to the Purchasing Options window. This table has no primary key. The table should never have more than one row. Important column are:
1. ORDER_TYPE_ID 2. ORDER_SOURCE_ID NUMBER 3. ORG_ID
Drop Shipment
Purchase Release inserts the records in Requisition Interface tables. Purchase Release picks the records from OE_ORDER_LINES_ALL for Booked order where SOURCE_TYPE_CODE is ‘EXTERNAL’. After running the Requisition Import (this is automatically run by Workflow Background Process for the Purchase Released Orders) record is inserted in OE_DROP_SHIP_SOURCES and PO_REQUISITION_HEADERS_ALL& PO_REQUISITION_LINES_ALL . Requisition Import Submits new request “Create Releases request” which Releases the Purchase Order i.e. putting the records in PO_HEADERS_ALL and PO_LINES_ALL. INTERFACE_SOURCE_CODE in PO_REQUISITION_HEADERS_ALL refers to ‘ORDER ENTRY’ and INTERFACE_SOURCE_LINE_ID refers to DROP_SHIP_SOURCE_ID in OE_DROP_SHIP_SOURCES .Also PO_HEADER_ID in PO_HEADERS_ALL and PO_LINE_ID In PO_LINES_ALL is stored in OE_DROP_SHIP_SOURCES creating the Purchase Order from Requisitions. Material can be received on the PO after the PO approval. Records do not directly go to Receipt Table (RCV_SHIPMENT_HEADERS& RCV_SHIPMENT_LINE). Once the PO is approved, record goes to Shipment Schedule table (RCV_LINE_LOCATIONS_ALL). The LINE_LOCATION_ID is the Primary key for this table and it is also stored in OE_DROP_SHIP_SOURCES. After the Receipt of the Material in Logical Organization, 2 records gets inserted in MTL_MATERIAL_TRANSACTIONS. One record is of Receipt of the Material (+ve Qty.) and another record
is of Sales Order Issue (-ve entry). The Order line automatically Ship Confirmed after successful receipt of the Material. OE_ORDER_HEADERS_ALL OE_ORDER_LINES_ALL LINE_ID HEADER_ID ORDERED_QUANTITY INVENTORY_ITEM_ID LINE_CATEGORY_CODE ORDER SOURCE_TYPE_CODE EXTERNAL SCHEDULE_SHIP_DATE SOLD_FROM_ORG_ID PO_REQUISITIONS_INTERFACE_ALL PO_REQUISITION_HEADERS_ALL REQUISITION_HEADER_ID SEGMENT1 AUTHORIZATION_STATUS INTERFACE_SOURCE_CODE ORDER ENTRY PO_REQUISITION_LINES_ALL REQUISITION_LINE_ID REQUISITION_HEADER_ID ITEM_DESCRIPTION & ITEM_ID UNIT_PRICE QUANTITY SOURCE_TYPE_CODE VENDOR NEED_BY_DATE DESTINATION_TYPE_CODE INVENTORY DESTINATION_ORGANIZATION_ID VENDOR_ID VENDOR_SITE_ID OE_DROP_SHIP_SOURCES DROP_SHIP_SOURCE_ID HEADER_ID LINE_ID DESTINATION_ORGANIZATION_ID REQUISITION_HEADER_ID REQUISITION_LINE_ID PO_HEADER_ID PO_LINE_ID LINE_LOCATION_ID
And req_h.interface_source_line_id =od.drop_ship_source_id
And od.po_header_id =ph.po_header_id
And od.line_id =ol.line_id
And ol.header_id =oh.header_id;
Returns
MTL_SO_RMA_INTERFACE & MTL_SO_RMA_RECEIPTS tables are obsolete. Once the RMA is booked, material can be received on RMA if OE_ORDER_LINES_ALL.BOOKED_FLAG is ‘Y’ and OE_ORDER_LINES_LINES .FLOW_STATUS_CODE is 'AWAITING_RETURN'. Also the Receipts are stored in table RCV_SHIPMENT_HEADERS & RCV_SHIPMENT_LINES. OE_ORDER_LINES_ALL ORDERED_QUANTITY SOLD_TO_ORG_ID SHIP_TO_ORG_ID INVOICE_TO_ORG_ID INVENTORY_ITEM_ID PRICE_LIST_ID LINE_CATEGORY_CODE RETURN RETURN_CONTEXT INVOICE, ORDER, PO, RETURN_ATTRIBUTE1 . . RETURN_ATTRIBUTE15 RETURN_REASON_CODE REFERENCE_HEADER_ID HEADER_ID, which is being returned REFERENCE_LINE_ID LINE_ID, which is being returned REFERENCE_CUSTOMER_TRX_LINE_ID OE_ORDER_HEADERS_ALL ORDER_CATEGORY_CODE RETURN, MIXED RCV_SHIPMENT_HEADERS SHIPMENT_HEADER_ID RECEIPT_SOURCE_CODE CUSTOMER ORGANIZATION_ID RECEIPT_NUM CUSTOMER_ID HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID RCV_SHIPMENT_LINES SHPMENT_LINE_ID SHIPMENT_HEADER_ID LINE_NUM QUANTITY_RECEIVED UNIT_OF_MEASURE ITEM_DESCRIPTION ITEM_ID OE_ORDER_LINES.INVENTORY_ITEM_ID SHIPMENT_LINE_STATUS_CODE FULLY RECEIVED, PARTIALLY RECEIVED SOURCE_DOCUMENT_CODE RMA DESTINATION_TYPE_CODE INVENTORY TO_ORGANIZATION_ID OE_ORDER_HEADERS.SHIP_FROM_ORG_ID TO_SUBINVENTORY
WIP_JOB_SCHEDULE_INTERFACE WIP_DISCRETE_JOBS WIP_ENTITY_ID ORGANIZATION_ID SOURCE_LINE_ID Order LINE_ID of Item of which Item Type is CONFIG PRIMARY_ITEM_ID INVENTORY_ITEM_ID of Item in Order of which
Item Type is CONFIG CLASS_CODE Discrete START_QUANTITY QUANTITY_COMPLETED COMMON_BON_SEQENCE_ID Assembly identifier used as bill of material
reference for explosions of nonstandard job
BOM_REVISION BOM revision for the primary assembly COMPLETION_SUBINVENTORY STATUS_TYPE (Lookup Type = WIP_JOB_STATUS) 1=Unreleased 3=Released 4=Complete 12=Closed WIP_REQUIREMENT_OPERATIONS INVENTORY_ITEM_ID ORGANIZATION_ID WIP_ENTITY_ID OPERATION_SEQUENCE_NUM COMPONENT_SEQUENCE_ID WIP_SUPPLY_TYPE REQUIRED_QUANTITY QUANTITY_ISSUED QUNTITY_PER_ASSEMBLY SEGMENT1 ITEM
Price Lists QP_LIST_HEADERS_B This table stores the header information for all lists. List types can be, for example, Price Lists, Discount. LIST_HEADER_ID CURRENCY_CODE ROUNDING_FACTOR LIST_TYPE_CODE Price list = PRL, Promotion = PRO PARENT_LIST_HEADER_ID ACTIVE_FLAG QP_LIST_HEADERS_TL This table stores the translatable columns, name and description of the list, in each of the available languages in the database. LIST_HEADER_ID NAME DESCRIPTION QP_LIST_LINES This table stores all list lines for lists in QP_LIST_HEADERS_B. LIST_LINE_ID LIST_HEADER_ID LIST_LINE_TYPE_CODE LIST_PRICE LIST_PRICE_UOM_CODE INVENTORY_ITEM_ID ORGANIZATION_ID
Customers
1. HZ_PARTIES (RA_CUSTOMERS):- The HZ_PARTIES table stores basic information about parties that can be shared with any relationship that the party might establish with another party. The primary key for this table is PARTY_ID.
Few Important Columns are
PARTY_ID: Party identifier PARTY_NUMBER: Unique identification number for this party PARTY_NAME: Name of the party PARTY_TYPE: The party type can only be Person, Organization, Group or Relationship.
2. HZ_CUST_ACCOUNTS:-The HZ_CUST_ACCOUNTS table stores information about customer accounts, or business relationships that the deploying company establishes with a party of type Organization or Person. This table focuses on business relationships and how transactions are conducted in the relationship. Since a party can have multiple customer accounts, this table might contain several records for a single party. For example, an individual person can establish a personal account, family account, and a professional account for a consulting practice. The primary key for this table is CUST_ACCOUNT_ID.
Few Important Columns are
CUST_ACCOUNT_ID: Customer account identifier PARTY_ID: A foreign key to the HZ_PARTY table. ACCOUNT_NUMBER: Account Number CUSTOMER_TYPE: Receivables lookup code for the CUSTOMER_TYPE attribute. I for internal
customers, R for revenue generating external customers. CUSTOMER_CLASS_CODE: Customer class identifier
Addresses
3. HZ_CUST_ACCOUNT_SITES_ALL:- The HZ_CUST_ACCT_SITES_ALL table stores all customer account sites across all operating units. Customer account sites are addresses, for customer accounts, where the deploying company does business with its customers. One customer account can have multiple customer account sites, and customer account sites for one customer account can belong to multiple operating units. The primary key for this table is CUST_ACCT_SITE_ID.
Few Important Columns are
CUST_ACCT_SITE_ID: Customer site identifier CUST_ACCOUNT_ID: Identifier for a customer account. Foreign key to the HZ_CUST_ACCOUNTS
table PARTY_SITE_ID: Identifier for a party site. Foreign key to the HZ_PARTY_SITES table BILL_TO_FLAG: Indicates if this is a Bill-To site. SHIP_TO_FLAG: Indicates if this is a Ship-To site.
MARKET_FLAG: Indicates if this is a Marketing site.
4. HZ_PARTY_SITES:- The HZ_PARTY_SITES table links a party (see HZ_PARTIES) and a location (see HZ_LOCATIONS) and stores location-specific party information such as MAILSTOP and ADDRESSEE. One party can optionally have one or more party sites. One location can optionally be used by one or more parties. For example, 500 Oracle Parkway can be specified as a party site for Oracle Corporation. This party site can then be used for multiple customer accounts within the same party.
The primary key for this table is PARTY_SITE_ID.
Few Important Columns are
PARTY_SITE_ID: Party site identifier. PARTY_ID: Identifier for the party. Foreign key to the HZ_PARTIES table. LOCATION_ID: Identifier for the party site. Foreign key to the HZ_LOCATIONS table. PARTY_SITE_NUMBER: Party site number. PARTY_SITE_NAME: User-defined name for the site. ADDRESSEE: Addressee information
5. HZ_LOCATIONS (RA_ADDRESSES_ALL):- The HZ_LOCATIONS table stores information about a delivery or postal address such as building number, street address, postal code, and directions to a location. This table provides physical location information about parties (organizations and people) and customer accounts. The primary key for this table is LOCATION_ID.
Few Important Columns are
LOCATION_ID: Unique identifier for this location COUNTRY: Country code from the TERRITORY_CODE column in the FND_TERRITORY table ADDRESS1: First line for address ADDRESS2: Second line for address ADDRESS3: Third line for address ADDRESS4: Fourth line for address CITY: City POSTAL_CODE: Postal Code STATE: State ADDRESS_KEY: Derived key that facilitates fuzzy searches
Sites
6. HZ_CUST_SITE_USES_ALL (RA_SITE_USES_ALL):- The HZ_CUST_SITE_USES_ALL table stores business purposes assigned to customer account sites, for example Bill-To, Ship-To, and Statements. Each customer account site can have one or more purposes. This table is a child of the
HZ_CUST_ACCT_SITES_ALL table, with the foreign key CUST_ACCT_SITE_ID. The HZ_CUST_SITE_USES_ALL table also stores operating unit identifier, though the HZ_CUST_ACCT_SITES_ALL table itself stores the operating unit for customer account sites. The primary key for this table is SITE_USE_ID.
Few Important Columns are
SITE_USE_ID: Site use identifier CUST_ACCT_SITE_ID: Identifier for the customer account site. Foreign key to the
HZ_CUST_ACCT_SITES_ALL table SITE_USE_CODE: Business purpose assigned to customer site account, such as Bill-To, Market,
and Statements. PRIMARY_FLAG: Indicates if this site is the primary site for this customer account. Y for the
primary customer account site. N for other customer account sites.
Interfaces (Import Orders)
The Sales Order has been modeled as a business object that Oracle Order Management owns. The Sales Order business object comprises of several entities, namely, Header, Header Sales Credits, Header Price Adjustments, Header Pricing Attributes, Header Adjustment Attributes, Header Adjustment Associations, Lines, Line Sales Credits, Line Price Adjustments, Line Pricing Attributes, Line Adjustment Attributes, Line Adjustment Associations and Line Lot Serial Numbers.
Order Import can import new, change, and completed sales orders or returns from other applications such as a legacy system. The orders may come from any source such as EDI transactions that are processed by the Oracle e-Commerce Gateway or internal orders created for internal requisitions developed in Oracle Purchasing or returns.
Order Import features include validation and defaulting, processing constraint checks, applying and releasing of order holds, scheduling of shipments, then ultimately inserting, updating or deleting the orders in the base Order Management tables. Order Management checks all the data during the import process to ensure its validity within Order Management. Valid transactions are then converted into orders with lines, reservations, price adjustments, and sales credits in the base Order Management tables.
You can setup your defaulting rules which allow you to default columns in the same way as for orders entered online. You can pass the column value Null to Order Import if you want the defaulting rules to populate the column. However, if the column is defined as Not Null or Mandatory column and the defaulting rules fail to default the column, for any reason, Order Import displays an error message without importing the order.
Import Types:
Configurations Order Management provides you with the ability to import ATO and PTO configurations. Changes you can import changes to orders that have been imported by passing all changed data through Order Import. You can update or delete orders, order lines, price adjustments, and sales credits. You can use change sequence numbers to control the sequence of changes you want to make to orders. Order Status You can import new, booked or closed orders. If an order is imported with an entry status of Booked (OE_HEADERS_IFACE_ALL.BOOKED_FLAG=Y) the result after import is that a Action Request of BOOK_ORDER is initiated. You may also pass the Action Request to BOOK_ORDER; both methods are supported. Workflows You can import an order within any valid order workflow activity. The order must be at the initial activity of Entered, Booked, or Closed. Orders imported using Order Import cannot be in the middle of a workflow activity. Manual and Automatic Pricing Pricing in process order API can be controlled using flag calculate_price_flag on order line record. When set to ‘Y ‘the process order API fetches the list price and applies adjustments and charges. When set to N, the process order API would fetch a list price if the list price is not passed and no adjustments would be applied. When set to P, all the modifiers which are associated with phases having override freeze flag set to Y are applied. That mainly includes freight charges. Scheduling Order Import allows you to reserve orders as they are imported, using the same rules as online order entry. If the scheduling request is unsuccessful on an imported order, the order will still be imported, and the scheduling exceptions can be viewed in the Error Messages of the Order Import Corrections window. You can use Schedule, Unschedule, Reserve or Unreserve as values for scheduling actions. Return Lines Process order can be used to create and update return lines also. To create a return line, you can either pass in the line category of RETURN on the order line record and the line type would default to the inbound line type of the order type. Alternatively, you can also provide a line type of the typeReturn on the order line record. Additionally, if you want to specify a reference for the return line, you can pass in the return flexfields (return_context, return_attribute1-2). Column Return_Context can have the following values to determine the reference type:
Sales Order Customer PO Invoice Serial Number
Process Order Application Open Interface Return_Attribute1... Return_Attribute2 can have the following values depending on the reference type:
1. Sales Order return_Attribute1: Header ID
return_Attribute2: Line ID 2. Customer PO
return_Attribute1: Header ID return_Attribute2: Line ID
3. Invoice return_Attribute1: Invoice Header ID return_Attribute2: Invoice Line ID
4. Serial Number return_Attribute1: Inventory Item ID return_Attribute2: Serial Number
If you wish to import an order as booked, you must set the OPERATION_CODE column in the actions interface table OE_ACTIONS_IFACE_ALL with a value of "BOOK_ORDER". Do not use the BOOKED_FLAG column in the OE_HEADERS_IFACE_ALL table. This will cause the order header to show as booked, but not the order lines. The order lines will not progress through workflow to the Pick Release/Shipping actions.
1. OE_HEADERS_IFACE_ALL This is a multi-org table for sales order headers open interface. This table stores order header information that is imported from a feeder system into Oracle Order Management using Order Import. For more information on Order Import refer to the Oracle Order Management Suite API's and Open Interfaces Manual.
2. OE_LINES_IFACE_ALL:- This is a multi-org table for sales order lines open interface. This table stores order lines information that is imported from a feeder system into Oracle Order Management using Order Import. For more information on Order Import refer to the Oracle Order Management Suite API's and Open Interfaces Manual.
2. OE_PRICE_ADJS_IFACE_ALL:-
3. OE_PRICE_ATTRS_IFACE_ALL:-
4. OE_CREDITS_IFACE_ALL:-
5. OE_RESERVTNS_IFACE_ALL:-
6. OE_LOTSERIALS_IFACE_ALL:-
7. OE_ACTIONS_IFACE_ALL:-
Setups
Transaction Types
1. OE_TRANSACTION_TYPES_ALL
2. OE_TRANSACTION_TYPES_TL:- This is a mult-lingual table for OE_TRANSACTION_TYPES_ALL table:- SELECT OH.ORDER_NUMBER
,OTTA.ORDER_CATEGORY_CODE ,OTTA.ORG_ID ,OTTL.NAME
FROM OE_ORDER_HEADERS_ALL OH ,OE_TRANSACTION_TYPES_ALL OTTA ,OE_TRANSACTION_TYPES_TL OTTL
WHERE OH.ORDER_TYPE_ID =OTTA.TRANSACTION_TYPE_ID AND OTTA.TRANSACTION_TYPE_ID =OT T L.TRANSACTION_TYPE_ID AND order_number =113 0100008; 3. OE_WORKFLOW_ASSIGNMENTS:-This table associates assignments to order types and line
For Document Sequence record stores in FND_DOCUMENT_SEQUENCES. After creating the Transaction Type, automatically the Document Category gets created and record goes to table FND_DOCUMENT_CATEGORIES.
1. FND_DOCUMENT_SEQUENCES DOCUMENT_SEQUENCE_ID NAME INITIAL_VALUE TABLE_NAME OE_TRANSACTION_TYPES_ALL
2. FND_DOCUMENT_CATEGORIES APPLICATION_ID CODE NAME TRANSACTION TYPE NAME DESCRIPTION TABLE_NAME OE_TRANSACTION_TYPES_ALL
1. OE_ORDER_HOLDS_ALL:-This table stores information of all the orders and lines that are on hold and the link to hold sources and hold releases. HOLD_SOURCE_ID HEADER_ID LINE_ID ORG_ID RELEASED_FLAG
2. OE_HOLD_AUTHORIZATIONS:-Stores information about who has the authority to apply and release holds. – Retrofitted
3. OE_HOLD_DEFINITIONS:-This table stores information about hold name and its validity period.
4. OE_HOLD_RELEASES:-This tables stores information about all the holds that has been released.
Lookups
1. FND_LOOKUP_VALUES Quick Code values LOOKUP_TYPE LOOKUP_CODE MEANING DESCRIPTION
FROM OE_SALES_CREDITS CR ,JTF_RS_SALESREPS SREP ,OE_ORDER_HEADERS_ALL OH ,OE_SALES_CREDIT_TYPES CR_TYPE
WHERE CR.SALESREP_ID =SREP.SALESREP_ID AND CR.HEADER_ID =OH.HEADER_ID AND OH.ORG_ID =SREP.ORG_ID AND CR_TYPE.SALES_CREDIT_TYPE_ID =CR.SALES_CREDIT_TYPE_ID AND OH.ORDER_NUMBER =113 0100005;
Profiles Credit Check Rules 1. OE_CREDIT_CHECK_RULES:-This table stores information about the credit check rules.
2. PO_DISTRIBUTIONS_ALL:- Purchase order distributions
1. QP_ATTRIBUTE_DEFNS:-QP_ATTRIBUTE_DEFNS is the table on which the Qualifier and Pricing Attribute Descriptive Flexfields are based. It is used for the entity and attributes definition in attribute sourcing.
2. QP_COUPONS:-QP_COUPONS stores any Coupons which have been issued.
3. QP_EVENT_PHASES:- QP_EVENT_PHASES stores the mapping between pricing events and pricing phases.
4. QP_LIST_HEADERS_B:- QP_LIST_HEADERS_B stores the header information for all lists. List types can be, for example, Price Lists, Discount
5. QP_LIST_HEADERS_TL:- QP_LIST_HEADERS_TL stores the translatable columns, name and description of the list, in each of the available languages in the database.
6. QP_LIST_LINES:-QP_LIST_LINES stores all list lines for lists in QP_LIST_HEADERS_B.
7. QP_PRICE_FORMULAS_B:- QP_PRICE_FORMULAS_B stores the pricing formula header information.
8. QP_PRICE_FORMULAS_TL:- This table stores the translatable columns, name & description of the pricing formulas, in each of the available languages in the database.
9. QP_PRICE_FORMULA_LINES:-QP_PRICE_FORMULA_LINES stores each component that makes up the formula.
10. QP_PRICE_REQ_SOURCES:-QP_PRICE_REQ_SOURCES stores the mapping between Pricing Request Types and Source Systems.
11. QP_PRICING_ATTRIBUTES:-QP_PRICING_ATTRIBUTES stores product information and pricing attributes.
12. QP_PRICING_PHASES:- QP_PRICING_PHASES stores all pricing phases.
