How To Change Date Patterns and End Dates In EnterpriseOne (P0008, P0010, R099103)

Goal

How To Change Date Patterns and End Dates In EnterpriseOne.

Solution

1. How to Change Date Patterns

There are two options for converting fiscal date patterns:

• Set up a short year to adjust for the interim period.
• Set up a new company under the new date pattern.

Regardless of the option taken, two considerations apply:

1. In EnterpriseOne, the Fiscal Year is determined by the year in the date for the last day of Period 1. For example, if the first period of the fiscal year begins on December 15, 2001, and ends on January 14, 2002, then December 15, 2001 through December 14, 2002 is Fiscal Year 2002.
2. Each fiscal year must be unique within the same date pattern code.

The procedures to complete this change vary depending on whether it is from a calendar year to non-calendar year or, conversely, from a non-calendar year to a calendar year. 

1.1 Changing from a Calendar Year to a Non-calendar Fiscal Date Pattern

Option 1:  Short Year Setup

In the following example, the company is on a standard calendar year and needs to be changed to a non-calendar fiscal year of April - March.  For this particular change, date patterns need to be set up in the Work with Fiscal Date Patterns (P0008) according to the following table.

Fiscal Year 01, Date Pattern R	Fiscal Year 02, Date Pattern R	Fiscal Year 01, Date Pattern A	Fiscal Year 02, Date Pattern A
Jan 01	Jan 02	Apr 01	Apr 02
Feb 01	Feb 02	May 01	May 02
Mar 01	Mar 02	Jun 01	Jun 02
Apr 01	Mar 02	Jul 01	Jul 02
May 01	Mar 02	Aug 01	Aug 02
Jun 01	Mar 02	Sep 01	Sep 02
Jul 01	Mar 02	Oct 01	Oct 02
Aug 01	Mar 02	Nov 01	Nov 02
Sep 01	Mar 02	Dec 01	Dec 02
Oct 01	Mar 02	Jan 02	Jan 03
Nov 01	Mar 02	Feb 02	Feb 03
Dec 01	Mar 02	Mar 02	Mar 03
Dec 01	Mar 02	Mar 02	Mar 03
Dec 01	Mar 02	Mar 02	Mar 03

After these date patterns have been configured, begin the process of switching to the new fiscal year by completing these steps:

1. Run the annual close for FY01 with Date Pattern R.
2. Post the current activity to FY02 Date Pattern R.
3. Change the desired company in the Work with Companies (P0010) application to use Fiscal Date Pattern (data dictionary item DTPN) to A and the Beginning of Fiscal Year (data dictionary item DFYJ) to April 1, 2002.
4. Back up the Account Ledger (F0911) and Account Balances (F0902) tables.
5. Run Calculate Fiscal Year and Period Number (R099103) over all fiscal years to realign the periods across the fiscal years. For example, January 2002 entries will then appear as period 10 in FY 01. Make sure to run the Calculate Fiscal Year and Period Number (R099103) report in Proof mode to verify any changes prior to running it in Update mode.
6. Run Repost Account Ledger (R099102) to update the Account Balances (F0902) table. Always run this report in Proof mode to verify changes before running it in Update mode.
7. Run the Annual Close for FY 01 with Date Pattern A.

Some important things to note:

• A short year "bridge" of Jan 1-Mar 31 2002 followed by the new pattern Apr 1, 2002-Mar 31, 2003 in this example cannot be used because Period 1 of Fiscal Year 2002 would  then be represented by two months, January and April. This setup causes major reporting problems.
• At this point, no changes can be made to the Fiscal Year 2001 because the period numbers have been recalculated.
• All fiscal years must be defined and then Calculate Fiscal Year and Period Number (R099103) must be run over all the years at one time. The annual close must be run for each year.
• Back up the Company Constants (F0010), Account Master (F0901), Account Ledger (F0911) and Account Balances (F0902) tables before changing any information.
• To avoid unpredictable results, before running Repost Account Ledger (R099102) or the Calculate Fiscal Year and Period Number (R099103) in Final mode, verify no other users are on the system.

Option 2:  New Company Setup

1. Set up a new company with the new non-calendar year Fiscal Date Pattern (DTPN).
2. Set up business units and accounts for the new company.
3. Run Indexed Allocations for any periods where the old company transactions should be applied to the new company.

This method allows users to access information under both date patterns concurrently.  However, as shown in the initial example, keep in mind that period-to-period comparisons are meaningless because Period 1 in pattern R (January) is not the same month as Period 1 in pattern A (April).

1.2 Changing from a Non-calendar Fiscal Date Pattern to a Calendar Year Date Pattern

Option 1:  Short Year Setup

1. Create two new date patterns.  One should be for a short fiscal year beginning with the current non-calendar fiscal year period and ending on December 31.  The first new date pattern only needs to be created if some companies are going to remain on the old non-calendar year pattern. Otherwise, the current year under the non-calendar date pattern can be changed to end on December 31.  The second date pattern should be for the calendar year.  
2. Change the Fiscal Date Pattern (data dictionary item DTPN) for the desired company to the short date pattern type in Work with Companies (P0010).
3. Run Calculate Fiscal Year and Period Number (R099103), first in Proof mode.Verify the results and run in Final mode.  
4. Run Repost Account Ledger (R099102), first in Proof mode. After verifying the results, run the report again in Final mode.
5. Run the Annual Close for the short year.  
6. Change the Fiscal Date Pattern (DTPN) for the desired company to the new calendar year date pattern. 
7. If postings have been made to this new year, run the Calculate Fiscal Year and Period Number (R099103) again.  If past years need to be updated, run this UBE over all fiscal years at one time with the company set to the calendar date pattern. The Annual Close  process needs to be ran for each year individually.

Option 2:  New Company Setup

1. Set up a new company with the new calendar year Fiscal Date Pattern (DTPN).
2. Set up business units and accounts for the new company.
3. Run Index Allocations for any periods where the old company transactions should be applied to the new company.

Note - Any transactions created for the new company should be removed or voided from the old company.

This method allows users to access information under both date patterns concurrently. However, as shown in the initial example, keep in mind that period-to-period comparisons are meaningless because Period 1 in pattern R (January) is not the same month as Period 1 in pattern A (April).

2. How to Change End Dates

Occasionally, a fiscal date pattern is not properly defined for a particular period.  For example, the ending date for February is incorrect for a leap year. Company policy may or may not require changes.  If the ending date of the period is incorrect, transactions entered with a G/L date for the omitted day (e.g. 2/29) are added to the next period.

2.1 Unposted Records

There are no repercussions to changing a period's end date if transactions have not yet been posted for that date.  If the Accounts Payable or Accounts Receivable constants are set to post offsets by batch (B), the Automatic Entries for these transaction will be created for the correct period and date and will also be unaffected.  However, if transactions were created for the end date in question prior to the change, the Period Number (data dictionary item PN) in the General Ledger (F0911) will be incorrect.  Because the transactions are not posted, the Account Balances (F0902) table is unaffected. Therefore, only the Period Number (PN) in the General Ledger (F0911) needs to be corrected. To do so, run the Calculate Fiscal Year and Period Number (R099103) report. This UBE needs to be run in Proof mode to determine which records are affected before running the program in Final mode.  If the transaction originated in a system other than General Accounting, it is possible other tables are affected.  These other tables may contain a Period Number field (PN).  These issues must be changed manually using a database utility because there are no EnterpriseOne solutions for updating the Period Number (PN) in other tables.

2.2 Posted Records

If the end date of a period is changed after transactions have posted to it, the Account Balances (F0902) table will be incorrect.  Automatic Entries that are created by batch need to be corrected because there is the possibility that they posted to the wrong period.

When Problems Occur
Problems occur when transactions are posted and/or entered specifically to the date that is changed.  The example, a transaction that is posted with a General Ledger date of 2/29 and the period end date is changed from 2/28 to 2/29.  When the period is changed, the fiscal date pattern now indicates that 2/29 belongs to period 2  instead of period 3.  Because there are transactions posted with a General Ledger date of 2/29 that are in period 3, the Account Balances (F0902) table does not reflect the date pattern change. Depending on company policy, there may be a need to correct the period number on these records so they appear in financial statements for the proper period (February instead of March).

Correcting the Records
Different steps are required to correct the period numbers on records depending on the posting status and the type of transaction.  Perform the following steps after the period end date is changed in the date pattern.

1. Run the Calculate Fiscal Year and Period Number (R099103) in Proof mode first to verify which records will be updated.  After the information is verified, run this report again in Final mode.  This program updates the fiscal year and period number of the General Ledger (F0911) record based upon its G/L date. 
2. After these fields are updated in the General Ledger (F0911), run the Repost Account Ledger (R099102) to  update amounts in the Account Balances (F0902) table. 
3. If prior years are affected, the annual close should be submitted for the year(s) in question after the Account Balances (F0902) is updated.  

Caution - The Repost Account Ledger (R099102) and the Calculate Fiscal Year and Period Number (R099103) must always be run for a full fiscal year.  Any data selection has the potential to cause integrity problems.

Automatic Entry Considerations
Running the Repost Account Ledger (R099102) does not correct all records.  Automatic Entry transactions may not be updated properly, depending on the offset method specified in the Accounts Payable and Accounts Receivable constants.

If the Accounts Payable constant is set to use Offset Method B (batch) an AE transaction is automatically posted using a the last day in a GL period.  For example, a date pattern is set for Period 3 (March) with a period end date 3/30 and Period 4 (April) with a period end date of 4/30. A voucher for $100.00 is created with a G/L Date of 3/31. When the voucher is posted, its Automatic Entry is created with a GL Date of 4/30.  If the date pattern is changed so Period 3 ends on 3/31, the Calculate Fiscal Year and Period Number (R099103) does not correct the Automatic Entry because its GL Date is within Period 4. However, the Expense Account entry in the General Ledger (F0911) is updated to reflect the current period, leaving inconsistencies in the data.

To correct the Automatic Entry, create two one-sided journal entries to move the transaction amount from period 4 to period 3.  In this example, the first journal entry would be for $100.00- on G/L date 3/31 and the second would be for $100.00 on 4/30.   There may be more than one trade/offset account involved in the posting of a transaction.  Run General Journal by Batch (R09301) and use data selection to isolate records with a GL date of 3/31 and GL Period 3 to obtain a list of accounts and amounts that need to be corrected.

Other Accounts
This situation is not isolated to A/P and A/R trade accounts and AE document types.  Reversing Journal Entries also create date problems because they use the first day of the next period as the GL Date. For example, if the date pattern gets changed from 2/28 to 2/29 the following may happen:
· A reversing Journal Entry created for 2/28 prior to changing the period end date has a GL Date of 2/29, instead of 3/1.
· A reversing Journal Entry created for 2/29 prior to changing the period end date has a GL Date of 4/01, instead of 3/1.

Run General Journal by Batch (R09301) and use data selection to isolate records for these GL Dates that are also reversing (Reverse Void (R/V) field = R).

Other Systems
Running Repost Account Ledger (R099102) and the Calculate Fiscal Year and Period Number (R099103) does not correct or update records in tables other than the General Ledger (F0911) and Account Balances (F0902).  Changing the fiscal date patterns could impact other applications, such as the Accounts Payable Ledger (F0411).  The Accounts Payable Ledger (F0411) also records a Period Number (PN). This issue could result in an A/P integrity issue. This fact is true for any table that utilizes the Period Number (PN) field.  There is no update for these other tables, so use caution and understand the implications before proceeding.