YTD totals incorrectly showing on payslips

Jocelyn

Hello,

It has been recently bought to my attention that YTD totals for our employees are not showing correctly on their payslips. It is only showing the totals for the previous month, not for the entire year which up until midway through January it was occurring correctly.

We recently had email sending issues so payslips weren't sending.

What can we do to fix this?

TIA

Acctd4

Hi Jocelyn

It’s difficult to speculate without seeing the file/transactions but a few things to check ...

1. Is the file being verified regularly (via File > Utilities > Verify Data option) ? If not, please do this then run the Rebuild Data option x 3, to see if this resolves it.
2. Check the Payroll Items used/shown - Have you used more than one that together total the final YTD figures (eg Hourly, Sick Hourly, Hol Pay etc) ?
3. Are you using one of the Reckon default Payslip templates or are your Payslips on a Custom Template ? If Custom, please try generating the applicable Payslip(s) on a Reckon default Payslip template & see if the issue is still present. (In some cases, the occurrence of this anomaly can be directly related to the Custom template, suggesting some corruption within that specific form)

Rav

Hi Jocelyn

Is this occurring for all employees or just a selected one/few?

Jocelyn

I have checked over a dozen of our employees and they are all showing the incorrect total. We have over 90 employees.

Rav

Ok thanks for that Jocelyn.

I've just had a quick word with the tech support team about this one and they've suggested the help guide below should help with this situation -

https://help.reckon.com/article/6e1pbelnij-kba-5623-leave-amount-is-incorrect-in-the-payslips-although-it-is-correct-in-the-employee-s-record

Acctd4

@Rav I don't think it's the leave that Jocelyn is referring to but rather the YTD $ amounts ?

Jocelyn

We did a verify and 3 x rebuild and it has fixed the problem. Thank you. Hopefully no more dramas!

Dianita

Hello Team,

@Rav and Shaz @Acctd4, is there anything else you could suggest to by-pass this issue of YTD amounts are not showing correctly in the payslips. After rebuilding a Reckon data test file 3 times, I rerun a few payroll runs, printed the payslips using the Reckon default template (not our standardised template), however the figures still show incorrectly. I have taken a few test samples that illustrate that the issue is affecting different payroll items, see below:

Not sure what this $0 YTD amount is related to

This one is attached to the YTD of back pay only

This one is attached to the YTD of personal salary

These two samples below have lines of 'personal salary', but unlike the above example remain unaffected.

Do you have any theory what caused this and suggestion(s) on how we can fix this issue? When we ran the testing, they were affecting random staff members and payslips from different pay periods as well. There was no one consistent cause that was breaking it. Looping in @Radhika in here.

Thanks and look forward to hearing back from you.

Regards,

Nita

Acctd4

Hi Nita

Hmm ... that's quite a mystery 😒 Can you pinpoint when the issue started ?

You may have a more significant data corruption issue there that may require Reckon's data services intervention. However, this is a paid service 😬

What are your thoughts @Rav ?

Dianita

Hello morning Shaz,

Unfortunately, I won't be able to pinpoint the exact timeline as it could have happened a long time ago, but we did recently cut down all our Reckon file (and 22nd Jun 2023 was the cut off). The returned file from the Reckon Data Recovery team was a shelled 'blank' file. It only contained the existing card files (e.g. lists, payroll item list, customer centre, employee centre, chart of accounts, etc). It had 0 transactions. We migrated the open balances via IIF file uploads. Since then, we have performed very regular backups and data verification (however never a rebuild).

Regards,

Nita

Acctd4

Hi Nita

Run the Rebuild x 3 on this new file (just noted you did this in a sample file but not this one 😬)

Rav

Hi @Dianita

I'm not quite sure what the cause of this could be but I put forward your situation to our tech team and they just want to clarify something -

Is this problem occurring in the data file provided by the Data Recovery team which you added new transactions to after it was returned with only list data?

And your existing file with historical data?

From what I've gathered its the former however as Shaz has mentioned I would strongly recommend running rebuilds on it and just confirm whether that gets things back on track.

Dianita

Hello morning Team,

Thanks for this.

@Acctd4 Shaz I actually did run the rebuild x 3 in one of the older back up file (a copy from 30th Oct morning). It just took so long when I ran it in the live file at 6 am yesterday, could not finish in time before 8, so I had to abandon. The files are almost entirely identical.

I did try doing it in the live file this morning (but again, did not even finish doing even the 1 file rebuild before 8 am), had to sadly abandon it. It stopped doing the backup at 92% for more than half an hour.

Might have to do it over the weekend (i.e. if I have to run it 3 times).

@Rav it is hard to tell as I would not be able to know which payslips affected to check but yes, I do believe it is very probably that the issue may have presented itself in the older file that was submitted to the data rec team back in May-Jun. Our original plan was to actually remove only transactions prior to 1 Jul 2019, but it took Omar so long as he did (later on) confirm that the file could have been corrupted. We then decided just to remove all the transactions from in there.

I will try running that rebuild in the live file per suggestion and assess that one instead.

With the check post 3x rebuild, could I confirm again please that it will fix the historical payslips or just for the future ones?

Thank you and regards,

Nita

Dianita

Morning Team,

I have rebuilt the file 3 times over the weekend. The first took 2 hours, the second and third took around 4 hours. For some reason the file size tripled (from the typical copy and paste method, I was told that I could do this type of back up as well in June). Does this seem normal to you?

Also, just to confirm my question again from last week, when I check for this YTD issue, will that reflect in the future payslips only or will that reflect in the previously recorded slips?

Thanks and regards,

Nita

Acctd4

Hi Nita

I believe the file size increase can happen (not sure why though, @Rav will likely know more about the technical side than me) but saving & restoring a portable file instead, will decrease the file size.

I note you started with a lists-only, fresh company file not very long ago so I'm wondering why the size has blown out so dramatically ... & so quickly ! Are there a lot of blank or $ 0.00 lines in your transactions (for example, unused lines autofilling from a previous entry with no value on them) ? The file size - & backup file size - seem very excessive given the short timeframe 😲

Changes to leave entitlements - as well as Payroll Items (names, their linked accounts & tax tracking) - will reflect on historical Paycheques. Note the YTD will be in real time so whilst reflective of Payroll Item changes, entitlements & $ values will display as at the specific pay date.

Dianita

Morning Shaz,

Thank you for your reply.

I had a look at some of the confirmed problematic historical payslips, their YTD amounts were unfortunately all still showing incorrectly. Not sure what else can be done. We will continue to monitor subsequent payslips, hopefully (at least the future ones) will be ok. Do you recommend doing a rebuild every month?

With regards to the $0 transactions, yes, I believe we do have quite a lot as our purchase orders are not always assigned to one bill/ in one go. Our suppliers do tend to split the billing, depending on which items are shipped first. Is there a different way to assign the items that will allow the PO to remain open? We did find that by not zeroing the items in the latter shipments, we would not be able to see the PO again in the drop-down list. An example is below. So yes, if the PO has 50 lines and split into more than one bill, some of the items (whilst in $0) would be repeated a few times as well.

Also, to give Rav a little bit of illustration, when it was shelled in Jun/ July, our file size was just under 300 MB (almost blank), with some migrated open balances. The ones that have no 'backup' in the name were just copy paste of the LIVE file. There were two that were back-up'd from Reckon. The file size difference is not a lot.

This one for Nov however, the difference is huge. Again, the copy paste version is only a little bit bigger than in July by around 150 MB.

Thanks and hopefully you can give me some more feedback on how to slow the exponential growth of this file size.

Regards,

Nita

Dianita

@Kelvin FYI, re: size anomaly and payslip YTD issue

Rav

Hi @Dianita

I've been speaking with my friends in the Data Recovery team about your case and a QBB that increases in size to that extent when compared to the QBW file indicates that there is actually a very large TLG file that is being included with the QBW inside the QBB.

This means that the QBW file has not undergone a backup with complete verification enabled. When this is enabled when the backup is performed, the built-in verify data is first run through the QBW file. If there are no errors detected then it resets the TLG back to a tiny size, and the QBW is compressed and bundled inside a QBB file.

Can you please take a screenshot like you have above but instead show the QBW file AND the TLG file just so we can confirm the size of the TLG file.

Also, can I get you to do the following -

• Rebuild your file
• Verify your file

Then once done, send me a private message with a copy of the QBWIN.LOG file which will show these two operations along with any errors detected/corrected (if any).

Acctd4

Hi Nita

It may not reflect these changes historically on the Payslips but should reflect on screen in the Paycheques themselves.

Always delete all unused $ 0 lines from transactions! Having excess lines with no value increases the file size & clogs it with empty data. Note: Doing this doesn't affect any linked forms (SOs, POs etc) as any lines not "Received" - with a quantity - will still remain open.

Dianita

Noted on the point re: YTD paycheques and payslips, thanks Shaz.

Also re: PO, I am sure we couldn't partially receive the PO's as they did not use to show. Now I tested it again, it worked. I'll let our accounts payable team know so that they can start doing this/ or at least testing.

Thanks and regards,

Nita