Tuesday, August 16, 2011

Payroll 941 Mystery Solved (or The Case of Missing Table)

If I was asked by a payroll person for one piece of advice, I would tell them to always make sure they have a backup before printing and posting payroll.  So much trauma could be avoided if restoring a backup after a payroll posting gone wrong was possible.

And then, if they allowed me, I would provide two more:

1.  If you run in to problems printing and/or processing the payroll prior to posting, DO NOT go ahead and post it.  Cancel out of it.  Your transactions will be available to be included in a new build, and you won't have to worry about cleaning up a partial posting.

2. Any time you use manual checks to record adjustments or corrections, always make sure you check and double check the taxable wages and employer FICA taxes (as these are not detailed on the edit list).  Mistakes in these two fields when manually entering payroll information account for many 941 and payroll summary reconciliation issues.

But, let's get back to payroll posting gone wrong :)  Recently I had a case where the payroll printing was interrupted when the server was shut down accidentally.  When the server came back up, the user attempted to post the payroll and received errors.  Fortunately, they were able to send out the checks since they had already been printed successfully.  And then we were able to set about fixing the posting.

We found that the posting interruption appeared to occur between updating the check history (UPR30100) and transaction history (UPR30300) tables.  The check history had the checks listed, but the transaction history table was blank for the audit trail code.  So we removed the stranded records from the UPR30100, and the users could then re-enter the payroll through manual checks (Transactions>>Payroll>>Manual Checks).  Fortunately, they had all of the information to do this and a small number of employees.

After completing this task, though, the 941 was still off.  Payroll Summary (Reports>>Payroll>>Period End) looked great.  As did the wage amounts from the 941 (Reports>>Payroll>>Quarter End).  It was all in the taxes, they appeared to be double what they should be, and the 941 schedule B also showed double for that payroll date.

Head-scratcher, huh?  Probably not for those of you who know better.  So I went looking in Utilities>>Payroll>>Edit Liabililties and I saw it!  The check run had posted its information in the Payroll Tax Liabilities table (UPR30200).  So once we removed the record from there as well, all was right with the world.  So the lesson here is not forget about the UPR30200, particularly with posting interruptions as it seems that it posts the summary level info before the detail info.

As someone who has avoiding getting in to the realm of "fixing" payrolls that have gone wrong, it has been quite a learning experience for me to move beyond insisting users restore backups when these issues are encountered.  I am still not sure what is better, though...losing the work associated with restoring a backup or the time involved (usually with a consultant) to clean it up if you don't.  And then you add in the concern of making sure that the client understands what you are doing and why so that questions don't come up later regarding all the "back-end" fixin'.  Jury is still out for me, but maybe I am more old-school than I thought ;)

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising 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.

Monday, August 8, 2011

Reporting Puzzle (2 of 2)- Report Options and Report Groups

(UPDATED 8/9/2011) Thanks to Mariano Gomez for a bit of clarification on this one :)

As is noted in the user guides, there is a limit to how many reports can be put in a report group (for example, Reports-Financial-Groups).  Each report group can only contain 32 reports.  This isn't too big of a deal, since you can simply set up additional groups, right?

But, there is a bit more of a dilemma.  Let's say that I have a report that has 33 report options set up for it.  In this case, Reports-Financial-Trial Balance:

Reports-Financial-Trial Balance
Trial Balance Report window

Note the 33 report options set up for the Detailed report.  So, then, let's say I want to add some of these report options (particularly the 33rd option) to a report group.  Reports-Financial-Groups:

Reports-Financial-Groups
Financial Groups window


In the Financial Groups window, I start a new report group.  But, notice that the 33rd option is not even available for selection.  So, although I can create more than 32 options for a report, only the 1st 32 report options are available for selection in a group.  The lesson learned is that you have to set up the report options you want in groups first, so that they are among the first 32 options on any given report.

Although this can be confusing, this is NOT the same as the fact that a report group can only contain 32 report options.  In the case noted above, my report group is brand new with no report options in it...and yet, I still can't pick to include the 33rd report option from the Detailed trial balance report to the group.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising 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.

Reporting Puzzle (1 of 2)- Dynamics GP SQL Financial Trial Balances

Along with a coworker, I have been chewing on a SQL Reporting Services (or so I thought) issue for the past few weeks.  Users had reported that both of the financial trial balances (Detail and Summary) in SQL Reporting Services were not returning results.  The report worked fine for them in TWO (Fabrikam), but not in either their live or test database.  Strange.  And even stranger, the report worked fine if we changed the data source to use the 'sa' user and password.

I felt like we had checked everything, including:
  • Confirmed access to reports in Report Manager, and access to Data Source- other reports work fine (including other financial reports)
  • Confirmed the database roles- all affected users had rpt_poweruser roles to both the company and DYNAMICS databases
  • Placed users in to SYSADMIN server role for testing- still didn't return results
  • Recreated stored procedures used by report- no luck
  • Recreated report itself- running out of ideas
What we found through all of this testing is that a) no errors were being returned (yes, we did a trace to confirm this) and b) when running the stored procedure in SQL Server directly, we still did not get results.  We found any number of blog posts related to similar issues, but these all had to do with GP2010 R2 and the temp table not populating correctly.  We were on GP2010 SP1, so it didn't seem likely that it was the same issue.  We started a case with Microsoft, and after a couple more weeks of working on it back and forth we uncovered the rather embarrassingly simply cause. Three words.  Account. Level. Security.

So, the SSRS financial trial balances use the same stored procedure that is used for the trial balance reports in Dynamics GP.  This stored procedure incorporates account level security.  In our company (and test company), account level security (organizational structures) is activated (Tools-Setup-Company-Company).  So when the report is generated, it cannot locate any accounts based on the user's security (since the SSRS reports use windows credentials, not the GP user accounts). This causes the report to not return any results, and does not produce any errors.

Simple cause.  The workaround is to change the data source for the report to use the 'sa' user and password.  If you choose to do this, keep in mind that all users who have access to the report will in turn have access to all data.  In our situation, this works since the only users who can access the report are allowed access to all accounts.  In a more restrictive environment, I think you would have to look at modifying the report to map the windows accounts to GP accounts.  If you did this, you would need to take care not to affect the stored procedure used by the standard Dynamics GP reports.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising 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.

Thursday, August 4, 2011

A Matter of Degrees? Activity Tracking and Dynamics GP

More and more, it seems like the answer to most Dynamics GP questions is "well, it depends."  It might depend on how much money you want to spend on services and/or software, or how much you care about a particular piece of functionality.  And, lately, it seems like I am getting a lot of questions related to tracking changes within Microsoft Dynamics GP.  Sometimes this is due to "damage control", or because a prior system had the capability, and in most cases I completely understand the concern and the request.  And, like I have suggested, the answer is not a simple one.  There are several options available to you, depending on how much time/effort/money you want to spend.

At the very basic level, GP offers a few inherent tracking tools, for example:
  • Many transactions table provide tracking of the user who posted the transaction (not who entered it, but who posted it).  These fields are visible in Smartlist (Microsoft Dynamics GP menu-Smartlist), for Financial-Account Transactions the field is called User Who Posted and for Purchasing-Payables Transactions it is called Posted User ID.  Some records also provide a modified date, although it does not show who (Purchasing-Vendors, for example).
  • With the Human Resources module, tracking is enabled in the form of a "reason for change" on pay and position changes.  This enables reporting of who, what, and why on the changes.  Although it does not track the before/after values (which could be inferred to some degree based on the change)  Depending on your configuration in Microsoft Dynamics GP menu-Tools-Setup-System-HR Preferences, entering a "reason for change" may not be required. 
  • There are controls available for batch approval and posting permissions through posting setup (Microsoft Dynamics GP menu-Tools-Setup-Posting-Posting) and security setup (Microsoft Dynamics GP menu-Tools-Setup-System-User Security) to control who can post transactions.  This is less tracking, but does help with the "damage control" requirement as security can also be used to limit access to master records, utilities, etc.
These are often some of the first options I look at, but GP also offers a couple additional options depending on your needs. One is included with GP, the other is an additional purchase:
  • Activity Tracking- Tracks a number of tasks in GP, with basic information related to who, what and when.  This is included in core Dynamics GP.
  • Audit Trails- This is an additional module that tracks the who, what, and when in detail including the before and after values of the field.  Audit Trails actually creates a separate database to track the audit information, and is configured to track changes based on your specific needs.  For more information, refer to this Microsoft Dynamics site on compliance, which includes a link to a fact sheet on the Audit Trails and Electronic Signatures modules.
We are going to take a look at the capability provided by the Activity Tracking feature included in core Dynamics GP.  First, let's look at the setup:


Activity Tracking Setup window
Microsoft Dynamics GP-Tools-Setup-System-Activity Tracking

Use this window to configure Activity Tracking, but be careful to only activate those items that you actually think will be useful (as this can add ALOT of records to your database very quickly).  There are five different types of activities you can track:
  • Login/Logout Tracking- Tracks unsuccessful and successful attempts to log in to Dynamics GP
  • Access Tracking- Tracks unsuccessful and successful attemps to access a file, window, report, or the Modifer and Report Writer tools
  • File Tracking- Tracks additions, deletions, and modifications to Setup, Master, and Transaction files
  • Process Tracking- Tracks use of File Maintenance, Utililties, and Routines
  • Posting Tracking- Tracks posting by window/transaction origin
Select the Activity Type you wish to track, and select the User and Company to track.  Then mark the specific activities you want to include in the tracking, taking care only to select those items that you feel will be useful as noted above.  Repeat for additional activities, users, and companies as needed. Click OK when complete.

The results of the activity tracking can be viewed easily:

Activity Tracking Inquiry window
Inquiry-System-Activity Tracking

Note that the activities can be filtered by company, user, activity type, and activity.  The information available includes the company, user ID, date, time, and description of the change.  The description includes the record that was affected, but does not include any details of the specific change (this is the major difference between activity tracking and the Audit Trails module-- the level of detail about the change available).  You can also report on this information through Reports-System-General-Activity Tracking Detail.

If you choose to use activity tracking, make sure you set up a recurring task for yourself to remind you to remove the detail on a regular basis.  Keeping the activity detail in your database indefinitely can increase your database size quickly depending on the types and number of activites being tracked.  To remove activity detail:
Remove Activity Tracking Detail window
Microsoft Dynamics GP menu-Tools-Utilities-System-Activity Detail

Use this window to remove the activity detail based on parameters you specify, including activity type, activity, and ranges by date, user, and company. Generally, you would run this process after a full backup of your databases.  Select and insert the necessary ranges (don't forget to mark the activities to remove, and to mark the "Remove Records" and "Print Report" checkboxes), and then click Process to remove the records.

Although activity tracking may not necessarily meet all tracking and audit needs, it can be a useful tool with minimal investment of time and/or money to see results immediately.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising 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.

Tuesday, August 2, 2011

Programmatically Checking Company Database eConnect Version Numbers

Back in November 2008, I wrote a post about checking eConnect version numbers programmatically.

At that time, I had found that the eConnect Release Info application simply called the stored procedure DYNAMICS..taeConnectVersionInfoDYNAMICS.  That stored procedure returned a list of databases and the eConnect version for each database.

The problem with that utility is that if a database is offline or not accessible for some reason, the Release Info app will display an error and will not return any results.  If you have a client with dozens or hundreds of company databases, and has one or more database offline, this error can be quite annoying.

While troubleshooting a new eConnect 2010 issue, I had to do some extensive eConnect version sleuthing, and finally discovered how the Release Info app gets version numbers from the database.

The eConnect Release Info application calls the taeConnectVersionInfoDYNAMICS procedure.  That stored procedure gets a list of all INTERID values from the Dynamics SY01500 table--basically a list of all of the company databases.

For each company database, it then queries the taeConnectVersionInfo function, like:

SELECT dbo.taeConnectVersionInfo()

This returns the eConnect version for the database.

So, the obvious question is:  How does this function get the eConnect version number for the database?

That's easy--it's hard coded!

The function simply returns a hard coded version number string, such as 11.0.1.0.  So there is no table or object or magic query that is being run to extract the version number from the depths of the company database.  It is simply the taeConnectVersionInfo function that is updated with each eConnect release.

So, if you are looking for a programmatic way to check the eConnect version number for individual databases, you can just select the taeConnectVersionInfo function for each database.

Pretty simple.  Wish they would have just documented this somewhere.

Although that will provide you with the database's eConnect version, please note that with eConnect 2010, there are different versions of the eConnect DLLs and eConnect Service with each service pack and hotfix.  So for instance, eConnect 2010 SP2 has DLLs with version 11.0.1761.0, but if you install the eConnect June 2011 Hotfix (KB2561289), the DLL versions will change to 11.0.1812.0.

So it still probably makes sense to verify the eConnect DLL versions as well as the DB versions.


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

http://www.precipioservices.com

Wednesday, July 27, 2011

Consultant Tools Series: Macbook Air -- with Windows!

For the last 4 years, I've been using a Dell Latitude D620 laptop.  Back in 2007, it was a pretty respectable laptop, with a then fancy Core 2 Duo.

I had the internal 3G wireless card, 2GB of RAM, Bluetooth, and an 80GB hard drive.  Plenty adequate for running Windows XP and doing all of my work.

After a few years, it was time for an upgrade, so I bumped it up to 4GB of RAM and installed a fast solid state hard drive.  That made it usable with Windows 7, but the battery life was starting to fade.  So, I bought two extra batteries that used the CD/DVD slot, which gave me plenty of battery life.

After four years of dutiful use, the D620 was getting tired.  The three batteries were now providing less than 3 hours of runtime, and the laptop, the extra batteries, and the power supply totaled over 7 pounds!  While it doesn't sound like much, 7 pounds in a laptop bag is pretty heavy and quite bulky.

Well, last week Apple released a new version of their Macbook Air.  While I previously never imagined buying any type of Mac, the 2.9 pound 13" Air looked perfect for my needs.  Fast Intel i5 processor, solid state hard drive, small form factor, and a typically compact Apple power supply.  And did I mention 2.9 pounds?

The slim wedge virtually swims in my old laptop bag, and my bag is now 4 pounds lighter, which is a huge difference in weight hanging on my shoulder.

When I received the Air, naturally the first thing I did was install Windows 7.  The new Air has full support for installing Windows via a USB drive.  Just copy the Windows 7 ISO file to the hard drive, plug in a large USB drive, click a few buttons in the OS X "BootCamp" utility, and in a few minutes, you'll be installing Windows 7.

There Air has full device and driver support in Windows 7, so the installation completed flawlessly.

Although I'm thrilled by the massive weight savings and the great form factor of the Air, there are a few significant caveats to transitioning to a MacBook running Windows.

First, the touch pad on the Air doesn't have physical buttons.  If you press anywhere on the surface of the touch pad, the pad will click, so the entire pad serves as a big button.  Also, the touch pad supports gestures, so you can use two, three, or even four fingers to perform certain actions, not all of which are supported in Windows.

There are a few downsides to this in Windows.  First, I'm so used to having two physical buttons below my laptop touch pad that it requires significant retraining for me to use the new Mac touch pad properly.  If I try and click with my thumb while my finger is on the touch pad, it often detects that as a two-finger click, which is a right-mouse click in Windows.  In theory, the touch pad should be able to detect a thumb click vs. a two finger click, but I'm still a bit clumsy with it.  And strangely, the touch pad surface is massive compared to other laptops that I've used--I'm not entirely sure why they did that.  The problem with this is that other fingers or part of my hand will touch the edges, causing it to think I'm using 2 or 3 or more fingers on the surface, or causing the mouse pointer to jump around.

Second, and more critical, is the keyboard.  Although I very much like the feel of the Air keyboard, and the keys are incredibly quiet, it is after all a Mac keyboard and not a Windows keyboard.  This is one thing I didn't consider.

I am a heavy keyboard user.  If there is a keyboard shortcut, I use it.  ALT+E+S+V in Excel, ALT+F+E+P in Word, Page Up/Down, Home, End, CTRL+Home, CTRL+End, CTRL+Shift+End, you name it.  If there is a shortcut I can remember, I'll try and use it since it's so much faster than using the mouse to navigate menus or position a cursor.

Well, let's just say that the Mac keyboard feels a bit 'disadvantaged'.  First, there are no page up, page down, home, or end keys.  Just browsing web pages drives me nuts without those.  And jumping to the beginning of a field, or the top or bottom of a sentence or document, or highlighting lines--all of those things require funky key combinations on the Air.  Page Up is Fn+Up Arrow.  Page Down is Fn+Down Arrow. Home and End are Fn+Left Arrow and Fn+Right Arrow, so those are all two keys vs. one on a typical Windows laptop.

And of course there is the "Command" key.  Fortunately this one is easy to relate to, since it equates to the Windows key on a PC.  But unfortunately it is next to the space bar, which is where the Alt key is located on my Dell, making it difficult to adjust--I'm constantly hitting Command+F or Command+S instead of Alt+F and Alt+S.

Although these are annoying at first, it's only been a few days, so I'm still adjusting, and am assuming I can eventually undo the 8+ years of Dell Latitude Keyboard Indoctrination that I've gone through.

But I think it will be worth it.  The feather light weight, the instant-on feature, the 4 hours of battery life, and the gorgeous display should more than make up for the touch pad and keyboard adjustments I'll have to make.

And before anyone posts comments about how there is an equivalent or better Dell or Thinkpad or some other brand of Windows notebook, I know that there are other options out there, but after shopping around, I was hard pressed to find a standard 13-14" notebook that had the same properties of performance, capacity, weight, and battery life as the Air.  It's a pretty amazing device.  With Microsoft Windows, of course.


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

http://www.precipioservices.com

Friday, July 22, 2011

Reconcile to GL Oddity

I have to admit that I sometimes cringe when I get a call about the Reconcile to GL feature in Dynamics GP (Microsoft Dynamics GP-Tools-Routines-Financial-Reconcile to GL).  I know it is simply because I still haven't learned all the quirks of an otherwise very useful tool. 

For those of you not familiar with it, the Reconcile to GL tool creates assists you with reconciling the payables or receivables subledger by creating a spreadsheet of subledger transactions and the matching (or potentially or unmatched) general ledger transactions.  It replaces the "old" method of exporting the detail from SmartList for payables/receivables and for the general ledger, and then using VLOOKUP in Excel to match up the transactions (oh, my, the fun we have had). 

Reconcile to GL window
Microsoft Dynamics GP-Tools-Routines-Financial-Reconcile to GL

Simply select the module (Receivables Management and Payables Management are the currently available options), enter the date range to examine, and the AP account(s).  Then click Process to generate the spreadsheet. 

The spreadsheet details the transactions that match between GL and Payables Management, those that potentially match, and those that do not match (which could be likely causes of variances between GL and Payables Management).  It then gives you the total of the transactions per GL and per Payables Management.

A funny thing happens, though, when you post a payables transactions with a "check on the fly" (which is a check recorded and printed directly from the Payables Transaction Entry window), and then void both the payment and invoice.  In my experience, this occurs when you have marked the option for Separate Payment Distributions in Company Setup (Tools-Setup-Company-Company-Options button).

Payables Transaction Entry
Transactions-Purchasing-Transaction Entry

First, record the payables transaction and "check on the fly" using the Payables Transaction Entry window.  And then post the transaction, ensuring that the transaction is posted in both Payables Management and the GL.  Then generate the Reconcile to GL spreadsheet:

Reconcile to GL Spreadsheet (after posting of "check on the fly")
Microsoft Dynamics GP-Tools-Routines-Financial-Reconcile to GL


Note that both the invoice and the payment are reflected on the spreadsheet properly, to cancel each other out. But, let's say I then need to void the payment (Transactions-Purchasing-Void Historical) and then void the invoice (Transactions-Purchasing-Void Open).  Then re-generate the Reconcile to GL spreadsheet:

Reconcile to GL Spreadsheet (after voiding of invoice and check from "check on the fly")
Microsoft Dynamics GP-Tools-Routines-Financial-Reconcile to GL


Notice that both of the voids show up in the "Matched Transactions" section, but that the payment no longer shows alongside the original invoice.  So the original invoice has been moved up to "Potentially Matched".  The issue is then that the toal of the payables activity is off since the payment is no longer listed, there is now a net increase of $250 on the total of payables activity.  This is incorrect, and does not match what is actually in GP.

I have walked through this issue with Microsoft, and they are currently researching to determine if it is a quality report.  So please let me know if you have run in to it or not.  Since this tool is used to help find issues when Payables Management and the General Ledger do not match, these little issues can take up valuable time and lead users down the wrong path as to the cause of their discrepancy.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising 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.