Oracle Financials Strategy

I've been tagged - so here goes.

1. I was raised on a real farm in West Virginia - and yes, I have milked a cow, albeit it not very well.
2. We have 21 legs in our household - me, 3-dogs, a cat, and due to an unfortunate recent accident, one three-legged dog.
3. I have an X-box 360, and my favorite game is whimpy tennis - kinda reminds me of pong.
4. I moved to Portland the same day as the fool that started this game of tag.
5. I just finished reading Shirley MacLaine's new book, "Sage-ing while Age-ing" and if you have a VERY OPEN mind and are interested in UFO's, it's an interesting read.
6. I was very lazy in high school, and that laziness didn't really change during my college years, so I went to grad school because I didn't want to work.  However, being a poor college student quickly lost its appeal, and I finished grad school in just one year.
7. I started my career at Circuit City as a programmer in RPG on the AS/400 - working on distribution and payroll/HR systems.  Glad to have dumped that Circuit City stock long ago!
   
8. I recently declared my aspirancy to become a Sister of Perpetual Indulgence - it's a lifetime commitment and takes at least a year to become a fully-professed sister, but they do great work.
   

There's my eight - and if there's another blogger left - watch out!  Vini, Carol, Helle, Julia, Julie, Annette, Zoe, Amrita.

I think I should point out the disclaimer on the right about veering off topic occasionally....

I've been tagged by Joe (even though it is the post below this one, you get a link anyway) as part of some kind of online pyramid scheme.... I hope it makes Jake his fortune since he is at the top of the pyramid!

8 things you may not know about me.

(1) Once upon a time, I used to have some technical skills. My first job in Oracle consulting was installing an Oracle 6 database and Financials (GL) at a health authority in Dorset.

(2) Although I am not that IT literate compared to most of the Web 2.0-enabled people I work with, I maintain the website for my kids' school. The people of Teddington obviously have simpler expectations from that there interweb thing...

(3) I have a thing for music. I have just bought a restored 1920s piano and I perform on keyboards and vocals in a folk band. I also play bass guitar very badly. I had to sell my drum kit a few years ago but I am now thinking of getting one of those electronic ones where you can practise quietly.

(4) I am also currenly obsessed with Guitar Hero 3 and Singstar, although I think the gadget euphoria of my new PS3 will wear off fairly soon.

(5) This one's not really a secret... I am a terrible driver. I crashed a car into a wall the day after I passed my driving test. I also crashed a sports car at 60mph in the rain (not on the same day). When I was working temporarily at Oracle HQ I even crashed a hire car during a particularly demanding parking manoeuvre.

(6) I was born in Romford, Essex and have endured many Essex Girl jokes in my time.

(7) I am scared of chickens. As a child on a farm camping holiday I was chased by one in the dark, and it has gone downhill from there. I might have been a vegetarian but for the death-to-all-chickens thing.

(8) I've seen David Beckham topless in the home team changing rooms at Old Trafford (the home ground for Manchester United, one of his former teams). I wasn't that impressed at the time to be honest, I was really hoping to bump into Eric Cantona.

When you read this message please send me $5 and pass the message on to 8 of your friends. Within 1 month you will make $47billion! Hmmm no, that wasn't it. But now Elise, Linda, Suzanne, Diana, Maria, Neil, Balaji and Brian - you're tagged too!

I keep hearing from customers about having the ability to enter invoices through Excel. Whenever I hear that, I used to wonder why they would need that as the current system (EBS R12) already has quick invoice entry and the regular invoice workbench for invoice data entry. Also if the customer really wanted to go electronic they could go with the XML approach of loading invoices. In my personal opinion going the XML way makes more sense as it eliminates the need to enter invoices manually into the system. But I guess we are still living in the paper dominated world where all the documents are still sent through paper.
   Coming back to the excel interface I am not really sure about the true benefits of this approach. This is not to say that there is none, as there are a few that I can think of. Ease of data entry, ability to enter invoices faster and no need to train users as most of the computer users are already familiar with the excel tool. But if I were to go a step further then I see some issues here. Notably that there could be errors during data entry as the excel template might not have all the online validations that are normally found if the user were to enter these invoices using the quick invoice/invoice workbench pages that is currently available in EBS R12. Because of data entry issues, the user might be forced to go back into the ERP system to fix the data entry errors. To me, this looks like doing double work.
    Currently in EBS R12, we have the quick invoice entry (which also has very minimal validations) where the user can enter both PO matched invoices as well as non-PO invoice. Following this the user has to run the invoice import program which will create the actual invoice. If the user does not like this approach they can always enter the invoice directly using the invoice workbench.
    Since customers are looking for the excel based invoice entry, I have a few questions that I would like to ask.

     1. Is this primarily used by internal AP dept? Or is the excel template given to the suppliers asking them to enter their invoices in excel?
    2. If this is used by AP dept, then are they using it for entering non-PO invoices or are they using it to enter PO invoices.
    3. Currently on the quick invoice page there are very minimal validations. Since excel is going to have very minimal validations, what is the advantage here? Why can't the user use the quick invoice page and why do they need excel?
    4. If the AP dept is using this for entering PO matched invoices, then wouldn't it be helpful if they can enter it in quick invoice page or the regular invoice entry. Using the online pages gives you lot of flexibility in the sense that the user can pick and choose select PO's schedules etc. Given this, why would the user want to enter data in excel which does not have any validations.
    5. Also if users were to enter the data in excel and if there were some mistakes, then they would have to go back to the online component to fix the data errors. This is doing double duty as the user has to first enter the data in excel and then have to go back to the online component to fix the data errors. Wouldn't they be better off if they enter this data in the online component directly?
    6. What kind of benefit does the customer have (AP dept) if they use excel. Is it cut and paste? If so, since the invoices are not the same, how can they cut and paste? Are they doing cut and paste only under the scenario where there are multiple invoices coming from the same supplier?

   I would like to hear from users about their comments on using excel upload. Let me know.

I'm sure that nearly every company has as many internal acronyms as Oracle, but it is sometimes problematic for us because we often assume that our customers operate with the same understanding of acronyms and terminology that we do.  Even internally, we are not all on the same page when using some of these acronyms and terms.  I'm going to attempt to clarify some of these terms & acronyms, and if I get them wrong, I'm sure that I'll get some comments!

• GL -  usually pertaining to the General Ledger product.  Sometimes you'll hear "in GL" which more than likely means "not some other product" like payables, receivables, subledger accounting, or intercompany.
• SLA - subledger accounting (architecture).  In Release 12, we introduced subledger accounting, the centralized rule-based accounting engine for all subledgers.  Oddly enough, the product prefix for SLA is XLA, so you if you see references to tables and forms that are prefixed with XLA - it's SLA related.
• SOB - Set of Books, grouping of journals.  In Release 12, SOB has been renamed "Ledger", luckily it's only one word, so there's no need for an acronym.  You'll typically see SOB written, but not spoken - saying SOB makes people giggle.
• JE - typically, "journal entry"  in GL.   However, JE is the also the product prefix for the EMEA localizations, so it's helpful to know if you're talking Europe or accounting.
• COA - Chart of Accounts.  Technically speaking, COA is the set of valid combinations of values that make up your accounting flexfield.  Frequently, we hear customers speak of "a single COA" when they really mean "a single COA structure".  The difference is slight and can greatly impact a conversation.  "A single COA" implies that there is one set of valid combinations that is uses by all SOBs or ledgers.  "A single COA structure" says that all of SOBs have the same segment names, but there may be multiple valuesets for a given segment (ie- the Cost Center segment in  the US is made up of "ABC","DEF", "GHI"; whereas the Cost Center segment in the UK contains "E11","E12","E13")
• BSV - Balancing Segment Value.  The value part of this is frequently misused.  Accurately use, the BSV is the value of the segment of the combination that is qualified as the balancing segment (in the Vision instance, "01", "03","99", etc.)  However, it's often used in conversation to mean the segment name (in the Vision instance, the balancing segment name is usually "Company").
• CCID - Code Combination ID.  It never ceases to amaze me how many people use this acronym because it's a technical term, but it's usually used in a functional way. The CCID is technically, the ID of the record in the GL_CODE_COMBINATIONS table that represents a combination of values in the accounting flexfield.  For example, the account combination of "01.2500.36.C12" could be stored in the table with the ID of 384569.  Typically, people are referring to "01.2500.36.C12" not 384569 when speaking of the CCID.
• LE - Legal Entity.  This is relatively new term in Release 12 because legal entities play a more prominent role  Legal Entities are used to determine tax as well as the difference between intercompany (between LEs) and intracompany (within LE) trading and accounting. In R12, BSVs can be mapped to LE as part of the accounting setup.
• Account - depends on whom you ask.  On most of our user interfaces, "account" refers to the complete accounting flexfield ("01.2500.36.C12").  However, when defining your COA structure, one of the segments must be qualified as the Natural Account segment (possibly segment 2), and sometimes people refer to just this segment value when referring to "account" (if segment 2 is the natural account segment, then in the context of the combination "01.2500.36.C12", the term "account" would refer to just "2500").

In upcoming posts, I'll attempt to bring some deeper meaning to some of these terms and acronyms.  If there are any terms or acronyms that you'd like added or discussed, leave a comment, and I'll add them to the list.

As a relatively green Strategist for the Fusion Payments module, I've started a knowledge quest of sorts to get myself quickly up to speed on relevent topics.  In meetings with my new development team, SEPA comes up frequently.  So, I've done a little research and I thought I'd pass on a quick summary of my findings

 

What is SEPA?

SEPA stands for Single European Payments Area and it is an area in which consumers, companies and other economic actors will be able to make and receive payments in euros, whether between or within national boundaries under the same basic conditions, rights and obligations, regardless of their location.  It is comprised of:

 

• a single currency
  
• a single set of euro payment instruments - credit transfers, direct debits and card payments
  
• an efficient processing infrastructure for euro payments 
  
• a common set of technical standards
  
• a common set of business practices
  
• a harmonized legal basis

Why did SEPA come about?

Back in 2000, European political big wigs got together in Lisbon and decided the EU would be one of the world's leading knowledge-based economies by 2010 - a plan that has become known as the Lisbon Agenda. Out of this stemmed the idea to support innovation and the idea of a single market by making it easier and cheaper to move money around the EU. The European Commission decided that cross-border payments should cost no more than domestic payments and, in 2002 the European Payments Council (a group of banks) sketched plans for how this would be done. Thus the Single European Payments Area was born.

 

Stay tuned for more on:

• Why is SEPA important? 
  
• Do I care if I don't do business in Europe?

This entry is a continuation of my quest for understanding and knowledge of the hot topics in the Payments arena as a new Strategist for that module.  Please see the first part below:  A Primer on SEPA.

 

Why is SEPA important?

SEPA�s adoption means fewer charges on transactions and purchases in euros. On the consumer side of things, it could mean you'll be able to buy things on your card in another European country and pay nothing more than you would domestically. On the business side, it'll mean the same thing - moving money around should be as cheap as it is domestically. A more competitive and innovative euro retail payments market will bring with it higher service levels, more efficient products and cheaper alternatives for making payments. Banks will have to sharpen up their IT systems to replace manual processes with automatic ones in order to bring down costs � all good for corporates as well as consumers.

 

Do I care if I don�t do business in Europe?

YES!  No matter where you do business on the globe, standardization of retail payments is a goal to aspire to.  Making payments inefficiently is an avoidable drain on organizational resources. Transactions within the SEPA regime will be based upon the ISO20022 payment message � a global payment standard that will be made widely available on an �out-of the-box� basis by most (if not all) major software vendors.  You don�t have to go global to benefit from SEPA � but you can gain efficiencies and save on payment processing costs by adopting the global payment standard upon which it is based.

 

Helpful links:

SEPA Compliance (EBA)

SWIFT Community

The Road to the Single European Payments Area (Die Bank)

We get asked frequently about balancing segment values (BSVs), and we have definitely seen some cases of BSVs being...well...misused.

In short, the intention of balancing segments were to identify an entity that should produce a balance sheet or statement of financial position. According to FASB,

• Financial position, as it is reflected by the records and accounts
  from which the statement is prepared, is revealed in a presentation
  of the assets and liabilities of the entity.

• And an entity is defined as: Any legal structure used to conduct activities
  or to hold assets. Some examples of such structures are corporations,
  partnerships, limited liability companies, grantor trusts, and other
  trusts.

While this should seem pretty straightforward, the term "legal" used in the definition of entity always seems to lead to confusion.  Granted, you must produce a balance sheet for your legal entities, but many of our customers wish to produce balance sheets for sub-legal entities as well.    By sub-legal entity, I mean simply a portion of the legal entity.  This sub-legal entity could be a division, a department, a plant, or any other segment of the business.  In order to keep your accounting pristine, this sub-legal entity should always roll-up to a single legal entity.

So determining your balancing segment values is pretty simple:

I've seen some creative implementations in my time, and these implementations have definitely resulted in some creative heartaches.  The best advice that I can give is to just keep it simple and try to avoid those "if's" and "but's" that will inevitably lead you to one of those creative implementations or heartaches.