Dynamics GP 2010 Localization and Language

Two "L" words that cause a lot of confusion in regards to Microsoft Dynamics GP are "Localization" and "Language".  I have heard these used interchangeably when they actually mean very different things.

Localization is the inclusion of specialized functionality within Dynamics GP to address country-specific reporting and regulatory requirements.

Translation is actual language translation, meaning data, labels, reports in another language.

Unlike love and marriage, you CAN have one of these without the other. Currently, Microsoft Dynamics GP 2010 is available with the following:

• Localizations: Argentina, Australia, Canada, Chile, Colombia,United Kingdom, United States
• Languages: English (US), English (UK), French (Canadian),Spanish (Latin America)

Check out the following link for more information on localization and language availability for Dynamics GP:
http://download.microsoft.com/download/3/4/9/349B103F-95ED-4029-A9BF-ADB78A1852B2/MBS_GP_AvailabilityGuide_US.pdf

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.

Support Expectations

Recently, I have been coaching consultants that are relatively new in their careers working with Dynamics GP.  It has been a really eye-opening experience in learning styles, consulting styles, and how we all build knowledge and expertise in a way that allows us to craft a career path.  I know this will sound trite, but I have learned alot from them and it has brought back some of my own passion for what I do every day.  I do love my job- I love helping customers/clients/users get the most out of their software, and therefore improve their work life.  We spend way too many hours on the job to be miserable.  I also enjoy building relationships over the years with clients, former students, and fellow consultants.  Some turn in to friends, others turn in to mentors and mentees (is that even a word?).

It has gotten me thinking, though, about what I call the Support Conundrum.   A client's first interaction with consultants (beyond the salesperson) tends to be with the most senior folks in an organization.  Make sense, right?  We send out our "A" team to build the relationship, and to showcase our expertise. And, if the timing works out, these same people take the helm of the implementation project and serve in primary roles with the customer. 

So....what happens when the customer's implementation is done?  And they transition to support?  Who happens to be on the support desk?  In many organizations, it is the least senior folks.  The skill level both in product knowledge and working with customers may still be in development and uneven in some areas.  So how do we manage that?  How do we ensure that the customer is not disappointed with support, and at the same time the folks on the support desk are valued/not diminished in importance?

I believe strongly that working on the support desk is an excellent way for consultants to build knowledge, relationships, and strong troubleshooting skills. I don't have all of the answers regarding how best to support both the folks on the desk and the customers so that they don't look at support as the "2nd string".  But here are some of my random thoughts, and I hope that you will share yours as well...

1. Have a solid troubleshooting methodology as an organization, what questions do you ask immediately? 
2. Teach that getting the problem "down the road as far as possible" is as important as ultimately solving the issue, meaning that using solid troubleshooting to isolate the real issue/root cause is a productive task
3. Set expectations regarding how issues are escalated, and what information should be collected prior.  Involve the support desk in the resolution when it is escalated.
4. Teach triage (prioritization)
5. Make sure everyone understands that overcommunication in support is imperative, update clients on progress (or lack thereof) on a regular basis
6. As much of an ego boost as it may give you, do not "bad mouth" your support team...even passive- aggressively (e.g., encouraging a client to contact you directly when they should be using support)
7. Consider a reduced rate for phone/remote support services
8. Support "behind the scenes", providing the support desk with tips, tricks, etc directly so that they can provide it to the customer and learn themselves

What are your thoughts? What else could we add to the list?  Do you agree or disagree with any of these?

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.

Generating Secure Report Links in Management Reporter

Back in the FRx days, you could generate a report directly to Excel.  Due to security concerns related to generating financial data to a file that was not secure, that capability was eliminated with Management Reporter.  However, many users still have a need to generate reports to Excel without manually exporting it after publishing the report.

With Management Reporter 2012, you can publish a secure report link that will prompt the user to open the report in the Report Viewer, Excel, or XPS format.  The link is secure because it relies on Management Reporter security for the user to determine the reports to which they have access.  Very cool!

Let's take a look a the steps involved in doing this.  But first, the prerequisites...

1. You can publish the link to either a shared network location (UNC or mapped drive) or to a SharePoint site. 
2. If publishing to a shared network location, the service account used for the MR process service must have read/write access to the shared location.  And when using SharePoint, the service account must have Design permissions on the library.

Here is a link to a great blog post from the Dynamics Corporate Performance Management team on publishing links to a SharePoint site.

Now, to set the location, we navigate to the report definition in Management Reporter, then click on the Output and Distribution tab:



Mark the option to "Generate to multiple report library locations" and then specify the report library location in the left hand column, this will be used to determine the security access for the report.  Then, on the right hand side, use the Browse button to locate the shared directory to publish the report link.  You can then add additional combinations of report library locations and related report link locations, so that the report is published to multiple locations with different security settings as needed.

Once you have specified the necessary paths, you can generate the report.  The report link will automatically generate and appear in the shared directory:

Double-click to open the link:

If Report Viewer is installed, you will be given the option to open the report in Report Viewer, otherwise you can select Microsoft Excel or XPS Viewer.  We select Microsoft Excel:

Remember, it is using the security defined for the associated report library location to determine access to the report.  Then you are prompted to open or save the report in Excel:

We choose Open, and we see the report...Ta Da!

I know I need more data on the report, but hopefully you get the idea :)  Pretty cool in my book and super easy to set up!

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.

When developing eConnect integrations, don't forget the details...

I am testing an eConnect SOP Invoice integration that I just developed.  The invoices are importing fine, and everything looks good...except...the invoice distributions are duplicated.  Instead of 3 distribution lines, there are 6 lines.

Hmmm, that isn't good.  I'm sending in the three distributions, and they look good in GP, but somehow they are being duplicated.

I triple check my code to confirm I'm not doing anything silly, and the code looks good.  I then check the XML that is being sent to eConnect, and it looks good as well--only 3 distributions are being sent.

Puzzled, I then do a SQL trace on the eConnect inserts to see what it is doing.  The trace confirms that taSopDistribution is only being called 3 times, not 6 times.

So if only 3 distributions are being sent to eConnect and the stored procedure is only being called 3 times, how do I have 6 distribution lines in GP?

Although I have encountered several eConnect bugs over the years, I found it difficult to believe that this could be an eConnect bug.  Hundreds of people would have discovered this issue by now, so I have to assume it isn't a bug.

I then decide to randomly query the distribution records in SQL (SOP10102) to see what they look like.  And that is when it dawns on me.

Notice that the first three records have a DistRef value.  But the last 3 records don't.

The first three records are ones that I'm sending in to eConnect.  So what are the second three?

They look like the default distributions.  The distributions that would normally be created if you didn't send any distribution data to eConnect as part of the SOP invoice.  Which happens when you send a value of taSopHdrIvcInsert.CREATEDIST = 1.  Or, if you don't send any value for CREATEDIST.  Or if you forgot to send a value for CREATEDIST.

Ooops.

As soon as I saw the distribution records in  SOP10102, I realized what I had missed.  One little tiny detail that is kind of important.  Well, it's important if you want your distributions to be correct...

Don't forget the details!

 

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.

http://www.precipioservices.com

Management Reporter Migration and Row Linking

It has been very well publicized that MR does not yet have row linking capability.  In FRx, you could design a report tree and have each branch of the tree use a different row format.  In MR, you can link to different GL links within a row format but not to different row formats.  Recently, though, I learned of a quirk with the migration related to row linking that I did not expect.

But first, a couple of good blog posts from the Dynamics Corporate Performance Management Team regarding FRx migration to Management Reporter and row linking.

http://blogs.msdn.com/b/dynamicscpm/archive/2012/05/23/migrating-to-management-reporter-2012.aspx

http://blogs.msdn.com/b/dynamicscpm/archive/2011/08/09/management-reporter-advanced-reporting-scenarios-and-features.aspx

What I was surprised to learn is that when you have row linking on a tree in FRx, it impacts the migration in more ways than one.  Not only does it remove the row linking from the tree (which would be expected), it also does not migrate the GL linking in all of the row formats there were linked in the tree.  For example...

The tree has a summary and three branches:

• Summary
• Dept 1
• Dept 2
• Dept 3

In FRx, the three departments are linked to three different row formats as follows:

• Summary: Row format A
• Dept 1: Row format A
• Dept 2: Row format B
• Dept 3: Row format C

When the row formats are migrated, only Row format A would be migrated intact.  Row formats B and C would drop their GL links (when you open the row, there would only be descriptions) so that the row formats would be have to be rebuilt with the correct GL links.

And it is not enough to simply remove the row linking in the tree in FRx prior to migration, as unassociated rows will not migrate.  So you would have to associate the rows with another catalog for them to migrate properly.  A little prep work to consider if you use row linking in FRx.  Then you can address the report design (the blog post above on advanced reporting has some ideas) to achieve similar results to row linking.

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.

Save Operation on UPR_WORK_State_Tax

When building a payroll (Transactions-Payroll-Build Checks) on GP2010, a client encountered the error "A save operation on table 'UPR_WORK_State_Tax' has created a duplicate key".  We isolated the error to benefit transactions for three specific employees and then determined what they had in common-- they were all being paid wages that were being taxed in a state other than their default state.  So, here is the scenario...

1. Employee has default state tax code defined, Cards-Payroll-Tax Information (in this example, MO)
2. Employee has pay code transactions entered (Transactions-Payroll-Transaction Entry) with state tax codes for another state only (in this example, IL)
3. Employee has benefit transactions entered (Transactions-Payroll-Transaction Entry) that are state taxable (Cards-Payroll-Benefits)

Now, in the example above, if the employee also had pay code transactions with the state tax code of MO then there would be no error.

Also, if you change the employee's default state tax code (Cards-Payroll-Tax Information) to IL, then there would be no error either.

I know this is not the most common scenario since most employees have wages that are only taxed in a single state. But I work with several organizations who need to tax specific wages in specific states for employees. I will update you all when I get more information from Microsoft on additional workarounds and/or a fix.

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.

The Power of the Microsoft Dynamics Ecosystem

The following question was posted to Experts Exchange recently:

We currently use Solidworks for CAD modelling.  Initial BOMS are created in Solidworks, and we would like to be able to import a BOM from Solidworks into Dynamics GP.

Hmmm.  That's a good one.  I checked the eConnect documentation, but BOMs are not a supported import.  You could reverse engineer the tables and try and import the data, but that isn't the most desirable solution--and that's just the GP side of things.  Since I'm not familiar at all with CAD software or Solidworks, it didn't occur to me to look for a third party add-on that might import such data into GP.

Well, the author of the question did some research, and believe it or not, there is a solution called Agni Link designed to provide a real-time, bidirectional integration between three major CAD software solutions and all four of the Microsoft Dynamics ERP solutions.

This is an example of the power of the Microsoft Dynamics "ecosystem".

First, products like Dynamics GP have been around for a long, long time, starting with its many years as Great Plains.  Second, the Dynamics ERP products are used by tens of thousands of customers, providing a large installed based that makes it economically viable to develop relatively niche products like a CAD to Dynamics integration.  Third, Dynamics ERP products have development tools and APIs that facilitate the development of third party solutions.

And last, because they all run on common Microsoft technologies like Windows and SQL Server, both of which are ubiquitous in the business world, third party solutions have the option of integrating with multiple Dynamics ERP products, providing a larger customer base for those ISV solutions.

I thought this was a great example of how all of those things come together to help customers use Dynamics GP to integrate their business systems.

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.

http://www.precipioservices.com