Navigate to Tools (Menu bar at top of Internet Explorer) > Internet Options > Security Tab.
If we will try to approve the PO in the form , then we will receive the following Error.
“Error: Line #1 Schedule # 1: The consigned setting on the shipment line does not match the consigned attribute on the ASL. The shipment line must be deleted and re-entered.”
The reason why the system is throwing the error while approving the PO is:
Approved Supplier List (ASL) for the item has the “Consigned from Supplier Flag” checked, while the corresponding PO Shipments does not have the Consigned Flag checked.
If the ASL / Item is consigned enabled, the Consigned Attributes must be passed on to the PO Shipment Line for the error to suppress
To Approve the PO, we need to perform either of the following Option.
– Deselect the “Consigned from Supplier” checkbox for the ASL if Consigned Inventory is not desired for the Supplier. (Check for the consigned_from_supplier_flag in po_asl_attributes table)
OR
– Ensure the Consigned flag is checked on the PO Shipment. (consigned_flag in po_line_locations_all should be set to Y).
What is the Solution if we need to import Consigned Purchase Orders in Bulk into the system.
We can not manully go & approve the PO one by one after taking care of the above 2 points.
As Per Oracle;
Is it possible to use the consigned flag while importing Purchase Orders ? — No, This functionality is not yet available.
Enhancement Request Bug 4261977 has been opened to request that this functionality and to be considered for inclusion in future versions of the application
Workaround which can be used to Import Consigned Purchase Orders:
There are several ways to resolve this, depending on how you want the order to progress:
A. If you want to ship the delivery lines , do the following:
1. Query the Order in Shipping Transaction form
2. Navigate to Delivery tab. From the Actions button, choose Reopen Delivery>Go. Re-query order to confirm Delivery status is now “Open”.
3. From the Actions button again, choose Unassign Trip>Go
4. Re-query order to confirm the Trip has been removed, then from the Actions button again, choose Confirm Order>Go
5. Enter required information (such as Ship Method, quantity, Inventory Control)
6. Confirm the Order as usual.
B. If you want to cancel the order or order line, the delivery must be closed to do this, so do the following:
1. Query the Order in Shipping Transaction form
2. Navigate to Delivery tab. From the Actions button, choose Reopen Delivery>Go. Re-query order to confirm Delivery status is now “Open”.
3. From the Actions button again, choose Unassign Trip>Go
4. Once the Trip is removed, navigate to Delivery Line tab and remove the Shipped Quantity.
5. Once the Shipped Quantity field is null, go back to Delivery tab>then Actions button, choose Confirm Order>Go
6. Choose the Backorder All.
7. Once the delivery is closed and delivery lines are in backordered status, then navigate to Sales Order and cancel as needed.
C. To close a stop manually please follow steps below: To implement the solution, please execute the following steps:: You will need to manually close the stops
1. On the test instance, please click on the Path by Stop tab and manually close all of
the sequences:
Query order on Shipping Transaction form > Path by Stop tab > Actions > Update
Stop Status >Close
Also be sure to check the ‘Defer Interface’ checkbox on the form.
2. Then submit the Interface Trip Stop – SRS program
3. The line should now progress to ‘Interfaced’.
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.
===========================================================================
PROBLEM DESCRIPTION
===========================================================================
** DESCRIPTION OF PROBLEM, INCLUDING ALL ERRORS:
There is no column that accepts the value for match_option (invoice
matching 'P'or'R') in PO_LINES_INTERFACE. (The enhanced PDOI now supports
standard PO import.) If there is a method to populate the matching
option value via the PDOI, it should be documented in the PDOI update
release note. "matching option" is stored in the following table in EBS.
PO_LINE_LOCATIONS_ALL.MATCH_OPTION
===========================================================================
ADDITIONAL DETAILS
===========================================================================
** TAR NUMBER (ALSO ENSURE BUG NUMBER FIELD IS UPDATED IN TAR):
** LIST ADDITIONAL DOCUMENTATION AVAILABLE (LOG FILE, REPORT, TRACE, ETC.):
N/A
** HOW WILL DEVELOPMENT RECEIVE THE ADDITIONAL DOCUMENTATION?:
Via Email or ess30 upon request.
** DESCRIBE ANY WORKAROUND(S) AVAILABLE TO THE CUSTOMER:
Open POXPOEPO and update the option for all imported POs, which is rediculous.
** LIST NAME & VERSION OF ALL MODULES INVOLVED (FORM,REPORT,PACKAGE,ETC.):
EBS 11.5.3
Please ask if you need specific file versions.
** IS THE PROBLEM OCCURRING IN TEST OR PRODUCTION?
Production.
** DOES THE CUSTOMER HAVE ANY CUSTOMIZATIONS OR 3RD PARTY PRODUCTS?
No.
===========================================================================
HISTORY
===========================================================================
** WAS THE CUSTOMER ABLE TO COMPLETE THE SAME PROCESS PREVIOUSLY?:
No.
** LIST PATCHES APPLIED RECENTLY WHICH COULD AFFECT THIS PROBLEM:
N/ADefaulting of match_option is as follows
1. From Supplier Site
2. From Supplier
3. From Financials System Parameters
The HLD for STD PO do not mention anything about this column.
Will be an ER to create the column in CASE and to add the necessary
validations.PREMCOR REFINING GROUP is requesting this ER be changed to a priority 3 bug so
a fix can be included in a future PO Family Pack. They have 100's of PO's
that they import from a 3rd party system (Maximo) using the PDOI. These
multi-line POs are primarily Service Type POs and whether the line can either
be Invoice Match Option to Receipt or Invoice Match Option to Purchase Order
needs to be controlled at the Line level when inserting into the PO Interface
tables.
Here is the solution for the invoice matching, someone needs to update the
bug to include this solution:
Invoice matching, populate the following columns in PO_LINES_INTERFACE table:
'2WAY' inspection_required_flag = 'N'
receipt_required_flag = 'N'
'3WAY' inspection_required_flag = 'N'
receipt_required_flag = 'Y'
'4WAY' inspection_required_flag = 'Y'
receipt_required_flag = 'Y'
Recent Comments