Monday Mar 09, 2015

Mandatory Post Patch Required for Fixed Assets Feb 2015 RPC

UPDATE 3/23/2015: Fixed Assets Development has now combined the two patches (the former RPC and the mandatory post-RPC) into one patch. They have re-released the Feb 2015 FA RPC under this new, combined patch.  The new RPC patch number is 20687418:R12.FA.B.

IMPORTANT UPDATE 3/13/2015: Fixed Assets Development will be combining these two patches (the RPC and the mandatory post-RPC) into one patch. They will re-release the Feb 2015 FA RPC under this new patch number. Watch this blog for the announcement of that new RPC patch number, when released. Thanks!

There is now a mandatory post-RPC patch (Patch 20530852 - Do Not Allow Changes To Other Financial Details Along With Depreciate Flag) for Fixed Assets that has to be applied after the Fixed Assets Feb 2015 RPC.  Development discovered an issue due to the fix made in 19933377:R12.FA.B, which has now been obsoleted, but was included in the RPC.  The issue in that bug was certain valid transactions were not allowed to go through.  However, after the fix, transactions that should be prevented also got through.  These transactions will cause data corruption in the product.  The issue typically occurs when customers change multiple fields when performing an adjustment such as depreciate flag and cost, but this could be any combination of multiple changes during a single adjustment transaction.

The Readme for the RPC - R12.1: Fixed Assets Recommended Patch Collection, Feb 2015  (Doc ID 1983884.1) has been updated to reflect this mandatory patch.  If you have downloaded the Fixed Assets Feb RPC Patch 20183189, please also download, test and apply the post-requisite Patch 20530852.

Thursday Jan 22, 2015

Obtaining Bonus Depreciation Methods for Oracle Fixed Assets

Are you looking for bonus depreciation methods for Release 12?  These could be depreciation methods used for the Jobs and Growth Tax Relief Reconciliation Act of 2003 or for the American Jobs Creation Act of 2004

Bonus depreciation methods are generally made available via a patch after the enactment of new laws.  In R12, bonus depreciation methods were made available for R12.0 (R12.FA.A) via Patch 6511705:R12.FA.A.  These methods were made available for R12.1 (R12.FA.B) via Patch 6511705:R12.FA.B.

As R12.2 was released well after the enactment of these laws, a later patch was created for delivery of these bonus depreciation methods.  For R12.2 (R12.FA.C), apply Patch 20012197:R12.FA.C.

 For reference, please review the documents:

  • R12 and R12.1 Seeded 30% 50% Bonus Depreciation Methods Missing In New Install (Doc ID 561517.1) and 
  • How To Obtain The 30%, 50% and 100% Bonus Depreciation Methods For Release 12.2.3 Of Oracle Assets? (Doc ID 1955574.1).

Wednesday Dec 17, 2014

An Insight Into Asset Impairment

Why would you have an asset impairment? 

An asset impairment is a situation in which the usefulness of an asset suddenly declines, making it so expensive to maintain that it can no longer be expected that it will pay for itself through future cash flows.  A company can choose to maintain the asset on its books but write down the value to more accurately reflect its value, or it can list the asset for sale and dispose of it.  Once an asset is impaired, it cannot be recovered.  Therefore, companies should test assets before placing them in this category.

IAS 36 Impairment of Assets seeks to ensure that an entity's assets are not carried at more than their recoverable amount (i.e. the higher of fair value less costs of disposal and value in use).  With the exception of goodwill and certain intangible assets for which an annual impairment test is required, entities are required to conduct impairment tests where there is an indication of impairment of an asset.  The test may be conducted at the asset level or for a 'cash-generating unit.'

What is an impairment?

If the recoverable amount of an asset is less than the asset’s carrying amount:
•  The asset is impaired
•  The asset’s carrying amount should be reduced to the recoverable amount
What is the recoverable amount of an asset?

The recoverable amount of an asset is the greater of:

1.  The net selling price of the asset or
2.  The asset’s value in use

An example:

   Asset A  Asset B
 Cost  1000  1000
 Accumulated Reserve  400  400
 Carrying Amount  600  600
 Recoverable Amount  900  400
   Asset not impaired

 Asset is impaired - reduce the carrying amount

 When does an asset need to be impaired?

There are several circumstances under which an asset can become impaired. 

There can be external sources such as:

•  Market value declines
•  Negative changes in technology, markets, economy, or laws
•  Increases in market interest rates

Or internal sources:

•  Obsolescence or physical damage
•  Asset is idle, part of a restructuring or held for disposal
•  Poorer economic performance than expected

Which assets can be impaired?

IAS 36 applies to:

•  Land
•  Buildings
•  Machinery and equipment
•  Investment property carried at cost
•  Intangible assets
•  Goodwill
•  Assets carried at revalued amounts under IAS 16 and IAS 38

How does impairment work in Oracle Assets?

These are the processes for creating, posting and managing asset impairments in Oracle Assets:

•  Assigning Cash-Generating Units to Assets (optional)
•  Entering and Uploading Asset Impairments
•  Updating Asset Impairments
•  Reviewing Asset Impairment Reports
•  Posting Asset Impairments
•  Viewing Asset Impairments
•  Rolling Back Asset Impairments
•  Deleting Asset Impairments

For details on each of the above steps, reference the Impairments White Paper in Doc ID 461834.1.

With credit to Vaishali Karanth, Oracle Assets

Monday Nov 17, 2014

How FA and GL Calendars Work Together in R12 Versus R11i

Both FA and GL have calendar setups.  How do these setups work together?  In R11i, Assets maps the calendar period to GL using an exact match of period name.  If your GL period is SEP-14 for September 2014 (as an example), then your FA September 2014 period has to be called SEP-14 as well.  Any variance, even Sep-14 rather than SEP-14, will cause the posting from Assets to GL to fail.  Then you have to log a Service Request (SR) to get that data mismatch fixed.calendar

One data mismatch you don’t have to worry about in 11i, though, is if you have set the actual period of September 2014 to have different dates in FA and GL.  For example, say your FA September 2014 period runs from 01-Sep-2014 to 30-Sep-2014, but in GL it runs from 31-Aug-2014 to 27-Sep-2014.  Since FA doesn’t check those dates, there is no issue posting depreciation amounts dated in FA on 30-Sep-2014 into the GL September period.  As long as the period names are the same, the dates don’t matter.

Now you upgrade to R12.  Assets no longer maps by period name.  In fact, it does not control the selection of the GL period at all.  SubLedger Accounting (SLA) does.  Now it no longer matters if the period names are the same or not, but the calendars matter a lot. 

Take this example:

1.  You run depreciation on September 30th.  Assets creates the rows in the depreciation tables and also inserts a row in xla_events with an event_date of September 30th.  That row is in U/U (Unprocessed / Unposted) status.
2.  You then run Create Accounting.  It picks up that row in xla_events with the September 30th event_date and it maps that date to the GL calendar.  It finds that September 30th is in the October period in GL, and it then sets the field xla_ae_headers.period_name to OCT-14.
3.  You review your postings in GL after Create Accounting has completed, and you find September’s depreciation in October’s period.

This is why it is highly recommended that you consider aligning your FA and GL calendars in R12.  

Here are the basic rules you will encounter for Assets' choice of event_date:

a.  If the event is added in period A and has a DPIS or other effective date of earlier (ex:  a backdated addition or backdated retirement), the event_date will be the first day of the open period.
b.  If the event has an effective date within the period, that date is normally used.  For example, an asset added in September with a DPIS of September 10th will have an event_date of September 10th for the addition’s accounting.
c.  Depreciation works a bit differently since it doesn’t really have an effective “date” so much as a period.  You will find:

  • If you run depreciation on a sysdate later than the last day of the period, you will get the last day of the period as the event_date.
  • If you run depreciation on a sysdate that falls within the period, you will get the sysdate as the event_date.
  • If you run depreciation before the first day of the period, you will get the first day of the period as the event_date.  That scenario is normally only encountered in testing, as when you want to test closing and close a number of periods so that the open period is now sometime in the future when compared to sysdate.

This is why we recommend you take steps to synch up your FA to GL calendars if you have not been running the same dates in 11i, as part of your upgrade to R12.  It is not required, but it does normally reduce the heartburn associated with when and how things post from FA.  

If you do synch up those periods, are there any implications?  In most cases, there is only the pain of the one-time setup work (see below).  However, you do need to think this over if you use Divide by Days, and/or Daily Prorate Conventions, as it will move some depreciation from one period to another.  Straight Line with Even Distribution won’t do that, as it allocates annual depreciation by period regardless of the dates of the period.  Depending on your setup, you could see some depreciation changes periods.  Over the life of the asset, depreciation will still take the full amount, and normally the annual amount is the same as well.  However, some customers using Divide by Days might see the amounts distributed within a year will be slightly different from period to period than they were in 11i.

How do you actually synch up those calendars?  The critical limitation is that you can only modify periods that are not open.  You must retain whatever your current depreciation period is and whatever your current prorate convention periods are.  Thus, the first recommendation is, if possible, make the changes in 11i before you upgrade.  This is because 11i is indifferent to the dates and, since you can’t modify the open periods, you don’t want to find you have mismatched dates after upgrade, and have to manage that for the upgrade period.

The basic plan is (taking the depreciation calendar as an example):

1.  Query up the calendar in the calendars form.
2.  Go to the last record.
3.  Delete the last record.
4.  Save.
5.  Delete the new last record.
6.  Save.
7.  Repeat until you arrive at the currently open period, which you cannot delete.
8.  Add new periods back with your amended dates.

Remember that this must be done for prorate conventions as well.

With credit to Kathy White, Oracle Assets

Friday Oct 24, 2014

Using the Concurrent Request "Transfer Journals to GL - Assets"

PreventMost users transfer journals to GL via the transfer parameter within Create Accounting.  If you set that parameter to yes, Create Accounting will transfer everything it accounts within that batch to GL as part of the Create Accounting process.  However, what if you accidentally set that parameter to No?  Create Accounting, when next run, will not pick up the items accounted in the earlier run.  It handles ONLY those items accounted within the specific run.  To move those earlier items, you have to run the concurrent request Transfer Journals to GL – Assets.

Another normal use of the Transfer concurrent process is immediately after an upgrade from 11i to R12.  If you upgrade with some transactions already completed in the open period, those will be accounted by the upgrade (not by Create Accounting – but by the upgrade process itself).  They will have their xla_ae_headers.gl_transfer_status set to ‘N’ (No), so that you can move them to GL by running the Transfer concurrent.

Transfer Journals to GL – Assets is an “all or nothing” process.  That is, it has to move everything available to transferred, or it will rollback everything it attempted.  This is important because there is a known upgrade issue which can cause some items from very old periods (sometimes from years earlier) to have xla_ae_headers.gl_transfer_status set to ‘N’ (No), thus indicating – incorrectly – that they still need to be transferred.  Thus, this scenario can be encountered:

  • You upgrade from 11i to any version of R12 with some additions and retirements already done in the open period.
  • The upgrade accounts for these additions and retirements and, since they do actually need to be transferred, it leaves xla_ae_headers.gl_transfer_status set to ‘N’ (No).
  • You run Transfer Journals to GL – Assets after upgrading with the aim of moving those open period pre-upgrade items to GL.
  • It fails with an error message relating to musty old data from years ago.  You know this data is already transferred.
  • However, there is no reference in the log file to the open period data, which is the data you really want in GL, and which continues to not be in GL.

Since the Transfer is an all or nothing process, it failed everything because of the old data.  Since the open period data does not actually have an issue, there is no mention of it in the log file at all.  This does not mean it was not transferred, just that due to the other unwanted data failure, the open period data got rolled back, too.

Another common way to encounter this:

  • You  upgraded from 11i to R12 with no transactions entered into 11i in the period open at the time of upgrade.
  • You have successfully closed a number of periods while using Create Accounting with Transfer parameter as ‘Y’ (Yes).  You have, in fact, never run the Transfer concurrent.
  • Your user accidentally sets the Create Accounting transfer parameter to ‘N’ (No) or you have some type of database issue that causes Create Accounting to complete normally but not submit the transfer.
  • Many users who are unfamiliar with Transfer Journals to GL – Assets open an SR at this point to find out how to transfer data outside of Create Accounting.
  • Once you run the process, though, you encounter the same set of errors on old pre-upgrade data as in the earlier scenario.

How does that open period data actually get posted?  You are going to have to get a data fix to mark the old musty data as transferred to GL, so that the Transfer concurrent can run without failure and move the open period data.  To get that data fix, open a Service Request with Oracle Support and tell the analyst you have the issue in Transfer Journals to GL - Assets Attempts to Transfer Old Pre-Upgrade Data and Will Not Transfer Open Period Data (Doc ID 1347364.1).  The analyst will be able to provide a data fix that cleanly marks the old data transferred and allows you to post your open period data.

With credit to Kathy White, Oracle Assets

Tuesday Oct 14, 2014

An Explanation of Automatic Asset Numbering and Skipped Numbers

What is an asset number?

An asset number uniquely identifies each asset.  If you enter an asset number in Fixed Assets, it must be unique and not in the range of numbers reserved for automatic asset numbering. 

What is automatic asset numbering?

When you add an asset, you can enter the asset number, or you can leave the field blank and the system will use automatic asset numbering.  Automatic asset numbering uses the database sequence FA_ADDITIONS_S, which assigns a number to asset_id and asset_number.  The asset_id is the internal asset number and cannot be modified or updated.  The asset number is the public number and can be assigned by the user.  By default, the same number is assigned to asset_id and asset_number, which is then incremented by one after each asset addition.

The system skipped asset numbers.  Why?

A user entered an asset and the asset number of the last asset added was 16450.  Later, the user resumed entering assets and noticed that the next asset number was 16471 rather than 16451 as expected.

Oracle Applications requires space to execute stored packages and functions.  If that space is fragmented, there may not be enough space for a package or function, so the system pre-allocates space for packages, functions, and sequences by "pinning" them.  The asset number (asset_id) values created by the sequence FA_ADDITIONS_S are cached for performance reasons. 

What happens is that the sequence FA_ADDITIONS_S will be aged out of the cache.  The applications' perspective is that the next value of sequences will increment to the next multiple of the sequence cache value.  This is generally set to 20 by default.

How can I change how many values are being cached?

The easiest option is to set the nocache value to zero, but do realize there could be a performance issue when adding a larger number of assets.

Another solution is to prevent sequences from aging out of the library cache by pinning them using dbms_shared_pool.keep().  Pinning the sequence will prevent the sequence values from being aged out of the cache.

For more information on either option, please review Automatic Asset Numbering Skips Numbers (Doc ID 1036833.6).  An additional resource for this topic is the FAQ: Automatic Asset Numbering (Doc ID 469359.1).

Tuesday Sep 09, 2014

New Fixed Assets White Paper for Insurance Policies and Calculations

If you are contemplating the use of the insurance policy feature of Fixed Assets, you may be interested in a new document:  White Paper – Insurance Calculations in Oracle Assets (Doc ID 1913774.1).   Setup steps and insurance calculation methods are included in this new white paper.  Insurance

With this insurance feature, you can check if assets are under- or over-insured based on the annual index provided by your insurance company.  You can enter, view and maintain the insurance policies as well as the calculation methods.  There are three different calculation methods that can be used to obtain the current insurance value, which is then compared to the actual insurance coverage for an asset.

The three calculation methods are:

  • Value as New (VAN) - This method calculates the base insurance value of the asset, based on acquisition or production costs.  This value can be indexed annually to give a current insurance value.  It can also incorporate the indexed value of transactions that affect the asset value.
  • Market Value (CMV) - This method calculates the current market value of the asset.  Assets automatically calculates the current value from the net book value of the asset, incorporating index factors and the indexed value of any transactions affecting the asset value.
  • Manual Value - This method allows you to manually enter an insurance value for an asset.  With this method you can also manually enter updates to the asset insurance calculations in the insurance value.  Assets updates the current insurance value automatically only if you enter an optional maintenance date.

Additionally, there are two associated reports:

Insurance Data Report - Used to review insurance details for assets and to verify that the assignments for insurance records are correct.

Insurance Value Detail Report - Used to review calculations of insurance coverage for selected assets.  The Insurance Value Detail Report prints all insurance amounts for the selected assets and displays totals at the Balancing Segment level, Insurance Calculation Method level, Insurance Company level, and Insurance Policy Number level. The insurance coverage calculation indicates the differences between insured amounts and current insurance values.

For more details on the Fixed Assets' insurance feature, take a look at the white paper.  It also includes example cases with sample calculations and comparisons.

Tuesday Jul 29, 2014

Let's Talk About Reclassifications in Fixed Assets

MOS SupportThere have been some questions raised about asset reclassifications recently, so let's have a brief discussion about the reclass of assets. 

What is a reclassification?  Simply put, a reclass of an asset is moving the asset from one category to another. 

Perhaps the asset was in an incorrect category.  Perhaps the accounting for the category has changed and a new category needed to be created and the assets moved from the old category to the new category.

A reclass is performed at an asset level (not at a book level).  Therefore, a reclass performed on an asset will move that asset from the original category to the new category simultaneously in each book that the asset exists in.  Thus, the reclass of an asset occurs in all books and cannot be performed in only one book.  If an asset cannot be reclassified in one book, the asset will not be reclassed in any of the books to which it belongs.
You cannot reclassify fully retired assets.

When you reclass an asset in a period after the period of addition, journal entries are created to transfer the cost and accumulated depreciation to the accounts of the new asset category.  The depreciation expense account is also changed to the default depreciation expense account for the new category, but there is not an adjustment for prior period expenses.   

Reclassification does not re-default the depreciation rules of the asset to the default rules from the new category.  Manual changes would be necessary if the depreciation rules for the asset should also be changed.

You can reclass a group of assets by using the Mass Reclassification process.

Two resources for additional questions about the reclassification of assets and using Mass Reclassification are:

1.  Chapter 3 (Asset Maintenance) of the Oracle Assets User Guide
2.  Reclassifications of Assets in Oracle Assets (Asset Reclass) (Doc ID 107079.1)

Wednesday Jun 25, 2014

My Oracle Support Accreditation for E-Business Suite

The My Oracle Support Accreditation Series delivers a targeted learning experience that is designed to increase your expertise with My Oracle Support core functions and build skills to help you leverage Oracle product solutions, tools, and knowledge.

The accreditation framework for Oracle E-Business Suite is targeted to customers and partners who actively use My Oracle Support and Oracle E-Business Suite. The content is focused on building skills around best practices, recommendations, and tool enablement – taking your expertise with Oracle E-Business Suite to the next level. The Oracle E-Business Suite course covers:

•    Staying informed
•    Period Close
•    Patching
•    Certifications
•    Upgrade Advisor
•    Reporting 

Visit the My Oracle Support Accreditation Index and get started with the Level 1 My Oracle Support Accreditation path and the Level 2 Oracle E-Business Suite learning path today.

Thursday May 29, 2014

Fixed Assets Recommended Patch Collections

After the introduction of the Recommended Patch Collections (RPCs) in late 2012, Fixed Assets development has released an RPC about every six months.  You may recall that an RPC is a collection of recommended patches consolidated into a single, downloadable patch, ready to be applied.  The RPCs are created with the following goals in mind:

  • Stability:  Address issues that occur often and interfere with the normal completion of crucial business processes, such as period close--as observed by Oracle Development and Global Customer Support.
  • Root Cause Fixes:  Deliver a root cause fix for data corruption issues that delay period close, normal transaction flow actions, performance, and other issues.
  • Compact:  While bundling a large number of important corrections, the file footprint is kept as small as possible to facilitate uptake and minimize testing.
  • Reliable:  Reliable code with multiple customer downloads and comprehensive testing by QA, Support and Proactive Support. 

There has been a revision to the RPC release process for spring 2014.  Instead of releasing product-specific RPCs, development has released a 12.1.3 RPC that is EBS-wide.  This EBS RPC includes all product-recommended patches along with their dependencies.

To find out more about this EBS-wide RPC, please review Oracle E-Business Suite Release 12.1.3+ Recommended Patch Collection 1 (RPC1) (Doc ID 1638535.1).

Wednesday Apr 30, 2014

Have You Visited the Fixed Assets and Property Manager Community?

Have you visited the Fixed Assets and Property Manager Community?  This community is one of the Oracle E-Business Suite communities.  If you have visited recently, you probably noticed that it has undergone some changes and that it has a new look.  If you have not visited the Fixed Assets and Property Manager Community, we hope you will give it a try. 

The community is moderated by Oracle Support Services.  The goal of the community is to exchange knowledge and to collaborate on the following products:
  • Oracle Assets 
  • Oracle Property Manager 
  • Oracle WEB ADI (Additions and Physical Inventory Integrators) 
  • Oracle iAssets

As a participant, you can assist other users as well as receive assistance for issues that are posted.    

You can 'Start a discussion' to engage directly with an Oracle Support engineer without logging a Service Request.  You may also get input and expertise from other participants in the community who may have faced your same issue.  By marking answers as "Helpful" or "Correct," you'll be able to assist the next participant to solve their issue, too.

It's fast.  It's easy.  Try it today!

Thursday Apr 03, 2014

New Log Analyzer for Depreciation Error Logs

We have a new depreciation error log analyzer for Fixed Assets.  This new tool can be found in the document:  Log Inspector: Assets Depreciation (FADEPR) Terminated in Error (Doc ID 1626908.1).  When your depreciation process has terminated in error, you can use this tool to explore possible causes and find solutions. The Log Inspector will step you through the process. 

When you first view the Log Inspector document, you can select the link to view a short presentation about the use of the tool.  When you are ready to access the tool, you first select your release 12.0.x, 12.1.x, or 12.2.x.  Then select "Next."

The Log Inspector presents the second screen to you.  You will paste the contents of your depreciation error log file into the blank entry field.  When you select "Next," the Inspector will process the information provided to obtain a possible solution.

Error log

In this example, the depreciation error log was pasted into the Log Inspector's window, "Next" was selected, and the Inspector returned a solution:


The next time you encounter an error when running the depreciation process, consider utilizing the Log Inspector for analysis of the issue.  

Monday Mar 17, 2014

Need Assistance With A POST Mass Additions Issue?

In the last entry to the EBS Fixed Assets Support Blog, the Troubleshooting Assistant for the Create Mass Additions process was highlighted.  We also have a Troubleshooting Assistant for the POST Mass Additions process (also known by its short name of FAMAPT).  The Post Mass Additions process is the process used to post mass additions lines, making assets from those addition lines.  Alternatively, you might be making cost adjustments to assets or adding CIP assets using the Post Mass Additions process.  1610669.2

To assist with issues that you might encounter in the Post Mass Additions process, we have a new Troubleshooting Assistant (or Search Helper) to help you identify typical problems and obtain the solutions for those problems. 

  • You might have an error in the process
  • Perhaps you have encountered a performance issue
  • Maybe you are trying to merge addition lines
  • Is the list of values (LOV) for the book empty? 

Select the appropriate issue(s) in the selection window of the Troubleshooting Assistant and possible solutions will appear on the right side once you make your selection(s).

You can access this Troubleshooting Assistant by reviewing Troubleshooting Assistant: FAMAPT - Post Mass Additions (Search Helper) (Doc ID 1610669.2).

Thursday Feb 27, 2014

Need Assistance With A Create Mass Additions Issue?

We have created a new Troubleshooting Assistant for Oracle Fixed Assets for the Create Mass Additions process.  This process (also known by its short name in Assets as FAMACR and in Payables as APMACR) is used to bring addition and adjustment lines from Accounts Payable into Fixed Assets via the mass additions interface.  There have been a number of changes to the process and enhancements made in recent releases.

TroubResolveleshooting Assistants are resources created to help you find a resolution to an issue by guiding you from the problem, through the possible scenarios, and to the proposed solution.  These troubleshooting assistant types of resources were formerly called Search Helpers.  Called by either name, they are designed to provide a path through various topics related to a process and, based on the selections you make, provide suggested solutions. 

The troubleshooting assistant for create mass additions includes solutions for these issues, and more: 

  • Addition lines that were not transferred from Payables to Assets
  • Addition lines that were transferred into Assets but should not have been 
  • Merging of addition lines 
  • Transferring freight, tax or miscellaneous lines
  • ORA-30926 errors
  • Performance issues

You can access this troubleshooting assistant in Troubleshooting Assistant: Create Mass Additions From Payables (AP) to Fixed Assets (FA) (Doc ID 1609542.2)

Monday Sep 10, 2012

Oracle E-Business Financials Recommended Patch Collections (RPCs) for R12.1.3 Have Been Released for August 2012

What is a Recommended Patch Collection (RPC)? An RPC is a collection of recommended patches consolidated into a single, downloadable patch, ready to be applied. The RPCs are created with the following goals in mind:

  • Stability: Address issues that occur often and interfere with the normal completion of crucial business processes, such as period close--as observed by Oracle Development and Global Customer Support.
  • Root Cause Fixes: Deliver a root cause fix for data corruption issues that delay period close, normal transaction flow actions, performance, and other issues.
  • Compact: While bundling a large number of important corrections, we have kept the file footprint as small as possible to facilitate uptake and minimize testing.
  • Reliable: Reliable code with multiple customer downloads and comprehensive testing by QA, Support and Proactive Support.

RPCs are available for the following products:

  • Cash Management
  • Collections
  • E-Business Tax
  • Financials for India
  • Fixed Assets
  • General Ledger
  • Internet Expenses
  • iReceivables
  • Loans
  • Payables
  • Payments
  • Receivables
  • Subledger Accounting

For the latest Financials Recommended Patch Collections (RPCs), please view: EBS: R12.1 Oracle Financials Recommended Patches [Doc ID 954704.1].


Welcome to the EBS Support Blog where Oracle insiders share news and information about EBS products including new releases, tips and tricks, troubleshooting guides, upcoming webcasts and links to EBS Communities.

Stay Connected



« March 2015