This topic describes best practices for developing C/SIDE applications.

Ensuring Simplicity

When you program a solution in C/SIDE, keep it simple. This applies to everything that becomes visible either to other programmers or to any users. The following are a few examples.

  • If the default value for a property is adequate for a certain purpose, then do not make the default value explicit.

  • If a variable can be reset using a statement such as a := 0; then do not use a special C/AL function, such as the CLEAR Function, to reset the variable.

  • If the contents of a record can be copied using a statement such as MyRec := MyRec2; then do not use a special C/AL function, such as the TRANSFERFIELDS Function (Record), to copy the contents.

Activating Objects

If you want to use the value of a field to find a record in a table or if you want to activate an object identified by the field, then ensure that the field contains a value. To do this, use the TESTFIELD Function (Record), as shown in the following example. This produces more informative error messages if the value is zero or blank.

  CopyCode imageCopy Code 
GLEntry.TESTFIELD("Department Code");
Dept.GET(GLEntry."Department Code");
GenJnlTemplate.TESTFIELD("Report ID");
REPORT.RUN(GenJnlTemplate."Report ID")

Setting Properties

To set properties from C/AL, use code that is similar to the following code.

  CopyCode imageCopy Code 
"Customer No.".Visible := TRUE;
Cust.MARK := TRUE;
CurrReport.SHOWOUTPUT := TRUE;

Do not use the following code.

  CopyCode imageCopy Code 
Customer." No.".Visible(TRUE); 
Cust.MARK(TRUE);
CurrReport.SHOWOUTPUT(TRUE);

Writing Lookups

When 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.

  CopyCode imageCopy Code 
WITH Cust DO BEGIN
  Cust := Rec;
  Dept.Code := "Department Code";
  IF FORM.RUNMODAL(O,Dept) = Action::LookupOK THEN BEGIN
	"Department Code" := Dept.Code;
	VALIDATE("Department Code");
	Rec := Cust;
  END;
END;

To make Lookup work on a field that has a table relation to a system table, you must always explicitly set the LookupFormID Property on controls that show the field.

Set the LookupFormID Property and DrillDownFormID Property 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 LookupFormID property is set on the table.

Designing Journal Forms

The default order of fields in journals is:

  • Date

  • Document Type

  • Document No.

  • No.

  • Description

  • Amount

The order of fields in ledger entries should be the same. The order of fields in forms, pages, and reports should also be the same.

Laying Out Fields on Forms and Pages

This section contains guidelines for which fields to include on the following forms and pages:

  • Card forms

  • Tabular forms

  • Card pages

  • Worksheet pages.

For each type of forms and pages, consistency is important. Similar pages in the application areas must be composed the same way.

Card Forms and Pages

Some card forms and pages are related to a table that contains only a few fields. It is not hard to create such forms and pages because it is often obvious where to place the fields on tabs in a form or on FastTabs on a page and which fields to promote to the FastTab header. Most card forms and pages are related to tables with many fields.

Many forms pages use several tab or FastTab controls. How many tabs or FastTabs are needed and what to call them are specific to each form and page. The following tab and FastTabs names are commonly used:

  • General, which is the first tab

  • Invoicing

  • Posting

All relevant fields must be included on a card form or page. Even card forms and pages with many tabs have a limited space for fields, so you must carefully consider relevancy. Which fields to include depends on the purpose of each form or page. We recommend using the following guidelines:

  • Always include dimensions, such as department, project, or location.

  • Do not include fields that are automatically filled in and do not need to be changed by the user.

  • Do not place the same field on a form or page twice, even on different tabs.

  • If two or more fields are related according to source or function, then group them.

On which tab or FastTab to place a field depends on the specific form or page. Some tabs and fields are used on many pages. For consistency, place the following fields on the General tab or FastTab:

  • No.

  • Name

  • Search Name

  • Blocked

  • Last Date Modified

  • Other information about the account

Place the following fields on the Posting or Invoicing tab or FastTab:

  • General Business Posting Group

  • General Product Posting Group

  • Posting group from the actual application area

  • Department Code

  • Project Code

Tabular Forms and Worksheet Pages

The information in this section refers to tabular forms and also applies to tabular pages.

In general, all fields are included on tabular forms. Some exceptions are mentioned in the following section. The fields are shown or hidden depending on how relevant they are and what the layout of the form is. You must consider the following points when you create tabular forms:

  • Always include dimensions, such as department or project. The fields should be hidden.

  • Do not include FlowFields on tabular forms unless the form is seldom used or the field is essential. FlowFields are calculated even when they are hidden.

  • Do not include more than about 25 fields on a form, because this can affect performance. Consider carefully which fields, both hidden and visible, that you will include on a form. Because of performance considerations, tabular forms should not include fields that may be informative but cannot be changed, such as Posting Group, Journal Name, Weights, and Source Type.

  • Never include fields that are used internally in the program, such as Closed by Entry No.

  • Use tabular forms for all forms in the Setup menu. Creating these forms does not typically cause problems because they often contain only a code and a few information fields.

Tabular forms such as journals, sales/purchase lines, and ledgers are difficult to create and maintain properly because the related tables contain a lot of functionality and many fields. In an uncustomized application, the same template is used to compose these forms so that they look similar. The following table shows the template. It is divided into sections according to functionality. In each section, the most common field names are mentioned.

NoteNote

The table does not include all functionality. Additionally, the order that is indicated in the table does not always indicate the order in forms.
Section Example fields

Dates

  • Posting Date

  • Document Date

Document

  • Entry Type

  • Document Type

  • Document No.

No. (of Account)

No.

Posting Description

Description

Dimensions

  • Department Code

  • Project Code

  • Business Unit Code

  • Location Code

  • Salesperson/Purchaser Code

  • Work Type Code

  • Phase Code

  • Task Code

  • Step Code

Currency

  • Currency Code

  • Exchange Rate

General Posting Setup

  • General Posting Type

  • General Business Posting Group

  • General Product Posting Group

Quantity

  • Quantity

  • Invoiced Quantity

  • Remaining Quantity

  • Unit of Measure Code

Prices/Cost

  • Direct Unit Cost

  • Indirect Cost %

  • Unit Cost

  • Total Cost

  • Profit %

  • Unit Price

  • Total Price

  • Price Group Code

  • Chargeable

    NoteNote

    The exact name and order depend on the application area.

Amounts

  • Amount

  • Amount Including VAT

  • VAT Amount

  • Remaining Amount

    NoteNote

    Amounts in LCY must follow each amount type.

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

  • Sales/Purchase (LCY)

  • Profit (LCY)

  • Line Discount %

  • Line Discount Amount

  • Allow Invoice Discount

  • Invoice Discount Amount

Payment Terms

  • Payment Terms Code

  • Due Date

  • Payment Discount Date

  • Payment Discount %

Application

  • Serial No.

  • Applies-To Document Type

  • Applies-To Document No.

  • Applies-To ID

  • Applies-To Item Entry

  • Applies-To Entry

  • Apply and Close (Job)

  • Open

Miscellaneous Information

  • Cost Is Adjusted

  • Cost Posted to G/L

  • On Hold

  • Bank Payment Type

Intrastat

  • Transaction Type

  • Transport Method

  • Country Code

Posting Information

  • Quantity to Ship

  • Quantity Shipped

  • Quantity to Invoice

  • Quantity Invoiced

Audit Information

  • User ID

  • Source Code

  • Reason Code

  • Entry No.

See Also