I am pleased to announce the next release in our extensive oracle related White Paper Library of:

Oracle EBS R12 Receivables Closing Period Procedures

Authored by Mohamed Nazih

Purpose of Mohamed’s Paper;

This paper will help you understand the steps, order, and reports required to close Oracle Receivables period. Proper closing each month helps minimizing year end time needed to issue financial statements.

Please feel free to drop by the White Paper library to request your copy of the White Paper today.

Remember to email Mohamed with any feedback you may have relating to this white paper or post it to this blog!

Thanks Mohamed

A question was asked by a beginner in PIM within another social networking site regarding items in Oracle EBS/PIM applications.  I thought it is a good question to put into the blog for PIM and EBS.  I hope I am correct. 

An item is ALWAYS created in a defined master organization in PIM. Though it is not coincidence that it is an Oracle EBS configured master organization. It is mandatory to define the item in a master organization.

Do not concern yourself with the Inventory module. When you create an item in PIM, it is the same item that is created in the Inventory module. When you create an item in the Inventory module’s Master Item form, that same item is fully available in the PIM html forms. They both share the same mtl_system_items_b table as well as others.

It is only when you define attribute groups that you have additional information in PIM regarding the item.

In fact, item catalog categories and item catalog groups are the same thing. But, you get more functionality in PIM regarding their usage.

Please consider PIM as a mandatory module to purchase in your next upgrade or implementation.  It has proven to be highly useful in multiple industries. 

Have a great one!

Bob 

Just a thought for anyone having difficulties or dilemna in choosing cost method in Oracle EBS (or other software systems)

I have had clients complain that average costing changes the entire way they do “cost management”.  The complaint has been that average costing is impossible for them to manage.  Simply because they say systematically, they cannot trace back to the “per unit” cost calculation that established the current system derived “per unit” average cost.

I say, “let the computer do all the work” and “let the computer report its calculations in detail back to you”.  You should be watching changes anyway.

People got to get used to faster reaction “moving average” with average costing methods.  This is as opposed to adjusting at the end of the year.  Standard costing is very slow to react.  Book value is “misrepresented” in standard costing because the computer and transaction are not adjusting the cost and value, people are.

Monitoring changes in purchasing and mfg cost is better monitored and reflected in inventory value with average cost.  But since there is no real variance account balances, the client complains that they have no “off the shelf” way of knowing when things are not right.
 

That is where bigger business intelligence monitoring takes over in average costing.  Monitoring specific events or jobs compared to historical performance in the past helps to make decisions.
 

Two things:
 

1)      Market commodity dependency on purchased material:  If price fluctuates greatly then go to average.  If customer price based on cost then go to layer costing.  If purchase price stable then stick with standard costing
2)      If manufacturing can build the same thing in a lot of different ways producing relatively the same production costs then stick with standard costing.  If mfg can build the same thing in a lot of different ways producing large fluctuation in production costs then consider average to amortize it into total inventory value or consider layer costing to tie cost to specific lots or serial numbers of the same item. 
 

But there is naturally many other things to assist in the choice….
 

Financially, standard cost causes more adjustments than average costing.  Operationally, average cost can hide increasing or decreasing trends in costs.  Layer costing requires more “tailor made” placement of cost in transactions (cost hook) but will help adjust trends. 
 

Accuracy(less to greater value representation):  Standard then Average then Layer (FIFO/LIFO)
Maintenance (less to more after go-live):  Layer then Average then Standard
Best practices and future direction (oldest to future): Standard to Average to Layer costing
Cost to implement in Oracle(least to most upfront costs):  Average to Standard to Layer costing
 

Long term trend in decreasing inventory cost: Standard
Long term inventory holding: Standard or Layer
Cost Based pricing in high competitive market: Layer
Short term trend in decreasing inventory cost: Average
Short term inventory holding: Average or Layer
 

None of these are industry specific nor industry specific best practices.  These are just guidelines used to help me and my client choose.

Just don’t make the decision solely on how your current reports are used or “That’s the way we’ve been doing it for years”. 

Hi Everyone,

Happy Friday! I am Pleased to Annouce the next release in our extensive Oracle Related White Paper Library of :

An Introduction to E-business Suite Tax

Authored by David Sparks

‘The purpose of David’s White Paper is to break down E-business Tax, and to present the simplest of cases, thus giving the basis to build more complicated scenarios. It does so by navigating through the E-Business Tax menus and configuration screens in the appropriate order giving examples of a working configuration.’

Please feel free to drop by the White Paper library to request your copy of the White Paper today.

David Thank you for taking the time to write such a detailed paper.

Remember to email David with any feedback you may have relating to this white paper or post it to this blog!

“Give a man a fish; you have fed him for today.  Teach a man to fish; and you have fed him for a lifetime”

As a consultant/contractor, it can be tempting to do as much as you can for the client on your own, making yourself appear indispensable.

However, this may not be in the long term interests of the client or yourself, especially when involved in first time Oracle e-Business implementations.

An alternative view is that you should be able to make yourself dispensable by ensuring that the client is able to be self-supporting once the project is over, the money has run out and/or you decide to move on to your next consulting challenge.

For this to work, you need to build this into your consulting approach at the outset of the project.

A feature of projects with the best outcomes is that the client assigns their best people, rather than those who they can afford to move sideways into “Special Projects”.

Typically, the client people will “buddy up” with an external consultant, perhaps on a module by module basis, resulting in a combination of business specific and Oracle product specific knowledge.

It is crucial that once the project is over, the client people are left with an enduring understanding of the workings of Oracle, instead of viewing it as a “black box”. Yes, the consultant may also leave with a better knowledge of the client’s (and their related industry) practices, but this isn’t why the client engaged you in the first place.

So how can this be done, especially given tight timeframes?

The key is to immerse the client expert in both the analysis and resultant configuration processes, even going as far as making them responsible for completing the relevant documentation (eg MD050, BR100 etc if using AIM). More importantly, for key functional configuration decisions, allow the client expert to experiment with the various options available by themselves.

A real-life example occurred for me when I was leading both the Receivables and Assets streams of a large implementation project. Fortunately the client had appointed the AR manager to the project. When we pondered how best to set up AutoAccounting (it was Release 11.0.3) to meet the complex government fund accounting requirements and the introduction of GST, we decided that it he should take full ownership for the design of this aspect.

After a session or two on the basics of AutoAccounting, he spent the necessary time experimenting with the various permutations available until the required outcomes were achieved. This exercise resulted in both a deeper and broader understanding of the end-to-end flows within AR. Once the client was live, they were totally self-supporting, because they took the time to understand the critical components of Oracle AR. They not only knew what worked and didn’t work, they knew the “hows and whys”.

Of course, as the consultant, you should always be there to provide support, guidance and review. It doesn’t matter who compiles the Configuration documents, what matters is that the client has the skills to continue, well after the project team has packed up and gone.