The following presentation was done by me at the Florida SunCollaborate Conference in Jun 2015. This presentation will give you a good overview of the Fusion Accounting Hub Reporting Cloud Service. If you thought co-existence (Using EBS and Fusion together) was only a marketing gimmick, go ahead and read this. This is one of the finest examples for co-existence between EBS and Fusion.

In this article we will see how the document approval hierarchy is setup and how it works in Oracle Purchasing. Any document (Purchase Order, Requisition etc.) we create in Oracle Purchasing needs to be approved by the proper authority. The approval hierarchy setup determines how the document will be routed to different approvers.

In Oracle Purchasing, we have three methods to route documents for approval

Approval Hierarchy Method: This method uses the Position hierarchy for approvals

In this article, I will only discuss the first two methods since they can be setup using Oracle Purchasing and HR. I will cover AME in another article.

Before we discuss the different approval methods, let us understand the concepts of Jobs and Positions since we need to setup jobs and/or positions depending on the type of approval method we select.

Job: Within an organization, we have generic roles like Manager, Director, and Consultant etc. These roles are referred to as Jobs within Oracle HR

Positions: Positions are different instances of the job within an organization. If ‘Manager’ is defined as a Job, we can have ‘Marketing Manager’, ‘Production Manager’ etc. defined as Positions.

Before we start using the Jobs and Positions, we have to define the segments for the Job and position names and their valid values using the Key Flexfields Job Name Key Flexfield and Position Name Key Flexfield respectively.

It was almost 2 years ago when I first saw and used Fusion Financials in a training conducted by Oracle. To be honest, the first impression was a mixed one. Having worked on EBS since the character based version, Fusion financials didn’t really click for me. There was way too much information on each page, the fonts were so small that I could hardly read unless I zoomed by browser to 125%, the navigation looked clumsy and I was completely lost. I wondered if this was the flagship product that Oracle was so passionate about after acquiring PeopleSoft and Siebel and what not. As a result, I came out of that training with very little liking for the product. A year passed by and I did not touch the product at all. It was only when I started preparing for the Fusion Certification (Yes, I am Fusion Certified Implementation Specialist in GL, AR and AP), I started doing some hands on again. And this time around my opinion about the product was completely different. I started liking the product and enjoyed working on it. Continue reading

One of the fundamental controls in Payables is the PO match. This simply means that the invoice you enter in the application is matched to the Purchase Order. If the match is not successful, the invoice is kept On-hold. On-Hold invoices cannot be paid. The hold has to be resolved before you can pay the Invoice. The PO Match functionality ensures you only record and pay invoices that are eligible for payment. It is a very simple & powerful feature that prevents your organization from paying incorrect & fraudulent invoices.

Now that we understand why we perform a PO match, let’s look at the different methods of PO Match. Depending on your business requirement, you would perform a two-way, three-way or four-way matching.

Two-Way Match: In a two way match, you compare two attributes from your invoice with the Purchase Order. The invoices is considered to be successfully matched (matched within tolerances) when

The Quantity Billed (on the Invoice) is less than or equal to the Quantity Ordered (on the Purchase order)

The Invoice Price is less than or equal to the Purchase order price.

Three-Way Match: In a three-way match, in addition to the two match conditions mentioned above, you also check the quantity received. So the three conditions that are checked are

The Quantity Billed (on the Invoice) is less than or equal to the Quantity Ordered (on the Purchase order)

The Invoice Price is less than or equal to the Purchase order price.

The Quantity Billed (on the Invoice) is less than or equal to the Quantity Received against the Purchase Order

Four-Way Match: In a four-way match, you add one more match condition to the three-way match. Not only do you check the quantity received, but you also check the quantity accepted. All the four conditions that are checked in the four-way match are

The Quantity Billed (on the Invoice) is less than or equal to the Quantity Ordered (on the Purchase order)

The Invoice Price is less than or equal to the Purchase order price.

The Quantity Billed (on the Invoice) is less than or equal to the Quantity Received against the Purchase Order

The Quantity Billed (on the Invoice) is less than or equal to the Quantity Accepted against the Purchase Order

In a tabular format, the match approval level options can be represented as follows

Invoice

Purchase Order

Two-Way

Invoice Price

PO Price

Invoice Quantity

Quantity Ordered

Three-Way

Invoice Price

PO Price

Invoice Quantity

Quantity Ordered

Quantity Received

Four-Way

Invoice Price

PO Price

Invoice Quantity

Quantity Ordered

Quantity Received

Quantity Accepted

Most organizations opt for a three way match. This also ensures that the quantity is received in the system before an Invoice is created and also helps ensures that the Open PO information is up-to date.

The quantity and price tolerances set up in your system also plays a major role in determining if it is a match or if the invoice should be put on hold. Note that the match has to be within the tolerances. For example if the ordered quantity is 100 units, tolerance is 5% and if you invoice 103 units, the system will accept it as a match because it is within the tolerance level.

Where to setup the PO-Matching option?

You setup the match approval levels in the

Purchasing Options

Supplier Level

Supplier Site Level

Purchase Order Shipment level

Purchase Order shipment level takes precedence over Supplier Site Level which takes precedence over Supplier level and so on.

The following presentation on Financial Accounting Hub was done by me at the Oracle Open World 2011. Though the title of the presentation was “Oracle Financials Accounting Hub in the Banking Industry”, the content of this presentation is applicable across all industries.

And, just to make sure there is no confusion, I am talking about the R12 Financial Accounting Hub and not the Fusion Accounting Hub.

In any global rollout one of the most important and fundamental aspect to consider is the organization structure. Often Organizations realize that they are not able to utilize the complete potential of the application just because they undermined the value of an effective Organization structure. Depending on how you model your organization within Oracle Applications, you will or will not be able to use some of the important functionalities. In this paper we will discuss the various components of the Organization Structure and their Implementation considerations. The objective of this paper is to

Discuss various Organization Structure design considerations

Provide guidelines on how to go about designing an effective Organization structure

Highlight the Oracle Standard functionalities that are dependent on the Organization Structure

Before we get into the details of the design considerations, let’s question ourselves on what exactly do we mean by an Effective Organization structure? How do we define Effective? Is there any standard organization template (effective template) that ALL organizations can use? Does an organization structure that has worked well for another company in the same Industry be an effective organization structure for my company as well? The answer is probably not. Something that is effective for one organization may not be effective for another organization because each organization has its own business model and different set of requirements. Since there is no single template as such for an effective structure, let’s have a look at the various components and discuss them in detail…

I have seen a lot of people getting confused with the concept of Revenue Recognition. I have also seen some people who very well understand how Revenue Recognition works in Oracle Receivables (in technical terms), but do not clearly understand why it is done and what business objective it serves. Here is my attempt to explain the concept of Revenue Recognition. Hope it helps.

Well, there is no better place to check the Profile Options using the Profile Options Form in System Administrator responsibility. But at times, you either do not have System Administrator responsibility or you need to check and compare profile options for more than one profile or more than one responsibility at the same time. The following queries are very useful in those scenarios…