The Reusable Dynamics NAV Patterns is a joint initiative between the NAV team and NAV partners. This is an open initiative to anyone who has documented design patterns which are specific to NAV, please reach back to us either by leaving a comment here, or by writing to us. This week, we introduce the pattern well before the weekend, just to break our own pattern again.
Meet the Standard Journal pattern, which gives the NAV user the advantage of storing transaction details and reusing them multiple times at later dates. For example, this is how to pay a monthly bill.
If the journal data can be reused later, the user has the possibility to save the current temporary transaction details. One example can be the case of monthly electricity payments. The user will manually enter the details for the first payment, of the current month. Next month, a part of the data will be the same, such as the vendor and transaction details. If the user has saved the initial monthly payment as a standard journal, then they can now reuse it to create the draft of the next monthly payment. Once the draft journal lines are created, they can be updated with the current month information.
When a journal is created, the user can invoke the Save as Standard Journal action to save the current journal for later use. When saving the journal as a standard journal, the user is required to choose a code, which is later used to identify the saved journal. The journal lines are stored in a separate table. There can be one standard journal saved per journal type and code.
Later, the user can create new journal lines by using the Get Standard Journals action. This action restores the saved journal into the new journal lines.
Step 1: The data entered by the user through the Journal page is stored temporarily in the Journal Line table. The data is available for editing or deleting. The journal line data will be stored in this table until it is either deleted or posted.
Step 2: The user decides to save the current journal line entries for later use. If this is the monthly rent, the user may want to use similar entries next month when a new payment is due. On the Journal page, the user invokes the Save as Standard Journal action. This triggers the Save as Standard Journal report, which copies the entries from the Journal Line table to the Standard Journal Line table. When saving, the user will be asked for an identifier, a code, which will be used to later uniquely identify the saved entries.
Step 3: When the user invokes the Get Standard Journal action, a list of codes are presented to the user so that they can decide which standard journal to restore and copy in the Journal Line table.
The sequence flow of the three steps is described in the following diagram.
In the standard version of NAV, the Standard Journal functionality is implemented in the following journals:
The user enters data in the General Journal page (39) and invokes the Save/Get actions as illustrated in the following screenshot:
When saving the journal lines, the Save as Standard Gen. Journal report (750) is invoked. The report saves the entries in the Standard General Journal Line table (751).
The Reusable Dynamics NAV Patterns team
Hello, I just wanted to thank you for the effort of putting the patterns into words. It really helps new developers doing things the "Dynamics Nav Way". I really hope you will keep up with this very good articles even if not many people will comment them. Sadly there isn't much more to say than thank you :)
I hope you guys keep up with these articles,too.There are very helpful for us.Thank you very much for your effort.
Great with this feature. But why stop with these two journals? My advice: For improving usability - go all the way and not only make a 80/20 solution? Customers can’t figure that part out with the fragmented feature philosophy.
Common users cannot figure out why requisition worksheets haven’t got this great feature (OK we have Recurring Req. worksheet – and then why do we have them?). In the ordinary req. worksheet the feature would be most useful. Tell a common user (in a simple trading company) to go and order a subset of items in the usual quantity (minimum order quantum) in the usual purchase units of measure (not the default purchase UoM from the item). He could go and make a purchase order but the subset of items are delivered by different vendors (and the vendor may change from time to time for these items). OK the user then go for the requisition worksheets. But here the user can order all items. Item lookup shows all available and not available items (throughout the whole solution). So it is very easy to order the wrong items. Why not give the user the possibility of choosing preconfigured list of items with minimum order quantum and correct unit of measures and so on. And afterwards running a sourcing availability check (may item be ordered, is the vendor blocked for ordering, is the order quantum still allowed, and when can we expect to have the items - all of them). If the check is OK then carry out Action Message (which is an odd name of a function – why not just call it “process the line/worksheet/journal”?).