Oracle Project Costing - Cost Rate concepts

Cost Rates are defined in different places in Project Accounting.  Let us see which one is relevant for distributing the cost in project costing?
One of the common errors that you can see while running the cost distribution program is 'Missing Cost Rates'. As usual I am going to put this in a question and answer format

 

Question:  For what purpose do we need cost rates in the system ?

 

Answer:  We need cost rates for the following ( only the following):

• Usage Cost
• Labor cost

Question: Where do we define the cost rates in project costing for usage cost?

 

Answer: The cost rates for usage cost is defined only in the following places:

• Expenditure Types - In the expenditure types we can define the cost rates. Each Expenditure type can have a cost rate defined. You can have different cost rates for different Operating Unit and for the same expenditure type. When you run the PRC: Distribute Usage and Miscellaneous Costs, the program will pick up the cost rate mentioned at the expenditure type level, for the cost transaction. 
• Non-Labor Resource - If you need a rate at a resource level and want the system not to pick the cost rate mentioned in the expenditure types then you can set the cost rate overrides for the non-labor resource in the Non-Labor Resource setup screen.

 

Question: I have seen non-labor rates mentioned in the rate schedule, is it not also used for calculating the usage cost?

 

Answer: No, the rate schedule for non-labor is not used for cost purpose for usage cost calculation. It is used only for billing purpose.

 

Question:  Where do we define the cost rates in project costing for Labor cost?

 

Answer: Labor cost rates are picked from the rate schedules. It could be the rate schedule mentioned at the employee level or at the job level.

 

Question: When there are multiple rate schedule defined for labor, how does the system understand, from which rate schedule to pick the rate?

 

Answer: Under the Organization Labor Costing Rules ( Setup>> Costing>> Labor>> Organization Labor Costing Rules ), we mention which Cost Rate schedule should the system pick the rates. We can have different rate schedules assigned for transactions with different Expenditure Organization.

 

Question: Is rate schedule the only place where the rates are picked from for labor cost?

 

Answer: If we need a different rate for an employee ( relevant, if the rate schedule that is configured to pick up is a job rate schedule), then we can define labor  costing overrides ( Setup >> Costing>> Labor >>  Labor Costing Override) at the employee level. This will override the rates mentioned in the rate schedule.

 

Oracle Subledger Accounting Method - Concept Explained

This writeup is intended to help clarify the concept of Subledger Accounting Method introduced in R12. We will also understand the significance of the 4th C assignment to the Ledger. Let us also look at some concepts on primary ledger, secondary ledger and the reporting currency, how they all related to the subledger accounting method.

I would like to discuss the above in a question and answer format :

1. What is the significance of the 4th C in a ledger and why is it needed?

4th C is nothing but the new subledger accounting method introduced in R12. By assigning 4th C to a ledger, we are telling the system what accounting method should be used for the specific ledger. We would really want our system to create accounting in the manner we want. We can have our own logic as per the business requirement for debit and credit entries. For example, if my revenue account to be credited should be based on the DFF defined in the sales order, then I can define that rule in my accounting method. In 11i we did have option only to pick our account from either sales representatives or standard lines or customer site or transaction types. But here, we can have each of our accounting segment values picked based on any field from any forms in any related module. We can define all these rule and give a name to the rules, which is nothing but the subledger accounting method. The name can be any thing like US GAAP or IAS or any other name of your choice. What is more relevant here is your accounting logic that goes behind it.

Once we give a name to our rules, we need to ask our ledger to follow only our rules for accounting. That is exactly what we do, by assigning the subledger accounting method to our ledger which is the 4 th C.

2. What is the link between the sub-ledger accounting definition and the ledger

 

The link between the sub-ledger accounting definition and the ledger is established by using the 4th C in the ledger definition ( Accounting Convention / SLA Method). 

3. Is the 4th C mandatory for a ledger. If it is not set, what is the impact?

4th C is not mandatory. If you just plan to use only General Ledger module, then you can leave the 4th C blank.   4th C becomes mandatory if you are using subledger modules like AP, AR, INV etc..

4. If my intention is to continue the accounting logics available in the subledger modules and not configure SLA for accounting, do I still need to assign the SLA method to my ledger?

Yes. If you are planning to use the accounting logics available in the subledger modules ( similiar to 11i), you need not create your own SLA method. Instead you can pick the appropriate standard SLA method for assigning to the ledger.  For Example, the SLA method, standard accrual uses the account segments that gets generated by the accounting logics in the subledger module. ( Like the account that gets created in the account distribution screen for an Invoice).
Below are some of the standard accounting methods:

• Standard Accrual
• Standard Cash
• China Standard Accrual
• Encumbrance Accrual
• Encumbrance Cash
• United States Federal

5. Why will you ever want to have a secondary ledger and what purpose?

We use secondary ledgers when any of the 4Cs are different in your accounting representation except currency.
For example, You want to use US COA for local reporting but would like to use different COA (Like France COA) for corporate reporting, then we should add secondary ledger to accommodate this requirement. All account balances would get converted to the secondary ledger as well.

6. What are the scenarios where we will have a reporting currency Vs using the translation feature of GL?
 
Reporting currencies are intended for use by organizations that must regularly and routinely support statutory and legal reporting of both transactions/journals and General Ledger account balances in multiple currencies, other than the ledger currency. If you only need to report account balances in a currency other than your ledger currency, you can use General Ledger translation.

We will use translation instead of setting the currency as a reporting currency, if the intention of the translation is to see period end/quarter end/year end balances in different currency. If we need to have immediate reports as soon as the transaction is done in a different currency, then we use reporting currency.






 

Is process re-engineering required before you start an ERP Implementation?

In many of my ERP implementation projects, I have seen and even involved in doing a process re-engineering prior to starting an ERP implementation. Many companies do this basically to set right the existing process or lean out the current complicated process. The idea being not to bring the current redundant steps or procedures to the new process that would involve ERP.  This do sound very reasonable thing to do and the concept quickly caught as a best practice as a pre-implementation activity. Re-engineering experts were hired to assist them in identifying their existing process bottlenecks, and provide them with a value stream maps that would remove all these reduntant steps and bring in process improvement.

While all these sounds very right, I am personally not convinced with this approach as a pre-implemenation activity and here are the reasons why..

Future Process Maps

What ever may be the existing process, during the ERP implementation, the consultants comeup with the future process documents which is not the same as the leaned or improved process.  The ERP consultants still have to discussion with the business users to understand their existing process and chart out the future process taking into consideration the ERP application functionalities and process. Since ultimately the users will have to work in the ERP application, doing a re-engineering activity without considering the process steps within the ERP application does not make any meaning. One of the prime flou that I have seen is the customers using pure re-engineering resources who do not have knowledge of the ERP system that they are planning to implement. They conduct workout sessions and comeup with value stream maps in isolations of the ERP application. Lot of time and energy is spent on this activity which will anyway again be re-looked when the ERP implementations gets underway. So this raises the following questions

• Why not involve the ERP consultants ( may be along with the re-engineering consultants), in the entire activity of coming up with the leaned or improved process?
• Instead of concentrating too much on the ASIS process, why can't they look at what they want, the future process. ( which will automatically be the improved process from the existing )?
• Why spend too much money and energy on a pre-implementation, re-engineering activity? Why can't the re-engineering activity be clubbed with the future process design phase of the ERP implementation itself ?

Where Re-engineering can be useful ?

Having been little negative on the ERP pre-implementation re-engineering activity, I would like to also mention some specific areas where value stream maps will be useful.

• Where the business is aware of a complicated process which they need to streamline
• Where the busniess is aware of reduntant activities that they think should be removed
• Where there is a process bottleneck that can be avoided.

Re-engineering can be specifically targeted on the above which are non-ERP related and which may be needed even after ERP is implemented. For example, if the goods are delivered to the customer site, but it takes 2-3 days to confirm the delivery of the goods to the billing team ( due to the remote customer locations) and thus resulting in delay in revenue recognition or billing. The process step could be that the truck driver faxes the delivery note with the customer signature to the billing team after the goods are delivered. The availability of fax facility may not be near the remote customer location and thus the delay. The re-engineered process may be to provide the truck driver with an handheld device that sends immediate information of the delivery directly to the billing team thus saving the valuable 2-3 days of delay in revenue recognition or billing to the customer.

In the above scenario, there was a problem and the process is now improved (re-engineered) by issuing the hand-held device to the truck driver. The solution would be the same whether ERP is implemented or not.  Such scenarios really qualifies to be a candidate for re-engineering prior to ERP implementation.

Conclusion

Doing general re-engineering activity prior to starting any ERP implementation is more a waste of time and money, since the processes will anyway be re-looked to suite the ERP oriented steps and procedures. Any process that is independent and will not change with ERP system that need to be re-engineered qualifies as a candidate to be looked into pre-implementation.

I would appreciate your views and feedbacks on the topic.

What it takes to become a successful ERP Consultant?

I have been teaching Oracle Applications for quite sometime now and have seen students with varied flavours. Not all have become successful in ERP career. So I thought to address the question on what it would really take to become a successful ERP consultant.

Career in ERP Consulting is quite interesting and rewarding as well. There are lot of people, both experienced and fresh, trying to get into a career in ERP.

Some reasons why people try to get into ERP career

• They are not satisfied with the current job or just need a change and wanting to explore the oppertunities that looks more greener.
• ERP is being implemented in the office that they are working currently . They feel that learning ERP will make them more successful in their current job.
• Students who are fresh from college and are looking to learn ERP application and make a career out of it.
• Passion to be a consultant and meeting people to give solution.
• By chance; they were at the right place at the right time and got into an ERP career.

Who becomes successful?

I have seen people making successful career in ERP who are belonging to each of the above categories.  But unfortunately, I have also seen people failing. So what it takes to be successful ? Is ERP applications so difficult to master? Is the application really a monster as perceived to be from outside?

I would say that your effort to figure out what is in application is just 30 percent of your effort. Remaining 70% of your efforts is to understand the concepts and the business processes. So it is very obvious where people fail in an ERP career. Understanding the business language and translating the business requirements into a well defined process(70%) and mapping the same to the ERP application (30%), is the work of an ERP consultant.

To be very honest for the last 5 years of my ERP career, I was more on the 70% bracket and was aware of 10% of the remaining 30%. I used to work with my customers to define their process and even help them re-engineer their exiting processes. My customers used to love me for the solutions that I provided in Oracle ERP. This was not because I was an expert in Oracle ERP, but it was because of my clear understanding of their business processes. If a consultant comes out of a process discussion meeting, by summarizing his understanding of the customers business process correctly, it means he has sealed his position with his customer. If I have to break the 30% further, I would say 10% goes to your knowledge of what can be done and what cannot be done in ERP ( on specific module). Remaining 20% is the details of the module. If you are very good at the first 70% and 10% of the remaining, you would be surely successful in the career.

As a trainer in ERP, I tell all my students to go to 5000 feet level or even 10000 feet level to understand the concept or the process. It is a must for all the consultant to go to this level and look at the broader picture before working on a solution in ERP.  You really don't need to be at a ground level, leave that job to consultants working for you or alternatively, you can easily open the application and figure out the configuration or transactions within the ERP application.  

So what it takes be part of the failure team in the ERP career?

• People who can not demonstrate their expertise on the first 70%.
• People really working very hard, but are not ready to come out of the reamining 30% bracket.
• People who love to work at the ground level and not ready to take a flight to go to the 5000 feet or 10000 feet level.

There are other below mentioned optional requirements that would help in making a successful ERP consultant, but I would not consider them a must for those who are in the 70% + 10% bracket.

• Communication Skills
• Work experience & subject matter expertise ( though people in 70% bracket will surely will be an SME)
• Excel knowledge
• inter-personnel skill
• Hard Work
• Ready to handle pressure

As an interviewer, I would always test my candidates at 5000 feet level when it comes to drilling them on ERP application. My concentration would always be more on the 70% bracket.

As a person exploring to becoming an ERP consultant, judge yourself where you stand. If you are good at the first 70%, then do not hesitate, you will surely become successful. Remember 'Figuring out what is in an ERP application is the most simple task and hardly takes anytime'.