Monday, September 17, 2012

INV: Transaction impact Profile option with List of Transaction Types - Date Validation

    Below is the list of transactions on which the profile has a control:-
  • Sales order staging transfer
  • Move order issue
  • Move order sub transfer
  • Account receipt
  • Account alias issues
  • Account alias receipts
  • Internal order subinventory transfer
  • Internal order direct organization transfer
  • Internal order staging transfer
  • Cycle count adjustments
  • Physical inventory adjustment
  • Inventory subinventory transfer
  • Inventory direct organization transfer
  • Miscellaneous issue
  • Miscellaneous receipt
  • Inter–project Borrow
  • Inter–project Payback
  • Inter–project Transfer

    Below is the list of transactions on which the profile does not have a control:-
  • Purchase order receipt
  • Return to supplier from stores
  • Purchase order delivery adjustment
  • Sales order issue Profile has no impact
  • WIP assembly return
  • WIP cost update
  • WIP component issue
  • WIP component return
  • WIP assembly completion
  • WIP assembly scrap
  • Internal requisition intransit receipt
  • Internal requisition delivery adjustment
  • Internal order issue

    Creation of Internal Order as such is not controlled by this profile:-
  • Standard cost update
  • Receipt of customer return
  • Rejection of customer returns
  • Inventory intransit receipt
  • Inventory delivery adjustment
  • Update layer cost
  • Average cost update
  • WIP negative component issue
  • WIP negative component return

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

Why receivable transaction workbench is showing LE name instead of OU name

Receivables:

All Receivables activity must have a legal owner, so Legal Entity is stamped on every transaction. Receivables activity such as transaction whether credit memo or debit memo or invoice must have stamps on it and receipt header with the Legal Entity information.

Because there can be multiple legal entities using the same ledger, it may be necessary for the user to assign the LE. Each transaction can only belong to one Legal Entity, so when multiple legal entities exist, either the system or the user will assign the LE.

Transaction

The defaulting hierarchy for a transaction comes from the setup of the Transaction Type and Transaction Batch Source. Receivables will look first to the Transaction type. If a LE has not been assigned, then Receivables will look to the Batch Source. The assignment of the LE to the Transaction Type and Transaction Batch Source is option, so if Receivables cannot find a default LE, then it is up to the user to provide the LE value.

Payable

Invoices and Payments indicate the operating unit and the legal entity owner of the transaction. The legal entity can be used as selection criteria when preparing pay runs.

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.

Creating a Custom Top in Applications Oracle Release R12:

  Custom Tops are required if you are creating new forms, reports, workflows, OAF pages etc. This allows you to segregate your custom written files from the standard seeded functionality that Oracle Applications provide. Customizations can therefore be preserved when applying patches or upgrades to your environment.
Step By Step Guide to Creating a Custom Application in Oracle Release R12 :
1) Make the directory structure for Custom Pages Top.
cd $JAVA_TOP
cd classes
mkdir classes/xx_hr
mkdir classes/xx_ums
mkdir classes/xx_ums/oracle/apps/
mkdir classes/ xx_ums/oracle/apps/
2) Make the directory structure for Custom Forms and Reports Custom top.
cd $APPL_TOP
mkdir appl/xx_hr
mkdir appl/xx_ums
3) Add the custom module into the environment
Apply ADX.E.1 and add the entry to topfile.txt as a standard product top entry (follow the existing model in the file) Customised environment variables can be added to AutoConfig by using the filename specificed by s_custom_file, which is then called from the APPSORA.env file. If using Forms Listener Servlet, you may also need to add $CUSTOM_TOP to formsservlet.ini in $APACHE_TOP/Jserv/etc
4) Create new tablespace for database objects
create tablespace xx_ums datafile '/emea/oracle/visuk09/visuk09data/xx_ums .dbf' size 10M default storage(initial 10k next 10k)
5) Create schema
create user xx_ums identified by xx_ums
default tablespace xx_ums
temporary tablespace temp
quota unlimited on xx_ums
quota unlimited on temp;
grant connect, resource to xx_ums;
6) Register your Oracle Schema.
Login to Applications with System Administrator responsibility Navigate to Application-->Register
Application = xx_ums Custom
Short Name = xx_ums
Basepath = xx_ums_TOP
Description = xx_ums Custom Application
7) Register Oracle User
Navigate to Security-->Oracle-->Register
Database User Name = xx_ums
Password = xx_ums
Privilege = Enabled
Install Group = 0
Description = xx_ums Custom Application User
8) Add Application to a Data Group
Navigate to Security-->Oracle-->DataGroup
Data Group = xx_ums Group
Description = xx_ums Custom Data Group
Click on "Copy Applications from" and pick Standard data Group, then add the following entry.
Application = xx_ums Custom
Oracle ID = APPS
Description = xx_ums Custom Application
9) Create custom request group
This will act as a placeholder for any custom reports we wish to make available for the Custom Responsibility (which is defined at a later stage)Navigate to Security-->responsibility-->Request
Group= xx_ums Request Group
Application = xx_ums Custom
Code= xx_ums
Description = xx_ums Custom Requests
We will not define any requests to add to the group at this stage, but you can add some now if required.
10) Create custom menu
This will act as a placeholder for any menu items we wish to make available for the Custom Responsibility (which is defined at a later stage) We will create two menus, one for Core Applications and one for Self Service. Navigate to Application-->Menu Menu= xx_ums_CUSTOM_MENU
User Menu Name = xx_ums Custom Application
Menu Type =
Description= xx_ums Custom Application Menu
Seq= 100
Prompt= View Requests
Submenu=
Function = View All Concurrent Requests
Description = View Requests

Seq= 110
Prompt= Run Requests
Submenu=
Function= Requests: Submit
Description = Submit Requests

Menu= xx_ums_CUSTOM_MENU_SSWA
User Menu Name = xx_ums Custom Application SSWA
Menu Type=
Description = xx_ums Custom Application Menu for SSWA
11) Create new responsibility.
One for Core Applications and One for Self Service (SSWA) Navigate to Security-->Responsibility-->Define
Responsibility Name= xx_ums Custom
Application= xx_ums Custom
Responsibility Key = xx_ums CUSTOM
Description= xx_ums Custom Responsibility
Available From= Oracle Applications
Data Group Name= xx_ums Group
Data Group Application = xx_ums Custom
Menu= xx_ums Custom Application
Request Group Name= xx_ums Request Group

Responsibility Name= xx_ums Custom SSWA
Application= xx_ums Custom
Responsibility Key = xx_ums CUSTOMSSWA
Description = xx_ums Custom Responsibility SSWA
Available From= Oracle Self Service Web Applications
Data Group Name= xx_ums Group
Data Group Application = xx_ums Custom
Menu= xx_ums Custom Application SSWA
Request Group Name= xx_ums Request Group
12) Add responsibility to user
Navigate to Security-->User-->DefineAdd xx_ums Custom responsibility to users as required.
13) Other considerations
You are now ready to create your database Objects, custom Reports, Forms, Packages, etc Create the source code files in the xx_ums _TOP directory appropriate for the type of object. For example forms would be located in
$xx_ums_TOP/forms/US or package source code in
$xx_ums_TOP/admin/sql for example. Database Objects, such as tables, indexes and sequences should be created in the xx_ums schema, then you need to
a) Grant all privilege from each custom data object to the APPS schema.
For example: logged in as xx_ums user
grant all privileges on myTable to apps;
b) Create a synonym in APPS for each custom data object
For example: logged in as APPS user
Create synonym myTable for xx_ums.myTable; Other database objects, such as views and packages should be created directly in the APPS schema.

Reservation Type : mtl_supply_demand_source_type

------------------MTL_DEMAND_SOURCE_TYPE---------------------
---------------------------------------------------------------------------------

select LOOKUP_TYPE, LOOKUP_CODE, MEANING
from apps.MFG_LOOKUPS
where LOOKUP_TYPE like 'MTL_SUPPLY_DEMAND_SOURCE_TYPE'
order by LOOKUP_TYPE, LOOKUP_CODE;

Output from Backend (Toad)




 Lookup Codes

LOOKUP_TYPE LOOKUP_CODE MEANING
MTL_SUPPLY_DEMAND_SOURCE_TYPE 1 Purchase order
MTL_SUPPLY_DEMAND_SOURCE_TYPE 2 Sales order
MTL_SUPPLY_DEMAND_SOURCE_TYPE 3 Account number
MTL_SUPPLY_DEMAND_SOURCE_TYPE 4 WIP repetitive schedule
MTL_SUPPLY_DEMAND_SOURCE_TYPE 5 WIP discrete job
MTL_SUPPLY_DEMAND_SOURCE_TYPE 6 Account alias
MTL_SUPPLY_DEMAND_SOURCE_TYPE 7 WIP nonstandard job
MTL_SUPPLY_DEMAND_SOURCE_TYPE 8 Onhand quantity
MTL_SUPPLY_DEMAND_SOURCE_TYPE 9 Reserved sales order
MTL_SUPPLY_DEMAND_SOURCE_TYPE 10 Reserved account number
MTL_SUPPLY_DEMAND_SOURCE_TYPE 11 Reserved account alias
MTL_SUPPLY_DEMAND_SOURCE_TYPE 12 Intransit receipt
MTL_SUPPLY_DEMAND_SOURCE_TYPE 13 Discrete MPS
MTL_SUPPLY_DEMAND_SOURCE_TYPE 14 Repetitive MPS
MTL_SUPPLY_DEMAND_SOURCE_TYPE 15 Onhand reservation
MTL_SUPPLY_DEMAND_SOURCE_TYPE 16 User supply
MTL_SUPPLY_DEMAND_SOURCE_TYPE 17 User demand
MTL_SUPPLY_DEMAND_SOURCE_TYPE 18 PO requisition
MTL_SUPPLY_DEMAND_SOURCE_TYPE 19 Reserved user source
MTL_SUPPLY_DEMAND_SOURCE_TYPE 20 Internal requisition
MTL_SUPPLY_DEMAND_SOURCE_TYPE 21 Internal order
MTL_SUPPLY_DEMAND_SOURCE_TYPE 22 Reserved internal order
MTL_SUPPLY_DEMAND_SOURCE_TYPE 23 WIP Supply Reservation
MTL_SUPPLY_DEMAND_SOURCE_TYPE 24 Flow Schedule
MTL_SUPPLY_DEMAND_SOURCE_TYPE 30 Cycle Count Reservation
MTL_SUPPLY_DEMAND_SOURCE_TYPE 31 Purchasing Supply Reservation
MTL_SUPPLY_DEMAND_SOURCE_TYPE 32 Move Order Demand
MTL_SUPPLY_DEMAND_SOURCE_TYPE 33 Move Order Allocation
MTL_SUPPLY_DEMAND_SOURCE_TYPE 34 Move Order Supply

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