The Acumen software design blog provides you with helpful articles about Dynamics GP.

Several web sites provide a good overview.

Official Microsoft Dynamics GP Overview

Dynamics GP Wikipedia

I do not have any experience in accounting background, and some of the concepts so obvious to others are a mystery to me. One of those concepts was “Quantity in Base”. Although there may be a great description of this concept directed at the ignorant, I did not find it, and most of the discussion I found did not help me.

Quantity in base is used in several contexts, and one of them is described here by an example.

Suppose you have a new product, ITEMNMBR ‘1234’, and you enter it into Dynamics GP. Table IV00101 will have a new row, and you must have supplied values that include SELNGUOM (Selling Unit of Measure), PRCHSUOM (Purchasing Unit of Measure) and UOMSCHDL (Unit of Measure Schedule).  These units are expressed as strings so that they can be somewhat descriptive.

This means that you must supply a value for SELNGUOM such as EACH, 5P (5 Pieces), 10P, lb (pound), oz (ounce), or CASE, etc.  When someone sells the item and it is entered into as a line item into SOP10200, each line item will have a QUANTITY and a UOFM (Unit of Measure). Normally we would expect the Unit of Measure to the same as the SELNGUOM in IV00101, but what if it isn’t?

The order can have a different UOM for an item than that which is anticipated so long as there is a table entry to translate the UOFM in the sale order to the “Base Unit of Measure” that is anticipated in the record setup for the item’s definition in IV00101. The line item for an actual sale of an item is in SOP10200 (and is moved to SOP30300 after posting). For each line of SOP10200 there is a UOFM (the units used in the order and invoice for sale) and the QUANTITY sold.

The table that translates from one UOFM to another is IV40202. The table has a number of rows that will translate the units. To find the one we want, we must know the UOMSCHDL for the item in IV00101. This, combined with the actual selling unit of measure (which is the UOFM column in iv40202) two pieces of information needed to look up the QTYBSUOM (Quantity in Base Unit of Measure), which is a _ratio_ between  the Actual Unit of Measure (UOM)  and the usually expected unit of measure. To get the units in the SELNGUOM, you will multiply the actual number of units in the actual line item (QUANTITY in SOP10200) by the QTYBSUOM.


FROM IV00202

WHERE UOMSCHDL = <<the SELNGUOM of the item from IV00101>> AND UOM = <<the actual unit of measure used in the sales line item of SOP10200>>

But apparently you don’t have to look this up, because the record in SOP10200 has a QTYBSUOM which is inserted into the record for convenience.

GP Dynamics

After rebuilding the SQL Server and restoring databases due to a catastrophic hardware failure that even corrupted the redundancies, once users tried to open certain smartlists, they received the following error window:

GP Dynamics

Then, after getting the message multiple times, the smartlist data finally showed, but it was a major nuisance for the users.

After troubleshooting, I found the issue to be because in the new install of SSRS, I had set it to run on a domain service account. After trying some other potential solutions, I found that setting the SSRS service to run as NETWORK SERVICE ceased the copious number of error messages received.

See our Network Services page for more information on ways we can help you!

Dynamics 2012

This past weekend I upgraded a client’s installation of Microsoft Management Report v.2 to 2012. After transferring everything and testing it, I reported it ready for production. Soon after, I got an email from a user with the attached screenshot of the error message he received when generating a report in the updated Report Designer:

Dynamics 2012

Dynamics 2012 Solution

When I went into Report Viewer, I found that the reports had been generated.

But I was able to open them in the viewer. I just could not open the reports from within Report Designer.

The issue that I found was that at one time, the Terminal Server that the application runs on at one time had Google Chrome.

But Chrome had since been removed. In the time that Chrome was there, the user had had Chrome set as the default browser. Since Chrome had been removed, Internet Explorer had never been reset as the default browser.

(This being a Terminal Server and the users were trained not to use a browser from the remote desktop).

Once I set IE as the default browser, Management Reporter was able to send the reports to browser, as was the expected behavior.

The issue does not seem to be the use of a browser other than IE, just the lack of a default browser set for the user. Even though I didn’t test it on the system, Management Reporter Web Viewer should run on Microsoft Internet Explorer 9 or 10, Chrome 22.0.1229.79 or newer, Firefox 14.01 or newer or Safari 5.1 or newer.

See our IT Support Page for more information.