How should phone numbers be entered or formatted in ERP and CRM systems?

By Steve Endow

While reviewing the Dynamics 365 Business Central Customer record, I noticed that Business Central allows numbers and symbols, but does not allow any letters in the Phone number field.

This got me thinking...  (ya, I know, dangerous things happen when I think...)


1. How should phone numbers be entered in ERP and CRM systems?

2. How should a system support global phone number formatting?

3. How should a system support phone number extension prefixes (e.g. "x") or notes?

4. How should a system format phone numbers to help support VoIP dialing?


Below are some examples of a few systems to which I have access, and I show how phone numbers can be entered into those systems.

While reviewing how these systems handle phone numbers, I was thinking about my questions above.  I additionally wondered:

What should the minimum length be for phone number fields?  How should users enter phone numbers with extensions?  Should you allow letters in a phone number field?  Should users be able to enter brief notes, like in my examples below?

Initially, I would have thought that restrictions on the phone number values and formats are not required, and users should be able to enter whatever they want / need.  However, if you consider the potential need for VoIP dialing, free form text phone numbers might complicate things.

Dynamics 365 Business Central vs. Dynamics GP: Customer Record

By Steve Endow

This is the third post in a series comparing Dynamics 365 Business Central and Dynamics GP, and follows on the post Dynamics 365 Business Central vs. Dynamics GP: Customer Navigation.

In this post, I am going to compare the Customer records of both Business Central and Dynamics GP.

There are hundreds of details of Customer records that can be analyzed, but I'm going to discuss a handful of the things I happened to observe as a long time user of Dynamics GP, but a brand new user of Business Central.

Dynamics GP

I've spent so much time in the Dynamics GP Customer Maintenance window that I no longer notice the details.  As a result, I'm going to have to review it more carefully to try and point out some details that make it unique, along with a few quirks.

Dynamics GP: User ID value is not consistently recorded when new batch is created

By Steve Endow

I received a request today asking if it is possible to enforce a rule in GP so that the user who creates a batch cannot approve that batch.

I initially thought that this would be an easy thing to enforce using a few lines of VBA.  But then I took a look at the fields for the Batch record in the SY00500 table, and saw something odd.

When I created several different batches in Dynamics GP 2018, the USERID field was not reliably populated in the SY00500 batch table.

User ID is not consistently populated in SY00500

This seemed odd.  Why would the USERID value be inserted for GL and SOP batches, but not IV and PM?

As far as I can tell, the issue is not a technical limitation, as the Batch Entry windows appear to all call the same stored procedure: zDP_SY00500SI.  It appears that the developers were simply lazy and either didn't bother to retrieve the current user ID, or didn't bother to pass the value to the stored procedure?

User ID not supplied when the IV Batch Entry window calls zDP_SY00500SI

Very odd.

In theory, you could write SQL triggers to fix this, but ensuring that SQL triggers are reliable and don't interfere with any other Dynamics GP processes is often more difficult that you would expect.

So this simple request to try and improve the Dynamics GP batch approval process appears to be much more involved than I would have hoped.



Update:  Mariano replied to me on Twitter, noting that the User ID field is not really intended to be used to identify the user who created a batch--it's used as part of the posting process.

So it seems the User ID field is not a viable option for determining who created a batch.

Steve Endow is a Microsoft MVP in Los Angeles.  He works with Dynamics GP, Dynamics 365 Business Central, SQL Server, .NET, Microsoft Flow, and PowerApps.

You can also find him on Twitter and YouTube

http://www.precipioservices.com

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.

I'm a huge fan of detailed application logs

By Steve Endow

This week, one of my customers suddenly started having severe performance issues with a custom Dynamics GP web API that I developed for them a few years ago.

The customer and their Dynamics GP partner immediately knew about the performance problem because the web API has logic to detect certain performance issues, log the problem, and proactively send an email notification to the customer and GP partner.

This is a sample of the log file that told me everything I needed to know to work on diagnosing the issue.

Full Time Debug Level Logging with Elapsed Time Measurement

Notice that the elapsed time (in parens) jumps from 0.09 seconds to 32.96 seconds when the GetCCCustomerProfileID step completes?  That step normally takes a few milliseconds, but was suddenly taking 20-40 seconds to complete.  No bueno.  That step calls an on-premises web service for a credit card management system, and that system was experiencing a problem.  Fortunately, my code is setup to log a warning and send an email whenever an operation takes more than 20 seconds, so admins were notified as soon as the problem started.

Measuring Latency in Complex PowerApps

By Steve Endow

I have created a PowerApp that has several dependencies, and I am concerned about latency, and how that will affect the delay that a user experiences when they use the PowerApp.

In order to understand the latency, I have designed my PowerApp-based solution to measure and display elapsed times for key operations that are performed when a user clicks a button.

Here's a video demonstrating the design and the underlying code:

https://www.youtube.com/watch?v=3rNDZWQpWF0

When I say "Complex" PowerApp, I am referring to an application or solution that has multiple dependencies or performs complex operations that may result in a noticeable delay for the user.