Thomas Simkiss

Inter and Intra Company Accounting – A Deep Dive

Author: Thomas Simkiss Date: September 11th, 2012
Categories: E-Business Suite, Oracle Application Services

In E-Business Suite (EBS) Release 12, Oracle completely changed the way in which intercompany transactions can be accounted by creating a robust, flexible, rules-based intercompany accounting program. This accounting program, however, is only useful if you understand how it’s used and how it should be configured. This article will give clarity to those configurations, EBS Legal Entities, the purpose they serve and answer the question: “When is a legal entity,not a legal entity?” 

» Read More

BizTech Offers Access to R12 Vision Instance

Author: Thomas Simkiss Date: March 16th, 2012
Categories: E-Business Suite

BizTech is pleased to provide public access to Oracle’s Release 12 Vision environments. These Vision instances provide best practice configurations, as well as sample data and transactions for Oracle’s E-Business Suite. 

» Read More

Multi-Period Accounting in SLA

Author: Thomas Simkiss Date: February 28th, 2012
Categories: E-Business Suite, Oracle Application Services

Multiperiod accounting is a flexible, powerful tool available with Release 12 of the Oracle e-Business Suite which allows users to systematically record accounting entries across multiple periods. This post will focus on real world applications of this functionality, and present the detailed steps required to implement the functionality within Payables and Purchasing.

Multi-Period Accounting using SLA

Author: Thomas Simkiss Date: October 18th, 2011
Categories: E-Business Suite, Oracle Application Services

Multiperiod accounting is a flexible, powerful tool available with Release 12 of the Oracle e-Business Suite which allows users to systematically record accounting entries across multiple periods. This blog entry  will focus on real world applications of this functionality, and present the detailed steps required to implement the functionality within Payables and Purchasing.

» Read More

Intercompany / Intracompany Accounting in Oracle R12

Author: Thomas Simkiss Date: August 22nd, 2011
Categories: E-Business Suite, Oracle Application Services

If you are using R12 you may have encountered a requirement to setup all your legal entities with intercompany accounting for each. That is, for each legal entity, whether your setup requires that you configure intercompany relationships for each entity you have, or you are able to use the all other setup, it can still be a lot of work to configure.

One of the many benefits of R12 is that the new legal entity structure provides the ability to track intercompany transactions as a very granular level. Per the Oracle Financials Implementation Guide, there are different types of intercompany journals. The Balancing API first determines the type of the intercompany journal (one-to-one, one-to-many, many-to-one, or many-to-many) with respect to the legal
entities. However, for intercompany balancing there is no clearing company usage and all legal entities are balanced by summary net with respect to each other.

Intercompany accounting for transactions performed between separate legal entities that belong to the same corporate enterprise.

Intracompany balancing for journals that involve different groups within the same legal entity,
represented by balancing segment values. A group could be a profit center, manufacturing plant, a warehouse, a cost center, or any other organization that represents a subset of a legal entity. Often, these transactions pass through a clearing organization, which is also represented by a balancing segment value.

In 11i, it was possible to use a clearing account or company, whereby a company can use a single account or company to own all its intercompany (or intracompany in R12 parlance) transactions.

This situation can look like this:

Parent Company is a holding company represented by value 1000. Parent Company pays the invoices on behalf of its subsidiaries, Child 1001 and Child 1005. Rather than have transactions flow across legal entities, Parent company wants all due to and due from to flow through it.

So, when an invoice is entered and paid for Child 1001, the journal entry would be this:

1001.Expense.0000 100
1000.A/P.0000 100
1000.I/C.1000 100
1001.I/C.1001 100

This is a relatively straightforward configuration which can be achieved via standard intercompany configuration.

However, what if there is a transaction between 1001 and 1005. Standard I/C setup will not allow a clearing account, so the intercompany would be between 1001 and 1005.

If you configure Legal Entity Parent Company, and assign value 1000 to it, and then assign the balancing segments for 1001 and 1005 to the Legal Entity Parent, you can achieve the desired result.

Using Intracompany accounting, for a source of Other, category of Other, allows you to configure all intracompany transactions to use the default clearing company of 1000.

The journal entry for a transaction between 1001 and 1005 would then look like this:
1001.Expense.0000 100
1005.Expense.0000 100
1005.I/C.1000 100
1001.I/C.1000 100

The journal above represents transactions run through the 1000 parent as per the requirements.

NOTE: If you are required to configure the 1001 or 1005 Legal entity for reporting purposes or bank ownership, this method will not work.

Collaborate 2011 – A Review

Author: Thomas Simkiss Date: May 2nd, 2011
Categories: E-Business Suite, Oracle Application Services

All,

For those that attended Collaborate 2011 in Orlando, welcome back! Special thanks to the OAUG, IOUG, and Quest for puting together another great conference with some tremendous content for users new and old alike.

For the first time several of the Special Interest Groups (SIGs) got together to present a single flow presentation, crossing multiple business areas and processes across several different presentations. This Collaborative SIG (CS) was teh result of a brainstorming session held last year in LAs Vegas at Collaborate 2010, and required a lot of hardwork and cooperation from several groups.

The presentations utilized a process flow based on the Oracle Vision Environment for a sale of products in the US, sourced from Germany, via a Dutch supplier, and then invoiced via Drop Ship in the US. The entire presentation, along with all the others, is available from the OAUG website for OAUG Members.

BizTech had nine presentations at Collaborate 2011, all of which are available from OAUG and at BizTech.com here.

For those that made it to Orlando – which sessions did you like the best and why? Did you get out of the conference what you were hoping? If not, why not? Please comment so that we can share with the OAUG and make better for next time.

For the next post, a bit about subledger accounting. See you then!

Project Reporting from the General Ledger

Author: Thomas Simkiss Date: April 7th, 2011
Categories: E-Business Suite, Oracle Application Services

In order to understand how General Ledger may be used to provide projects based or project related reporting, we must first explain how Oracle General Ledger stores and tracks account balance information. 

Any segment in the chart of accounts could be considered for use as a project segment.  You can set up your accounts to record project activity, and you can use the Financial Statement Generator to produce customized project tracking reports.  If you set up your accounts for project tracking, General Ledger automatically maintains project-to-date balances in the GL_BALANCES table.  The project-to-date balance is based on the project start date you enter when you define a project segment value.   For each new code combination identification (CCID) inserted into GL Balances, Oracle starts recording balances, beginning balance (0 for a new CCID), period-to-date debits and credits, quarter-to-date debits and credits, and project-to-date debits and credits.   Project-to-date balances for all accounts types, assets, expenses, revenues, etc. are treated as if they were balance sheet accounts – they do not close out to retained earnings at the end of a the fiscal year.  Thus even for projects across years, you can still get project-to-date reporting.

Project-to-date reporting is supported in many standard Oracle General Ledger Reports including but not limited to:

• Trial Balance
• Trial Balance – Additional Segment Detail
• Trial Balance – Detail
• Financial Statements

These reports all contain project -to-date balances in their definitions, which as stated above, allow reporting of project balances for any type of account, even if it crosses a fiscal year. 

Project access and duration may both be maintained using the standard Oracle Functionality of Start and End Dates on the Value in the Value set.  In addition Cross Validation rules were implemented to ensure that only specific charge types applicable to the project were able to be coded to the project.

Two pieces of functionality which may be applicable to Project based reporting from General Ledger are Budgetary Controls and Security Rules.   Budgetary control refers to the process of recording budget data and tracking encumbrance and actual data against a budget. You can track budget or encumbrance data using one of two methods: encumbrance accounting or budgetary accounts. Funds checking is a feature of budgetary control that helps prevent overspending budgets by verifying available funds online before processing a transaction. With funds checking, you can verify transactions online against available budget, immediately update funds available for approved transactions, and control expenditures at the detail or summary level.   Use of Budgetary Controls in conjunction with Purchasing and Payables allows for instantaneous verification that sufficient funds are available for expenditures.  Budgetary Controls may be implemented at the Detail Account Level (a budget must be entered for every valid account in a budget range) or at a summary level using roll up groups.

Security rules applies to individual value sets give you the capability to restrict the set of values a user can use during data entry.  You may use security rules and responsibility level control to set up data entry security on your flexfield segments and report parameters.

When you use Flexfield Value Security, users see only values they are allowed to use; restricted values do not appear in lists of values associated with the flexfield or report parameter. There are two levels where you must activate Flexfield Value Security; the value set level and the individual segment or parameter level.  You make Flexfield Value Security available for your value set by choosing Hierarchical Security or Non-Hierarchical Security for the Security Type.  When you make security available for a value set, all segments and report parameters that use that value set can use security. You then enable security for a particular segment or parameter. Choose Non-Hierarchical Security if you do not want security on a parent value to “cascade down” to its child values. Choose Hierarchical Security if you do want the hierarchical security feature enabled.

Make sure to stop by my presentation at Collaborate 11 in Orlando for more in this topic, or feel free to let me what you think about Project reporting from the GL using the comments link on the BLOG.   Thanks and happy Oracling!!!

Oracle R12 Financials Blog – Welcome!

Author: Thomas Simkiss Date: March 18th, 2011
Categories: E-Business Suite, Oracle Application Services

Welcome to the Oracle R12 Financials Blog.  The purpose of this blog will be to share information, experiences, best practices, and strategies for implementing, configuring and using the Oracle R12 Financials.  My hope is that the content put forth on this site will be useful and informative and hopefully, spur discussion and some debate amongst the readers. 

The four C’s – Calendar, Currency, Chart of Accounts and Accounting Convention – are the foundation of every applications implementation.   A well designed chart of accounts must capture the relevant information required for financial and operation reporting, while maintaining flexibility for growth and business change.  With the introduction of subledger accounting and secondary reporting ledgers, increased integration between the Oracle Applications and improved reporting tools such as OBIEE and Hyperion the need to cram everything possible into the chart of accounts has drastically increased.  

I have always gone by the adage: “If you need a financial report by “it”: Cost Center, Profit Center, Line of Business, Department, Legal Entity, Bob, etc., “it” should be in your chart of accounts”.    This is a holdover from the days of the true FAT ledgers where everything related or desired for reporting was included in the chart of accounts.   This drove companies to have huge, bloated charts of accounts that were difficult to maintain, and use, and often caused great pain and heartache when it came to writing and updating FSGs.   That is not what I am advocating, but instead, I am focused on Financial Reports only:  Profit and Loss, Balance Sheet, Statement of Cash Flows, etc. 

The chart of accounts may be best summarized as follows:

• Three segments are mandatory: natural account, balancing segment, and cost center
• The balancing segment reflects organizational units, both legal and management
• The cost center is generally aligned with the department structure used in your human resources application
• Additional segments are optional and should only be added if required to generate financial reports directly from Oracle GL

Additional segments are added as required for product hierarchies, project codes, or channel analysis or whatever you wish to track.  All products that perform accounting derive the account code combination identifier (CCID) using Oracle Subledger Accounting and write a full entry for each business event.  These entries may be summarized and posted on your schedule (for example posted immediately or monthly) to the ledger.

What are your thoughts and experiences?  Please post your reply and let’s get some good old fashioned debate started on this subject!

Please make sure to come and see me at OAUG Collaborate 2011 where I will be participating in several Collaborative Special Interest groups covering best practices in the P2P and O2C flows, as well as presentation with Party City on the very subject of Chart of Accounts design and use for a retail environment!    Thanks and see you in Florida.