Sie sind auf Seite 1von 10

NAV

Development rules

DOCUMENTINFORMATION
Microsoft Dynamics NAV development rules
Microsoft Dynamics NAV development rules for Bejo V5.doc
Final
V1.06
30 June 2010
J.J.P. Beemster
30 June 2010

Document title
Document name
Document status
Version
Version date
Auteur
Release date

VERSIONMANAGEMENT
Version Datum

Status Changed by

Description

V1.00
V1.01
V1.02
V1.03
V1.04
V1.05
V1.06

Final
Final
Final
Final
Final
Final
Final

Field modified added


Object range Bejo Add-on modified
Object range Bejo Add-on trade modified
Units Changed
Variable naming section added
Free Dataports changed
Table range for Prod Add On expanded

27 March 2008
13 August 2008
6 November2008
16 February 2009
12 March 2009
3 February 2010
30 june 2010

J.J.P. Beemster
J.J.P. Beemster
J.J.P. Beemster
J.J.P. Beemster
P. Blokker
J.J.P. Beemster
P. Blokker

RESPONSABLES

Sign

Date

J.J.P. Beemster

J.J.P. Beemster

Team Manager NAV

Lead

INDEX
INTRODUCTION...........................................................................................................................................3
Overview ...........................................................................................................................................................3
2. DOCUMENTATION ......................................................................................................................................4
Labelling the changes .......................................................................................................................................4
Development units ............................................................................................................................................5
Used Object Ranges.........................................................................................................................................5
Variable naming conventions............................................................................................................................7
Variable naming conventions for Complex Data Types ..................................................................................7
Variable naming conventions for normal Data Types .....................................................................................7
Other naming conventions ................................................................................................................................7
3. PROJECT GUIDELINES...............................................................................................................................8
Project guidelines..............................................................................................................................................8
4. REFERENCES..............................................................................................................................................9
5. OPEN ISSUES/RISKS ................................................................................................................................10
1.

Pagina 2 of 10

Dynamics NAV development rules for Bejo 1.06

1. INTRODUCTION
Overview
This document describes the development rules for Microsoft Dynamics NAV for Bejo Companies.
The intention of this document is to work together with international NAV partners, local NAV partner in the
Netherlands, internal developers at Bejo Zaden (the Netherlands) as well application managers at local Bejo
companies. The bases of this document are the standard development rules described in document on the
white paper on partner source.

Version V

Page 3 of 10

Dynamics NAV development rules for Bejo 1.06

2. DOCUMENTATION
Labelling the changes
In an international environment all information must be written in the English language.
The changes must be documented by the company/developer who is changing the objects.
Every development group has got his own identification. The identification and the version number combined
is the label what must be added to the change.
First of all the code what is changed is labeled with this reference.
A sample of a small code change should be like this:
State := "Employee."Default Work State"; // BEJORO3.70.123
If an entire Block of code has been added or modified, mark the change as follows:
// - BEJORO3.70.123 --JobLedgEntry."Seminar Registration No." := "Seminar Registration No.";
// + BEJORO3.70.123 +++
For the removal of a block of code, mark it as follows:
{ - BEJORO3.70.123 --- Start Deletion
State := "Employee."Default Work State";
Locality := "Employee."Default Work Locality";
"Work Type Code" := Employee."Default Work Type Code";
+ BEJORO3.70.123 +++ End Deletion}
For a full description see also Dynamics NAV course 8873A_NA50_ENUS_DEVII chapter 4.
The old code written by another development group may never be deleted from the object code.
The developer who has written the old code may decide for legibility reasons to delete the code. The
developer must describe this in the documentation trigger.
The reference is always written in the documentation trigger.
A sample of information in the documentation trigger should be as follows:
YYYYMMDD Version
Sign Proj.Ref. Description
------------------------------------------------------------------------20071213 BEJOPL3.70.123 JBe 070322
Seminar Registration added

YYYYMMDD: The date of change column is intend start with year. There will be no discussion about
the place of the month.
Version: Start with the development unit, like BEJO, NAV or LLP. When the development unit delivers
for more groups then this would be added. For example BEJOPL (Bejo Poland), BEJOWW (Bejo
world wide) or NAVW1. After the development unit the version of the NAV database including the
version numbering is added. For example BEJOPL3.70.123. The delivery is from the IT-service desk
of Bejo and is special made for Bejo Poland. The database version is 3.70. And this change is a part
of the 123th delivery in the production environment. Before that there were 122 .fobs installed.
Sign: The programmer, In this case Jeroen Beemster
Proj.Ref: The reference to a project number. This number is per development unit different. For the
Bejo IT department this field is not optional. Local NAV partners can use this for a contract no.
Description: Description of the change. One ore two lines is mostly enough

Version V

Page 4 of 10

Dynamics NAV development rules for Bejo 1.06

In the object designer the version identification is also added into the field version list. Every development
unit must write the highest version into this field. This field can contain more than one version, but only one
per development unit. For example NAVW13.70.01,BEJOWW3.70.20,BEJOPL,3.70.123
As a sign of delivery into the production environment, the field modified must be turned off.

Development units
The following development units are known and can not be used by other development units
Code
NAVW1
NAVPL
ITESY
BEJOWW
BEJOPL
CDCR
BEJOPRWW
BEJOPRUS

Development unit,
Dynamics NAV international version W1
Dynamics NAV Poland, polish localization
(you may read for PL also RO for Romania, RU for Russia and so on. )
Integro, Local Dynamics NAV partner Poland
IT service desk Bejo, the Netherlands, Standard Bejo Add-on Trade
IT service desk Bejo, the Netherlands, Bejo Poland modifications
(you may read PL also RO for Romania, RU for Russia and so on.)
Dynamics NAV hotfix
IT service desk Bejo, the Netherlands, Standard Bejo Add-on Production
IT service desk Bejo, the Netherlands, Bejo USA modifications
(you may read for US also FR for France, AU for Australia and so on.)

Used Object Ranges


The following ranges must be purchased for the Bejo Add-on
50.000 50.019 Tables
50.040 50.049 Tables
50.000 50.099 Forms
50.000 50.099 Reports
50.000 50.099 Data-ports
50.000 50.099 XML-Ports
50.000 50.009 Code-units
The field numbering in a table, used for the Bejo Add-on (code BEJOWW) is always in the range
50.000 59.999. If a field is added which only used in one country the field numbering must be in the range
60.000 69.999.
Objects in use by the Bejo add-on:
50.000-50.019 Tables
50.048-50.048 Tables
50.000-50.039 Forms
50.056-50.079 Forms
50.090-50.099 Forms
50.000-50.044 Reports
50.058-50.099 Reports
50.021-50.049 Dataports
50.060-50.069 Dataports
50.090-50.099 Dataports
--------- --------- XML port
50.002-50.002 Codeunits
50.007-50.009 Codeunits
51
51 Menu-Suite

Version V

Page 5 of 10

Dynamics NAV development rules for Bejo 1.06

Objects in use by Bejo Production:


This is currently NOT a part of the Bejo Add-on Trade.
50.100-50.130 Tables
50.100-50.199 Forms
50.100-50.199 Reports
50.007-50.013 Dataports
50.050-50.059 Dataports
--------- --------- XML port
50.010-50.019 Codeunits
50.100-50.100 Codeunits
52
52 Menu-Suite
Objects free to use for local NAV Partners:
50.040-50.045 Tables
50.040-50.055 Forms
50.080-50.089 Forms
50.045-50.057 Reports
50.070-50.089 Dataports
50.050-50.099 XML port
50.003-50.006 Codeunits
Please take notice of the information in Chapter three of this document when using this object-range.

Version V

Page 6 of 10

Dynamics NAV development rules for Bejo 1.06

Variable naming conventions


There are no official naming conventions for variables but to enhance the portability of code it is desirable to
have some rules for naming variables. These naming conventions are obligatory for Bejo employed
developers but they are guidelines for external contractors.

Variable naming conventions for Complex Data Types


In order to easily identify the scope of Complex Data Type variables (i.e. a record, table, form, codeunit etc.)
it is recommended to use the following prefix conventions for Complex Data Type variables.
Scope of a variable:
The first character of the prefix is a g or a l and this describes the scope (global versus local) of the variable.
i.e. a variable named grecSalesline for a Sales line record has a g as the first character of the prefix, this
means the variable is a global variable. A variable name like lcuDimMgt tells that this is a local variable for the
codeunit Dimension Management.
Prefixes for Complex Data Type variables: (without the scope character)
blob
BLOB
rec
Record
frm
Form
cu
Codeunit
dlg
Dialog
rpt
Report
dtf
DateFormula
tbf
TableFilter
recref RecordRef
recid RecordID
fldref FieldRef
keyref KeyRef
instr
InStream
outstr OutStream
var
Variant
bigtxt BigText

Variable naming conventions for normal Data Types


In order to easily identify the scope of Data Type variables (i.e. type Integer, Code, Boolean etc.) it is
recommended to use the following prefix conventions for Data Type variables.
Scope of a variable:
The first character of the prefix is a g or a l and this describes the scope (global versus local) of the variable.
i.e. a variable named gInteger for an Integer type variable has a g as the first character of the prefix, this
means the variable is a global variable. A variable name like lHasChanged for a Boolean type variable tells
that this is a local variable.
Normal Data Types do not have prefixes that tell the type of the variable.
i.e. an Integer type variable is not named gintInteger but simply gInteger.

Other naming conventions


Variables must be formed with/from words in the English language.
With Text Constants use the Text prefix combined with a numeric identifier: i.e.: Text000, Text50000.
With temporary tables use the prefix Temp. i.e. TempObject for a temporary table containing objects.

Version V

Page 7 of 10

Dynamics NAV development rules for Bejo 1.06

3. PROJECT GUIDELINES
Project guidelines
Since there are more suppliers involved in the development of NAV for Bejo companies there must be a
protocol to ensure an adequate system. The main key to success is to communicate with each supplier. But
some rules must be kept in mind.
1)
2)
3)
4)

The IT Service desk of Bejo has got the overall responsible for the whole system.
The local partner is responsible for the first implementation without the Bejo Add on.
The local partner is responsible that the legal issues in the country are supported in NAV
The IT Service desk of Bejo, has got the full responsible of objects in the range 50.000 59.999. If a
local partner wants to use one of these object-numbers then Bejo IT service desk will reserve a free
object number.
5) The project guidelines can be overruled by a project plan. All involved parties must agree (and sign)
the project plan. This new agreement written in the project plan is only for the period of the project.

Each change made by a local partner must be send by e-mail to the IT Service desk of Bejo. The change
must be delivered to the IT Service desk of Bejo before this is installed in the production environment.
To secure that no more than one supplier is changing the same object, only one supplier may do the changes
at the same time. Before a local partner want to make a change, Bejo IT Service desk must give a timeslot
where the change can be made. In this timeslot there are no changes made by Bejo IT Service desk. Bejo IT
service desk receives the changed objects by e-mail. The local partner may not change the objects
afterwards. The timeslot will be closed. The changes may never be installed in the production environment
without an improvement form Bejo IT Service desk.

Version V

Page 8 of 10

Dynamics NAV development rules for Bejo 1.06

4. REFERENCES
In this chapter some documentation is copied from official whitepapers and courses of Microsoft Dynamics.
8873A_NA50_ENUS_DEVII.4 Introduction to c/side solution development in Dynamics NAV 5.0
Documentation in Existing Objects
When changes are made to an existing object, a note should be entered in the
Documentation trigger. Usually, this means one note for each feature. The note
heading should contain a reference number, the date the modification was
completed, the name of the developer responsible for the modification, the
project name, and a short description of the change. Here is an example:
Microsoft Business Solutions
------------------------------------------------------Project: Solution Development II Training
jtd: John T. Doe
No. Date Sign Description
------------------------------------------------------001 01.21.2004 jtd Created
002 05.05.2004 jtd Transfer new field
Seminar Registration No.
Notice that documentation in an existing object looks similar to the
documentation in a new object, except that a new reference number is created for
each modification.
Code Comments
Along with the general comments that provided in the Documentation trigger, it
is important to provide comments in the code at the lines where a change has
been made. Only do this when modifying an existing object, not when creating a
new object.
The key is to mark the changed code with the same reference number as used in
the Documentation trigger of the object. For example, a modified single line of
code should be marked like this:
State := "Employee."Default Work State"; // jtd002
If an entire block of code has been added or modified, mark
the change as follows:
// - jtd:002 --JobLedgEntry."Seminar Registration No." := "Seminar
Registration No.";
// + jtd:002 +++
For the removal of a block of code, mark it as follows:
{ - jtd:002 --- Start Deletion
State := "Employee."Default Work State"; Locality :=
"Employee."Default Work Locality"; "Work Type Code" :=
Employee."Default Work Type Code";
+ jtd:002 +++ End Deletion}
Note that this keeps the old code in place, just commented out. Never delete
Microsoft Dynamics NAV base code comment it out instead.

Version V

Page 9 of 10

Dynamics NAV development rules for Bejo 1.06

8873A_NA50_ENUS_DEVII.10 Introduction to c/side solution development in Dynamics NAV 5.0


Customer has Design Tools
If the customer has Design Tools, the problem is that the customer probably does
not follow the Microsoft Dynamics NAV development rules. These include rules
about setting the Version Tags and Modification Flags, internal object
documentation, developing on line, and not using a project log, so one cannot tell
why they made a change.
The solution has two parts; first, better planning is necessary. Try to teach
customers the rules, explaining how it makes upgrading easier. Or, just get them
to follow one rule leave the Modification Flags alone. This rule is easy to
follow, since it does not require them to do anything.

5. OPEN ISSUES/RISKS
Description issue/risk

Action/Solution

Responsible

1.
2.
3.

Version V

Page 10 of 10