Programming vs. Accounting - Rocky XII
No, I am not riding on the coattails of the recent release of Stallone's latest movie 'Creed' like I so unabashedly did with my blog on Star Wars and ERP Implementations. I will make no references to Rocky Balboa or Apollo Creed here and I will not conjecture on who would be the better developer.
With that said, programming solutions can conflict with accounting best practices and it can seem like a slugfest. But should one always "program" oneself out of an accounting problem?
Here's a common scenario. A transaction in Microsoft Dynamics NAV was posted with an incorrect date. A programming solution would be to go into the backend and correct the dates of all the related posted entries. Yes, it should work- but should the problem be solved in that manner?
From an accountants point of view, no. There is no audit trail by going into the backend and changing data. Additionally, it is risky even when one is confident of one's knowledge of the system involved.
Moreover, the users of the system may become dependent on a programmer's ability to make a quick fix and request future data entry errors to be corrected in such a manner. The correct way to solve this is to enter a correcting transaction to reverse out the original transaction and re-enter the new transaction.
What if 1000 transactions were posted with incorrect posting dates and it will likely take two personnel a full week to reverse and correct the transactions? In this case a programmer could come in handy, but how the problem is solved is key.
One could write a process to change all the posting dates of all the transactions involved. However, this has its risks depending on the system and transactions involved as it bypasses the normal validation of data. One should instead write a process which creates the reversing and correcting transactions as if the user had entered them. Thus a full audit trail is maintained. The programming solution "simulates" a user entering the transactions by hand and therefore, follows best practice.
There can be exceptions. For instance, 1000 orders were posted with a Text field incorrectly populated. It is 100% certain that the text field is not tied to any logic within the system and is purely informational. In this case, a programming solution to update the posted data directly is of no real risk.
Judgement is required, then to determine when a programming solution should be undertaken or not. In the majority of cases. if an issue can be solved by entering transactions, that will be the ideal solution.
Designing Microsoft Dynamics NAV Implementations - Part 2
The last blog on this topic covered pre-design activities. We'll pick up from where we left off and cover the design process itself. There are probably a number of ways to carry out design, so this is one potential methodology.
The design process roughly consists of:
1) Design requirements meetings
2) Analyzing the notes from the meetings.
3) Designing solutions and translating the concepts into functional and technical specifications.
4) Reviewing the specifications with the client, updating them until full agreement is reached.
We'll cover each step independently:
Design Requirements Meetings
A good way to structure meetings is to keep the number of attendees reasonable and to break them into 2-3 hour sessions. Schedule breaks. The designer should have ready access to NAV to be able to demonstrate out-of-the-box functionality. The client should have ready access to the legacy system to demonstrate current functionality.
It is vital to use a written guideline to drive the meetings. An agenda is only a start. A functional design template is best which is pre-written and covers all the topics that will be covered in the design with key data pre-populated in the template. Without a design template, it will be far to easy to "forget" to mention an important detail, get side-tracked and lose focus. The written guideline should be included as one of the pre-design activities. The design template should be tailored for the client prior to the meetings. Note any gaps between the standard product and client requirements and any pre-sales data gleaned from prior meetings.
With the pre-design activities in place - 1) Client has agreed-upon a design approach, 2) Client understands their internal processes, and 3) Client has been trained, the client is now in a position where design collaboration can be most effective.
The meeting starts with the process of the area being designed. For example, sales order entry. Review the as-is process and to-be process diagrams if you have them. Otherwise, you will need to capture, but not necessarily diagram these, during the meetings.
Have the client demonstrate their functionality. In this case, how to enter an order. Note any gaps. Demonstrate the same functionality in NAV. Note any gaps and get the requirements for the gaps. For example, the legacy order entry screen contains fields that are not in NAV. How are they used? it turns out they print out on the invoice and is required by certain customers in order to pay the invoices.
The designer notices the pricing in the legacy system operates quite differently than NAV. This was not brought up in the RFP stage or in any of the demos. NAV picks the lowest price available while the customer's system picks prices in a set hierarchical pattern. This is non-negotiable as prices are contracted with customers and therefore NAV requires customization. The designer asks questions until and notes the requirements down, preferably in the design template itself. Personally, I don't use pens or pencils in design meetings. It saves much time to simply type the requirements in the template itself.
NAV order entry is demonstrated and the client is satisfied it will meet their needs minus the previously mentioned items. The meeting is complete.
Analyzing Notes from the Meetings and Designing Solutions
Now is the fun part - designing the implementation. I like to work in small segments so I work on each segment of the design in turn. In some cases, design may involve converting notes into a clear statement of the requirements in plain, clear terms. In other cases, you will need to "figure out" how to accomplish a goal in the ERP system. Putting concepts on paper is a good way to visualize solutions and "trying" out various scenarios by entering transactions in NAV can be revealing. I find it successful to design in the physical universe - sketching, drawing, typing data into Excel, entering transactions and testing. I don't spend a lot of time "thinking" in me 'ead. And of course, Google may have passed up the dog as man's best friend. Don't be afraid to use it. There may be third party solutions or someone may have already solved the problem.
The end product will be functional and technical design specifications that effectively capture and communicate the requirements to its intended audience. The functional specifications must be understandable by the client and project personnel. The technical specifications should be thorough and clear so that developers can read them and execute without a lot of further discussion.
Reviewing the Specifications with the Client
It is now the responsibility of the designer to ensure the client and project personnel understand the design. This is best done in person and updating the document per client feedback. The document is sent back to the client for review and further iterations are made until the design is finally agreed upon.
Design Continues throughout the Project
It is fait accompli that the design will not be 100% accurate or complete and therefore one should expect that it will continue to evolve throughout the project. Development should be delivered iteratively with frequent client demos and feedback sessions. Client should be hands-on in the development stage. The product will then shape and mold to the client's requirements iteratively and the remainder of the project will have the greatest chance of success.
Summary
Design is not an art. It is a science and requires a number of skills- the foremost is the ability to communicate effectively and clearly verbally and in writing backed with extensive product knowledge and implementation experience. It requires the ability to ask questions so as to obtain requirements and to steer group meetings to achieve the goals of design. It requires the ability to research and come up with solutions to problems.
A good design communicates to all those will consume it- client and project resources. Functional specifications should be in simple, clear language, not peppered with a volley of technical acronyms. Technical specifications should follow suit and should be thorough enough so that developers can run with it.
Sufficient time should be spent on the design process. It is time well-spent and is necessary to ensure the success of the project.
Improving Efficiency with Mandatory Fields for Microsoft Dynamics NAV
One of the issues that has plagued all versions of Microsoft Dynamics NAV, is that there is no built-in enforcement of mandatory fields while setting up master records such as customers, vendors, items, fixed assets, etc. This can create interruptions in daily workflow as errors may not be encountered or discovered until a user tries to enter a transaction or worse - after posting a transaction. This often requires involving resources in multiple departments to correct the issue.
Let's take an example of a sales order where an item was setup without an item category and posted. To correct this in NAV would require crediting the order and copying the posted invoice onto a new order and re-posting the order. This could have been avoided had the item been validated as properly set up initially.
NAV 2013 added a feature where "mandatory" fields can be indicated with a red asterisk as a reminder to users. However, this is simply a "reminder" with no actual enforcement. Further, one has to use the Development Environment to mark fields as "mandatory".
The answer to this long-standing problem is a low-impact customization which allows a user to select mandatory fields for various master records such as customers, vendors, items, etc. within NAV and blocking master records unless all mandatory fields are populated.
The above fields are required when setting up a customer. Customer will be blocked until all fields are populated.
This customization can be embellished further by displaying a warning message should the user neglect to enter all required fields before leaving the master record page.
To make this more user-friendly, the mandatory settings can be pre-populated with the commonly expected mandatory fields for master tables.
Designing Microsoft Dynamics NAV Implementations
Design is one of my passions. Throughout my career, I have had the privilege and opportunity to design implementations and solutions on Microsoft Dynamics NAV from small informal businesses to large, global corporations. I have learned a few things over the years which I will now share.
Pre-Design
Pre-design are those activities prior to design which will facilitate the design process. This may include agreeing upon a design approach, business process mapping/re-engineering, training on the base product, and preparing for the design requirements meetings.
Discussing the design approach early in the process will prevent heartache downstream. By design approach, is meant the manner in which the design process will be carried out. The design activities can then be steered accordingly. Here are some important points to consider:
- Is your client adverse to customizing the product?
- Is your client open to changing key internal processes to suit the software?
- Are the key internal processes inflexible due to technical reasons, contractual obligations, or otherwise requiring customization?
- Is the budget inflexible or fixed?
- Is efficiency and ease-of-use more important than avoiding customization?
- Has the legacy system been heavily customized?
The answers to these questions should guide the designer in how the meetings are conducted and how the design activities are carried out. The design approach could be summed up in a statement such as:
Client prefers an out of the box approach, customizing only in the X module, where customer obligations dictate specific requirements not supported by NAV out of the box. Code changes are to be heavily scrutinized.
Another one might be:
Budget is more or less fixed, requiring lengthy board reviews and approvals for changes to the budget. Core requirements have been identified in spreadsheet X. Anything outside of the core requirements will be placed on hold to be discussed after the initial go live.
Another example:
A key target is to streamline the current manufacturing process. It has been acknowledged that NAV's out of the box manufacturing process will require customization to reduce keystrokes and to prevent data entry errors. Great attention will be placed on efficiency throughout the manufacturing process. Finance and sales will use NAV primarily out of the box. However, the sales order entry will be customized to reduce keystrokes and place key functions on the users roles for quick access. Speed of sales order entry is key.
Now, it would be very wise to ensure the entire implementation team is briefed on the design approach prior to the process mapping and design meetings and to lead the meetings accordingly.
Business Process Mapping
Business process mapping may include the as-is processes as well as the to-be processes. The to-be processes should be mapped in coordination with the desired ERP system. Otherwise, the to-be processes may veer far from the out-of-the box processes and the resulting to-be processes will be out of sync with the standard ERP system requiring major customization.
Business process mapping is of value in several aspects. Often it is the first time personnel have had open discussions on how their job relates to other jobs in the company and it gets the team involved in an open dialog. Discussions can get heated as viewpoints shift and new patterns and agreements are made. Secondly, it moves the processes and procedures of the organization out of the "minds" of individuals into the material universe where it can be visualized, discussed and improved. Thirdly, it lays the foundation for the design of the ERP system and facilitates a smooth transition from business process to design requirements.
Is business process mapping required for all implementations? No, successful implementations have been done with and without them. Larger, more complex implementations would benefit from business process mapping. However, any company would benefit from documenting and understanding their internal processes.
Pre-Design Training
Pre-design training is highly recommended for implementations where the implementation is not an obvious out-of-the box installation. Armed with a better understanding of the system, the client can better collaborate during the design process.
Preparing for Design
This includes items such as preparing an agenda, ensuring the room is properly set up, the meeting sizes are not too large, access to legacy systems, projectors, and so forth.
In the next series of this blog, I will cover the design process.
The Importance of Roles in Microsoft Dynamics NAV
What is a role in Microsoft Dynamics NAV? A role defines what menu items you see as well as what appears on your Role Center (the main page you see when you log into NAV). Below is the default Sales Order Processor role.
An optimally configured role would give users quick access to their most often used pages, reports and functions, would provide useful information at a glance through the use of tiles (see blue squares above) and contain any other relevant information.
You can assign the default roles to users and begin using them and while this is better than not using any roles at all, for ease-of-use and efficiency, it is highly recommended to tailor roles for your organization.
The Role Center is just another page with an important distinction - custom code cannot be written on the page. This is intentional so that non-development resources can set up their own roles. However, setting up roles is a technical endeavor and requires use of the development environment, so is most easily done by a developer, though non-development resources could be trained to configure roles. However, before volunteering to set up all the roles for a company, it would be a good idea to observe a resource seasoned in configuring roles before committing to the task. It is not a simple point-and-click affair and not-at-all intuitive if you are not familiar with the NAV development environment.
A good procedure to take in configuring roles would be:
1) Look over the standard roles in NAV. Best done by running the roles using the Development environment. These are in the 9000 page number range.
2) Make a list of the roles for your company. E.g. (CFO, Controller, A/R Manager, A/P Manager, Sales Order Processor, Inventory Control, etc.)
3) For each role, list out the pages and reports that role will need access to. Use the standard role as a guide. Consult with an actual user of the future role while doing this.
4) List any tiles that may be useful for the Role. Tiles display a numerical value which usually drills down into further detail. E.g. A tile that shows the number of open sales orders. When clicking on the tile, the user views a list of open sales orders. The standard roles may have tiles you would like to incorporate into your role or may give you ideas for other tiles. Consult with an actual user of the future role while doing this.
5) Once you have defined the roles and what is to be contained in them, you can start configuring roles. It is best to start with an existing role, copy it and configure the copied role. This will leave all of the standard roles untouched and they can be used for reference.
6) Finally, assign the role to a future user of that role and have them test it out and get their feedback and make any desired changes.
Optimally configured roles should result in users being able to carry out their jobs more efficiently within Microsoft Dynamics NAV, highlight key data and metrics, reduce training time, and time spent locating screens, reports and functions.
Star Wars and Implementing ERP Software?
I know what you're thinking- this is a really old marketing trick, positioning and leveraging against the soon-to-be-released "Star Wars - The Force Awakens" movie, and guess what, you would be right. The two subjects have absolutely nothing to do with each other, but neither do popchips and Star Wars as I casually noted while strolling down the grocery aisles over the weekend.
So here's just a bit of fun. If you had to pick your favorite Star Wars characters to implement your ERP software, who would you select? Here are my top picks:
Sales/Account Executive - Han Solo- he's charismatic, outgoing, bold and doesn't hold back. He may be a bit reckless with his tongue and he may seem to be all-too interested in his sales commission, but at the end of the day, he'll take care of business.
Senior Developer - Luke Skywalker without question. He's bright, a quick-study, honest and capable. He's tired of farming anyway and he's ready for a new game.
Project Manager - Princess Leia. She's tough, resilient, smart and can think on her feet in a fire-fight. She'll get the job done on time and in budget, even if it means leaping into a trash compactor. She won't back down when it comes to loyalty and principles even in the face of evil.
IT Technician - Anakin Skywalker (before he turned to the dark side). If he can build and repair droids, he can install your SQL Server database with literally one arm tied behind his back.
Implementer - C3PO - you really should not have your personnel trained by a robot, but he does speak six million languages, so whether your implementation is on the dry desert scape of Tatooine or the lofty cloud-city of Bespin, he'll be able to communicate effectively to your staff and he can set up a database faster than any human around.
Third Party Consultant - Lando Calrissian. At first, your not sure if you can trust him and you're pretty sure you can't. He's got that charm and beguiling smile, and he may turn you over to the dark side if his hand is forced, but he'll figure out a way to make the project a success.
Executive Sponsor - Yoda. I can hear him now, "Security, you will set up and a SOX audit you will avoid."
'Nuff said.
ERP User Documentation, a Compulsion
I admit it- I have a compulsion and that compulsion is to document procedures and customizations. I realize I am a prime candidate for the twelve step program, "Documentation Anonymous". In fact, I refuse to deliver any development without user documentation describing where to find and how to execute any particular development, along with testing tips, and other juicy tidbits. Worse, I have passed this disorder down the organization to others.
How this disorder befell me is an interesting story. You see, I just got tired of training the same procedure or task to one person after another and then again after someone forgot. This is no fault of any other persons as human memory in its current state is not perfect. It was my responsibility because I didn't document it. And I found, magically, the amount of traffic regarding said procedure or task died down to a mild murmur, and eventually to a wonderful blissful silence.
When procedures, tasks and details are held in minds of others and not in writing, it is subject to degradation, loss, alteration and other forms of unfortunate circumstance. Employee transfers, promotions, leaves, new hires, etc. are just a few of the possibilities. As these procedures and tasks are handed off from one person to another, data inevitably gets altered or bits of data gets dropped off and knowledge is then lost. "Tribal knowledge" can be converted to "Permanent knowledge" by documenting procedures, tasks and customizations.
I may have struck a serious blow to the financial interests of "Documentation Anonymous" and if so, the world will be a better place!
Microsoft Dynamics NAV in the Cloud or On-Premise?
There's a lot of talk about the cloud these days and not a day goes by without a new company springing up offering a new cloud service. Cloud services are advantageous because they don't require high up-front costs such as hardware, specialized services & training or high initial software license fees.
Microsoft Dynamics NAV, in the recent past could only be purchased by buying the software license. The up-front costs could be high depending on the number of users and of course, you needed adequate hardware, internal or external IT staff to install, configure and maintain the servers and requisite software. The initial investment was often quite high.
Now Microsoft Dynamics NAV can be purchased two ways. The traditional "buy the software license" approach is still available. However, if you don't want dump a load of cash into hardware and IT resources, you can purchase NAV on a subscription basis. Here, your initial up-front costs are very low, no specialized hardware or IT services are needed and your data is secure and backed up automatically. You simply pay a monthly fee per user. Note: there is a small initial up-front fee and pricing varies depending on the options you select as well as the size of your database.
Your NAV solution can be hosted in the cloud on our preferred hosting provider's data centers or on Microsoft's data centers also known as "Azure". Our hosting provider will install NAV and take care of all the of the technical details and you will have NAV up and running in no time! Your solution will still need to be configured for your business, but all of the infrastructure will have been taken care of so you can focus on your implementation and your business.
Plugging Dynamics NAV Security Holes
The default security roles that come out of the box allow certain users to access the Chart of Accounts, G/L detail and financial reports when they should not have access.
The technical reason behind this is specific permission sets give the user the ability to read G/L accounts and G/L Entries. These include sales/purchase order entry, posting of sales/purchase orders, and so forth. Further, the default permissions give users the ability to view all pages (screens). Therefore, these users have the ability to view the chart of accounts, see balances and drill down into the G/L entries.
The obvious question is, "Why do you not simply take away the ability to read the G/L account or entries?" Users may need to select a G/L account on the sales or purchase lines for misc. charges or to record an expense and the posting routines need to read the G/L entries. Therefore, these permissions cannot simply be taken away.
The next obvious question is, "Why not give users access only to specific pages (screens)?" This is a valid question and yes this can be done, but it will a mind-numbingly and time-intensive task which could take a hundred hours or more. There are third party tools which can help, but there are other possibilities without purchasing additional software.
A recommended approach is to set up roles for each department so that users only see the pages, reports and tools they will need. Then the key thing is to remove the Departments menu from the user's role. Users will not be able to access any page, report, etc. that they cannot see on their menu. They will not be able to search and find any feature that is not specifically on their role. Therefore, they will not have access to the Chart of Accounts, or financial reports. Setting up roles as described above accomplishes two goals:
- Simplifies the user-interface greatly and enhances the user experience.
- Enhances, but does not replace the security settings.
Still with the above done, there is still a few holes to be plugged. Users, while looking up a G/L account, could go to the G/L Account Card or Navigate and see the detail of posted entries. Navigation is an immensely useful feature, but the user could potentially drill down into the G/L entries, remove the filter and see any data in the G/L. This can be resolved with a few lines of code on the G/L Account Card and General Ledger Entries pages. It is recommended to add a field to the User Setup table which very few users will have access to. Call it, "G/L detail access". Then code the G/L Account Card and Entries page to error out unless the user has "G/L Detail Access". This should plug the final holes.
What if you don't have roles configured as above and you need to plug the holes right now? Then, you would take the coding approach above and apply it to all objects to be blocked. This would include minimally: G/L Account Card, G/L Entries page, G/L Registers Page and Report, Chart of Accounts and all reports on the General Ledger menu under Entries and Financial Statement. This sounds daunting, but is easily accomplished in a few hours.
Don Saito
All content provided on this blog is for informational purposes only. ERP Efficiency Experts, LLC makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. ERP Efficiency Experts, LLC will not be liable for any errors or omissions in this information nor for the availability of this information. ERP Efficiency Experts, LLC will not be liable for any losses, injuries, or damages from the display or use of this information.
Estimate for Upgrading Microsoft Dynamics NAV Causes Acid Reflux
If you are currently on NAV and looking to upgrade, particularly from NAV 2009 or earlier to NAV 2013 on up, you may have received an estimate from your partner which may have caused a moderate to severe physical reaction, depending on your constitution.
The reason for the huge costs to upgrade are primarily due to the major technological improvements in NAV 2013 and the lack of stellar upgrade tools for NAV 2009 and earlier. To make NAV more-web accessible, the screens (forms) were replaced by pages, data conversion tools (dataports) were replaced by XMLports and the proprietary report writer was replaced with Visual Studio.
So, what can you do to reduce the upgrade costs? Ask for a detailed estimate that breaks down the estimate by type of object. For example, what is the estimate to upgrade tables, forms, reports, dataports and codeunits.
The largest cost will likely be upgrading modified reports. So, this opens the door to reducing your upgrade costs. You can ask your provider to install code to track which reports you actually run prior to upgrading. You can also review the modified reports to see if you truly need them in the new system.
It is very likely a good majority of Dataports (data conversion utilities) do not need to be upgraded as there are often used for initial data conversions when you went live and no longer needed.
Upgrades from 2013 and onward will be much less likely to cause a severe reaction as the upgrade tools have been markedly improved.
Don Saito
All content provided on this blog is for informational purposes only. ERP Efficiency Experts, LLC makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. ERP Efficiency Experts, LLC will not be liable for any errors or omissions in this information nor for the availability of this information. ERP Efficiency Experts, LLC will not be liable for any losses, injuries, or damages from the display or use of this information.