, , , ,

What are Business Events in Oracle Apps?

Business event is, as the term means, is simply an event that occured in business. Business is all about people taking decisions in their respective functions on the information available at that time and communicating further down the supply chain as quickly and accurately as they can: Upon order booking warehouse ships the order or based on invoice apporval payables department pays either the vendor or an employee. All these are business events in the flow of work from one department to another so that common objective is achieved at the end of the day.
Business events in workflow are no different from the above scenario. As the human actions that flow from one department to another, workflow also passes the message from source to destination so that information can be processed in the supply chain. Also business events can be raised and read accross applications and systems.
From technical point of view, just like a department which ”performs” the action that should be communicated, there is a source that “raises” the event. This event when raised is “queued” into an “agent”. Then there is an “agent listener” this picks up the queue from this agent processes it or “dequeues” it. While dequeueing, the “agent listener” processes the rule function that is attached as a ”subscription” using the information that contained in the queue message (“parameters”).
Take an example. Say a new employee joined your company. The day she reports to work, you generate an employee record for her. Say,once she is assinged an employee number, you have to communicate to payroll and systems departments (among others). This information either can be an email to both the departments or inter-office memo for each department. This memo will be picked by mail department and delivered. Once this mail is received, payroll and systems divisions use this information like employee number to complete their own work.
So if you extend this example to business events in wokflow, HR Department raises this event (creation of employee). This event will have a message to be delivered (parameters). This message will be picked up by mail department and delivered (Agent). Once delviered, respective departments receive this information (listened to the queue). This message will be delivered to an appropriate person in the department (subscriber) who will process this information (executing code or kicking a workflow off).
Nailing this down to simple diagram in technical terms, this is how it looks.

There are can be two kinds of subscriptions: Deferred or Immediate. Deferred subscriptions are those that are queued and to be processed by listener. The above example is of that kind. HR deferred the work to be processed by Payroll. On the other hand there are chances that the HR and Payroll handled by the same person. In that case there is nothing to be deferred. This is synchronous process and both the functions are performed in the same department (no need of mail delivery) or by the same person.
And subscribers can process the information in two different ways: either kick off a workflow or execute pl/sql package or java class. If the rule function controls this. Also based on the rule function (workflow vs pl/sql of Java function) appropriate queue is used. If it is pl/sql WF_DEFERRED is used and if it is Java then WF_JAVA_DEFERRED is used.

/by
, , ,

SLA functionality

A good part of SLA functionality is deriving correct account based on business rules. This functionality is called defining account derivation rules. The outcome of accounting derivation rule sometimes is an entire account (famously known as code combination) or simply a segment in the code combination. If only a segment is derived then each of the segment in the chart of accounts is weaved together just like the way it is done in workflow account generator. Take for example revenue account. Oracle gives us a default account from the transaction in AR which is generated using Auto Accounting. What we can do is, take that account and plant a specific segment, say, natural account under specific condition. Also the whole account can be replaced with a new one under specific conditions.
The difference between workflow account generator and SLA accounting derivation rules is that, the conditions under which the account or a segment derived reside in code in first one but are visible to the business users in later one. They understand the conditions under which an account is derived because it is configured in the screens and not sitting some cryptic code. Also little room for bugs, so to speak.
Usually we generate the account for either credit or debit line of a journal entry. An accounting entry, at a minimum, has a debit and credit. These are called are journal lines (a debit line and a credit line). An accounting derivation rule is for a specific journal line. Going a little further this journal entry is for a transaction. This transaction event is called event class. These two make up the heart of SLA setups.
Taking the same example of revenue account, revenue account is a journal line. Revenue is one side or one line in an accounting entry. The other usually is a receivables account (in case of AR transaction). These two together make a journal entry. And this journal entry belongs to an event class called Invoice (in case it is invoice).But if you have observed the line definitions under invoice event class you might have noticed way more than these two lines. That is because each of them is used in different ways depending on the nature of transaction.
Implementation: What is in it? What kind of work is involved?
Traditionally we have accounting in each application or a process flow is taken care of by individual specialist in that area. For example an AR specialist used to get the accounting needs implemented as per the requirement and cost management or order management specialist gets the cost accounting right. So a business process owner for accounting has to run around each of these specialists to get the accounting taken care of. Also prior to SLA the functionality provided in Oracle is rigid in some application areas and very flexible in a number of other areas. To cater to these flexible needs a number of tools were also available like Workflow account generators, Post or Pre hooks or some setups to generate accounting based on business rules.
SLA is a game changer from that perspective. We can throw away workflow accounting generator and post or pre-hooks coding. And also one specialist, who understands enterprise accounting and business needs of accounting department, can implement complete SLA solution in all applications and processes. This is new and emerging consulting role.
Implementing SLA involves writing rules to arrive at accurate accounting under specific conditions for a specific transaction event. To achieve what you need, we may need to write some coding in custom sources but in general that is far simpler than workflow. All you need to know if writing simple pl/sql code.
But for a SLA specialist the challenge is in understanding transactions and event class is mapping to these transactions. Sometimes it is self explanatory. An event class like Sales Order issue in Cost Management or Invoice in AR tells you that these are for COGS and Revenue respectively. But not all are so straight forward. But if you have knowledge about the transactions performed in each application areas and some technical background it is pretty easy to get there.

Apart from generating accounts there are a lot of other features in SLA.

/by
, , , ,

Concept behind Subledger Accounting

Before going into any detail, let me take you into accounting world for a brief moment. Fundamentally accounting is based on two methods : Cash Basis or Accrual Basis.
Accrual Basis Accounting
Under the accrual basis accounting, revenues and expenses are recognized as follows:
AR:

  •  Revenue recognition: Revenue is recognized when both of the following conditions are met:
        a. Revenue is earned.
        b. Revenue is realized or realizable.
  •  Revenue is earned when products are delivered or services are provided.
  • Realized means cash is received.
  • Realizable means it is reasonable to expect that cash will be received in the future.

AP:

  • Expense recognition: Expense is recognized in the period in which related revenue is recognized (Matching Principle).

Cash Basis Accounting
Under the cash basis accounting, revenues and expenses are recognized as follows:
AR:

  • Revenue recognition: Revenue is recognized when cash is received.

AP:

  • Expense recognition: Expense is recognized when cash is paid.

 Timing differences in recognizing revenues and expenses:

  1. Accrued Revenue: Revenue is recognized before cash is received.
  2. Accrued Expense: Expense is recognized before cash is paid.
  3. Deferred Revenue: Revenue is recognized after cash is received.
  4. Deferred Expense: Expense is recognized after cash is paid.

                 Options in 11i                            To                                Options in 12
Till 11i the only way we represent this accounting method is by choosing accounting method in Payables Options in AP and System Options in AR. But in R12 you can see in that these options are gone from the system options of AP and AR. That is where subledger accounting comes in.
Part of the global release concept in R12, accounting methods have to be much more flexible and generation of accounting entries should be configurable.
As we know accounting is the end product of transctions and financial statements are end products of accounting. Also there is a need to seperate transaction from accounting. An accounting clerk who creates an invoice has nothing to do what accounting is behind that transaction. It is the duty of the management to decide accounting behind this transaction. 
Subledger Accounting is taking us in that direction.
Purpose of Subledger Accounting
The end product of Subledger Accounting Setups is a Subledger Accounting Method that can be assigned to one or more ledgers in GL. All accounting in different subledger applications is subject to the rules defined in this accounting method.
In 11i, as mentioned earlier, the only way to choose accounting method we chose is AR and AP system options setup (Cash Vs Accrual). We used start in GL setting up the Set of books and then define the organization information like Legal Entity and Operating units and so on. And then define these accounting methods for each operating unit. As you can see operations and accounting are so closely meshed with each other. But in R12 it is not the same. In this release it is now configurable in Subledger Accounting setups taking this away from system options of individual products.
Demystifying subledger accounting setups
Out of the box, Oracle seeds accounting rules for all applications. If you are satisfied with the Oracle’s seeded rules, there is no need to change any setup and you can use those existing rules (Accounting Method for Accrual is Standard Accrual and for Cash is Standard Cash). This screenshot here shows you the difference between the Accrual Basis of accounting and Cash Basis of Accounting. As you can see here, per rules, there is no accounting created when invoice is created under cash basis (no revenue is recognized until cash is received) but accounting is created when cash is realized. Invoice is accounted as soon it is completed under Accrual Method. This is configurable here where as in 11i we did not have a choice!.
If you choose this accounting method, accounting works exactly the way it works in previous releases.
Subledger Accounting as a gatekeeper of Reconciliation
       R11i Transfer to GL                                                                   R12 Transfer to GL
Starting R12 all accounting entries are generated and passed through subledger accounting application instead of directly going to GL. Hence reconciliation is already done between source to Subledger Accounting and Subledger Accounting to GL, reducing huge amount of time spent on reconciliation. Since these entries have to flow through the subledger accounting application, there is a need to map the source application accounting entries to subledger accounting. That is key for the setups.
Mapping a transaction to Subledger Accounting Setup
                                        AR Invoice Accounting
Let us take a simple example. Whenever you create an AR Invoice following accounting takes place. 
                             
                             Invoice Accounting in AR
Taking a step back and thinking through, this transaction is happening in AR for the Invoice Creation event….                                            
                                            Subledger Accounting Setup Model
Now we map the source (AR Invoices) to Subledger Accounting as shown here. So to conclude
Journal Line Types are nothing but accounting line types (Receivable or Revenue).
Event Classes identify a transaction type (Invoice Vs Credit Memo).
These two are assembled using Accounting Derivation Rules and Sources.
All these together make up Application Accounting Definition for Receivables.
Different Application Accounting Definitions together make up a Subledger Accounting Method.
This method can be attached to one or more Ledgers.

/by
, , , , , ,

WIP completion and Asset Tracking

Back in 2009, I needed WIP completion transaction also be part of the Asset Creation process for depreciable items in Asset Tracking. The base was either R12.0.4 or R12.0.6, i don’t remember. But traditionally, for depreciable items,  following transactions are supported to create an asset in FA while the asset is still in Inventory.

  1. Miscellaneous Receipt
  2. Account Alias Receipt
  3. Account Receipt
  4. PO Receipt into Inventory
  5. PO Receipt into Projects
  6. Physical Inventory (Receipts)
  7. Cycle Counting (Receipts)

But there are companies that manuafacture products and they want to track them in FA. They typically get into inventory with WIP completion transaction. As you can see this transaction is not in the list above.
Recently, to my surprise, I found this patch 7489949 (which was released in 2008) that includes WIP completion also into supported transactions for asset creation. To add to my surprise, support had no clue when they were asked for solution at that time. Of course we came a long way.
BTW, it is included in base release of R12.1.1.

/by
, , , , ,

Creating Manual Journal Entries from Sub ledger Accounting (SLA)

One of many cool features in SLA is creating manual journal entries. Many times we have a need to pass manual entries to reverse the entries happened a source transaction because the account is wrong or date is wrong or even the value is wrong. All sub ledgers give you a way to reverse the transaction and hence reverse the associated accounting entry. But sometimes you may run out of time and luck and resort to manual entries in GL. Once we are GL to enter manual entries for transactions that pertain to sub ledger, we lose an opportunity to reconcile as we do not have primary references for which we have created this accounting entry for. If we have any reports that are based on SLA tables the reconciliation becomes harder as we cannot link anything that happened in the GL with the SLA. After all, the purpose of SLA is to eliminate this risk of reconciliation with GL.
Also, I guess, Oracle Support uses this route (manual journal entries) to fix any entries that were corrupted in the original transaction.
While entering these manual entries we can capture original transaction attributes using supporting references feature where you can capture attributes like asset_id if it is Assets related entry, transaction_id if it is related to Inventory, invoice_Id for AP and customer_trx_id or cash_receipt_id if it is AR invoice or cash respectively, These give meaning to the manual journal entries.
Process comes in three steps: 
Creating entries, saving them as incomplete entries with in SLA to be posted later and finally completing this so that this will automatically transfer to GL, journal Import and Post them as needed. To create manual entries you need to assign a sub-function SLA: Create Subledger Journal Entry to the menu. It will appear as a button in the view journal entries page.
The same can be achieved with an API XLA_JOURNAL_ENTRIES_PUB_PKG. Also this is immensely useful if you want to create accounting entries related to transactions in legacy or related systems. You can capture the supporting references related to the related system for reconciliation purpose.
The best part of using this API is that, we do not have to separately code for Journal Import and Posting (with complete journals parameter to complete, transfer and post). The value you pass to this parameter takes care of that.
Sources:Oracle Financial Accounting Hub Implementation Guide (Chapter 12 on Manual Sub ledger Journal Entries API) and Oracle Subledger Accounting Implementation Guide (Chapter 6 Sub ledger Journal Entries).
/by