"Background process is running: Exit Aborted" message when trying to close GP

By Steve Endow

I am developing a Dynamics GP VS Tools AddIn for a customer, and while testing the AddIn, I started to get this message when I tried to close GP:

"Background process is running: Exit Aborted"

In my VS Tools AddIn code, I am accessing a table buffer, and during my first few versions of the rough code, I had forgotten to close the tables.  This left them open, and caused GP to think that they were still being accessed.  So I added the following lines to close the table buffers:

paBillingSubDetailWorkTm.Close();

paCostCategory.Close();

But even after that, I would still get the Background Process message from GP.

After further review, I realized that I did not have a Try / Catch block in my code yet.  So an error was causing an exception before the Close commands were processed.

After adding the Close commands in a Finally block, the Background Process message went away.

As my daughter says, "Easy peasy lemon squeezee"...

Update: This issue was discussed by David Musgrave in a blog post back in 2009.  Funny that I had this problem back in 2010 and posted a comment on his blog.  And now four years later, I made the same mistake again!

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

Adding 1099 Box Number to Reports

A shout out to the fabulous Patrick Roth at Microsoft for pointing me in the right direction for this one.  We had been trying to add the 1099 Box Number from the Vendor Maintenance Options window to the 1099s Printed report (printed from the Print 1099s window in GP).

There is a KB article that talks through the process of adding the Vendor Contact Name to the 1099 forms.  So it seemed easy peasy, just do the same for the 1099s Printed report.  Follow the same KB, but add the 1099 Box Number instead.  http://support.microsoft.com/kb/863177

Of course, not that easy peasy.  We added the field, but nothing printed.  Ugh.  I went looking for a function or calculated field to pull the information.  But I couldn't find anything. Fortunately, Patrick pointed me in the right direction- to look at the Vendor Information report.  Sure enough, there was a calculated field using a User Defined function (it appears under the System series).

I created the calculated field and it worked like a charm :)

I know the time for this has passed for this year, but thought I would put it out there for next year :)

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a senior managing consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

Recreating Year End Wage File After 2014 Payrolls

Ah, Payroll Year End.  It deserves to be capitalized.  So much fun, in such a short time frame :)  Just a quick reminder post that you can recreate the Year End Wage File if absolutely necessary after running 2014 payrolls.  Assuming you have applied the 2014 payroll tax tables, you simply need to run the following script (Courtesy of Terry Heley at Microsoft)...

UPDATE UPR10100 SET FICASSWL='113700.00000' WHERE RPTNGYR ='2013'

Then you can remove and rebuild the year end wage file (GP knows to only include 2013 activity). Of course, ALWAYS MAKE A BACKUP BEFORE DOING STUFF LIKE THIS.

Hopefully we are over the hump for the year, but thought I would put this out there just in case.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a senior managing consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

Tracking Actual Hours Worked in Payroll

There is no good excuse for my absence from blog land in the past few months.  It seems like I came out of Technical Airlift and GPUG in to a whirlwind of holidays, projects, and January 1st go lives.  So in all of that, the rhythm of posting to the blog just sort of faded.  But with a new year comes renewed commitment!  I know Steve managed to post last week, so I don't want to be outdone! Especially by a developer! :)

So, here I go.  A common theme lately among our payroll implementations is the need to track actual hours worked, not just what a person was paid for.

You: "But wait, why would someone work more or less hours than what they are paid for? "
Me: "Well, if someone gets paid a day rate for a certain job, or sometimes salaried people"
You: "Oh, well, wouldn't a timeclock track that?"
Me: "Sure, but a lot of times these folks aren't part of the timekeeping system."
You:

Well, maybe "stunned silence" is a bit melodramatic.  But we have seen an uptick in the need to track the hours worked, sometimes for reporting and analysis purposes, or for communicating to employees.

Fortunately, this is easy enough to do in Dynamics GP.  Simply set up a piecework pay code, Setup-Payroll-Pay Code:

We pick piecework so the hours don't interfere/add to the existing hours that are being calculated based on the salary (and hourly if applicable) pay codes.  If you have an instance where employees are not using salary or hourly pay codes for their base pay, you could technically use an hourly pay code to do this.  The two key fields, in any case are the Pay Type (in this case, Piecework) and the Pay Rate (which should always be zero).

You can then assign the pay code to the employee using Cards-Payroll-Pay Code.  Make sure that the rate is still zero, because we are not using this code to pay the employees- only to record their hours worked.  Then you can record the hours worked (or import them) using Transactions-Payroll-Transaction Entry.

A simple thing to do, but then the hours are available for reporting out of the payroll module, and will appear on employee's pay stubs.  You can use this same process also to record miles driven (use a different pay code, of course).  When reimbursing mileage, you will want to use a Business Expense type pay code so that the reimbursement does not add to gross wages.  But you can record the actual miles driven using a Piecework type pay code, to show employees the miles recorded.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a senior managing consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.