Activity Stream

7 days ago
new download
Gunas Rams downloaded How to create conditional flexfields

new user registration
Gunas Rams joined our community! Welcome!

More than 2 weeks ago
new user registration
Mohit Agarwal joined our community! Welcome!

About 3 weeks ago
new user registration
Henry Jiang joined our community! Welcome!

About a month ago
new user registration
shirish ora joined our community! Welcome!

new user registration
T Sundaram joined our community! Welcome!

new user registration
Appoicfoors Appoicfoors Uggs Outlet joined our community! Welcome!

How to organize your BR.100s with multiple organizations
( 1 Vote )
Experiences - Best Practices
Written by Jouke de Groot   
Tuesday, 06 November 2007 21:43

Documenting the setup in BR.100's is not the favorite activity for most consultants, but I think it is an essential part of the implementation. During this phase, which usually consists with lots of uncertainty and pending decisions, the BR.100's reflect the agreed setup for the master environment. But how can we reduce the size of these documents in case of multiple Operating Units and Set of Books ?

br100.jpgThe way we document the setup in BR.100's using Oracle's AIM methodology is a separate topic. Who has never had any discussions about creating documents in Excel, or by creating screen shots ? And what do we actually document in the BR.100's and what do we put in separate sheets (e.g. payment terms, CoA value sets, ...) ?

In this article I will describe how I usually organize my BR.100's in situations where multiple Operating Units and/or multiple Set of Books (sorry, I have no practical experience with Ledgers in R12 yet). The standard, empty BR.100's are organized per module (even if we implement Business Flows ...). Each BR.100 contains all setup steps related to that module. I have seen BR.100's where all the operating unit specific parts are copied and modified accordingly within the same document, resulting in BR.100's with hundreds of pages ... The revision history was overwhelming, and maintenance extensive ...

In my opinion it's better to split these documents in general (global) setup and OU-specific (or SoB specific for GL) setup. This approach has a lot of advantages.

  • It is easier to share with multiple persons
  • Better version control
  • Better overview
  • Better insight for less-experienced persons what the impact of a setup change is (local or global)
  • Local setup BR.100 is basis for future roll-outs

So the idea is to start with a global setup document per module. This setup needs to be agreed globally and serves as a basis for future roll-outs. Changes in this setup will affect all operating units, so it needs to be guarded carefully.

But before splitting the BR.100's according to Oracle's organization structure ('org-striping') it's worth to understand that the org structure is not always the most obvious choice from a functional point of view. Some setup is global from an Oracle perspective, but could have deviations per operating unit (e.g. Customer Profile Classes, Dunning Letters, Pay Groups). The freedom to deviate from the global footprint (if available Wink) depends per organization, so these setups needs discussion beforehand). Secondly, some global setup is employee related (collectors, approval limits). It is very likely that this setup needs to be discussed for every Operating Unit, so according to me it is obvious to include this setup in the local setup document.

Find below the split-up for the Financial modules.

Receivables


Global Setup
Local Setup Global/Local Setup
Define AutoCash Rule Sets Define System Options Open/Close Accounting Periods (shared per SOB)
Define Receivables QuickCodes Define Transaction Types Define Collectors (shared)
Define Demand Class QuickCodes Define Bank Accounts Define User Approval Adjustment Limits (Shared)
Define AutoInvoice Line Ordering Rules Define Bank Codes Define Receipt Classes and Payment Method (shared)
Define Accounts Receivable Payment Terms Define Invoice Sources Define Statement Cycle (shared)
Define Invoicing and Accounting Rules
Define Accounts Receivable Distribution Sets Define Standard Messages (shared)
Define Aging Buckets Define Receivables Activity Define Dunning Letters (shared)
Define Transmission Formats Define Receipt Sources Define Dunning Letter Sets (shared)
Define Tax Locations and Rates Define Tax Codes and Rates Define Salespersons (shared)
Define Tax Authorities Define Tax Groups Define System Profile Options
Review Sales Tax Rates Define Customers Define Customer Profile Classes (shared)

Define Remit-To Addresses

Define Lockboxes

Define Standard Memo Lines

Define Item Tax Rate Exceptions

Define Tax Exemptions

Payables

Global Setup Local Setup Global/Local Setup
Define VAT Code Type Payables
Choose a Set of Books Define Invoice Tolerances (shared – OU specific)
Define Withholding Tax Groups
Define Tax Names
Define Profile Options
Maintain Tax & Certificates
Define Witholding Tax Groups

Define Invoice Approvals
Maintain Tax & Certificates
Define Payment Interest Rates
Define Payment Interest Rates

Define Income Tax Regions Define Reporting Entities

Define Payment Formats
Define Financial Options

Define Request Sets
Define Accounts Payable Options

Define Account Segments for Expense Reporting
Define Request Sets

Define Aging Periods
Define Account Segments for Expense Reporting

Printer for Vendor Mail Label : Printer Style
Define Special Calendars
Printer for Vendor Mail Label : Printer Driver
Define Bank Accounts

Printer for Vendor Mail Label : Printer Type


Printer for Vendor Mail Label : Register a Printer


Assign Printer Style to Vendor Mail Label Report

Define Special Calendars










Comments

Please login to post comments or replies.