During these years working with Dynamics NAV / Business Central, I have noted certain deficiencies in various processes of the application. These deficiencies are related to general functionalities that lead to frustration for the contracting company. In many cases, these frustrations arise because there is always an alternative way of doing things, even though that alternative may be very time-consuming, leading to surprises and the need for post-project development for a new client:
- Clients often feel that specific issues could have been addressed and communicated during the analysis phase instead of encountering the need for additional development later.
- It’s also possible that the counterpart, being aware of the generalities, chose to omit certain details.
- This situation raises questions about what else might be missing and whether the lack of specific procedures is due to minor deficiencies in the program rather than there being different correct ways of doing things.
I firmly believe that these well-known issues should be promptly addressed by the partners, and the program should be offered with several of these resolutions already implemented, especially if they are relevant to the client. This way, partners can openly say, “This doesn’t work as you need it, but we have modified it to fit your requirements,” without causing frustration during such a crucial phase as implementation.
I have always considered the implementation project as something that should be sold based on value, not just hours. Instead of stating that the project costs 30k and modifying automatic invoicing costs 1k, I can say the project costs 31k because we are solving an issue that the standard has in this case, due to the required functionality of automatic invoicing. This goes beyond an “economic” mindset.
Nowadays, this approach is a sine qua non condition to compete, as extensions have opened up the possibility of standardizing solutions, which reduces repetitive costs for implementers. I know that many implementers are working in this way.
General functionalities that, in my opinion, need to be changed or implemented before the client’s implementation are as follows:
Combine Shipments
The current invoicing process is based on sales orders and the subsequent registration of shipments. The combine shipments process generates invoices based on shipment records and certain breaking criteria (reasons for generating a new invoice instead of including more lines in an existing invoice), which include customer and invoicing party, currency, and dimension set. Consequently, if we have two sales orders from the same customer, one in dollars and the other in euros, two invoices will be generated – one in dollars and one in euros..
The issue with this approach is that it ignores crucial factors such as payment method, payment terms, VAT business posting group, customer discount group, invoice discount code, salesperson, etc. As a result, all delivery note lines originating from orders with different payment methods and terms will be part of an invoice with the payment method and term specified in the customer’s record.
For companies with significant dependencies on payment methods and terms or extensive use of discounts, the standard automatic invoicing does not meet their needs and requires modification.
In most cases, by adding payment method, payment term, and VAT business posting group as criteria, around 80% of companies would be covered, and an additional code field, for example, could be used to establish a new breaking criterion, making the standard solution applicable to almost all cases.
Bank Reconciliation
The bank reconciliation functionality in Business Central has various levels, from controlling the month-end balance with the bank to matching each bank entry and even registering payments based on a bank statement file. However, not all functionalities are available, and some should be included. (The basic functionality I consider necessary is the ability to match the recorded transactions against the actual bank movements.)
Bank reconciliation is often mentioned as a functionality, but it rarely includes the direct option to import any bank’s norm 43.
The norm 43 is a file that contains all the movements of our bank account, which banks allow exporting. By importing this file, one could match each bank movement recorded in the program with the actual movements from the bank or even use it to register bank transactions.
This is a general functionality that would be useful for all clients using Business Central. It’s essential for both parts to know that, unless stated otherwise, bank reconciliation, without further development, will not be of much use.
The development for this is quite straightforward; it involves importing a .txt file into a table without any additional functionality. Microsoft’s built-in functionality takes care of the automated comparison and matching of data.
Deletion of Posted Documents
The philosophy of Business Central is based on the idea that what is recorded remains recorded. To reverse an accounting entry, a counter-entry must be made; to cancel an invoice, a credit note must be issued. However, there is a particularly dangerous aspect.
In historical document pages, such as “Historical Purchase Invoices,” the deletion of records is allowed. This deletion only removes the document but does not undo all associated entries (accounting movements, VAT, etc.). This can lead to data inconsistencies, especially based on human analysis.
The philosophy behind this is that since Microsoft allows the registration of invoices from journals (not only as invoices but also as entities), and these do not generate historical invoices, there should be no issue with allowing deletion from the historical records. After all, processes like issued invoice books are based on VAT entries, while others may rely on customer movements. None of these processes are based on historical invoices, as there is no obligation for a document to appear in the historical records.
I believe it wouldn’t cost much, if the registration of invoices through journals is not required, to avoid the potential problem of being able to delete a historical invoice. It is a very simple and 100% standardized development, with almost no cost in its inception and no cost at all if used for different clients.
General Journals
All journals are the same; they all share the same table. The only difference between them is the visible fields. Why not consolidate them?
There is no need to have separate entries for the general journal, payment journal, or cash receipt journal. It’s good to differentiate them, but there’s no need to add complexity where it isn’t necessary, especially in accounting.
This modification to the program is straightforward and contributes to user-friendly navigation. Personally, I always prefer to have all fields available in one place to avoid switching back and forth.
Consolidation of Customer and Vendor Balances
In BC21, functionality has been included to perform this consolidation
Automatic blocking of clients and doubtful debtors
Many businesses deal with a large number of clients, including end consumers and retailers. In such cases, managing the appropriateness of continuing to serve a client based on unpaid invoices can be challenging.
A functionality could be implemented that automatically blocks a client based on the total amount of overdue debt and the number of days the debt has been overdue. The outstanding balance would then be transferred to a doubtful accounts receivable account, reflecting the company’s true financial position and ensuring that no further services are provided to that client, even by mistake.
In conclusion, the aforementioned points represent the most common and significant cases I have encountered, applicable to various companies. Some businesses may require personalized management of commissions and sales agents, while others may have specific needs related to proration, production, warranties, etc. However, the issues I have summarized are relevant to many companies and are relatively easy to address.
The main advantage of Business Central currently lies in its constant innovation and updates, the incorporation of improvements by Microsoft, and, most importantly, the capacity for making modifications to the system.
Nowadays, a development license is no longer required to make changes, allowing for the implementation of many small and straightforward alterations that add significant value and save time (such as modifying access, adding visible fields, automating processes, creating reports, etc.) at a lower cost than in the past.
Having a designated internal team capable of continuously improving the program and consolidating all knowledge about the company’s processes with the ERP has become increasingly beneficial. The cost of a “Development License” is no longer a concern. I believe it is now very cost-effective to have an internal team responsible for understanding all the details of the company’s relationship with its management system, analyzing and monitoring business operations with the help of the ERP partner. It is crucial not to completely outsource such an important aspect of the company as process improvement.
