Real World Oracle Apps

Order Management - Pick Release Concepts

2010-12-17T15:49:00.000-05:00

Release Rules

Release rules define the criteria to be used during Pick Release. Only orders that meet the criteria and are eligible will be released. An order line is eligible if it has completed the prerequisite workflow activities, such as Schedule - Line or Create Supply.

Release Sequence Rules

Release Sequence rules determines the order in which inventory is allocated to sales orders. You choose to allocate by order, outstanding Invoice value, Scheduled Date, Departure Date and Shipment Priority.
The order in which sales orders are filled could be very important. If a company has a problem of running out of material before all of their orders have been filled it is very important that they have filled their most important orders first.

Picking Rules

Picking rules, which are created and maintained in Oracle Inventory, suggest which material to use, based on inventory controls such as revision control, lot control, FIFO (first in first out) or subinventory/locator picking numbers.
Picking rule is an Item Attribute. Create a variety of picking rules and associate them with the appropriate items. If there isnt a Picking Rule associated with the item, the system will use the organizations default picking rule which is found on the Shipping organizations Parameters.
Note: Picking Rules are covered in Oracle Inventory. To learn more see Oracle Inventory users guide.

Pick Slip Grouping Rules

Pick Slip Grouping Rules organize how released order lines are grouped on Pick Slips for ease of picking. For Example: By using the Pick Slip Grouping Rule as Subinventory, the user can reduce the number of trips to a particular subinventory by grouping all lines for that subinventory on to one Pick Slip.

Order Management - Shipping Concepts

2010-12-17T15:41:00.000-05:00

Trip

A trip is carrier specific and represent a unique instance of that carrier leaving your warehouse with deliveries.
The carrier could be a public carrier such as DHL or could be a companys own fleet of trucks.
A trip could represent a truck, air cargo, ship cargo, or railcar. These entities would be set up as items in Oracle Inventory with an item type of Vehicle.
Each trip has a minimum of two stops, pick-up and drop-off.
A trip can be created automatically or manually from the Shipping Transactions form or can be automatically created from the Ship Confirm window. You can also create a trip as a part of a concurrent process.
Companies that use public carriers can enable the system to automatically create Trips as part of of the Ship Confirm process. This eliminates unnecessary transactions.

Stops

A stop is a point along the route of a trip that is due for pick-up or drop-off.
The Ship Confirm process can initiate closing the pick-up stop updating the delivery
status to Intransit.
Manually record all stops made by the Trip using the Shipping Transactions form or
have the Ship Confirm process automatically close a Trip, which creates and closes the
pick-up stop and drop-off stop and changes the Delivery status to Closed.
Companies that use public carries let the system automatically close a Trip as part of Ship
Confirm.

Delivery leg

A delivery leg consists of two stops where the delivery is picked up and dropped off, respectively on the same trip. The delivery might travel through several legs to get to its final destination and is synonymous to the Bill of Lading.
A bill of lading is a receipt, listing all the goods that were signed over to a carrier.
The Ship Confirm window enables you to generate a bill of lading which can then be printed separately or as part of the Delivery Document Set.

Deliveries

A delivery must be created to perform Ship Confirm. It represent all the goods that were shipped from the same warehouse, going to the same Customer location.
The grouping of delivery lines into deliveries is restricted by the grouping rules that are established on the Shipping Parameters - Delivery Tab.
A delivery can be created automatically or manually from the Shipping Transactions form at any time after the order line status has become Awaiting Shipment or can be automatically created during the Release Sales Order process.
A delivery is also automatically created when you invoke the action Pick and Ship or Pick, Pack, and Ship.

Delivery Lines

Delivery lines are sales order lines which have completed all their workflow activities that are prerequisites to Oracle Shipping Execution such as Schedule Line or Create Supply.
Delivery lines are visible from the Shipping Transactions form. They are also visible from the sales order lines Additional Information Deliveries tab.
Delivery lines with similar attributes can be systematically grouped together into deliveries based on grouping rules.

LPNs

LPN, (License Plate Number) are also known as Containers. An LPN can be loaded inside of another container, for example, pack an item into a box and then pack that box onto a pallet.
Optionally LPNs can be setup as inventory items if the shipper is interested in using weight and Volume and packing functionality.
LPNs can be made mandatory using your Shipping Parameters.

Ship From

The ship-from location represents the warehouse that is performing the shipping transaction. A warehouse is an Inventory organization.

Ship to

The Ship To Location represents a Ship-To address that has been setup on the customers record.

Order Management Concepts - Shipping Execution Flow

2010-12-17T13:49:00.000-05:00

After a sales order has been booked, the sales order lines must complete all workflow activities leading up to the shipping activity. Two typical preceding workflow activities are Schedule - Line and Create Supply.

Schedule – Line:

Scheduling the line makes the order lines demand visible to Oracle Inventory for planning. It
also sets the Shipment Schedule Date.

Create Supply:

Variety of subflow paths can be taken within Create Supply Line based on the type of item
shipped. They are as follows:
Configurable Items: Configurable items must complete the Create Supply activity
which takes an order line through a build cycle. The final assemblies that are completed
out of Oracle Work in Process are received into Oracle Inventory as Reserved for a
specific customers order.
Drop ship: Drop ship order lines must complete the Create Supply activity too. After a
Purchase Requisition has been passed to Oracle Purchasing the order line advances to the
Shipping Activity.
Standard Shippable Items: Standard shippable items don't need to perform any of the
Create Supply activities so directly advance to the Shipping activity.

Shipping:

What happens when the order line reaches ‘Ship Line’ workflow activity?

Oracle Order Management calls Oracle Shipping Execution APIs to indicate that a line is Ready to Release.
The sales order line status is changed to Awaiting Shipping. Order lines that are awaiting shipping are called Delivery Lines in the Oracle Shipping Execution module
Pick Release process creates move orders to move items to the staging location and create
reservation in Oracle Inventory
From the staging area shipments are weighed, packed and shipped
Deliveries are Ship Confirmed out of the staging location
When a delivery is Ship Confirmed, Oracle Shipping Execution calls OM APIs to communicate the event, triggering the line flow to move forward

Order Management Concepts - Qualifiers and Modifiers

2010-11-11T14:38:00.000-05:00

Qualifiers:

A qualifier defines eligibility rules for modifiers and price lists.

A qualifier can be a customer name, a customer class, an order type, or an order amount that can span orders.

Though a qualifier may be set up independently, it comes into effect only when linked to a modifier or a price list. Thus, the modifier that is set up and linked to a qualifier determines who the price adjustment will affect as well as the amount that will change.

You can create qualifier groups to apply individual qualifiers as a set. When you group qualifiers, they become a set, which allows for faster searching and setup.

Modifiers:

Modifiers determine the adjustments made to the list price. These are dependant on various business factors such as the type of adjustments to make, the level at which the adjustments are made, how the modifiers are qualified, how they are applied, etc. You can create three modifier list types in Oracle Pricing:

Discount List
Surcharge List
Freight and Special Charges List

There are four modifier line types available in Oracle Pricing:
Discount
Surcharge
Freight and Special Charges: Amount applied to the customer invoice for movement of a shipment to a destination
Price Break: Only point price breaks are allowed in Basic Pricing modifiers. For example, the following pricing decisions are:

If Item Quantity = 1-50, then discount = 5%
If Item Quantity = 51-100, then discount = 7%
If Item Quantity is between 101 and 99999999999, then discount = 10%.
So if the ordered item quantity is 110, then the discount applicable is 10%.

Modifier controls are of the following types:
Pricing Event is a time in the process flow of the calling application at which it makes a call to the pricing engine (analogous to an Oracle Workflow event); for example, Book Order in Order Management.

Pricing Phase is a user-defined group of modifiers that the search engine considers together when applying them to pricing requests, for example, Phase 1: Line Adjustments.

Incompatibility: In any given level within the same phase, the system only allows one modifier to be selected. The pricing engine may retrieve more than one modifier that meets the calling request and can be applied. There are three methods to resolve incompatibilities within the modifiers that the pricing engine retrieves:

Precedence
Best price
Exclusivity

Incompatibility Level: Each modifier has an incompatibility level. If there is more than one modifier line with the same incompatibility level, the pricing engine selects the one with the highest precedence. If there is more than one modifier with the highest precedence in an incompatibility level, the pricing engine selects the modifier that provides the best benefit to the customer.

In Basic Pricing, users cannot add additional phases or events, and incompatibility level and buckets are defaulted.

Order Management Concepts - Basic Vs Advanced Pricing

2010-11-11T14:29:00.000-05:00

Oracle offers two levels of pricing functionality: Basic and the separate enhanced product, Advanced Pricing. While both levels of functionality share some similarities, the licensed Advanced Pricing application extends the ability to adjust pricing.

Price Lists:
The creation of price lists within both levels carries many of the same elements. Both are able to add items to, and copy price lists. However, as you implement Advanced Pricing, the ability to use Qualifiers, Pricing Attributes, and Secondary Price Lists becomes extended from only allowing the default or one context element in Basic, to an unlimited number of values being available.

Agreements:
The use of Agreements is the same for both Basic and Advanced Pricing. They are both able to identify customer items, create price lists, use versioning, and define price breaks.

Formulas:
Both Basic and Advanced Pricing allow Static Formulas, while only Advanced Pricing allows the use of Dynamic Formulas.

Modifiers:
While both basic and Advanced Pricing have the ability to execute Discounts, Surcharges, Freight Charges, and point-based price breaks, Advanced Pricing extends this functionality greatly. Advanced Pricing also allows price modifications via Coupons, Terms Substitution, Promotions, Item Upgrades, and Other Items discounts. Additionally, Advanced Pricing
allows you to implement adjustment functionality that will change the list price used for the adjustment; affect the timing of when the adjusting activity will occur; and enable you to define rules affecting which adjustments may be used at the same time. In Advanced Pricing,
you can also flag discounts as exclusive, which implies that only that discount will be eligible and no others.

Note: Additionally, Advanced Pricing enables you to derive prices from external sources. For further information on the Advanced Pricing functionality, please refer to the Advanced Pricing User and Implementation Manuals.

Oracle 12i functionalities in depth

2010-03-30T11:37:00.003-04:00

In the next few weeks I will be focusing on new functionalities introduced by Oracle 12i in the following areas:

1. Financial Management

a. Across Financials

i. Oracle Financials Concepts and Implementation

b. Assets and Real Estate

i. Oracle Assets

ii. Oracle iAssets

c. Cash and Treasury

i. Oracle Cash Management

ii. Oracle Treasury Management

d. Credit to Cash (Receivables)

i. Oracle Receivables

ii. Oracle iReceivables

iii. Oracle Advanced Collections

iv. Oracle Trading Community Architecture

e. Financial Control and Reporting

i. Oracle Advanced Global Intercompany System

ii. Oracle Financial Consolidation Hub

iii. Oracle Financial Accounting Hub

iv. Oracle General Ledger

f. Financial Common Modules

i. Oracle E-Business Tax

ii. Oracle Subledger Accounting

g. Oracle Internet Expenses

h. Procure to Pay (Payables)

i. Oracle Payables

ii. Oracle Payments

2. Projects

a. Oracle Projects Fundamentals

b. Oracle Project Costing

c. Oracle Project Billing

d. Oracle Project Management

e. Oracle Project Portfolio Analysis

f. Oracle Project Resource Management

Project Manufacturing Fundamentals - Part 2

2010-03-03T13:45:00.001-05:00

8. What is the use of Profile INV: Project Miscellaneous Transaction Expenditure Type?
This profile Governs the entry of expenditure types for project miscellaneous transactions.
Values that are available are:
User Entered (Default value): If the profile is set to User Entered, the user has to enter expenditure types for project miscellaneous transactions.
System derived from cost elements If the profile is set to this value, user cannot enter the expenditure types for project miscellaneous transactions.

9. Parameters that are to be given or can be used to verify if an organization is PJM enabled or not?
1. Organization has ‘Project Manufacturing Organization’ classification defined in Organization form.

2. Check that Project Cost Collection Enabled (check box) is enabled in Organization Parameters form under Costing Tab. This indicates whether subinventories can be associated with a given project and task.

3. And Enable Project References check box, located in the Project Manufacturing Parameters form, is also selected. So the cost collector process can transfer costs to project accounting.

10. How can we create User defined transaction types for a project?
At the time of creation of User defined transaction type we need to check the Project Check box.

11. What are the Project locators and common locators ?

Oracle Project Manufacturing reserves segment19 and segment20 of the Stock Locator key flexfield to store the project and task numbers.

Project Locator A project locator is a locator with a project or project and task reference. It is also a logical partition of a physical location. Project locators are used to track project hard pegged material. Project inventory needs to be stocked in a project locator and needs to be transacted in and out of a project locator. Since locators can be dynamically created, it is not necessary to predefine project locators.

A project locator must be tied to the same subinventory as its corresponding physical locator. For non-project Locators, physical_locator_id and inventory_locator_id are supposed to be same or physical_locator_id may be null , but inventory_locator_id is populated always.

Common Locator
A common locator is a locator without a project or project and task reference. It is also a
real, physical location. Common locators are used to track common (soft pegged)
material.

12. What is the common validation done for Project locators ?

The system validates the project and task segments of a locator based on the value of the
Project Control Level parameter you set up in Organization Parameter as described in the following
table –

Project Control = Null, Level Project Segment = Cannot enter any value, Task Segment = Cannot enter any value

Project Control = Project, Level Project Segment = Optional, Task Segment = If Project is entered, Task is optional. If Project is not entered, Task cannot be entered.

Project Control =Task, Level Project Segment = Optional, Task Segment = If Project is entered, Task is mandatory.If Project is not entered, Task cannot be entered.

Project Manufacturing Fundamentals - Part 1

2010-03-03T13:12:00.000-05:00

1. What is PJM Manufacturing and what kind of industries it is employed in ?

Oracle Project Manufacturing supports companies in the Engineer-To-Order, Make-To-Order, Seiban, and Aerospace and Defense industries. These industries plan, track, procure, and cost based on project, contract, or Seiban numbers.

2. Project Setup

A project is a primary unit of work that you can break down into one or more tasks. You charge the transactions you enter in Oracle Projects to a project and a task. When you set up a project, you must set up the work breakdown structure (WBS), and enter project and task information.

After your project structure and budgeting have been defined in Oracle Projects, you need to define the Project Manufacturing parameters for your project.

3. What activities are involved during Project Manufacturing execution phase ?

The execution system addresses the inventory, shop floor, and procurement activities.

4. What are the diff. flows which can be performed for PJM org in Order Management ?

Oracle Project Manufacturing supports:

• Project Sales Orders Oracle Order Management enables user to link sales order lines to projects and project tasks.

• Project Return Material Authorization (RMA) Oracle Order Management enables user to process Project RMAs using the line type category ‘Return.’ Examples of the line types available are return for credit without receipt of goods, return for credit with receipt of goods, and return for replacement.

• Project Assemble-To-Order (ATO) and Pick-To-Order (PTO) Oracle Project Manufacturing enables user to use Oracle Configurator with Oracle Order Management with propagation of project and task on the configured

model, options, and included items. For ATO, the Final Assembly Schedule process creates a WIP Job with the configuration’s project and task.

• Project Drop Shipments You can specify a project and task on a sales order line and use drop shipment to automatically create a project purchase requisition. Drop-shipped materials ship directly from supplier to customer.

• Project Fulfillment Oracle Order Management and Oracle Shipping Execution support delivery-based shipping with user-definable picking rules for order fulfillment. After manufacturing is complete, finished goods are picked automatically from the project inventory upon pick release. You can also pick all items for a project and task.

• Project Order Import If you use external systems to capture order information you can use Order Import to import external sales orders or quotations, including project and task references.

5. What are the various activities which can be performed in WIP for PJM org ?

• Project WIP Jobs You can create WIP Jobs with project/task references. Project Manufacturing supports standard and non-standard WIP Jobs. You can create Standard Project WIP Jobs automatically.

• Project Outside Processing You can use existing outside processing functionality to support Project Outside Processing. The system transfers the project/task on the work order once the outside processed purchase requisition generates.

• Project Repair Orders You can link non-standard WIP Jobs to a project / task to capture project repair.

• Project Flow Schedules You can use flow schedules in a work order-less production environment.

6. What features are supported for Project Procurement ?

• Project Requisitions You can create requisitions with project/task references. You can define project requisitions for inventory and expense destination types.

• Project Purchase Orders You can create purchase orders with project/task references. You can define project purchase orders for inventory and expense destination types.

• Project Blanket Releases You can create purchase blanket releases with project/task references.

• Project RFQs You can create purchase Request For Quotations (RFQ) manually or auto-create an RFQ from a requisition.

7. What different types of Project Material transactions one can perform in Inventory ?

Tracking inventory by project and dealing with permanent and temporary transfers from one project to another or from common inventory to project inventory is essential for a project-based environment. Oracle Project Manufacturing supports:

• Project Inventory You can use project locators to segregate inventory by project. Purchase order receipt locators validate automatically for project purchase orders. You can reference existing project locators or dynamically create project locators upon receipt. The issue, back-flush, and completion locators validate automatically for project WIP jobs and associated material. Similar logic applies in processing flow schedules using work order-less completions.

• Project Material Transactions You can use existing material transactions such as Miscellaneous Issue/Receipt, Move Orders, PO Receipt, WIP Issue, WIP Return, and WIP Completion.

• Permanent Project to Project Transfers You can use project transfer transactions to transfer material from one project to another with appropriate transfer of inventory value.

• Temporary Project to Project Transfers You can use borrow payback transactions to borrow material from one project to another, and ensure payback against the original value.

• Common-to-Project and Project-to-Common Transfers You can use project transfer transactions to transfer material from common inventory to project inventory and vice versa, with the appropriate transfer of inventory value.

• Project Mass Transfers You can use the mass transfer wizard to initiate the mass transfer of material from one project to another based on criteria you define, with the appropriate transfer of inventory value.

• Consigned Material from Supplier You can perform implicit and explicit consumption of consigned items to demand/supply documents with project references, with appropriate transfer of inventory value into a project.

Customer model in Oracle 11i

2010-01-13T17:58:00.001-05:00

Features of Customer Model:

• The 11i customer model is build to handle the new requirements of CRM and e-commerce. These new requirements introduced new features and user interfaces for the 11i Customer Model

• The customer model is based on a new foundation that provides for a number of important new features in Release 11i+ and Release 12

• The 11i Customer Model handles customer types of organizations and people.

• Modify customer form to match against and link with global registry

• Establish global registry of organizations, people, locations, and the relationships among them

Global: Parties, Party sites, Locations, Customer accounts
Org-Specific: Customer account sites

• Customer addresses do not have to be duplicated across operating units -- they can be created once then referenced by different operating units

• Provides foundation for linking suppliers and customers in future.

• AR customer modules do not expose all capabilities and attributes from new model

• Party Registry

 Information about your different relationships are tied to one “source of truth” representation of the person or business
 A Party is anything that can enter into business relationships with another party

• Customer Addresses

 Multiple parties can do business at one location
 Addresses are global, not specific to operating units
 Address validation using Vertex or Tax Ware information
 Flexible address formatting with seeded and custom formats

Oracle Assets - Business Scenarios for CRP's

2009-08-25T09:00:00.000-04:00

ADDITIONS :
Create Mass Addition via EPI AP (eg: Computer Equipment, vehicle, land, Office furniture)
Create Mass Addition via PA (EPI)
Create Mass Addition via ADI
Mass Addition (via PO with unit # greater than 1)
Mass Addition (via PO with item #)
Create Mass addition : Split a single invoice line to multiple assets
Create Mass Addition : Merge different invoice line to one asset
Create Mass Addition : Add to existing asset
Update mass addition information : serial number, tag number
Create Assets (post mass addition)
Add assets to subledger in detail
Add assets to subledger with quick addition
Additions of monthly Service Units and Metres (length of Services line) -

New units and metres
Relay units and metres
Adding Inactive Service record

ADJUSTMENT
Update descriptive information (eg description, serial number, model number, manufacturing number)
Updating quantity and costs for Mass Property accounts through AP.
Updating quantity for Mass Property accounts through other interfaces
Process adjustments to prior year asset costs
- asset-detail accounts e.g 472
- mass property accounts units and amount e.g. 475
Adjust NBV and accumulated depreciation

TRANSFER :
Transfer assets between LOB
Transfer assets between FA Book
Transfer assets between Employee
Transfer assets between Location
Mass Transfer between LOB
Mass Transfer between Employee
Mass Transfer between Location

RECLASSIFICATION
Reclassification (category)

RETIREMENT
Retirement on single asset (by cost)
Retirement on single asset with vintage pool
Retirement on single asset (by unit)
Mass Retirement by date place in service /vintage year
Mass Retirement by location
Mass Retirement by category
Mass Retirement from spreadsheet (ECG)
Mass Retirement by asset number
Retirement reversal of a single asset by cost
Retirement reversal of a mass property asset by units.
e.g: 475
Asset-detail partial retirement
FIFO retirement of mass property account
Mass retirement of asset-detail
- retire small tools and work equipment over 15 years
Retiring Inactive Service record

DEPRECIATION
Monthend closing – Depreciation Run
Change Depreciation rate
Review catch up depreciation calculation
Run/review journal entry reserve report
Add multiple depreciation rates
- 3 decimal places
Amortization of lease-hold account and computer software assets
Perform back-dated depreciation

PROCESS JOURNAL ENTRIES
Generate GL journal entries
Review Asset Addition JE, Transfer JE, Adjustment JE, Retirement JE, Depreciation JE

REVALUATION
Set up revaluation book
Run Revaluation (Midcoast/LPL)

INQUIRE ASSETS
Inquire assets based on category
Inquire assets based on location
Inquire assets based on employee
Inquire assets based on asset number
Inquire assets based on FA Book
Inquire assets based on historical project # (ie serial #)
Inquire assets based on storage tank unit # (ie. Manufacturer information)
Drill down to asset source detail
Cross referencing asset group
e.g. Land and building,
Calculate life-to-date, year-to-date and current month depreciation

YEAR END
Plant Asset year-end Allocations
Asset-detail Accounts:

1. allocate all miscellaneous costs within each
2. asset-detail account for current fiscal year.

Plant Asset year-end Allocations
Mass Property Asset Account Allocations

1. allocate all current year miscellaneous costs to current year installed service sizes within regions.
2. allocate all current year miscellaneous costs to current year installed main sizes within regions.
3. allocate all current year miscellaneous costs to current year installed sales stations within regions

Option: Use Project Accounting to handle the costs. (common cost)

Oracle R 12 GL Implementation - Auto Offset in Payables works even if Dist Acct’s Balancing Segment belongs to a different Legal Entity

2009-04-20T09:13:00.006-04:00

R12 Functionality:

1. Primary Ledger can be associated with Multiple Secondary Ledgers
2. Primary Ledger can be assigned to Multiple Legal Entities
3. Primary Ledger can be assigned to Multiple Operating Units
4. An Operating Unit is tied to the Primary Ledger through the Legal Entity Context
5. Specific Balancing Segment Values are assigned to specific Legal Entities in the Primary Ledger
6. Payables supports the auto offset features wherein the Balancing Segment of the Trade Liability Acct will equal the Dist Acct’s Balancing Segment
7. Payables allows the selection of Balancing Segment values not assigned to the Legal Entity that owns the Operating Unit in the Distribution Window
8. Accordingly, it also allows the selection of the corresponding balancing segment when it builds the Trade Liability Account
9. Question: What is the specific purpose of assigning Balancing Segment Values to the Legal Entity in Accounting Manager Setup (as once assigned, the same value is not allowed to be selected for any other Legal Entity), if this value is usable for the Operating Unit(s) that does not have this Legal Entity Context?

Summary of key facts:

1. Common COA Structure used for Primary and Secondary Ledgers
2. Ledger shared by Multiple Legal Entities
3. Specific Balancing Segment Values assigned to Specific Legal Entity (Overlap not allowed)
4. Specific Legal Entity Vision Operations Assigned to Payables Manager OU for Legal Entity Context
5. User preference set to Access Vision Operations OU by Default in Payables

Conclusion and Findings:

1. Balancing Segment Value Assignment to the Multiple Legal Entities, sharing the same Ledger does not seem to restrict the user of these Balancing Segment Values in the Feeder, Operating Unit specific Modules Like AP, wherein Legal Entity Context is passed to the OU through the link of the Primary Ledger
2. However, access to these Balancing Segment Values could be controlled through Security Rules being assigned to the Value Set and the Respective Responsibility
3. The Key question is: If Legal Entity having the context to the Operating Unit that shares the common Ledger does not have assignment to it, what impact it has on the integrity of data when this access is otherwise allowed, except through Security Rules?

Oracle Project Costing - some new features in 11.5.10.2

2009-03-19T16:19:00.003-04:00

Business Challenges:

It’s difficult to get information when you need it:

Transactions come from many sources
•Labor costs are captured in time entry systems
•Supplier cost is captured in Accounts Payable
•In many industries, the majority of cost is captured in manufacturing
•Frequently Indirect and Overhead costs must calculated and applied manually

In order to manage to budget, you need to track outstanding commitments as well as amounts spent.

In a Global Environment, you have to process and translate foreign currency transactions and if you are sharing resources across organizations, you have to process intercompany adjustments to account for cost reimbursement and revenue sharing agreements.

For Capital Projects, you have to ensure that cost is allocated to assets appropriately and you have to track your different types of cost: Construction cost (CIP), Cost of Removal, and Proceeds of Sale.

How do you accomplish these things in a timely manner, Project Costing can help.

New Features for Oracle Project Costing:

•Capital Projects Enhancements
–Create and Assign Assets using AMG
–Automatically Allocate Indirect and Common Costs
–Calculate Interest on CIP Cost
–Periodically Group Cost and Assets for Capitalization
–Automate Retirement Cost Processing
•Labor Costing Enhancements
•Cross-Charging Enhancements
•Burdening Enhancements
•MRC Schema Elimination
•PO/AP Integration

Create and Assign Assets using API’s:

# To enable integration with external asset management systems, project asset API’s have been added to the Activity Management Gateway
# The new API’s allow you to create, update and delete project assets and project asset assignments

Automatically Allocate Indirect and Common Costs:

It is sometimes necessary to apply cost to multiple assets. For example, if you are replacing wooden light poles with new steel ones and each pole is an asset, you need to distribute labor costs across the number of poles replaced. If all the poles are the same, you can just spread the cost evenly, but if some poles are longer than others, you may want to distribute based on the cost of the pole, recognizing that the longer poles no only cost more and require more time to install.

Project Costing now supports the predefined cost allocation methods displayed here. In the past, unless you were using a consulting solution, all indirect and common cost had to be manually allocated across assets.

The following new predefined allocation methods are now supported:
•Spread Evenly
•Actual Units
•Standard Unit Cost
•Estimated Cost
•Current Cost
•Client Extension

Periodically Group Costs and Assets for Capitalization:

Assets placed in service within a period and cost collected for the period can be grouped together for capitalization.

For repetitive jobs and phased projects, Project Costing has introduced Capital Event Processing. Assets placed in service within a period and cost collected for that period can be grouped together for capitalization.

Continuing our light pole example, if you placed 100 poles in service in January, you can now automatically assign all cost collected in January to those new poles and send the information to Fixed Assets to begin capitalization. In February, you repeat the process; the cost for February is associated with the new poles installed in February and sent to FA.

Process Retirement Costs:

Project Costing has added support for retirement cost processing.
You can now track retirement costs by identifying retirement tasks and generating retirement asset adjustments to be sent to Fixed Assets.
You can improve the accuracy of the adjustments by also tracking Proceeds of Sales. Let’s complete the light pole example, it you sale the old wooden poles for firewood, you can subtract the proceeds of these sales from the cost of removal when you generate the retirement asset adjustment lines.

Identify retirement assets:
•Assign asset group number to project or task
Identify retirement tasks
Classify retirement costs
•Use expenditure categories and/or expenditure types to track Costs of Removal and Proceeds of Sale
Generate retirement asset lines and prorate common costs

Calculate Interest on CIP Costs:

We all know there is cost associated with funding a project. If you borrow money, you have to pay interest. If you invest your own funds, you lose dividends.

In many industries, you are allowed to capitalize all or a part of this cost. So Project Costing has added a feature that allows you to generate interest expenditure batches based on the open CIP balance.

Labor Costing Enhancements:

To reduce maintenance and overhead and pave the way for some future integration, Project Costing has redesigned the labor costing model.
You now maintain rates in rate schedules and can enter rates by employee or by job.
Labor Costing Rules define how labor cost is calculated. You can select a costing method of Rates or Client Extension. You can also apply cost multipliers to overtime expenditure types without implementing the overtime extension.
Costing rules and rate schedules are then assigned to organizations. You are no longer required to enter an assignment for each employee.
However, when necessary, you can enter overrides at the employee level. You can override the assigned rate schedule or you can enter an overriding rate value.

Cross Charge EnhancementsDescription:

Prior to Family Pack-K Rollup, cross charge transactions were converted to the reporting currencies of the Provider Operating Unit only. After Family Pack-K is installed, transactions are converted to the reporting currencies of both the Provider and Receiver Operating Units.
An upgrade script is provided with this patch to convert existing cross charge transactions to the reporting currencies of both the Provider and Receiver Operating Units.

Burdening Enhancements:

Many customers reported that we needed to improve the burdening process; that moving from provisional to firm rates was taking too long and generating too much database volume.
So we made the process smarter and we added an option that allows you to create incremental adjustments.
When you modify a schedule we now track your changes and only mark the transactions impacted by those changes for recalculation.
Ad if you choose to use the incremental option, we no longer reverse the original accounting entries; we just create incremental entries for delta amounts.

MRC Schema Elimination:

Oracle Projects now allows you to use a single responsibility to perform the following:
•View amounts in Primary and Reporting Currency
•Generate Reports in Primary and Reporting Currency
•Interface Primary and Reporting amounts to GL

Supplier Invoice Adjustment:

Oracle Projects now allows you to adjust supplier invoice expenditures that are matched to accrue on receipt purchase order lines
When the adjustment is interfaced from Oracle Projects to Oracle Payables, the following occurs:
•Two New Invoice Distributions are created
–A distribution created to reverse the accrual against the PO charge account
–A distribution is created to record the expense with the adjusted project attributes
•AP Generates Tax for the new Distributions

Oracle 12i - How to create accounting and transfer JE's to GL using SLA

2009-02-21T14:11:00.005-05:00

I. Create Accounting Program:

The Create Accounting program processes eligible accounting events to create subledger journal entries. To create the subledger journal entries, the Create Accounting program applies application accounting definitions that are created in the Accounting Methods Builder (AMB).

The Create Accounting program:
•Validates and creates subledger journal entries
•Optionally transfers the journal entries to GL
•Optionally posts the journal entries in GL
•Generates the Subledger Accounting Program Report, which documents the results of the Create Accounting program

Draft Accounting:
When you select draft accounting, Subledger Accounting creates the relevant journal entries in draft mode. Draft entries are not posted to General Ledger. You can review the resulting entries, update the transactions, or update the accounting rules. Any changes will be reflected when the transaction is processed again for accounting.

Online Accounting (Final):
Final entries are ready to be transferred to General Ledger and cannot be modified. The transactions are considered as processed for accounting. Any changes to the rules will not impact final entries.

Straight-Through Accounting (Final - Post):
If you select Final Post, Subledger Accounting posts the journal entries all the way through to General Ledger. This means that you can update GL balances straight from the invoice entry (or any other transaction entry) window.

Create Accounting Program:
The Create Accounting program creates subledger journal entries. In general, the parameters described in the table above determine which accounting events are processed.
Navigation Paths (example Payables)
Payables: Other > Requests > Run
Receivables: View > Requests (B) Submit a New Request

Paramaters:

1. Ledger - Required; limits accounting events selected for processing to those of a particular ledger. This program is run for primary ledgers or valuation method enabled secondary ledgers. Any reporting currency or secondary ledger associated with the selected primary ledger is also processed; i.e. entries are generated for the selected primary as well as reporting currencies and non-valuation method secondaries.

2. Process Category - Optional; restricts the events selected for accounting to a particular process category. For example, Invoices.

3. End Date - Required; end date for the Create Accounting program; processes only those events with event dates on or before the end date

4. Mode (Draft/Final) - Required; determines whether the subledger journal entries are created in Draft or Final mode

5. Errors Only (Yes/No) - Required; limits the creation of accounting to those events for which accounting has previously failed

6. Report (Summary/Detail/No Report) - Required; determines whether to generate a report showing the results of the Subledger Accounting program in summary or detail format

7. Transfer to General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to transfer the subledger journal entries to General Ledger

8. Post in General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to post subledger journal entries in General Ledger

9. General Ledger Batch Name - Optional; user-entered batch name that appears on the transferred General Ledger subledger journal entries. Transfer to GL option must be set to Yes.

10. Include User Transaction Identifiers (Yes/No) - Required; controls whether the report displays user identifiers' names and values.

Create Accounting Program:
The Create Accounting program generates one or more accounting programs depending on the volume to be processed. The Subledger Accounting Program report is generated by the Create Accounting program and documents the results of the Create Accounting program. It lists the following:
•Successful events and the subledger journal entries created for those events
•Errors for failed events
You can run the report in summary, detail, or no report mode which are described as follows:
•Summary mode provides a summary of events processed and detailed information about their errors.
•Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.
•No report mode will show an error count without actually generating the report.

II. Transfer Journal Entries to GL Program:

The Transfer Journal Entries to GL program enables you to transfer any eligible journal entries to General Ledger, including those from previous runs that have not yet been transferred to General Ledger.

Note: This program is used if you run accounting online in Final mode (not Final Post) or if you run the Create Accounting program and set the Transfer to GL parameter to No.

The only reason you would want to run the Create Accounting program and set the Transfer to GL parameter to No is if you want to run accounting at different intervals than the GL transfer, for example, you may run accounting every hour but only transfer to GL nightly.

The Transfer Journal Entries to GL program consists of a subset of parameters used in the Create Accounting program as listed below:
–Ledger
–Process Category
–End Date
–Post in General Ledger
–General Ledger Batch Name

III. Oracle Subledger Accounting Program Report:

The Subledger Accounting Program Report is generated by the Create Accounting program and lists the following:
•Successful events and the subledger journal entries created for those events
•Errors for failed events

You can run the report in summary or detail mode as follows:
•Summary mode provides a summary of events processed and detailed information about any errors.
•Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.

IV. Transfer Journal Entries to GL Report:

The Transfer Journal Entries to GL report is generated by the Transfer Journal Entries to GL program and lists the following:
•Transfer to GL Summary
•Errors

Setting Profile Options:
The profile options listed above relate to data access and security and impact how accounting is generated through SLA in R12.

1. SLA: Enable Subledger Transaction Security in GL
•Use this profile option to combine subledger transactions security with data access security for General Ledger responsibilities when drilling down to multi-organization enabled subledger application. Transaction security in the respective subledger application is always applied when drilling down from subledger transactions to subledger journal entries.

2. SLA: Enable Data Access Security in Subledger
•This profile option determines whether the General Ledger Access Set security mechanism is applied for a subledger application responsibility when viewing, reporting, or creating subledger journal entries associated with a given ledger. The General Ledger Access Set security mechanism is always applied for responsibilities associated with the General Ledger application.
•The profile option enables you to combine data access security with subledger transaction security and therefore control access to subledger journal entries depending on the ledger to which they belong. For example, you can implement a Multi-Org Security Profile that allows you to create Oracle Receivables Invoices for two different operating units each associated with different ledgers but restrict drill-down from the subledger transaction to the associated subledger journal entry based upon the destination ledger contained in the Access Set.

3. SLA: Additional Data Access Set
•The SLA: Additional Data Access Set profile option, in conjunction with the GL: Data Access Set profile option, controls which ledgers and balancing or management segment values you can access when logging onto a responsibility. If SLA: Enable Data Access Security in Subledgers is enabled for the responsibility, you have access only to the ledgers and balancing or management segment values included in the data access sets assigned to the SLA: Additional Data Access Set and GL: Data Access Set profile options.

4. SLA: Allow Reports Journal Source Override
•This profile option applies only to the following reports:
-Open Account Balances Listing
-Third Party Balances Report
•Enable this option to change the Journal Source parameter during report submission. If the option is set to No, then you cannot change the value defaulted during report submission.
For example:
•Should the general ledger data access set security be enforced when generating accounting? For example, should journal entries be created if the user does not have ledger clearance even if they may have multiorg access to the operating unit?
•Should the transaction security model be applied when drilling down from GL? For example, should the user be allowed to inquire on journal entries of certain operating units if they do not have MO access, but have ledger clearance?
•If there are secondary ledgers and data access set security is enforced in the subledger module, then an additional data access set needs to be assigned to the user to enable access to the secondary ledger.
•Should the user be able to run certain reports across data from multiple subledger applications?

Oracle AR 12i - how to configure and use Credit Card Chargeback features

2009-02-17T17:09:00.002-05:00

Credit Card Chargeback:

A credit card chargeback takes place when a credit card holder disputes a charge with the credit card company (e.g. VISA) and the credit card company issues a chargeback to the customer for the disputed amount and notifies the vendor that they have issued a chargeback to the customer.
A cardholder can request a charge back for many reasons including, but not limited to:
•Charges for undelivered goods
•Charges for goods or services different from what was ordered or if they received the wrong quantity of the goods or services ordered.
•Charges for goods that were not timely delivered

In release 11i, we already have the functionality for the vendor to issue a chargeback directly to the customer. The customer can however also request a chargeback from the credit card issuer, so in release 12 - we are introducing the functionality for the vendor to also be able to register and process a chargeback that a card issuer has already issued to the customer.

Benefits:
•Reduce costs by automating the credit card chargeback process

Credit Card Chargeback Process:
After having received the credit card chargeback notification from the card issuers, the vendor will:
•Find the receipt for which the chargeback was requested.
•Un-apply the application line and subtract the amount of the credit card chargeback.
•Apply the credit card chargeback activity on a new application line on the receipt. This automatically generates a negative miscellaneous receipt to the value of the chargeback.

If the vendor finds the chargeback to be valid, the vendor creates a credit memo to credit the invoice with the amount charged back.

If the vendor can prove to the credit card company that the chargeback was not valid, the vendor reverses the application of the credit card chargeback by:
•Finding the receipt
•Un-applying the credit card chargeback activity from the receipt. This automatically reverses the negative miscellaneous receipt
•Restoring the original amount on the application line.

It is important to understand how our new Credit Card Chargeback functionality differs from the Credit Card Refunds we already have in 11i:
•Credit card refunds: The merchant needs to refund the customer. So the negative misc. receipt must be remitted.
•Credit card chargebacks: The customer has already received the chargeback, so the vendor will just need to record that a chargeback has taken place. The purpose of the misc. receipt is just to keep the accounting in place.

Business Process Steps:
The business process that takes place when a credit card chargeback needs to be recorded is a three step process:
1.The vendor receives the receipt, records it and applies it to the invoice.
2.The vendor receives the Credit Card Chargeback notification and records the credit card chargeback by applying the credit card chargeback to the receipt
3.The vendor then needs to investigate if the Credit Card Chargeback is valid or not. Based on the outcome, the vendor can choose to either:
-Acknowledge the credit card chargeback and credit the invoice, or
-Prove that the credit card chargeback was not valid, and after acknowledgement un-apply the credit card chargeback from the receipt

Credit Card Chargeback Process Receive Receipt:
Example:
•A customer visits a web store and orders goods for $100 using their credit card
•The credit card company authorizes the payment and notifies the vendor of the receipt of $100
•The vendor processes the receipt and applies it to the invoice.
Please note that there are no changes in how these activities are carried out in R12.

Let’s now take a look at the credit card chargeback process.
•The customer receives the goods, but finds that goods for $25 are missing.
•The customer files a dispute with the credit card company for $25
•The credit card company credits the customer $25 and notifies the vendor that a chargeback of $25 has taken place.
•The vendor applies the credit card chargeback to the receipt which generates a miscellaneous receipt to decrease cash with $25
Here we can see how the clearing account for the receivable activity of type ‘Credit Card Chargeback’ is used. It gets credited when the credit card charge back is applied and gets debited when the misc. receipt is generated.

Accounting Entries:

•Un-apply the receipt
–DR Receivables $25
–CR Unapplied $25
•Apply the credit card chargeback
–DR Unapplied $25
–CR Credit Card Chargeback $25
•Misc. receipt is generated
–DR Credit Card Chargeback $25
–CR Cash $25

Chargeback Process for Vendor:
1.Find receipt
2.Un-apply the receipt
3.Decrease the value on the receipt application line to $75
4.Apply $25 to receipt activity ‘Credit Card Chargeback’ (creates a negative misc. receipt of $25)

Validate Credit Card Chargeback:
After the vendor has analyzed the credit card chargeback, the vendor can find the credit chargeback to be either valid or invalid.
The vendor can now either:
•Acknowledge the credit card charge back and credit the invoice.
•Prove to the credit card company that the credit card chargeback was invalid and un-apply the credit card chargeback from the receipt once it has been acknowledged by the credit card company that the credit card chargeback was invalid.

If the vendor acknowledges the credit card chargeback, the vendor simply credits the invoice by creating a credit memo for $25.

•Credit the invoice by creating a credit memo
–DR Revenue $25
–CR Receivables $25

Vendor proves the chargeback to be invalid:

•Un-apply the credit card chargeback
–DR Credit Card Chargeback $25
–CR Unapplied $25
•Misc. receipt is automatically reversed
–DR Cash $25
–CR Credit Card Chargeback $25
•Reapply the receipt
–DR Unapplied $25
–CR Receivables $25

Credit Card Chargeback Setup:
•Responsibility: Receivables
•Navigation: Receipts > Receipts > (B) Apply > Applications > (B) Chargeback
Release 12 comes with the seeded Receivables Activity Type of ‘Credit Card Chargeback’.
The only setup step required is to create a new receivables activity of type credit card chargeback and specify the GL clearing account for the new activity.
Note: Only one activity of this type can be active.

Balance Forward Billing in Oracle AR 12i

2009-02-17T11:16:00.002-05:00

Balance Forward Billing in 12i:

Balance Forward Billing replaces Consolidated Billing feature with enhancements to bill creation and presentation.
•Billing Cycles
-Billing cycles are no longer just monthly. Easily create daily, weekly, monthly, bi-monthly, quarterly, and annual billings
-Bill on specific days of the month. User can not only specify the day of the month for the billing date, or even multiple days like “every 15th and last day of month”. User can also elect to bill on a specific day of the week, such as every Friday.
-Choose to exclude weekends. User can skip weekends when determining billing dates, so billing dates only fall on workdays
-For importing transactions with specific dates, there is an External Billing Cycle
•Consolidate invoices at different customer levels
•Activity can be consolidated across account sites, or by each billing site. This means one bill can be sent for each billing location, or a single bill can be sent incorporating all invoices for that customer account within an organization
•Not all billing sites for a customer must consolidate their invoices. A site can be excluded from the account level bill. If a site prefers to receive individual invoices, that site can be excluded from the Balance Forward bill.
•specific invoices can be excluded from the Balance Forward Bill. By changing the payment term on an invoice, it can be printed separately

Enhanced viewing and printing:
•Balance Forward Billing integrates with Oracle Bill Management, which provides formats with a more appealing layout that can be easily modified.
In 11i, there are five consolidated bill programs. The new feature consolidates these programs into three.

Benefits:
1. Flexibility
•In 11i, you had to choose between consolidating all invoices for a customer into one monthly bill, or printing all invoices separately. Plus, if you needed different billing formats that meant customizing print layouts.
•Now you have expanded billing periods definition by using the new billing cycle concept; varied levels of consolidation; the ability to exclude specific invoices, and unlimited formats that are easily created and maintained and selected automatically by a rules engine

2. Clearer communication with the customer
•User views the balance forward bill online exactly as the customer sees it
Accurate Aging
•In 11i Consolidated Billing, the payment term assigned to the transaction was ignored if consolidated billing was enabled. This meant that the due date on an individual invoice may be different then on the consolidated bill if the payment term assigned to the invoice was different than the default payment term assigned to the customer. Aging is based on due date of the individual invoice, while payment due date was based on the payment term assigned to the customer. This caused aging to be out of sync with bills due date. Now all Invoices that are consolidated on the same bill have the same payment term and due date, guaranteeing the individual invoices will age simultaneously.

Setup and Process:
The key setup steps are:
1.Define a Billing Cycle
2.Define or update the Payment term and assign it the Billing Cycle
3.Enable Balance Forward Billing for customers wishing consolidated bills at either the site or account level.
The process is then executed as follows:
1.Enter transactions or import them using AutoInvoice or Transaction API
2.Run the Generate Balance Forward Bill Program to create the bills as either draft or final, or set it up to run automatically
•The generate program will kick off the print program in BPA to create either draft or final bills.
•In Draft format, they can be reviewed before sending.
•If the process is mature, you may elect to run Generate Balance Forward Bill Program in the create Final Bill format. In which case, the BPA program will create final bills.
3.If you create bills in draft mode, you can either reject or accept the bills using the Confirm Balance Forward Bills Program.
•You can choose to reprint draft bills via the BPA Print Program by selecting the concurrent request ID.

Balance Forward Billing Setup - Define Billing Cycle:
•Responsibility: Receivables
•Navigation: Setup:Print > Balance Forward Billing Cycles
•For Daily, you can pick the number of days before the next bill. Also choose whether to include weekends in the number of days. For example, you can choose a daily cycle that is every 5 days, not including weekends in the daily count.
•For Weekly, you can pick the number of weeks before the next bill. Also, choose the day of the week the bill will be created. For example, you can choose bi-weekly billing that occurs every other Friday.

Balance Forward Billing Setup - Define Billing Cycle:
•For the monthly cycle, choose the number of months before the next bill. For example, choose 3 months if you need quarterly billing, or 6 months if you need bi-annual billing.
•Also choose the day of the month to create the bill. This option allows you to choose more than one date so billing can occur bi-monthly on the same days each month. For example, you can set it so billing occurs on the 15th and last of day of each month.
•By choosing Type of Day, you can elect to create the bills only on the workdays Monday through Friday. When you chose “Exclude Saturdays and Sundays”, if the billing date falls on a Saturday or Sunday, the billing date automatically changes to the date of the following Monday.

Balance Forward Billing Setup - Define Payment Term:
•Responsibility: Receivables
•Navigation: Setup : Transactions > Payment Terms
•Billing Cycle is a new attribute of the Payment term and must be assigned to the payment term to process balance forward billing. This field is not updateable if the payment term has been used.
•Cutoff Date information is now setup on the billing cycle, therefore the Cutoff Date block has been removed from the payment term setup window.
•The payment schedule dates:
-Due Date is calculated based on the cycle and billing date therefore, the Due Date is not enterable for Balance Forward Bills
-The Due Days field can indicate how many days after the billing date the bill is due for daily and weekly cycles
-Day of Month and Months ahead can be used with the Monthly billing cycle. It is recommended that these only be used when a single bill day is used otherwise the due date will be the same for all the bills created during the calendar month.
•After a balance forward billing payment term has been attached to a customer profile, the cycle will not be updateable.
•Existing payment terms cannot be updated to balance forward billing payment terms and vice versa.
•Consolidated or Proxima billing terms created in 11i will automatically be updated to balance forward billing payment terms.

Balance Forward Billing Setup - Customer Profile Class:
•Responsibility: Receivables
•Navigation: Customers > Profile Classes
•The customer profile class can be updated with the Balance Forward Billing information, which can then default to the profile on the customer account record.
•This region replaces the Consolidated Bill region in 11i.
•The Enable Checkbox must be checked to select a payment term with a Balance Forward Billing cycle.
•Balance Forward Bills can be created in summary or detail format: summary is at invoice total level; detail is at the invoice line level. Imported is used for the Imported Billing Number feature that was introduced in 11i.
-Note: The default print formats use this customer profile. If you do not want to use this option, you can create rules in BPA to ignore this value. When creating a rule, use the attribute “Display Format” to look at the value in this field.
•The Payment Term field allows you to choose either a Balance Forward if the Enabled checkbox is selected, or a Non-balance forward term if the Enable checkbox is not selected.
•The Override Terms checkbox means that the default Balance Forward bill payment term on an invoice can be changed. You can only select a non-balance forward payment term if you are overriding the default. Changing the payment term on the invoice means that you do not want this invoice to be included on the bill.
•Note: This is different functionality then 11i Consolidated billing which included all in voices on the bill regardless of the payment term assigned if consolidated billing was enabled.

Oracle BPA Rules Setup:
•Rules in BPA determine which template is used for printing and viewing Balance Forward Bills. Rules are created and then the templates get assigned to them.
•If you wish to have similar functionality as was provided by Consolidated Billing, use the default rules delivered with the feature. If you wish to create new BPA rules, and you want to use the Summary/Detail Type assigned to the customer profile option, use the BPA attribute called “Display Format”.
•BPA uses the following information to create the default rules:
-The Primary Data Source must be Oracle Receivables Balance Forward. Use this source when creating your own BPA rules.
-There are two Default rules: 1) one rule uses the attribute “Display Format” = Detail, 2) another rule uses the attribute “Display Format” = Summary
-These rules are then included in the rule hierarchy.
-Templates are assigned to each of rules. You can use the delivered summary and detail templates provided by BPA, or create and use your own templates
•When you run Generate Balance Forward Bills, BPA looks at the customer profile for the value assigned to the Summary/Detail Type to determine which template to choose.

Self Assessed Tax (perviously Use tax) in Oracle Payables 12i

2009-02-17T09:49:00.002-05:00

Self-Assed Tax :
Self Assessed tax differs from regular taxes in one way: as a purchaser, you are responsible for reporting and paying the tax and the supplier is not.
This was also known as USE TAX in previous releases.
For example: You receive an invoice for $1000 which is due to be paid to the supplier. Tax A for 10% was not charged on the invoice however, as the purchaser, you recognize that you are responsible to pay tax A. You would self-assess Tax A for the $100 and include it in your filings to the corresponding tax authority.

Features:
•The flexibility to have self assessed tax automatically assessed (based on tax setup) or to manually mark the calculated tax as self assessed during invoice entry.
•An ability to have recoverable and non-recoverable portions of self assessed tax amounts based on your invoice details.
•The ability to report and account detailed recoverable and non-recoverable self assessed tax AND the corresponding Self Assessed Tax Liabilities when the transaction is accounted.

Benefits:
Improved Fiscal Discipline
•Automatic reporting and accrual helps maintain an audit trail for the tax amounts and the invoices they tie to.
•Separate liability accounts for self assessed taxes translate to more granular and accurate accounting.
Improved Operational Excellence
•By automating previously manual processes and providing functionality available during invoice entry, the propensity for human error or delayed information is reduced.

Self Assessed Tax Predetermined Process:
•During Invoice Entry, Validation, and Import, Payables gathers information known as “tax drivers’ entered on the invoice header and lines and passes that information to the new E-Business Tax module.
•Based on these tax drivers and additional information derived by E-Business Tax such as the supplier’s party tax profile and buyer’s and supplier’s tax registrations, the engine determines if any self assessed tax is applicable to the invoice.
•The self assessed tax will be passed back to Payables along with the recoverable and non-recoverable tax amounts and the General Ledger Accounts for the recoverable tax and self assessed liability.
•Payables displays the self assessed tax amount in a column on the Invoice header in the Invoice Workbench. Payables will also derive the accounts for the non-recoverable portion of the self assessed tax then store all accounts to be used later when the invoice is accounted.
•When the Invoice is Accounted, the self assessed tax and corresponding self assessed tax liabilities will be accounted along with the rest of the invoice.

Self Assessed Tax Manual Determination Process:
•This slide illustrates the process for an invoice where the calculated tax returned by the E-Business Tax engine is expected to be paid to the supplier and the Payables’ user updates the it as Self Assessed instead.
•Just like the first example, Payables gathers tax drivers entered on the invoice header and lines and passes that information to the E-Business Tax module.
•Based on these tax drivers and additional information derived by E-Business Tax, the engine calculates the tax that is expected to be paid to the supplier (in other words: Non-self assessed taxes)

Self Assessed Tax: Predetermined Set Up – First Party, Party Tax Profile:
To enable the application to automatically assess self assessed taxes for the First Party or for certain Third Party Suppliers, you need to first set up the Party Tax Profile. The Party Tax Profile is party specific, tax related information that can be associated to 1st and 3rd parties. It includes information such as defaults, tax registrations, classifications and tax reporting codes.
Using the Tax Managers responsibility, navigate to the Parties, Party Tax Profiles page. Search based on the Party Type of First Party Legal Establishment and the desired party name.
You have the flexibility to configure First Party Establishments for Self Assessed Taxes at the following levels based on your needs:
•Registration, Regime
•Registration, Regime, Tax
•Registration, Regime, Tax, Tax Jurisdiction
•From the Tax Summary Window, the Payables user marks the tax as self assessed. E-Business Tax updates their records and returns the tax details to Payables.
•Payables stores the GL Accounts, displays the self assessed tax amount in a column on the Invoice header and the validated invoice is ready for accounting.

Self Assessed Tax: Predetermined Set Up – First Party, Party Tax Profile:

•Enable Self Assessment on the Party Tax Profiles tab
•By checking the Set for Self Assessment/Reverse Charge option at a particular level, E-Business Tax returns applicable taxes for supplier invoices that fall within the level
–For example, if you enable this option at the Registration – Regime level, all invoices to be taxed within that regime will be considered Self Assessed tax

You can also set up a particular supplier’s Party Tax Profile by doing either of the following:
•Use the Tax Managers responsibility to query a Third Party
•Navigate to the Tax Details page from the Supplier (Entry) pages from the Payables Responsibility

Implementation Considerations:
E-Business Tax is a common module available with Oracle Financial Applications.
•The E-Business Tax engine is responsible for calculating tax amounts applicable to invoices.
•It also assists in automatically identifying taxes as self assessed and allows setting options for manual determination.
Subledger Accounting is also a common module available with Oracle Financial Applications.
•Subledger Accounting is not specific to this feature but a general tool to configure accounting entries and to provide accounting reports to meet your needs.

Assets related enhacements to Oracle AP in 12i

2009-02-17T09:33:00.002-05:00

•Enhanced Asset Tracking - R12 provides the ability to track attributes of an item, such as manufacturer, serial number, from Purchasing through Accounts Payable to Fixed Assets. This increases processing efficiency and eliminates manual updates in FA that may have been required in the past.
–Item Description
–Manufacturer
–Model
–Serial Number
–Warranty Number
•Enhanced Mass Additions
–Asset Book
–Asset Category
–IPV/ERV distributions

Enhanced Asset Tracking Benefits:
Increased Efficiency and Reduced Costs
•Asset information typically entered on a purchase order, such as manufacturer, serial number, and model number, can now flow seamlessly into Payables and Assets.
Improved accuracy of information
•The Create Mass Additions process can now be submitted to select only those invoice distributions with a specific Asset Book, reducing the possibility of errors that need to be manually corrected.

Enhanced Asset Tracking Process:
•Enter or import a Payables Invoice and Match to Purchase Order.
•Payables retains the asset information.
•Optionally, update asset information on the invoice line or distribution.
•Submit the Create Mass Additions Process to transfer the Assets.

Invoice Lines:
Oracle Payables incorporates Invoice Lines into the invoice model. Adding Invoice Lines is a key architectural change, which enables Oracle Payables to better model the paper or electronic business document yet maintain key features that exist at the invoice distributions level.

Merged into the current invoice transaction business flows, Invoice Lines support the representation of the goods or services as well as tax, freight, and other charges as lines with distributions tied to each line. Additional fields record attributes such as serial numbers and item descriptions.

This feature offers the ability for line level approval and matching between an invoice line and a purchase order shipment pay item, or receipt. Furthermore, it facilitates the capture and transfer of additional, pertinent information to and from Oracle Projects and Oracle Assets.

Deferred Recoverability feature of AP in 12i

2009-02-17T08:57:00.002-05:00

Deferred Recoverability:

Deferred Recoverability refers to an accounting process where tax recovery is reported when the invoice is paid. The accrual (and therefore the settlement and/or reporting) of recoverable taxes is delayed due to special tax rules either enforced by the Tax Authority, or allowed with the agreement of the Tax Authority.

Features:
•Accurate reporting and accounting of pending recoverable tax amounts for the recoverable portion of the tax.
•When payment is made, whether fully or partially, the corresponding tax is automatically recorded as recoverable and reversed from the interim recoverable account.

Benefits:
1. This feature allows you to meet the challenge of adhering to local tax laws that require deferred recoverability whether you need this feature now or plan to expand into new, international markets in the future.
2. Streamlined operations and operational excellence both contribute to lower costs. Automatic accrual means less time spent accruing accounts manually, providing better control over accounting and reducing the propensity for manual errors.
3. Fiscal Discipline is improved as General Ledger accounts reflect transactions that have occurred and automated accounting reduces auditing time

Deferred Recoverability Process Part 1: Set Up and Invoice:
You must first configure E-Business Tax Service for deferred recoverability and optionally tailor the Subledger Accounting definition if needed for accounting.
•During Invoice Entry, Validation, and Import, Payables gathers information known as tax drivers that are entered on the invoice header and lines and passes that information to the new e-Business Tax module.
•Based on these tax drivers and additional information derived by e-Business Tax such as the supplier’s party tax profile and buyer’s and supplier’s tax registrations, the engine determines the applicable tax, returns both recoverable and non-recoverable amounts and, in the case of deferred recoverability, the interim tax General Ledger account for recoverable taxes.
•Payables displays the tax amount in a column on the Invoice Header and in the Summary region, creates the tax lines in the Lines tab, and records the Distributions including the interim recoverable tax account.
•When the Invoice is Accounted, the interim recoverable tax account is posted to General Ledger.

Deferred Recoverability Process Part 2: Set Up and Payment:
At payment time, Payables determines if the invoices being paid are subject to deferred recoverability. If so, Payables requests the distribution accounts for the recoverable tax from E-Business Tax.

Payables determines how much is recoverable based on how much of the invoice is paid, then records the amount and corresponding distribution account.

When the payment is accounted, the interim recoverable tax account is reversed and the recoverable tax is posted to General Ledger.

Setup Taxes with Deferred Recoverability:
•Responsibility: Payables
•Navigation: Setup > Tax > E Business Tax Home > Task List > Task Configuration > [Tax Regime, Tax, Tax Status, Tax Rate] > Create > Controls and Defaults > Allow Tax Recovery
To enable taxes with deferred recoverability, enable the Allow Tax Recovery and the Default Recovery Settlement options at the Regime, Tax, Tax Status, or Tax Rate levels. Set the Default Recovery Settlement option to Deferred.
In addition, when you set up a Tax with deferred recoverability, ensure that you define the following Tax Accounts for that tax:
•Tax Expense
•Recoverable Tax
•Interim Tax (used only for Accrual Based accounting)
The default account for recoverable taxes in Subledger Accounting is Accounts Payable deferred. You can change this account if necessary.

Implementation Considerations:
E-Business Tax is a common module available with Oracle Financial Applications.
•The e-Business Tax engine is responsible for calculating tax amounts applicable to invoices.
•E Business Tax configuration qualifies taxes with attributes to meet tax compliance requirements
Subledger Accounting is also a common module available with Oracle Financial Applications. Subledger Accounting is not specific to this feature but a general tool to configure accounting entries and to provide accounting reports to meet your needs.

New Accounts Payable architecture for 12i

2009-02-16T17:43:00.003-05:00

Suppliers in the Trading Community Architecture (TCA) :

The Trading Community Model:
•Is a highly flexible architecture
•Allows you to model real world entities in your trading community
•Allows you to accurately represent complex relationships among entities
•Is the core data model for trading partners used by Oracle E-Business Suite applications

TCA Security by Functional Areas:
A new user interface presents a clear distinction between the supplier’s company details and terms and controls for the trading relationship. Managing the attributes specific to particular functional areas such as Oracle Payables,
Purchasing and Receiving can be controlled with the use of Function Security.
•You can add new locations or relationships with additional operating units
•You can modify a quick update page with those values most often updated for faster maintenance
•Additional tax and legal registrations provide key information to meet reporting and compliance needs
The new supplier UI also includes a Survey section that provides administrators with access to the results of questionnaires that the supplier has been asked to complete, either during self-registration or as part of profile maintenance through iSupplier Portal. Purchasing Category assignments further designate the type of goods and services the supplier will provide.

Bank Accounts are:
•Centrally defined
•Managed and secured
•Include the legal ownership and operating unit access for each bank account

Supplier Bank Accounts:
The bank account is tied directly to the trading partner allowing one bank account definition to be leveraged by a ‘supplier’ trading partner and shared if the trading partner is also an employee or customer. This approach provides for easier and centralized maintenance and security of the bank account information.

This definition is targeted directly towards ‘trading partner’ bank accounts leaving internal bank accounts out of the user interface. In other words, the supplier’s banking information is entered and assigned right in the Supplier Entry and Maintenance user interface.

Collaboration with Suppliers to Resolve Disputes:

Holds on invoices that are a result of differences between the invoiced and planned amounts or quantity result in disputes that must be resolved. Invoices that have been approved by the owner of the purchasing transaction but rejected during the approval process may also be subject to disputes with the supplier.

Leveraging workflow notification, disputes are communicated and negotiations can be suggested to the Supplier. Suppliers are able to accept the suggested changes, withdraw their invoice, or submit their counter proposal. The negotiation continues until the issues are finally resolved. Suppliers can also negotiate online via iSupplier Portal. All changes and comments entered during the collaboration are tracked in Payables and can be viewed at any time.

Invoice Requests:

•Invoices entered by Suppliers via iSupplier Portal where a purchase order has not been obtained
•Are visible in Oracle Payables
•Are not paid or accounted until the invoice can be verified and approved

Whats new for Fixed Assets in 12i

2009-02-12T13:25:00.004-05:00

I. Subledger Accounting Architecture:

•Oracle Assets is fully integrated with SLA, which is a common accounting platform for Sub Ledgers
•You can use the seeded Account Derivation definitions or modify them as required
•SLA supports Account Generator functionality for existing Asset Books
•Supports new SLA Accounting report and online account inquiry

Benefits:
The flexibility of the accounting rule setup allows meeting different requirements in different legislative, geographic or industry contexts within a single instance. Assuming operations in multiple countries, each with its own legal requirements and accounting standards, you are able to define a setup to meet each of the requirements. SLA allows for multiple accounting requirements for a single transaction or business event.

The accounting data that is generated is viewable and provides full auditability.

Subledger Accounting Process:
The process is executed as follows:
•Enter transactions in Oracle Assets
•Run the Create Accounting Program to process accounting.
•Inquire and drilldown from SLA Pages

II. Enhanced Mass Additions for Legacy Conversions:

• Many attributes have been added to the FA MASSADDITIONS interface table, including:
–Asset life
–Depreciation method
–Prorate convention
–Bonus rule Ceiling name
–Depreciation limit

• Oracle Web Applications Desktop Integrator (Web ADI) has been enhanced to support the following new columns:
–Depreciation Method
–Life in Months
–Basic Rate
–Adjusted Rate
–Prorate Convention
–Bonus Rule
–Depreciation Limit Type

Enhanced Mass Additions for Legacy Conversions Benefits:
You can use the mass additions process to convert data from a previous asset system. Instead of loading the asset information into multiple Oracle Assets tables, load it into the FA_MASS_ADDITIONS table. The Post Mass Additions process can then be used to move the asset information from the table to Oracle Assets. After placing your data in this table, you run the Post Mass Additions program to perform the data import.

III. Automatic Preparation of Mass Additions:

•Consist of default rules and Public APIs that can be used by customers to complete the preparation of mass addition lines automatically
•Auto populate required fields such as Expense Account, Asset Category, and others

Benefits:
The major benefits of this feature are that you can:
•Avoid manual intervention during the Mass Additions prepare process
•Avoid customization and use public APIs to effect custom business logic

To process mass addition lines:
1.Interface Mass Additions Lines from Accounts Payable or any other system
2.Run the Prepare Mass Additions Program
3.Optionally verify Mass Additions data
4.Post Mass Additions

Automatic Preparation of Mass Additions Setup Quickcodes
Set up the Rules to Prepare Mass Additions in Quickcodes:
•Use Default: The Asset Category is derived based on the Asset Clearing Account if there is a one to one match in the Asset Category setup. The Expense account is derived based on the Clearing Account by replacing the natural account segment from the Asset Category.
•Use Custom: The Prepare Mass Additions program will use the custom logic coded in the Public API
•Use Custom Energy: Energy industry specific custom rule.

IV. Flexible Reporting Using XML Publisher:

•Major Asset Transaction reports have been modified to support XML publisher
•You can customize report output by modifying seeded templates or by using new templates

XML reporting is available for the following asset reports:

•Asset Transfers Report
•Transaction History Report
•Asset Reclassification Report
•Mass Additions Create Report
•Cost Adjustment Report
•Cost Summary Report
•CIP Summary Report
•Reserve Summary
•Journal Entry Reserve Ledger
•Asset Additions Report
•CIP Capitalization Report
•Mass Additions Posting
•Asset Retirements

Set up Procedure:
1.Query up the concurrent program as system administrator
2.Change the output format to XML
3.Once the output is flagged as XML, submit concurrent request

V. Automatic Depreciation Rollback:
Since release 11i, users have been able to run depreciation for an asset book without closing the period. If additional adjustments are required in the current period, then the user submits a process to roll back depreciation for the entire book, performs the necessary adjustment(s) and then resubmits the depreciation program.

In Release 12, the intermediate manual step of rolling back depreciation for the entire book in order to process further adjustments on selected assets is no longer necessary. As before, you can submit depreciation for the entire book prior to closing the period. If it becomes necessary to process financial adjustments on one or more assets, you may proceed with the transaction normally via the asset workbench or mass transactions. Oracle Assets automatically rolls back the depreciation on just the selected assets (instead of the whole book) and allows the transactions to be processed normally. The assets for which depreciation was rolled back is automatically picked up during the next depreciation run or at the time that the depreciation period is finally closed.

Benefits:

1. It is no longer required to run depreciation rollback program manually.
2. Depreciation rollback is executed only on select assets as required and not on the entire Asset Book, thereby enhancing performance of the program.

12i Cash Management new features - PART 2

2009-02-12T13:19:00.002-05:00

IV. Bank Statement Reconciliation – Description:

In Release 12, Bank Transaction Codes can be linked to multiple sources. Previously each bank transaction code had to be linked to a single source, such as Accounts Payable. This could create an issue if the bank was using the same transaction code to report back a payment that was initiated from an application other than Accounts Payable. In Release 12, you can link bank transaction code to as many sources as you would like and also assign a priority number used in the auto reconciliation for sequencing.

Reconciliation tolerances in Release 12 are moved from the system level to the bank account level. This means that each bank account can have a unique set or reconciliation tolerances. Moreover, there is now a distinction between tolerances for manual and auto reconciliation. Furthermore, auto reconciliation tolerances can be unique for each source – Accounts Payable, Accounts Receivable, Cash Management and Open Interface.

Finally, since now it is possible to use the same bank account, created in the centralized model, in multiple organizations, the bank statement reconciliation is also done across Operating Units.

Bank Statement Reconciliation - Benefits:
The enhancements for the Bank Statement Reconciliation process allows you to improve efficiency. By having granular level reconciliation tolerances and the ability to cross operating units, you will increate straight-through processing success rate of the auto reconciliation.

Setup:
•Now part of bank setup
•Transaction Codes
–Assign a transaction code to multiple transaction sources
•Account Controls
–Reconciliation control parameters

V. Multi-Org Access Control and Security:

•Provides bank account maintenance security.
–Privilege to create and update bank accounts that belong to the legal entities that the user can access
•Provides bank account access security.
–Bank Account Access Cash Management Security Profile: Which organizations the user can access. Sets:
—Bank Account use
—Treasury security
—MOAC security
—Payroll security

Benefits:
•Reduced Costs: Enable shared services centers and cut down processing time.
•Improved Efficiency: Easily access data from different operating units.
•Improved Security Control: Explicitly grant access to specific users for specific purposes.

VI. Cash Pooling:

Cash leveling or Cash Pooling is a cash management technique aimed at optimizing the balances of the internal bank accounts held at one or several banks. It is usually performed on a daily basis and can be done by transaction or by total net end-of-day balances. To perform cash leveling, you need to define a cash pool and assign internal bank accounts setup in Oracle Treasury to the cash pool.

Creating Cash Pools:
•Notional Cash Pools:
–Consist of one concentration account and multiple sub accounts
–Are used for cash leveling similar to zero balancing without the actual funds movement
•Physical Cash Pools:
–Consist of one or two concentration accounts and multiple sub-accounts with funds transfer rules specified
–Are used for cash leveling wherein you can initiate fund transfers or mirror outsourced cash pools

Viewing and Updating Cash Pools:

•You can view cash pool information as follows:
–Search for the cash pool name
–Click on the cash pool name in the Search and Results page
•If you have the appropriate user security, you can update the cash pool

12i Cash Management new features - PART 1

2009-02-12T11:58:00.003-05:00

I. Bank Account Balances and Interest Calculations:

In prior releases, bank account balances were only available as a part of the bank account statement. The bank account interest calculation was only available for bank accounts set up in Treasury. In Release 12, the functionality to keep track of the multiple bank account balance types and calculate accrued interest is available to all internal bank accounts set up in the centralized bank account model.

Not only can you enter the balances manually, but also you can import them automatically at the same time when the bank statement is imported. In addition to the actual historic balances, you can keep track of the projected balances. Such balances can be entered manually or copied over from the Cash Position. You can then create reports that will compare the actual balances versus projected, and you can accomplish it in either an onscreen report or via XML Publisher. Finally, to simplify the bank account interest calculation, you can create reusable interest rate schedules that will contain the interest rates and other interest calculation parameters. Interest calculation features will work not only for stand-alone bank accounts but also for the notional cash pools as well.

Bank Account Balances and Interest Calculations - Benefits:
The new bank account model allows you to view bank account balances independent of the bank statement, calculate accumulated interest on the fly, and create customized balance reports.

Bank Account Balances and Interest Calculations Maintenance:
Once you have defined your bank accounts in the centralized bank account model, query them in the bank account balance page and manage historical or projected amounts.

Bank Account Balances and Interest Calculations Setup:
To obtain a balance report, create a report layout or a view and generate a report based on that. To calculate interest on the bank account balance, create the interest rate schedules, tie them to the bank accounts and use the interest calculator page to view the accumulated interest.

II. Bank Account Transfers:

In Release 12, you are able to create bank account transfers in Cash Management. The transfers can be initiated, approved, settled and accounted for. The settlement is done through the Payments application, while the accounting is done though the Subledger Accounting engine.

Bank Account Transfers Description:
Bank Account Transfers can be created manually by the user in the system. In addition, if there are any physical cash pools defined in the system, the transfers can be created automatically when the cash leveling process is run or when a bank statement with ZBA sweep lines is processed.

With manual transfers, you have the option of creating and using a payment template. The template will default the transfer information, such as the source and destination bank accounts, currency, and payment method, and can be used in the same fashion as a repetitive or semi-repetitive wire template created by your bank.

In cases when the settlement of the bank account transfer does not have to be initiated by the system (for example, for ZBA bank account transfers that the bank processes on its own), there is an option to exclude such a transfer from the settlement process and only create the accounting entries.

Finally, the UMX security model lets you define who can create bank account transfers for which legal entities. The settlement authorization function is also separate from the transfer creation, so you can implement the separation of duties for bank account transfer management.

Bank Account Transfers - Benefits:
The bank account transfer functionality enriches the Cash Management functionality so that you could take action on the projected closing balances calculated by the system. The seamless integration with the Payments application allows you to send payment instructions to the bank in a variety of payment formats and the integration with the Subledger Accounting allows you to use flexible journal creation rules.

Bank Account Transfers Process:
•Responsibility: Cash Management
•Navigation: Cash Management > Bank Account Transfers
Once the setup is in place, you can start creating the bank account transfer. If the system parameter requires authorization, the bank account transfer must be authorized before it is available for settlement or journal creation. Otherwise, you can proceed to settle or journalize the bank account transfer immediately after creation and validation.

The Payments application formats your payment request and sends it to the bank. Any exceptions in the payment process are communicated back in the form of an error status. If settlement of the bank account transfer errors out, you can see the reason so that the cause of the error can be rectified and the bank account transfer recreated. If the payment is processed without any exception, you see a successful payment status returned.

The subledger accounting process creates journal entries according to your setup and you can drill down to view these journal entries.

Bank Account Transfers – Dependencies and Interactions:
The bank account transfer feature depends on Payments application in cases where the settlement of the bank account transfers is required. There is also a dependency on the Intercompany setup when funds are transferred between different legal entities. Finally, all of the accounting activity for bank account transfers happens in the Subledger Accounting framework.

Bank Account Transfers Setup:
•Responsibility: Cash Management
•Navigation: Setup:System Parameters > (T) Cash Management Transactions
If you are using the cash leveling or ZBA features, the setup starts with the new system profile. Then, optionally, you can set up Transaction Subtypes and Payment Templates for bank account transfers. The Payment Templates are required if you intend to send the payment instructions to the bank to process the bank account transfer. The Transaction Subtypes are optional and can be used for reporting purposes.

Bank Account Transfers Setup – Set System Profile:
The new system profile option CE: Bank Account Transfers defines where the cash transfers will be created as a result of the cash pool activity. If you choose Cash Management, then the cash transfers created by the cash leveling or ZBA sweep activity are created in Cash Management using the Bank Account Transfer framework. If you choose Treasury, then these cash transfers are created in Treasury using Inter-Account Transfers (if both bank accounts belong to the same legal entity) or Intercompany Funding transactions (if bank accounts belong to different legal entities). Before Release 12, Bank Account Transfers could only be created in Treasury. This functionality is preserved but now you have a choice.

III. Subledger Accounting:

Subledger Accounting provides a common flexible framework for creating journal entries for Bank Account Transfers and Bank Statement Cash Flows in Cash Management. Prior to Release 12, Cash Management produced journal entries for bank statement activity based on simple rules and sent them to the General Ledger interface. In Release 12, in addition to the bank statement activity, a new source of accounting entries is available – bank account transfers – and the rules for journal entry creation are more flexible and sophisticated. Finally, you can now view all the journal entries produced by Cash Management events in Cash Management.

Subledger Accounting for Cash Management:
In Cash Management Release 12, bank account transfers and bank statement cash flows are the two objects that can produce accounting events. Once the events are created and the accounting program is run, the journal entry setup and the accounting configurations are referenced to produce journal entries. The journal entries are then transferred to GL. GL has visibility into the source transactions and Cash Management users can drill down from the transaction level to the journal entry details.

Subledger Accounting - Benefits:
The Subledger Accounting feature allows multiple accounting representations for a single business event, resolving conflicts between corporate and local fiscal accounting requirements. In addition, with subledger accounting you retain the most granular level of detail in the journal entries, with different summarization options in the General Ledger, allowing full audit and reconciliation

Subledger Accounting Key Concepts :
Here are some key subledger accounting concepts:
•Event model is defined in SLA for each subledger represents the transaction/document types and the lifecycle of each transaction:
-Event class classifies transaction types
-Event type defines possible actions on each event class with possible accounting significance.

The journal creation rules are defined per event class/event type. In Cash Management, there are two event classes: Bank Account Transfer and Bank Statement Cash Flow. An accounting event for a Bank Account Transfer, for example, would be the creation or cancellation of a bank account transfer. So, any time a bank account transfer is created, an accounting event is created as well. Based on the rule setup, there may or may not be a resulting journal entry. You may set up rules to generate journal entries for some events, but not for others.

Transaction object and sources are the data model for each subledger that contains the transaction attributes/information made available to be used during journal rule setup and journal entry generation.

Bank Account Model in Release 12i

2009-02-12T10:41:00.005-05:00

Here is a summary of the new features introduced by 12i in the area of Bank Account Model:

Bank Account Model Definition:
The new bank account model allow you to define and keep track of all bank accounts in the e-Business Suite in one place and explicitly grant account access to multiple operating units/functions and users. Bank accounts for internal use in Cash Management, Payables, Receivables, Treasury and Payroll are consolidated in Release 12. If you were using internal bank accounts in prior releases, all bank accounts will be migrated into the centralized bank account model automatically during the upgrade.

UMX-based Security:
The CE UMX Security Wizard is available under the User Management (UMX) responsibility. The wizard helps you quickly define the legal entities available for a role. To launch the wizard, log in as System Administrator, then in the User Management responsibility, go to Roles & Role Inheritance.

Bank Account Model Interaction :
In previous releases, Oracle Accounts Payable owned banks, bank branches and bank accounts. Such bank accounts could also be used by Accounts Receivable. Payroll and Treasury, however, had their own bank account models. In Release 12, banks and bank branches are created as Trading Community Architecture parties. The bank accounts are associated with Bank Branches but reside within the Cash Management application. During the bank account creation, you will be able to define in which applications this bank account can be used.

Bank Account Model Benefits:
The new model reduces the number of access points to manage bank accounts by providing a centralized user interface where all internal bank accounts can be set up. Bank account access in the new model can be granted to multiple operating units, thus eliminating the redundant duplicate bank account setup under different operating units in case these operating units share the same bank account. This simplifies the reconciliation process since now one bank account is the system corresponds to one bank account at the bank.

Cash Management Security Components:
Set up security for access to Cash Management activities by using components from different applications. The specific steps required to secure access to your bank accounts depend on the type of access you want to secure, the applications that you use for your business, and your organization structure.
•Use the CE UMX Security Wizard to grant a role (responsibility) the ability to perform bank account activities in the following areas:
-Use: View bank statements, reconcile cashflow transactions, work with cash forecasting, cash positioning, and cash pools
-Maintenance: Create and update bank accounts
-Bank Account Transfers: Transfers funds from and to internal bank accounts.
•When creating bank accounts, specify the legal entity that owns the account and the organizations that the account is used for (Payables, Receivables, Treasury, Payroll).
•Create security profiles to define the list of organizations that a user can access. Set up security profiles in the following applications as needed:
-MOAC: to define the list of operating units a user can access for Payables and Receivables and be able to reconcile AP and AR bank statement lines.
-Cash Management: to define the list of organizations a user can access to reconcile cashflow transactions. This security profile also allows users to access bank accounts for cash forecasting, cash positioning, and cash pools if no other security profiles are set up.
-Treasury: to define the legal entity that the Treasury user can access and be able to reconcile Treasury bank statement lines.
-Payroll: to define the business groups a user can access and be able to reconcile payroll transactions.

Bank Account Model Setup and Process:
•Responsibility: Cash Management
•Navigation: Setup:Banks > Banks
The key setup steps are:
•Define Banks in Oracle Cash Management.
•Define Bank Branches in Oracle Cash Management.
If you intend to use this bank account in Oracle Treasury as a company bank account, switch to that application, define Bank Counterparties and link them to Bank Branches that you have created. If you do not intend to use this bank account in Oracle Treasury, skip this step and proceed straight to the Bank Account definition.
At this point the system verifies your privileges for bank account maintenance. If you are authorized to maintain bank accounts for this legal entity, you will be able to create your Bank Accounts in Oracle Cash Management.
If you do not intend to use this bank account in Payroll, then the setup process is complete for you. If you intend to use this bank account in Payroll, switch to that application and add this bank account to the organizational payment method.

Implementation Considerations:
The bank new account model has several dependencies on other applications and centralized features.
•There is a dependency on the Trading Community Architecture because this is where the banks and the bank branches are stored.
•The organizational hierarchy comes from Human Resources.
•Finally, the General Ledger accounts that are assigned to the bank accounts are defined in General Ledger.
•If you are using Payroll or Treasury, then the bank account set up depends on those applications as well.

Implementation considerations for R12 General Ledger setups

2009-02-12T09:05:00.002-05:00

Many clients ask for best practices and implementation considerations for implementing a new GL in 12i, here are some important implementation considerations:

Chart of Accounts:
–Share the same value set for the balancing segment across charts of accounts

Determine the Number of Legal Entities to Assign in an Accounting Setup based on:
–Statutory and legal requirements for legal entity accounting, such as document sequencing, tax accounting, and intercompany accounting
–Business Needs

Types of Accounting Setups:

1. Accounting Setup with No Legal Entity (LE)
–Can be used for GL only implementations
–Used for a business need where no legal entity is required or management reporting
–Cannot maintain legal entity context in subledger transactions
–Cannot set up Operating Units
–Cannot use Advanced Global Intercompany Accounting System

2. Accounting Setup with One LE
–Cannot perform lump sum payments across legal entities in AP

3. Accounting Setup with Multiple LEs
–Cannot perform autonomous document sequencing and tax that is unique per legal entity
–Consider local laws that prohibit commingling transactions with multiple LEs

Choosing the Ledger to be the Corporate Representation:

Best practice is to choose the primary ledger to be the corporate representation in the local currency:
–Provides the most detail
–Allows you to assign a subledger level reporting currency if you want to maintain a detailed additional currency representation
–Note: Secondary Ledgers cannot have subledger level reporting currencies assigned

Legal Entity (LE) Accounting:

1. LE above Ledger
–If you require multiple primary ledgers to perform accounting for the same legal entity, you must create dummy legal entities because a legal entity can only be assigned to one accounting setup, not multiple accounting setups

2. LE = Ledger
–If legal entity equals the primary ledger, you may choose not to assign balancing segment values to the legal entity

3. LE Below Ledger
–Legal entities should be represented by one or more balancing segment values

Balancing Segment Value (BSV) Assignment:

1. No BSVs Assigned = All values available for data entry
2. Assign specific BSVs to LEs at any time
3. Behind the scenes, BSVs assigned to LEs are automatically assigned to the ledgers
4. No BSV validation performed across accounting setups
5. BSV assignment is required for Intercompany Accounting
6. Optionally assign BSVs to the ledger for non-legal entity related transactions, such as management adjustments
7. Before BSVs can be assigned to the ledger, they must be assigned to LEs first, if used

Reporting Currencies (RC):

1. Journal and Subledger level RCs act like regular ledgers
2. To automatically populate historical data, run the Create Opening Balance Journals in Reporting Currency program.
3. Conversion for subledger sources that uptake SLA are disabled for Subledger Level SLs
4. When posting a journal to the PL, journals for the RC will be automatically created/posted in the same batch
–Ensure same open periods for source ledger and RC
5. Data access set should include same write access to source ledger and RCs to prevent posting errors

Subledgers that uptake SLA (Assets, Budget Execution, Cash Management, Cost Management, Inventory, Oracle Loans, Payables, Payroll, Property Manager, Purchasing, and Receivables)

Secondary Ledgers (SL):

1. Can be added at any time with an unlimited number allowed
2. To populate historical data, use Consolidation (GCS)
3. Secondary Ledgers cannot have Subledger Level RCs assigned
4. COA Mapping required if COAs are different between the PL and SL
–COA Mapping can be used if the COAs are the same except for Subledger Level SLs
5. Conversion for subledger sources that uptake SLA are disabled for Subledger Level SLs

R12 Multi-Org Access Control - Preferences

2009-02-08T15:54:00.002-05:00

Multi-Org Access Control Preferences - Description :

Multi-Org Preferences allows you to control the list of operating units to which you have access. For example, a system administrator may create a security profile that has ten operating units assigned to it and assign it to your responsibility. But, you may only deal with five of the operating units on a daily basis and do not want work space cluttered with extraneous operating units. You could set up Multi-Org preferences to restrict the list of operating units; you have complete control over this and can change it at anytime. In addition, you can specify a default operating unit.

Multi-Org Access Control Preferences - Benefits:

•Increase Efficiency
–Save key strokes with default operating unit
–Limit access to operating units you use most
•User Level Control
–Eliminate using System Administrators; you can control your own access
•Reduce cost
–Perform processes quicker

Multi-Org Access Control Preferences Setup:
Most products have added the Preferences user interface to their responsibility menus. You can select preferred operating units which represent a subset of operating units assigned to your responsibility’s security profile. You can also set a default operating unit.

Multi-Org Access Control Preferences – Setup – Add to SubMenu:

To enable and display Preferences in your menu
1.Request that your System Administrator to add the function FNDMOPREFS to your menu definition
•The System Administrator should use either the System Administrator or Application Developer responsibility, and select the Menu (Application) option
2.Select your product’s menu and add the function named User Preferences (FNDMOPREFS)

Multi-Org Access Control Preferences – Setup – Set Preferences:

Multi-Org Preferences page:
•The header displays:
–The user name that you are logged in as
–The responsibility name
–The Security Profile that you are currently assigned to
•The Default Operating Unit region is where you select a default OU.
•Preferred Operating Units is where you select the subset of operating units you want to work with.

R12 Multi-Org Access Control - Setups

2009-02-08T15:50:00.002-05:00

Multi-Org Access Control Setup:

•Responsibility: Human Resources
•Navigation: Security > Profile
In Release 12, when you define your security profile in HR using the Security profile form or the Global Security profile form, you must:
•Assign all of the operating units that you want a responsibility to access. Run a concurrent request called “Run Security List Maintenance” from HR which makes those security profile available and allows you to assign them to a responsibility via a profile option called MO: Security Profile.

Multi-Org Access Control – Setup – Create Operating Unit:
•Responsibility: General LedgerNavigation: Accounting Setup Manager > Financials : Accounting Setup : Accounting Setup Manager

•Responsibility: Human Resources:Navigation: Work Structures : Organization > Description
In Release 12, you can define your operating units in two places. You can continue to define them in the Oracle HRMS Organization Form or you can define them in the new Accounting Setup Manager feature in General Ledger.

The Accounting Setup Manager streamlines the setup and implementation of Oracle Financial Applications. It centralizes the setup and maintenance of common financial components, such as legal entities, operating units, and ledgers. So when you create an accounting setup, assign a legal entity and create the ledgers that will perform the accounting for that legal entity, you can also define and assign the relevant operating units. By leveraging Accounting Setup Manager to define your OUs, you can streamline your setup.

In R12, is instead of attaching an OU to a LE, you assign it to a default legal context. All Release 11i HR Organizations classified as “Operating Units” will be preserved in Release 12. If operating units are assigned to a set of books, then they will be associated to a primary ledger in an accounting setup. You will be able view all operating units assigned to an upgraded primary ledger using Accounting Setup Manager.

Multi-Org Access Control – setup Define Security Profile:
•Responsibility: Human Resources
•Navigation: Security : Profile or
•Navigation: Security : Global
Using Oracle HRMS, you can define your security profile using two forms:
•The Security Profile form, which allows you to select operating units from only one Business Group
•The Global Security Profile form, which allows you to select operating units from multiple Business Groups

Enter a name, and select the Security Type called “Secure organizations by organization hierarchy and/or organization list”. This allows you to assign multiple OUs.

When assigning operating units, first select classification Operating Unit, and then select the organization or Operating Unit name. You can assign multiple operating units.

Multi-Org Access Control – Setup – Run System List Maintenance:

•Once the security profile has been created, run the Security List Maintenance program.
–This ensures that all of the security profiles that you created are available for assignment to your responsibilities.

Multi-Org Access Control – Setup – System Profile Options:

•The MO Security Profile controls the list of operating units that a responsibility or user can access. If you set the security profile at the responsibility level, then all users using that responsibility will have access to only the operating units available in the security profile. If you set the security profile at the user level, then the user will have access to only those operating units, irrespective of application responsibility that they log into.

•The MO: Default Operating Unit is optional and allows you to specify a default operating unit that defaults when you open different subledger application pages. Because you can access multiple operating units, you may want to set up a default one instead of forcing users to constantly have to choose one. User Preferences allows you to specify a default operating unit at the user level. Use the MO: Default Operating Unit profile option to set the operating unit context or default operating unit when accessing an applications.

•The last profile option is for backwards compatibility and to support products that do not use Multiple Organizations. The release 11i setting was for this is preserved during upgrade. The Release 11i MO: Operating Unit profile option is supported in Release 12 as not all customers of Oracle products require multiple organizations.

Implementation Considerations:

•Oracle HRMS
–Define operating units
–Set up Multi-Org Security Profiles
•Accounting Setup Manager
–Define operating units
–View all operating units assigned to the primary ledger
•Oracle E-Business Suite Products that Use Operating Units
–Process data across multiple operating unitsusing Multi-Org Access Control

R12 Multi-Org Access Control - features and benefits

2009-02-08T15:45:00.001-05:00

Multi-Org Access Control - Description:

In 11i, when users had to enter or process data for multiple operating units, they had to login to different responsibilities because each responsibility could only access one operating unit. So if there were a centralized payment processing center where users processed payments for multiple organizations, they would have to keep logging in and out of different responsibilities to process payments for a different organization or operating unit.

Now in Release 12, Multi-Org Access Control enables companies that have implemented a Shared Services operating model to efficiently process business transactions by allowing users to access, process, and report on data for an unlimited number of operating units within a single application’s responsibility.

This increases the productivity of Shared Service Centers as users no longer have to switch application responsibilities when processing transactions for multiple operating units. Data security and access privileges are still maintained using security profiles that will now support multiple operating units.

Multi-Org Access Control - Example:

For example, if you have three operating units in the center you were managing, such as a Belgium Operating Unit, a Holland Operating Unit, and a Denmark operating unit, in 11i you needed to define three different responsibilities. If you had one user who processed payables invoices across all three operating units, then you would need to assign the three responsibilities to that user and then the user would need to log in and out of each responsibility to process invoices.

In Release 12, you can create a Security Profile and assign as many operating units as you want to that security profile. So in this example, you could assign all three operating units to the same security profile. Then, you can tie that security profile to a single responsibility using a profile option called MO: Security Profile. For example, you could assign the security profile to the EMEA Payables responsibility to allow that responsibility to process invoices across all three operating units.

Processing payables invoices is just one example, with Multi-Org Access Control, you can efficiently perform other processes, such as processing receivables invoices, viewing consolidated requisitions, performing collections using Advanced Collections, and process receiving and drop shipments.

MOAC - Benefits:

•Improve Efficiency
–Process data across multiple OUs from one responsibility
–Process transactions more efficiently for companies that have centralized business functions or operate Shared Service Centers
•Obtain better information for decision making
–Obtain a global consolidated view of information
–View information, such as supplier sites and customer sites across multiple OUs
•Reduce Costs
–Speed data entry
–Reduce setup and maintenance of many responsibilities

Multi-Org Access Control Process Summary:

Each Financials product team has implemented MOAC to best suit their business process flows. For example, in AP, there’s a new operating unit field on their Invoice Workbench. The OU list of values reads from the Security Profile assigned to the responsibility to determine which OUs should be displayed in the LOV. In general, when a user logs in to a responsibility and opens an application, the application will determine which operating units can be accessed and used for processing. The user can then view or process transactions for multiple operating units.

R12 Financials Overview and new features at a glance (PART 2)

2009-02-08T15:30:00.002-05:00

Oracle E-Business Tax (eBTax):
consists of a tax knowledge base, a variety of tax services that respond to specific tax events, a set of repositories (for tax content and tax recording) that allow customers to manage their local tax compliance needs in a proactive manner, as well as the ability to integrate with external tax content providers through a single integration point.

Advanced Global Intercompany System:
•Addresses the Top Barrier to a Fast Close
•Generates subledger invoices
•Controls transaction entry with Intercompany Calendar
•Has a Fully Configurable Approval Rules
•Has a Flexible Security Model
•Has a Centrally defined Intercompany Accounts

Centralized Banking:
•Bank account is now associated with the LE instead of the Operating Unit
•A single bank account serves multiple Operating Units
•Any and all Operating Units associated with a ledger can be permitted to use the bank account
•There is a centralized Credit Card Model
•There is Credit Card Encryption
•The Supplier & Customer Banks are in TCA

Multi-Dimensional Analysis & Reporting:
•In product row/column UI or within a Spreadsheet
•You can create the following reports & graphs:
– Historical
– Current
– Projected data
•You can analyze performance:
– Detect trends
– Define
– Variance
– Thresholds
•Receive auto-alerts

Financial Consolidation Hub:
R12 includes interactive spreadsheet reporting with live drill down to transactions

XML Publisher:
Enables you to format, manage, and deliver documents
•Meets business requirements such as:
-Removes complexity
-Reduces maintenance cost
-Reduces TCO
•Integrated with: R9 CRM, ESA, FMS, HCM, and SCM

New Standard Reports:
•Uses XML Publisher
•835 Templates are available
•Merges custom templates and data extracts at run-time
•Delivers output in PDF, HTML, RTF, Excel (HTML), or text for use with EFT and EDI transmissions
•98 Global reports have been replaced with 19 Extracts, 86 Templates

Other new features:

•Live AR-Inventory. Revenue-COGS Match
•Deferred COGS and Revenue Automation
•Advanced collection, Dunning, Loans
•Invoice Lines
•Suppliers in TCA: one setup per partner
•Supplier, users invoice self service
•Straight through processing (STP) at banks
•Per diems, approval enhancements
•Expense Bar Codes
•Self Service receipt matched invoices
•Real time contract T&Cs in PO, AP
•Asset Automatic Depreciation Rollback

R12 Financials Overview and new features at a glance (PART 1)

2009-02-08T15:18:00.003-05:00

Why R12:

Release 12 is defined as “The Global Business Release.” Global is not just a geographic perspective, but also a comprehensive perspective; release 12 functionality spans across both industries and business functions.
•Flexible, centralized, global accounting structure
•300+ enhancements to best practice business processes
•Comprehensive governance, risk and compliance platform
•Truly integrated performance management
•Real-time profitability analysis
•Unified financial and operational analytic applications
•Integration with core industry applications
•Self-service report formats and publicationSuperior ownership experience

New architecture and benefits:

The major components of the new architecture include:
•Multi-Org Access Control
•Ledger and Ledger Sets
•Subledger Accounting
•Tax Engine
•Intercompany
•Bank Model

Benefits of the new architecture include:
•Maintain 1 Ledger with 1 OU for each Company (LE)
-Get privacy for each company’s data
-Manage each company’s national and local compliance
•Combine many companies’ ledgers in a set
-Share GL services and workload
-Get combined data
•Use MOAC to enable access to many OUs
-Process in and report across many Companies’ Operating Units

MOAC: Multi-Org Access Control:
MOAC provides role based access to Operating Units, and allows you to perform multiple tasks across operating units without changing responsibilities.

Subledger Accounting:
Subledger accounting provides centralized rules and a common repository, and global control of your accounts. Features include:
•Accounting Rules
-SarBox & 8th Dir.
-User Editable
•Subledger Daybooks (Journals)
•Subledger Balancing
•Reports, inquiries, open items, et cetera
•Multiple Representations
•Common Posting to GL Ledgers
•Real time or Periodic

Benefits of subledger accounting are:
•Faster, Easier Reconciliation
•Corporate Rules = Accounting Standardization
•Local Rules = Improved Local Compliance
•Automate “Apples to Apples” Adjustments
•Improved Audit- ability
•Improved Internal Control

Ledger:

•One Repository of Financial Truth
•Implements the 4 C’s:
–Chart of Accounts
–Currency
–Calendar
–Accounting Convention
•Example:
–The balance on Creditors (COA)
–is 4.2M Eur (Currency)
–on March 31, 2006 (Calendar)
–according to IAS/IFRS definitions (Accounting Convention)

Ledger Sets:
Ledger sets provide global information at a glance. Ledger sets share a chart of accounts and a calendar. The key benefits to many Ledgers in one set are:
•Decision-driving business information always available
•Simpler processing and General Ledger management
•Data and definitions that can be shared and secured

Ledger Architecture:
Typical Ledger Sets:
•All IAS/IFRS or US GAAP ledgers
•26 Subs in 1 country
•35 countries in 1 region

Legal Organization:
Legal Entities (Les) such as Parent companies, own or control subsidiaries. There are no group entities
•LEs pay the taxes and therefore need tax registrations
•Trade between LEs needs intercompany
•LEs own the money and bank accounts
•LEs file the accounts and take care of accounting
•LEs comply with whatever needs compliance: “legal” in LE

Enhanced Legal Support:
•Did not replace GRE/LE - employer
•Added TCA parties for the Authorities
•Added a Legal Entity Configurator
•Introduced the following new terms:
-Jurisdiction: A legislative category and territory, has legal rules
-Legal Authority: Legal body who enforces legislation, collects fees / taxes, etc
-Legal Function: Functions that companies are required to perform (e.g. produce yearly report, pay taxes, etc.)
-Legal Associations: Mapping companies to Ledgers, BSVs, OUs and other system entities

Examples of using Legal Entities:
•Accounting Setup Manager: Assign books, bookkeeping rules and currency management to your registered companies
•EBusiness Tax: Have your registered companies calculate, file, and pay the transaction taxes they owe
•Intercompany: Do business between and across your registered companies with full legal documentation
•Bank Model: Have your registered companies use their money to pay their bills, etc.

Oracle 11i Upgrade Model Questionnaire

2008-11-07T11:38:00.004-05:00

Click on the Excel image below to get a readable view:

Understanding Oracle Bill Of Materials (BOM)

2008-09-27T21:14:00.005-04:00

BOM Overview:

A bill of material is a list or Items associated with a parent Item, such as an assembly, and information about how each item relates to the parent item.

# A single level BOM consists of one parent Item and its immediate component Items
# Multilevel BOMs are displayed by linking together single level BOMs stored in the system
# A subassembly is both a parent and a component
# All items in a BOM model, including the parent Item being configured, must be defined in the Item Master and enabled in the Inventory Organization where BOM Model is created
# A BOM Model can be shared among other Inventory Organizations by creating common bills
# After a valid combination of options is selected from BOM Model, a Standard BOM is created to guide manufacturing planning and execution
# Repetitive combinations of option selections can be stored and retrieved as pre-configured Items

BOM Types:

1. Standard Bill
2. Model Bill
3. Option Class
4. Planning Bill

BOM Models:

•Create Model bills to represent products and service that allow user-selected options:
# Option Classes are groups of optional items
# Optional Items
# Required Items
•Model bills and Option Class bills of material can include:
# Stock Items
# Assemble-to-Order Models
# Mandatory and Optional Components

PTO and ATO BOM Models:

•ATO BOM Models:
# Represent product models that require assembly “downstream” in Oracle Work In Process
# Are assembled using manufacturing work orders that can be costed
•PTO BOM Models:
# Represent product Models in which included items appear on pick slips and selected when the order ships
# Are not costed

Configurable PTO and ATO BOM Models:

# The inventory Item that represents the top level in your BOM Model must have the BOM Item Type attribute set to Model
# PTO and ATO BOM Models can contain Standard Items and Option Classes as components
# ATO and PTO BOM Models can also contain other ATO BOM Models as components
# An ATO BOM Model cannot contain a PTO BOM Model
# A PTO BOM Model can contain a PTO BOM Model

Implicit Rules:

•Basic rules are included with Oracle Bills of Material:
# Optional or Required
# Mutually Exclusive
# Maximum and Minimum Quantity
# Quantity Cascade
•These rules provided by Oracle Bills of Material are called Implicit Rules.
•Oracle Configurator honors these rules as well as the rules defined using Oracle Configurator Developer

Option Classes:

Option Class is an element of a Configuration Model.The purpose of Option Classes are to group and prevent viable alternatives. The end user typically selects one or more options from each Option Class during runtime to create a valid configuration.

Option Class Selection Rules:

BOM Model rules for selecting options from an Option Class during order entry:
•Required and Mutually exclusive:You must select one and only one Item in this Option Class
•Required:You must select one or more optional items in this Option Class
•Optional and Mutually Exclusive:You can select only one optional item in this Option Class
•Optional:Select none, some, or all optional items in this Option Class

BOM Example:

Oracle Configurator Fundamentals

2008-09-27T21:01:00.004-04:00

Oracle Configurator Introduction:

A configurator is a tool for configuring products and services. The configuration process can include assessing customer needs, selecting product and service components, and viewing configurations. Oracle Configurator can be integrated with the following applications,
•iStore
•Order management
•TeleSales
•Sales Online
•Quoting
•A custom Web Application

Oracle Configurator Supports:

# Configuration for Simple to Complex products and services
# Guided Buying or Selling for non-expert users
# Real-time validation during option selection
# Multiple User Interfaces (Uis) for different types of users accessing the same model
# Batch validation of configuration models
# Custom rule extensions to the configuration model
# APIs for integrating with other hosting applications, including custom Web applications
# BOM Synchronization
# Multiple Instantiation in Solution-based Models
# Model Networks and Connectivity
# Configuring Attributes

Oracle Configurator Architecture:

I. Three-Tier Architecture
• Data tier for Oracle Applications Database Server
• Application Tier for the Oracle Configurator Servlet and Internet or Web Server
• UI Tier for Configurator Thin Client UI
II. Runtime Oracle Configurator and Oracle Configurator Developer use the same data tier architecture .
III. Production Oracle Configurator and the test runtime Configurator. User Interface invoked from Oracle Configurator Developer are thin Client Uis using the same application tier architecture

Oracle Configurator Implementation Overview:

•Setup an Oracle Configurator development or test environment
•Import PTO and ATO BOM Model structures and Item Master data into Oracle Configurator Developer
•Use Oracle Configurator Developer to enhance the configuration model:
# Structure (imported from Oracle BOM or structure you create in Developer)
# Rules
# User Interface
•If required, extend the configuration model by using Functional Companions to:
# Access information outside the configuration model
# Perform engineering calculations
# Integrate with an alternative User Interface
# Write custom rules that cannot be created using OCD
•Test the configuration model and any Functional Companions against defined Test Cases.

Conceptual Overview of Configurator Implementation Flow:

RMA (Return) Order Cycle

2008-09-14T18:26:00.004-04:00

RMA Defined:

•Permission for a customer to return lines.
•Oracle Order Management allows you to authorize the return of your sales orders as well as sales made by other dealers or suppliers, as long as the items are part of your item master and price list.

Standard Return Flow:

Typical RMA Business Processes:

•RMA with credit only
–Your company issues a credit without the customer returning the product.
–Accept returns for credit by applying credits to original invoices or creating on account credits.
•RMA with receipt and credit
–Customer returns a product and receives credit.
•RMA with receipt and no credit
–Your customer returns a product you sent to them on a trial basis or at no charge, therefore they receive no credit.

Other RMA Types:

•RMA with repair
–Your customer returns a damaged product. Your company repairs and returns the product to the customer.
•RMA with replacement
–Your customer returns a product and your company sends a replacement product rather than issuing a credit.
•Returned item fails inspection
–Customer returns product, company inspects product and rejects it. Company scraps product or sends product back to customer.
•Trade in
–Return line on the same order as the product that the customer is purchasing.

Accounting Impact:

•During receipt of RMA in Receiving Inventory
Receiving Inventory Dr.
COGS Cr.
•During receipt into Subinventory
Material Dr.
Receiving Inventory Cr.
•During generation of Credit Memo
Revenue a/c Dr. to Receivables a/c Cr.

Tables that get updated:

•OE_ORDER_HEADERS_ALL
•OE_ORDER_LINES_ALL
•RCV_SHIPMENT_HEADERS
•RCV_SHIPMENT_LINES
•RCV_TRANSACTIONS
•RA_INTERFACE_LINES
•RA_CUSTOMER_TRX_LINES_ALL
•RA_CUSTOMER_TRX_ALL

Purchasing and Inventory Accounts commonly defined during Setup

2008-05-21T22:13:00.002-04:00

1. Purchasing:
Financial Options
Accounting Information
· Liability Account
· Prepayment Account
· Discount Taken Account
· Rate Variance Gain Account
· Rate Variance Loss Account

Purchasing Options
Accruals
· Expense AP Accrual Account

Receiving Options
Receiving Account (need one account per inventory organization; they can be the same).

2. Inventory:
Define Organization Parameters - All accounts in this section are required for each inventory organization; they can be the same between orgs.
· Inter-Org Transfer Accounts (required for setup)
· Inter-Org Receivable Account
· Inter-Org Payable Account
· Inter-Org Purchase Price Variance Account
· Intransit Inventory Account

Valuation Accounts
· Material Account
· Outside Processing Account (this won’t be used, so a suspense account is fine)
· Material Overhead Account (this won’t be used, so a suspense account is fine)
· Overhead Account (this won’t be used, so a suspense account is fine)
· Resource Account (this won’t be used, so a suspense account is fine)

Other Default Accounts
· Purchase Price Variance Account
· Invoice Price Variance Account
· Inventory Accrual Account
· Encumbrance Account (this won’t be used, so a suspense account is fine)
· Expense Account
· Sales Account
· Cost of Goods Sold Account (this is a default; each item can have a COGS account as well)
· Average Cost Variance Account (this probably won’t be used, so a suspense account is fine)

Define Subinventory - All accounts in this section are required for each subinventory in each org; they can be the same as the org level, and can be the same between subinventories.

Subinventory Accounts
· Material Account
· Outside Processing Account (this won’t be used, so a suspense account is fine)
· Material Overhead Account (this won’t be used, so a suspense account is fine)
· Overhead Account (this won’t be used, so a suspense account is fine)
· Resource Account (this won’t be used, so a suspense account is fine)
· Expense Account
· Encumbrance Account (this won’t be used, so a suspense account is fine)

Define Freight Carriers - Need an account for each carrier defined; they can all be identical, overlapping (Ground account vs. Express account) or unique; freight carriers are optional, and may not be set up.

Define Inter-Org Shipping Information
· Inter-Org Transfer Credit Account
· Inter-Org Receivable Account
· Inter-Org Payable Account
· Inter-Org Purchase Price Variance Account
· Intransit Inventory Account

Define Overhead
· Absorption Account

Define Item - need an account code for each item defined; they can be identical, overlapping, or unique; these accounts are optional since they will default from the subinventory or organization
· Cost of Goods Sold Account
· Encumbrance Account (this won’t be used, so a suspense account is fine)
· Expense Account
· Sales Account

Troubleshooting Guide - Create Release against Blanket PO

2008-05-21T22:02:00.002-04:00

You have 3 basic choices for the requisitions created by this process:
1. Release against a blanket PO
2. Autocreate into POs
3. Release as standard PO (but you must have a quotation to use instead of a blanket -- pricing has to come from one or the other).

The general process for release against a blanket (or quotation) is:

1. Create a blanket PO with lines for all parts to be sourced. Enter a price for each line. (Or, enter a quotation).

2. Define a sourcing rule (Purchasing > Supply Base > Sourcing Rules)
Enter a name for the sourcing rule.
Org = your org name
Type = buy from
Supplier = name of supplier on blanket PO or quotation.
Supplier site = name of supplier site on blanket PO or quotation.
Allocation = 100% (must be 100%)

3. Assign the sourcing rule to an Assignment Set (Purchasing > Supply Base > Assign Sourcing Rules)
Enter an Assignment Set Name (for example "MRP Planned Items"
Assigned To (I usually pick Item/Organization)
Org = your inventory org code
Item/Category = part being sourced
Type = sourcing rule
Sourcing Rule = name you created in Step 2

4. You must then enter this Assignment Set Name at the responsibility level for the system profile option MRP: Default Sourcing Assignment Set.

5. Create Approved Supplier List
Upper half of screen:
Type = Item
Enter Item Number
Lower half of screen:
Business = direct
Name = name of blanket PO vendor from step #1
Site = site of vendor from step #1 (must be same site as defined in step #2)
Status - changed to "approved".
Global = no
Owning org = your inventory org name

Click on Attributes button
Enter Purchasing UOM (required)
Select release method:
Automatic release (no review)
Automatic release with review
Release using Autocreate (for greatest control)
Sequence = 1
Type = either Blanket or Quotation
Blanket Number & Line Number
Blanket Status (blanket PO must have been approved).

Support also states that you can also use a quotation to turn a requisition into a standard PO in a similar process, but I have never tested this. Try entering a quotation in the PO module and reference this instead of Blanket in the Approved Supplier List form.

You can also take the approved requisitions and just turn them into POs using the autocreate function. But be sure that you have "Approve Purchase Requisitions" as one of the functions on the Approval Assignments form or the reqs will be "incomplete" instead of "approved" and you cannot then autocreate them onto POs. (That error cost me two whole days to find.......)

Oracle Lease Management Overview

2008-05-21T20:57:00.002-04:00

Lease Life Cycle :

a) Credit Checking of the Lessee (Customer)
b) Author a Contract between Lessor and Lessee
c) Bill the Lessee during a Contract Term
d) Receive Payments from Lessee during the term of the contract
e) Lessee interacts with Lessor during the term of contract.
i. May inquire regarding his payments or next invoice
ii. May request for some additional Product information
iii. May dispute an invoice.
iv. On the basis of Lessee’s interaction, Lessor’s agent may initiate certain tasks internally or send some notifications

f) At the end of Contract term, as per T&C of the contract
i. Lessee may return the Asset to Lessor
ii. Lessee may purchase the Asset
iii. Lessee may renew a contract
g) Lessor sends quote to the lessor if there is a purchase option as per T&C
i. May be an early termination Quote
ii. End of Term Quote
h) Asset is returned to the Lessor
i. Asset may become part of inventory which can be re-leased later
ii. Asset may be remarketed

OLM integrates the power of Oracle’s ERP, CRM and Contract Applications for complete leasing solution.

Key Business Flows:
OLM has designed the following Key Business Flows to address all the scenarios of a typical Lease Life Cycle

1. Credit Application to Booking
2. Invoice to Receipt
3. Asset return to Disposal
4. Quote to termination
5. Inquiry to Resolution
6. Period Open/Close - This is purely Accounting setup

Oracle APPS responsibilities for OLM:

All the Key Business Flows except Inquiry to Resolution are performed by
Logging into OLM HTML Version. Lease Super User module is used

OLM has number of concurrent programs for processing data within OLM and transfer of data to other modules like AP, AR, GL etc. All these concurrent Programs are accessed by using Lease Administrator responsibility which is in Oracle Forms Version.

Lease Center Agent Responsibility in Oracle Forms Version is used for the inquiry to Resolution Business Flow.

1. Credit Application to Booking:

Modules involved: AP, FA, GL, Inventory, Contracts Core and Installed Base
A Third party Lease Price modeling software, SUPER TRUMP performs stream generation and Lease Pricing

· Credit Approval
· Authoring a Contract
· Vendor Payment
· Asset Tracking

For some clients, Credit Application of the Lessee( Customer) is processed in a separate system.
Approved contract is entered in OLM. Contract information is available different subsystems. Most of the times, Contract has to be imported by drawing information from those subsystems.
In a few cases, we may be entering a Contract from scratch

2. Invoice to Receipt:
Modules involved: AR, Collections, GL, Contracts for Service

Billing functionality identifies items to be passed onto lessee.
Billable items are as follows

· Cost of the equipment – multiple assets
· Fees incurred like Customer Service Fee, Documentation Fee
· Expenses like Insurance premium, Installation charges
· Taxes like Sales Tax, VAT

Billing amounts may be generated automatically or manually
Lessee may have assets at multiple locations under same lease contract
Various Billing requirements like Usage Based Billing
Payments from Lessee – Receipts to Lessor
Transfer of funds – Lessee or Lessor may initiate
Mode of Payments: Direct Debits, Checks, Wire Transfers or Credit Cards
Notifications to Customers
Collections – missing Payments, delinquent, litigations etc

3. Quote to Termination:

Modules involved: AR, FA, CRM Foundation, Workflow and GL

Alternatives when a Lease Contract expires

· Manage a repurchase
· Restructure a Contract
· Terminate a Contract

OLM processes restructured contracts through Contract authoring and Booking
Request for a renewal or termination quote
Complete termination of Contract
Update Asset records

When termination quote for sale is accepted, assets are retired in Fixed Assets

4. Asset return to Disposal:
Modules involved: iStore, Marketing Online, Advanced Pricing, CRM Foundation

· Asset returns
· Remarketing

Asset evaluation process
Shipping instructions for returned Assets.
Returns may be accounted as scrap, or inventory to be remarketed
Remarketing manages disposition of Assets when a Lease expires.
Sale of Asset to a 3rd Party or internal remarketing efforts

5. Inquiry to Resolution:
Modules involved: CRM Foundation, Telesales, E Business Center

Customer Service representative tracks a customer inquiry through its resolution.
Communicate to appropriate authorities regarding tasks to be performed for resolving a customer query
Define processes to manage specific requests such as:
· Insurance quotes
· Claims
· Contract transfers
· Equipment exchanges
· Asset modifications
· Lease Renewals

Components of CRM Foundation used in OLM

· Resources
· Sales Representatives
· Remarketers
· Assignment Groups
· Interaction History
· Fulfillment

Summary of the modules used in OLM:

Functional
Financials : GL, AP, AR and FA
Contracts: Contracts core, Contracts Service
CRM: CRM Foundation, Installed Base, Telesales, iStores, Marketing Online
Distribution: Inventory, Advanced Pricing
(Telesales – Customer Service and Collections Functionality)

Technical
Workflow – Processes Approvals and Notifications
XML gateway – Integrates with Lease Price Modeling Software
Advanced Inbound and Outbound – Customer Service, Call Center functionality, Universal Workques, Fulfillment Server

Oracle Apps Reporting Tools

2008-05-19T14:55:00.004-04:00

Introduction : Oracle provides over a thousand standard reports within the application. These standard reports are developed to cover common generic needs. Before creating any new reports, one should examine the standard report sets to determine if any meet the requirements. If requirements cannot be met with the standard Oracle report sets, tools are available to create custom reports.

The following matrix addresses reporting tool options, including:

A brief description
Who should be provided the access to the tool?
Advantages
Disadvantages
When is it appropriate to use?

(Click anywhere on the below image to ZOOM and read the complete table):

Inventory Flexfield Structure Definition for a Food Processing and Distribution Company

2008-05-17T22:46:00.006-04:00

Introduction - This real world case study on proposed item structure for a Food Processing and Distribution Company was based on the requirements of business, gathered through discussions during the implmentation project, as well as recommendations submitted by consultants.

1. Objective

The Decision on Inventory Flex fields Structure was taken based on achieving the following Objective:

Ø Item code structure across all Product lines & Products is required to be uniform;
Ø Item code should be simple and short;
Ø Item code numbering should be driven by a simple logic to avoid deciphering the codes by field staff;
Ø Item code should be independent of the personal view of the person defining the item;
Ø Item code should not be dependent on either supplier or customer codes;
Ø Each item should have code and a description to identify the item uniquely;
Ø Code should not be repeated in description and vice-versa;
Ø Expiry date and location of the item should be identified
Ø All items should be properly classified in a logical manner, so that MIS reports can be generated; and
Ø All existing reporting requirements are met, in addition to the reports available in Oracle Inventory.

In Oracle Inventory, an Item should have a System Flex field; in order to take advantage of the Oracle Apps, features, it is also recommended to use Category Sets, Lot number control and Locator to define an Item.

Based on the above, the following item code structure was designed.

2. System Item Flexfield

The System Item Flex field is used to define the Item Code through which an Item in the Inventory is identified uniquely. For the client's business, the System Item Flex field will be:

No. Of segment = 1
Segment Name = Item

Size = 6 Numeric

The segment will have serial no starting from 000001 to 999999. This gives flexibility to have 999999 items in the company. To ensure that items are numbered in a logical manner, range of serial no. will be allocated, so that serial no. can be used only from the range.

As a next step, Description of the item has to be entered to save the item in the system. It is proposed that the name of the supplier/brand, existing description and the package size shall be entered in description, eg. ABC Supplier (Brand), Mod Chicken (Description) and 900 grams (package size) so the description would be 'ABC Supplier Mod Chicken 900 Grams'.

3.Category Set

A Category is a logical major classification of items that have similar characteristics. A Category Set is a set of distinct categories in which an Item can be grouped/classified. E.g. one grouping or classification can be based on “Buying”; another grouping or classification for the same Items can be based on the Physical Inventory attributes. The flexibility of having multiple category sets allows reporting and query on items in a way that best suits business needs.

For our common business requirements across all departments, an Inventory Category Set will be created at the beginning with the following four segments:

*The segment size has been considered keeping in view that most of the business requirements are met. As these 6 segments are required to appear in Reports, GRNs, PO & Invoices hence, having longer size would mean that on the reports, other information might not fit in 80-column Or 128 column Stationery.. However, in system their full description can be entered and maintained. It is also advisable that these categories can be numbered properly to avoid extending the report size.

The values for the above 6 segments will have to be first updated and combinations also created. This will then be available as List of Values (LOV). Every time an item is created, this default category set structure will be attached to the Item, and the values for each of the segments can be selected from LOV. Few items have been classified under four segments:

Once a Category set is attached to an item, reports on its segments i.e. Focus, Brand, Category, Base Product, Product & Size can be generated. For an existing item, a Category set can be delineated, if required, and a new category set attached. Last change audit trail will be available in the system. A new category set can also be created or an existing Category set be disabled.

4. Lot Control

Lot control feature can be utilized to capture the expiry of items in the inventory. It plays a crucial role in the organizations, which are into Food Processing, Pharmaceutical and products that get expired due to elapse of time. It is proposed that the lot control feature can be enabled and used for all products. Basically, system will require a lot number and expiry date to be entered by the user to complete the transaction. Transactions are as follows:

A. Material Receipts
B. Transfer goods from one location to another location and
C. Material Issues

In case of material transfer between locations, user has to choose the lot number, which is already assigned to the items. This will eliminate multiple lot numbers assigned to single item in different locations for a better control. To ease the operations, it is proposed that the ETA date (Expected Time of Arrival) shall be entered as lot number for the item and the user has to input expiry date of the item. Preferably, these lot numbers should be pasted on the Pallets so that the inventory clerk can easily identify the location of the goods.

5. Locator Structure (To be used in Future)

Locators are used to identify physical location where the item is actually stored in the Warehouse/Store. Locator can track item quantity. An Item can also be restricted to a specific locator or a locator can be dynamically assigned to the item on receipt.

In order to use this available feature for better managing the inventory, we need to –
Ø Design the locator storage system based on the warehouse space and use structure for storing items.
Ø Paint the palettes using standard primary colors.
Ø Assign numbers to all the palettes.
Ø Define all the locator addresses in the Inventory system.
Ø Attach item to a locator.

It is proposed to use a Locator segment of Colour & Number, for e.g. R120 would mean RED colour palette number 120. This detail will help in tracking the item during transfers, issues and also during taking physical stock of the items. Proposed locator address structure is given below:

It is proposed that the locator will be defined in the system but the users will be using it once they are well versed with the system. The locators segment have to entered on following transactions:

A. Material Receipt to Warehouses
B. Transfer of goods from one location to another location
C. Movement of Goods within the warehouse
D. Issue of materials to Customers and Vans
E. Receipt of materials from Van and Customers

6. Benefits of the Proposed Item Structure

a. At the time of Item creation, the only User logic built into the item code is the Sub Division to which the item belongs.
b. The Item Code is short with one segment and is uniform across all Products.
c. Company can have up to 999999 items.
d. The Item Code is not dependent on the item code of the Vendor or Customer and is unique to the Client.
e. The probability of making duplicate item code is nil since the Item Code is unique in inventory. f. Items have been classified in an Inventory Category Set with six segments Type, Product Line, Brand and Product. In the existing system the classification is more or less the same. Focus, Brand, Category, Base Product, Product & Size will be available as List of Values for selection, so that typographical errors are avoided. However, it is important that the selection is correct to avoid changing the category subsequently.
g. Inventory Reports can be generated on any of the segments i.e. Item Code, Description, Focus, Brand, Category, Base Product, Product & Size to sort the items in Inventory Organization.
h. An Item can be attached with lot numbers & Locator to identify the location and expiry dates.
i. Stocks can be maintained Expiry date wise

Accounting entries in Receivables

2008-05-17T21:45:00.003-04:00

A quick re-cap of accounting entries generated in Oracle Receivables:

Invoices:
When you enter a regular invoice through the Transactions window, Receivables creates the following journal entry:
DR Receivables
CR Revenue
CR Tax (if you charge tax)
CR Freight (if you charge freight)

If you enter an invoice with a Bill in Arrears invoicing rule with a three month fixed duration accounting rule, Receivables creates the following journal entries:
In the first period of the rule:
DR Unbilled Receivables
CR Revenue

In the second period of the rule:
DR Unbilled Receivables
CR Revenue

In the third and final period of the rule:
DR Unbilled Receivables
CR Revenue

DR Receivables
CR Unbilled Receivables
CR Tax (if you charge tax)
CR Freight (if you charge freight)

If you enter an invoice with a Bill in Advance invoicing rule, Receivables creates the following journal entries:

In the first period of the rule:
DR Receivables
CR Unearned Revenue
CR Tax (if you charge tax)
CR Freight (if you charge freight)

DR Unearned Revenue
CR Revenue

In all periods of the rule for the portion that is recognized.
DR Unearned Revenue
CR Revenue

Credit Memos:
When you credit an invoice, debit memo, or chargeback through the Credit Transactions window, Receivables creates the following journal entry:
DR Revenue
DR Tax (if you credit tax)
DR Freight (if you credit freight)
CR Receivables (Credit Memo)

DR Receivables (Credit Memo)
CR Receivables (Invoice)

When you credit a commitment, Receivables creates the following journal entries:
DR Revenue
CR Receivables

When you enter a credit memo against an installment, Receivables lets you choose between the following methods: LIFO, FIFO, and Prorate. When you enter a credit memo against an invoice with invoicing and accounting rules, Receivables lets you choose between the following methods: LIFO, Prorate, and Unit.

If the profile option AR: Use Invoice Accounting for Credit Memos is set to Yes, Receivables credits the accounts of the original transaction. If this profile option is set to No, Receivables uses AutoAccounting to determine the Freight, Receivables, Revenue, and Tax accounts. Receivables uses the account information for on-account credits that you specified in your AutoAccounting structure to create your journal entries.

Receivables lets you update accounting information for your credit memo after it has posted to your general ledger. Receivables keeps the original accounting information as an audit trail while it creates an offsetting entry and the new entry.

Commitments:
When you enter a deposit, Receivables creates the following journal entry:
DR Receivables (Deposit)
CR Offset Account

Use the AR: Deposit Offset Account Source profile option to determine how Receivables derives the Offset Account to credit for this deposit.

When you enter an invoice against this deposit, Receivables creates the following journal entries:
DR Receivables (Invoice)
CR Revenue
CR Tax (if you charge tax)
CR Freight (if you charge freight)

DR Offset Account (such as Unearned Revenue)
CR Receivables (Invoice)

When you apply an invoice to a deposit, Receivables creates a receivable adjustment against the invoice. Receivables uses the account information that you specified in your AutoAccounting structure to create these entries.

When cash is received against this deposit, Receivables creates the following journal entry:
DR Cash
CR Receivables (Deposit)

When you enter a guarantee, Receivables creates the following journal entry:
DR Receivables
CR Revenue

Receivables uses the Receivable Account and Revenue Account fields on this guarantee's transaction type to obtain the accounting flexfields for the Unbilled Receivables and Unearned Revenue accounts, respectively.

When you enter an invoice against this guarantee, Receivables creates the following journal entry:
DR Receivables (Invoice)
CR Revenue
CR Tax (if you charge tax)
CR Freight (if you charge freight)

DR Revenue
CR Receivables

When you apply an invoice to a guarantee, Receivables creates a receivable adjustment against the guarantee. Receivables uses the account information you specified in your AutoAccounting structure to create these entries.

When cash is received against this guarantee, Receivables creates the following journal entry:
DR Cash
CR Receivables (Invoice)

Receipts:
When you enter a receipt, Receivables creates the following journal entries:
DR Cash
CR Receivables

When you fully apply a receipt to an invoice, Receivables creates the following journal entry:
DR Cash
DR Unapplied Cash
CR Unapplied Cash
CR Receivables

Note: These examples assume that the receipt has a Remittance Method of No Remittance and a Clearance Method of Directly.

When you enter an unidentified receipt, Receivables creates the following journal entry:
DR Cash
CR Unidentified

When you enter an on-account receipt, Receivables creates the following journal entry:
DR Cash
CR Unapplied

DR Unapplied
CR On-Account

When your receipt includes a discount, Receivables creates the following journal entry:
DR Receivables
CR Revenue

DR Cash
CR Receivables

DR Earned/Unearned Discount
CR Receivables

Receivables uses the default Cash, Unapplied, Unidentified, On-Account, Unearned, and Earned accounts that you specified in the Remittance Banks window for this receipt class.

When you enter a receipt and combine it with an on-account credit (which increases the balance of the receipt), Receivables creates the following journal entry:
DR Cash
CR Unapplied Cash

To close the receivable on the credit memo and increase the unapplied cash balance, Receivables creates the following journal entry:
DR Receivables
CR Unapplied Cash

When you enter a receipt and combine it with a negative adjustment, Receivables creates the following journal entries:
DR Cash
CR Receivables (Invoice)

DR Write-Off
CR Receivables (Invoice)

You set up a Write-Off account when defining your Receivables Activity.

When you enter a receipt and combine it with a positive adjustment, Receivables creates the following journal entries:
DR Cash
CR Receivables (Invoice)

DR Receivables (Invoice)
CR Write-Off

When you enter a receipt and combine it with a Chargeback, Receivables creates the following journal entries:
DR Cash
CR Receivables (Invoice)

DR Receivables (Chargeback)
CR Chargeback (Activity)

DR Chargeback (Activity)
CR Receivables (Invoice)

You set up a Chargeback account when defining your Receivables Activity.

Remittances:
When you create a receipt that requires remittance to your bank, Receivables debits the Confirmation account instead of Cash. An example of a receipt requiring remittance would be a check before it was cashed. Receivables creates the following journal entry when you enter such a receipt:
DR Confirmation
CR Receivables

You can then remit the receipt to your remittance bank using one of the two remittance methods: Standard or Factoring. If you remit your receipt using the standard method of remittance, Receivables creates the following journal entry:
DR Remittance
CR Confirmation

When you clear the receipt, Receivables creates the following journal entry:
DR Cash
DR Bank Charges
CR Remittance

If you remit your receipt using the factoring remittance method, Receivables creates the following journal entry:
DR Factor
CR Confirmation

When you clear the receipt, Receivables creates a short-term liability for receipts that mature at a future date. The factoring process let you receive cash before the maturity date, and assumes that you are liable for the receipt amount until the customer pays the balance on the maturity date. When you receive payment, Receivables creates the following journal entry:
DR Cash
DR Bank Charges
CR Short-Term Debt

On the maturity date, Receivables reverses the short term liability and creates the following journal entry:
DR Short-Term Debt
CR Factor

Adjustments:
When you enter a negative adjustment against an invoice, Receivables creates the following journal entry:
DR Write-Off
CR Receivables (Invoice)

When you enter a positive adjustment against an invoice, Receivables creates the following journal entry:
DR Receivables (Invoice)
CR Write-Off

Debit Memos:
When you enter a debit memo in the Transactions window, Receivables creates the following journal entries:
DR Receivables
CR Revenue (if you enter line amounts)
CR Tax (if you charge tax)
CR Freight (if you charge freight)

DR Receivables
CR Finance Charges

On-Account Credits:
When you enter an on-account credit in the Applications window, Receivables creates the following journal entry:
DR Revenue (if you credit line amounts)
DR Tax (if you credit tax)
DR Freight (if you credit freight)
CR Receivables (On-account Credit)

Receivables uses the Freight, Receivable, Revenue, and Tax accounts that you specified in your AutoAccounting structure to create these entries.

Once the on-account credit is applied to an invoice, the following journal entry is created:
DR Receivables (On-account Credit)
CR Receivables (Invoice)

Oracle Projects - Steps to make the Project Budgetary Control features work

2008-05-04T22:48:00.002-04:00

Published on behalf of Ravishankar Panchapagesan:

· Set the value of the profile PA : Enable Budget Integration and Budgetary Control

· Enable Budgetary Control in the Set of Books window and choose a default Encumbrance account

· For the Budget Control Group “Standard” in GL menu, enter Projects as the source and Total Burdened Cost as the category and choose the fund check level of “ None”

· Ensure this is the value of the profile at the application or responsibility for the profile option “Budgetary Control Group”

· Check “Use PO Encumbrance in Payables Financial Option and enter values for PO and Invoice encumbrance type.

· In Purchasing menu, Open the Encumbrance year and period. In Purchasing, there are 2 Forms. One for Open and Close Periods and the other for Control Purchasing Periods. Use the Control Purchasing Period to open the Encumbrance Year and the corresponding GL period. This is a pre requisite for encumbrance to work. Use the Open and Close Periods for controlling Purchasing Period.

· Complete the set ups for Project type, budgetary control tab and create project templates and projects using the set up.

· Ensure that the budget entry method allows the entry of Total Burdened cost. You do not have to burden the transactions. System populates the raw cost budget into this field for budgetary control check.

· Ensure the pre requisite GL patches (No 1995914 and 2002508) are in the application. These patches are included in PA M as cumulative components.

· Enter transactions in AP and verify the process. Upon saving the invoice, navigate to the Tools Menu and click “ Check Funds” menu. System will display a message whether the invoice and its distribution lines will pass or fail funds check.

· Validate the invoice normally. Funds check will be performed upon validation based on the amount type and boundary code associated with the Project and the control levels chosen for the project, task, resource group and resource list level.

· Invoices that failed the funds check upon validation with the reason code “Funds checking could not be performed” cannot be manually released. You need to enhance the funds available.

· You can view the Transaction Funds Check Results in Projects regardless of the interface from AP.

· For each line that is passed funds check, in the above window, the system will display 2 rows: 1 with the status “Passed funds check” and the other with the status “Approved”

· Interface validated and accounted invoice distribution lines to Projects normally.

· Schedule to run the process PRC: Maintain Budgetary Control Balances based on business requirements. When this process is run, the system purges details of Funds check results display. Choose to run this process in conjunction with the value of profile option for PA: Days to maintain BC packets

· You cannot change the budget amount type for budgetary control in the Projects window after supplier invoice costs are incurred. However, you can change the control values and amount type and boundary codes. If you do, system will prompt the user to re baseline the current version of the cost budget used.

Implementing iExpenses for a Global Professional Services Firm (Part 2)

2008-04-18T16:39:00.003-04:00

Detailed Functional Components of iExpenses:

1. Expense Report Entry:

1.1 Create Expense Report:
· Employees log on to Oracle Web Expense and enter their expense report using a standard Web browser.
· Employees enter general information about their expense report in the Report Information region.
· Employees enter their expenses in the Enter Receipts region.
· iExpense offers a “disconnected solution”, to meet the needs of employees with limited access to the corporate intranet. Employees can enter expense reports off line, and save them for later submission, when intranet access is available.
· The disconnected expense reporting process involves the following:
· Employees use the Download Expense Spreadsheet function to save a copy of Client’s expense spreadsheet template locally. Employees must be connected to the corporate intranet in order to use the Download Expense Spreadsheet function.
· Employees use an expense spreadsheet to enter their expense reports while disconnected from the corporate intranet.
· Employees use the Upload Expense Spreadsheet function to transfer expense reports created with a spreadsheet to iExpense. Once uploaded, the transferred information appears as an expense report in iExpense, and employees can update, save, or submit it. Employees must be connected to your corporate intranet to use the Upload Expense Spreadsheet function.
· iExpense automatically populates the Cost Center field with the cost center of the employee requesting reimbursement.
· For manager approval, employees direct their expense report to their manager. When required, employees can redirect their expense report for approval by entering a value in the Override Approver field of the expense report template.

1.2 Review:
· iExpense enables employees the opportunity to review their expense report before they submit it.
· Employees use the View Receipts region to view expense lines in the order they entered them.
· The View Receipts region also identifies the expense lines for which your accounts payable department requires original receipts.
· Employees can use the Expense Summary region to view weekly summaries of their expense reports.
· The Expense Summary region displays amounts for each expense type. Employees can click on amounts to see detailed information for the receipt(s) that make up that amount.
· iExpense enables employees to check the status of their expense report(s).
· Employees can see whether their expense reports have been approved by their manager.
· Employees can see whether the accounts payable department has reviewed their expense reports.
· To view expense report statuses, employees choose the View Expense Report History function from the main menu.
· If an employee’s expense report has been adjusted by the accounts payable department, the employee can choose the View Expense History function, to see why an adjustment was made to their expense report.

1.3 Submit Expense Report:
· Employees submit their expense report using a standard Web browser.
· After employees submit their expense report, it is their responsibility to send original receipts to the accounts payable department for verification.

2. Validation:

2.1 Server Side Validation:
· The Server Side Validation process adds required information to the AP Expense Report Headers, and AP Expense Report Lines tables in order for the workflow approval processes and the Payables Invoice Import program to function properly.
· The accounts payable department can query and view Web Expense reports only after the expense reports pass the Server Side Validation process.

2.2 Manager (Spending) Approval Process:
· The Manager (Spending) Approval Process routes expense reports to managers for their approval.
· If an expense report receives manager approval, it transitions to the AP Approval Process.
· If a manager rejects an expense report, the expense report transitions to the Rejection Process.
· When managers reject expense reports, The Rejection Process begins.
· With this process, the employee is notified that their expense report(s) has been rejected.
· Employees can retrieve, fix, and resubmit rejected expense reports by using the Modify Expense Reports function.

2.3 AP Approval Process:
· The AP Approval Process first determines whether expense reports require the approval of the accounts payable department as defined in the AP Expense Report Workflow.
· If accounts payable approval is not required, the process automatically gives accounts payable approval.
· If expense reports require accounts payable approval, then the process waits for the results of the accounts payable department review.
· The accounts payable department uses the Expense Reports window in Oracle Payables to review, adjust, short pay, and approve iExpense reports.
· The accounts payable department approves expense reports by checking the Reviewed by Payables check box.
· Once the expense report has been approved by the accounts payable department, the Invoice Import program in Oracle Payables converts the expense report into an invoice for payment.

3. Payables:

3.1 Payables Import Process:
· Submit the Payables Invoice Import program in Oracle Payables to convert expense reports into invoices.
· An iExpense report is eligible for Invoice Import after successfully completing the AP Expense Report workflow process.
· When expense reports cannot be imported, Payables prints the Invoice Import Rejections Report.
· If the expense report is rejected, correct the problems, and resubmit the Payables Invoice Import program.

3.2 Accounts Payable Approval/Pay Expense Reports:
· iExpense enables you to enforce company expense report and reimbursement policies.
· To enforce policies, the accounts payable department uses the Expense Reports window in Oracle Payables to approve, adjust, or short pay employee expense reports.
· When the accounts payable department adjusts an expense report, the AP Approval workflow process informs the employee of the reason for, and the amount of, the adjustment.
· When the accounts payable department short pays an expense report, the Shortpay Unverified Receipt Items workflow does the following:
· Creates a new expense report from the lines which have missing required receipts, and/or creates a new expense report from the lines which have inadequate justifications.
· Eliminates the lines the accounts payable department short paid from the original expense report and approves it.
· Once the accounts payable department has approved, and/or adjusted the employee’s expense report, a payment is created for the invoice in the same manner as other invoices.

4. The Expense Report Template:

4.1 Descriptive Flexfields:
· Descriptive Flexfields enable employees to enter additional information about receipts not otherwise captured in iExpense.
· Descriptive Flexfields can be defined so they appear as either a text box with a poplist that contains a list of values, a check box, or a text box.
· Descriptive Flexfields have two different kinds of segments or fields, global and context sensitive.
· Context sensitive segments appear only when an employee selects expense types to which you have associated flexfield segments.
· Global segments always appear in the Enter Receipts region, regardless of the expense type an employee chooses.
· The Descriptive Flexfields defined for Web Expense also appear in the Expense Reports window in Oracle Payables.
· To plan context sensitive and global descriptive flexfields for use in iExpense you must:
· Determine for which expense types you want to collect additional information. These are the context sensitive segments.
· Determine what information you want to collect regardless of expense type. These are the global segments.
· Determine how you want employees to enter information. You can choose from the following three methods:
· a text box with a poplist that contains a list of values
· a check box
· a text box.

4.2 Multiple Expense Templates:
· An expense template defines the list of expense types (airfare, car rental, meals, etc.) employees can choose from when they enter their expense reports.
· You can define multiple expense report templates for use with iExpense.
· If you define multiple expense report templates, employees can select an expense report template from a list of values in the Report Information region.

4.3 Original Receipts:
· When you define expense report templates for use with iExpense, you can indicate whether an original receipt is required for an expense type.
· You can also indicate that an original receipt is required only if the expense exceeds a certain limit.
· The employee can see whether an original receipt is required in the View Receipts region of iExpense.
· Employees have the ability to indicate that they do not have an original receipt by checking the Original Receipt Missing check box in the Enter Receipts region.
· iExpense can be set up so when employees check the Original Receipt Missing check box, it changes the status of a receipt from required to unrequired.

4.4 Refund/Credit Tracking:
· Set up iExpense so employees can enter negative receipts (credit lines) when creating an expense report.
· Employees enter negative receipts to report refunds from a previous reimbursed expense (I.e., the refund of an unused airline ticket).

4.5 Required Justifications:
· Set up iExpense so employees are required to enter justifications for specific expenses.
· When you define an expense report template, you can indicate whether justification is required for the expense.

4.6 Required Purpose:
· Set up iExpense so employees are required to provide a purpose for their expense report.
· When you define an expense report template, you can indicate whether a purpose is required for the expense.

4.7 Expense Report Number Prefixes:
· You can define a prefix for every expense report entered in iExpense.
· Entering a prefix value enables you to easily identify invoices in Oracle Payables originally created as iExpense employee expense reports.

Revenue Recognition and Invoicing Rules explained

2008-04-18T15:42:00.013-04:00

Revenue recognition principle is an important accounting principle, which is the main difference between cash basis accounting and accrual basis accounting. In cash basis accounting revenues are simply recognized when cash is received no matter when and how the services were performed or goods delivered. In accrual basis accounting revenues are recognized when they are (1) realized or realizable and (2) earned no matter when cash is received.

Revenue recognition criteria according to US GAAP:
USSEC's SAB104 states that revenue generally is realized or realizable and earned when all of the following criteria are met:
1. Persuasive evidence of an arrangement exists;
2. Delivery has occurred or services have been rendered;
3. The seller's price to the buyer is fixed or determinable; and
4. Collectability is reasonably assured

Invoicing Rules and Accounting Rules:
In Oracle AR, the invoicing and accounting rules help create invoices that span several accounting periods. Accounting rules determine the accounting period or periods in which the revenue distributions for an invoice line are recorded. Invoicing rules determine the accounting period in which the receivable amount is recorded.

Accounting Rules:
Accounting rules determines revenue recognition schedules for invoice lines. Different accounting rules can be assigned to each invoice line. Using Accounting rules, the number of periods and the percentage of the total revenue to recognize in each period can be specified. Also accounting rules can be Fixed or Variable Duration.

Clients can also create rules that will defer revenue to an unearned revenue account. This helps in the delay of specifying the revenue recognition schedule until the exact details are known. When these details are known, clients use the Actions wizard to recognize the revenue.

Invoicing Rules:
Invoicing rules determines when to recognize receivable for invoices that span more than one accounting period. Clients can only assign one invoicing rule to an invoice. Receivables provides the following invoicing rules:
• Bill In Advance: Use this rule to recognize your receivable immediately.
• Bill In Arrears: Use this rule if you want to record the receivable at the end of the revenue recognition schedule.

Using Invoices with Rules:

Assigning Invoicing Rules:
• Invoicing rules determine whether to recognize receivables in the first or in the last accounting period.
• Once the invoice is saved, you cannot update an invoicing rule.
• If Bill in Arrears is the invoicing rule, Oracle Receivables updates the GL Date and invoice date of the invoice to the last accounting period for the accounting rule.

Assigning Accounting Rules To Invoice Lines:
• Accounting rules determine when to recognize revenue amounts.
• Each invoice line can have different accounting rule.

Creating Accounting Entries:
• Accounting distributions are created only after the Revenue Recognition program is run.
• For Bill in Advance, the offset account to accounts receivable is Unearned Revenue.
• For Bill in Arrears, the offset account to accounts receivable is Unbilled Receivables.
• Accounting distributions are created for all periods when Revenue Recognition is run.

Running The Revenue Recognition Program:
• The Revenue Recognition program gives control over the creation of accounting entries.
• Submit the Revenue Recognition program manually through the Run Revenue Recognition window.
• The Revenue Recognition program will also be submitted when posting to Oracle GL.
• The program processes revenue by transaction, rather than by accounting period.
• Only new transactions are selected each time the process is run.

Implementing iExpenses for a Global Professional Services Firm (Part 1)

2008-04-15T11:27:00.010-04:00

Client and Business Case - Global Professional Services Firm executing projects globally wanted to implement Oracle Internet Expenses to support employee expense reporting and reimbursement. Oracle iExpenses was implemented to enable Client employees to independently enter and submit their expense reports on-line, real time, utilizing a standard Web browser or a Web-enabled mobile device. Oracle Workflow was configured to automatically routes expense reports for approval and enforce reimbursement policies. Oracle iExpenses integrates with Oracle Payables and Oracle Projects to provide quick processing of expense reports for payment.

Key Features implemented - The implementation of iExpense enabled the client to benefit from the following functionalities:

1. Enable employees to record, and submit expense reports using a standard Web browser.

2. Provide employees a “disconnected solution” when access to a corporate intranet is not available.

3. Use Descriptive Flexfields to enter additional information about expense related receipts not otherwise captured in the Expense Template.

4. Define multiple Expense Templates. Employees can choose from a List of Values the Expense Template(s) available.

5. Define Expense Templates, and indicate whether an original receipt is required for the expense type so employees are aware of the original receipts requirement.

6. Use Oracle Workflow with Oracle Web Expense to automatically route expense reports for approval, and enforce reimbursement policies.

7. Use Oracle Web Expense to seamlessly integrate with Oracle Payables so expense reports can be quickly processed for payment.

8. Create “Authorized Delegates” to authorize a user to enter expense reports for another employee. (i.e., An executive assistant is given the authority to enter expense reports for their manager.)

9. Indicate in the Expense Template if original receipts are required.

10. Allow employees to enter negative receipts to report refunds, or credits against their reported expenses.

High Level Business Flow:

Key Components of the implementation:

In my next post, I will try and expand on each of the key components implemented above.

Configuring for TAX in Oracle Apps (Rel 12)

2008-04-14T17:07:00.003-04:00

Supported Tax Software Versions - Following Vertex and Taxware Versions are Certified for Release 12:
Vertex Q Series 3.2
Taxware 3.5.0
Please be sure to mention to Vertex / Taxware that you would need file for Release 12. The data files have been changed in Release 12 and you can not use the same file as in Release 11i or before.

Loading Tax information into Rel 12i:
1) Please get datafile from tax partners (Vertex or Taxware) in R12 format .
2) Copy file to a Linux or Unix directory. Filename - *.dat. Please note that loading the datafile into interface table is a part of the Request Set and will not need to be done manually.
3) Click "Tax Managers" resp
4) Click "Schedule Request Set" link under "Requests"
5) Select "E-Business US Sales and Use Tax Import Program" from the "Request SetName" LOV
6) In the first stage,
a) Enter "File Location and Name" parameter (directory in which partner datafile has been placed, filename could be *.dat) e.g. "/home/user/zx/TMD2.dat" ,
b) select "2" (for Taxware) or "1" (for Vertex) for the "Tax Content Source" parameter,
c) and select a Tax Regime Code (new or migrated) for "Tax Content Source Tax Regime Code" parameter.
7) Click "Next" twice to submit the request.
8) Check the status of programs
9) After completion, data will be loaded into TCA Geography model and EBTax entities - Tax, Status, Rates, Jurisdictions.

R12 Oracle E-Business Tax Configuration (By Mariluci Pereira - Metalink)
1. Basic Tax Configuration:
Tax Definition: comprises the tax data that you set up for each tax regime and tax that your company or institution is subject to. The Tax Authority designates the regulations and rates that apply to the tax regime.

Required Task List:
a) External Dependencies
1. Create First Party: Legal Entity and Establishments
2. Create Reporting and Collecting Tax Authorities

b) Tax Configuration
1. Create Tax Authorities Party Tax Profiles
2. Create Tax Regimes
3. Create First Party Legal Entity Party Tax Profile
4. Create Tax
5. Create Tax Status
6. Create Tax Jurisdictions
7. Tax Rate

2. Managing Party Tax Profiles:
The configuration tier identifies the factors that participate in determining the tax on an individual transaction. These “taxability” factors are: party, product, place and process.

3. Configuration Owners and Service Providers:
a) Tax Configuration Ownership
b) Tax Configuration Options
c) Configuration for Taxes and Rules
d) Configuration for Product Exceptions
e) Service Subscriptions
f) Legal Entity and Operating Unit Configuration Options
g) Event Classes
h) Configuration Owner Tax Options

4. Fiscal Classifications:
Fiscal classifications provide tax determination values for situations where the party, product, or transactions are factors in tax determination. You set up a fiscal classification type to identify a category of fiscal classification that has a potential tax implication; you assign fiscal classification types to tax regimes and taxation countries. You set up fiscal classification codes under a fiscal classification type to provide additional granularity to a particular fiscal classification category. When creating tax rules, you use fiscal classification types as determining factors and fiscal classification codes as condition set values.

5. Setting Up Tax Rules:
You create tax rules by translating the tax regulations of a tax authority into determining factors and tax conditions that the E-Business Tax tax rules engine uses to evaluate the applicability of a tax on each transaction line. Tax rules determine: the applicability of a tax; the place of supply and tax jurisdiction of the transaction; the tax registration; the tax status and tax rate; the recovery rate (if applicable); and the taxable basis and tax formula to use in calculation.

6. Setting Up Tax Rules – Determining Factors:
Determining factors are the key building blocks of your tax rules. They are the variables that are passed at transaction time or derived from information on the transaction. Determining factors fall into four groups, namely: Party, Product, Place and Process. A determining factor is an attribute that contributes to the outcome of a tax determination process, such as a geographical location (place) or tax registration status (party). Determining factors can be used in tax rules, taxable basis formula, and tax regime determination.

Please read the Metalink whitepaper to get detailed step by step instruction on how to setup each of the above configurations in Oracle Apps.

Reference Notes:
Metalink Doc ID’s = 461084.1, 552390.1, 466575.1, 456310.1

AP Check fraud prevention in Oracle Apps - Payee Match with Positive Pay

2008-04-14T14:59:00.003-04:00

Client and Business Case – A large multinational corporation wanted to implement a very tight check fraud prevention tool while implementing Oracle Payables. This was because of the reason that with today’s technology, it has become much easier for individuals to commit check fraud. The corporation was concerned with the recent increase in check fraud activity perpetrated against itself, hence they needed a more effective fraud-fighting tool within Oracle Apps.

Solution - In order to reduce Client’s susceptibility to check fraud, Payee Match was implemented. Payee Match is a tool used by corporations and financial institutions to match the amount and serial numbers on checks as well as the name of the payee given out in the “Payee Zone” on the check.

Payee Match service works independently of the Positive Pay Service. It matches all the data in the “Payee Zone” on the face of Client’s checks. This service usually works in conjunction with the Positive Pay service.While Positive Pay verifies the amount and the serial numbers of the check Payee Match provides a third line of defense against check fraud by verifying the payee name and address. Payee Match matches a file, sent by the Client, to the checks presented for payment at the bank. The Client will have the choice to pay or reject any non-matched items.

Payee Match generates pay or no pay alerts on the following data elements:
a) Issued date
b) Serial Number
c) Amount
d) Transit Number
e) Bank Identifier
f) Account Number
g) Payee Name
h) Payee Address.

High level Solution Steps:
1. Develop a Custom Positive Payee match Report in Oracle to include all the data elements of Payee Match as per the structure required by the Client.
2. Run the Positive Payee Match Report
3. Format the text file generated by the Positive Payee Match Report as per the format agreed to with the banks.
4. Custom Scheduler Process --FTP the file to the desired location in the server as per the bank’s specification
5. Bank will tabulate and send the results of payments by payee detailing the count for each pay cycle in a text file to the desired location on the FTP Server.
6. Custom Scheduler Process will grab the text file sent by bank from the designated location and sends it to the desired location on the Oracle server.

Detailed User Procedures:
In order to achieve the payee match solution the following steps need to be performed:
1. Development of a custom report on the lines of the standard Positive Payee Match report in Oracle.
2. Run the report and format the resulting text file as per the bank’s format.
3. Custom Scheduler Program will extract the file from the oracle server and FTP it to the FTP server from where the bank can download the same. This will be on a daily basis with at least one pay cycle per day throughout the week beginning from Sunday and ending on Friday.
4. Need to create an image map of Client check stock; anything inside the image map is called the “Payee Zone”. The Payee Zone is read using OCR technology and converted into a text string, with each element being separated by a space. All punctuation and white space is removed from the string. All information contained in the Payee Name Zone of the physical check must be included in the fields “Check Sequence 1” through “Check Sequence 10” in order of appearance on the physical check (top to bottom, left to right.)
5. Once the scanned data is converted to a text string, the matching software combines all of the Check Sequence fields from the Client issued file into a string, and separates each field element with a space. It then compares this string to the scanned data from the check. This comparison identifies any discrepancies that may have been caused by fraudulent activity. If any discrepancies are detected between the two strings, the check is examined manually. If it is determined that the mismatch is not caused by a computer error, then Client is notified of the discrepancy with a pay / no pay decision, via email or fax.

6. The Bank will upload the file with the count of the payments in the particular pay cycle to the FTP server from where the custom scheduler program can retrieve and send it over to the designated location in the Oracle server.

Happy Tamil New Year - My blog registered at blogs.oracle.com

2008-04-12T15:54:00.004-04:00

Happy Tamil New Year everyone !

Very happy to note that my blog has been registered at blogs.oracle.com.

Please keep visiting and any feedback is much appreciated.

Overview of Bank Reconciliation using Oracle Cash Management

2008-04-12T15:34:00.002-04:00

Bank Reconciliation Process - Bank accounts are the assets of the company and must be explained as part of the audit requirements. Bank reconciliation can reveal fraud as well as errors. Reconciliation is the process of explaining the difference between two balances which could be due to legitimate reasons like timing differences.

Bank Reconciliation uses the following formula:
Bank Account Balance in Oracle Financials + Items on Bank Statement, but not in Financials
Items in Financials, but not on Bank Statement = Balance as per Bank Statement

Both types of differences are to be analyzed to determine whether the source of discrepancy was error or a legitimate difference and action initiated accordingly.

Legitimate differences occur due to the following reasons:
1. Timing differences – Check Issued but not presented or Checks Deposited but not cleared.
2. Bank charges and other items unknown till the bank statement is received.
3. Fees for currency conversion
4. Unprocessed Transactions
These differences once identified have to be eliminated by making appropriate accounting entries.

Reconciliation Process:
Bank transactions entered directly into GL or generated from Payables, Receivables or Payroll can be reconciled with CM.
1. Loading the Bank Statement:
The transactions can be reconciled manually or automatically by loading an electronic statement directly into CM. Loading is done using the bank statement open interface where a bank statement in the requisite flat file format is uploaded into CM tables. The automatic reconciliation looks for certain match criteria to determine whether a transaction and a bank statement line are one and the same.

2. Reconciling Journal Entries:
The journal entries entered directly in GL can be reconciled with the bank statement. The Auto reconciliation program matches a journal line description with the bank statement line transaction number.

3. Reconciling Payments:
Supplier payments entered in Payables can be reconciled to the bank statement lines in CM. The payment status against each check is updated as “Reconciled”.

4. Reconciling Receipts:
Receipts created in Receivables can also be reconciled to the bank statement lines in CM. CM updates the status of the receipts to “Reconciled” and creates appropriate accounting entries for transferring to GL. Payables and Receivables can generate reconciliation accounting entries for cash clearing, bank charges and foreign currency gain or loss.

5. Reconciling other Transactions:
Certain transactions like bank charges, interest credits, specific exchange rate applied against foreign currency transactions, customer receipts returned due to bounces etc, are known only when the bank statement is received. These would not have been initiated from Oracle Applications. CM is the primary point of entry for these transactions.

Importing Bank Statements and Validation:
Use CM’s Reconciliation programs to:
•Validate the information in the bank statement open interface tables
•Import the validated bank statement information
•Perform an automatic reconciliation after the import process completes

The AutoReconciliation program performs the following validations on loading bank statement information into the bank statement open interface tables:
•Bank statement header validation
•Control total validation
•Statement line validation
•Multicurrency validation

Reconciling Bank Statements Automatically:
Use AutoReconciliation program to automatically reconcile any bank statement in Oracle CM. There are three versions:
1. AutoReconciliation: Use this program to reconcile any bank statement that has already been entered in CM.
2. Bank Statement Import: Use this program to import an electronic bank statement after loading the bank file with a SQL*Loader script.
3. Bank Statement Import and AutoReconciliation: Use this program to import and reconcile a bank statement in the same run. After the program has been run, review the AutoReconciliation Execution Report to identify any reconciliation errors that need to be corrected and re-run the program again if corrections are done.

Accounting for Refunds within Oracle Payables

2008-04-10T15:03:00.005-04:00

Refund Scenario - A supplier will send a request for a deposit of prepayment to the Accounts Payable group. The following is a basic overview of the standard account suggested by Oracle for the entry of a prepayment with a refund from the supplier.

1. Enter a prepayment invoice to the supplier.

Prepayment Account (default) - DR.
Liability Account - CR.

2. Pay the prepayment invoice to the supplier.

Liability Account - DR.
Cash Clearing Account - CR.

3. Reconcile payment in cash management.

Cash Clearing Account - DR.
Cash Account - CR.

The supplier sends a refund check for ‘some amount’ (XX) of the original prepayment.
___________________________________________________________________________________________

4. The Accounts Payable person enters a ‘dummy’ invoice with invoice number ‘Refund XXXXX’ in the amount of the refund.

Expense Account DR. ******Cash Account workaround.
Liability Account CR.

5. Match the invoice to the original prepayment invoice.

Liability Account DR.
Prepayment Account (default) CR.

___________________________________________________________________________________________
At this point, the refund has never been officially recorded in Payables or in Cash Management. The refund will not show any or Oracle’s standard reports. Oracle’s standard process for recording refunds of prepayments includes an additional step to record the refund in Payables and in Cash Management.

6. The Accounts Payable person enters a ‘dummy’ Debit Memo.

Liability Account DR.
Expense Account CR.

7. The debit memo is ‘paid’ with the entry of the refund check.

Cash Clearing DR.
Liability Account CR.

8. The refund is reconciled through Cash Management

Cash DR.
Cash Clearing CR.
___________________________________________________________________________________________
******The Cash account can be used for logging the payment to the correct GL account. However, there are no provisions to have the refund show up on the AP standard reports or to be cleared through Cash Management.

Retrospective Payroll Processing in Oracle Payroll

2008-04-07T16:55:00.003-04:00

Client and Business Case - A global manufacturing company wanted to automate the retrospective pay calculation in Oracle Payroll for critical payroll processes like retrospective pay awards, temporary promotions, secondments, retro pay for part timers etc.

Solution - Oracle Payroll allows you to make back pay adjustments through the RetroPay process. Key points include:
–Inputs to pay that were originally correct have now changed retroactively.
–You receive late notifications of promotions.
–You can run the RetroPay process from the submit Requests window.

How Retro Pay Works - Oracle Payroll now rolls back and reprocesses all the payrolls for the assignment set from the date you specified. The system compares the old balance values with the new ones and creates entry values for the RetroPay elements based on the difference. These entries are processed for the assignments in the subsequent payroll run for your current period.
No changes are made to your audited payroll data.

Configuration - All payroll elements configured during the implementation are assessed for whether they are “retropay’able” or not. Usually all regular payments and allowances are considered eligible for retropay. Voluntary deductions and some non-recurring payments are not normally eligible but can be made so if required.

For each eligible element a corresponding “Retropay Element” is also configured. These elements will hold the results of any pay adjustments calculated by the “Retropay” process.

A number of Retropay element “Groups” may also be configured. I.e. There will almost certainly be a group which includes all eligible elements but there could be another group which is just for bonus related adjustments. This gives flexibility when running retropay to restrict the process to just those items where you are notified that a change is due.

Operational steps - Immediately prior to every payroll calculation the “Retropay Notifications” report should be run. This lists any system changes that indicate a retrospective adjustment may be due. E.g. One or more employees may have had a late or corrected entry of a new allowance, change of Grade, change of Grade Step placement etc.

Using the “Retropay Notifications” report you can establish the assignments, period and elements for which retrospection is needed.

If a retrospective calculation is needed, then run the standard “Retropay by Element” process.
Input parameters are :-
Assignment set – if you want to restrict the run to selected assignments
Retropay element group – if you want to restrict the run to selected elements
Start date – this is the earliest date you want the system to recalculate from
End date – this is the latest date you want the system to recalculate up to

The process recalculates for the assignments, period and elements indicated. Any resulting adjustments are attributed to each relevant retropay element and entered into the current pay period for processing in the full payroll gross to nett run. In this way the results of the previous period(s) payrolls are not amended. The adjustments will only affect values and be costed in the current payroll period.

How the notification process works - During the implementation “Dynamic Triggers” will be configured. These identify when a change has occurred in the database which could mean an adjustment to pay is needed. E.g. There will be dynamic triggers to detect changes in Grade, Spinal Point, Standard Hours, Contract Type, FTE, Allowances etc. The “Retrospective Notifications” process uses these triggers to notify you of the items which need retrospective calculation.

How the calculation process works - Assume a retropay run is for March and April with the adjustments to be paid in May. The system retrieves all balances for the assignment as at end of February payroll and notionally recalculates all eligible elements for March and April. These notional element results are compared by the system with the original actual results in March and April for the same elements. Any differences are automatically entered onto the relevant retropay element in May. The end result will be exactly the same as if a payroll clerk had manually calculated the adjustments needed and manually keyed them onto adjustment elements in the current pay period.

Optimising use of the Retropay functionality - It can be seen that as the exact same system process is used to recalculate as was used in the original payroll calculation, then elements which have derived values will automatically be correctly recalculated by the retropay process.

e.g.
Allowance X has a formula attached which specifies that the allowance value is 10% of basic salary plus 2% of all contractual allowances. If basic salary and all contractual allowances are part of the retropay set then Allowance X will also be recalculated.

If the allowance has no formula and is populated by a user keying in an arbitrary amount then it will not be affected by retropay on other elements. The only way this would generate a retropay adjustment would be if the original allowance entry were changed, i.e. different start/end date or value.

During the implementation, due consideration should be given to how elements are configured to enable maximum use of the retropay functionality.

Pay Awards - When revising the values on a pay scale due to a pay award it will be essential to datetrack to the correct effective date when the new values come/came into force. You can apply the pay award in advance of the effective date or after it. If it is applied late then restrospective calculations will be due and the operational steps outlined above will need to be followed. If you have applied the pay award in advance then the old rates will be applied until the effective date of the pay award when the new rates will automatically be applied. If this occurs mid-period then the calculated values will be pro-rated accordingly.

Temporary Promotions, Secondments etc. - Any employee who is in a role which is not their usual substantive assignment will still be eligible for retropay adjustments on their substantive assignment for the period before their Temporary Promotion or Secondment started, and also on their extra assignment for the Promotion or Secondment.

Part Timers - It can be seen that as the exact same system process is used to recalculate as was used in the original payroll calculation, then elements which are pro-rated according to a part-timers FTE will still be pro-rated in exactly the same way.

Overlapping Retrospective Runs - It is possible that having run Retropay in June to recalculate March-May, you then have reason to run it in September for April-August. This is perfectly legitimate and the system will correctly process the second retropay run which overlaps the time period covered by the first run.

Implementing Oracle GCS (Part 2)

2008-04-06T08:45:00.005-04:00

Client and Business Case - Global Manufacturing client wanted to implement GCS in Oracle GL to enable consolidation within Oracle. The steps involved in configuring GCS are detailed in the following sections.

I. DEFINE SETS OF BOOKS (SOB):
1. Where all subsidiaries share a single SOB which consists of the same COA, accounting calendar, and currency, it is purely a reporting kind of consolidation requiring FSG tool. No separate consolidation SOB is required
2. Where each subsidiary and the parent company require their own SOB meet their operational or local accounting needs:-
2.1 If Parent SOB can be touched, then data transfer can take place to the Parent SOB.
2.2 Else, a separate consolidation SOB is required where data transfer has to take place.
3. Where companies use non-Oracle Applications, Create dummy SOBs within the GCS parent’s database instance. Each of these SOBs represent the subsidiary SOBs on disparate application instances. The consolidation can happen to Parent SOB or a separate consolidation SOB.

II. GATHER DATA FROM DISPARATE INSTANCES OR NON–ORACLE GL SYSTEMS:
GCS provides a convenient interface to import subsidiary data from any external source,
such as a separate database instance of Oracle GL, or an entirely separate non–Oracle
accounting system. There are two options available for gathering data from diverse sources:
1. Applications Desktop Integrator (ADI) to work in a spreadsheet environment. Simply transfer the subsidiary information from the external system into ADI’s journal worksheet. Then upload the entries to the GCS system where it can be posted.
2. SQL Loader to load data from diverse sources into the GCS open interface.

III. MAP SUBSIDIARIES TO PARENT:
To consolidate multiple SOB that have different functional currencies, accounting calendars,
or charts of accounts, first map subsidiaries’ COA to parent’s COA. A consolidation mapping is a set of instructions for mapping accounts or entire account segments from a subsidiary SOB to the parent SOB. When one subsequently transfers amounts from a subsidiary to parent, GL creates an unposted consolidation journal batch in parent SOB based on the subsidiary’s mapping information.

IV. PREPARE YOUR SUBSIDIARY DATA:
Prepare subsidiary data by revaluing and translating balances before transferring the balances to parent.
1. Revalue Balances - If any subsidiary SOB has balance sheet accounts that are denominated in a foreign currency, revalue the balances to reflect the impact of any changes in exchange rates. Post the resulting revaluation journal.
2. Translate Balances - If any subsidiary SOB uses a functional currency different from parent, translate the account balances into the parent SOBs’ functional currency before transferring the subsidiary data to parent.
3. Multiple Reporting Currencies (MRC) - If MRC is used, then consolidate directly from subsidiary’s reporting SOB to parent SOB. Revaluation needs to be run on the primary and reporting SOB before consolidation. The primary issue to consider when deciding whether to consolidate directly from a subsidiary’s reporting SOB is: What accounting rules govern the parent’s and subsidiary’s business environments?

V. TRANSFER DATA:
1. Transfer the balances or transactions to be consolidated from subsidiary SOB to parent.
2. GL accumulates subsidiary information based on the mapping rules defined, then populates the GL_INTERFACE table with the consolidation data.
3. Journal Import must be run, to create an unposted consolidation journal batch in parent SOB.
4. One can initiate a subsidiary–to–parent transfer from the subsidiary or from the parent SOB.
5. One can transfer balances (Actual / Budget) or transactions (Actual only).

VI. POST CONSOLIDATED DATA:
Once the subsidiary data has been transferred to parent SOB, one needs to combine the subsidiary and parent data. This involves several steps:
• Run Journal Import if it was not chosen as one of consolidation run options.
• Review the unposted journal batch created by the transfer and subsequent Journal Import.
• Post the consolidation journal in parent SOB.

VII. ELIMINATE BALANCES:
The Oracle GL Automatic Intercompany Eliminations program eliminates intercompany balances. Create an elimination set which is a batch of one or more elimination journal entries.
1. Full Eliminations: Elimination sets can optionally use an elimination company to fully eliminate a group of intercompany elimination entries for a set of subsidiaries.
2. If your elimination journals are out of balance, you can specify balancing options to either allow out of balance journals to be created or to post the net difference to an alternative account. In addition, threshold rules can be applied to prevent the creation of elimination journals if the net difference exceeds a specific amount, a percentage of a particular account, or a percentage of the total journal.
3. You generate the elimination set every period to automatically create the elimination journal entries. You have the option of automatically posting the journal or wait till you review it.
4. You can also use the Consolidation Workbench to track the elimination status of your elimination sets and post any generated elimination sets.
5. Formula–Based Eliminations: If you have formula–based elimination entries or you want to eliminate average balances, use Oracle GL’s recurring journals feature.
6. The Automatic Intercompany Eliminations program automatically generates eliminating entries per the rules specified.

VIII. REPORT:
Use the FSG as the mechanism to sum up the subsidiaries to produce consolidated results in case of Single SOB. In case of companies having multiple SOB / non-Oracle Application, use FSG to report on consolidated results. Use the ADI to extend reporting to the spreadsheet environment. ADI allows to create and publish consolidated reports in HTML format to the Internet or corporate intranet.

IX. ANALYZE:
1. Use full drilldown capabilities to drill from consolidated balances down to subsidiary journal lines and subledger detail. GCS enables to drill from consolidated balances in the parent SOB directly to the subsidiary SOB within the same instance. In case of companies having disparate applications, one cannot drilldown to the subledger detail.
2. Directly link data to Oracle Financial Analyzer, an online analytical processing (OLAP) application, to analyze consolidated balance and prepare operational and financial analyses for your management team. One can also drill between a subsidiary’s translated balance to its original balance. GCS also provides you with the ability to drill between summary accounts, detail accounts, and the original journal entries, down to The subledger detail.

Posting Payroll Costs to General Ledger

2008-04-05T14:12:00.012-04:00

Client and Business Case - A Banking Client who had implemented a full installation of HR (including payroll processing) wanted to configure the system such that the payroll costs are posted periodically to the General Ledger.

High Level Solution - There is a Key FlexField (KFF) in Oracle Payroll called “Cost Allocation Flexfield”. Like any other KFF it must be setup to contain segments that together represent the full analysis code to be used in posting payroll costs to General Ledger (GL).

This KFF also uses Qualifiers to determine where each segment is made accessible to the user.

There are 5 different places in the standard Oracle HRMS application where Costing information can be configured by the user. This is true for any Oracle HRMS customer.

The 5 places are :-

1. Payroll – Each active payroll must have segments setup for Costing and Suspense. This is normally maintained by technical Payroll Sysadmin staff.

Navigation = HR Responsibility > Payroll > Description:

2. Element Link – All Elements which pay/deduct money must have at least one link created. The number of links for each element and their complexity is dependent on how Finance requires the postings in GL. Each link has 2 costing flexfields, one for the Debit and one for the Credit entry in GL. Each of these 2 records may need one or more of the Cost Allocation KFF segments populated. This is normally maintained by technical Payroll Sysadmin staff.

Navigation = HR Responsibility > Total Compensation > Basic > Link:

3. Organization – Each Organization may have a single costing record populated with one or more segments. This works most effectively where each HR Org can be directly related to a particular GL Cost Centre. This is normally maintained by HR Sysadmin staff.

Navigation = HR Responsibility >Work Structures > Organization> Description:

4. Employee Assignment – Each Employee Assignment may have multiple costing records populated with one or more segments. This is where split % costing’s applied. This is normally maintained by HR Operational staff.

Navigation = HR Responsibility >People> Enter and Maintain > Assignment > Salary Information > Others > Costing:

5. Employee Assignment Element Entry (sometimes called Element Entry Overrides) – Each element entry may have a single costing record populated with one or more segments. e.g. Time entries from Timesheets. This is normally entered by Payroll Operational staff.

Navigation = HR Responsibility >People> Enter and Maintain > Assignment > Salary Information > Entries:

6. Final Setup
There is one final setup step to map the CostAllocation Flexfield segments to the corresponding segments in the GL Chart of Accounts KFF.

High Level Costing Process:

There are two report processes available.
1. Cost Breakdown Report for Costing Run
2. Cost Breakdown Report for Date Range
These reports simply select a set of payroll calculation results according to run parameters and report on them.

There is one process for collecting Payroll costs.
3. Costing - This process collects a set of payroll calculation results, attributes them to the full GL analysis code and creates an output file in the correct format for posting to GL. The file can be viewed via the normal view process results function.

There is one process for transferring the costs.
4. Transfer to GL - This process takes the results file and moves it to a designated area on the file server from where it can be uploaded to GL under the control of an authorised GL user.

There is one process for retrospective costing adjustments.
5. RetroCosting Process - This process recalculates costs and compares the results with the original costing process results to identify and differences.

Understanding Mass Additions

2008-04-05T11:22:00.004-04:00

Client and Business Case - One of my clients (Oil and Gas - Retail) who implemented Oracle Assets needed a simpler way to:
1. Convert Fixed Assets data from legacy system for Go-Live
2. Add new assets or cost adjustments from other (Oracle or Non Oracle) systems to the Oracle Assets system automatically without reentering the data

Mass Additions - The Mass Additions process lets you:
1. Load (convert) assets automatically from an external source. You can review new mass addition lines created from external sources before posting them to Oracle Assets. You can also delete unwanted mass addition lines to clean up the system.
2. You can also load (convert) asset data into Oracle Assets using the Create Assets Feature in the Applications Desktop Integrator (ADI), which allows you to import data from an Excel spreadsheet.
3. Maintian Assets data - The mass additions process lets you periodically add new assets or cost adjustments from other systems (like Oracle AP, Oracle Projects ) to your Asset system automatically without reentering the data.

Mass Additions Features:

1. Review Mass Additions - Clients can review newly created mass addition lines for entering additional mass addition source, descriptive, and depreciation information, assign the mass addition to one or more distributions, or change existing distributions. Once the mass addition is ready to become an asset, change the queue to POST. On Posting Mass to FA this mass addition becomes an asset. The Mass Additions post program defaults depreciation rules from the asset category, book, and date placed in service which can be overridden

2. Add to Existing Asset - Clients can add a mass addition line to an existing asset as a cost adjustment. Choose whether to change the category and description of the existing asset
to those of the mass addition and whether to amortize or expense the cost adjustment. When one changes the queue name to POST for a mass addition line which is being added to an existing asset, the queue name is changed to COST ADJUSTMENT. This makes it easy to differentiate between adding a new asset or adjusting an existing asset.

3. Merge Mass Additions - Clients can merge separate mass addition lines into a single mass addition line with a single cost. The mass addition line becomes a single asset when one
Posts Mass Additions. One can only merge mass additions in the NEW, ON HOLD, or user–defined hold queues. Choose whether to sum the number of units. When one posts the merged line, the asset cost is the total merged cost.

4. Split Mass Additions - Clients can split a mass addition line with multiple units into several single unit lines. The original line is put in the SPLIT queue as an audit trail of the split. The resulting split mass additions appear with one unit each, and with the same existing information from the source system. Each split child is now in the ON HOLD queue which can be reviewed to become a separate asset.

5. Post Mass Additions to FA - Use the Post Mass Additions to FA program to create assets from mass addition lines in the POST queue using the data entered in the Mass Additions window. It also adds mass additions in the COST ADJUSTMENT queue to existing assets.

6. Clean Up Mass Additions -The Delete Mass Additions program removes mass addition lines in the following queues:
• Mass additions in the SPLIT queue for which child mass addition lines created by the split has already been posted.
• Mass additions in the POSTED queue that have already become assets
• Mass additions in the DELETE queue.

7. Create Mass Additions from Invoice Distributions in Payables - Mass Additions adds assets and cost adjustments directly into FA from invoice information in Payables. The Create Mass Additions for Oracle Assets process sends valid invoice line distributions and associated discounts from Payables to an interface table in FA. One reviews them in and determines whether to create assets from the lines.

Pre-requisites steps for seemless Mass Additions Process:

1. Register the Accounts - Account Type Must Be Asset: Register the clearing accounts to be used as Asset accounts. The create mass additions process selects Payables invoice line distributions charged to clearing accounts with the type of Asset.
Define Valid Clearing Accounts in FA: For each asset category in FA for which invoice line distributions are to be imported from Payables, define valid asset clearing and construction–in–process clearing accounts. These accounts must be of type Asset. The create mass additions
process only imports lines charged to accounts that are already set up in asset categories.

2. Define Items with Asset Categories - Clients can define a default asset category for an item in Purchasing or Inventory. Then when one purchases and pays for one of these items using
Purchasing and Payables, the mass additions process defaults this asset category. If mass addition lines for an item are to appear in FA with an asset category, Cleints must:
• Define a default asset category for an item in the Item window in Purchasing or Inventory
• Create a purchase order for that item
• Receive the item in either Purchasing or Inventory
• Enter an invoice in Payables and match it to the outstanding purchase order
• Approve the invoice and Post the invoice to GL
After cleint runs create mass additions, the mass addition line appears with the asset category specified for the item.

3. Enter Invoices in Payables - While entering a new invoice in AP, charge the distribution to a clearing account that is already assigned to an asset category. The line amount can be either positive or negative.

4. Units - If one enters a PO with multiple units and match it completely to an invoice in payables, the Create Mass Additions process uses the number of units specified by the original PO for the mass addition line. Mass addition lines created from invoices entered directly into AP without matching to a PO default to one unit. After one approves and posts the invoice in AP, run the Create Mass Additions process to send valid invoice line distributions to FA.

5. Handle Returns: Clients can easily process and track returns using mass additions.

6. Conditions For Asset / Expensed Invoice Line Distributions To Be Imported - For the mass additions create process to import an invoice line distribution to FA, these specific conditions must be met:
• The line is charged to an account set up as an Asset account. (Expense in case of expense asset)
• The account is set up for an existing asset category as either the asset clearing account or the CIP clearing account
• The Track As Asset check box is checked. (It is automatically checked if the account is an Asset account)
• The invoice is approved and The invoice line distribution is posted to Oracle GL from AP
• The GL date on the invoice line distribution is on or before the date specified for the create program
• AP must be tied to the same GL SOB as the corporate book for which one want to create mass additions

7. Running the Create Mass Additions For FA Program in Payables - Clients can run Create Mass Additions for FA as many times as during a period. Each time it sends potential asset invoice line distributions to FA. AP ensures that it does not bring over the same line twice.

Consolidation in Oracle GL (Part 1)

2008-04-03T19:07:00.004-04:00

Client Profile - Global clients who want to implement Consolidation functionality within Oracle GL. Other consolidation methods include Financial Consolidation Hub (FCH) and use of Hyperion cubes to generate Consolidated reports.

Consolidation - is the period–end process of combining the financial results of separate subsidiaries with the parent company to form a single, combined statement of financial results. Clients can consolidate any number of subsidiaries that use different SOBs and having different COA, currencies and calendars.

GL Consolidation Tools - There are basically two consolidation tools which can be used for consolidation within Oracle GL.
1. Financials Statement Generator (FSG) - Used for consolidating financial information for businesses using a single SOB or using different SOB that share the same calendar and COA.
2. Global Consolidation System (GCS) - GCS is a multi-source consolidation solution that can accumulate information from diverse financial systems, geographic locations, including Oracle and non-Oracle Applications. With GCS one can consolidate data from multiple SOBs, multiple instances and non-Oracle applications.

What Can Be Consolidated? - With GCS, one can consolidate any business dimension at any level of detail from any point of view:
1. Any Source: Data from any source system, including ledger, databases, or other accounting systems can be consolidated
2. Any Chart of Accounts: Subsidiaries can use separate COA from the parent to address unique operational accounting practices and meet local statutory requirements. GCS enables you to consolidate across diverse charts of accounts.
3. Any Calendar: Subsidiaries can use different accounting calendars from the parent. GCS enables you to consolidate across calendars.
4. Any Currency: Subsidiaries can use a functional currency which differs from the functional currency of the parent. GCS revalues and translates all subsidiary balances to ensure consistent consolidated results.
5. Any Level of Detail: Consolidate detail transactions, detail balances and summary balances.
6. Any Balance Type: Consolidate any balance type; including actual, average, translated, budget, and statistical balances.

Implementation Considerations -
•Do all subsidiaries share the same SOB? If yes, then FSG can be used to meet the requirement.
•Do all subsidiaries have different SOB? If yes, then:
They share the same COA and calendar – Use FSG
They reside in the same instance – Use FSG
•Do all lines of business use GL as their operational accounting system?
•Is a separate consolidation SOB required to keep consolidation data separate from transactional data or can the companies be consolidated in the parent SOB?
•Is a separate elimination company required to segregate eliminations or can it happen in the parent company?
•Are companies to be consolidated at Balance level or Transaction level?

Other Uses of GCS:
1. Changing Chart of Accounts (COA) after implementation. GCS can be use to map values from old COA to new COA and balances from old SOB can be transferred to new set of books.
2. Changing the Accounting Calendar after implementation. GCS can be used to map and transfer account balances from the old period to the new period.

In my next article, I will explain in detail the various steps involved in setting up GCS in Oracle GL.

Oracle Fixed Assets - Quick Module Overview

2008-03-31T22:36:00.003-04:00

Introduction:
Oracle Fixed Assets is fully integrated with other modules so that data input in Purchasing, Payables and Projects will flow through Fixed Assets into the General Ledger. This also means that any asset can be queried and the source information obtained by drilling down to find details of invoices. You can perform most of your transactions in Oracle Assets using just three windows: the Assets Workbench, Mass Additions Workbench, and Tax Workbench.

Additions:
The majority of assets should come via the Purchasing, Payables / Project modules using the Mass Additions / Interface Supplier Costs process. There may be a few occasions when manual additions are required. Ordinary assets can be quickly entered using Quick Additions. Detailed Additions can be used to handle more complex assets as follows:

· Assets with a salvage value.
· Assets with more than one assignment.
· Assets with more than one source line.
· Assets that Category defaults do not apply.
· Subcomponents Assets.
· Leased assets and Leasehold Improvements.

Depreciation:
Default depreciation rates can be set up for each asset category and also can be overridden in special cases. Before running depreciation you can change any field but after running depreciation you can only change asset cost and depreciation rate. You then can choose whether to amortize the adjustment or expense it.

Retirement:
You can retire an entire asset or you can partially retire an asset. You can also use Mass Retirements to retire a group of assets at one time.

Tax Book Maintenance:
Oracle Assets allows you to copy your assets and transactions from your corporate book to your tax books automatically using Initial / Periodic Mass Copy. You can create as many tax books as you need, maintain your asset information in your corporate book, and then update your tax books with assets and transactions from your corporate book.

Prepaid Services:
To record warranty and maintenance information into Oracle Assets, a purchase order must be created and the data input will flow into Payables with the proper prepaid account. Prepaid accounts are maintained in the general ledger and amortized over the period of coverage; however, the accounts charged are based on the designated account(s) for the prepaid services. The charges into the Fixed Assets account and asset category is based on the monthly charges from the monthly amortization of the prepaid services.

Capitalized Leases vs. Operating Leases:
Oracle Assets allows you to test leased assets in accordance with generally accepted accounting principles to determine whether to capitalize and depreciate your leased assets. Lease Capitalization Test: (1) the ownership of the asset transfers to the lessee at the end of the lease (2) a bargain purchase option exists (3) the term of the lease is more than 75% of the economic life of the leased asset (4) the present value of the minimum lease payment exceeds 90% of the fair market value of the asset at lease inception.

Regarding Operating leases, Fixed Assets tracks your payments under operating leases, or leases that do not meet any of the criteria, for informational purposes. You can use this information to create a schedule of future minimum payments under operating leases, information that may require disclosure in the footnotes of your financial statements.

Period-End Process:
The key components of the Period-End Process are:
· Ensure All Assets have been Properly Assigned.
· Copy New Assets Entries into Tax Books.
· Run Depreciation for the Corporate Book.
· Create Journal Entries.
· Post Journal Entries to the General Ledger.

Oracle Fixed Assets - Requirements Analysis Questionnaire

2008-03-31T22:09:00.002-04:00

Fixed Assets - Commonly asked Requirements Analysis Questions:

1. Do you need to track locations other than State, City, and Country for your assets? If yes, please provide alternate location values.

2. What is the Oldest Date of an asset that is Placed in Service?

3. How many assets are presently live in your system? How many are added each month?

4. Do you track tax amounts separately for federal, state, AMT, ACE etc.?

5. Please list any Prorate Conventions you use:

Common examples: Mid-month, Date in Service, Following Month

6. Please list current Asset Category information

7. What is your policy for capitalization?

8. At what point is a purchase known to be an asset? (PO, Invoice entry, later?)

9. How many locations are used and where are they located? Are any outside of USA?

10. What are your currently used depreciation methods?

11. With respect to cost centers (departments), how do you plan on tracking assets? How do you handle asset transfers?

12. How do you account for obsolete/damaged assets? What is the write-off policy?

13. Describe how assets are to be tracked and managed.

14. When are asset tags applied?

How to create Custom Address Styles in Oracle Apps

2008-03-27T14:48:00.014-04:00

Client – Clients who are having Global Rollouts and need for multiple address styles.

Business Case – Need to add country specific address style formats for addresses information which are stored in the different core modules of Oracle Apps including Receivables (for Customer and Remit to Addresses), Payables (Supplier and Payment Addresses), Banks (Bank Branch addresses)

Out of the box address styles - Oracle Applications provides one default and five predefined address styles. These address styles cover the basic entry requirements of many countries. The different address styles provided out of the box are:
• Default,
• Japanese,
• Northern European and Southern European,
• South American,
• United Kingdom/Asia/Australasia,
• United States

How to add a new Address Style -

Let us say the client has a Business requirement to add a new address style for ‘Canada’. The following high level steps can be followed to define this new ‘Canada’ address style.

1. Choose address style database columns for your ‘Canada’ address style.

First you need to decide (as per client’s requirements) which columns from the database you are going to use and how you are going to order them. All the seeded address styles include the following database columns and some additional columns.

• Bank Addresses
• AP_BANK_BRANCHES.ADDRESS_LINE1
• AP_BANK_BRANCHES.CITY
• AP_BANK_BRANCHES.STATE
• AP_BANK_BRANCHES.ZIP

• Customer and Remit-To Addresses
• HZ_LOCATIONS.ADDRESS1
• HZ_LOCATIONS.CITY
• HZ_LOCATIONS.POSTAL_CODE
• HZ_LOCATIONS.STATE

• Supplier Addresses
• PO_VENDOR_SITES.ADDRESS_LINE1
• PO_VENDOR_SITES.CITY
• PO_VENDOR_SITES.STATE
• PO_VENDOR_SITES.ZIP

• Payment Addresses
• AP_CHECKS.ADDRESS_LINE1
• AP_CHECKS.CITY
• AP_CHECKS.STATE
• AP_CHECKS.ZIP

For example, in the Japanese address style, the address element called Province maps onto the STATE database column and that in the United Kingdom/Africa/Australasia address style the address element called County also maps onto the STATE database column. Oracle recommends that all custom address styles also include at least the above database columns because these address columns are used extensively throughout Oracle for printing and displaying.
Note: Most reports do not display the PROVINCE, COUNTY, or ADDRESS4/ADDRESS_LINE4 database columns for addresses.

The following screenshot gives you an idea of how to setup database columns for your ‘Canada’ address style:

2. Define ’Canada’ address style to database columns using Define Descriptive Flexfield Segments Window.

Next step is to create a new context value for each of the descriptive flexfields.

Payables – Bank Address:

Payables – Site Address:

Receivables – Address:

Receivables - Remit Address Information:

3. Add address style to the address style lookup:

Add the ‘Canada’ address style name to the Address Style Special lookup so that you will be able to assign the style to countries and territories.

To add a new style to the address style lookup:
A. Using the Application Developer responsibility, navigate to Applications > Lookups > Application Object Library.
B. Query the ADDRESS_STYLE lookup.
Receivables displays all of the address styles used by Flexible Addresses.
C. Add your new ‘Canada’ address style, as follows:

D. Enable this style by checking the Enabled check box.

4. Assign the address style to the appropriate country using the Countries and Territories window.

· Using Receivable or Payables Superuser responsibility navigate to Setup > System > Countries. · Query for Country = ‘Canada’
· Attach the ‘Canada’ Address Style created to the Canada Country
· Save the record

5. This completes the setup for the new ‘Canada’ address style, now you can use this new address style while adding new Canada Customers, Suppliers etc. See screenshot below on how the Customer Form displays the new ‘Canada’ address style:

Click on the Address filed and you will get a popup window with the new ‘Canada’ address style:

Designing Simple Forms Personalizations for Functional Consultants

2008-03-23T14:45:00.014-04:00

Forms Personalization: I kept reading about this amazingly new feature called 'Forms Personalization' but what really bothered me was almost all the articles / whitepapers had the targeted audience as ‘Admin / Developer’ who have some ‘knowledge of Oracle Developer, PL/SQL, Coding Standards and API’s’.

This really caught my attention and I spent about 2 hours trying to figure out what can a Functional Consultant like myself get out of this new feature. Good news is that you don’t need to have any technical knowledge to design some simple personalizations. So in this article, I have tried to explore some easy to design personalization’s which the Functional Consultants can easily build and test.

Why personalization’s are handy – Since Oracle Apps is a pre-built product, most of the clients would like to remove/ rename, change default values of some of the fields, buttons, tabs etc. Traditional method of getting all the above ‘extensions’ done was to ‘customize’ the form (by customizing the custom.pll) which was generally protected during upgrades / patching. Luckily most changes traditionally done using cutom.pll can be accomplished using Forms Personalization.

Functional Folks - How to quickly get started – The ‘personalize’ menu can be found at Help -> Diagnostics -> Custom Code -> Personalize. To prevent unauthorized users from changing the look and behavior of forms, please use the following profile options:
Utilities: Diagnostics = Yes / No
Hide Diagnostics = Yes / No

Four sections to define a Personalization – There are four sections in the define forms personalization form:
Rules Header – This is where you enter the rules and rule descriptions in plain English. You can sequence these rules using a number and enable/ disable any one rule by using the Enabled checkbox.
Conditions – Consists of Trigger Event: the event within the form that causes invocation of the rule, Trigger object: the context for the trigger event, such as a
particular block or item, Condition: an optional SQL fragment that, when it evaluates to TRUE, allows the rule to execute.
Context or Scope - The Scope is evaluated based on the current runtime context to determine if a Rule should be processed or not. The Scope can be at the Site, Responsibility, User, or Industry level. Each Rule can have one or more Scopes associated with it.
Actions – Determines what the personalization does when the condition and context are true. Various types of actions available include ‘Property’, ‘Message’, Builtin’ or a ‘Special’. Based on the type, additional definition

Real world examples you can try – One of my banking client wanted the Journal Enter form to be customized for the following business rules:

1. Change the ‘Journal’ prompt to display ‘Voucher’
2. Journal description should always be in UPPER CASE
3. Do not display the Budget field, as budgets were not implemented
4. Note to display warning to change Period for prior period Journals.

The following screenshots explain how these four business requirements were implemented using Forms Personalization:

1. Change the ‘Journal’ prompt to display ‘Voucher’:

2. Journal description should always be in UPPER CASE:

3. Do not display the Budget field, as budgets were not implemented:

4. Note to display warning to change Period for prior period Journals:

Journal Entry Form after Personalizations:

When opening the form, the following note gets displayed:

Journal Entry Form after Personalization (Note - Voucher, Budget not displayed and Description in Upper Case:

General Ledger Implementation Considerations - Sets of Books (Ledger for 12i) and Chart of Accounts

2008-03-20T14:42:00.002-04:00

Set of Books (Ledger for 12i):
Set of books determines the functional Currency, Chart of account structure, and accounting Calendar for each company or group of companies, which are known as the 3 C's.

You need to create and set up one or more sets of books. The number of books you set up depend on various factors, such as:
Ø Whether you have multiple subsidiaries using different calendars, charts of accounts, and currencies requiring multiple sets of books
Ø Whether you have multiple subsidiaries that share the same calendar, chart of accounts, and currencies that allow them to share the same set of books
Ø Your organizational requirements or government reporting requirements.

General Ledger provides you with the flexibility to manage your financial information within any company structure. One can maintain multiple companies with similar or different accounting structures, and consolidate their results for meaningful financial reporting.

Chart of Accounts:
Chart of accounts uses Key Flexfield (Accounting Flexfield) that, comprises of Segments, Value sets, Values and Code Combination ID.

Defining the Chart of accounts:
Planning the Chart of accounts structure is the most important activity involving the structure, segments, segment validation and additional features. Analyze the organizational structure and the dimensions of the business before designing the Chart of accounts. By carefully evaluating the business needs, design the chart of accounts to take advantage of General Ledger’s flexible tools for recording and reporting the accounting information.

The account structure can comprise 30 segments with a maximum character length of 275 for the entire String. Each string of multiple-segments is called a code combination and stores a code combination ID based on which balances are maintained in GL. An accounting chart normally consists of Company code, Line of Business, Cost center, Natural Account, Intercompany and Future.

How to define Key Flexfield Structures like Chart of Accounts:
Ø Define descriptive information and validation information for each segment.
Ø Determine the appearance of your key flexfield window, the number and order of the segments, and the segment descriptions and default values.
Ø Freeze flexfield definition and save the changes once set up or when the structures/segments are modified. On saving, Flexfield compiles automatically to improve on–line performance.
Ø Compile the flexfield every time when the changes are made to this form, including enabling or disabling cross–validation rules and when the changes are made to the shorthand aliases window.
Ø Oracle Applications submits one or two Concurrent requests to generate database views of the flexfield combinations table.
Ø The flexfield changes immediately after freezing and recompiling. However, the changes affect other users only after they change responsibilities or exit the application and sign back on.

Determine the Chart of Accounts Structure That Best Suits Your Organization:
Ø Examine the organization structure to identify how performance and profitability are normally measured
Ø Also multiple organizational structures may be needed to allow views of the organization from multiple perspectives. Summary accounts can be used to roll up details.
Ø Visualize each segment of the account as a unit dimension of the business. Combine units that are based on similar dimensions to avoid using multiple segments that measure the same dimension.
Ø Identify the functions, products, programs, funding sources, regions, or any other business dimensions that are to be tracked
Ø Determine the reporting needs.

Consider the following questions before defining the COA structure:
Ø What information will better help one to manage one’s organization?
Ø What are the different ways in which one can look at one’s operations?
Ø What kinds of reports do managers ask for?
Ø What reports one prepares now with some difficulty?
Ø What reports are provided by other financial information systems?
Ø What statistical reporting does one want to perform?
Ø Is project reporting needed?
Ø At what levels of detail does one produce reports?

To Determine Your COA Segment Needs:
Ø Determine the segment that captures the natural account, such as assets, liabilities, expenses, and so on.
Ø Define a separate Accounting Flexfield segment for each dimension of your organization on which you want to report, such as regions, products, services, programs, and projects.
Ø Group similar business dimensions into one segment. This allows a more simplified and flexible account structure For example, you only need one segment to record and report on both districts and regions. Because regions are simply groups of districts, you can easily create regions within your district segment by defining a parent for each region with the relevant districts as children. Use these parents when defining summary accounts to maintain account balances and reporting hierarchies to perform regional reporting.

Flexfield Concepts

2008-03-20T14:06:00.001-04:00

Flexfield in Oracle Apps - Oracle Apps forms and reports are designed to be flexible and to accommodate many kinds of business rules for a wide variety of situations. Along with the innumerable predetermined fields that appear on each screen, most screens can accommodate the entry of additional information through the use of flexfields.

Types of Oracle Apps Flexfields:

1. Key Flexfield:
1.1 Most organizations use ”codes” made up of meaningful segments (intelligent keys) to identify general ledger accounts, part numbers, and other business entities. Each segment of the code can represent a characteristic of the entity. Oracle Applications store these ”codes” in key flexfields.
1.2 Key flexfields are flexible enough to let any organization use the code scheme they want, without programming. One has to decide what each segment means, what values each segment can have, and what the segment values mean. An organization can define rules to specify which segment values can be combined to make a valid complete code (also called a combination). One can also define relationships among the segments.
1.3 Key flexfields are dynamic in the sense that they are used throughout the Applications to uniquely identify information - GL accounts, inventory items etc, that every business needs to keep track of.

2. Descriptive Flexfield:
2.1 Descriptive Flexfields (DFFs) enable to capture additional pieces of information from transactions entered into Oracle Applications. Descriptive flexfields provide customisable ”expansion space” on your forms.
2.2 One can use descriptive flexfields to track additional information, important and unique to your business that would not otherwise be captured by the form.
2.3 Each field or segment in a descriptive flexfield has a prompt, just like ordinary fields, and can have a set of valid values.
2.4 An organization can define dependencies among the segments or customize a descriptive flexfield.

Flexfield Concepts:

1. Segment:
@ A single sub–field within a flexfield.
@ Represented in the database as a single table column.
@ Usually describes a particular characteristic of the entity identified by the flexfield
@ Determines the structure of the Key flexfield (say chart of accounts).
@ Each segment requires a value set to be defined and assigned.
@ One has to be very clear on how many segments are required, their order and validation.

These decisions affect the definition of value sets and their values.

2.Value, Validation (Validate), Value set:
@ Oracle Application Object Library uses values, value sets and validation tables as important components of key flexfields, descriptive flexfields, and Standard Request Submission. The end user enters a segment value into a segment while using an application.
@ Generally, the flexfield validates each segment against a set of valid values (a ”value set”) that are usually predefined. One can share value sets among segments in different flexfields, segments in different structures of the same flexfield, and even segments within the same flexfield structure. Value sets can be shared across key and descriptive flexfields.

Because the conditions one specifies for the value sets determine what values to be used with them, both the values and the value sets should be planned at the same time.

3. Structure:
A flexfield structure is a specific configuration of segments. If you add or remove segments,
or rearrange the order of segments in a flexfield, you get a different structure. You can
define multiple segment structures for the same flexfield (if that flexfield has been built to
support more than one structure).

Difference, Advantages and Disadvantages between Inter-Project Billing and Inter Company Billing

2008-03-19T22:17:00.001-04:00

Intercompany Setups and Sample Transaction Processing using Oracle Projects

2008-03-19T11:27:00.001-04:00

Client Industry – Professional Services Firm implementing Oracle Project Accounting which has Global Operations.

Business Case – Canadian employee travels to US to work on a US project. Canadian employee needs to bill time and expenses for the US Project and the US Project Manager has to pay the Canadian office for the Canadian employees work on the US project.

Setups to support Intercompany Billing:
The setup steps are divided into the following phases:
Global Setup:
• Define transfer price rules
• Define transfer price schedules
• Define additional expenditure types, agreement types, billing cycles, invoice formats, and supplier types
• Define an internal supplier
• Define an internal customer
Operating Unit Setup:
• Define supplier sites for the internal supplier (receiver)
• Define bill to and ship to sites for the internal customer (provider)
• Define internal billing implementation options (each operating unit)

• Define internal tax codes for Receivables invoices (provider)
• Define internal tax codes for Payables invoices (receiver)
• Define an agreement for intercompany billing projects
• Dene a Project Type for Intercompany Billing Projects
• Dene Project Templates for Intercompany Billing Projects
• Dene Intercompany Billing Projects (receiver)
• Dene Provider and Receiver Controls

Provide Controls:

Receiver Controls:

• Dene AutoAccounting for Intercompany Billing Transactions

Steps to process Intercompany Transactions for Contract Projects (Canada = Provider OU, US = Receiver OU):

1. Receiver OU - Create/ Approve Contract. Enter "Employee Bill Rate and Discount Overrides" at the Project/ Task Level for Provider Employee’s
2. Provider OU - Employee enters time against Receiver OU Project
3. Provide OU - Time Card is approved
4. Provider OU - Employee enters & submits expenses against Receiver OU Project
5. Provider OU - Expense is approved are processed in AP
6. Provider OU - Run Transaction Import (Timecards), Interface Expense Reports to PA, Distribute Labor Costs
7. Receiver OU - Generate Draft Revenue
8. Provider OU - Review Proj Func Burdened, Labor, Expense Report Cost/ Accounts
9. Receiver OU - Verify Labor Revenue A/C, Expense Revenue A/C
10. Receiver OU - Run Project WIP Report (on demand), Project Manager reviews WIP Report and Attests Revenue
11. Receiver OU - Generate Draft Invoice, Approve & Release Draft Invoice
12. Receiver OU - Interface to AR, Review BPA Invoice, Run BPA Master Print Program to print invoice, Mail Invoice to Customer
13. Provide OU – Generate, Approve and Release Intercompany Invoice
14. Provide OU – Interface Intercompany Invoice to Receivables
15. Provide OU - Verify Intercompany Receivables / Revenue Account, Invoice Tax Account
16. Receiver OU – Run Payables Intercompany Invoices Interface Import, AP Post , Payables Transfer to GL, Validate Accounts

SOX, SOD and Oracle Apps

2008-03-13T13:55:00.001-04:00

Why SOX Compliance is critical - Top Ten IT Control Deficiencies ( Source: Ken Vander Wal, Partner, National Quality Leader, E&YISACA Sarbanes Conference , 4/6/04):

1.Unidentified or unresolved segregation of duties
2.Operating System access controls supporting financial applications or Portal not secure
3.Database access controls supporting financial applications not secure
4.Development staff can run business transactions in production
5.Large number of users with access to “super user” transactions
6.Former employees or consultants continue to have system access
7.Posting periods not restricted within GL application
8.Custom programs, tables and interfaces are not secured
9.Procedures for manual processes do not exist or are not followed
10.System documentation does not match actual process

Segregation of Duties (SOD) Definition:

Segregation of duties (SOD) provides the assurance that no one individual has the physical and system access to control all phases of a business process or transaction: from authorization to custody to record keeping. A person or group has too much access or authority – resulting in risk exposure to the business.

SOD Examples:

Organizations in Oracle Apps

2008-03-13T12:20:00.001-04:00

I.Organization in Oracle Applications

Definition of Organization:

Organization is an entity to which different types of transactions, that are recorded, are identified. A transaction is recorded for a particular kind of Entity, in other words, Organization.

Need for Organization:

1.Use a single installation of any Oracle Applications product to support any number of organizations, even if those organizations use different sets of books.
2. Define different organization models

3. Support any number of legal entities within a single installation of Oracle Applications.
4. Secure access to data so that users can access only the information that is relevant to them.
5. Sell products from a legal entity that uses one set of books and ship them from another legal entity using a different set of books, and automatically record the appropriate intercompany sales by posting intercompany accounts payable and accounts receivable invoices.
6. Purchase products through one legal entity and receive them in another legal entity.

II. Types of Organizations

The types of Organizations are based on the business needs of an enterprise. These also depend on the purpose for which an Organization is created. An Organization could be Internal or External. Broad grouping of Organization is as follows:

A. Business Unit
B. Headquarters
C. Divisions / Departments / Branch
D. Plant / Operations Unit
E. Product Lines

These are considered for reporting purposes. An External Organization could be Agents or Tax Authorities. By categorizing an Organization as External, employees cannot be assigned.

Classification of Organizations:

The Classification of Organizations decides the data flow of your Enterprise. The following are the classifications to which an Organization can fall into.

1. Set of Books:

If the business need requires having more than one Set of Books, then the installation automatically becomes Multi Organizational. Oracle General Ledger secures transaction information (such as journal entries and balances) by set of books. When you use Oracle General Ledger, you choose a responsibility that specifies a set of books.

2. Business Group:

The Business Group represents the highest level in the Organizational Structure. All the human resources information is stored at this level. The employees are assigned at this level. All the Sets of Books that are attached to a Business Group share the employees within that Business Group.

3. Legal Entity:

This is an Organization which represents the legal Company for which the fiscal and tax reports are prepared. This is presently available in the United States Federal Reporting context.

4. Balancing Entity:

This is the accounting entity for which the financial reports are prepared. This is the mandatory segment in the Accounting Flexfield in Oracle General Ledger. There could be multiple companies that come under the same Legal Entity and each company’s financial statements match tally within itself.

5. Operating Unit:

An Operating Unit is generally your branch office or a sales division or a department. The subledgers like Payables, Receivables, Purchasing and Order Management are configured based on operating unit. The users attached to this subledger would see the data for only the operating that has been attached to the respective responsibility.

6. Inventory Organization:

This is the Organization that tracks the inventory transactions and balances and the activities of an organization that manufactures or distributes or stores products. Manufacturing units, warehouses, distribution offices are normally classified into this category. Oracle Manufacturing Suite modules are based on Inventory Organizations.

7. HR Organization:

This class of Organization represents the work structure of an enterprise. They usually represent the functional management, or reporting groups that exist within a business group.

8. Project Organizations:

These classes of Organizations are used in Oracle Projects to monitor and transact on different kinds on projects, created in Oracle Projects Suite. This document discusses in detail on Project Organizations in the coming sections.

9. Asset Organizations:

This is a new class of Organization introduced in Release 11i. An asset organization is an organization that allows you to perform asset–related activities for a specific Oracle Assets corporate depreciation book. Oracle Assets uses only organizations designated as asset organizations

III. Setup Organizations

The following are the simplified setup steps to be followed to create an organization structure in a new environment:
1) Define Organization Structure.

· This is a pen and paper process of setting up the organizations structure.

· Assign organization classification in the following order:

(1) Legal entities, (2) Operating units, and (3) Inventory organizations.

2) Define Sets of Books. Use Define Set of Books window to enter a set of books. Responsibilities used to assign sets of books:

a) Assets - Setup -> Financials -> General Ledger -> Set of Books

b) General Ledger - Setup -> Set of Books -> Define

c) Inventory - Setup -> Financials -> Books

d) Payables - Setup -> Set of Books -> Define

e) Purchasing Receivables - Setup -> Organizations -> Set of Books

f) Receivables - Set Up -> Financials -> Books

g) Government General Ledger - Setup -> Set of Books -> Define

3) Define Organizations. Use Define Organizations window to define organizations. · Responsibilities used to assign organizations:

i) Inventory - Setup -> Organizations -> Organizations

ii) Purchasing - Setup -> Organizations -> Organizations

iii) Order Entry / Shipping - Set Up -> Organizations -> Organization

iv) Projects - Setup > Human Resources -> Organizations -> Define

v) Receivables - Set Up > System -> Organization

vi) Government Purchasing - Setup -> Organizations -> Organizations

vii) Government Receivables - Set Up -> System -> Organization ·

Define Business Groups. (Optional)

· Define if you have multiple business groups or do not use default business group.

· You must have at least one business group. Oracle Applications supplies default business group, Setup business Group (fresh install).

· If you define business group next step must be to associate business groups with a responsibility and verify the HR: Business Group profile option. (See step 5.)

4) Define Organization Relationships. Use the Define Organization window to define organization relationships by assigning classifications to each organization.

a) Classification of an organization can be any combination in the following order: i) Legal entities, ii) Operating units, and iii) Inventory organizations.

b) Legal entities must have a location specified. (Zoom to Define Locations window.)

5) Define Responsibilities. Use the Define Responsibility window to define responsibilities for each operating unit. Responsibilities used to assign responsibilities:System Administrator - Security -> Responsibility -> Define If you have multiple business groups, you must associate each responsibility with one and only one business group. Use the HR: Business Group system profile option to associate a responsibility with a business group.

6) Set MO:Operating Unit Profile Option for Each Responsibility.

MO:Operating Unit profile option must be set.

· System Administrator - Profile -> System

· Set profile option to appropriate operating unit id (ORG_ID). You must set the default-operating unit setting MO:Operating Unit at the site level.

7) Run Convert to Multiple Organization using Adadmin utility. Process replicates seed data to all operating units that have been defined. This step is irreversible. Adadmin will fail if previous steps have not been completed. Concurrent managers must be down and no one should access the database. If adadmin fails during conversion and you are prompted to proceed as if successful, never select Yes, as the conversion process has already begun, and steps that may be missed during the conversion process will need to be manually created and be difficult, costly and timely to recreate.

8) Define Inventory Organization Security (Optional). Restricts manufacturing users to specific organizations.

9) Change Order Entry Profile Options (Optional). For Release 11: OE:Item Validation Organization profile option is set a responsibility level if operating units have different item validation organizations.
For Release 11i: Attach the submenu ‘ONT_SETUP’ and function ‘Setup OM parameters’ to any main menu (AR / OM). Switch to AR / OM Responsibility and
1. Open OM_Parameters Menu.
2. Give a Name for OPERATING UNIT and
3. For Item Validation Organization, Select Inventory Organization
4. Save your work

10) Update Profile Options Specific to Operating Units.

Set profile options at the responsibility level e.g.:i) AR: Receipt Batch Source ii) AR: Transaction Batch Source iii) OE:Item Validation Organization – Only for Release 11 iv) OE: Set of Books v) GL: Set of Books Sequential Numbering

Responsibilities used to assign profile options:System Administrator - Profile -> System. Refer to individual Oracle Financial Applications Products User's Guides for specific information on profile options that need to be set.

11) Set up Oracle Applications Products. OE, PA, PO, AR and Sales Compensation must be set up for each operating unit it they the product groups are to be used. FA, GL INV and the rest of the Oracle Manufacturing product do not need to be set up for each operating unit.

12) Secure Balancing Segment Values by Legal Entity. (Optional) Use the Define Security Rule window to create rules that secure data entry of balancing segment values for each legal entity.· Security rule elements specify a range of values to be included or excluded. Use the Assign Security Rules window to assign the same rule(s) to all responsibilities associated with the legal entity's operating units. Define additional rules and assign them to all responsibilities associated with relevant operating units.

13) Run the Setup Validation Report to Identify Setup Problems. Data for disabled fields on Enter Customer and Enter Supplier Window must be deleted.

14) Header information is shared across operating units and if you do not choose to delete the data, you must edit the database manually. All responsibilities in one operating unit must share the same profile option values and sequence numbering option.

Create Locations:

Use the Define Location window to define names and addresses for the locations you use within your enterprise. You define each location once only. This saves you time if you have multiple organizations with the same location. You should define locations for your legal entities and inventory organizations. Oracle Applications products use locations for requisitions, receiving, shipping, billing, and employee assignments.

Cross Business Groups

With Cross Business Group Access (CBGA) the business group now exists at one level lower and you can access organizations, resources and projects across business groups within a hierarchy

IV.Organizations in Projects Accounting

Projects can be controlled based on the Organization Classifications. The following are the basic classifications:

Project / Task Owning Organization. Project/Task Owning Organizations are organizations that can own projects and/or tasks in the operating unit.

Project Expenditure/Event Organization. Expenditure/Event Organizations are organizations that can own project events (labor and non–labor) and can incur expenditures for projects in the processing operating unit.

Project Invoice Collection Organization. If your business decentralizes its invoice collection within an operating unit, you must enable the Project Invoice Collection Organizations classification for each organization in which you want to process invoices.

Project Manufacturing Organization is one that links your Project between Inventory Organization and Projects. This is a new feature in Release 11i.

Billing Schedule Organizations are organizations that have their own billing schedules. Any organization in the operating unit’s business group can have its own billing schedules.

Resource Organizations are organizations that own resources and/or resource budgets. Any organization in the operating unit’s business group can own non–labor resources. Only HR organizations can have employees assigned to them. Oracle Projects does not have a classification requirement for an organization to own non–labor resources.

Relationships between Organizations

1. Legal Entities Post to a Set of Books

2. Operating Units Are Part of a Legal Entity

3. Inventory Organizations are Part of an Operating Unit

4. Inventory Organization Determines Items Available to Order Management

5. Inventory Organization Determines Items Available to Purchasing

6. Project Organizations are attached to Business Group

7. Employee availability within Operating Units depends on the Business Group to which the OU is attached.

8. A Project Organization has to be classified as HR Organization if employees are planned to be assigned.

9. A Project Manufacturing Organization should have an additional classification of Inventory Organization to be able to handle inventory items.

V. Organization Hierarchy

In Oracle Applications, organization hierarchies show reporting lines and other hierarchical relationships among the organizations in your enterprise. An organization hierarchy illustrates the relationships between your organizations. When you define a hierarchy, you tell Oracle Projects which organizations are subordinate to which other organizations. The topmost organization of an organization hierarchy is generally the business group.

In addition to the primary reporting hierarchy, you can set up in as many other organization hierarchies as you need. You can create as many organization hierarchies as you need for different reporting and processing needs, and you can create multiple versions of an organization hierarchy. Oracle Projects uses the hierarchy version to determine which organizations are used for reporting and processing.

The following organization hierarchy versions are assigned in Oracle Projects:

A Project/Task Owning Organization Hierarchy Version is assigned to each operating unit.
An Expenditure/Event Organization Hierarchy Version is assigned to each operating unit.
A Default Reporting Organization Hierarchy Version is assigned to each operating unit. This hierarchy version can be overridden at reporting time.
A Project Burdening Hierarchy Version is assigned to each business group.

Start Organization

This is the branch of your organization hierarchy that you specify in Oracle Projects as the top of your hierarchy. When you choose a start organization as a reporting parameter, the start organization and all organizations below it are included in the report.

You create organization hierarchies in the Organization Hierarchy window. Always define hierarchies from the top organization down. You must define the top organization in the hierarchy, and at least one organization subordinate to it. The organization hierarchy you define here appears in a list of values in the Implementation Options window.

To create an Organization Hierarchy,

1. Enter a unique name for the hierarchy, and check Primary if it is your main reporting hierarchy.
2. Enter the version number and start date for the hierarchy. You can copy an existing hierarchy.
3. Query the top organization name in the Organization block.
4. In the Subordinates block, select the immediate subordinates for the top organization.
5. To add organizations below one of these immediate subordinates, check the Down check box for the organization. The Organization block now displays the organization you selected. You can add subordinates to this organization. To return to the previous level, check the Up check box.

To change the hierarchy

1. Query the name of the hierarchy.
2. In the Version field, use the Down Arrow to move through existing versions of the hierarchy until you reach a version number for which no other data appears. Enter the start date for the new version.
Note: Overlapping versions of a hierarchy cannot exist. Whenever you enter a new version of a hierarchy, the system automatically gives an end date to the existing version. Oracle HRMS retains the records of obsolete hierarchies, so you do not lose any historical information.
3. Query the top organization name in the Organization block.
4. In the Subordinates block, select the immediate subordinates for the top organization.
5. To add organizations below one of these immediate subordinates, select the Down check box for the organization. The Organization block now displays the organization you selected. You can add subordinates to this organization. To return to the previous level, select the Up check box.

Project/Task Owning Organization Hierarchy

You assign a project/task owning organization hierarchy to the operating unit to control which organizations can own projects and tasks. To own projects and/or tasks in the operating unit, an organization must have all of the following characteristics:
1.The organization must belong to the project/task organization hierarchy assigned to the operating unit.
2. The organization must have the project/task owning organization classification enabled.
3. The project type class must be permitted to use the organization to create projects. This permission is determined when you define the organization.
4. The organization must be active as of the system date.

Expenditure/Event Organization Hierarchy
You assign an expenditure/event organization hierarchy to the operating unit to control which organizations have the following capabilities:
1. incur expenditures
2. own project events
3. be assigned to a resource list as a resource

Default Reporting Organization Hierarchy

You specify an organization hierarchy and version to indicate which organization hierarchy of a Business Group you want Oracle Projects to use as the default reporting organization hierarchy.

You specify a start organization to indicate which branch of your organization hierarchy you want Oracle Projects to recognize as the top of your hierarchy for reporting purposes. If you want to use your entire organization hierarchy, your top organization (generally the business group) is the start organization. For example, if you define your organization hierarchy with four divisions under the top organization, you can specify one division as the start organization. Oracle Projects consequently recognizes only that division and its subordinate organizations as its default reporting hierarchy.

Project Burdening Organization Hierarchy

For each Business Group, you specify a Project Burdening Organization Hierarchy and Version. Oracle Projects uses the Organization Hierarchy/Version to determine the default Burden Multiplier when compiling a Burden Schedule.

To specify project burdening hierarchies:

1. Select an Oracle Projects responsibility with access to the Organization window associated with the Business Group for which you are entering Legal Entities and Operating Units.
2. Navigate to the Organizations window (Setup > Human Resources > Organizations > Define).
3. Define an organization or query organizations that you defined as a business group. You must define the hierarchy before you designate it as the project burdening hierarchy.
Depending on your enterprise organization structure and business process, it is possible for the Project Burdening Hierarchy Version to be different from the Project/Task Organization Hierarchy Version, Expenditure/Event Organization Hierarchy Version, or Default Project Reporting Organization Hierarchy Version that you defined for any operating units associated with the business group. The Cost Distribution processes will not burden expenditures for expenditure organizations that are not in the Project Burdening Hierarchy.

If you add a new organization to the Project Burdening Hierarchy Version

If you add a new organization to the Project Burdening Hierarchy Version, you must
1. add new burden multipliers for that organization in the appropriate burden schedules, or
2. use the multipliers inherited from the parent organization as the burden multipliers for the organization

If you want to add burden multipliers to a particular schedule version for the organization, you need to compile the affected schedule version. If you use the parent organization multipliers, you must submit the PRC: Add New Organization Burden Compiled Multipliers process. This process adds multipliers for this organization to all burden schedules versions for which you did not explicitly add multipliers. If you do not run this process, you will encounter a rejection reason of ’Cannot find compiled multiplier’ for transactions charged to this organization.

VI.Profile Options

HR:Business Group
Use this profile option to attach a Business group.

HR: Security Profile
Use this profile option to point your responsibility to a specific business group.

HR: User Type
Use this profile option to classify the type of HR installation your enterprise has

HR: Cross Business Group
Use this profile option to enable Cross Business Group access functionality.

MO: Operating Unit
Use this profile option to control which operating unit a particular responsibility corresponds to only if you have implemented multiple organization support.

Multi-Org 101

2008-03-13T10:45:00.002-04:00

Multi-Org Architecture:
1. Before Multi-Org – Need one server for every set of Books implemented
2. With Multi-Org – One server, multiple sets of Books
3. The multiple organization structure simply partitions key tables to allow for an ORD_ID number per row
3.1 Used to provide security and data segregation.
4. Criteria used to partition tables includes:
4.1 The table contains a GL Account Code (code combination ID).
4.2 There is a business reason for the table to be partitioned (for example, the entity should not be shared).
4.3 The table contains transaction data.
4.4 The table is an interface table where data being loaded is partitioned.
4.5 The table includes a foreign key to a partitioned table and is accessed independently (in other words, not just as a child of a partitioned table).

Centralized Processing:
1. Centralized GL, AP, AR, PO, OE, and PA
1.1 Clients can use your balancing segment within your Chart of Accounts to segregate legal entity data
2. Decentralized GL, AP, AR, PO, OE, and PA
2.1 Client must have an Operating Unit for each group

Multi-Org Relationships:
1. Business Group, Legal Entity and Master Inventory Organization are all separate structures
2. Business Group and Legal Entity are linked through Responsibilities using the System Profile Options
3. Legal Entities and Inventory Organizations are linked by Set of Books

Why do you need Multi_org?
1. We only have one Set of Books, Business Group, Legal Entity and Operating Unit. Why Run Multi-Org?
1.1 Future growth and acquisitions
1.2 Change in company directions
1.3 Conversion from single org to multi-org is
1.3.1 Difficult in Release 10
1.3.2 Required in Release 11i and 12i

High Level Multi-Org Setup Steps:
1. Develop the organization structure
2. Define sets of books
3. Define organizations (Business Group, Legal Entity, Operating Unit, Inventory Orgs)
4. Define organization relationships
5. Define responsibilities
6. Update Profile Options Specific to Operating Units
7. Run the Setup Validation Report (recommended)

Multi-Org model as it relates to organizations:
· A ‘Business Group’ is the highest level of the structure and has no accounting impact. The ‘Business Group’ determines which employees will be available to ‘Sets of Books’ and ‘Operating Units’ related to that ‘Business Group’
· ‘Set of Books’ is the highest level which impacts the accounting side of the business
· ‘Set of Books’ is associated with a single ‘Business Group’, multiple ‘Sets of Books’ may be associated with a single ‘Business Group’
· Each ‘Set of Books’ may have a different chart of accounts structure, calendar or functional currency
· Each ‘Legal Entity’ is associated to a single ‘Set of Books’, multiple ‘Legal Entities’ may be associated with the a single ‘Set of Books’
· Each ‘Operating Unit’ is associated with a single ‘Legal Entity’, multiple ‘Operating Units’ may be associated with a single ‘Legal Entity’
· An ‘Inventory Organization’ may be associated with any ‘Operating Unit within the same ‘Set of Books’

New Operating Units - Critical Steps:
1. Oracle provides the seed data replication program as a concurrent program
2. May need to run the Replicate Seed Data process if seeded data does not replicate correctly
3. Remember to set up Responsibilities and System Profile Options (GL: Sets of Books and MO: Operating Unit) for each new OU defined

High level Workflow Customization Approaches

2008-03-13T10:04:00.001-04:00

Approach 1. Preserve the original workflow, with a different name. Then customize the original workflow.

Approach 2.Customizing the original (even if you use the appropriate workflow protection) often results in the flow being blown away when patches are applied. It also means that the fact a flow is customised difficult to tell. So where possible we create new top level (runnable processes) by copying them and renaming them and the same for all lower levels that are customised. With the PO approval (and several other flows inc accopunt generator flows) this is the way to go because you can define the startup process in the application.

So for reasons of patch protection and clearly visable customisations always create new top level processes. All new or customised functions, notifications etc are also copied and renamed.

Approach 3.One other point to consider is there are workflows that you cannot rename. Therefore, you will have to customize the ORIGINAL. Some of these workflows were in the PO module.

Approach 4.The Best way to Customize the workflows is as follows.
1)Take the seeded workflow
2)Right click on the Item TYpe and create a new Item TYpe .
3)OPen Seeded Workflow in other window .
4)Copy and paste ATTRIBUTES , NOTIFICATIONs etc from the the seeded workflow to the Newly named workflow .
5)Verify the workflow
6)Customize the new workflow according to your need.

Approach 5.If you make a copy of the item type itself, you will also need to customize your form which calls the workflow, since the internal name is hard coded in the application.

In case of an 'Account Generator' workflow, you can make a copy of the top level process 'Generate Default Account', customize it and other processes under it and then call it by setting the internal name of this process under Application =>
Flexfield => Key => Accounts for the specific account generator.

As a general rule, do not decide to customize forms code for workflow related changes. To retain your customizations, upload your customized workflows whenever any patches are applied.

Approach 6.Some workflows do not allow you to use the copy approach so you have to modify the standard process. Examples where you can use the copy are:

1. All account generator workflows
2. PO Approval
3. Requisition Approval

Examples where you cannot do this:

1. PO Create documents
2. Expense Report Approval

Oracle AIM Document Templates

2008-03-12T16:22:00.001-04:00

1. Business Process Architecture (BP)
BP.010 Define Business and Process Strategy
BP.020 Catalog and Analyze Potential Changes
BP.030 Determine Data Gathering Requirements
BP.040 Develop Current Process Model
BP.050 Review Leading Practices
BP.060 Develop High-Level Process Vision
BP.070 Develop High-Level Process Design
BP.080 Develop Future Process Model
BP.090 Document Business Procedure

2. Business Requirements Definition (RD)
RD.010 Identify Current Financial and Operating Structure
RD.020 Conduct Current Business Baseline
RD.030 Establish Process and Mapping Summary
RD.040 Gather Business Volumes and Metrics
RD.050 Gather Business Requirements
RD.060 Determine Audit and Control Requirements
RD.070 Identify Business Availability Requirements
RD.080 Identify Reporting and Information Access Requirements

3. Business Requirements Mapping
BR.010 Analyze High-Level Gaps
BR.020 Prepare mapping environment
BR.030 Map Business requirements
BR.040 Map Business Data
BR.050 Conduct Integration Fit Analysis
BR.060 Create Information Model
BR.070 Create Reporting Fit Analysis
BR.080 Test Business Solutions
BR.090 Confirm Integrated Business Solutions
BR.100 Define Applications Setup
BR.110 Define security Profiles

4. Application and Technical Architecture (TA)
TA.010 Define Architecture Requirements and Strategy
TA.020 Identify Current Technical Architecture
TA.030 Develop Preliminary Conceptual Architecture
TA.040 Define Application Architecture
TA.050 Define System Availability Strategy
TA.060 Define Reporting and Information Access Strategy
TA.070 Revise Conceptual Architecture
TA.080 Define Application Security Architecture
TA.090 Define Application and Database Server Architecture
TA.100 Define and Propose Architecture Subsystems
TA.110 Define System Capacity Plan
TA.120 Define Platform and Network Architecture
TA.130 Define Application Deployment Plan
TA.140 Assess Performance Risks
TA.150 Define System Management Procedures

5. Module Design and Build (MD)
MD.010 Define Application Extension Strategy
MD.020 Define and estimate application extensions
MD.030 Define design standards
MD.040 Define Build Standards
MD.050 Create Application extensions functional design
MD.060 Design Database extensions
MD.070 Create Application extensions technical design
MD.080 Review functional and Technical designs
MD.090 Prepare Development environment
MD.100 Create Database extensions
MD.110 Create Application extension modules
MD.120 Create Installation routines

6. Data Conversion (CV)
CV.010 Define data conversion requirements and strategy
CV.020 Define Conversion standards
CV.030 Prepare conversion environment
CV.040 Perform conversion data mapping
CV.050 Define manual conversion procedures
CV.060 Design conversion programs
CV.070 Prepare conversion test plans
CV.080 Develop conversion programs
CV.090 Perform conversion unit tests
CV.100 Perform conversion business objects
CV.110 Perform conversion validation tests
CV.120 Install conversion programs
CV.130 Convert and verify data

7. Documentation (DO)
DO.010 Define documentation requirements and strategy
DO.020 Define Documentation standards and procedures
DO.030 Prepare glossary
DO.040 Prepare documentation environment
DO.050 Produce documentation prototypes and templates
DO.060 Publish user reference manual
DO.070 Publish user guide
DO.080 Publish technical reference manual
DO.090 Publish system management guide

8. Business System Testing (TE)
TE.010 Define testing requirements and strategy
TE.020 Develop unit test script
TE.030 Develop link test script
TE.040 Develop system test script
TE.050 Develop systems integration test script
TE.060 Prepare testing environments
TE.070 Perform unit test
TE.080 Perform link test
TE.090 perform installation test
TE.100 Prepare key users for testing
TE.110 Perform system test
TE.120 Perform systems integration test
TE.130 Perform Acceptance test

9. PERFORMACE TESTING(PT)
PT.010 - Define Performance Testing Strategy
PT.020 - Identify Performance Test Scenarios
PT.030 - Identify Performance Test Transaction
PT.040 - Create Performance Test Scripts
PT.050 - Design Performance Test Transaction Programs
PT.060 - Design Performance Test Data
PT.070 - Design Test Database Load Programs
PT.080 - Create Performance Test TransactionPrograms
PT.090 - Create Test Database Load Programs
PT.100 - Construct Performance Test Database
PT.110 - Prepare Performance Test Environment
PT.120 - Execute Performance Test

10. Adoption and Learning (AP)
AP.010 - Define Executive Project Strategy
AP.020 - Conduct Initial Project Team Orientation
AP.030 - Develop Project Team Learning Plan
AP.040 - Prepare Project Team Learning Environment
AP.050 - Conduct Project Team Learning Events
AP.060 - Develop Business Unit Managers’Readiness Plan
AP.070 - Develop Project Readiness Roadmap
AP.080 - Develop and Execute CommunicationCampaign
AP.090 - Develop Managers’ Readiness Plan
AP.100 - Identify Business Process Impact onOrganization
AP.110 - Align Human Performance SupportSystems
AP.120 - Align Information Technology Groups
AP.130 - Conduct User Learning Needs Analysis
AP.140 - Develop User Learning Plan
AP.150 - Develop User Learningware
AP.160 - Prepare User Learning Environment
AP.170 - Conduct User Learning Events
AP.180 - Conduct Effectiveness Assessment

11. Production Migration (PM)
PM.010 - Define Transition Strategy
PM.020 - Design Production Support Infrastructure
PM.030 - Develop Transition and Contingency Plan
PM.040 - Prepare Production Environment
PM.050 - Set Up Applications
PM.060 - Implement Production Support Infrastructure
PM.070 - Verify Production Readiness
PM.080 - Begin Production
PM.090 - Measure System Performance
PM.100 - Maintain System
PM.110 - Refine Production System
PM.120 - Decommission Former Systems
PM.130 - Propose Future Business Direction
PM.140 - Propose Future Technical Direction

The 'X' Factor

2008-03-07T17:03:00.001-05:00

'X' Concept - One of my clients wanted to get a Trial Balance in the US Sets of Books which will only have Transactions which are entered in US dollars. As per the standard Oracle functionality, if the transaction currency is the same as the SOB functional currency, the Entered Dr and Entered Cr columns are not populated. Only the Accounted Dr and Accounted Cr columns are populated. This creates an issue as the client wants to run a trial balance on transactions entered only in SOB functional currency.

High Level Solution - 'X' currency, to overcome this, a solution was developed to use a currency called ‘X’ as the USD books reporting currency. If we take USD (Primary SOB) and USX (Reporting SOB), all transactions in USD in USD SOB will appear as a transaction currency in the USX SOB (foreign currency transaction). This will enable the user to run foreign currency Trial Balance in the USX books on transactions entered in USD.