To Disable Or Not: User Account Control

As more and more clients move to Windows 7 (or Windows Vista), the issue of user account control appears to come up more and more in relation to supporting Dynamics GP. The most common issue that occurs, in my anecdotal experience, deals with using Dynamics GP Utilities. Users can successfully launch utilities, but after logging in they will receive BCP utility errors.

The immediate workaround go this issue is to launch Dynamics GP Utilities by right-clicking on the icon and choosing "Run As Administrator". Easy enough. But I have also seen a trend lately where it is just recommended to turn off user account control. Why does that approach bother me? I will admit it does.

I try to tread respectfully when working with a client's IT support (either internal or external) and appreciate that they may have goals and strategies outside the world of Dynamics GP (yes, that world does exist). And it seems to me that the decision to turn off user account control should be left to IT and not to me as a Dynamics GP consultant. Of course, I can share my opinion but to actually disable it blurs an already fuzzy line of responsibility.

Do you all agree? Am I overreacting to something that is benign yet annoying? I put this in the same category as changing permissions on shared drives or local drives for a client. I am hesitant to do so if not working directly with their IT support. Again, am I overreacting?

Please share your thoughts, go ahead and let me know if you think I am a) a worrywart or b) sensible.

Posting Settings- Creating a Posting Journal Per What?

First, I should take a moment to explain Steve's recent absence from blogland. No, he is not slacking, but rather taking care of the newest addition to his growing brood. He and his wife added daughter number two in recent weeks. I will let him trumpet her arrival when he returns full force to the blog, and in the meantime you will be subject to my less-technical posts on the wonders of Dynamics GP :)



When training new power users on Dynamics GP, I emphasize the significance of the posting settings window (Tools>>Setup>>Posting>>Posting) as the control center of subledger posting. In particular, I like to point out the "Create a Journal Entry Per" setting.

This setting actually enables three different posting methods for the subledger origin specified:

• Transaction: Post a separate journal entry for each transaction in the batch, this is often referred to as "posting in detail"
• Batch: Post one summarized journal entry for the entire batch, this is referred to as "posting in summary". This option also limits the "Posting Date From" option to "Batch" only.
• Batch, mark "Use Account Settings": This option lets you mix and match posting in detail and summary based on individual account settings by series, Cards>>Financial>>Account. You can then set whether the account should be posted to in detail or summary based on series. Keep in mind, these settings are only used when a Series and Origin is set to "Create a Journal Entry Per: Batch" and "Use Account Settings" in Posting Setup.

So why post in detail -vs- summary? Well, I typically advocate for detail unless there is tremendous volume and it would never actually be used. When posting in detail, valuable originating information (like Originating Master ID, Originating Master Name, and Originating Document Number) is passed to the general ledger and is accessible through SmartList>>Financial>>Account Transactions. This originating information would include the vendor ID, vendor name, and document number for a payables transaction, for example. Very valuable when reconciling or researching in the general ledger.

Just a couple reminders before I wrap up. If you access Posting Setup, make sure you pick a specific Origin to view your settings. The view will default to the Origin of "All". This Origin is used to rolldown changes to all origins in the selected series. For example, if you change to "Create a Journal Entry Per: Transaction" for the Origin of "All" and save, it will update all origins in the series. It does NOT prompt you for the rolldown, it just does it. Also, the Origin of "All" will never reflect your true setup, since each Origin can be different. The Origin of "All" will always show the default settings. For this reason, and to avoid accidentally changing all of your posting settings for a series, always select a specific Origin when viewing your settings.

My final reminder is that the Posting Setup window is critical to the successful use of the system, and one inadvertent change can negatively impact your ability to access information. For example, if someone unmarks "Post to the General Ledger" the selected subledger origin will not create any GL transactions. For this reason, be very careful when accessing this window and limit who can access it to avoid undesired changes.

In Defense of Classes (Payroll)

Delayed in Tampa, I thought I would take the opportunity to deliver on my promise to write about the benefits of employee classes after my earlier post regarding item classes. Normally, I will ask a client if they categorize their employees for reporting or if they pay their employees in specific groups, as the answer to both of these questions can help inform the set up of employee classes in payroll. Payroll has a lot of reporting capability by class, including period end reports (Reports>>Payroll>>Period End). But you can also process a payroll by employee classes, by restricting the build process to a specific class (Transactions>>Payroll>>Build Checks).


Now, just like other classes you can provide a variety of defaults like department, position, and location, but a few of the defaults are of particular importance in my experience.

• SUTA State and Workers Comp Code: These values appear on the employee card (Cards>>Payroll>>Employee) but then default from the employee card to employee pay code maintenance (Cards>>Payroll>>Pay Code). If these values are not populated accidentally on the employee, and do not default on the pay code, there will no warnings or errors when you process payroll. But when you check your SUTA wages, or try to post your workers comp liabilities, you will find that the wages were not probably tracked. Avoid this dilemma but putting these values at the class level, and if you do not have the need for other types of categories you can divide your classes by SUTA state and/or workers comp code.
• Accrue Vacation and Accrue Sick check boxes: If these are not marked, regardless of whether the accrue options are marked in employee pay code maintenance, vacation and sick time will not be accrued. Mark them at the class level, and you can ensure they will default as marked in employee maintenance (Cards>>Payroll>>Employee). Everyone wants their vacation and sick time, so avoid the mistake of inadvertently not accruing the time for an employee.

But my favorite is the Employee Class Code Setup window (Tools>>Setup>>Payroll>>Employee Classes>>Codes). And I would love to insert a screenshot of the window here, but the airport internet connection is not cooperating, so I will attempt to explain the window.

You can select to add Pay Codes, Benefits, Deductions, State Taxes, and Local Taxes to the class by selecting the type of code and inserting it in to the Assigned Codes list from the Available Codes list. By doing this, employees assigned to the class will receive these codes as defaults which can be a huge timesaver in a variety of instances like:

• All employees are in one state and need to be assigned to one state tax code, or employees are in different states and employee classes are divided based on state. This ensures that employees have a default state tax record.
• Classes are divided by type of employee, and all employees in the NONEXEMPT class use the SALARY pay code and others.
• A specific class of employees all get the same basic deductions and/or benefits.

Another feature of this option is that if you later remove a code from the Assigned Codes list, you will be asked if you want to inactivate the code for all employees in the class. This is very handy when using switching pay codes, or when you need to inactivate a code for an entire group of employees. And adding a code gives you the option to assign it to all current members of the group.

And, don't forget, you can also easily assign codes to individual employees as well using Cards>>Payroll>>Quick Assignment.

So I hope you can see how the use of employee classes in GP can increase payroll accuracy and also ease the setup of a new employee. If you want other payroll speed tips, check out my earlier post on Speedy, Speedy Payroll Entry.

In Defense of Classes (Inventory)

So, last week I was on phone support (which sometimes happens when the stars align and our regular support folks actually want to take the vacation they have earned), I had a case come through that was a great reminder of the benefits of classes in Dynamics GP.


Of course, there are the generally accepted benefits:

• Provide defaults for new records


• Roll down changes to records


• Group records for reporting and other processes

In all modules except Fixed Assets, classes are completely optional. However, there are some very practical reasons to use classes which I was reminded of this past week. First, let's talk inventory. When you set up an item from scratch, using Cards>>Inventory>>Item, the maintain history checkboxes are not marked by default in Cards>>Inventory>>Item>>Options. This presents a couple of issues. First, will someone actually remember to click the Options button and choose to track history for item? Odds are, sometimes they will and sometimes they won't. So, then, what happens? Well, I hate to be obvious but...inventory history will NOT be tracked for the selected item. Yes. You heard that right. No inventory history, which will then interfere with the printing of historical reports like the historical stock status. Ugh.

So...how does a class help this? Well, you can set up your item classes and mark the check boxes to track history. Then when an item is placed in the classes, those settings can default. Which can be a huge lifesaver, since items that are not marked to maintain history behave just like items that do maintain history. Trust me, the issue will only come out when you go looking for inventory and there is none.

Now, a similar issue can occur if new item classes are set up and the maintain history check boxes are not marked for the new class. How can we ensure that these options are marked by default on new classes? It's as easy as marking the "default" check box on a class.

The "default" check box is often misunderstood. It does NOT mean the selected class is the default class for new items. What it DOES mean is that the selected class is the default template for any future classes that are created. So, pick a basic class with the correct settings, and make it your default. Then when you set up a new class, it will assume the settings of the default class and then you can make modifications based on the requirements of the new class. easy.

Next up, in defense of employee classes later this week :)

Dynamics GP OLE Container and Note Files - Part Deux

Mariano posts an update to his excellent OLE Container article, and offers some very interesting insight into the file format used by Dynamics with its OLE Container files.  He has even used my new favorite file compression tool, 7-Zip, to partially deconstruct the OLE files.  It looks like he's onto something, and I look forward to a follow up to see if he has cracked the secret to the OLE file format.

On the topic of GP Notes, I personally have had only a few clients use the GP Note fields consistently, and very few used the OLE Container feature to attach files or embed other content. But if the file format were more open, accessible, or, gasp, based on some common standard, I think it might help increase adoption, and might offer some interesting integration possibilities for sharing data with external systems.  It might even make sense to automate the attachment of documents to allow users to avoid the somewhat tedious OLE Container window.

On the other hand, there are many very good third party document management modules for Dynamics GP that can do some amazing things with file attachments for GP transactions, so if a company is serious about having files linked to GP data, I think I would probably steer them towards one of those solutions.

But if you have invested time in the GP Notes with OLE attachments, definitely check out his follow up post.

http://dynamicsgpblogster.blogspot.com/2010/08/all-about-dexterity-ole-container.html

From the Blog Archives: Using VBA in Report Writer

I've known for years that the Dynamics GP Report Writer supports VBA.  The theory is that you can add VBA code to Report Writer events, allow you to perform complex calculations, modify field values, or retrieve and display additional data on reports.

I say "known" and "theory" because until today, I had never bothered to try VBA on a report.  I probably should have years ago, but if you've used Report Writer, you can understand my reluctance to spend too much time exploring its exciting features and then be labeled as a Report Writer "expert". 

It turns out that adding custom VBA code to a report is quite easy--once you know how to do it, and how VBA works with report writer.  The documentation for doing so is not in the Report Writer Manual, but is instead in the VBA Developer's Guide document.  It does a fairly good job of explaining the mechanics, and I was able to get some code working in just a few minutes that performed an ADO query of a table outside of the standard reporting dictionary for the report, and displayed that data on each line of the report.

Afterwards, I checked to see if there was a blog post on the process, and sure enough, his eminence David Musgrave has written an excellent post on the topic, providing some great details that were not obvious from my cursory review of the VBA Developer's Guide.

If you haven't used VBA with the Dynamics GP Report Writer, definitely read his post.

http://blogs.msdn.com/b/developingfordynamicsgp/archive/2008/10/30/using-vba-with-report-writer.aspx

From the Blog Archives: Dynamics GP Notes and the OLE Container

Today I fielded an interesting question on Experts Exchange.

The user explained that they no longer used GP 10, but they had Notes with attachments in GP.  He saw all of the OLE Note files stored on disk, and asked if it would be possible to access or extract the contents of the OLE files.

Fortunately, Mariano Gomez did an excellent job in this 2008 blog post.

http://dynamicsgpblogster.blogspot.com/2008/11/all-about-dexterity-ole-container.html

Unfortunately I couldn't find the follow up post, but his article does a very good job of explaining the history of OLE, the nature of the OLE Container in GP, and some of its limitations.