Dynamics 365 Business Central vs. Dynamics GP: The Home Page

By Steve Endow

First post in this series:  Dynamics 365 Business Central vs. Dynamics GP: Customer Navigation


This post continues my Dynamics 365 Business Central vs. Dynamics GP series, and compares the "Home Pages" of both applications.  If I would have thought of it at the time, I would have made this the first post in the series, but discussing the Home Page didn't occur to me until after my first post.

After I wrote my post about Customer Navigation, I kept wondering why Dynamics 365 Business Central looks and feels so different than Dynamics GP.  After I wrote the post, I realized that the Customer Navigation in Business Central is pretty simple and pretty obvious.  So why do I feel so disoriented when I login to Business Central?

After actually staring at the Business Central Home Page for a while, I realized that the Home Page probably has something to do with my disorientation.  The Dynamics 365 Business Central Home Page is a very different experience for a long time Dynamics GP user.  As someone who has seen the Dynamics GP application daily for the last 15 years, the Business Central Home Page is actually visually disorienting for me.  When it appears, I literally don't know where to look or what to do.

In this post, I compare the Dynamics GP Home Page to the Business Central Home Page and share my opinions as a brand new Business Central user.

Dynamics 365 Business Central vs. Dynamics GP: Customer Navigation

By Steve Endow

I've been working with Dynamics GP for 15 years, and as a result, I know it so well that I can navigate the application without even thinking.  I know the menus, navigation, windows, fields, and dialog boxes so well that I can tab and click through the data entry process as easily as I can touch type.  I know exactly where to find settings and options and transactions and specific fields.  It's like second nature to me.

On the other hand, I am completely new to Dynamics 365 Business Central. I've been playing with it since it was Project Madeira and then Business Essentials, and now, finally, Business Central. But I have not spent much time working with it yet.

When I launch Business Central, everything feels foreign.  The UI is web based, and the navigation is designed completely differently than Dynamics GP.  I currently feel a bit lost when working with the application.  Fundamentally, Business Central has similar functionality as Dynamics GP, but it's a completely different user experience.

As an alternative to going through all of the Business Central online courses, I am interested in using my knowledge of Dynamics GP as a reference point to compare the features and functionality of Business Central to Dynamics GP.  How is Business Central navigation different from GP?  How are the record types different?  How are the fields and options different?  What can BC do that GP cannot, and vice versa?

Using this approach also makes it easier for me to review Business Central in bite-sized chunks.  One record or window at a time.

This is the start of that journey.

NOTE: Obviously I am not yet an expert in Dynamics 365 Business Central.  If I have missed any important points or have shared any incorrect information about Business Central, please let me know. I welcome any feedback or suggestions.  You can post a comment at the bottom of this post, or email me at steveendow (at) gmail.

Dynamics GP: Deleting all document attachments for Payables Transactions

By Steve Endow

TOPIC:  Microsoft Dynamics GP


I'm working with a customer to automate the import of Document Attachments into Dynamics GP.

As part of the testing process, we are having to clear out all of the test attachments that have been imported so that we can re-import them again.

In case it's of interest to anyone, here are some SQL scripts I created to delete out ALL document attachments for ALL payables transactions.  You can modify the scripts to remove attachments for other record types.

Make sure to backup your company database before running any of these scripts.

If you find any mistakes or problems with these scripts, please let me know.

The most common eConnect error: The source was not found, but some or all event logs could not be searched

By Steve Endow

This is one of the most common eConnect errors that I continue to see with Dynamics GP customers.  It occurs when a new server is setup with eConnect, or when an integration is migrated to a new server where eConnect was just installed.

It is very simple to fix, but requires Local Admin rights on the machine running eConnect.


eConnect error:

Exception: The source was not found, but some or all event logs could not be searched.  To create the source, you need permission to read all event logs to make sure that the new source name is unique.  Inaccessible logs: Security.

Troubleshooting a Dynamics GP SQL Posting Error

By Steve Endow

I recently had a call with my friend Windi Epperson to troubleshoot an odd SQL error that was occurring when posting a Dynamics GP batch.

Here is a video discussing the error and our journey to identify the cause and resolve the issue.

Dynamics GP Document Attach Record Type (Origin Description) Codes

By Steve Endow

I have been working on a few Dynamics GP Document Attach projects lately, and I haven't been able to find a complete list of the record type codes used in the Doc Attach tables.

To find the codes, query the CO00101 table and look at the ODESCTN field values.

CO00101 Table

Here's the partial list that I've compiled so far for a US installation of Dynamics GP.  As I test additional record types, I'll update this list.

If anyone knows of a complete list or has updates, let me know.

Customer:      CC

Vendor:        Vendor (Creditor in UK)

Item:          IC

GL Transaction:    GL

PM Transaction:    PM

Purchase Order:        PO

Purchase Requisition:  REQ

PO Shipment:           PS

PO Shipment/Invoice:   PSI

Receivables Transaction:  RM

SOP Order:     SO

SOP Invoice:   SI

Note:  NOTES

**NOTE: It appears that some of the Doc Attach record type codes may vary by region.  For example, UK installations use "Creditor" instead of "Vendor".  But "CC" is still used for UK Customers, rather than "Debtor".

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

You can also find him on Twitter and YouTube

http://www.precipioservices.com

Bulk Export Dynamics GP Document Attachments using .NET

By Steve Endow

2/20/2023 UPDATE:  Version 1.30 released


A user on the GPUG Open Forum asked if there was a way to export all of the documents that are attached to Dynamics GP customers.

I previously wrote a blog posts showing how to export a single document attachment using BCP:

https://dynamicsgpland.blogspot.com/2017/05/extract-dynamics-gp-document-attach.html


And another showing how to export a single document attachment using .NET:

https://dynamicsgpland.blogspot.com/2017/05/extract-and-save-dynamics-gp-document.html


But the BCP solution is only for a single attachment, and the .NET solution didn't have any features for filtering or organized export of attachments.

So today I updated the .NET solution to allow the user to select a Database, Record Type, and indicate whether Deleted attachments should be exported.

Once those options are selected, the user can retrieve a list of all of the attachments, which shows the type, the associated record number, the file name, and file size.

The user can then select an export path and click a button to export all of the attachments to disk.

The application and full source code can be downloaded here:

       Version 1.30:  Precipio SaveDocAttachFiles v1.30.zip


Version 1.30 adds support for the EFOQUS SharePoint Connector for Business Central

-Save files as  <Attachment Name>!<BC Table Num>!<Record ID>

-Save files as  <Attachment Name>!<BC Table Num>!<BC Record Type Num><Record ID>


New record types can be added by editing the SaveDocAttachFiles.exe.config file. Locate the RecordTypes setting at the bottom of the file and add new name + code pairs to the list.


Please note that this .NET application was assembled in a few hours, and is not a refined, polished, commercial software release.  It does not have lots of configuration options or error handling, so you will want to test it in a TEST environment and be aware that it may need some modifications to work in your environment.

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

You can also find him on Twitter and YouTube

http://www.precipioservices.com

eConnect Performance: Using GetNextDocNumbers vs taGetNext stored procedures

By Steve Endow

This one is definitely an obscure topic that nobody is asking about.

But hey, I was curious.

I was researching whether the eConnect GetNextGLJournalEntryNumber could handle a heavy load, and whether it would throw any errors when issuing lots of JE numbers.

Interestingly, I was unable to break it.  I was able to get one SQL exception error when running my test while also trying to get a new JE number in the GP Journal Entry window, but I was unable to reproduce that error.

This image shows 3 instances of my load test application simultaneously retrieving a total of 3,000 JE numbers over about 45 seconds.

3,000 JE Numbers

 public string GetNextJENumbereConn()  
 {  
   GetNextDocNumbers getNext = new GetNextDocNumbers();  
   
   try  
   {  
     string nextJE = getNext.GetNextGLJournalEntryNumber(IncrementDecrement.Increment, ConnectionStringWindows());  
     return nextJE;  
   }  
   catch (Exception ex)  
   {  
     throw ex;  
   }  
 }  

Testing just 1 instance of my load tester, I saw that it took about 16 seconds to generate 1,000 JE numbers using the eConnect method.

So, naturally, I wondered what the performance would be if I called the stored procedure directly.

How long does it take to import Dynamics GP GL JEs with Analytical Accounting?

By Steve Endow

I recently did some tests to see how long it takes to import GL Journal Entries with large numbers of line items.

Those test results were fairly consistent, and showed that eConnect does a pretty good job of importing JEs with a large number of lines.  Only 8 seconds to import a JE with 2,000 lines seems pretty good to me, as I suspect most customers don't import JEs that large.

For anyone who is familiar with Dynamics GP integrations, the next obvious question is how eConnect handles imports of GL JEs when there is Analytical Accounting data involved.

From experience, I know that GL JEs with AA do not import terribly quickly or efficiently.

Here are the results of importing a single JE with varying line counts.  Every line in the JE has one AA code assigned.

100 lines:  3-8 seconds
200 lines:  3-9 seconds
500 lines:  9-17 seconds
1,000 lines:  21-47 seconds 
2,000 lines:  174-222 seconds


There are two obvious differences when you add Analytical Accounting codes to your GL JE import.

First, they take much, much longer.  A standard JE with 500 lines takes 2 seconds, but when you add AA, that same JE takes 9-17 seconds.

A standard JE with 2,000 lines takes 8 seconds, but when you add AA, that same JE takes 174-222 seconds.

HUUUUUGE decrease in import performance.

The second issue is the incredible variance in import times for the single JEs with AA data.  When importing the standard JEs, the import times were completely consistent.  Over 10 runs, I might have seen a 1 second variance, if any.

In this test with AA data, I imported the same JE at least 10 times for each line count, and you can see how different the times are.  The durations seem almost random.  The import times did not gradually increase or decrease--they would just increase on one run, and then decrease on the next.

The times varied from 89% to 200%, which is pretty wild.  I don't know how a stored procedure could have so much variance in performance from one run to the next.  If it wasn't such a nightmare to trace the activity from the eConnect procedures, I'd look into it.

So there you have it.  If you have to import transactions with Analytical Accounting data, you have been warned.  It seems that the eConnect procs for AA do not perform well.

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

You can also find him on Twitter and YouTube

http://www.precipioservices.com

.NET code to create a Dynamics GP batch with eConnect

By Steve Endow

I just posted a story about how I discovered that sometimes I need to explicitly create Dynamics GP batches using eConnect in order to control the batch posting date.

Here's the code that I used.

First, I check to see if the batch exists.

 public static bool BatchExists(string database, int series, string batchSource, string batchID)   
 {  
   try  
   {  
     string commandText = "SELECT COUNT(*) AS RecordCount FROM dbo.SY00500 WHERE SERIES = @SERIES AND BCHSOURC = @BCHSOURC AND BACHNUMB = @BACHNUMB"; // AND GLPOSTDT = @GLPOSTDT";  
     SqlParameter[] sqlParameters = new SqlParameter[3];  
     sqlParameters[0] = new SqlParameter("@SERIES", System.Data.SqlDbType.Int);  
     sqlParameters[0].Value = series;  
     sqlParameters[1] = new SqlParameter("@BCHSOURC", System.Data.SqlDbType.VarChar, 15);  
     sqlParameters[1].Value = batchSource.Trim();  
     sqlParameters[2] = new SqlParameter("@BACHNUMB", System.Data.SqlDbType.VarChar, 15);  
     sqlParameters[2].Value = batchID.Trim();  
     string result = DataAccess.ExecuteScalar(database, CommandType.Text, commandText, sqlParameters);  
     int recordCount = Convert.ToInt32(result);  
     if (recordCount > 0)  
     {  
       return true;  
     }  
     else  
     {  
       return false;  
     }  
   }  
   catch (Exception ex)  
   {  
     Log.Write("An unexpected error occurred in DataAccess.BatchExists: " + ex.Message, true);  
     return false;  
   }  
 }  

If the batch does exist, I make sure to update the posting date.

Sometimes you have to explicitly create Dynamics GP Batches with eConnect

By Steve Endow

You just can't know everything.

Maybe I never took the time to look at this one field when using that particular Dynamics GP batch posting setting, and never knew about this quirk.

Maybe I did know about this quirk at some point over the last 12 or 13 years working with eConnect, but forgot about it.

Either way, I didn't know about it when I needed to know about it.

Last week I had a call with a customer to try and troubleshoot a weird posting date issue.  They import a bunch of AP Invoices every Monday morning into dozens of batches, review the batch that Monday or Tuesday, and then post the batch.  Simple, right?

But when they were reconciling the GL for their month end close, they were seeing AP Invoice transactions post to prior weeks and prior fiscal periods.  An invoice imported on November 5 posted to October 30.  Another invoice imported on November 5 posted to November 1.

It was weird.

We looked at their GP posting settings for Payables Transaction Entry, and it looked pretty normal.

Typical Batch Posting Date

The customer is using the Posting Date from the Batch.  Okay, so that rules out an issue with the invoices posting based on the Transaction posting date.

But, that doesn't explain why invoices imported at the same time on Monday morning would post to different dates.

Dynamics GP 2018 R2 displays full screen by default?

By Steve Endow

I recently installed Dynamics GP 2018 R2 on my laptop.  The install went smoothly and GP works fine.

But I noticed something odd, and annoying.  Every time I launched GP 2018 R2, the application window would open maximized.  Before the login prompt appeared, the GP application window would fill the screen.  I thought maybe it launched in full screen on the first launch, but then once I resized the window and restarted, it would remember the window size settings.

But that didn't work.  I resized the GP application window, closed it, then relaunched it.  Nope--it would relaunch in full screen again.  I tried Run As Administrator to see if that made a difference.  Nope.  It would always launch maximized.

This was noticeable because I have never seen this behavior in GP before.

So where would this behavior be controlled?  Very likely in the Dex.ini file, of course.

Sure enough, as soon as I scanned the Dex.ini file, I saw the setting.

The likely culprit:  WindowMax=TRUE.

I've never noticed this setting, and didn't know it existed until today.  So I changed the setting to FALSE and restarted GP.

Presto, Dynamics GP launched with a non-maximized window, just like normal.  Problem solved.

Just to make sure I wasn't imagining things, I checked my GP 2018 install, and I see that the Dex.ini has the WindowMax setting, but the default value is FALSE.  I checked a GP 2016 install, and the default value is also FALSE.

I'm not sure if the default value for GP 2018 R2 is WindowMax=TRUE, or if that flag is only set to true when you choose to install the Web Client components.

But if you see this behavior, and you want to change it, now you know!

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

You can also find him on Twitter, YouTube, and Google+

http://www.precipioservices.com