Sage 100

Fiscal year question. We have a customer who needed to change from a September 30th fiscal year end to a calendar year end. So, we created a short year ending 12/31/2016. The ""gotcha"" is that the numbering system had FYE 09/30/2016 as ""2016"" and so created ""2017"" as the short year and then 12/31/2017 as ""2018."" OOPS! I think that I have an answer to this and would like suggestions and/or critiques. 1. Make a DAMN GOOD backup. (than another just in case) 2. Reinitialize GL_Fiscal Year and GL_FiscalYearDetail ONLY! 3. Redefine Fiscal Years in GL Setup. 4. Recalculate General Ledger. Anyone see an holes or how this might affect subsidiary modules? They have AP, AR, BR.

It has been a while since I did this. There used to be an issue with beginning balances. I guess I am not helping much other than emphasizing #1 above.

I'd imagine the module data would have any by-period reports combine the short year data with calendar 2017 data... unless there was a recalculate utility to update the summary tables.

I think I've dealt with this in the past by going way back and changing old fiscal periods. Problem is that some of the periods are going to look odd but in most cases you want the newer ones to appear correctly with the proper FYE. I don't remember every causing an issue just going back and changing the periods then moving forward but make a backup. This is also going to cause a funky inventory issue with a short year. I think I had one customer purchase the DSD recalculate so all prior periods could be on the same fiscal.

You're definitely on the right track. Here are some instructions from a very old kb article. Possible Resolution: Note: Use caution when working with these tasks. Reinitializing or recreating data files deletes all records in the selected files and is irreversible. Always make a backup before performing the procedures below. If necessary, seek the assistance of a qualified Sage Software business partner or Sage Software Customer Support analyst. 1.Open General Ledger / Setup / General Ledger Options. 2.Note the values in the 'Current Fiscal Year' and 'Current Period' fields. Change the fields to the following, and then click 'Accept': oCurrent Fiscal Year = The earliest fiscal year that contains data for the company oCurrent Period = Period 1 3.Open Library Master / Utilities / Reinitialize Data Files. 4.Select ""General Ledger"" and the company code. 5.Select the following fields: oGL_FiscalYear (GL Fiscal Year Masterfile) oGL_FiscalYearDetail (GL Fiscal Year Detail field) 6.Click 'Proceed'. Close the window when finished. 7.Open General Ledger / Setup / Fiscal Year Maintenance. The default year that appears is the year defined in G/L Options. 8.Enter the correct starting and ending dates for period 01. 9.Click the 'Calculate Dates' (gear) button. 10.Click 'Accept'. 11.Enter the next year. The correct fiscal dates should automatically populate the 'Period' fields. 12.Click 'Accept'. Add each year through the current fiscal period. 13.Open General Ledger / Setup / General Ledger Options. 14.Change the 'Current Fiscal Year' and 'Current Period' fields to the original year and period. 15.Open General Ledger / Utilities / Recalculate Account Balances, and click the 'Proceed' button.

Chuck, you have it correct. Remove the fiscal years, re-define them, then rebuild the GL. Yes, definitely check the beginning balances. There is a good chance they will need to be re-entered. Also, there are several tables in inventory and some in sales order that have history by period that will be out of sync. The GL period changes don't propagate to the other modules. As Wayne pointed out, DSD has a utility to correct the subsidiary modules if the client can't live with ""going forward from here"" after the change.

How fiscal periods affect other modules. See attached.

Thanks, everyone. Fortunately, no Inventory module to worry about on this installation.

it will affect AR and AP. Accounts Receivable AR_CustomerSalesHistory (Customer Maintenance History tab data) AR_SalespersonHistory (Salesperson Maintenance History tab data) Accounts Payable AP_VendorPurchaseHistory (Vendor Maintenance History tab data)

I found another oddity when performing this task. The GL for this system had originally been setup with the year designation being the same calendar year as the end of the fiscal year. Thus; ""2015"" was FYE 09/30/2015 and ""2016"" was FYE 09/30/206. So when we created the short year (10/01/2016 - 12/31/2016) to move to a calendar year basis, the short year was ""2017."" This is what necessitated the ""renumbering."" In short, because ""2016"" already had 12 periods in the GL_PeriodPostingHistory.M4T file, I had to reinitialize THAT file as well! The recalculate DID NOT get rid of the 4th through 12 period in the 2016 year so those figures threw off the 2017 beginning numbers. Fortunately, the ""recalculate"" function recreated all of the entries in the GL_PeriodPostingHistory file and everything looks good now.

Chuck, I have performed the fiscal year change several times. I am amazed at how many times I have seen the issue you encountered. If the FYE is 9/30/2016 then the year is supposed to be 2015 not 2016. If the original consultant that set up the GL used the wrong year and you later need a short year, you have to reinitialize the fiscal year table and re-establish the years and the rebuild. Now the history is REALLY screwed up!

I always think back on my days in public accounting. Always use the prior year tax return for companies with a fiscal year end in the current year. Easy way to remember how to set up companies with FYE.

Exactly, @DougHiggs !

Chuck, I had the same issue with the GL_PeriodPostingHistory file when changing fiscal year ends for a client a couple weeks ago, so my client's 2017 beginning balances were wrong as well. The procedures in the old KB article that John Kerr posted above are the same procedures that I used, but they don't discuss the potential issue with the GL_PeriodPostingHistory containing records that need to be removed. Maybe Sage should update these procedures to include this.