The mystery of the 13th period

(0) Share

Report

Posted on by Community Member

Hi all,

I have just come across a disturbing article relating to updating to Service Pack 3 of GP 2010:

https://community.dynamics.com/product/gp/gptechnical/b/dynamicsgp/archive/2012/08/02/microsoft-dynamics-gp-2010-utilities-hanging-when-upgrading-the-databases-with-service-pack-3-or-any-later-hot-fix.aspx

The gist of this is that the upgrade will hang if you have a thirteenth period that overlaps period twelve in its date range.

The article suggests that financial periods are "not setup correctly" if periods overlap, as per the following KB:

http://support.microsoft.com/kb/871679

This seems odd to me, as the GP 10 Financials Exam has a question in it about how may periods are allowed in a financial year in Dynamics GP - as I recall the answer is 367 - one for each day in a leap year, plus an adjusting period. I look forward to seeing how you can set up 367 periods without overlapping a day.

More worryingly though is the solution given in the article, which involves using a SQL query to update period 13 (and 14 if you have one) to be the last day of the financial year.

This causes two problems for me:

1. I have many customers with an overlapping period 12-13 setup who have been merrily running this way for years. In the UK our financial periods tend to run from April to March. I can see how in the US sacrifising New Year's Eve is not too big a deal, but in the UK 31st March is just another day, and my customers will have legitmate non-adjusting transactions posted to 31st March. They will also have adjusting transactions (probably) posted to the 31st March.

If I adjust the financial periods for all prior years (and there are a lot in some cases), I will have legitimate transactions in period 13 and reports will not be reproducable.

What is the right solution here?

Query GL30000 for all transactions posted to 31st March, figure out which are not adjusting transactions, and update the TRXDATE to 30th March? Then reconcile to correct financial periods?

Presumably I would also need to update the Posting Date in all subledger history tables as well, but this is less critical.

2. All of my customers have feeder systems that will try to post transactions through eConnect to GP. These feeder systems will not have any special knowledge that 31st March is off-limits too them. I reckon I can work around this by editting the stored procedure for the ta...Pre to override the TRX Date / Posting Date as appropriate to ensure that transactions are not posted to P13 and are redirected to P12.

Does that sound like the best solution?

Thoughts and comments welcome.

Cheers,

Andrew Cooper

*This post is locked for comments

I have the same question (0)

All responses (13)

Answers (1)

Verified answer

Jonathan Fear on at

Like (0)

Report

Hi Andrew,

This is a bug that we are aware of and are working hard on fixing. Please note that this is not something that you will be running into every time you upgrade in the future. This is a bug within the upgrade that will get resolved by development. We apologize for the issue is causes but like with any software application there are unforeseen errors that sometimes cannot be avoided.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Jonathan,

If it is a bug, that's fine. The tone of the original blog post about this issue suggested it was a new feature - i.e. from 11 SP3, periods cannot overlap.

But if that's not the case, then brilliant.

Cheers,

Andrew

Was this reply helpful? Yes No
Jonathan Fear on at

Like (0)

Report

I think there is still some confusion Andrew. You are not allowed to have overlapping fiscal periods. If you try to set this up in GP you will receive an error message. How have you gotten this to work? Are you using some 3rd party product or tool?

Was this reply helpful? Yes No
Ian Grieve 22,784 on at

Like (0)

Report

I used to work at the same company as Andrew and overlapping periods were being set up for P13 from Great Plains 7 (or it may have been 7.5), when we started selling GP, and onwards without seeing any errors. This was base GP with no add-ons.

And, as Andrew says, the maximum number of periods is 367 which would be one for every day of a leap year plus the adjusting period so the system MUST allow overlapping periods or this would not be possible.

Was this reply helpful? Yes No
Jonathan Fear on at

Like (0)

Report

Sorry about that guys. You both are right on this actually. We just did some testing and the system does allow you to have overlapping dates when you change the dates in the bottom of the fiscal period window. However when you use the calculate button the system does not allow overlapping. We are still looking into the bug and the information in the blog will be updated once we find out more information. Also this will only happen one time for each customer that has overlapping dates when the upgrade from GP 9 or 10. So if a customer runs into the issue upgrading from GP 10 to GP 2010 they will not run into this when upgrading to GP 2013. However if the customer upgrades from GP 10 to GP 2013 they will run into the issue.

Let mek now if you haves have any other questions about this.

Was this reply helpful? Yes No
Warren R. Pease 730 on at

Like (0)

Report

Let me ask a question on this from an accounting point of view.

Let's use a calendar year as an example. If you had period 12 as 12/1 to 12/31 and period 13 as 12/31/ to 1/31, then how does the system know what period a 12/31 transaction belongs to. We can only specify date on a transaction, not the period. If you run reconcile on the GL, what period summary would be updated?

Warren

Was this reply helpful? Yes No
Warren R. Pease 730 on at

Like (0)

Report

I just ran a test.

The only way I could get an overlapping period was to use 366 periods (367 in a leap year). It showed Period 365 as 12/31 and Period 366 as 12/31.

Next ran a GL Transaction dated 12/31. In summary inquiry the amounts showed in period 365. Ran a Reconcile GL and amounts stayed in period 365.

Therefore, the way I see it: Under special circumstances you can have overlapping periods defined in the Fiscal Calendar. However it does not appear that the system will allow you to control which of the two you actually post to. It goes to the first period it finds based on the transaction date.

I would say that Adjustment Periods are not supported by GP. While the manual states you can setup 367 (leap year), in reality you only get 366 max to use.

Am I missing a way to post to a user specifed period when the transaction date is in more than one?

Warren

Was this reply helpful? Yes No
Ian Grieve 22,784 on at

Like (0)

Report

Hi Warren,

When ou set up 13 periods you need to manually change the dates of the periods after you've done Calculate and set P12 and P13 to have the same date.

You control where GP posts to by having P12 open and P13 closed until you want to start posting into the adjusting period when you close P12 and open P13.

Was this reply helpful? Yes No
Warren R. Pease 730 on at

Like (0)

Report

Ian,

That is sure an eye opener to me. I have been working with and certified on GP since V2.2, never seen that before. I searched the help file and manual and can't find a reference to the Adjustment Transaction check box, I have never even seen it before. Thanks for the enlightenment on this.

Warren

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thanks for the replies all.

As has already been said, overlapping periods are possible by overriding the calculated dates in the Financial Periods window.

The system "knows" which period to update the balances for by which period is open, or the first if both are open.

(It should be said, however, that although this works fine through the General Entry window, it does not work through eConnect. Both periods need to be open or eConnect logs an error in the event log.)

Jonathan - thanks for the info. If I understand you correctly, a customer with overlapping periods will be able to upgrade from GP10 --> GP 2010 SP2 (but not SP3) --> GP2013 with no problems, but should just avoid GP2010 SP3 and going directly from GP10 to GP2013?

Cheers,

Andrew

Was this reply helpful? Yes No