The number of each field within its parent table object is the unique identifier that NAV uses internally to identify that field. We can easily change a field number when we are initially defining a table layout, but after other objects, such as Pages, Reports, or Codeunits, reference the fields in a table, it becomes difficult to change the number of referenced fields. Deleting a field and reusing its field number for a different purpose is not a good idea and can easily lead to programming confusion.

When we add new fields to standard NAV product tables (those shipped with the product), the new field numbers must be in the 50,000 to 99,999 number range, unless we have been explicitly licensed for another number range. Field numbers for fields in new tables that we create may be anything from 1 to 999,999,999.

When a field representing the same data element appears in related tables (for example, Table 37 Sales Line and Table 113 Sales Invoice Line), the same field number should be assigned to that data element for each of the tables. Not only is this consistent approach easier for reference and maintenance, but it also supports the TRANSFERFIELDS function. TRANSFERFIELDS permits the copying of data from one table's record instance to another table's record instance by doing record to record mapping based on the field numbers.

If we plan ahead and number the fields logically and consistently from the beginning of our design work and provide an entry in the Description column for each field, we will create code that's easier to maintain. It's a good idea to leave frequent gaps in field number sequences within a table. This allows the easier insertion of new fields numerically adjacent to related, previously defined fields. In turn, that makes it easier for the next developer to understand the modification's data structure.

See Object Numbering Conventions in the Developer and IT Pro Help section in the Development Environment for additional information.