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.
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