Below content is directly copied from the above link**** ## Ensuring SimplicityWhen you write a solution in Microsoft Dynamics NAV, keep it simple. This applies to everything that becomes visible either to other programmers or to any users. The following are a few examples.
1. If the default value for a property is appropriate for a specific purpose, then do not make the default value explicit.
## Setting PropertiesTo set properties from C/AL, use code that is similar to the following code.
"Customer No.".Visible := TRUE;
Cust.MARK := TRUE;
Do not use the following code.
## Writing LookupsWhen writing lookups in C/AL, do not filter records that the user may want to select. Instead, program the record cursor to be positioned on the most relevant record for the search even though it may not be first on the list. When programming the OnLookup trigger for a field, the code in the field’s OnValidate trigger is not called unless you explicitly call Field.VALIDATE. If errors can occur in the validation, then you must operate on a copy of the Rec variable as shown in the following example instead of directly on the Rec variable.
WITH Cust DO BEGIN
Cust := Rec;
Dept.Code := "Department Code";
IF PAGE.RUNMODAL(O,Dept) = Action::LookupOK THEN BEGIN
"Department Code" := Dept.Code;
Rec := Cust;
To make Lookup work on a field that has a table relation to a system table, you must always explicitly set the [LookupPageID Property](https://msdn.microsoft.com/en-us/library/dd338987(v=nav.90).aspx) on controls that show the field.
Set the [LookupPageID Property](https://msdn.microsoft.com/en-us/library/dd338987(v=nav.90).aspx) and [DrillDownPageID Property](https://msdn.microsoft.com/en-us/library/dd301384(v=nav.90).aspx) on most tables. You cannot anticipate when a user must activate a Lookup or DrillDown button. For example, if a user creates a report with a filter tab on the table, then the Lookup button on the filter tab will not appear unless the LookupPageID property is set on the table.
## Designing Journal PagesThe default order of fields in journals is:
1. Card pages
## Card PagesSome card pages are related to a table that contains only a few fields. It is not hard to create such pages because it is often obvious where to place the fields on FastTabs on a page and which fields to promote to the FastTab header. Most card pages are related to tables with many fields.
Many pages use several FastTabs. How many FastTabs are needed and what to call them are specific to each page. The following FastTab names are commonly used:
1. General**, which is the first tab
|## Section||## Example fields||Dates**|| 1. **Posting
Date** ||**Document** || 1. **Entry Type**
||**No. (of Account)** ||**No.** ||**Posting Description** ||**Description** ||**Dimensions** || 1. **Department Code**
||**Currency** || 1. **Currency Code**
||**General Posting Setup** || 1. **General
Posting Type** ||**Quantity** || 1. **Quantity**
||**Prices/Cost** || 1. **Direct Unit Cost**
||Amounts** || 1. **Amount** ||Balancing Account** ||**Balancing Account
Type** **Balancing Account No.** **Balancing General Posting Type**
**Balancing General Business Posting Group** **Balancing General Product
Posting Group****||Sales/Purchase and
Discount** || 1. **Sales/Purchase (LCY)** ||**Payment Terms** || 1. **Payment Terms
Code** ||**Application** || 1. **Serial No.**
||**Miscellaneous Information** || 1. **Cost
Is Adjusted** ||**Intrastat** || 1. **Transaction Type**
||**Posting Information** || 1. **Quantity to
Ship** ||**Audit Information** || 1. **User ID**