Quantcast
Channel: Microsoft Dynamics GP
Viewing all 59474 articles
Browse latest View live

Forum Post: RE: How to perform GetEmployeeList using DynamicGPwebservice in Microsoft dynamic GP?

$
0
0
This exception got resolved by below request payload, BARB0001 MSW64BJDEP\administrator -1 en-US Local Thanks & regards, Priya

Forum Post: Can i reprint reports that have been turned off during posting.

$
0
0
If i turn off a report in the posting setup will i still be able to reprint it later via the Reports>posting journals?

Forum Post: Stumped by performance issues with GP2018 installed on client, talking to database on server (Windows 10 vs 7)

$
0
0
Hello! I work in I.T. (support engineer) for a marketing/media company that uses Microsoft Dynamics GP for the financial software. During the 6+ years I've worked here, the Accounting team has gone through several migrations to newer versions with the help of a consulting firm they've used. Most recently, we upgraded from GP2015 to 2018R2. The program I'm running into is that performance has gotten absolutely terrible since the Finance folks were upgraded from Windows 7 machines to Windows 10. We only have 5 - 7 users who are ever in the application at a time, tops. Typically, only 2 or 3 are using it at the same time. Everyone has wired gigabit Ethernet connections back to a Windows 2012R2 server on a VMWare ESXi virtual machine, acting as the back end server for their clients. If I have someone go back to an older Windows 7 laptop and sign in on it, there's a noticeable speed increase over the same GP2018 installation on a new Windows 10 laptop. I've read some of the common suggestions to improve performance, such as disabling "Windows Defender" anti-virus and excluding certain extensions like .DIC from real-time scans. All good ideas, but seeing little to no speed improvements after doing that. If one of us runs GP2018 via a Terminal Server session so they're using the entire thing from the server itself, it runs much better. So this definitely seems to be a performance issue related to the database connections between the client and the server. Just wondering if there's an optimization or a change with the SQL connectors I should be doing on the Win 10 clients for this?

Forum Post: RE: vw RM Apply Detail smartlist SQL code

$
0
0
Nihad, You should be able to get this in SQL Server Management Studio by opening the view it's based on: CA_vwRM_Apply_Detail. Also, while impossible to say for sure without looking at the actual code for your view, based on the order and names of the fields it looks like this is using code from my blog with just a few changes. Here is the link to my blog post with this: https://victoriayudin.com/2010/02/15/sql-view-with-ar-apply-detail/

Forum Post: Importing from Excel to Purchasing and Sales

$
0
0
Very new to Dynamics GP so very limited knowledge however have been tasked to improve efficiency. We have a number of invoices that have multiple lines of data entry and would like to import from excel (or copy and paste like journal entry function). Wondering also if there is an option for import for cash receipts. We are currently using Dynamics GP 2018 and I don't believe we have integration manager. What are my options? Again, very new so detailed instructions would be great :)

Forum Post: Back Transaction Backed out but still needs voiding

$
0
0
How do I void a bank transaction that was backed out in the General module? I never voided the bank transaction but did back out the GJ entry, now I need to void the transaction but don't see it in the bank transactions any longer, also the amounts are still showing up on the bank reconciliation.

Forum Post: Editing Lockbox entries once uploaded to GP

$
0
0
A client is uploading a file using Lockbox in GP 2016 (Transactions - Sales - Lockbox Entry). Once the data is uploaded, the batch shows "Receiving" and from the documentation I've seen this is normal. Is there a way to open the payment transaction in the Cash Receipt window (Transactions - Sales - Cash Receipts) and edit the Apply information or the GL distributions prior to posting the payment? When trying these steps to edit the payment we receive a message the batch is being processed. Best Regards - Ron

Forum Post: GP consultants in the DC Metro area?

$
0
0
I'm looking for GP support in the DC metro area?

Forum Post: RE: GP consultants in the DC Metro area?

$
0
0
Hi Tracy Intellitec Solutions provides support for GP in the metro DC area. Please contact me Mark Calabria mcalabria@intellitecsolutions.com

Forum Post: RE: GP consultants in the DC Metro area?

$
0
0
Years ago, our company used these guys out of Frederick, MD. I'm told their support kind of went downhill as they experienced "growing pains" and you couldn't always work with the original owners anymore ... but it's been a long time since then and they seem to be thriving. We're actually considering giving them another try. https://www.ktlsolutions.com/

Blog Post: PowerApps | Passing Record Collections from Microsoft Flow to PowerApps

$
0
0
In my previous video, I showed you how we can pass collections from PowerApps as a JSON payload to Microsoft Flow. Now, we will see how we can get a JSON payload back into PowerApps. The technique used here requires knowledge of various PowerApps functions to accomplish the job: Split(), FirstN(), Last(), RemoveIf() , and a timer. Hopefully, one day we will be able to pass JSON payloads from Flow to PowerApps and use a deserialization function in PowerApps to extract the payload records into a collection. For more information, take a look at the following videos and articles: Microsoft Flow | Passing collections from PowerApps to Flow - click here Until next post! MG.- Mariano Gomez, MVP

Blog Post: Microsoft Dynamics GP and Year-End Update -- Upgrade Troubleshooting

$
0
0
Today's blog post will be a rehash of previously published information regarding upgrade troubleshooting. Since the main process hasn't changed for the upgrade itself, the troubleshooting points for the upcoming upgrade will be the same as past versions. The most common upgrade support cases for Microsoft Dynamics GP that we take on a daily basis include: 1. Version Checks and Upgrades 2. Modified Dictionary Upgrade 3. Known Upgrade Issues 4. Database Upgrade In this blog, I will focus on the table conversion. The table conversion is the step in the upgrade where a certain set of tables go through a conversion process for the required Microsoft Dynamics GP 2018 feature changes. Not each and every table gets updated each time a database goes through an upgrade to a new version/build of Microsoft Dynamics GP. Microsoft Dynamics GP Utilities uses the DU000010 table in the DYNAMICS/system database, which contains a list of table updates, and it uses the version/build that you’re starting from and then the version/build that you’re upgrading to for Microsoft Dynamics GP. Using that information, it gets a list of tables that need to be updated between the original and new versions. Sometimes one table can go through more than one update during a database upgrade. You can also refer to the Microsoft Dynamics GP Software Development Kit (SDK) for detailed table changes from the prior release: --In the Dynamics GP DVD, go into the Tools > SDK > Dynamics GP directory and you'll find the SDK.exe and Microsoft_DynamicsGP18_SDK_x86_en-us.msi files to install it with. A future blog will also be published with specific table changes introduced by the upgrade. The key to troubleshooting table upgrade errors is to first understand what happens to each table. You can then trace those steps in the Dexsql.log. The Dexsql.log is a tracing tool that will log everything that Microsoft Dynamics GP Utilities is doing during the upgrade process. This includes the table conversion process itself. If a table fails during the table conversion, you can use the steps to find where the failure happened in the Dexsql.log. Table Conversion Steps for Each Table 1. Table is Renamed: Key Word ‘RENAME’ The first step that occurs for a table going through an upgrade is that it gets renamed. This is done so that the new Microsoft dynamics GP table can be created. This is also important because it is like creating a backup of the table. An example of the naming convention that Dynamics GP Utilities uses to rename tables is the following: GL00100 >> G00100L SOP10100 >> S10100OP As you can see with this example, the tables that start with 2 letters have the second letter placed at the end of the table. Those tables that begin with 3 letters have the second and third letter placed at the end. Sometimes it can be a mix of letters and numbers, depending on the table. **TIP: When looking at a Dexsql.log to troubleshoot a failed table upgrade error, always search on the renamed table. For example, if the GL00100 failed, you would start your search with G00100L to get to the start of the conversion process for that table. 2. Primary Key is Renamed: Key Word ‘RENAME’ The primary key for each renamed table is also renamed so that the new primary key for the new Microsoft Dynamics GP table can also be created. This doesn’t necessarily mean the primary key is different than the previous release. 3. New Microsoft Dynamics GP table is created: Key Word ‘CREATE’ Microsoft Dynamics GP Utilities uses the Dynamics.dic to create the new table in the required structure for Microsoft Dynamics GP . The primary key, secondary indexes, dexterity procedures and bindings are also created during this process. **NOTE: **The ‘CREATE TABLE’ process is a very long process. In the Dexsql.log, you will see the start of the process with the CREATE TABLE. The end of the table creation process will be several “Default bound to column” messages like the following: 4. Check structure of new table, old table and/or dependent tables if applicable: Key Word ‘SELECT’ During the table upgrade process, Microsoft Dynamics GP Utilities may run SELECT statements against the original/renamed table, the newly created table, and/or even completely different tables that the current table being upgraded depends on. The SELECT statements are to validate the table structure of one or more tables. **NOTE: The ‘select’ statement can also be after the Insert statement as well 5. Records Inserted from Old Table to New Table: Key Word ‘INSERT’ After the new Microsoft Dynamics GP table is created and verified as being correct. Microsoft Dynamics GP Utilities will then insert any records that were in the original/renamed table. This is an important point of failure during the table upgrade process because if the old/renamed table is not in the correct structure, the insert will fail. Also, if the newly created table for Microsoft Dynamics GP is not in the correct structure, the insert will also fail. 6. Renamed table is dropped: Key Word ‘DROP’ Once the INSERT statement finishes inserting all records into the new table without any issues, then the old/re-named table is dropped. At the point of a table upgrading successfully and all data being inserted without issues, Microsoft Dynamics GP Utilities will set the Status for the table to a 0 in the DU000030 system table indicating the table was upgraded successfully The Beauty of the Upgrade – The db_status & Rollback! – You Don’t Need to Restore! An important part of the upgrade process is that each step is tracked by the DB_Status column in the DB_Upgrade system table. This allows Microsoft Dynamics GP Utilities to ‘remember’ where it stated and left off for an upgrade. The DB_Status of 23 is the table conversion step. Since Utilities remembers where it left off, you do not need to restore the database(s) if the upgrade fails. If the upgrade does fail, you can close out of Utilities, fix the issue and then re-launch Utilities again. Because of the number in the DB_Status column in the DB_Upgrade system table, Utilities knows where it left off and will pick up from that step. Microsoft Dynamics GP Utilities does a great job when individual tables fail. If a table fails to convert, Utilities will roll-back the table by deleting the new table and primary key, and then re-naming the old table and primary key back to their original name. For example, if the GL00100 table failed the upgrade conversion for any reason, Utilities would delete the new GL00100 table and primary key, and then rename the old G00100L table back to GL00100 along with its primary key. This way we don’t have to worry about losing any records in the upgraded tables and it allows you to close out of Utilities, fix any issues causing upgrade failures, and then launch Utilities again without needing to restore. Pretty AWESOME, eh? Let’s Troubleshoot a Table Conversion Failure! When the table conversion fails, the following window will appear in Microsoft Dynamics GP Utilities. Microsoft Dynamics GP Utilities will stop on the first company that fails. For example, if you mark to upgrade 15 companies and the 5th company fails, Utilities will not continue to upgrade the remaining 10 companies. Steps to Troubleshoot a Table Conversion Failure 1. Don’t Panic!! The first step is to not panic when you see a Red X next to your company. Hopefully, you are running the test upgrade first so you have time to troubleshoot. If you are not running a test upgrade, this blog will help you get the issue resolve fast! 2. DO NOT Restore the company database As mentioned above, Microsoft Dynamics GP Utilities remembers where it left off. All troubleshooting can take place at the point of failure and no restore is required. 3. Close out of Utilities When the Red X appears next to the company, close out of Microsoft Dynamics GP Utilities to start the troubleshooting process. 4. Determine what tables failed Run the script below in the SQL Server Management Studio to determine what tables failed. Pay particular attention to the errordes column. This column usually provides enough detailed information to start troubleshooting without even looking at the Dexsql.log. SELECT b.fileOSName, a.fileNumber, a.PRODID, a.Status, a.errornum, a.errordes, c.CMPANYID, c.INTERID FROM DYNAMICS.dbo.DU000030 a JOIN DYNAMICS.dbo.DU000010 b ON a.fileNumber = b.fileNumber AND a.PRODID = b.PRODID JOIN DYNAMICS.dbo.SY01500 c ON a.companyID = c.CMPANYID WHERE (a.Status <> 0 or a.errornum <> 0) and a.Status <>15 In this example, the following tables are failing: 5. Based on the results above, check the Known Upgrade Issues and Critical Upgrade Issues lists Even if you checked the Known Issues List and Critical Upgrade Issues prior to the upgrade, it is a good idea to check them if tables failed during the table conversion. 'Upgrading to Microsoft Dynamics GP ' hot topic: (coming soon!) 6. Based on the results above start troubleshooting! If the issue is not a Known Issue or Critical issue, start troubleshooting! The errordes column above can provide great direction to start troubleshooting. In this example, we can use the fileNumber values for the failed tables to determine via the DU000010 table at what point these tables get upgraded. For example, if we look in the DU000010 table for the SOP10200 table and fileNumber 497, as per this script: Select * from DU000010 where fileOSName = 'SOP10200' We see that fileNumber 497 and SOP10200 is the update that takes place at the '11.80.1' which means that it gets upgraded between Dynamic GP 2010 and Dynamics GP 2013. Since we're upgrading, in this example, from Dynamics GP 2010 to Dynamics GP 2015, we know that this upgrade is taking place during the upgrade we're currently doing, so we need to find out why this table is failing. Since our 'failed tables' script mentions this table 'did not have the correct structure prior to the conversion', we would want to look at this table and compare it to the Dynamics GP 2010 version structure, since the tables get rolled back once they fail. If we find the structure is incorrect, we would need to re-create the table again and the Dynamics GP 2010 version, for this example, with any data it has in it, then delete the record for this failed table in the DU000030 table and continue with the upgrade to Dynamics GP 2015 R2, after fixing the two failing tables as well. The DU000010 table can also be used to determine when a table gets upgraded, as to determine whether a table may be failing a current upgrade, due to not being correctly upgraded at a prior version. Again remember, that each table is rolled back if it fails, therefore, right now the SOP10200, IV70500 and the GL00201 are set back to the Microsoft Dynamics GP 2010 version, for this example. All troubleshooting can take place right in the failed state. DO NOT restore the database! Ideally, if you are opening a support case for a Dynamics GP database upgrade issue/errors, we would like this information sent to us when the support case is created, as it will help expedite a resolution: A. Run the following script: Delete DYNAMICS..DU000030 where Status <> 0 and Status <> 15 B. Start a dexsql.log file for the Dynamics GP version you're launching Utilities from, and delete any prior dexsql.log files that may already exist: KB article 850996 - How to create a Dexsql.log file for Microsoft Dynamics GP and Great Plains C. Launch Dynamics GP Utilities and continue the upgrade of the system or company database that is failing the upgrade, which should fail on the same errors. Once the upgrade fails again on this or any other errors, please send the dexsql.log file created, any error information from Utilities and then the results of the following scripts, because in the majority of upgrade cases, if it's failing on a table(s), this is what we're going to ask for: 1. Select CMPANYID,CMPNYNAM,INTERID from Dynamics..SY01500 2. Select * from Dynamics..DB_Upgrade 3. Select * from Dynamics..DU000020 order by companyID 4. SELECT b.fileOSName, a.fileNumber, a.PRODID, a.Status, a.errornum, a.errordes, c.CMPANYID, c.INTERID FROM DYNAMICS.dbo.DU000030 a JOIN DYNAMICS.dbo.DU000010 b ON a.fileNumber = b.fileNumber AND a.PRODID = b.PRODID JOIN DYNAMICS.dbo.SY01500 c ON a.companyID = c.CMPANYID WHERE (a.Status <> 0 or a.errornum <> 0) and a.Status <>15 Be sure to check back with the Microsoft Dynamics GP and Year-End Upgrade Blog Series Schedule page to review upcoming blog posts related to Upgrading Microsoft Dynamics GP and other helpful resource links.

Forum Post: RE: DBMS error 7405 when performing Security tasks in GP

$
0
0
I looked for what we've seen for DBMS: 7405 errors with Dynamics GP and this ‘Heterogeneous queries’ error you mentioned here, but the only thing I've found that we’ve seen this was when the customer was attempting to use Linked Servers in some way, such as with SmartList Builder reports, running a stored procedure that runs a query to a linked server, using a SQL View that pulls from a linked server with SLB, etc. Other than linked servers, we don’t see this error message typically. You are correct that this is a SQL error and not a Dynamics GP error, thus the DBMS value. The only ANSI settings I can think of are in the ODBC DSN being used to connect Dynamics GP to SQL Server, where we want to make sure all ANSI options are NOT marked, as per KB 870416. In the database properties for the GP system and company database(s), in SQL, under the ‘Options’ page, there are about 4 ANSI settings under ‘Miscellaneous’, all of which should be set to FALSE by default, which is required for dexterity procedures to work. That's about all I was able to find off hand...…. You could try running the Database Maintenance tool for Dynamics GP 2018 to drop and re-create the stored procedures, which would include this smUserCmpnyAccssChckAccssCHG procedure, then see if that changes anything. Very odd error, especially when you state you cannot create a new company database, give users access or remove access...…. Let us know if you find anything more...…… Thanks

Forum Post: RE: Is there a way to default the Promised Date to 0/0/0000 on a Purchase Order

$
0
0
You could try a form load event or after(leave) the PO number since they need to leave that field to get to the vendor ID. I am not sure of any events happening under the hood on that screen so you will need to test.

Forum Post: RE: DBMS error 7405 when performing Security tasks in GP

$
0
0
Yep, that was exactly everything that I found as well (linked servers, etc). I've checked the ODBC (trying it with those options off (be default) as well as checked) - nothing changes. I've also looked through the settings on the databases - comparing them to the GP 2010 environments databases line for line (and that is when I came across those lines which are all false). I have tried the Database Maintenance tool as well (thinking the SPs had been corrupted), but that did nothing to resolve this either. One thing I did do was to go and modify the smUserCmpnyAccssChckAccssCHG stored proc (along with the other 3 that are similar to this one, 2 being for unChecking), adding in SET ANSI_NULLS ON SET ANSI_WARNINGS ON into the procedure just after the 'as'. Since these are called from the company you are logged into, I only did this in one company. This did allow me to move forward with setting a users access when logged into that company, but I am not 100% sure that is actually fully working. Plus I KNOW that is absolutely not the way to solve issues like this. The only reason creating companies fails is because at the end of it, it also calls these stored procs to grant initial permissions to the company (or something similar to that - I haven't run a dexlog of an entire company creation process to see the exact proc, but I get the same error at the end of the company creation process). I've been traveling with work for the last couple of days, so haven't had a chance to run a SQL profiler yet to see if that gives me any clues. Thanks all!! Jerry

Blog Post: How to bypass SQL Version Errors from Dynamics GP Utilities

$
0
0
Have you ever had to do an upgrade of Microsoft Dynamics GP and the SQL Server has already been upgraded to the latest and greatest, but now when you attempt one of the upgrade steps, you get a SQL Version error for Dynamics Utilities. The wording of the error message is along these lines: Your current SQL Server is not a supported version. Req: Microsoft SQL Server 11.0 Act :Microsoft SQL Server 20XX (RTM) – XX.0.XXXX.XXX You need to upgrade to SQL Server 11.0 before continuing. The actual window will look something like this example: This often happens during upgrades where intermediate steps are required or when trying to create a new company after the server has already been upgraded. Solution DISCLAIMER: The method below is not officially supported as it was designed for testing purposes only, but has worked perfectly for the consultants who have used it. There is a Dex.ini Setting which can be used to override the SQL Server Version check and so get past this window. The Dex.ini Setting does vary depending on the version of Microsoft Dynamics GP, but it is fairly easy to work out which setting is needed. Where the screen lists the required version, take that number and remove the decimal point. For example: Req: Microsoft SQL Server 11.0 gives 110 Use this number in the setting duForceSQLXXXDetection where XXX is the number. So here are some examples: GP 2015 (v14.0) onwards wants duForceSQL110Detection=TRUE GP 2013 (v12.0) wants duForceSQL100Detection=TRUE GP 2010 (v11.0) wants duForceSQL90Detection=TRUE GP v10.0 wants duForceSQL80Detection=TRUE GP v9.0 wants duForceSQL70Detection=TRUE Don’t use the above list as a hard and fast guide as the required versions might have changed with service packs or R2 releases. Best to use the version number from the window to adjust the Dex.ini setting as required Here are some technical details from the DynUtils.dic source: The value for the Dex.ini setting is stored as a form level constant: FORCE_DETECT_SQLXXX of form duSQLInstall It is checked from the form level function: verifyServerVersion() of form duSQLInstall Which in turn is called from the form procedure: init of form duSQLInstall If the version is mismatched, the following script displays the error: displayBadServerVersion of form duSQLInstall Thanks to Larry Ressler and Beat Bucher for encouraging me to research this issue further. Hope you find this information useful. David This article was originally posted on http://www.winthropdc.com/blog .

Forum Post: RE: GP2015 and SQL 2017.

$
0
0
Hi Hossam, There might be some hope if you're still stuck in this setup... Read on the blog post from David Musgrave https://winthropdc.wordpress.com/2019/09/20/how-to-bypass-sql-version-errors-from-dynamics-utilities/#more-18029

Forum Post: Bulk printing and emailing Customer Statements.

$
0
0
Good Morning All, We are on Dynamics GP 2018 (18.00.0704 (R2)) and we are looking for a way to bulk generate statements to our customers. Some are emailed and some snail mailed. Is there a process to generate these on mass monthly?

Forum Post: Document Date was incorrect

$
0
0
We have run our checks and realized one of the checks has a document date of 1921 instead of 2019. The checks have printed, posted to expenses however it is not posting to AP or Cash. We are unable to void, put on hold that check it is holding up our entire process. Please help! We are in version 11.00.1752

Forum Post: RE: Stumped by performance issues with GP2018 installed on client, talking to database on server (Windows 10 vs 7)

$
0
0
Hi there, This is unfortunately a very difficult issue to debug / troubleshoot, as there are so many things that can have changed between the Win7 & Win10 upgrade.. I agree that usually the full Dynamics GP client should run very smoothly when deployed on the local computers/workstations.. but I almost always recommend my clients to use a Terminal Server to publish the GP application, as we can much better control the environment, and also the TS sits usually much closer to the SQL server where the data resides, which helps avoiding network issues that might come up. Where could you start ? maybe setup some wireshark tools to monitor the trafic between the workstations and compare the data between Win7 & Win10 computers.. you might find out that the packet size for the network trafic isn't optimized in W10 and could be the culprit. Can you be more explicit on which operations in the GP client are poor in performance ? is it when posting transactions ? is it when running reports ? smartlists ? exporting data from GP ? Are the dictionaries shared on a network or local (.DIC) ? There are so many places that can have an issue with the performance, that it is hard to tell without directly looking at it. I've have many clients that are running GP 2018R2 from W10 workstations and they run very well and smoothly. Hope this helps.
Viewing all 59474 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>