SBX - Search With Button

SBX - Forum Post Title

reporting periods in timesheet setup

Microsoft Dynamics GP Forum

Tiffany D asked a question on 24 Sep 2012 11:46 AM

Question Status

Suggested Answer

Our system was previously setup for weekly timesheets and now we want to change to monthly.  Under Project/Setup/timesheets, the reporting periods is grayed out.  I have tried changing the No. of Reporting Periods from 52 to 12 and also changing the First date of the Reporting period.  Nothing I do will ungray or change the reporting periods from 'weekly'. 

Can someone please tell me how to do this or if this is a one time setup option and can not now change.

 

Thanks

 

Reply
Andy Sather responded on 2 Oct 2012 10:34 AM
My Badges

Hello Tiffany - In order to change the reporting periods for Timesheets in Project Accounting you will need to use SQL because you will not be able to change from within GP once a timesheet has been saved or posted.

If the Reporting Periods are going to be changed I strongly recommend that all existing timesheets be approved or deleted so new ones can be entered.

In order to change the reporting periods to monthly you will need to update the PA41801 so the pareportingperiods field is a 5.

Additional Information

1. You will need to run a statement to update the Reporting Periods, Number of Reporting Periods, and First Day of Reporting Period (if you need/want to change this date).

2. The first field you will need to change is Reporting Periods. This tells the system if you want them to be Weekly, Monthly, etc. In the SQL table a number is used to represent this:

1-Daily

2-Weekly

3-Bi-Weekly

4-Semi-Monthly

5-Monthly

6-Bi-Monthly

7-Quarterly

9-Miscellaneous (can choose the number of reporting periods)

3. The second field is the PAnumofreportingperiods and they are also represented by numbers

365-Daily

52-Weekly

26-biweekly

27-Semi-monthly

12-Monthly

etc.

Once that is completed, you can now enter transactions to make sure they are correctly going to their respective periods. Unfortunately, transactions already entered will not be able to be adjusted to the current reporting periods. There is not a workaround for the previously entered transactions. I would recommend making the change in a test company first to ensure that it will work the way you intend before making the change in production.

Reply
Béat Bucher responded on 22 Jul 2015 10:15 AM
My Badges
Suggested Answer

Hi Tiffany,

I know this thread is pretty old and was a little technical, but could you please confirm that this worked for you and if so mark the question as answered.. this way other users could benefit from the answer.

Thank you.

Reply
Kristie McNulty responded on 3 Jan 2017 9:20 AM
My Badges

Yes, that would be appreciated to know if the suggested change worked.  While we are on the subject, I would like to know how it is period 53 is being generated in our version where we selected the weekly option at the onset and only expect to generate for 52 PA Reporting Periods (PAREPD) but are getting 53 periods, which then causes the transaction to fail.  I'll be happy to open a separate thread if that makes more sense.

Reply
Béat Bucher responded on 4 Jan 2017 8:57 AM
My Badges
Suggested Answer

Hi Kristie,

This is strange indeed.. the only reason I could think off might be a strange initial starting date or setup change after the initial configuration..

I checked all our historical data, and none of the periods are higher than 52.. However, the issue with a setup that was started over 10 yrs ago is that with the time, the weekly periods are shifting and now our first week in January has a period #3, because our period 52 in December ended on 2016-12-10...

I wouldn't focus too much on the Period value as this is misleading.. in our case we have twice a PAREPD value of 1-2-3 for 2016, as it's lapsing accros years now. and the system doesn't check for the combined value PAYR & PAREPD..  

For reporting purposes, I sollely rely on the PAYR and the PDK_TS_No, as I know those are driven by the staring date of the Timesheets (in our case every Saturday).

Reply
Béat Bucher responded on 22 Jul 2015 10:15 AM
My Badges
Suggested Answer

Hi Tiffany,

I know this thread is pretty old and was a little technical, but could you please confirm that this worked for you and if so mark the question as answered.. this way other users could benefit from the answer.

Thank you.

Reply
Béat Bucher responded on 4 Jan 2017 8:57 AM
My Badges
Suggested Answer

Hi Kristie,

This is strange indeed.. the only reason I could think off might be a strange initial starting date or setup change after the initial configuration..

I checked all our historical data, and none of the periods are higher than 52.. However, the issue with a setup that was started over 10 yrs ago is that with the time, the weekly periods are shifting and now our first week in January has a period #3, because our period 52 in December ended on 2016-12-10...

I wouldn't focus too much on the Period value as this is misleading.. in our case we have twice a PAREPD value of 1-2-3 for 2016, as it's lapsing accros years now. and the system doesn't check for the combined value PAYR & PAREPD..  

For reporting purposes, I sollely rely on the PAYR and the PDK_TS_No, as I know those are driven by the staring date of the Timesheets (in our case every Saturday).

Reply

SBX - Two Col Forum

SBX - Migrated JS