Showing posts with label Oracle EBS Order Management. Show all posts
Showing posts with label Oracle EBS Order Management. Show all posts

Tuesday, September 17, 2019

Reasons for a Sales Order to get Backordered

A Sales Order can get into backorder state after performing Pick Release on a Sales Order but there are many reasons for a Sales Order to get backorder.

1.         Order on Hold
2.         Inventory Period NOT open
3.         No enough on-hand quantity
4.         No enough quantity to reserve/transact
5.         No on-hand quantity in required sub-inventory
6.         The Lot from which items are selected is inactive/expired
7.         Lot control Item Lot Divisible Option not enabled
8.         Specified Lot is Disallowed Transaction (Applied on Material Status)
9.         Item On-Hand to Disallowed Transaction (Applied on Material Status)
10.      Wrong Item reservation (even inventory have enough quantity)
11.      Inventory reserved for other sales orders
12.      Inventory picked-up by other sales orders
13.      Previously done return to stock not properly performed
14.      Cycle Count Adjustments
15.      Serial Control Item Serial number not allocated or not assigned 
16.      Manually Backordered 
17.      Move order is in pending state 

NOTE: There will be many reasons for a sales order to get backorder as of now found these many reasons.


Please provide your valuable feedback ............

Wednesday, June 12, 2013

How to Purge Sale Order Records in Order Management

Details

Purging old data creates space in your database and can improve performance of transactions and maintenance. Please check with your planner in regards to how much sales order history is needed for forecasting within your Company, before setting this up.

The Purge Orders concurrent program enables you to purge selected closed orders and their workflow history. You first determine which orders you wish to purge by creating a Purge Set. Once orders have been selected for purging within a purge set, you can then choose to purge the entire set, a subset of the Purge set, or to cancel the purge. Details for how to set this up are outlined below.

Purge Restrictions

Orders can only be purged if they meet the following conditions:
  • Orders must be closed.
  • No open demand exist for orders, open work orders, open invoices, open returns, and open requisitions.
Order Tables Purged by Order Purge Concurrent Program
The following Order Management tables are purged of selected order data,
dependent upon the input parameters and a successful submission of the Order
Purge concurrent program.
  1. OE_HOLD_RELEASES
  2. OE_HOLD_SOURCES
  3. OE_LINE_SETS
  4. OE_LOT_SERIAL_NUMBERS
  5. OE_ORDER_HEADERS_ALL
  6. OE_ORDER_HOLDS
  7. OE_ORDER_LINES_ALL
  8. OE_PRICE_ADJ_ATTRIBS
  9. OE_PRICE_ADJ_ASSOCS
  10. OE_PRICE_ADJUSTMENTS
  11. OE_SETS
  12. OE_SALES_CREDITS
  13. Additionally, Oracle Foundations (FND) tables will be purged of any attachments for orders selected for purging by the Order Purge concurrent program.

Purge Set Creation

A purge set is a set which will contain orders to be purged based upon user specified criteria. Purge set can be created in the two following ways: 

  • Purge Set Creation using the Create Purge Set Concurrent Program
  • Multi-selection of orders within the Order Organizer window and then invoking the Create Purge Set Concurrent Program from the Tools Menu. Purge Set Creation using the Create Purge Set Concurrent Program

To create a purge set by specifying the where (selection) condition:

1. Navigate to the Order Purge Selection concurrent Program
OM > Orders, Returns > Purge > Order Purge Selection
2. Within the Purge Set name field, enter a unique name to identify the purge set.
3. Within the Purge Set Description, enter a description for your purge set.
4. Optionally, determine if you wish to purge a single order number or range of order numbers, by entering values for Order Number Low, Order Number High, or both input parameters. All orders created within the range entered will be selected for purging, provided other input parameters also enable purging.
5. Optionally, determine if you wish to purge orders for a specific Order Type by selecting a value in the Order Type input parameter. All orders created that utilize the Order Type selected will be purged, provided other input parameters also enable purging.
6. Optionally, determine if you wish to purge orders for a specific Order category by selecting a value in the Order Category input parameter. All orders created that utilize the Order Category selected will be purged, provided other input parameters also enable purging.
7. Optionally, determine if you wish to purge orders for a specific Customer Name by selecting a Customer Name in the Customer Name input parameter, provided other input parameters also enable purging.
8. Optionally, determine if you wish to purge orders created on a specific date or range of dates by selecting a value for the Creation Date Low, the Creation Date Order Purge / Order Purge Selection Concurrent Programs High, or both input parameters. All orders created for the date range specified are selected within the purge set, irrespective of the current order status.
9. Click Submit.












Purge Set Creation by multi-selection


Create a purge set by selecting multi-selecting orders within the Order Organizer, and then, from the menu, selecting Tools, Purge, Purge Set.
1. Enter the Purge Set name and a description for the purge set.
2. Click Submit to create a purge set with all the records (orders) you have selected within the Order Organizer.

To Submit the purge Request

Navigate to the Order Purge window
OM > Orders, Returns > Purge > Purge Set
Query by Purge Set name.
Purge sets can be submitted for purge, exclude certain orders within the set from being purged, or
completely deleted (provided the records have been previously purged).



















To View Process Exceptions
If the selection criteria includes orders that do not meet the purge restrictions (order is not closed, outstanding reservations exist, etc.) or if the purge process encounters an issue, a process error occurs. These errors can be viewed by viewing the purge set within the Order Purge window. Navigate to the Order Purge window is:
OM > Orders, Returns > Purge > Purge Set

For example, suppose when submitting the Order Purge Selection concurrent program a user specified all orders for customer Business World. When you navigate to the Order Purge window, you may find certain orders were ineligible for purge, and have been marked as such (within error column, a note would display the order is not closed, and the Purge Eligible check box is not enabled).

Tuesday, October 09, 2012

Parallel Pick Release in Oracle Shipping - R12 New Feature

Oracle has introduced lots of features in R12 (e-business Suite). 
It includes Parallel Pick Release:

With this feature user can now run the Pick Release processes in parallel and improve the over all performance.

Advantages:

One of Key Advantage of with Parallel Processing of the Pick release process is user can apply /engage additional (if available) resources to process the Pick release data that was previously process by 1 process only and hence save lot of time by submitting this process in Parallel.

Following are the changes made for this feature:
  • A new Parameter (No. Of Child Processes) has introduced in Pick release Concurrent Program.
  • A new profile option (WSH: No. Of pick release child processes) has introduced , it indicate how many child processes you want to spawn.

Note: If we run the Pick release from in Online Mode or Public API (online mode) then only 1 child processes to be spawned ( as good as existing behavior).

Some Constraints -

Irrespective of the parameter value and the profile option only 1 child process will be spawned if
1. Auto Create Delivery = Y and print Pick Slip is set as Immediate
2. Auto Create Delivery = Y and Delivery is enabled as Pick slip Grouping rule.

Setup

WSH: No. Of pick release child processes.
If value of this profile option is Null or 1 then only 1 Child Process will be submitted.
If value of this profile option is > = 2 (2 to 'n') then 'n' no. of Child Process will be submitted for Pick release ( some restriction applied , as discussed below).

By setting this profile option to any value doesn’t mean system will spawned that many child process. The # of child process spawned depend upon this profile option as well as the Unique item in the data SELECTED for the pick release.

Or more precisely we say No. of child process available for Pick release depend on the # of unique “Item and Organization “ combination.

Concurrent Program:

As explained earlier a new Parameter (No. of Child Processes) has been introduced in concurrent Program “ Pick Selection List Generation – SRS”. 





No. of child processes spawned are depend on the value you enter in this parameter , and by default value from the Profile option “WSH: No. of pick release child processes” defaulted for this parameter , but here we have advantage to overwrite the value of profile.


Note - # of pick slip reports not depend on this profile options, they still depend on the pick slip Grouping rules.

Other Considerations:
  • If we submit the pick release process from the Shipping Transaction UI, then only 1 process will be launch, parallel Pick release will not applicable, but if we launch the Pick Release process from Shipping transaction UI , Tools > then the Parallel Pick release Process will work fine.
  • In SRS window, all the child process will carry the Parent Request ID of the parent.
----------------End--------------

Thursday, September 27, 2012

Soft Reservation and Hard Reservation in Oracle Sales Order

By definition "Soft Reservation"

  • Sales order demand is a soft reservation.
  • When you are entering sales order go to tools and check the "reserve" that is soft reservation.
  • In Planning parameter form not enabled the check box Net reservation, the planning process considers all Sales Order demand as soft reservation.
  
"Hard Reservation"

  • Hard reservation is sales order demand that you *firm * by reserving selected inventory for the purposes of material planning.
  • Available to promise (ATP) calculations and customer service issues. 
  • In the planning parameter form whenever you enable the check box  Net reservations, the planning process satisfy hard reservation demand before soft reservations.
  • Further we have to set Pegging Method under MPS/MRP planning tab.
  • If the order is pick released for the customer that is hard release.

 -------------------------------------------

Monday, September 10, 2012

R12 : Deferred COGS Accounting Functionality

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 is no deferred COGS.



COGS is now directly matched to the Revenue
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.


SETUP and ACCOUNTING :

Advanced Accounting setup:

Nav:Inventory → Setup → Organization Intercompany Transaction Flow

Enter the Start and End Operating Unit (From Org and To Org) then choose type Shipping/Procuring and Start date.
bottom nodes block From Organization and To Organization (B) →Intercompany relations 
1. AR Invoicing for shipping - Customer with Location
2.AP Invoicing for selling     - Supplier with Site

To set the deferred COGS account.
Nav: Inv → 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 recognized, 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 to run the COGS recognition request :
Nav: Cost → COGS Recognition → Collect Revenue Recognition Information
Nav: Cost
COGS RecognitionGenerate COGS Recognition Events
Nav: Cost
View TransactionsMaterial 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 :
Nav: Cost
View TransactionsMaterial TransactionsDistributions

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 )

How To Transfer Deferred COGS To Actual COGS Account For Ship Only Business

1. In ship only flows the 'Close Line' activity will raise an costing event to transfer the amount from DCOGS to COGS as there is no AR intergartion.
 

2.1. No,when the line gets closed the 'Close Line' activity will raise an costing event to transfer the amount from DCOGS to COGS.

2.2. - It is done line by line not order by order.

Please run the following concurrent request to move DCOGS to COGS.
Nav: Cost
COGS RecognitionCollect Revenue Recognition Information
Nav: Cost
COGS RecognitionGenerate COGS Recognition Events
Nav: Cost
View TransactionsMaterial Transactions

Tuesday, September 04, 2012

OM/AR Separation of Duties Workaround - White Paper

Abstract

In order to implement a best practice internal control for Credit Hold Release, a proper separation of duties between Accounts Receivable and Order Management is required.
  • Accounts Receivable (AR) should be able to manually release Credit Sales Order Holds without being able to directly modify a Sales Order.
  • Order Management (OM) should not be able to release a Sales Order from Credit Holds applied by AR.
Enhancement request 3241406 was logged to address this issue and was approved for Future Release by Development. The enhancement request actually identifies three specific issues. This white paper defines workarounds for each of these issues.
The issues identified in the enhancement request are:
1. Customer Master Credit Hold Flag / Credit Check Flag Access
Both AR and OM have access to the Customer Master, which means that they both have access to the Credit Hold Flag and the Credit Check Flag.
· When the Credit Hold Flag is checked, it automatically places all applicable Sales Orders on Credit Hold.
· When the Credit Hold Flag is unchecked, it automatically removes the Credit Hold from all applicable Sales Orders.
· When the Credit Check Flag is checked it triggers automatic Credit Check audit processing against Sales Orders based on Credit Profile amounts.
· When the Credit Check Flag is unchecked, it assumes an unlimited Credit Transactional Profile amount.
2. Manual Credit Check Failure Sales Order Hold Release
When the credit check flag is checked, Sales Orders are automatically validated against Credit Profile Transaction amounts that are set and maintained by AR.
When the customer credit balance exceeds the credit profile transaction amount, the Sales Order will automatically be placed on Credit Check Failure Hold. This Hold can be manually released on the Sales Order Organizer – an OM Form.
3. OM Holds Setup Configuration
All Sales Order holds are configured in Order Management, including the Credit check Failure hold.
Standard Oracle Applications functionality is utilized in the workarounds defined for each of these issues.

Issue 1: Customer Master Credit Hold Flag / Credit Check Flag Access


As described in the abstract, when AR and OM have full access to the Customer Master, they both have access to the Credit Profile information for the customer. The goal of this workaround is to prevent access from OM while enabling the access for AR.
Workaround Detail
A best practice solution for preventing full access to the Customer Master Credit Profile information by both OM and AR is to restrict the OM users’ access via Menu Exclusion configuration changes.
Specific Menu exclusions would be applied only to the OM User Responsibility from access to the customer profile information tabs on the Customer Master. This is accomplished by adding two Functions to the Responsibility Menu Exclusion:
  • Customers: Profile
  • Customers: Address Profile
Once this exclusion has been performed, the OM User Responsibility will still have access to the Customer Master. However, regardless of which Customer Master access is chosen (Customers Standard, Quick, Summary, Add Customer from the Sales Order screen), the Credit Management Profile Tabs (Profile: Transaction, Profile: Document Printing and Profile: Amounts) will be grayed out and the user will not be able to see or change the information on these tabs. This is true at both the Customer “header” and the Customer “address” level.

Issue 2: Manual Credit Check Failure Sales Order Hold Release

The functional authority to remove Credit Check Failure Sales Order holds manually lies with the Credit Management (typically AR) area of a business. The functional authority to create, modify and delete Sales Orders lies with the Order Management area of a business.
Currently, Credit Check Failures holds applied to a sales order can only be manually released using the “Remove Hold” functionality designed in the Sales Order screen in Oracle. The problem is that the AR Department requires access to the Sales Order screen to remove these holds, which also gives them the ability to create, modify and delete Sales Orders.
The goal of this workaround is provide AR users access to the Sales Order screen that will allow them to review the order and release the Credit Check Failure holds while at the same time, disabling the ability to create, modify and delete Sales Orders.

Workaround Summary
A best practice solution for providing a limited access to the Sales Order Screen to personnel with Credit Management responsibility is to limit their access to the Sales Order Screen via custom Responsibility configuration.
The complete solution for the configuration of the Custom Responsibility uses all standard Oracle functionality and is summarized in the following activities:
1. Create a Custom Menu for a scaled down version of the Order Organizer that only has 'add in' function access to Remove Holds.
2. Create a Custom Responsibility which points to the new Custom Menu, thus restricting the access to the new Order Organizer – Lite
3. Define additional OM Setup Security 'Processing Constraints' that prevent Create, Modify and Delete access for the new Custom Responsibility
4. Configure the OM Setup Order Hold Release assess so that only the new Custom Responsibility can Release the seeded Credit Check Failure Hold
Workaround Detail
Step 1 : Create A Custom Menu for a scaled down version of the Order Organizer called 'Order Organizer - Lite'
The custom menu provides a limited access to the Order Organizer and Release Holds function found in the Action Button of the Order Organizer.
The table layout detailed below defines:
· the responsibility used to create the new menu along with the navigation path
· the menu definition screen field (required) configuration values for the new menu


Step 2: Create a Custom Responsibility which points to the new Custom Menu.
The custom responsibility detailed below provides a limited access to the Order Organizer and Release Holds function within the Order Organizer without additional menu exclusions.
The table layouts detailed below defines:
· the responsibility used to create the new responsibility along with the navigation path
· the responsibility definition screen required field configuration values for the new responsibility:
Custom Responsibility Configuration Requirements:
Responsibility
System Administrator
Navigation
Security > Responsibility > Define
Responsibility
Custom Credit Hold Management
Application
Oracle Order Management
Key
Custom Credit Hold Management
Description
Custom Credit Hold Management
Menu
Custom Credit Hold Management
Data
Standard Oracle Order Management
Request
n/a
Exclusions
n/a
Note : The creation of a custom responsibility is not required but allows for more clearly identified access within an organization. An alternative would be to add the new menu to an existing Credit Management responsibility menu as a submenu item
Step 3 : Define additional OM Setup Security 'Processing Constraints' that prevent Create, Modify and Delete access for the new Custom Responsibility
The custom responsibility created in step 2 will be used in the OM Processing Constraints Security configuration to prevent “change” access to Sales Orders. The table layouts detailed in the Configuration Requirements defines
· the responsibility used to create the new OM Setup Security Processing Constraints, along with the navigation path
· the parent / child Processing Constraint definition screen required field configuration values for the security configurations:
The OM Setup Security Processing Constraint Requirements are listed below, in the order they should be performed. Because the requirements are extensive and are in a tabular format, each step contains a link to display the detailed information. For all steps, use the following responsibility and navigation:
Responsibility
Order Management Super User
Navigation
Setup > Rules > Security > Processing Constraints
Step 4 : Configure the OM Setup Order Hold Release assess so that only the new Custom Responsibility can release the seeded Credit Check Failure Hold
The configuration access for the authority to apply and remove Sales Order holds is found in the OM Setup Order Holds screen. Sales Order Holds are manually “applied and removed” or are “automatically applied”. In turn, they are manually or automatically removed. The Credit Check Failure hold is “seeded” or pre-configured to be automatically applied but is not configured with a responsibility assignment to “release” the hold.
When this configuration is left blank, anyone with access to release holds on the Order Organizer can release this key financial hold. This workaround details the requirements to ensure that only the new Custom Credit Management responsibility created in step 2 will have the authority to release the Credit Check Failure Hold.
The table layouts detailed below define:
· the responsibility used to configure the OM Order Hold access along with the navigation path
· the Order Hold definition screen required field configuration values
Responsibility
Order Management Super User
Navigation
Setup > Orders > Holds
Order Hold definition screen required field configuration values:
Name
Credit Check Failure
Description
This hold is automatically placed on an order invoiced to a customer who fails credit check
Type
Credit Check
Responsibility
Authorization Action
Effective From
Effective To
CUSTOM CREDIT MANAGEMENT
Remove Hold
[today's date]
leave blank
As mentioned above, when an Order Hold Responsibility Authorization is left blank, anyone with Release Hold access to the Order Organizer can release the hold. This workaround assumes that all other active holds have been aligned with a Responsibility assignment and an Authorization Action. This will limit the release hold access for the new responsibility specifically to the Credit Check Failure hold.

Issue 3: OM Order Hold Setup Access

When Order Management users have the authority to create sales orders and have the ability to setup, configure or determine which responsibilities have access to release the Credit Check Failure hold, there is a concern around separation of duties. The goal of this work around is to limit the access to the OM Hold Setup Access.
Workaround Detail
A best practice solution regarding access to Order Management setups is to use a common operational model for Order Management Responsibility rollout with an Oracle implementation that provides: 1)OM Super User Responsibility, 2) OM User Responsibility and 3) OM Inquiry Responsibility.
  • OM Super User Responsibility

    This is not a transactional responsibility; it is a setup / maintain / support responsibility for Oracle Order Management. This would be the only responsibility with access to the OM Setup Order Hold screen .
  • OM User Responsibility

    This responsibility would have the authority and access to create, modify and delete Sales Orders, along with all other transactional OM access.
  • OM Inquiry Responsibility

    This would be a very limited, view only and report only access to Order Management information.
With the OM Access defined as mentioned above, the issue is alleviated. An additional audit trail is also available in that Oracle captures the USERID of the person who releases the Sales Order Holds, along with the date it was released and a release reason. This information is stored with the sales order automatically when the hold is released and cannot be controlled/changed by the user.

Summary

This solution details one approach to separate the OM and AR duties associated with Credit Management using standard Oracle functionality.
The workaround detail is meant to describe one best practice approach. Variations on that approach could include the addition of Menu Items for the Credit Hold Management responsibility (Customer Master access, reports, more OM “View” Functions). Also, more detailed Processing Constraint Security could further enhance the solution.