Microsoft ® Business Solutions–Navision ® 4.0 Development II - C/SIDE Solution Development Day...

Microsoft® Business Solutions–Navision®

4.0 Development II - C/SIDE Solution

Development

Microsoft® Business Solutions–Navision®

4.0 Development II - C/SIDE Solution

Development

Day 2

Managing Master FilesManaging Master Files

Review Questions

Multilanguage – Text ConstantsMultilanguage – Text Constants

4 of 65

Text ConstantsText Constants

• Defined as C/AL Globals• Captions for different languages

(ConstValueML)• Used instead of text strings in C/AL code

– Definition : Text001:ENU=‘%1 must be positive.’

– Usage : ERROR(Text005,FIELDCAPTION(Amount));

• Use table and field captions to replace the placeholders in text constants

Matrix FormsMatrix Forms

6 of 65

Matrix FormMatrix Form

Form SourceTable fields (SourceTable = Item)

Matrix Header TextBox

Matrix Box (MatrixSourceTable = Location)

Form SourceTable field (SourceTable = Item) Calculated per Item and Location

Filter and Options(SourceTable = Item)

7 of 65

Matrix FormsMatrix Forms

OnAfterGetRecord (Form)OnAfterGetRecord (Form)

OnAfterGetRecord (Matrix)OnAfterGetRecord (Matrix)

Triggers

• Fires for each source table record (Item)

• Fires for each matrix source table record (Location)• Used to update calculated matrix fields (Inventory)• C/AL code example:

SETRANGE("Location Filter",CurrForm.ItemAvailMatrix.MatrixRec.Code);CALCFIELDS(Inventory);

Table TypesTable Types

9 of 65


• Database Table– Regular table type to store data in the

database

• Virtual Table– Information provided by the system

• Temporary Table– Temporary variable to buffer table data on

client side

• System Table– Created automatically by the system

10 of 65


• Table that contains information provided by the system

• Information is read-only• Data is not stored in the database• Table definition cannot be modified• Can be used, for example, to show dates

in different periods (Date table)

Virtual Table

11 of 65


• Temporary variable based on a database table

• Data stored temporarily in workstation’s memory

• Write transactions principle does not apply• Reduces load on server and network• Can be used, for example, in posting

functions (table Invoice Post. Buffer)

Temporary Table

12 of 65


• Tables created automatically by the system

• Data is stored in the database• Table definition can be modified• Can be used by the system, for example,

to manage security and permissions (User, Member Of and User Role tables)

System Table

13 of 65

Additional FunctionsAdditional Functions

• CALCDATE• DATE2DMY• DATE2DWY• ROUND• RUNMODAL• CONFIRM• MESSAGE• ERROR• TESTFIELD• WORKDATE• VALIDATE• FORMAT• COUNT

Managing RegistrationsManaging Registrations

Lab

15 of 65

ConclusionConclusion

• We have now created the tables and forms necessary to register participants in seminars

• Now that we can enter transaction information, we need to create a posting routine

Managing RegistrationsManaging Registrations

Review Questions

17 of 65

ReviewReview

• Multilanguage – Using Text Constants• Matrix Forms• Table Types

Structure of Journal FormsStructure of Journal Forms

19 of 65


TemplateTemplate BatchBatchBatchBatch

BatchBatch LineLineLineLine

LineLineLineLine

Form Types

LineLine

20 of 65


• General Journal Templates– Set up different journal windows– Template for batches– No posting possible

• General Journal Batches– Different batches for each template– Set up for journals, like Bal. Account– Posting possible

• General Journal Line– Each line belongs to one template and batch– Transaction information for posting, such as Date,

Account and Amount– Posting possible

General Journal Forms

Journal Posting RoutinesJournal Posting Routines

22 of 65


• The Difference between a Journal and a Ledger

• Standard Journal to Ledger Posting Routines

• The Main Three Codeunits• The Theory behind Document Posting• The Codeunits used in Document Posting

23 of 65

The Difference between a Journal and a Ledger

• Ledger• Protected Table• Primary Key - Entry No.

An Integer• Entry Numbers Start at 1• Many Secondary Keys• Holds the Majority of the Detail

Information for the Functional Area

• NEVER INSERT OR DELETE!

•Journal• Temporary Work Area• Main Table is Journal Line• Two Supplemental Tables

• Journal Template• Journal Batch

• Compound Primary Key• Line Number Incremented Automatically


24 of 65

Numbering of Journal Posting RoutinesNumbering of Journal Posting Routines

1 Journal Check Line2 Journal Post Line3 Journal Post Batch

1 Journal Check Line2 Journal Post Line3 Journal Post Batch

0 Journal Management1 Journal Post2 Journal Post+Print3 Journal Batch Post4 Journal Batch Post+Print5 Show Ledger

0 Journal Management1 Journal Post2 Journal Post+Print3 Journal Batch Post4 Journal Batch Post+Print5 Show Ledger

•Posting routines

•Management and “starter” routines

Journal Posting Routines

25 of 65

Standard Journal to Ledger Posting RoutinesStandard Journal to Ledger Posting Routines

• “Starter” Routines - Just ask Question(s) and Go– 1. Post - Posts One Batch– 2. Post and Print - Posts One Batch and Prints

Register– 3. Batch Post - Posts Multiple Batches– 4. Batch Post and Print - Posts Multiple Batches

and Prints Each Register

26 of 65

Standard Journal to Ledger Posting RoutinesStandard Journal to Ledger Posting Routines

• Posting Routines - Don’t Ask, Just Do the Work– 1. Check Line - Test the Journal Line without

Disturbing Server– 2. Post Line - Transfer Data from Journal Line to

Ledger Line(s)– 3. Post Batch - Process a User-Entered Journal

27 of 65

The Main Three Posting Routine CodeunitsThe Main Three Posting Routine Codeunits

• Check Line• Post Line• Post Batch

28 of 65


• Check Line– Checks One Journal Record (Line)– No User Interface– Never Reads or Updates Journal Table– Does Data Entry Testing which does not Disturb

Server• Test to See if User Entered all Required Data• Tests that Certain Business Rules have been Followed• Tests for Valid Posting Dates• Tests may Read a Setup Record, but only if it can be

done Once per Posting Process

29 of 65


• Post Line– Posts One Journal Record (Line)– No User Interface– Never Reads or Updates Journal Table– Calls Check Line for its Journal Record– Does Validity Testing which can Read Records

from Other Tables– Creates Ledger Entry or Entries (needs

Permissions to do so)– Applies (links) Ledger Records as Necessary– Can be called from Other Posting Routines

30 of 65


• Post Batch– Posts Records from One Batch of Journal Table– Displays Progress to User, but no User Input

Allowed– Calls Check Line for Each Record in Journal– Does Total / Balance / Recurring Testing– Calls Post Line for Each Record in Journal– Deletes or Updates Journal Records

31 of 65

Architecture of Journal Posting RoutinesArchitecture of Journal Posting Routines

Post BatchCodeunit X3Post Batch

Codeunit X3

Post LineCodeunit X2

Post LineCodeunit X2

Check LineCodeunit X1Check Line

Codeunit X1

Check LineCodeunit X1Check Line

Codeunit X1

Starter RoutineStarter Routine

Journal Posting Routines

Document Posting RoutinesDocument Posting Routines

33 of 65

The Theory Behind Document PostingThe Theory Behind Document Posting

• What is a Document?• Breaking it Down

34 of 65

Header

Line 2(selling an

Item)

Line 3(selling a

Resource)

Line 1(selling an Account)

GeneralJournal

Document Tables Journal Tables Ledger Tables

ResourceJournal

ItemJournal

ResourceLedger

ItemLedger

CustomerLedger

General LedgerAccounts Rec. AcctSales Account 1Sales Account 2Sales Account 3

CreditsDebitsBalance Detail Entry

The Theory Behind Document Posting


35 of 65


Post documentCodeunit X0

Post documentCodeunit X0

Post document preparationCodeunit X1 / X2

Post document preparationCodeunit X1 / X2

Architecture of Document Posting

Type

Gen. Journal-Post Line (CU12)Gen. Journal-Post Line (CU12)

Gen. Journal Line TableGen. Journal Line Table

Item Journal-Post Line (CU22)Item Journal-Post Line (CU22)

Item Journal Line TableItem Journal Line Table

36 of 65


0 Document - Post0 Document - Post

1 Document - Post (Yes/No)2 Document - Post +Print1 Document - Post (Yes/No)2 Document - Post +Print

•Posting function

•Start functions

Numbering of Document Posting Routines

37 of 65


• A sales document is posted primarily by codeunit 80 – Sales-Post

• You can however post an entire batch of sales invoice documents by calling report 297

38 of 65


• Focusing in on Codeunit 80 (Sales-Post)– First, it creates a Journal Line using a record

variable (usually called GenJnlLine, ResJnlLine, ItemJnlLine, etc...) for the appropriate journal

– All of the necessary fields are assigned values from the Header or the Line (mostly the Line)

– Other values are calculated or retrieved from the posting group tables

– Finally, the record variable (never inserted into the table) is passed to the PostLine Codeunit for the appropriate journal

– All postings to the G/L go through the Gen. Jnl.-Post Line Codeunit

Table LockingTable Locking

40 of 65


• Different locking in Microsoft Navision and Microsoft® SQL Server®

• All write operations automatically lock the table or the record (SQL Server only) in use

• Use LOCKTABLE to explicitly lock a table in C/AL

• Use RECORDLEVELLOCKING to test for SQL Server

• Use COMMIT to end a write transaction manually only where needed

41 of 65


Microsoft Navision Database Server• Whole table is locked when issuing LOCKTABLE• Consistent versions for read tasks• Optimistic concurrency for multiple records by

means of LOCKTABLE(TRUE,TRUE)

SQL Server Option• Records are locked when accessed after LOCKTABLE• When no LOCKTABLE: Dirty reads (”Read

Uncommitted”)• Optimistic concurrency supported for single records

by means of Timestamp field added to all tables

Major Differences between Microsoft Navision and SQL Server

Performance IssuesPerformance Issues

43 of 65

Low Impact ProgrammingLow Impact Programming

• Low Impact on the Application• Low Impact on the Server• Low Impact on the Network• Low Impact on the Database

44 of 65

Low Impact on the ApplicationLow Impact on the Application

• Modifying Existing Objects– Tables– Reports– Codeunits– Forms

45 of 65


• Tables– In some cases, it is better to add a new table

than to modify an existing table– It is better to add a new field to an existing

table than to modify the meaning of an existing field

– It is better to change the Caption property than the Name property

– It is better to change the caption of an existing field than to add a new field, if the only purpose is to change the name

– Try to write new functionality into separate functions

46 of 65


• Reports– Always create a copy of an existing report and

modify the copy– Document changes well– Try to write new functionality into separate

functions

47 of 65


• Codeunits– Try to write new functionality into separate

functions

48 of 65


• Forms– Most changes– Hard to document– Try to write new functionality into separate

functions using local variables

49 of 65

Low Impact on the ServerLow Impact on the Server

• COMMIT• LOCKTABLE• INSERT, MODIFY, DELETE• CALCSUMS, CALCFIELDS• Keys• Validity Testing

50 of 65


• COMMIT– Handled automatically for almost all

applications– Should almost never be used manually

51 of 65


• LOCKTABLE– Limit to only where necessary.– Insert, modify, rename, and delete will lock

automatically.

52 of 65


• INSERT, MODIFY, DELETE– Try to structure to not use the return value.

53 of 65


• CALCSUMS, CALCFIELDS– Use when possible rather than looping through

records.– Takes about the same amount of time as one Get

command.

54 of 65


• Keys– Define new keys when appropriate– Select keys carefully, based on filters– Attach SumIndexFields to the most efficient key

55 of 65


• Validity Testing– When possible, perform tests that do not

involve the server first– Use temporary tables

56 of 65

Low Impact on the NetworkLow Impact on the Network

• MODIFYALL, DELETEALL• CALCSUMS, CALCFIELDS• Filters

57 of 65


• MODIFYALL, DELETEALL– Use these commands when possible, vs.

MODIFY and DELETE– Use appropriate keys and filters

58 of 65


• CALCSUMS, CALCFIELDS– Multiple parameters can sum many fields with

one function call (and one network packet)

59 of 65


• Filters– Use when possible, even if not part of a key

60 of 65

Low Impact on the DatabaseLow Impact on the Database

• SumIndexFields• Keys• Duplication of Data

61 of 65


• SumIndexFields– Take up a significant amount of space, only use

where beneficial

62 of 65


• Keys– Take up a significant amount of space, only use

where beneficial– Assign infrequently used keys to Key Groups

and deactivate when not needed

63 of 65


• Duplication of Data– Avoid where possible

Debugging ToolsDebugging Tools

65 of 65

Debugging ToolsDebugging Tools

• Navision Debugger– Checks C/AL code lines– Uses breakpoints– Contains several windows to watch fields,

variables, and stack

• Code Coverage– Logs objects and code– Shows not-executed lines in different color

(red)

Microsoft ® Business Solutions–Navision ® 4.0 Development II - C/SIDE Solution Development Day...

Documents

Transcript of Microsoft ® Business Solutions–Navision ® 4.0 Development II - C/SIDE Solution Development Day...