- Implementing Microsoft Dynamics NAV(Third Edition)
- Alex Chow
- 762字
- 2021-07-09 19:31:02
No save button
Dynamics NAV does not have any kind of save button anywhere in the application. So, data is saved into the database as soon as the user leaves the field.
Likewise, a record is inserted in its table right after the field (or fields) of the primary key. Some pages such as Sales Line and the different journals have the DelayedInsert
property set to Yes
, which means that the record won't be inserted until the user moves the cursor to the next line or the next record.
The main advantage
The major advantage is that users can create any card (for instance, Customer Card), any document (for instance, Sales Order), or any other kind of data without knowing all the information that is needed. Let's explain this with an example.
A new customer has to be inserted into the database. For Dynamics NAV, it is mandatory to fill in some information to actually be able to post any transaction with the customer. The mandatory fields are Gen. Bus. Posting Group and Customer Posting Group.

As you can see in the previous image, the Customer Posting Group field has not been filled for this customer. It doesn't matter right now; you can leave the card without losing the rest of the information that was introduced and come back to the card when you have figured out the Customer Posting Group that has to be used with this customer. The not-losing-the-rest-of-the-information part is important.
Imagine that there actually was a Save button; you would spend a few minutes filling in all the information and at the end, hit the Save button. At that moment, the system carries out some checks and finds out that one field is missing. It throws you a message saying that the customer card cannot be saved. So you basically have two options:
- To lose the information introduced until that moment, find out the posting group for the customer, and start all over again.
- To cheat. Fill the field with some wrong value so that the system actually lets you save the data. Of course, you can come back to the card and change the data once you've found out the right one.
Nothing will prevent any other user to post a transaction with the customer in the meantime.
When is the data verified?
How does Dynamics NAV verify the data that the user enters? Certainly not by someone looking over their shoulder. The data is verified when it is needed. In most cases, information in the master tables is needed when selecting a record either in a document or in a journal line, or when the posting routines are run.
Since customer number 61000
has a relevant field missing on its card, if you try to select this customer in Sales Order, you will get a runtime error that will say Customer Posting Group must have a value in Customer No.=61000. It cannot be zero or empty.
Some other data, such as the posting dates, will be checked when posting a transaction. You can set up your Dynamics NAV solution so that you only allow your user to post transactions using a specific range of dates. Posting dates can be restricted for the whole company or only to certain users.
Posting dates are an example of data that the system checks while posting a transaction. If posting dates are not allowed, an error message will be thrown saying Posting Date is not within your range of allowed posting dates.
The main drawback
There is one main drawback of validating the data this way. The problem will not occur until you try to post. An example would be when we have to post a shipment; the shipping agent is waiting with his truck and Dynamics NAV throws an error message because someone up the chain didn't properly do their job.
Problems like this can be mitigated by setting default values to the mandatory fields through modifications or through templates. However, the company should have the proper process or guideline in place for people to follow; the users should be responsible for their work. Basically, accountability is required.
In a way, this "drawback" is a benefit because there's no place for people to hide. Mistakes are reflected in a relatively short timeframe within your organization and you will be able to weed out who's good and who's not.
In our case, if the truck leaves and the warehouse person has to fill in the paperwork manually, you can go yell at the person responsible for setting up the data.
- Django Design Patterns and Best Practices
- bbPress Complete
- Mathematica Data Analysis
- 量化金融R語言高級教程
- Teaching with Google Classroom
- Instant Nancy Web Development
- Mastering C++ Multithreading
- Canvas Cookbook
- Android應用開發(fā)實戰(zhàn)(第2版)
- Practical Predictive Analytics
- Android應用開發(fā)攻略
- Python繪圖指南:分形與數(shù)據(jù)可視化(全彩)
- Mastering Clojure
- Visual FoxPro數(shù)據(jù)庫程序設計
- Access 2016數(shù)據(jù)庫應用與開發(fā):實戰(zhàn)從入門到精通(視頻教學版)