Price list and Modifier to be restricted against the OU level
QP: Security Control                                                      —         OFF to ON

Impacting Profile Options

 

1.Discounting Privilege
It should be set to full or unlimited.
   The button Add Adjustment is displayed based on the combination of the profile “OM: Discounting Privileges” and the “enforce List price” flag for the Order Type. If the order type is not entered then we do not consider the “Enforce List Price” flag and assume it to be false. We look at the profile OM: Discounting Privilege to see if the user has the privilege to apply the manual adjustments. Also if this privilege is FULL, then if the Order Type has Enforce List Price, a manual adjustment cannot be applied. If the privilege is None the user can never apply a manual adjustment. If the profile is

Ref: Master Note: Common Reasons for Error APP-ONT-250274 – No Manual Discount Available, Online Discounting Is Not Allowed; Order Type Enforce List Price [ID 1105868.1]


OM: List Price Override Privilege                         —         Unlimited Access
SO Price Override
ASO : Discounting Privilege                                —         None to Full       (Site)
OE: Discounting Privilege                                   —         Null to Unlimited            (User)
OM: Discounting Privileges                                 —         Null to Unlimited            (User)
QP: Blind Discount Option                                  —         No to Yes          (Site)
OM: Preinsert Manual Adjustments                     —         No to Yes          (Site)
1. Create Modifier (Discount) and Uncheck Automatic flag to both header and line,
2. Line level Enable Override check box then Header qualifier to add the price list  à Save
Now try to create the sales Order à go the lines enter the Item & Qty save or Book SO after change unit selling price now allow the manual override.

How to Generate the COGS Account from the Order Type [ID 414314.1]
In this Document
Purpose

Scope and Application

How to Generate the COGS Account from the Order Type

References
Applies to:
Oracle Order Management – Version: 11.5.1 to 12.0.6 – Release: 11.5 to 12.0
Information in this document applies to any platform.
FORM:OEXDTTYP.FMB – Define Transaction Types
Checked for relevance on 26-Nov-2010
Purpose
In order to generate the COGS account from the Cost of Goods Sold account assigned to the
order type (A.K.A. OM Transaction Type) of the order, the seeded COGS workflow needs to be
modified to change the default node from Get CCID for a line to Get CCID from the Order Type
ID.  This bulletin will detail the required changes to accomplish this.
Scope and Application
Familiarity with Workflow and Workflow Builder is required.
How to Generate the COGS Account from the Order Type
Background:
The COGS Account Generator is a Workflow Process that derives the Cost of Goods Sold
account for a transaction interfaced to Inventory from Order Management/Shipping. The
workflow item type ‘OM: Generate Cost of Goods Sold Account’ which has an internal name of
OECOGS encompasses all processes designed to build the COGS. The ‘Generate Default
Account’ is a seeded process which builds the COGS Account. It comes seeded with the function
Get CCID (account ID) for a line. This function will return the CCID assigned to an item as it
exists in the shipping warehouse. The intent of this function is to retrieve the CCID from the
Cost of Goods Sold assigned to the item on the sales order line within the shipping
inventory organization.
Modifying the ‘Generate Default Account’ to derive the Cost of Goods Sold account from
the Order Type:
1. The first step is to copy the existing ‘OM: Generate Default Account’ process. Give it a new
name, e.g. ‘NEW_DEFAULT_ACCOUNT_GENERATOR’, in the property sheet Internal Name
field. Please do not simply modify the existing default process.

2. Double-click on the new process from within the Navigator and continue by deleting the link
between the ‘Start generating Code Combination’ and the ‘Get CCID for a line’ function. Insert
between them the function ‘Get CCID from the Order Type’ by dragging it from the Navigator to
the process screen. Using the right mouse button, draw a line connecting the ‘Start generating
Code Combination’ to the ‘Get CCID from the Order Type’ function. Save this process
definition off to the database.

Point the Chart of Accounts to the new process:

Saving new Workflow Process Definitions to the database is all well and good, but it is of no
benefit unless the Chart of Accounts structure can invoke it. The relationship between the Chart
of Accounts structure and the Workflow Process for the ‘OM: Generate Cost of Good Sold’ item
type is made in the ‘Account Generator Processes’ form (OM: Setup > Financials > Flexfields >
Key > Accounts). Using the flashlight icon choose the applicable Chart of Accounts. Then assign
the new process to the ‘Generate Cost of Goods Sold Account’ Item Type.
Ensure that the new Account Generator points to the correct Chart of Accounts:
Care must be taken to ensure that the new Account Generator points to the correct Chart of
Accounts. To determine the correct Chart of accounts, follow the steps below:
1. Get the value of the Set of Books for the inventory organization for which you wish to
interface the transactions. Get this from the Organization Definitions form. (Inv: Setup >
Organization > Organizations). Query the name of the inventory organization desired, then with
the cursor on the ‘Inventory Organization’ organization classification, click the ‘Others’ button.
Choose ‘Accounting Information’.

2. Determine the Set of Books for the Order Management responsibility for which the order is
assigned. Accomplish this task in the same way as with the inventory organization as
demonstrated above, except place the cursor on the ‘Operating Unit’ line rather than the
‘Inventory Organization’ line. Choose Operating Unit Information.

3. Query this Set of Books up in the Define Set of Books form (Setup > Financials > Books).
Record the value for the ‘Chart of Accounts’.

4. Finally, find the workflow process this chart of accounts uses when building the COGS
account from the Account Generator Processes form (Setup > Financials > Flexfields > Key >
Accounts).

R12 Deferred COGS: New Process for Cost of Goods Sold [ID 567261.1]

In summary :
1. If the SELLING_OU = SHIPPING_OU, during an ‘SO Issue’ transaction always
the deferred COGS would be used and the COGS account would get reflected only
when the actual revenue recognition has happened, till then only the
temporary deferred COGS would hold the cost.

2. If the SELLING_OU <> SHIPPING_OU, during an ‘SO Issue’ transaction
Intercompany flows would come into picture and if a flow exists it would also
check if ‘Advanced Accounting’ is enabled. If ‘Advanced Accounting’ is not
enabled then COGS account would get costed, else Deferred COGS account would
get costed.
See Metalink
Note 416678.1 R12 : Deferred COGS Account[ID 416678.1]- for further details
below

R12 : Deferred COGS Accounting

Applies to:
Oracle Cost Management – Version: 12.0.0 to 12.1 – Release: 12 to 12.1
Information in this document applies to any platform.
Purpose
The purpose of the Bulletin is to make the reader aware of the new enhancement of the Deferred
COGS account.The enhancement is applicable for Release 12 onwards.
Scope and Application
The bulletin is applicable to Release 12 onwards. The reader is assumed to understand the
accounting in the 11i release.
R12 : Deferred COGS Accounting
Introduction :
The deferred COGS of goods account is the new feature introduced in Release 12. The basic
fundamental behind the enhancement is that the COGS is now directly matched to the Revenue.
The same was not possible till now.

Prior to this enhancement, the value of goods shipped from inventory were expensed to COGS
upon ship confirm, despite the fact that revenue may not yet have been earned on that shipment.
With this enhancement, the value of goods shipped from inventory will be put in a Deferred
COGS account. As percentages of Revenue are recognized, a matching percentage of the value
of goods shipped from inventory will be moved from the Deferred COGS account to the COGS
account, thus synchronizing the recognition of revenue and COGS in accordance with the
recommendations of generally accepted accounting principles.

The Matching Principle is a fundamental accounting directive that mandates that revenue and its
associated cost of goods sold must be recognized in the same accounting period. This
enhancement will automate the matching of Cost of Goods Sold (COGS) for a sales order line to
the revenue that is billed for that sales order line.

The deferral of COGS applies to sales orders of both non-configurable and configurable items
(Pick-To-Order and Assemble-To-Order). It applies to sales orders from the customer facing
operating units in the case of drop shipments when the new accounting flow introduced in
11.5.10 is used. And finally, it also applies to RMAs that references a sales order whose COGS
was deferred. Such RMAs will be accounted using the original sales order cost in such a way that
it will maintain the latest known COGS recognition percentage. If RMAs are tied to a sales
order, RMAs will be accounted for such that the distribution of credits between deferred COGS
and actual COGS will maintain the existing proportion that Costing is aware of.  If RMAs are not
tied to a sales order, there isno deferred COGS.

SETUP and ACCOUNTING :
To set the deferred COGS account.

Inventory — Setup — Organization — Parameters — Other Accounts
A new account is added which is referred as the Deferred COGS accounts.
Please note that when upgrading from a pre R12 version the DEFERRED_COGS_ACCOUNT
will be populated if it is null with the cost_of_goods_sold_account on the organization
parameter. This can then be changed accordingly if a different account is required.

NEW ACCOUNTING :

Release 12 :

When a Sales order is shipped the following accounting takes place:

Inventory Valuation Account : Credit.
Deferred COGS account : Debit

Once the revenue is recognised, you would need to decide the percentage you wish to recognize
the Revenue. A COGS recognition transaction will be created to reflect a change in the revenue
recognition percentage for a sales order line.

The steps to generate such transactions are as follows:
1. Run the Collect Revenue Recognition Information program. This program will collect the
change in revenue recognition percentage based on AR events within the user specified date
range.
2. Run the Generate COGS Recognition Events. This program will create the COGS recognition
transaction for each sales order line where there is a mismatch between the latest revenue
recognition percentage and the current COGS recognition percentage.

Note that users can choose how often they want to create the COGS Recognition Events.

Navigation to run the COGS recognition request :
– Cost > COGS Recognition > Collect Revenue Recognition Information
– Cost > COGS Recognition > Generate COGS Recognition Events
– Cost > View Transactions > Material Transactions

The distribution for the COGS Recognition transaction associated with the Sales Order
transaction now would be as follows:

Deferred COGS : Debit revenue percentage
COGS               : Credit (Actual revenue percentage )
Thus, essentially the recognized COGS balance is to move the value from Deferred COGS to COGS.

This particular COGS recognition transaction actually correspond to a revenue recognition
percentage change.

You can view the transactions as :
Navigation:
– Cost > View Transactions > Material Transactions > Distributions

A new COGS Revenue Matching Report shows the revenue and COGS information of sales
order that fall within the user specified date range by sales order line
SIMPLER TERMS ( Table level details ) :

Once the whole cycle is complete we will have 2 transactions lines in mtl_material_transactions.

1. Sales Order
2. COGS Recognition transaction

Accounting will be in mtl_transaction_accounts and the Subledger accounting tables as follows:

Transaction 1:
Inventory Valuation Account : Credit. (item_cost)
Deferred COGS account : Debit (item_cost)
Transaction 2:
Deferred COGS : Credit (Actual revenue percentage)
COGS : Debit (Actual revenue percentage )
3. R12: COGS To Recognize Cost By Item Types [ID 558044.1]

Solution

Applies to:
Oracle Order Management – Version: 12.0.4 and later   [Release: 12.0 and later ]
Information in this document applies to any platform.
*** Checked for relevance on 02-Sept-2010 ***
Goal
How to debit the correct account from R12 COGS workflow to recognize cost by Item Types. In
viewing the Material Distributions, there is no COGS entry for a specific transaction.

Solution
When the shipment transaction is costed, it will not debit COGS account directly. It will debit the
deferred COGS account defined at the organization parameter form.  The user needs to run a
series of concurrent programs to match revenue and COGS and transfer from deferred COGS
account to true COGS account.
If using OPM, in the MTL_MATERIAL_TRANSACTIONS table, if
SO_ISSUE_ACCOUNT_TYPE is ‘NULL’, this indicates that the Sales Order line is not setup for
deferred revenue recognition.
Please check if the Sales Orders that are being created are set for deferred revenue recognition
or not.  MTL_MATERIAL_TRANSACTIONS.SO_ISSUE_ACCOUNT_TYPE should be ‘2’ if
the Sales Order line is set for deferred revenue recognition.
There is a bug already reported where the COGS recognition event is not recognized for normal
sales order lines (which are NOT set for deferred revenue recognition).
Check version of the following file—
$GMF_TOP/src/common/gmfxoupd.lc
If using OPM,  go to OPM_financials and run the 3 steps for COGS recognition.
Run the Create Accounting process in order to generate the Order Management trx accounts.
Verify the Postings in Create Accounting Report/ Detailed Subledger Report for the COGS
journal
line type for the transaction.
The R12 Cost Management Users Guide, available online through Metalink, notes the
following —
Run a set of concurrent processes to record Sales Order and revenue recognition transactions and
to create and cost COGS recognition transactions. These COGS recognition transactions adjust
deferred and earned COGS in an amount that synchronizes the % of earned COGS to earned
revenue on Sales Order shipment lines.
1. Record Order Management Transactions: records new sales order transaction activity such as
shipments and RMA returns in Oracle Order Management.
2. Collect Revenue Recognition Information: determines the percentage of recognized or earned
revenue related to invoiced sales order shipment lines in Oracle Receivables.
3. Generate COGS Recognition Events: creates and costs COGS recognition events for new sales
order shipments/returns and changes in revenue recognition and credits for invoiced sales order
shipment lines.
The matching and synchronization of the earned and deferred components of sales order revenue
and
COGS is accomplished by running the following COGS recognition concurrent processes at
user-defined intervals:
• Record Order Management Transactions
• Collect Revenue Recognition Information
• Generate COGS Recognition Events.

Step 1: Define Flexfields

Define key and descriptive flexfields to capture additional information about orders and transactions. This step is required for Key Flexfields, and optional if you plan on using the functionality surrounding Descriptive Flexfields. Several defaulting values are
provided.

Step 2: Multiple Organizations

Define multiple organizations in Oracle Inventory. This step is optional.

Step 3: Inventory Organizations

Define inventory organizations (warehouses), parameters, subinventories, and picking rules in Oracle Inventory. You must define at least one item validation organization and at least one organization that acts as an inventory source for orders fulfilled internally.

If you plan to drop ship some orders, you must also define at least one logical organization for receiving purposes. Your item validation organization can be the same as your inventory source or your logical receiving organization, but you cannot use one organization for all three purposes. This step is required.

Step 4: Profile Options

Define profile options to specify certain implementation parameters, processing options, and system options. This step is required.

Step 5: Parameters

Set your Order Management Parameters to validate items, enable customer relationships, and operating unit defaults. This step is required.

Step 6: Invoicing

Define invoicing information, including payment terms, invoicing and accounting rules, Autoaccounting parameters, territories, and invoice sources.This step is required if you plan on transferring invoicing information to Oracle Receivables. Several defaulting values are provided.

Step 7: Salespersons

Define information on your sales representatives. This step is optional.

Step 8: Tax

Define tax features, such as codes, rates, exceptions, and exemptions. This step is required.

Step 9: QuickCodes

Define QuickCodes that provide custom values for many lists of values throughout Order Management. This step is required if you plan on creating user defined Quickcodes for utilization within Order Management. Defaulting values are provided.

Step 10: Workflow

Define order and line processing flows to meet different order and line type requirements. This step is required.

Step 11: Document Sequences (Order Numbering)

Define Document Sequences for automatic or manual numbering of orders. This step is required.

Step 12: Order Import Sources

Define sources for importing orders into Order Management. This step is required if you plan on importing orders or returns into Order Management.

Step 13: Units of Measure

Define the units of measure in which you supply items. This step is required.

Step 14: Item Information

Define item information, including item attribute controls, categories, and statuses. This step is required.

Step 15: Items

Define the items that you sell, as well as container items. This step is required.

Step 16: Configurations

Define the configurations that you sell. This step is required if you plan on generating orders or returns for configured items. Several defaulting values are provided.

Step 17: Pricing

Define price lists for each combination of item and unit of measure that you sell. Optionally, you can define pricing rules and parameters to add flexibility. This step is required.

Step 18: Customer Classes

Define customer profile classes. This step is required if you plan on using the functionality surrounding Customer Profiles. Several defaulting values are provided.

Step 19: Customers

Define information on your customers. This step is required.

Step 20: Item Cross References

Define item cross references for ordering by customer part number, UPC, or any generic item number. This step is required if you plan on using the functionality surrounding item cross referencing. Several defaulting values have been provided.

Step 21: Sourcing

Define your sourcing rules for scheduling supply chain ATP functions. This step is optional.

Step 22: Order Management Transaction Types (Order and Line Types)

Define Order Management transaction types to classify orders and returns. For each order type, you can assign a default price list, defaulting rules, order lines, return lines, line types, workflow assignments, payment terms, and freight terms. This step is required.

Note: Order Management provides NO seeded OM transaction types. For existing Oracle Order Entry customers, Order Management will update existing Order Types to OM transaction type during the upgrade process.

Step 23: Cost of Goods Sold (COGS)

Set up your Cost of Goods Sold Accounting Flexfield combination (COGS Account) in Oracle Inventory. This step is required if you plan on utilizing the functionality surrounding COGS.

Step 24: Processing Constraints

Define processing constraints to prevent users from adding updating, deleting,
splitting lines, and cancelling order or return information beyond certain points in your order cycles. Use the constraints Order Management provides, which prevent data integrity violations, or create your own. This step is optional. Several default values for processing constraints have been defined.

Step 25: Defaulting Rules

Define defaulting rules to determine the source and prioritization for defaulting
order information to reduce the amount of information you must enter manually in the Sales Orders window. This step is optional. Several Defaulting rules and corresponding values for have been defined.

Step 26: Credit Checking

Define your credit checking rules. This step is required if you plan on performing any type of order credit checking.

Step 27: Holds

Define automatic holds to apply to orders and returns. This step is required if you plan on performing automatic hold for orders or returns.

Step 28: Attachments

Define standard documents to attach automatically to orders and returns. This step is optional.

Step 29: Freight Charges and Carriers

Define freight charges and freight carriers to specify on orders. This step is required if you plan on charging customers for freight or additional order charges.

Step 30: Shipping

Define shipping parameters in Oracle Shipping Execution. This step is required.

Step 1 Flexfields. (Required)
Step 2 Multiple Organizations. MOAC (Required)
Step 3 Inventory Organizations. (Required)
Step 4 Profile Options. (Required)
Step 5 Shipping Parameters. (Required)
Step 6 Invoicing. (Required)
Step 7 Salespersons. (Required)
Step 8 Tax, Tax Categories. (Required)
Step 9 QuickCodes. (Required)
Step 10 Workflow. (Required)
Step 11 Document Sequences (Order Numbering) (Required)
Step 12 Order Import Sources. (Required)
Step 13 Units of Measure. (Required)
Step 14 Item Information. (Required)
Step 15 Define Items & Assign to Organization. (Required)
Step 16 Configurations. (Required)
Step 17 Pricing. (Required) 
Step 18 Customer Classes. (Required)
Step 19 Customers (Required)
Step 20 Item Cross References (Optional)
Step 21 Sourcing (Optional)
Step 22 Order Management Transaction Types (Order and Line Types) (Required)
Step 23 Cost of Goods Sold (COGS) (Required)
Step 24 Processing Constraints (Required)
Step 25 Defaulting Rules (Required)
Step 26 Credit Checking (Optional)
Step 27 Holds (Optional)
Step 28 Attachments (Optional)
Step 29 Freight Charges and Carriers (Required)
Step 30 Shipping (Required)
Step 31 Start Workflow Background Process (Optional)
Setp 32 Request set OM – AR Porting
ORDER MANAGEMENT Interview Questions
Q: What are the Process Constraints?
A: Processing Constraints allow Order Management users the ability to control changes to sales orders, at all stages of its order or line workflows to avoid data inconsistencies and audit problems.
Q: What is a Pick Slip Report?
A: Pick slip is a shipping document that the pickers use to locate items in the warehouse/ inventory to ship for an order.
Q: At what stage an order cannot be cancelled?
A: If the order is Pick Confirmed, it cannot be cancelled.
Q: When the order import program is run it validates and the errors occurred can be seen in?
A: Order Management Responsibility >Orders, Returns : Import Orders> Corrections
Q: What is the difference between purchase order (PO) and sales order?
A: Purchase Order: The document which is created and sent to supplier when we need to purchase something. (Buying)

Sales Order: The document which is created when customer places an order to buy something. (Selling)
Q: What are primary and secondary price lists?
A: Price list contains information on items and its prices. The pricing engine uses secondary price lists when it cannot determine the price for an item using the price list assigned to an order.
Q: Name some tables in shipping/order/move order/inventory?
A: WSH_DELIVERY_DETAILS,WSH_NEW_DELIVERIES, OE_ORDER_HEADERS_ALL, OE_ORDER_LINES_ALL, MTL_SYTEM_ITEMS_B, MTL_MATERIAL_TRANSACTIONS
Q: How is move order generated?
A: When the order is pick released.
Q: What is ONT stands for?
A: ORDER MANAGEMENT
Q: What does Back ordered mean in OM?
A: An unfulfilled customer order due to non-existence of the ordered items in the Inventory.
Q: What are picking rules?
A: A user-defined set of criteria to define the priorities Order Management uses when picking items out of finished goods inventory to ship to a customer. Picking rules are defined in Oracle Inventory.

Q: What is drop ship in OM?
A: A method of fulfilling sales orders by selling products without handling, stocking,or delivering them. The selling company buys a product from a supplier and has the supplier ship the product directly to customers.
Q: What are Defaulting Rules?
A: While creating the order,you can define defaulting rules so that the default values of the fields pop up automatically instead of typing all information.
Q: What are validation templates?
A: A validation template names a condition and defines the semantics of how to validate that condition. Validation templates can be used in the processing constraints framework to specify the constraining conditions for a given constraint.
Q: What are different Order Types?
A: Order Only, Mixed, RMA

Q: Explain the Order Cycle?
A: Book the order
Pick Release
Pick Confirm
Ship Confirm
Close the order
Q: What is packing slip?
A: An external shipping document that is sent along with a shipment itemizing in detail the contents of that shipment.
Q: When an order cannot be deleted?
A: Order cannot be delted if the Order is Pick Confirmed.
Q: What is pick slip?
A: Pick slip is a shipping document that the pickers use to locate items in the warehouse/ inventory to ship for an order.

Q: What is Drop shipment?
A: Drop Shipment is a process where the customer places a purchase order on a company and this company instructs its supplier to directly ship the items to the customer.