1. Project/Payroll pay period not correct

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

2. RE: Project/Payroll pay period not correct

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

4. RE: Project/Payroll pay period not correct

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

5. RE: Project/Payroll pay period not correct

We ran into a similar issue a couple of years back when I realized that our TS posting period was off by 4 weeks !!! after having used the GP / PDK combo for over 10 years, this kind of shifting happens, as Thaddeus explained.. Nothing to worry about, but it is just strange to start with period 1 in early-mid December..

You've to be careful though, since the system won't allow you two identical periods in the same accounting year in PA/PDK.. That was the trigger that made us realize there was a problem as we had in December a second period #3 or #4 for the same year..

Currently we're in reporting period #50, whereas it should be 48. Increasing the count to 53 or even 55 won't change the period number in PDK for the current year. In order to fix this we have to correct also the "First Date of reporting" in PA TS setup, and tell the system there are either 52 or 53 weeks in this year. But if you do this before the new year starts, you may hit the above mentioned issue with 2 periods on the same year. If you change it on year-end to fix it for January 2018, and people are already entering their TS reports early, then you're stuck, as several will have the wrong period added to their TS report.

Another way I could fix it for our main company is to set the total numbers of periods to 55, so next year in 2018 it would reach December 31st with period #55 and restart on Jan. 1st 2019 with period 1.

PS: I just tested my theory above, and it doesn't work.. PDK seems to be hard-coded on 52-weeks cycle and will only update the period number based on the start date.. :-(​​​​​​​

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

6. RE: Project/Payroll pay period not correct

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

7. RE: Project/Payroll pay period not correct

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

9. RE: Project/Payroll pay period not correct

Yes, If you run EL and ML and they are weekly not monthly, then you need to do the same update for them as for TS every six years.

What is bad is when you fail to do this update and all of a sudden your reports say that Period 1,2 and maybe even three of Year 2018 began in 2017. That's what is bad for reporting.

Most HR and Payroll depts have calendars that list the weeks of the year as 1-52 and periodically 1-53. They often run whats called a 4-4-5 month quarter to add to 52. These periods should correspond to the periods captured in Timeheets else payroll is in period 1 of 2018 and the Timesheets say period 3 of 2018. Pay will be OK but reporting will be confusing.

We normally do these updates as part of year end closing as it is then that we look forward and see that the year is a 53 not a 52. If you do it as part of year end close then no one will have entered forward timesheets and you will not need to update any transactions.

Its appears messier when you only notice the problem in December and things are already starting to go bad as people enter a timesheet that says Period 1, 2018 and it is still mid December 2017. Updating the bad transactions though is very easy just extra nuisance for the tow columns. They do not affect periodic table balances in PA.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

10. RE: Project/Payroll pay period not correct

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

11. RE: Project/Payroll pay period not correct

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

12. RE: Project/Payroll pay period not correct

I made the change and it shows up in both the setup table and window. As you can see our first date was 12/29/2003 which would have started the issue (way before me). I decided to look at the timesheets to make sure it will show periods 53, 54 and 55. It does not show them. It shows as 1, 2 and 3. If I type 55 in the period, it appears with the correct date. When I use the arrow to toggle to the next date, it appears as 4. If I toggle back, it shows as week 3. I confirmed that there are not predated timesheets.

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

13. RE: Project/Payroll pay period not correct

No, you are not missing anything. By setting the periods to 55, GP will now allow a period 55 but does not default it in.Normally you are only dealing with a period 53 and you make sure everyone knows to do their timesheet to period 53 not to 1. BBucher reminded me that in BP you cannot control the period.

In your case you have 53, 54, and 55 periods before you want to start again with 1 and the users will never understand it. So set the value to 55 as you have.

Then monitor your PDK10000 and PA10000 and update the Year and Period columns before you post the batches. Now it won't matter what the users send in or what defaults in.1-2018 becomes 53-20172-2018 becomes 54-20173-2018 becomes 55-2017After you have all your timesheets in for 2017 change the periods back to 52.Take a look at your tow tabkes though becasue there is alayws a few peopoel who do advance timesheets and you will need to fix them in the header

BBucher is going to comment on the firstdate of reporting period one ( I aiad leave it alone) but he is correct. It needs to be advanced so that your 2018 is clean for period 1. But let him explain.

Updating the PA10000, PDK10000, PA30100 (period and year) is safe. No issues as these are not in the periodics. Only for reporting.

I made the change and it shows up in both the setup table and window. As you can see our first date was 12/29/2003 which would have started the issue (way before me). I decided to look at the timesheets to make sure it will show periods 53, 54 and 55. It does not show them. It shows as 1, 2 and 3. If I type 55 in the period, it appears with the correct date. When I use the arrow to toggle to the next date, it appears as 4. If I toggle back, it shows as week 3. I confirmed that there are not predated timesheets.

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

14. RE: Project/Payroll pay period not correct

Hi @Brent MyrickSorry for the delayed reply, but I've played around with the various options of the periods setup for PA TS & PDK today, trying to validate as many scenarios as possible, to make sure I didn't miss something..A detailed blog post is going live tomorrow about this and explains the mechanic behind this setting.By analogy, the EL & ML setup follow the same rules.. but usually they are set for a daily period (365), rather than weekly (at least that's the case in our company).Now the EL & ML do suffer from the same shifting of periods over the years and need peridodically an adjustment.. like in our case, we're some 40 days behind.. It may not have the same adverse effect as for the payroll & time-sheet periods, but still can be confusing.Check it out tomorrow on http://bit.ly/GP_Geek​​

No, you are not missing anything. By setting the periods to 55, GP will now allow a period 55 but does not default it in.Normally you are only dealing with a period 53 and you make sure everyone knows to do their timesheet to period 53 not to 1. BBucher reminded me that in BP you cannot control the period.

In your case you have 53, 54, and 55 periods before you want to start again with 1 and the users will never understand it. So set the value to 55 as you have.

Then monitor your PDK10000 and PA10000 and update the Year and Period columns before you post the batches. Now it won't matter what the users send in or what defaults in.1-2018 becomes 53-20172-2018 becomes 54-20173-2018 becomes 55-2017After you have all your timesheets in for 2017 change the periods back to 52.Take a look at your tow tabkes though becasue there is alayws a few peopoel who do advance timesheets and you will need to fix them in the header

BBucher is going to comment on the firstdate of reporting period one ( I aiad leave it alone) but he is correct. It needs to be advanced so that your 2018 is clean for period 1. But let him explain.

Updating the PA10000, PDK10000, PA30100 (period and year) is safe. No issues as these are not in the periodics. Only for reporting.

I made the change and it shows up in both the setup table and window. As you can see our first date was 12/29/2003 which would have started the issue (way before me). I decided to look at the timesheets to make sure it will show periods 53, 54 and 55. It does not show them. It shows as 1, 2 and 3. If I type 55 in the period, it appears with the correct date. When I use the arrow to toggle to the next date, it appears as 4. If I toggle back, it shows as week 3. I confirmed that there are not predated timesheets.

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

Hi @Brent MyrickSorry for the delayed reply, but I've played around with the various options of the periods setup for PA TS & PDK today, trying to validate as many scenarios as possible, to make sure I didn't miss something..A detailed blog post is going live tomorrow about this and explains the mechanic behind this setting.By analogy, the EL & ML setup follow the same rules.. but usually they are set for a daily period (365), rather than weekly (at least that's the case in our company).Now the EL & ML do suffer from the same shifting of periods over the years and need peridodically an adjustment.. like in our case, we're some 40 days behind.. It may not have the same adverse effect as for the payroll & time-sheet periods, but still can be confusing.Check it out tomorrow on http://bit.ly/GP_Geek​​

No, you are not missing anything. By setting the periods to 55, GP will now allow a period 55 but does not default it in.Normally you are only dealing with a period 53 and you make sure everyone knows to do their timesheet to period 53 not to 1. BBucher reminded me that in BP you cannot control the period.

In your case you have 53, 54, and 55 periods before you want to start again with 1 and the users will never understand it. So set the value to 55 as you have.

Then monitor your PDK10000 and PA10000 and update the Year and Period columns before you post the batches. Now it won't matter what the users send in or what defaults in.1-2018 becomes 53-20172-2018 becomes 54-20173-2018 becomes 55-2017After you have all your timesheets in for 2017 change the periods back to 52.Take a look at your tow tabkes though becasue there is alayws a few peopoel who do advance timesheets and you will need to fix them in the header

BBucher is going to comment on the firstdate of reporting period one ( I aiad leave it alone) but he is correct. It needs to be advanced so that your 2018 is clean for period 1. But let him explain.

Updating the PA10000, PDK10000, PA30100 (period and year) is safe. No issues as these are not in the periodics. Only for reporting.

I made the change and it shows up in both the setup table and window. As you can see our first date was 12/29/2003 which would have started the issue (way before me). I decided to look at the timesheets to make sure it will show periods 53, 54 and 55. It does not show them. It shows as 1, 2 and 3. If I type 55 in the period, it appears with the correct date. When I use the arrow to toggle to the next date, it appears as 4. If I toggle back, it shows as week 3. I confirmed that there are not predated timesheets.

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

16. RE: Project/Payroll pay period not correct

Thank you Beat. Your blog explained everything very well. I want to run by what my path forward will be. It is currently week 52 for us.

For the following three weeks I plan on instructing users on changing the period to the assigned week e.g. next week would be 53.Before posting of the timesheets, confirm that the period is correct.If periods are correct, post timesheets.

On 1/1/2018, change the first day of reporting to 1/1/2018 and change the reporting periods back to 52.

I believe this should resolve the issue.

Could either of you confirm this please? I want to make sure I am following the conversation correctly.

Hi @Brent MyrickSorry for the delayed reply, but I've played around with the various options of the periods setup for PA TS & PDK today, trying to validate as many scenarios as possible, to make sure I didn't miss something..A detailed blog post is going live tomorrow about this and explains the mechanic behind this setting.By analogy, the EL & ML setup follow the same rules.. but usually they are set for a daily period (365), rather than weekly (at least that's the case in our company).Now the EL & ML do suffer from the same shifting of periods over the years and need peridodically an adjustment.. like in our case, we're some 40 days behind.. It may not have the same adverse effect as for the payroll & time-sheet periods, but still can be confusing.Check it out tomorrow on http://bit.ly/GP_Geek​​

No, you are not missing anything. By setting the periods to 55, GP will now allow a period 55 but does not default it in.Normally you are only dealing with a period 53 and you make sure everyone knows to do their timesheet to period 53 not to 1. BBucher reminded me that in BP you cannot control the period.

In your case you have 53, 54, and 55 periods before you want to start again with 1 and the users will never understand it. So set the value to 55 as you have.

Then monitor your PDK10000 and PA10000 and update the Year and Period columns before you post the batches. Now it won't matter what the users send in or what defaults in.1-2018 becomes 53-20172-2018 becomes 54-20173-2018 becomes 55-2017After you have all your timesheets in for 2017 change the periods back to 52.Take a look at your tow tabkes though becasue there is alayws a few peopoel who do advance timesheets and you will need to fix them in the header

BBucher is going to comment on the firstdate of reporting period one ( I aiad leave it alone) but he is correct. It needs to be advanced so that your 2018 is clean for period 1. But let him explain.

Updating the PA10000, PDK10000, PA30100 (period and year) is safe. No issues as these are not in the periodics. Only for reporting.

I made the change and it shows up in both the setup table and window. As you can see our first date was 12/29/2003 which would have started the issue (way before me). I decided to look at the timesheets to make sure it will show periods 53, 54 and 55. It does not show them. It shows as 1, 2 and 3. If I type 55 in the period, it appears with the correct date. When I use the arrow to toggle to the next date, it appears as 4. If I toggle back, it shows as week 3. I confirmed that there are not predated timesheets.

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

17. RE: Project/Payroll pay period not correct

Yes you have it correct. Some users may fail to set period 53 and some may not be able to set it. That is where the trigger comes in to save you the work.Keep an eye on 1-2018 just in case some one gets a timesheet in early.In any case, you can always update the table(s) direct. Posted or not. It is never a fatal issue if a couple get past you.Mark your calendar and do it again in six years.

Thank you Beat. Your blog explained everything very well. I want to run by what my path forward will be. It is currently week 52 for us.

For the following three weeks I plan on instructing users on changing the period to the assigned week e.g. next week would be 53.Before posting of the timesheets, confirm that the period is correct.If periods are correct, post timesheets.

On 1/1/2018, change the first day of reporting to 1/1/2018 and change the reporting periods back to 52.

I believe this should resolve the issue.

Could either of you confirm this please? I want to make sure I am following the conversation correctly.

Hi @Brent MyrickSorry for the delayed reply, but I've played around with the various options of the periods setup for PA TS & PDK today, trying to validate as many scenarios as possible, to make sure I didn't miss something..A detailed blog post is going live tomorrow about this and explains the mechanic behind this setting.By analogy, the EL & ML setup follow the same rules.. but usually they are set for a daily period (365), rather than weekly (at least that's the case in our company).Now the EL & ML do suffer from the same shifting of periods over the years and need peridodically an adjustment.. like in our case, we're some 40 days behind.. It may not have the same adverse effect as for the payroll & time-sheet periods, but still can be confusing.Check it out tomorrow on http://bit.ly/GP_Geek​​

No, you are not missing anything. By setting the periods to 55, GP will now allow a period 55 but does not default it in.Normally you are only dealing with a period 53 and you make sure everyone knows to do their timesheet to period 53 not to 1. BBucher reminded me that in BP you cannot control the period.

In your case you have 53, 54, and 55 periods before you want to start again with 1 and the users will never understand it. So set the value to 55 as you have.

Then monitor your PDK10000 and PA10000 and update the Year and Period columns before you post the batches. Now it won't matter what the users send in or what defaults in.1-2018 becomes 53-20172-2018 becomes 54-20173-2018 becomes 55-2017After you have all your timesheets in for 2017 change the periods back to 52.Take a look at your tow tabkes though becasue there is alayws a few peopoel who do advance timesheets and you will need to fix them in the header

BBucher is going to comment on the firstdate of reporting period one ( I aiad leave it alone) but he is correct. It needs to be advanced so that your 2018 is clean for period 1. But let him explain.

Updating the PA10000, PDK10000, PA30100 (period and year) is safe. No issues as these are not in the periodics. Only for reporting.

I made the change and it shows up in both the setup table and window. As you can see our first date was 12/29/2003 which would have started the issue (way before me). I decided to look at the timesheets to make sure it will show periods 53, 54 and 55. It does not show them. It shows as 1, 2 and 3. If I type 55 in the period, it appears with the correct date. When I use the arrow to toggle to the next date, it appears as 4. If I toggle back, it shows as week 3. I confirmed that there are not predated timesheets.

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

18. RE: Project/Payroll pay period not correct

We've seen some bizarre behavior from BP this week, though we're only in period 51 (so not there yet for the restart of sequence), but some TS reports in some companies have been labeled with a -2 at the end, and some with -1 (as expected)..The only comonality I could find was the creation date of the document, as some employee already started/submitted their TS for this week before last friday.. The ones with a -2 were created after the period start.. but even then, I can't find any duplication in the PDK10000 table that would cause this to trigger a -2 rather than the -1 ..For now I've just renamed those TS reports and will watch the upcoming weeks.

Hi @Brent MyrickSorry for the delayed reply, but I've played around with the various options of the periods setup for PA TS & PDK today, trying to validate as many scenarios as possible, to make sure I didn't miss something..A detailed blog post is going live tomorrow about this and explains the mechanic behind this setting.By analogy, the EL & ML setup follow the same rules.. but usually they are set for a daily period (365), rather than weekly (at least that's the case in our company).Now the EL & ML do suffer from the same shifting of periods over the years and need peridodically an adjustment.. like in our case, we're some 40 days behind.. It may not have the same adverse effect as for the payroll & time-sheet periods, but still can be confusing.Check it out tomorrow on http://bit.ly/GP_Geek​​

No, you are not missing anything. By setting the periods to 55, GP will now allow a period 55 but does not default it in.Normally you are only dealing with a period 53 and you make sure everyone knows to do their timesheet to period 53 not to 1. BBucher reminded me that in BP you cannot control the period.

In your case you have 53, 54, and 55 periods before you want to start again with 1 and the users will never understand it. So set the value to 55 as you have.

Then monitor your PDK10000 and PA10000 and update the Year and Period columns before you post the batches. Now it won't matter what the users send in or what defaults in.1-2018 becomes 53-20172-2018 becomes 54-20173-2018 becomes 55-2017After you have all your timesheets in for 2017 change the periods back to 52.Take a look at your tow tabkes though becasue there is alayws a few peopoel who do advance timesheets and you will need to fix them in the header

BBucher is going to comment on the firstdate of reporting period one ( I aiad leave it alone) but he is correct. It needs to be advanced so that your 2018 is clean for period 1. But let him explain.

Updating the PA10000, PDK10000, PA30100 (period and year) is safe. No issues as these are not in the periodics. Only for reporting.

I made the change and it shows up in both the setup table and window. As you can see our first date was 12/29/2003 which would have started the issue (way before me). I decided to look at the timesheets to make sure it will show periods 53, 54 and 55. It does not show them. It shows as 1, 2 and 3. If I type 55 in the period, it appears with the correct date. When I use the arrow to toggle to the next date, it appears as 4. If I toggle back, it shows as week 3. I confirmed that there are not predated timesheets.

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

We've seen some bizarre behavior from BP this week, though we're only in period 51 (so not there yet for the restart of sequence), but some TS reports in some companies have been labeled with a -2 at the end, and some with -1 (as expected)..The only comonality I could find was the creation date of the document, as some employee already started/submitted their TS for this week before last friday.. The ones with a -2 were created after the period start.. but even then, I can't find any duplication in the PDK10000 table that would cause this to trigger a -2 rather than the -1 ..For now I've just renamed those TS reports and will watch the upcoming weeks.

Hi @Brent MyrickSorry for the delayed reply, but I've played around with the various options of the periods setup for PA TS & PDK today, trying to validate as many scenarios as possible, to make sure I didn't miss something..A detailed blog post is going live tomorrow about this and explains the mechanic behind this setting.By analogy, the EL & ML setup follow the same rules.. but usually they are set for a daily period (365), rather than weekly (at least that's the case in our company).Now the EL & ML do suffer from the same shifting of periods over the years and need peridodically an adjustment.. like in our case, we're some 40 days behind.. It may not have the same adverse effect as for the payroll & time-sheet periods, but still can be confusing.Check it out tomorrow on http://bit.ly/GP_Geek​​

No, you are not missing anything. By setting the periods to 55, GP will now allow a period 55 but does not default it in.Normally you are only dealing with a period 53 and you make sure everyone knows to do their timesheet to period 53 not to 1. BBucher reminded me that in BP you cannot control the period.

In your case you have 53, 54, and 55 periods before you want to start again with 1 and the users will never understand it. So set the value to 55 as you have.

Then monitor your PDK10000 and PA10000 and update the Year and Period columns before you post the batches. Now it won't matter what the users send in or what defaults in.1-2018 becomes 53-20172-2018 becomes 54-20173-2018 becomes 55-2017After you have all your timesheets in for 2017 change the periods back to 52.Take a look at your tow tabkes though becasue there is alayws a few peopoel who do advance timesheets and you will need to fix them in the header

BBucher is going to comment on the firstdate of reporting period one ( I aiad leave it alone) but he is correct. It needs to be advanced so that your 2018 is clean for period 1. But let him explain.

Updating the PA10000, PDK10000, PA30100 (period and year) is safe. No issues as these are not in the periodics. Only for reporting.

I made the change and it shows up in both the setup table and window. As you can see our first date was 12/29/2003 which would have started the issue (way before me). I decided to look at the timesheets to make sure it will show periods 53, 54 and 55. It does not show them. It shows as 1, 2 and 3. If I type 55 in the period, it appears with the correct date. When I use the arrow to toggle to the next date, it appears as 4. If I toggle back, it shows as week 3. I confirmed that there are not predated timesheets.

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.

20. RE: Project/Payroll pay period not correct

Mystery of the -2 extension partially explained.. for some reasons, the TS reports in some companies got assigned the Period 27 instead of 51, which caused the duplicate finding for BP / PDK.. which does not include the Document number in the validation, but only the PAYR & PAREPD combo.. if there has been already an entry with -1, the nextg becomes -2 and so on..So all I have to do is rename the PAREPD from 27 to 51 and watch for the next weekly TS.. which certainly are going to have wrong periods too.. but still can't exlplain why.​

We've seen some bizarre behavior from BP this week, though we're only in period 51 (so not there yet for the restart of sequence), but some TS reports in some companies have been labeled with a -2 at the end, and some with -1 (as expected)..The only comonality I could find was the creation date of the document, as some employee already started/submitted their TS for this week before last friday.. The ones with a -2 were created after the period start.. but even then, I can't find any duplication in the PDK10000 table that would cause this to trigger a -2 rather than the -1 ..For now I've just renamed those TS reports and will watch the upcoming weeks.

Hi @Brent MyrickSorry for the delayed reply, but I've played around with the various options of the periods setup for PA TS & PDK today, trying to validate as many scenarios as possible, to make sure I didn't miss something..A detailed blog post is going live tomorrow about this and explains the mechanic behind this setting.By analogy, the EL & ML setup follow the same rules.. but usually they are set for a daily period (365), rather than weekly (at least that's the case in our company).Now the EL & ML do suffer from the same shifting of periods over the years and need peridodically an adjustment.. like in our case, we're some 40 days behind.. It may not have the same adverse effect as for the payroll & time-sheet periods, but still can be confusing.Check it out tomorrow on http://bit.ly/GP_Geek​​

No, you are not missing anything. By setting the periods to 55, GP will now allow a period 55 but does not default it in.Normally you are only dealing with a period 53 and you make sure everyone knows to do their timesheet to period 53 not to 1. BBucher reminded me that in BP you cannot control the period.

In your case you have 53, 54, and 55 periods before you want to start again with 1 and the users will never understand it. So set the value to 55 as you have.

Then monitor your PDK10000 and PA10000 and update the Year and Period columns before you post the batches. Now it won't matter what the users send in or what defaults in.1-2018 becomes 53-20172-2018 becomes 54-20173-2018 becomes 55-2017After you have all your timesheets in for 2017 change the periods back to 52.Take a look at your tow tabkes though becasue there is alayws a few peopoel who do advance timesheets and you will need to fix them in the header

BBucher is going to comment on the firstdate of reporting period one ( I aiad leave it alone) but he is correct. It needs to be advanced so that your 2018 is clean for period 1. But let him explain.

Updating the PA10000, PDK10000, PA30100 (period and year) is safe. No issues as these are not in the periodics. Only for reporting.

I made the change and it shows up in both the setup table and window. As you can see our first date was 12/29/2003 which would have started the issue (way before me). I decided to look at the timesheets to make sure it will show periods 53, 54 and 55. It does not show them. It shows as 1, 2 and 3. If I type 55 in the period, it appears with the correct date. When I use the arrow to toggle to the next date, it appears as 4. If I toggle back, it shows as week 3. I confirmed that there are not predated timesheets.

Don't change the PA1stdatereportperiod in PA41801, just the PAnumofreportingperiods.

The PA1st date controls what day of the week your period is to start such as Saturday or Sunday..If the period start and end dates are correct in the week, leave that column alone.

Increasing the PAnumber of periods just extends your year such that it gets to the end of the year before starting period 1, 2018 which is what you want.

When you have a 53 period year it will look like this: PDK BP uses the same tableThis year things are clean and neat as Monday is Jan 1, 2018 and normally the start of a new year and Period 1.

Make it so :)

Edit: in this screen shot my Period is Monday to Sunday. But it can be whatever you want such as Sunday to Saturday. This comes from PA1stdatereportperiod in PA41801, not the PAnumofreportingperiods which controls the length of the year.

Thanks Thaddeus,Going to look into the tables you reported.. My early tests yesterday showed that PDK is not taking care of the setting of PA in GP, when pushing this to 55, it remains at 52 in PDK and thus start period 1 in 2017 again.. which is not good. Onyl a day change from the original start date in GP would make PDK behave correctly..

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

This is a routine update. When your Period 1 creeps back into the previous calendar year from Jan 1 or Dec 31, you must update the PA41801 table every six years.

Both PDK and BP follow from PA. Neither are hardcoded to 52 weeks. They follow the PA setting.

Update the column PAnumofreportingperiods in PA41801 to 55 now so that your 2017 year will end on period 55 and 2018 will start on period 1. It is a single place update

A few weeks into 2018 go and update the PA41801 PAnumofreportingperiods back to 52. You are now good to go for 2018.

The only reason you have to set it to 55 ( in the original post) is because you had period 1 creep about 3-4 weeks back into 2016 from 2017 so 2017 probably started with period 4 or 5. 2017 should have had 53 periods. You just need 55 now so that 2018 starts correctly with period 1.

When you are doing this update regularly, then you set every sixth year to 53 and then set it back to 52.

Since you are setting 2017 to 55 rather late in the game you must also query your PA10000 and PDK10000 tables and look for any forward timesheets entered that may already show as PAREPD (Period 1,2,3) etc of PAYR 2018. If you have these, they must be updated back to what they should be i.e., PAREPD 53, 54, 55 for PAYR 2017. If some are already posted, the same fields need to be updated in the PA30100. PDK does not have a history table

There are no reconciles or checklinks needed. It is a one table one field update

Thank you all for the information. I am going to give you suggestions a shot in our test environment. I am not confident in our VAR to be able to handle this properly. That was why I knew this brain trust would be a better solution. I will report my results soon.

Yes, You must change the PA Timesheet setup periods from 52 to 53 and then back to 52 every few years else your period 1 will start to creep back into the previous year.This is done in a single place and is easy if you watch your timing.

If people are already entering forward timesheets for vacation etc, then some transactions may need to be fixed but you can avoid this by watching the timing of the period change.

Your VAR should be very experienced at doing this period update for PA Timesheets as it affects everyone who uses a 52 week year. 52 x 7 = 364 days not 365 so you get period "creep" of one day each year. And 2 days on a leap year.

Last year (2016) was a 53 week year so your Project Accounting settings should have been 53 weeks last year not 52 weeks. Each year you slip 1 or 2 days as 52 weeks does not = 365 days.You must add the 53rd week every 5-6 years.

This year (2017) then would have been OK but.... your 2015 was wrong and maybe even earlier.

The 52 week period should normally be ending this year on exactly Sunday 12/31/2017.

The current period 11/27-12/3 should be period 48 not 51 for a calendar year.

The resolution for you is to set 2017 in PA to have 55 weeks so that period 55 for 2017 ends on 12/31/2017. Then you reset it back to 52 weeks for 2018 before people start entering 2018 time.

If you do not set it forward in 2017, then Period 1 for 2018 for you will begin on 12/11/2017. Probably not what you want.

It has been noticed by our payroll person that the Time period is not correct. We are suppose to be on week 50 but the screen shows 51. This is the highlighted item on the picture below. We believe this is due to leap year but are not 100 percent sure. We are wondering what our options would be to resolve this issue. I know I can change the starting date in payroll setup but do not know what all that will touch. If this is the correct solution, would it be best to change it at the beginning of our new payroll year.