Hello Melanie.

I'm not sure if this will help but it sounds to me like it's a SQL security problem. We experienced similar errors with calculating payroll for non "master" user's that started in HRMS 2012. We ended up having to create explicit user accounts in SQL Server Management Studio Security , assigning all users to the public and sysadmin server roles, otherwise, calculate pay would not work for us either unless you were a master. I don't know if this is the same message, but it sounds like a similar problem.

Hope this helps.

Terry

How long have you been on HRMS? Did you use Abra Suites before going to SQL HRMS?

We've been on HRMS since 2013, started with 2012, have upgraded to 2015 and I'm currently looking at the upgrade to 2016. Prior to that, we were on Abra Suite from 2001 to the time of migration to 2012

I am still on Abra Suite but need to migrate to HRMS SQL. Did you change at the first of the year or with the data transfer over seamlessly. HRMS is going to be my 1st qtr project. Any advise?

We cut over mid-year (October 2013) and migrated our data. Our business partner did all the work for migration because there are changes to the tables. We are running Canadian Payroll and the HRMS is very different than ABRA. For your first time, I would recommend working with your Sage business partner; it took us three attempts to migrate the data because of various problems, then the parallel payroll runs to make sure everything was covered.

Are you happy with the end results of HRMS? Do you use ESS?

We do use ESS. It's a pretty good product but we had some issues with ESS that cannot be resolved so we just make it work. For example, we have four sick leave codes that roll into one sick attendance plan; of the four, two of them require monitoring because they have a limited amount of hours an employee can use in the plan year; ABRA used to allow us to monitor it automatically; with ESS, managers have to monitor it manually for usage. We can record the transaction in ESS, but cannot separate the transactions because of the database key it uses identifies it as a duplicate key; the other is we cannot distribute our employee's Revenue Canada T4 annual tax reporting; we still have to do those manually.

One significant issue with ESS is there is no plan year validation; so as long as an employee has a balance on their Vacation, for example, they can enter any date as the transaction date, even if it's in a prior plan year. How we found this out was through reporting; We've had to create reports to monitor the data to identify when this happens so the transaction can be fixed.

We're fairly satisfied with HRMS; we had some issues that have been sorted out. We have a considerable number of cost centres (GL Distribution codes) and while ABRA required you to enter a new cost only once, in HRMS it must be added in many places. For example, the creation of one cost centre code or GL distribution code, must be added to every earning, deduction, benefit, or taxable benefit code, one at a time. In our organization, the addition of 1 GL distribution code, ends up requiring 175 entries into HRMS; which use to take me a half a day to enter into the system. I have since written a SQL script that automates this process and it now takes 30 seconds.

It took us about 3 months to stabilize the payroll system after implementation due to various issues; when we moved from 2012 to 2015, it presented other issues and it once again, took us 3 months to stabilize the payroll processing.

Overall, we are satisfied with the system because we now know how to manipulate the things we need in order to have success with each pay cycle.

Thank you very much for all of the information and you time. Have a Merry Christmas and Happy New Year.

Terry thank you so much for your help! I am absolutely going to give it a try as it HAS to be a SQL security issue as I've tried everything else. I will let you know if that works! Thanks again.