Each object and field in C/SIDE is identified by a number that is stored in its ID Property. This topic describes the numbering system for the development environment. Numbering conventions that are used in the base application and guidelines for objects and fields that are outside the base application are described.

The Numbering System

The objects in C/SIDE are grouped as indicated in the following table.

Object number interval	Description
1 - 9,999	Base application design area
10,000 - 49,999	Country/region design area
50,000 - 99,999	Customer design area
100,000 - 999,999,999	Microsoft Certified Partner design area

Note
Do not use the object numbers 99,000 - 99,999 for objects that you create, even though they are in the customer design area. The training material for Microsoft Dynamics NAV uses these numbers.

The fields in C/SIDE are grouped as indicated in the following table.

Table number	Field numbers	Description
1 - 9,999	1 - 9999	Base application design area
1 - 9,999	10,000 - 49,000	Country/region design area
1 - 9,999	50,0000 - 99,999	Customer design area
1 - 9,999	100,000 - 999,999,999	Microsoft Certified Partner design area
10,000 - 49,999	1 - 49,999	Country/region design area
10,000 - 49,999	50,000 - 99,999	Customer design area
10,000 - 49,999	100,000 - 999,999,999	Microsoft Certified Partner design area
50,000 - 99,999	1 - 999,999,999	Customer design area
100,000 - 99,999,999	1 - 9,999	Microsoft Certified Partner design area
100,000 - 99,999,999	10,000 - 49,999	Country/region design area
100,000 - 99,999,999	50,000 - 99,999	Customer design area
100,000 - 99,999,999	100,000 - 999,999,999	Microsoft Certified Partner design area

Note
Do not use the field numbers 99,000–99,999 in tables numbered between 1 and 49,999 for fields that you create, even though they lie in the customer design area. The training material for Microsoft Dynamics NAV uses these numbers.

When a Microsoft Certified Partner buys the insert permissions for a table number interval, such as 200,000–200,099, the partner also gets insert permissions for the same number interval (200,000–200,099) for fields in all other tables. If you create a table in the range for which you have insert permissions, then it is possible to create fields in all field number intervals in the table. However, we recommend that you use only the field numbers that are in the same number interval as the table number interval so that fields in solutions from different partners do not interfere with each other.

Objects

The numbering conventions for objects depend on the object type. Conventions for the following types are described in the following sections:

Tables
Forms
Reports
Codeunits

Tables

Table object numbers are not divided into intervals in the base application. Use the first available object number when you create a table. Try to group related tables together.

Forms

Form object numbers are not divided into intervals in the base application. Use the first available object number when you create a form. Try to group related forms together.

Reports

Report objects are numbered in intervals in the base application. The following table displays the interval for each application area.

Report number interval	Application areas
1 - 99	G/L, including VAT and Consolidation
100 - 199	Accounts Receivable
200 - 299	Sales
300 - 399	Accounts Payable
400 - 499	Purchases
500 - 599	Common to both Purchases and Sales, including Exchange Rate
600 - 699	Requisition
700 - 799	Item, including Intrastat
800 - 899	Bill of Materials
900 - 999	Item Group
1000 - 1099	Inventory (common to Item, BOM, and Item Group)
1100 - 1199	Resource
1200 - 1299	Job
1300 - 1399	General
1400 - 9899	Future areas
9900 - 9999	Utilities

If you create a new report that does not belong in one of the existing application areas or if you create a new report and the area in which it belongs is full, then use a number from a new interval of length 100 and between 1,400 and 9,899.

If a report object can be printed, then it is called a report. Otherwise, it is called a batch job. Reports are numbered starting at the lower end of the interval. Batch jobs are numbered starting at the higher end of the interval with decreasing numbers.

We recommend that you number reports that are almost identical within the application areas with the same two final digits even if the report name is different. For example, the Sales Invoice report in the base application is number 206 and the Purchase Invoice report is number 406. Other examples are the date compression batch jobs for ledger entry tables, which always end with 98, and date compressions for budget entries, which always end with 97. This practice may cause gaps in the numbering sequence, but it helps the developer when adjustments to similar reports elsewhere in the application are needed.

Codeunits

Codeunit object numbers are not divided into intervals in the base application. Use the first available object number when you create a codeunit. Try to group related codeunits together.

The journal posting codeunits follow a pattern that makes it easier to understand a new journal once you are familiar with one group of journal posting codeunits.

A group consists of two parts:

Codeunits in the first part post a journal.
Codeunits in the second part manage the journals.

Codeunit final digit	Journal posting codeunits
1	Journal Line-Check
2	Journal Line-Post
3	Batch Name-Post

Codeunit final digit	Journal managing codeunits
0	Journal-Management
1	Journal-Post
2	Journal-Post+Print
3	Journal-Batch Post
4	Journal-Batch Post+Print
5	Register-Show Ledger

Codeunits for posting invoices also follow a pattern, which is displayed in the following table.

Codeunit final digit	Sales/Purchase Posting Codeunits
0	Sales/Purchase Post
1	Sales/Purchase Post (Yes/No)
2	Sales/Purchase Post+Print

When you create codeunits for the sales application areas, use the same final digit for similar purchase application areas.

Table Fields

When you assign numbers to new fields in a table, consider whether the table is associated with other related tables. If so, then you may need to also add the fields to these related tables. In this case, the field must have the same field number in all tables. For example, if you add a new field to the Customer table but do not add the field to the Vendor table, then you still must reserve that field number in the Vendor table for the new field from the Customer table. It is easier to maintain the application when the tables look very similar.

Examples of associated tables are:

Customer and Vendor tables
Journal template tables
Batch name tables
Journal line tables
Sales Header, Sales Shipment Header, Sales Invoice Header, and Sales Credit Memo Header tables
Purchase Line, Purchase Receipt Line, Purchase Invoice Line and Purchase Credit Memo Line tables

When you create a new independent table, do not leave gaps in the field numbers.