MOAC not only controls what operating units you can select in modules like Payables, Receivables, Projects, and Purchasing.  It also can control the inventory organization you can select in Inventory, WIP, and Cost Management.  However it does not apply to modules that are not operating unit based like General Ledger and Assets.

Let me give you a little background on how operating units and responsibilities work in 11i and how they work in R12 using MOAC.

In 11i, you were only allowed to access one operating unit per responsibility.  The responsibility would set the operating unit based on the value in the “MO: Operating Unit” system profile.  Because a responsibility was associated with only one “MO: Operating Unit”, responsibility to operating unit relationship is one-to-one.  So, if you wanted to enter an AP vendor invoices for the US operating unit and another invoice for the Swedish operating units, you would need to change responsibilities for each invoice.

In R12, you can access more than one operating unit in a single responsibility.  Oracle changed the relationship between responsibility and operating unit.  Instead of a one-to-one, now you have a one-to-many.  This is accomplished by a new system profile called “MO:  Security Profile”.  This profile looks to an HR security profile to determine which operating units or inventory organizations you can access under a given responsibility. .  So, if you wanted to enter an AP vendor invoices for the US operating unit and another invoice for the Swedish operating units, you can enter both invoices without leaving the AP invoice workbench form.

Configuring MOAC can help you streamline financial processes that are usually consolidated. These could include creating Purchase Orders, entering AP invoices, and closing the financial modules.

If you want the ability to access the operating unit field or parameter, you will need to configure MOAC.  When you upgrade to R12, your responsibilities will still be only linked to a single operating unit.  So, this will be an extra post upgrade step.  I have identified eight steps to configuring MOAC for your upgraded R12 instance.

Moving to MOAC Steps:

1. Analyze your current responsibilities and determine which responsibilities have the same access to forms and reports but are linked to different operating units.  You should be looking for responsibilities with the same menu, request group and exclusions.
2. Analyze your user population to determine if the same users are accessing these responsibilities.   If one user has AP User in both US and Sweden, then there’s an opportunity to consolidate those responsibilities.
3. Analyze if your HR security profiles should be based on hierarchies or lists or both.  Hierarchies are easier to maintain but lists are more flexible
4. Determine if you want to associate security profiles at the responsibility level or the user level.  Associating them at the responsibility level will allow you better visibility into what operating units the user is accessing but will create more responsibilities.  Associating them at the user level will allow segregate function access (by responsibility) from data access (by HR security profiles).
5. Create your new HR security profiles
6. Create any new MOAC responsibilities and assign the new the HR security profiles to your responsibilities
7. Assign the new MOAC responsibilities to users
8. Train your users on how to use the operating unit field on their forms and concurrent programs

I hope you will find these steps an easy way to take the mystery of out configuring MOAC and will help you streamline some of your financial processes

Account Generator Workflows in “Order to Cash” and “Procure to Pay”

There are two business flows where I have found it useful to customize the Account Generator workflows.  The first is the Procure to Pay cycle and the second is the Order to Cash Cycle.

In the Procure to Pay cycle, Purchasing and Payables use the following workflow processes to automatically derive the GL accounts in the purchasing distributions and payables distributions forms. Any vendor invoice or purchase order that references a project calls a special workflow process that must be customized because the seeded version contains a dummy process.  This dummy process returns an error by design.

In the 11i Order to Cash cycle, the Cost Manger program creates material distributions for Sales Order Issue transactions (shipments from Inventory to Customers).  The COGS workflow is called during this process to determine the Cost of Goods GL account.  If you don’t modify this workflow, the seeded version of this workflow will return the Cost of Goods account associated with the item.

In the R12 Order to Cash cycle, the Cost Manger program creates material distributions for Sales Order Issue transactions (shipments from Inventory to Customers).  The Sales Order Issue is booked to deferred Cost of Goods and reversed until you run the COGS recognition program in the Cost Management module.  This program will create a COGS recognition transaction.  It is this transaction that calls the COGS workflow to get the GL accounts.  The COGS recognition transaction is a logical transaction – meaning it does not affect inventory value.  Now that we know when and where we would modify the Account Generator workflows, let’s take a look at an example.

Modifying a Payables Account Generator Workflow Example

I’m using the Payables Project Supplier process because that is a workflow that needs to be modified for you to process project-related invoices in AP.  This example will work for any Account Generator workflow, you just need to know the workflow item type name.  I’ll provide a list of them at the end of this post.

In workflow builder, perform the following steps:

1.1.    Find the Project Supplier Invoice Account Generation workflow item type

1.2.    Create a copy of the Generate Default Account process

1.3.    Create custom attributes (one for each segment in your GL accounting flexfield)

Oracle Workflow Custom Attributes

1.4.    Create a custom workflow function

Oracle Workflow Custom Function

1.5.    Associate the attributes you wish to pass into the custom function

Oracle Workflow Navigator for Account Generator

1.6.    Modify the flow to first call the custom function then assign values to each attribute and then call the Validate Code Combination process

Oracle Account Generator Workflow Flow

Oracle Workflow Node Attributes

In a SQL tool, perform the following steps:

2.1.    Create a custom package with a procedure defined in 1.4.  Make sure the  parameters of the procedure follow the workflow standard:

(  itemtype IN VARCHAR2

        ,itemkey  IN VARCHAR2

        ,actid    IN NUMBER

        ,funcmode IN VARCHAR2

                        ,resultout   IN OUT VARCHAR2)

2.2.    In the procedure use the “wf_engine.GetItemAttrText “ procedure or the “wf_engine.GetItemAttrNumber” procedure to get the attributes from step 1.5

2.3.    Add the custom logic to derive the GL account segments

2.4.    In the procedure use the “wf_engine.setitemattrtext “ procedure to set the attribute values defined in step 1.3

In Oracle Applications, perform the following steps:

3.1.    In the Account Generator Process form, update the Process Name for the Project Supplier Invoice Account Generation Item Type with the same name as defined in step 1.2

Oracle Account Generator Processes

Oracle uses Cost Elements to track and account for Inventory Cost

Oracle uses 5 cost elements to track inventory value.  When you setup an Inventory organization, you’ll be asked for default accounts for material, material overhead, outside processing, overhead, and resources.  The first two (material and material overhead) are associated with material transactions (from the Inventory module) and the last three (outside processing, overhead, and resources) are associated with WIP transactions (from the WIP module).

Inventory Organization Costing Parameters

The Relationship between Inventory, WIP, and Receiving Transactions and Inventory Value Reports

It is important to note that only material and WIP transactions affect inventory value.  Material transactions occur in the Inventory module, WIP Transactions occur in the WIP module, and receiving transactions occur in the Purchasing module.  Receiving transactions do not affect inventory value reports.  These transactions are recorded to the receiving sub-ledger and affect the receiving value reports.

Relationship between Receiving, Material, and WIP Transactions and Inventory Value

How Material Receipts flow from Receiving to Inventory

When you look at a receiving transaction (with a routing of Direct Delivery) you will see two transactions.   The first transaction is the “Receive” transaction.  This records the receipt in the receiving module and creates the accrual.  The second transaction is the “Deliver transaction”.  This records the movement of inventory from receiving into inventory.  It records the credit to the receiving module and the debit to the inventory module. The way receiving affects inventory value is when the “deliver” material transaction is created.  This transaction is not recorded in the receiving module it is recorded in the Inventory module.

Receiving Transaction Flow for Accounting and Costing

How Oracle Calculates Inventory Value

When a material or WIP transaction is processed in Oracle, the on-hand quantity is updated.  If you are using the Average Cost costing method, the average cost is also updated.  Oracle uses the on-hand quantity multiplied by the item cost to calculate Inventory value.  If you run period-end inventory value reports, Oracle will rollback the quantity and cost to the period end values.  Otherwise, the inventory value is calculated (real time) with the current on-hand and item cost.

The Relationship between Material and WIP Distributions and Inventory Value

After a material or WIP transaction has been recorded, the Cost Manager will create the distributions for that transaction.  Each transaction has two distributions per cost element.  Each cost element will have a debit and credit distribution associated with specific accounting line types.  The accounting line type tells us if this distribution affects inventory value.  If the accounting line type is “Inv Valuation” then inventory value is affected.

Inventory Value Calculation and Material Distributions

Because “Inv Valuation” is the only accounting line type that affects inventory value, we can say that the inventory value should equal the sum of the “Inv Valuation” accounting line types.  This gives us the first step in our reconciliation.   Does the sum of the “Inv Valuation” accounting line types equal the Inventory Value report?  If not, then you have a problem with the on-hand or item cost being out of sync with the material distributions.   To verify this for a specific period, you need to subtract the inventory value from last period from the inventory value for this period.

Reconciling Inventory Activity to GL Activity

After you have verified that the difference between last period’s inventory value report and this period’s inventory value report equals the “Inv Valuation” material distributions, you can verify the sum of all material distributions for each inventory valuation GL account equals the difference the same amount.  If there’s between the two amounts you know that there are some material distributions that do not have an accounting line type of “Inv Valuation”.    The main culprit for these distributions is miscellaneous issues, miscellaneous receipts, and cost updates coded to an inventory valuation GL account.  The other possible reason is if your receiving account is the same as your inventory valuation GL account.  This will cause you to debit and credit the same account when the “deliver transaction” is recorded.  You can verify this by entering the material valuation GL account with the accounting line type of “Receiving Inspection” into the material distribution form.  When you have the adjustments to your material distributions, you can now compare the material distributions amount to the difference between last period’s GL balance and this period’s GL balance.  If you are using different accounts for each cost element, you’ll need to add them together before comparing.   If you have a problem here, then look for journal entries that do not have a source of Cost Management.   If you exclude these journal entries and you still do not balance, then make sure all accounting has be created, interface, and posted to the GL.

Inventory Activity Reconciliation Worksheet

1. Entering or Importing the Supplier Invoice
2. Optionally, matching the invoice to a Purchase Order or Receipt
3. Validating the invoice
4. Resolving automatic invoice holds
5. Running the invoice approval process and approving invoices
6. Creating and approving payment

Step 1: Entering or importing the supplier invoice

The first step in the Invoice to Payment process will be to enter the invoice information into the Payables module.  You can perform this step a number of different ways.  You can manually enter the invoice into the Invoice Workbench form or the Quick Invoice form.  You can interface and then import the invoice.  You can also generate invoices based on your PO receipts.  To generate invoices from PO receipts, you need to run the “Pay on Receipt AutoInvoice Program” in the Purchasing module.

Step 2: Matching the invoice to a purchase order or receipt

If your invoice has an associated purchase order, you can match the invoice quantity and price to that purchase order.  If your purchase order is setup as a 2 –way match, then you match the invoice to the purchase order lines.  If your purchase order is setup as a 3-way match, then you match the invoice to the inventory receipts.

Step 3: Validating the Invoice

Once the invoice is entered into the system, you will need to run the invoice validation process.  This process can be run from the Invoice Workbench form (by clicking the Actions button) or you can validate invoices by running the invoice validation concurrent program.  The validation process performs a couple of different checks.  First, it checks to see if should apply any matching holds.  Then it will calculate and apply taxes, verify the GL period status, verify exchange rates, and verify distribution information is valid.

Step 4:  Resolving Invoice Holds

When the validation process places an invoice on hold, you must either resolve the hold or release the hold before payment can be made.  Some holds can be released (like price and quantity holds) and other need to be resolved.  These holds are called system holds and are need to be resolved to make the invoice valid.

Step 5: Running the invoice approval process and approving invoices

After we have a valid invoice, you will need to run the invoice approval process.  This process can be tailor to your specific business needs with the Approval Management Engine (AME).  If the invoice meets the rules to require approval, AME will determine the approver(s) and send a notification.  The approver can then approve or reject the invoice online.

Step 6:  Creating and Approving payment

After we have an approved invoice, you are ready to pay the supplier.  You can create a manual payment for this invoice or you can batch all the invoices that are due for payment.  To create a payment batch, you use the Payments Process Request and select a template.  This template will identify the invoices to be paid and determines if approval is necessary.  If approval is not necessary, the payment documents will be formatted for printing (for checks) or electronic transmission.

In Project Manufacturing, you will setup cost groups and link them to projects (via the project parameters form). When you create a transaction in a Project Manufacturing enable inventory organization, you must enter the project number in a special locator.

In WMS, you can use cost group rules to determine the cost group based on a number of different attributes.  These attributes include supplier, customer, item, locator, item status, and item category.

Let’s take a look at the difference between an inventory organization without WMS or Project Manufacturing and one with WMS or Project Manufacturing.  Both organization will buy two identical items from different vendors and sell them to two different customers.

Example 1:  Inventory Organization with the Average Costing Method

Transaction 1:  Buy 100 units @ $10/unit from Vendor A

Transaction 2:  Buy 100 units @ $20/unit from Vendor B

Transaction 3:  Sell and Ship 100 units @ $30/unit to Customer Z

Transaction 4:  Sell and Ship 100 units @ $30/unit to Customer X

In this organization, all 200 units would be received into inventory and averaged together.  Then when the items are shipped to the customer, the average cost ($15/unit) would be applied to each order.

Example 2:  Project Manufacturing Inventory Organization with the Average Costing Method

Transaction 1:  Buy 100 units @ $10/unit from Vendor A for Project A

Transaction 2:  Buy 100 units @ $20/unit from Vendor B for Project B

Transaction 3:  Sell and Ship 100 units @ $30/unit to Customer Z for Project A

Transaction 4:  Sell and Ship 100 units @ $30/unit to Customer X for Project B

In this organization, project A’s 100 units would be received into inventory and averaged together ($10/unit) and project B’s 100 units would be received into inventory and averaged together ($20/unit) .  Then when the items are shipped to the customer, project A would have an average cost of $10 and a higher margin than project B.  The units from both projects could be indistinguishable and in the same physical location in the warehouse.  But, in the system, they are tracked separately.

Cost averages at the organization, item, cost group level.

Oracle Project Manufacturing Cost Group Example

You use the Project Parameters form to associate cost groups to projects

Oracle Projects Intercompany Transaction and Journal Flow

This will require us to perform the following setup steps:

1. Complete setup steps in last post
2. Setup labor and non-labor transfer price rules
3. Setup a transfer price schedule
4. Update our project’s cross charge options
5. In the providing operating unit, create a bill-to, ship-to site, and bill-to contact for the intercompany customer
6. In the receiving operating unit, create payment site for the intercompany vendor
7. In the receiving operating unit, setup intercompany autoaccounting rules
8. In the receiving operating unit, create an intercompany project type
9. In the receiving operating unit, create an intercompany project template
10. In the receiving operating unit, create an intercompany project
11. Create an intercompany agreement
12. Create a revenue budget for your intercompany project
13. Update provider/receiver controls
14. In the receiving operating unit, update the item validation organization parameter in OM
15. Open PA and GL periods in both operating units
16. Open periods in AR and AP (both operating units)

Step 1: Complete setup steps in (Oracle Apps Tutorial: How to Allow Other Operating Units to Charge Your Project) post

The steps in this post to ensure you can charge you project.

Step 2: Setup labor and non-labor transfer price rules

These rules will determine how the intercompany amount is calculated.  The transfer price can be a simple markup (using the basis) field, a more complex markup using burden schedules, or you can use a rate schedule.

Oracle Projects - Labor Transfer Price Rule

Oracle Projects - Non Labor Transfer Price Rule

Step 3: Setup transfer price schedule

After you have created your transfer price rule, you need to tell Oracle when to use the schedule.  It uses the hierarchies to find a receiver / provider combination.  Once it finds the combination, then it will use that schedule.  I created my own schedule to ensure it would pick the correct one.

Oracle Projects Transfer Price Schedules

Step 4: Update the project’s cross charge options

You will need to go back to your project in the receiving operating unit and update cross charge options. You will need update the transfer price schedules and update the intercompany tax task at the project level.  Since each task copies the transfer price schedule from the project, you will need to update the task’s transfer price.

Oracle Projects - Project Cross Charge Settings

Oracle Projects - Task Cross Charge Settings

Step 5: Creating a bill-to, ship-to site, and bill-to contact for the intercompany customer

Using the customer defined in the receiving operating unit’s implementation options, create a bill-to, ship-to, and bill-to contact for that customer in the provider’s operating unit.  This will allow you to associate this customer to your intercompany project.

Oracle Projects - Intercompany Project Customer

Step 6:  Create payment site for the intercompany vendor

Using the vendor defined in the providing operating unit’s implementation options, create a vendor payment site for that vendor in the receiver’s operating unit.  This will allow you to interface the AP intercompany invoice.

Step 7: Setup intercompany AutoAccounting rules

To process the intercompany invoice, you will need to setup rules and assign them to the intercompany accounting functions.

Oracle Projects - Intercompany Autoaccounting Assignments

Step 8: Create an intercompany project type

Using the contract project class, create a project type with the intercompany option checked.  For the billing tab, you might also need to setup dummy labor and non-labor rate schedules and new invoice format rules.   Select the work/work distribution method.

Oracle Projects - Intercompany Project Type

Step 9: Create an intercompany project template

After you have created your intercompany project type, create a template that using that type.  You will need to enable the financial structure and create one dummy task.  This project will not collect cost.  It’s just for billing.

Step 10: Create an intercompany project

Once you have the template, you can create the intercompany project.  Add your intercompany customer (with billing contact) and change the status to “Approved” or “Active”.

Oracle Projects - Intercompany Project

Step 11: Create an intercompany agreement

For Projects to generate an invoice, you will need an agreement.  Since this is an intercompany agreement, I have an agreement for $1 and made sure the hard limits were unchecked.  This will allow me to generate unlimited number of invoices.

Oracle Projects - Intercompany Agreement And Funding

Step 12: Create a revenue budget for your intercompany project

For Projects to generate an invoice, you will also need a baselined revenue budget.

Oracle Projects - Baselined Revenue Budget For Intercompany Project

Step 13: Update provider and receiver controls

After your intercompany project setup is complete, you can now update the Provider and Receiver Controls to use the processing method on “Intercompany” and to use your project to generate the invoice.  You can have the system generate one invoice per receiving operating unit (if there are multiple receiving operating units in your legal entity) or one invoice per project (the project you are charging to).  If you select “None”, Oracle will generate one invoice per legal entity.  You will also need to update the receiver controls (switch the operating unit to the receiver operating unit) to use the vendor site, a default expenditure type, and a default expenditure organization.

Oracle Projects - Provider/Receiver Controls (Provider Controls)

Oracle Projects - Provider/Receiver Controls (Receiver Controls)

Step 14: Update the item validation organization parameter in OM

Before you can generate intercompany invoices for your new operating unit, you will need to update the item validation organization parameter.  If you don’t have access to Order Management (for your new org), then you can create a custom responsibility to access this function.

Custom Menu For Order Management Parameters

Custom Responsibility For Order Management Parameters

Operating Unit Profile For Order Management Parameters Responsibility

Setting Item Validation Organization

Step 15: Open PA and GL periods in both operating units

You need to make sure PA and GL periods are open for both operating units.

Step 16: Open periods in AR and AP (both operating units)

You need to make sure AR and AP periods are open for both operating units.

After we have performed the setups, we can process cost and generate the intercompany invoice.  The intercompany flow starts with creating or importing cost and ends with importing the intercompany invoice into Payables.  Here are the steps I used to test my intercompany process:

1. Enter pre-approved expenditure batch for miscellaneous cost
2. Submit and release expenditure batch
3. Run PRC: Distribute Usage and Miscellaneous Cost
4. Run PRC: Generate Intercompany Invoice for a single project (make sure you enter a bill thru date)
5. Approve and release the intercompany invoice
6. Run PRC:  Streamline Interface Process (XIC option)
7. In Payables, run the Import Invoices program

Oracle Projects - Generating Intercompany Invoice

In this post, I’ll show you how to enable the operating units to charge your project in both situations. To focus just on the steps to allow you to charge the project, I’ll set the cross charging processing method to “None”.  This is the method you would use if you didn’t want to generate any intercompany accounting or invoices.  In my next post, we’ll start to explore the different options for intercompany accounting and billing setups.

Figure 1 Charging Across Operating Units

Figure 2 Charging Across Legal Entities

Oracle Projects Cross Charge Setup Steps for an Operating Unit with the Same Legal Entity

To enable the project in an operating unit with the same legal entity, you need to:

1. Create a new operating unit and a new expenditure organization
2. Create a new Projects responsibility for new operating unit
3. Replicate seed data
4. Update the Cross Charge tab in the System Implementation form in the existing operating unit
5. Update the Project Cross Charge option for each project you wish to charge in the existing operating unit
6. Update the Task Cross Charge option for each task you wish to charge in the existing operating unit
7. Setup the System Implementation options in the new operating unit
8. Add the new operating unit and expenditure organization to the project hierarchy
9. Associate the new operating unit to the existing operating in the Provider/Receiver Controls form

For my example, I’ll use the following data:

I’ll setup a new operating unit called “MY NEW OU” and link it to an existing legal entity (Vision Services).  I will also create a new project in the Version Services operating unit called “TEST CC PROJECT”.  This project will have an indirect project class and I will enable the project and task to accept charges from other operating units.

Step 1. I created a new operating unit and associated it with Vision Services’ ledger and legal entity

Step 1. I also created a new expenditure organization and linked it to my new operating unit

Step 2. I created a new responsibility for my new operating unit. I could have added my new operating unit to an existing responsibility using a MOAC (Multiple Organization Access Control) profile

Step 2. To allow my new responsibility can access my new operating unit, I updated the MO: Operating Unit profiles

Step 3. To setup the new operating unit in Projects, you’ll need to replicate the seed data into the new operating unit.

Step 4. In the existing operating unit (the operating unit that owns the project), you’ll need to allow cross charges from other operating units

Step 5. The “Allow Cross Charge from other Operating Units” flag is copied from the project level to the task level.

Step 6. The “Allow Cross Charge from other Operating Units” flag at the task level controls which tasks can be charged

Step 7. You will need to setup the Projects’ Implementation Options for the new operating unit.

Step 8. The new operating unit and expenditure organization need to be added to the project hierarchy. I added the new operating unit under the Vision Services organization.

Step 9. To allow my new operating unit to charge projects in the Vision Services operating unit, I added the Vision Services organization to the list of Receiver Operating Units.

Oracle Projects Intercompany Setup Steps for an Operating Unit with a Different Legal Entity

To enable the project in an operating unit with a different legal entity, you need to:

Perform steps 1 – 9 above

10. Associate the new operating unit to the existing operating in the Provider/Receiver Controls form
11. Update Internal Billing tab on the System Implementation form

For my cross legal entity example, I will leverage the same operating unit from the previous example (My New OU).  This operating unit is linked the Vision Services legal entity.  To test the charging across legal entities, I will create a new project (TEST MS CC LE) in the Vision Operations operating unit.  This project will have an indirect project class and I will enable the project and task to accept charges from other operating units.  Please note that you can charge a capital project across legal entities.  So when you perform your test, make sure you use an indirect or contract project.

Step 10. To allow my new operating unit to charge projects in the Vision Operations operating unit, I added the Vision Operations organization to the list of Receiver Operating Units.

Step 10. To allow my new operating unit to charge projects in the Vision Operations operating unit, I added the Vision Operations organization to the list of Receiver Operating Units.

MOAC - Selecting Operating Unit Field

Background on How Oracle uses Operating Units to Support Multiple Business Entities

Before we discuss how to implement MOAC, let’s review how operating units work in Oracle E-Business Suite.  Way back in Release 10.7 Oracle introduced the concept on multi-org, multiple operating units, so companies wouldn’t need a separate database instance to handle different business entities.  For example, if your company has one business entity in US and anther in Sweden, without multi-org you would need to implement Oracle twice.  With the introduction of multi-org, you can use the same Oracle database instance and segregate your US setups from your Swedish setups by operating unit.  Each module you be associated with an operating unit by a unique responsibility.  This works well if your department functions are decentralized (i.e. Sweden has its own AP department).  It doesn’t work well if the department functions are centralized because it causes the user to keep switch responsibilities.

Operating Unit and Responsbilities in 11i

How MOAC Supports Centralized Business Functions

To help organizations with centralized business functions, Oracle now allows you to enter and process data for multiple operating units (without having to change responsibilities).  When you upgrade to R12, the operating unit field will only allow you to enter data for the operating unit associated with the responsibility (the value in the MO: Operating Unit system profile option).  In order to enter in more than one operating unit, you must implement MOAC and associate the responsibility with a MO: Security profile instead of the MO: Operating Unit system profile option.  By using this profile you can now associate multiple operating units to a single responsibility.

MOAC - Operating Unit and Responsbilities in R12

How MOAC links to Multiple Operating Units

When you create a security profile, you can associate operating units by a security type.  Your security type choices are:

1. View all organizations
2. Secure organization by organization hierarchy and or list
3. Secure organization by single operating unit
4. Secure organization by operating unit and inventory organization

MOAC - Security Profile Setup Example

MOAC - Security Profile Setup Example 2

MOAC - Security Types

After you create your security profile, you also need to run the Security List Maintenance concurrent program and assign the role to the MO: Security Profile (under system profiles)

MOAC - MO Security Profile

There’s one caveat when using MOAC and the MO: Security Profile.  The operating units need to share all other profile values.  So if you have a profile like localizations, the values need to be the same across all operating units within a security profile.

Entering Data for Multiple Operating Units

After you enable MOAC for you responsibility, you can select the different operating units associated with that security profile.

MOAC - Selecting Operating Unit from List of Values

How to Login to Oracle’s E-Business Suite

You use a web browser (i.e. Internet Explorer, Firefox) to access the Oracle E-Business Suite login page.  Depending on how you have implemented your sign-on strategy.  You will either use the local login page or the single sign-on login page.  The difference between these two pages is where the login information (user name, password) is stored.  After you enter your user name and password, you will be redirected to Oracle’s home page.

Oracle E-Business Login Page

Using Oracle’s E-Business Suite Home Page

The home page is divided into four sections:  the header, the footer, the navigator menu, and the work list section.  The header and footer sections contain links to favorites page, logout page, preferences page, and the help page.  The work list section contains a list of your workflow notifications (messages to approve or review transactions).  The navigator menu section contains a list of your responsibilities.  This is the list you will use to access the system functions.

Oracle Navigator R12 12.1.3 Homepage

How to Use Responsibilities

A responsibility is a group of application functions that you authority to access.  Responsibilities are using group by module (General Ledger, Payables, Inventory) and level (Super User, Manager, User, Inquiry).  So if you have the Inventory Super User responsibility can access all function in the Inventory module.  If you only have Inventory Inquiry, you can only view certain information in the Inventory module.  In Release 12.1.3, Oracle introduced a hierarchal navigator menu on the Oracle home page.  This menu mimics the Navigator menu used in the Java forms.  At the lowest level of the menu tree, you will see two different icons.  The icon allows you to access web-based applications and the icon allows you to access java-based applications.

Oracle Navigator Menu

Oracle Navigator Menu Expanded

Using E-Business Web-Based Applications

After you click on a <web> icon, you will be open a web page for that function.  Like the Oracle Home Page, the application web page is typically divided into four sections:  a header, a footer, a search region, and a data region.  The header and footer contains links to

1. The Navigator menu (new to release 12.1.3)
2.  Favorites page
3.  Home page
4.  Login page
5. Preference page

Most pages will have a region on the page for searches.  You can enter your search criteria and then click the Go button.  The results of the search will appear in the data region.  Most new functionality in the Oracle E-Business Suite will be in web pages.

Oracle R12 Web Page with Navigator and Favorites Links

Using E-Business Java-Based Applications

After you click on a <java> icon, you will be open a web page that contains a Java applet.  This applet will launch the Java Oracle E-Business Java application and open the window (also called form) was clicked on. The Java application has four main sections:  the menu, toolbar, Navigator menu and application window.  The menu contains the common functions like adding new record or clearing data.  The menu also can contain special functions for the specific form that is open.  This menu is the Tools menu.  Below the menu is the Toolbar, the Toolbar also contains common functions.  Below the toolbar are the Navigator and Application windows.  The Navigator window contains the menu options for your current responsibility.  When you click on the lowest level menu option, Oracle will open the application window that can perform that function.  For example when you click on the “Invoices” menu option, Oracle will open the Invoices application form so that you can enter or query invoices.  The application form will have the look and feel of a typical windows application.  And like an application web page, it can be broken into different sections.  A simple application form may only have two sections (a master/detail layout) but more complex forms have may many sections.  These complex forms are sometimes called workbenches.  You can move around the form using your tab key (the enter/return key will click the active button).  The fields colored in yellow are required fields.

Oracle Java Application Form

Special Navigation for OTM (Oracle Transportation Management) and Demantra

Because OTM and Demantra applications were acquired from other companies, the login and navigation is different than the standard E-Business applications.

Oracle Navigator R12 Homepage from 12.0 to 12.1.2

Oracle Navigator R12 Homepage 12.0 to 12.1.2 with Menu Functions

Oracle Navigator R12 12.1.3 Homepage

Oracle Navigator R12 12.1.3 Homepage with Sub Menu

Another change is the ability to access this hierarchical menu from application web pages.  If you open a web page, you will now see a Navigator icon on the top of the page.  This allows you to access other web pages or Java forms direct from any web page.  This removes the need to go back to the home page to access other functions.

Oracle R12 Web Page with Navigator and Favorites Links

Oracle R12 Web Page with Navigator Menu

Oracle R12 Web Page with Navigator Sub Menu