Open Forum

Like what you see? Discover the benefits of the GPUG Community. Learn More

Project/Payroll pay period not correct

  • 1.  Project/Payroll pay period not correct

    SILVER CONTRIBUTOR
    Posted 11-28-2017 07:43 PM
    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.



    ------------------------------
    Brent Myrick
    IT Application Specialist
    City of Ellensburg
    Ellensburg WA
    ------------------------------


  • 2.  RE: Project/Payroll pay period not correct

    TOP CONTRIBUTOR
    Posted 11-29-2017 08:16 AM
    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.

    ------------------------------
    Thaddeus Suter
    Retus, Inc
    TX
    ------------------------------



  • 3.  RE: Project/Payroll pay period not correct

    SILVER CONTRIBUTOR
    Posted 11-29-2017 08:40 AM
    ​Are you saying to change the number of reporting periods per year in the several PA setup windows once the next reporting year starts?

    ------------------------------
    Al Schuette
    Senior Business Consultant
    Heartland Business Systems, LLC
    Little chute WI
    ------------------------------



  • 4.  RE: Project/Payroll pay period not correct

    TOP CONTRIBUTOR
    Posted 11-29-2017 08:55 AM
    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.

    ------------------------------
    Thaddeus Suter
    Retus, Inc
    TX
    ------------------------------



  • 5.  RE: Project/Payroll pay period not correct

    GPUG ALL STAR
    Posted 11-29-2017 11:16 AM
    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.. :-(​​​​​​​

    ------------------------------
    Beat Bucher
    Business Analyst, Dynamics GP MVP
    Ultra-Electronics Forensic Technology Inc.
    Montreal QC/Canada
    @GP_Beat http://dyngpbeat.wordpress.com/
    Montreal QC GPUG Chapter Leader
    GP2013R2 / MR2012 CU14
    ------------------------------



  • 6.  RE: Project/Payroll pay period not correct

    SILVER CONTRIBUTOR
    Posted 11-29-2017 07:19 PM
    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.

    Thanks again.

    ------------------------------
    Brent Myrick
    IT Application Specialist
    City of Ellensburg
    Ellensburg WA
    ------------------------------



  • 7.  RE: Project/Payroll pay period not correct

    TOP CONTRIBUTOR
    Posted 11-29-2017 10:18 PM
    Folks,

    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

    ------------------------------
    Thaddeus Suter
    Retus, Inc
    TX
    ------------------------------



  • 8.  RE: Project/Payroll pay period not correct

    SILVER CONTRIBUTOR
    Posted 11-30-2017 08:26 AM
    ​If you are doing reporting off the periodic history, won't it cause you a problem if timesheets have 55 periods this year but equipment log and misc log only have 52?

    ------------------------------
    Al Schuette
    Senior Business Consultant
    Heartland Business Systems, LLC
    Little chute WI
    ------------------------------



  • 9.  RE: Project/Payroll pay period not correct

    TOP CONTRIBUTOR
    Posted 11-30-2017 09:17 AM
    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.

    ------------------------------
    Thaddeus Suter
    Retus, Inc
    TX
    ------------------------------



  • 10.  RE: Project/Payroll pay period not correct

    GPUG ALL STAR
    Posted 11-30-2017 08:41 AM
    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.
    Thaddeus Suter,  11-29-2017 10:18 PM
    :-) .. the problem, nobody cared about this for the past 10 years.. ending up with the shift we have now. Need to fix it for 2018.


    ------------------------------
    Beat Bucher
    Business Analyst, Dynamics GP MVP
    Ultra-Electronics Forensic Technology Inc.
    Montreal QC/Canada
    @GP_Beat http://dyngpbeat.wordpress.com/
    Montreal QC GPUG Chapter Leader
    GP2013R2 / MR2012 CU14
    ------------------------------



  • 11.  RE: Project/Payroll pay period not correct

    TOP CONTRIBUTOR
    Posted 11-30-2017 09:29 AM
    Edited by Thaddeus Suter 11-30-2017 09:33 AM
    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 table
    This 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.

    Thaddeus Suter
    Retus, Inc
    TX
    ------------------------------



  • 12.  RE: Project/Payroll pay period not correct

    SILVER CONTRIBUTOR
    Posted 11-30-2017 02:35 PM
    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.

    Am I missing something?

    By the way, I love this thread. I am learning so much.



    ------------------------------
    Brent Myrick
    IT Application Specialist
    City of Ellensburg
    Ellensburg WA
    ------------------------------



  • 13.  RE: Project/Payroll pay period not correct

    TOP CONTRIBUTOR
    Posted 11-30-2017 03:32 PM
    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-2017
    2-2018 becomes 54-2017
    3-2018 becomes 55-2017
    After 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.

    Be glad you only do this every six years!

    ------------------------------
    Thaddeus Suter
    Retus, Inc
    TX
    ------------------------------



  • 14.  RE: Project/Payroll pay period not correct

    GPUG ALL STAR
    Posted 11-30-2017 09:25 PM
    Edited by Beat Bucher 12-01-2017 01:19 PM
    Hi @Brent Myrick
    Sorry 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​​

    Edit: blog post link
    ------------------------------
    Beat Bucher
    Business Analyst, Dynamics GP MVP
    Ultra-Electronics Forensic Technology Inc.
    Montreal QC/Canada
    @GP_Beat http://dyngpbeat.wordpress.com/
    Montreal QC GPUG Chapter Leader
    GP2013R2 / MR2012 CU14
    ------------------------------



  • 15.  RE: Project/Payroll pay period not correct

    TOP CONTRIBUTOR
    Posted 12-06-2017 09:43 AM
    Folks,

    One of our GP instances needed to do this fix this year so to add some elegance since timesheets coming from BP will not get the correct period and the user cannot edit the period.

    Here is a trigger for the situation where you have a period 53 issue this year and your week starts on Sunday for time reporting.

    CREATE TRIGGER [dbo].[zzTLS_PA10000_Fix Period 53]
    ON [dbo].[PA10000]
    AFTER INSERT, UPDATE AS
    SET NOCOUNT ON
    UPDATE PA10000
           SET PAYR = 2017,
                   PAREPD = 53
    where PAREPDT = '2017-12-24 00:00:00.000'
    SET NOCOUNT OFF

    This triggers cleans up any bad records that are already in PA10000 as well as fixes any new records prior to posting.

    You would also add the trigger to PDK10000. The columns are the same.

    Where you have periods 53, 54, 55 to deal with, you would need to edit the trigger to accommodate all three periods.

    You may also have to update period 1, 2018 if people start entering those timesheets before you advance your first period reporting date so that period 1, 2018 starts correctly without a trigger.

    Do your updates from the PAREPDT which is the first date for your timesheet period and is unique to the timesheet period and the year.

    ------------------------------
    Thaddeus Suter
    Retus, Inc
    TX
    ------------------------------



  • 16.  RE: Project/Payroll pay period not correct

    SILVER CONTRIBUTOR
    Posted 12-06-2017 06:45 PM
    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.

    ------------------------------
    Brent Myrick
    IT Application Specialist
    City of Ellensburg
    Ellensburg WA
    ------------------------------



  • 17.  RE: Project/Payroll pay period not correct

    TOP CONTRIBUTOR
    Posted 12-07-2017 09:36 AM
    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.

    ------------------------------
    Thaddeus Suter
    Retus, Inc
    TX
    ------------------------------



  • 18.  RE: Project/Payroll pay period not correct

    GPUG ALL STAR
    Posted 12-07-2017 12:26 PM
    Thanks Thaddeus for posting this suggestion..

    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.

    ------------------------------
    Beat Bucher
    Business Analyst, Dynamics GP MVP
    Ultra-Electronics Forensic Technology Inc.
    Montreal QC/Canada
    @GP_Beat http://dyngpbeat.wordpress.com/
    Montreal QC GPUG Chapter Leader
    GP2013R2 / MR2012 CU14
    ------------------------------



  • 19.  RE: Project/Payroll pay period not correct

    SILVER CONTRIBUTOR
    Posted 12-07-2017 12:31 PM
    Thank you Thaddeus and @Beat Bucher so much for the knowledge.  This is the major reason why I love this community. ​​

    ------------------------------
    Brent Myrick
    IT Application Specialist
    City of Ellensburg
    Ellensburg WA
    ------------------------------



  • 20.  RE: Project/Payroll pay period not correct

    GPUG ALL STAR
    Posted 12-08-2017 08:40 AM
    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.​

    ------------------------------
    Beat Bucher
    Business Analyst, Dynamics GP MVP
    Ultra-Electronics Forensic Technology Inc.
    Montreal QC/Canada
    @GP_Beat http://dyngpbeat.wordpress.com/
    Montreal QC GPUG Chapter Leader
    GP2013R2 / MR2012 CU14
    ------------------------------