- creates requisitions or purchase orders.
- authorizes the purchase of goods and services.
- receives goods or services.
Setting Up
Overview of Setting Up
This section contains an overview of each task you need to complete to set up Oracle Master Scheduling/MRP and Oracle Supply Chain Planning.
Before you set up , you should:
Related Product Setup Steps
Set Up Oracle Applications Technology
The setup steps in this chapter tell you how to implement the parts of Oracle Applications specific to.
You need to complete several setup steps, including:
Also, if your product uses Oracle Workflow to, for example, manage the approval of business documents or to derive Accounting Flexfield values via the Account Generator, you need to set up Oracle Workflow.
See also Oracle Applications System Administrator’s Guide and Oracle Workflow Guide
Oracle Inventory
Make sure you set up Inventory as described in Overview of Setting Up, Oracle Inventory User’s Guide. Ensure that all the following steps have been completed:
Oracle Purchasing
Make sure you set up Purchasing as described in Overview of Setting Up, Oracle Purchasing User’s Guide. Ensure that all the following steps have been completed:
Oracle Bills of Material
Make sure you set up Bills of Material as described in Overview of Setting Up, Oracle Bills of Material User’s Guide. In addition to the set up, ensure that all the following steps have been completed:
Oracle Work in Process
Make sure you set up Work in Process as described in Overview of Setting Up, Oracle Work in Process User’s Guide. Ensure that all the following optional steps have been completed:
Oracle Capacity
Make sure you set up Capacity as described in Overview of Setting Up, Oracle Capacity User’s Guide. Ensure that all the following optional steps have been completed:
Oracle Project Manufacturing
If you work in a project–based environment, perform the following additional steps to use Oracle Project Manufacturing:
See: Setting Up Project MRP in Oracle Inventory
Oracle Workflow
You can use the Enabled Exception Messages workflow to generate and distribute messages to those who are the contacts for specific job tasks in order to resolve problems. See: Setting Up Oracle Workflow, Oracle Workflow Guide.
Setup Checklist
Complete the following steps, in the order shown, to set up Oracle Master Scheduling/MRP and Oracle Supply Chain Planning:
Note: The Master Scheduling, MRP and Supply Chain Planning products use many of these steps in common, but steps 25 through 33 are only applicable to the Supply Chain Planning product.
Setup Checklist
|
||
Step
|
Required
|
Title
|
1
|
Required
|
Set Up System Administrator
|
2
|
Required
|
Set Up Key Flexfields
|
3
|
Required
|
Set Up Calendars, Currencies, and Set of Books
|
4
|
Required
|
Set Up Organizations
|
5
|
Optional
|
Set Up Supplier Planned Inventories
|
6
|
Optional
|
Define your Locations
|
7
|
Optional
|
Define your Employees
|
8
|
Required
|
Define your Planning Parameters
|
9
|
Optional
|
Define your Planning Exception Sets
|
10
|
Optional
|
Define your Demand Classes
|
11
|
Optional
|
Define your Planners
|
12
|
Optional
|
Define Source Lists
|
13
|
Required
|
Set Up Planner Workbench
|
14
|
Optional
|
Set Up Capacity
|
15
|
Required with Defaults
|
Set Profile Options
|
16
|
Optional
|
Define your Forecast Sets
|
17
|
Optional
|
Define Forecast Rules
|
18
|
Optional
|
Define your MDS Names
|
19
|
Optional
|
Load MDS
|
20
|
Optional
|
Define your MPS Names
|
21
|
Optional
|
Define MPS Options
|
22
|
Optional
|
Define your MRP Names
|
23
|
Optional
|
Define MRP Options
|
24
|
Optional
|
Set Up Workflow Options
|
25
|
Optional
|
Define Shipping Methods
|
26
|
Optional
|
Define In–transit Lead Times
|
27
|
Optional
|
Create your Assignment Sets
|
28
|
Optional
|
Define your Sourcing Rules or Bills of Distribution
|
29
|
Optional
|
Define your Inter-organization Shipping Network
|
30
|
Optional
|
Set Up Supply Chain ATP
|
31
|
Optional
|
Set Up Supply Chain CTP
|
32
|
Optional
|
Define your DRP Names
|
33
|
Optional
|
Define DRP Options
|
34
|
Required
|
Start the Planning Manager (Required)
|
35
|
Optional – Highly Recommended
|
Run the Information Audit
|
Setup Steps
Step 1 Set Up System Administrator (Required)
This step involves the following tasks:
Step 2 Set Up Key Flexfields (Required)
If you are, or will be, fully installing other applications, such as Oracle Human Resource Management or Oracle Inventory, be sure to coordinate with those products’ flexfield setup before defining the key flexfields here, as it is not recommended to change flexfields frequently. See: Oracle Applications Flexfields Guide.
For each key flexfield, you perform the following tasks, some of which are optional for some flexfields:
Note: Even if you do not use item catalogs, stock locators, or sales orders, you must still compile the respective flexfields because all Oracle Inventory transactions (such as the Define Items window), inquiries, and reports require a frozen flexfield definition. However, you do not need to configure the flexfield in a specific way.
Step 3 Set Up Calendars, Currencies, and Set of Books (Required)
If you have defined your calendars, currencies, and set of books while setting up a different Oracle Applications product, proceed to the next step. However, if you are performing a Multi-Org implementation of Oracle Master Scheduling/MRP and Oracle Supply Chain Planning, see the note below.
Context: If you are performing a Multi-Org implementation, you may optionally create more than one calendar, currency, or set of books. See: Multiple Organizations in Oracle Applications.
This step involves the following tasks:
Step 4 Set Up Organizations (Required)
You may not need to perform this step if you have already installed and set up Oracle Inventory or performed a common-applications setup.
For the following tasks relating to setting up organizations, see: Oracle Human Resources User’s Guide.
Step 5 Set up Supplier Planned Inventories (Optional)
For instructions on setting up for Supplier Planned Inventories, see the Prerequisites in: Supplier Planned Inventories.
Step 6 Define Locations (Required)
If you’re also setting up other Oracle applications, you may already have defined locations when you set up those applications.
In Oracle Purchasing, define locations for where you ship, deliver internally, or bill the goods and services you order. This is a necessary setup if you plan on importing purchase requisitions from the Planner Workbench into Oracle Purchasing. See: Setting Up Locations, Oracle Human Resources User’s Guide.
Step 7 Define your Employees (Optional)
If you do not install Oracle Human Resource Management Systems with Oracle Master Scheduling/MRP, you use the Enter Employee form to define and maintain employees in Oracle Master Scheduling/MRP. Otherwise, the forms in Oracle Human Resource Management Systems are used to enter and maintain employees.
Define every employee who:
This is a necessary setup if you plan on importing purchase requisitions from the Planner Workbench into Oracle Purchasing.
Step 8 Define your Master Scheduling / MRP Planning Parameters (Required)
You need to define different modes of operation and default values that affect other functions in Oracle Master Scheduling/MRP. If you manufacture your assemblies repetitively, you can also set up your repetitive item defaults. See: Defining Planning Parameters.
Step 9 Create your Planning Exception Sets (Optional)
You can define and update planning exception sets that you can use to identify items and orders that require attention based upon a set of predefined action messages. This facilitates control over message sensitivity, message priority, and marking those messages where action has been taken. See: Creating Planning Exception Sets
Step 10 Create your Demand Classes (Optional)
You can define and update demand classes to group similar customers, demand channels or sales order types. You can use demand classes as a means of forecasting and master scheduling different sources of demand separately. See: Creating Demand Classes.
Step 11 Define your Planners (Optional)
For instructions on defining your planners. See: Defining Planners.
Step 12 Create Source Lists (Optional)
For instructions on creating source lists. See: Creating Source Lists.
Step 13 Set up Planner Workbench (Required)
For instructions on setting up Planner Workbench, see: Setting Up Planner Workbench.
Step 14 Set up Capacity (Optional)
For instructions on setting up Oracle Capacity. See: Set Up Steps, Oracle Capacity User’s Guide.
Step 15 Set Profile Options (Required with Defaults)
Profile options specify how controls access to and processes data. In general, profile options can be set at one or more levels. System administrators use the Profile Options form to set profile options at the site, application, responsibility, and user levels.
Oracle Master Scheduling/MRP and Oracle Supply Chain Planning users use the Profile Options form to set profile options only at the user level. You can update your personal profile options if you want to override the defaults provided by Oracle Master Scheduling/MRP and Oracle Supply Chain Planning. Personal profiles allow you to control data access and processing options at the user level.
For more information about the profile options available in Oracle Master Scheduling/MRP and Oracle Supply Chain Planning, see: Oracle Master Scheduling/MRP and Oracle Supply Chain Planning Profile Options.
Step 16 Define your Forecast Sets (Optional)
You can define any number of forecast sets or names. This allows you to define any number of forecasts, including different types of forecasts, such as by customer or by item. For each forecast set, you can also specify the number of days that a sales order looks to consume the forecast and the minimum level of forecast information required to consume the forecast. See: Defining a Forecast Set
Step 17 Define your Forecast Rules (Optional)
You can define forecast rules to establish the forecast method, bucket type, and sources of demand that are considered when compiling statistical or focust forecasts. See: Defining a Forecast Rule, Oracle Inventory User’s Guide.
Step 18 Define your MDS Names (Optional)
Define any number of demand schedule names; this allows you to define multiple master demand schedules, each with a unique name. A master demand schedule is a statement of anticipated demand that you can use to create a master production schedule, or as direct input to a material requirements plan. For each master demand schedule name, you can also signify if sales order shipments relieve the schedule. See: Defining a Schedule Name.
Step 19 Load MDS (Optional)
For each type of master demand schedule load, you choose a number of load options. Not all options apply to all load types. See, Loading a Master Schedule from an Internal Source.
Step 20 Define your MPS Names (Optional)
Define any number of production schedule names; this allows you to define multiple master production schedules, each with a unique name. A master production schedule defines the anticipated build schedule for the product family members and other critical items. For each master production schedule name, you can also signify if the creation of jobs/repetitive schedules relieves the schedule. See: Defining a Schedule Name.
Step 21 Define MPS Options (Optional)
You can optionally include your MPS plan as available supply and get information on quantities that have been implemented as discrete jobs, purchase orders, or purchase requisitions. See: Defining a Schedule Name.
Step 22 Define your MRP Names (Optional)
Define any number of material requirements plan names. This allows you to generate multiple MRP plans, each with a unique name. A material requirements plan defines a set of recommendations to release or reschedule orders for material based on the net material demands. See: Defining MRP Names.
Step 23 Define MRP Options (Optional)
Material requirements planning (MRP) calculates net requirements from gross requirements by evaluating: the master schedule, bills of material, scheduled receipts, on–hand balances, and lead times. See: Overview of Material Requirements Planning.
Step 24 Set Up Workflow Options (Optional)
You can use Oracle Workflow technology to handle exception messages by routing them to personnel who have specific job responsibilities in planning. Workflow runs in the background; it automates the generation and distribution of these messages. See Oracle Workflow Guide.
Supply Chain Planning Setup Steps
Note: The Master Scheduling, MRP and Supply Chain Planning products use many of these steps in common, but steps 25 through 33 are only applicable to the Supply Chain Planning product.
Step 25 Define Shipping Methods (Optional)
The Shipping Method code defines specific shipping methods. For example: Ground, Express, or Air. See: Defining Shipping Methods, Oracle Inventory User’s Guide.
Step 26 Associate Shipping Methods with Lead Times (Optional)
You can associate shipping methods with lead times in the Inter-org Shipping Methods window. See: Defining Inter-Organization Shipping Network, Oracle Inventory User’s Guide.
Step 27 Create your Assignment Sets (Optional)
Once you have defined your sourcing rules and bills of distribution, you must assign them to particular items, categories and/or organizations. A set of such assignments is called an assignment set. (Later, when you specify plan options for a plan, you will choose which assignment set you want the plan to use.) See: Assigning Sourcing Rules and Bills of Distribution.
Step 28 Define your Sourcing Rules and Bills of Distribution (Optional)
Sourcing rules specify how to replenish items in an organization. A bill of distribution specifies a multilevel replenishment network of warehouses, distribution centers, manufacturing centers, and trading partners. See: Defining Sourcing Rules, Defining Bills of Distribution.
Step 29 Define your Inter-organization Shipping Network (Optional)
Inter-organization shipping network information describes the relationships and accounting information that exists between a shipping organization and a destination organization. See Defining Inter-Organization Shipping Networks, Oracle Inventory User’s Guide and Defining Shipping Methods, Oracle Inventory User’s Guide.
Step 30 Set Up Supply Chain ATP (Optional)
Supply Chain Available to Promise enables you to view detailed availability information from Oracle Inventory or Oracle Order Entry in order to choose which supply source you want to use to meet the demand. See Defining Inter-Organization Shipping Networks, Oracle Inventory User’s Guide.
Step 31 Set Up Supply Chain CTP (Optional)
Capable to Promise extends Available to Promise by taking into account capacity information. See: Capable to Promise.
Step 32 Define your DRP Names (Optional)
Define any number of distribution requirements plan names. This allows you to generate multiple DRP plans, each with a unique name. A distribution requirements plan defines a set of recommendations to release or reschedule orders for material based on the net material demands. See: Defining DRP Names.
Step 33 DRP Options (Optional)
Select different options for your distribution requirements plan. The planning process uses the input from a supply schedule or a demand schedule to determine the quantities and timing of the items to be manufactured or purchased. See: Reviewing or Adding Supply Chain Plan Options.
Step 34 Start the Planning Manager (Required)
You need to activate the planning manager to execute several maintenance tasks such as forecast consumption and master schedule relief. See: Starting the Planning Manager.
Step 35 Run the Information Audit (Optional-highly recommended)
Audit the information you use to plan your master schedules and material requirements. Information audits are primarily used to validate the integrity of your database. For example, you can use the audit to verify the structure of your bills. Oracle Master Scheduling/MRP provides a set of predefined audits that can be executed to verify existing data. See: Audit Information Report.
Defining Planning Parameters
From the Planning Parameters window, you can enable planning functions. You can also define and update execution options and default values that affect other functions in Oracle Master Scheduling/MRP and Supply Chain Planning.
To define and update the enable dates and default parameters
To assign and update repetitive planning parameters and other repetitive planning defaults
Repetitive planning uses a series of repetitive planning periods (defined as repetitive planning horizon and repetitive planning buckets) to level the production rate over time. When planning the repetitive part, all the demand is grouped by the number of days you specify, and the supply is averaged out over the period.
Starting the Planning Manager
The Planning Manager controls a continuous background process that periodically activates for all organizations. It differs from a normal process in that you need to start it only once. This process is activated based on the processing interval you define.
Once activated, the Planning Manager executes several maintenance tasks. For example, the Planning Manager performs forecast consumption, MDS shipment relief, MPS schedule relief, and forecast and master schedule imports.
Note: You should activate the Planning Manager and leave it running. The Planning Manager performs maintenance tasks vital to the proper operation of Oracle Master Scheduling/MRP and Supply Chain Planning.
Note: When it operates, the Planning Manager may run for a very short time only, making it difficult to determine whether it is running. To be sure, examine the log file for the concurrent request of the Planning Manager to verify that it is active.
To start the Planning Manager and to define the processing interval
Defining Planners
You can define and update material planners or planning entities for the current organization and assign them to inventory items at the organization level. See: Updating Organization Items, Oracle Inventory User’s Guide and General Planning Attribute Group, Oracle Inventory User’s Guide.
To define and update material planners or planning entities
Creating Planning Exception Sets
You can define and update planning exception sets to identify items, orders, and resources that require attention based upon a set of predefined action messages. This facilitates control over message sensitivity, message priority, and marking those messages where action has been taken. After you have defined a planning exception set, you can assign it to the appropriate items when you set the Exception Set attribute for the MPS/MRP Planning group in Oracle Inventory. (If you’re creating an exception set that includes exceptions involving resources, you also need to associate the exception set to resources in Bills of Material.) You will see exceptions based on your exception set associated with your items, and resources.
To enter and update planning exception sets
To enter sensitivity controls for the planning exception set
To enter exception time period types for monitoring exceptions
Creating Demand Classes
You can group similar customers or sales orders by creating demand classes. Demand classes are a means of grouping different sources of demand separately for consumption purposes.
When you create a forecast and/or a master schedule, you have the option of associating a demand class with it. When you book a sales order that has an associated demand class, the forecast consumption process searches the forecasts for entries that have the corresponding demand class. The consumption process attempts to consume these entries first.
The shipment of a sales order or the creation of discrete jobs within a particular demand class causes relief to occur in any master demand schedule and master production schedule that is associated with that demand class.
To create and update demand classes
Creating Source Lists
Field values and button name for each source list window.
|
|||
Window Name
|
Type Field Values
|
Source Type Field Values
|
Button Name
|
Forecast Source List
|
Copy/Merge Forecast Load/Copy/Merge
|
Forecast Entries
|
Copy/Merge Forecast
|
MDS Source List
|
Load/Copy/Merge MDS
|
Forecast Entries MDS Entries MPS Entries MPS Planned Order Demand MRP Planned Order Demand DRP Planned Order Demand
|
Load/Copy/Merge MDS
|
MPS Source List
|
Load MPS Copy/Merge MPS
|
Forecast Entries MDS Entries MPS Entries MPS Planned Order Demand MRP Planned Order Demand DRP Planned Order Demand
|
Load/Copy/Merge MPS
|
Setting Up Planner Workbench
Before you can implement planning recommendations, you must generate at least one MRP, DRP or MPS plan, load purchase orders and new purchase requisitions, and assign purchasing categories and list prices.
Prerequisites for setting up Planner Workbench
To load purchase orders:
Define yourself as an employee and associate your user name to your employee entry. See: Entering New People, Oracle Human Resources.
To load new purchase requisitions
Define at least one deliver-to location and assign this location to your organization. See: Site Locations, Oracle Human Resources User’s Guide and Representing Organizations, Oracle Human Resources User’s Guide.
To assign purchasing categories and list prices:
Assign purchasing item attributes for purchasing categories and list prices to purchased inventory items in Oracle Inventory. See: Defining Items, Oracle Inventory User’s Guide and Defining Categories, Oracle Inventory User’s Guide.
To implement planned orders as purchase requisitions:
Set requisition numbers to be generated automatically in Oracle Purchasing. See: Overview of Purchasing Options, Oracle Purchasing User’s Guide.
Defining Your Display Preferences
Display preferences control what horizontal material planning data, horizontal capacity planning data, and supply/demand detail are displayed for each item.
To define your display preferences
Setting Up Line Scheduling Workbench
Before you can use the Line Scheduling Workbench functionality, you must set up your information in several places:
Set inventory items for Flow Manufacturing
Define items, including both products and parts. Optionally, assign members to a product family. See: Overview of Inventory Setup, Oracle Inventory User’s Guide
Define a Default Discrete Class
Define Default Discrete Class in the Work in Process parameters, or WIP Accounting Class if you have an Oracle Project Manufacturing environment. See: WIP Parameters, Oracle Work in Processing User’s Guide
See: Assigning Project Parameters, Oracle Project Manufacturing User’s Guide
Define Production Lines and Line Rate
Define production lines and associated line rates for items and product families. See: Setting Up Production Lines, Oracle Work in Processing User’s Guide
Define Resources
Define resources for a flow manufacturing line. See: Overview of Flow Manufacturing Procedures, Oracle Bills of Material User’s Guide
Define Flow Routings
Items need to be associated to lines through routings. See: Creating a Flow Routing, Oracle Bills of Material User’s Guide
Run an MRP, DRP, or MPS plan if you are scheduling planned orders
This process is necessary to keep the planned order quantity in synch with the flow schedules to prevent overstatement of demand.
Changing Your Organization
Profile Options
This section describes the Oracle Master Scheduling/MRP and Oracle Supply Chain Planning profile options. In addition to descriptions, you can see the default value and updatable level.
Implementing Profile Options Summary
The table below indicates whether you (the User) can view or update the profile option and at which System Administrator levels the profile options can be updated: at the user, responsibility, application, or site levels.
A Required profile option requires you to provide a value. An Optional profile option already provides a default value, so you only need to change it if you don’t want to accept the default.
Profile Option
|
User
|
System Administrator – User
|
System Administrator – Responsibility
|
System Administrator – Application
|
System Administrator – Site
|
Required?
|
Default Value
|
MRP:ATP Assignment Set
|
–
|
–
|
–
|
–
|
+
|
Required
|
No Default
|
MRP: Calculate Excess Exceptions on Time Fence
|
–
|
–
|
–
|
–
|
+
|
Optional
|
No
|
MRP: Calculate Suggested Repetitive Schedules
|
0
|
0
|
0
|
0
|
+
|
Optional
|
No Default
|
MRP: Compute Sales Order Changes
|
–
|
–
|
–
|
–
|
+
|
Optional
|
Yes
|
MRP: Consume Forecast Set Summary
|
+
|
–
|
–
|
–
|
+
|
Optional
|
No Default
|
MRP: Consume Forecast
|
0
|
–
|
–
|
–
|
+
|
Optional
|
Yes
|
MRP: Consume MDS
|
0
|
–
|
–
|
–
|
+
|
Optional
|
Yes
|
MRP: Consume MPS
|
0
|
–
|
–
|
–
|
+
|
Optional
|
Yes
|
MRP: Cutoff Date Offset Months
|
+
|
–
|
–
|
–
|
+
|
Optional
|
12
|
MRP: Debug Mode
|
+
|
+
|
+
|
+
|
+
|
Optional
|
No
|
MRP: Default DRP Plan Name
|
+
|
+
|
+
|
+
|
+
|
Optional
|
No Default
|
MRP: Default Forecast Date
|
0
|
+
|
+
|
+
|
+
|
Optional
|
Yes
|
Key
|
+
– 0 |
You can update the profile option.
You can view the profile option but cannot change it. You cannot view or change the profile option value. |
Profile Option
|
User
|
System Administrator – User
|
System Administrator – Responsibility
|
System Administrator – Application
|
System Administrator – Site
|
Required?
|
Default Value
|
MRP: Default Forecast Name
|
+
|
+
|
0
|
0
|
0
|
Optional
|
No Default
|
MRP: Default Plan Name
|
+
|
+
|
0
|
0
|
0
|
Optional
|
No Default
|
MRP: Default Schedule Name
|
+
|
+
|
0
|
0
|
0
|
Optional
|
No Default
|
MRP: Default Sourcing Assignment Set
|
+
|
–
|
–
|
–
|
+
|
Optional
|
No Default
|
MRP: Demand Time Fence Days
|
–
|
–
|
–
|
–
|
+
|
Optional
|
No Default
|
MRP: Environment Variable to Set Path for MRP Files
|
–
|
–
|
–
|
–
|
+
|
Optional
|
No Default
|
MRP: Firm Planned Order Time Fence
|
–
|
–
|
–
|
–
|
+
|
Optional
|
Yes
|
MRP: Firm Requisitions within Time Fence
|
–
|
–
|
–
|
–
|
+
|
Optional
|
No Default
|
MRP: Include Scheduled Receipts in Use-up Calculation
|
–
|
0
|
0
|
0
|
+
|
Optional
|
No
|
MRP: Interface Table History Days
|
–
|
–
|
–
|
–
|
+
|
Optional
|
No Default
|
MRP: Maintain Original Schedule Version
|
–
|
–
|
|
|
+
|
Optional
|
No
|
MRP: MPS Relief Batch Size
|
0
|
0
|
0
|
0
|
0
|
Optional
|
No Default
|
MRP: MPS Relief Direction
|
–
|
–
|
+
|
+
|
+
|
Optional
|
Backward, then forward
|
MRP: Perform Planning Manager Functions in Loads
|
+
|
+
|
+
|
+
|
+
|
Optional
|
Yes
|
MRP: Plan Revenue Discount Percent
|
+
|
0
|
0
|
0
|
+
|
Optional
|
0
|
MRP: Plan Revenue Price List
|
+
|
0
|
0
|
0
|
+
|
Required
|
No Default
|
MRP: Planning Manager Batch Size
|
–
|
–
|
0
|
–
|
+
|
Optional
|
No Default
|
MRP: Planning Manager Max Workers
|
–
|
–
|
0
|
–
|
+
|
Optional
|
10
|
MRP: Purchasing by Revision
|
–
|
–
|
–
|
–
|
+
|
Optional
|
No Default
|
Key
|
+
– 0 |
You can update the profile option.
You can view the profile option but cannot change it. You cannot view or change the profile option value. |
Profile Option
|
User
|
System Administrator – User
|
System Administrator – Responsibility
|
System Administrator – Application
|
System Administrator – Site
|
Required?
|
Default Value
|
MRP: Purge Batch Size
|
–
|
–
|
–
|
–
|
+
|
Optional
|
25000
|
MRP: Requisition Load Group Option
|
+
|
+
|
+
|
–
|
+
|
Optional
|
Suppliers
|
MRP: Retain Dates within Calendar Boundary
|
–
|
0
|
0
|
0
|
+
|
Optional
|
Yes
|
MRP: Snapshot Pause for Lock (Minutes)
|
–
|
–
|
–
|
–
|
+
|
Optional
|
5
|
MRP: Snapshot Workers
|
–
|
–
|
–
|
–
|
+
|
Optional
|
5
|
MRP: Sourcing Rule Category Set
|
+
|
–
|
–
|
–
|
+
|
Optional
|
No Default
|
MRP: Time Fence Warning
|
+
|
+
|
+
|
+
|
+
|
Optional
|
Yes
|
MRP: Trace Mode
|
+
|
+
|
+
|
+
|
+
|
Optional
|
No
|
MRP: Use Direct Load Option
|
–
|
–
|
–
|
–
|
+
|
Optional
|
No
|
MRP: Use Ship Arrived Flag
|
0
|
0
|
0
|
0
|
+
|
Optional
|
No
|
Key
|
+
– 0 |
You can update the profile option.
You can view the profile option but cannot change it. You cannot view or change the profile option value. |
MRP:ATP Assignment Set
Indicates the name of the assignment set to use for Supply Chain ATP.
MRP:Calculate Excess Exceptions on Time Fence
Indicates whether to calculate excess exceptions at the time fence, instead of up to the time fence.
This profile has a predefined value of No upon installation.
MRP:Calculate Suggested Repetitive Schedules
Indicates whether to calculate and use suggested repetitive schedules to perform forecast consumption. Available values are listed below:
Yes – Calculate and use suggested repetitive schedule information.
No – Do not calculate and use suggested repetitive schedule information.
MRP:Compute Sales Order Changes
Indicates whether to calculate and use sales order demand to perform forecast consumption and track sales order information. Available values are listed below:
Yes – Calculate and use sales order information.
No – Do not calculate and use sales order information.
Oracle Master Scheduling/MRP predefines a value of Yes for this profile for the site upon installation. You may set this value to No if you wish to disable forecast consumption and sales order tracking in Oracle Master Scheduling/MRP permanently.
This profile has a predefined value of Yes for this profile for the site upon installation.
MRP:Consume Forecast Set Summary
Indicates whether to enable or temporarily disable forecast set consumption. Forecast set consumption is the process that replaces forecasted set demand with actual demand and is handled by the Planning Manager process. Available values are listed below:
Yes – Enable forecast set consumption. Update the forecast set when you place sales order demand.
No – Disable forecast set consumption. Do not update the forecast set when you place sales order demand.
MRP:Consume Forecast
Indicates whether to enable or temporarily disable forecast consumption. Forecast consumption is the process that replaces forecasted demand with actual demand and is handled by the Planning Manager process. Available values are listed below:
Yes – Enable forecast consumption. Update the forecast set when you place sales order demand.
No – Disable forecast consumption. Do not update the forecast set when you place sales order demand.
The planning manager verifies the setting of this option before performing forecast consumption. If it is set to No, the planning manager does not update forecast entries. The planning manager processes any sales order demand occurring while this profile is set to No when you set the profile option back to Yes.
This profile has a predefined value of Yes upon installation.
MRP:Consume MDS
Indicates whether to enable or temporarily disable shipment relief of a master demand schedule. Available values are listed below:
Yes – Enable shipment relief.
No – Disable shipment relief.
The planning manager verifies the setting of this option before performing shipment relief. If it is set to No, the planning manager does not update MDS entries. The planning manager processes any sales order shipments occurring while this profile is set to No when you set the profile option back to Yes.
This profile has a predefined value of Yes upon installation.
MRP:Consume MPS
Indicates whether to enable or temporarily disable production relief of a master production schedule. Available values are listed below:
Yes – Enable production relief.
No – Disable production relief.
The planning manager verifies the setting of this option before performing production relief. If it is set to No, the planning manager does not update MPS entries. The planning manager processes any purchase requisitions and discrete jobs occurring while this profile is set to No when you set the profile option back to Yes.
This profile has a predefined value of Yes upon installation.
MRP:Cutoff Date Offset Months
Specifies the number of months from today to default the cutoff date for all forecasting, scheduling and planning forms. Oracle Master Scheduling/MRP loads the forecast, master scheduling, and material requirement entries from the current date up to and including this date.
MRP:Debug Mode
Indicates whether to enable debug messages within Oracle Master Scheduling/MRP. Available values are listed below:
Yes – Enable debug messages.
No – Do not enable debug messages.
This profile has a predefined value of No upon installation.
MRP:Default DRP Plan Name
Specifies the DRP plan name that defaults when navigating to the Plan Options window, Plan Status window, or the Planner Workbench.
MRP:Default Forecast Date
Indicates whether to default the forecast date to the next valid day/week/period in the Enter Forecast Entries window. Available values are listed below:
Yes – Default the forecast date to the next valid day/week/period in the Enter Forecast Entries form.
No – Do not default the forecast date to the next valid day/week/period in the Enter Forecast Entries form.
This profile has a predefined value of Yes upon installation.
MRP:Default Forecast Name
Specifies the forecast name that defaults when navigating to any of the forecasting forms.
MRP:Default Plan Name
Specifies the MRP or MPS plan name that defaults when navigating to any of the planning forms.
MRP:Default Schedule Name
Specifies the schedule name that defaults when navigating to any of the scheduling forms.
MRP:Default Sourcing Assignment Set
Determines the sourcing assignment set that Oracle Purchasing uses to assign sources to requisitions.
MRP:Demand Time Fence Days
Indicates the number of time fence days for forecast set consumption and MDS (sales order) load.
MRP:Environment Variable to Set Path for MRP Files
Specifies the appropriate path for the MRP files. If this profile is not used, the files are written to $MRP_TOP/$APPLOUT.
This profile contains no pathname following the installation.
MRP:Firm Planned Order Time Fence
Indicates whether to form natural time fences for your MRP firm planned orders when launching the planning process. A MRP firm planned order is an order that is frozen in quantity and time (unavailable for rescheduling). Available values are listed below:
Yes – Form natural time fences for your MRP firm planned orders when launching the planning process.
No – Do not form natural time fences for your MRP firm planned orders when launching the planning process.
This profile has a predefined value of Yes upon installation.
MRP:Firm Requisitions within Time Fence
Indicates whether to form natural time fences for your firm requisitions when launching the planning process. Available values are listed below:
Yes – Form natural time fences for your MRP firm requisitions when launching the planning process.
No – Do not form natural time fences for your MRP firm requisitions when launching the planning process.
MRP:Include Scheduled Receipts in Use-up Calculation
Enables the Memory-based Planning Engine to include scheduled receipts in calculating use-up date. The scheduled receipts included will be Discrete Jobs, Approved Purchase Orders, Receipts, and Shipments. Purchase Requisitions and Non-Standard Jobs will be excluded.
This profile has a predefined value of No upon installation.
MRP:Interface Table History Days
Indicates the number of days that Oracle Master Scheduling/MRP saves rows in the forecast, schedule, and workbench temporary interface tables after they have been processed.
This profile has a predefined value of 5 upon installation.
MRP:Maintain Original Schedule Version
Indicates whether to maintain the original master schedule version. The original schedule version is the earliest copy of schedule dates and quantities, and often may not serve a useful purpose. This gives you the ability to disable the original schedule version if you do not intend to use it as part of your business procedures and do not want to contend with the additional overhead required by Oracle Master Scheduling/MRP to maintain it.
If you change this profile option, you must start the concurrent manager and the planning manager so that the new setting of the profile option is detected.
Available values are listed below:
Yes – Maintain the original master schedule version.
No – Do not maintain the original master schedule version.
Oracle Master Scheduling/MRP predefines a value of No for this profile for the site upon installation.
This profile has a predefined value of No upon installation.
MRP:MPS Relief Batch Size
Indicates the batch size for production relief when relieving master production schedule entries.
MRP:MPS Relief Direction
Indicates the direction in which the production relief takes place when relieving master production schedule entries. Available values are listed below:
Backward, then Forward – Oracle Master Scheduling relieves master production schedule entries backwards from the discrete job due date, then forwards until it finds enough schedule quantity to relieve.
Forward only – Oracle Master Scheduling relieves master production schedule entries only forward from the discrete job due date until it finds enough schedule quantity to relieve.
Attention: When you change any of these profile options you must restart the planning manager to activate the new profil option.
This profile has a predefined value of Backward, then forward upon installation.
Note: The name of this profile option in Release 10 is MRP:Relief Directional Control.
MRP:Perform Planning Manager Functions in Loads
Ensures that the forecast and master schedule load programs perform all planning manager functions: compute sales order changes, forecast consumption, and MDS relief.
This profile has a predefined value of Yes upon installation.
MRP:Plan Revenue Discount Percent
Specifies the average discount percent that is applied to all items in a plan. This value is a key performance indicator used to calculate performance in a plan for Business Intelligence reports.
This profile can be a value between 0 and 100, decimal values are permitted.
MRP:Plan Revenue Price List
Specifies the sales order price list that is applied to items in a plan. This value is used to calculate the plan margin key performance indicators for Business Intelligence reports.
MRP:Planning Manager Batch Size
Indicates the batch size for the number of rows in a set that the planning manager processes. You use this profile option during a forecast and master schedule load to determine the number of rows to process in batch. Oracle Master Scheduling/MRP also uses this profile option during forecast consumption and master schedule relief to determine the number of items to process.
A larger batch size is more efficient, because a process needs to make fewer database hits. For example, if there are 1000 rows or items to process, and you have set the profile to 100, the process needs to access the database 10 times to retrieve information on all 1000 rows or items. Setting the profile to 200 means that the process needs to access the database only 5 times.
A smaller batch size means that the work may be divided across more workers. Using the example above, a value of 100 means that the Planning Manager could divide the work across 10 processes, while a value of 200 means that only 5 processes could operate simultaneously.
MRP:Planning Manager Max Workers
Indicates the maximum number of workers to be launched by the planning manager. If there are many rows processing, the planning manager continues to spawn more workers, until all rows have been processed, or the number of Planning Manager Workers running or pending matches or exceeds the value of MRP:Planning Manager Workers.
A larger value for this profile means that the Planning Manager can use more workers to process tasks. However, a larger value could also mean that the concurrent manager queue becomes filled with workers, and other processes do not run.
In general, do not define a value that exceeds the maximum number of concurrent programs that can run simultaneously.
This profile has a predefined value of 10 upon installation.
MRP:Purchasing by Revision
Indicates whether to pass on item revision to the purchase requisition.
MRP:Purge Batch Size
Indicates the batch size for the number of rows that the planning purge process deletes between commits. The larger the number, the faster the purge processes performs. The lower the number, the smaller the rollback segments required.
This profile has a predefined value of 25000 upon installation.
MRP:Requisition Load Group Option
Indicates the group by option used when loading requisitions using the Planner Workbench form. Available values are listed below:
All on one – Create one purchase requisition for all recommended orders.
Buyer – Create one purchase requisition for buyer. Within each requisition, create one line for each planned order for the buyer.
Category – Create one purchase requisition for each category of items. Within each requisition, create one line for each planned order for the category.
Inventory item – Create one purchase requisition for each inventory item. Within each requisition, create one line for each planned order for the item.
One each – Create one purchase requisition for recommended order.
Planner – Create one purchase requisition for each planner. Within each requisition, create one line for each planned order for the planner.
Supplier – Create one purchase requisition for each supplier. Within each requisition, create one line for each planned order for the supplier.
MRP:Retain Dates within Calendar Boundary
Ensures that dates stay within the calendar boundary.
This profile has a predefined value of Yes upon installation.
MRP:Snapshot Pause for Lock (Minutes)
Indicates the number of minutes to pause execution of the Snapshot process while waiting to acquire locks on tables.
This profile has a predefined value of 5 upon installation.
MRP:Snapshot Workers
Indicates the number of workers that are launched during the execution of the Snapshot process. A larger value means that more tasks are performed in parallel. Too many workers, however, can result in system degradation and diminishing performance benefits.
In general, do not define a value for this profile that exceeds the maximum number of concurrent programs that can run simultaneously.
This profile has a predefined value of 5 upon installation.
MRP:Sourcing Rule Category Set
Indicates the category set used when Oracle Supply Chain Planning or Oracle Purchasing creates sourcing assignments at category-org or category level.
MRP:Time Fence Warning
Indicates whether to receive a warning if you modify a master production schedule within the planning time fence or master demand schedule within the demand time fence. Available values are listed below:
Yes – Receive a warning modify a master production schedule within the planning time fence or master demand schedule within the demand time fence.
No – Do not receive a warning if you modify a master schedule within the planning or demand time fence.
This profile has a predefined value of Yes upon installation.
MRP:Trace Mode
Indicates whether to enable the trace option within Oracle Master Scheduling/MRP and Supply Chain Planning. Available values are listed below:
Yes – Enable the trace option within Oracle Master Scheduling/MRP and Supply Chain Planning.
No – Do not enable the trace option within Oracle Master Scheduling/MRP and Supply Chain Planning.
This profile has a predefined value of No upon installation.
MRP:Use Direct Load Option
Enables the Loader Worker to use the direct load option instead of conventional loads.
This profile has a predefined value of No upon installation. You can update this profile at all levels.
MRP:Use Ship Arrived Flag
Indicates how to treat sales orders shipped to customers. You can automatically treat sales orders as “arrived” at a customer site after the intransit lead time has expired, or you can manually update the ARRIVED_FLAG in SO_PICKING_HEADERS.
This profile is used by the Memory-based Planning Engine when a customer is modelled as an organization.
This profile has a predefined value of No upon installation. Available values are listed below:
Yes – Use arrived flag in SO_PICKING_HEADERS.
No – Use intransit time between source and the destination organizations.
See Also
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.
___________________________________________________________________
Oracle Application R12 COGS
In Oracle Application R12 COGS process has been changed. Reason for that are aggressive revenue
recognition practices as well as the guidelines from various governing bodies.
Till R11 Cost of goods sold has been recognized as soon as the Order line has shipped, as shown in below
steps
After ship confirm, user run the interface trip stop (ITS).
ITS in turns run the OM Interface and Inventory Interface.
Inventory Interface calls Inventory transaction manager which in turns call COGS WF.
But as per new practices COGS should be recognized along with the revenue.
In R12 used need to define deferred cogs account. These deferred cogs account can be defined at each
inventory org level.
During shipping process Inventory tables will hold the deferred COGS accounts. Only after invoicing has
done in AR, AR will notify the Costing and Costing in turns call the COGS account generator to get the
cogs account .In that way COGS and revenue will be recognized in the same period.
There are few exceptions like how to get the COGS for
1. Ship only line (No Invoice will be created).
To handle above cases Close-line activity of the order line workflow has modified to call the costing API
to get the cogs value
What is the Deferred COGS account in R12
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.
To set the deferrred COGS account.
Inventory –Setup–Organization–Parameters–Other Accounts
A new account is added which is referred as the Deffered COGS accounts.
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:
Deffered COGS : Debit y 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:
Deffered COGS : Credit (Actual revenue percentage)
COGS : Debit (Actual revenue percentage )
COGS (Cost of Goods Sold) in Oracle E-Business Suite Release 12
Deferred COGS is a new feature introduced in Oracle E-Business Suite Release 12. The basic
fundamentals behind the enhancement are that the COGS are now directly matched to the
Revenue.
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.
While this helps solve some key accounting issues, there are some key issues one needs to be
aware of:
• Currently Deferred COGS accounting cannot be turned off in Oracle EBS Release 12.
• The activity of recording COGS recognition is now a multi-step process
• Run AR Revenue Recognition, and Submit Accounting Processes
• Run a set of concurrent processes in Cost Manager 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.
• Record Order Management Transactions: records new sales order transaction activity
such as shipments and RMA returns in Oracle Order Management.
• Collect Revenue Recognition Information: determines the percentage of recognized or
earned revenue related to invoiced sales order shipment lines in Oracle Receivables.
• 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 end result of these activities is a series of COGS Recognition Material Distributions.
However these distributions will not be visible on the Material Transaction screen, unless the
‘Include Logical Transaction’ checkbox is checked.
R12 Order Management: Revenue-COGS Matching Part I
It is a relief to see this much awaited functionality. We heard our accounting departments
complaining about the period mismatches in for our COGS and Revenue accounting for one
order. We ship an order on the last day of the month and COGS gets posted to this month, but if
the invoice is created with next period’s GL date as the current AR period is closed by the time
the order is invoiced. Now all that is changed. Revenue-COGS matching is a standard
functionality now. In simple terms, this means, COGS for an order line will be recognized only if
the revenue is recognized for that line making sure that the revenue and COGS are posted in the
same month.
All of us have spent a lot of time working on COGS accounting workflow to achieve what we
want for our clients/companies. In some cases we even customized Revenue accounting
generation (avoiding auto accounting logic) by using ra_interface, distributions_all table. We had
a handle on accounts generation in this process but not on the actual events of accounting
recognition.
We all know this.
When we ship the order and run the Interface Trip Stops program, inventory gets reduced and
orders get updated to move forward in the workflow to the next activity. Interface Trip Stops
program calls the OE_FLEX_COGS_PUB to generate the COGS account as per design. This
gets passed on to the mtl_material_transactions table in the distribution_account column. When
Cost Manager runs, distribution_account from mtl_material_transactions is picked up to generate
accounting as shown.
Cr Inventory Material account $100
Dr COGS Account $100
The role of COGS
workflow is not changed. It is still the same which generates the account of our choice per
workflow design. It still passes the generated account to the mtl_material_transactions table into
the distribution_account column. But what changed in R12 is accounting. In order to match
Revenue with COGS accounting in terms of timing, COGS account cannot be used at the time
shipping. Instead revenue recognition process of the invoice for that order line should generate
COGS accounting.
To achieve this, a new account called Deferred COGS account is introduced at the inventory
organization parameters level. So when the order shipped instead of the above entries the entry
will be
Cr Inventory Material account $100
Dr Deferred COGS Account $100
When you invoice is this order line, if you have no revenue recognition policies or specialized
accounting rules, revenue should be instantly recognized (upon running revenue recognition
program).
After revenue is recognized, the following programs need to be run to relieve deferred COGS
value and debit actual COGS account.
Record Order Management Transactions: This program collects all the transactions that
belong to transaction types Sales order issue and Logical Sales Order Issue which are not costed
and the order line is invoiceable. The source table is mtl_material_transactions. This program
inserts rows into two tables: cst_cogs_events and cst_revenue_cogs_match_lines. This program
is not necessary to run. When not run, Cost Manager will insert rows into these tables. So from
implementation considerations, this program is not required to be run.
Collect Revenue Recognition Information: This program collects invoice line information of
the order line after the revenue is recognized. The source tables are ra_customer_trx_lines_all
and ra_cust_trx_line_gl_dist_all. It will check the percentage of the revenue recognized (we can
recognize revenue partially for a specific order line based on accounting rule or contingency
rules) and inserts that information into this table: cst_revenue_recognition_lines. Also the table
cst_revenue_cogs_control table is updated with the latest run date with high date of this
parameter, which is used in the next run of the same program.
Generate COGS
Recognition Events: The role of this program is to record a logical material transaction, which
is used to create final COGS entry. This program takes information from the above tables and
creates one logical inventory transaction in mtl_material_transactions with a new transaction
type called COGS Recognition. In the same program these transactions will be costed (not by the
cost manager) creating the following accounting entries. The COGS account in this entry is taken
from the distribution_account in mtl_material_transactions table (which was generated earlier by
COGS workflow).
Cr Deferred account $100
Dr COGS Account $100
This is the concept in simple terms. There are different cases (well documented in the Cost
Management User Guide) in this same flow which, I will take one at a time to discuss in the
coming posts.
SQL statements that help understand the data model are below,
SELECT header_id
FROM oe_order_headers_all
WHERE order_number = &your_order_number;
SELECT line_id
FROM oe_order_lines_all
WHERE header_id = (SELECT header_id
FROM oe_order_headers_all
WHERE order_number = &your_order_number);
SELECT *
FROM mtl_material_transactions
WHERE trx_source_line_id IN (SELECT line_id
FROM oe_order_lines_all
WHERE header_id = (SELECT header_id
FROM oe_order_headers_all
WHERE order_number =
&your_order_number))
AND transaction_type_id IN (33, 10008);
SELECT *
FROM mtl_transaction_accounts
WHERE transaction_id IN (
SELECT transaction_id
FROM mtl_material_transactions
WHERE trx_source_line_id IN (SELECT line_id
FROM oe_order_lines_all
WHERE header_id = (SELECT header_id
FROM
oe_order_headers_all
WHERE
order_number = &your_order_number))
AND transaction_type_id IN (33, 10008));
SELECT *
FROM cst_revenue_cogs_match_lines
WHERE cogs_om_line_id IN (SELECT line_id
FROM oe_order_lines_all
WHERE header_id = (SELECT header_id
FROM oe_order_headers_all
WHERE order_number =
&your_order_number));
SELECT *
FROM cst_cogs_events
WHERE cogs_om_line_id IN (SELECT line_id
FROM oe_order_lines_all
WHERE header_id = (SELECT header_id
FROM oe_order_headers_all
WHERE order_number =
&your_order_number));
SELECT *
FROM cst_revenue_cogs_control;
SELECT *
FROM ra_customer_trx_lines_all
WHERE interface_line_context = ‘ORDER ENTRY’
AND interface_line_attribute6 IN (SELECT line_id
FROM oe_order_lines_all
WHERE header_id = (SELECT header_id
FROM
oe_order_headers_all
WHERE order_number
= &your_order_number));
SELECT *
FROM ra_cust_trx_line_gl_dist_all
WHERE customer_trx_line_id IN (
SELECT customer_trx_line_id
FROM ra_customer_trx_lines_all
WHERE interface_line_context = ‘ORDER ENTRY’
AND interface_line_attribute6 IN (SELECT line_id
FROM oe_order_lines_all
WHERE header_id = (SELECT
header_id
FROM
oe_order_headers_all
WHERE
order_number = &your_order_number))
AND account_set_flag = ‘N’
AND account_class = ‘REV’);
SELECT *
FROM cst_revenue_recognition_lines
WHERE revenue_om_line_id IN (SELECT line_id
FROM oe_order_lines_all
WHERE header_id = (SELECT header_id
FROM oe_order_headers_all
WHERE order_number =
&your_order_number));
SELECT *
FROM mtl_transaction_accounts
WHERE transaction_id IN (
SELECT transaction_id
FROM mtl_material_transactions
WHERE trx_source_line_id IN (SELECT line_id
FROM oe_order_lines_all
WHERE header_id = (SELECT header_id
FROM
oe_order_headers_all
WHERE
order_number = &your_order_number))
AND transaction_type_id IN (33, 10008));
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.
Latest Posts
- R12 – How to Handle NULL for :$FLEX$.VALUE_SET_NAME In Oracle ERPAugust 25, 2023 - 1:20 pm
- R12 – How to Delete Oracle AR TransactionsMarch 22, 2019 - 8:37 pm
- How to Define Custom Key Flexfield (KFF) in R12January 19, 2018 - 5:43 pm
- AutoLock Box Concepts In R12November 10, 2017 - 8:30 am
- R12 – java.sql.SQLException: Invalid column type in OAFSeptember 15, 2017 - 9:39 am
Recent Comments