978-1-904811-74-9 www.packtpub.com Cover Image by David Studebaker ( navbook@libertyforever.com ) Credits Author David Studebaker Reviewers Luc Van Dyck Mark Brummel Senior Acquisition Editor Douglas Paterson Development Editor Mithil Kulkarni Technical Editors Nilesh Kapoor Divya Menon Kushal Sharma Editorial Manager Dipali Chittar Project Manager Patricia Weir Project Coordinator Abhijeet Deobhakta Indexer Bhushan Pangaonkar Proofreader Chris Smith Production Coordinators Shantanu Zagade Manjiri Nadkarni Cover Designer Shantanu Zagade Foreword In 1986 the Navision founders Jesper Balser, Torben Wind, and Peter Bang were looking back on the successful release of their Zrst product cPC-Plus d. It was the Zrst easy-to-use accounting package for the IBM PC on the Danish market. It immediately picked up a huge market share and the founders started thinking about how to expand the business.<br><br> They decided to try to sell a vertical solution for auto-repair shop spare-part management 4but they were immediately [ooded with requests from potential customers who wanted to have the product tailored exactly to meet their needs. Because of this they decided to get out of the customization business, thus enabling partners to do the customization while providing them with the right tools. PC-Plus used a database, which was based on the ISAM database, which Anders Hejlsberg wrote as a sample program for his Pascal compiler.<br><br> However the database was not multiuser and if the power went, data could easily get corrupted. Other database alternatives were either too expensive or of poor quality, so they decided to write their own database. The result of this was the Navision product, which had a rich set of tools for modifying the business application and a robust multiuser version-based database.<br><br> The product became a huge success with a rapidly growing number of partners, who recognized a big business opportunity, and customers, who could have the product tailor-made to fulZll the speciZc needs of their businesses. The Windows version of Navision was released in 1995 and became part of the Windows revolution. The rest is history: the company went international, went public, and in 2002 was acquired by Microsoft.<br><br> I joined Navision in 1987 and have been a part of this amazing journey. Today as part of Microsoft, the team and I have started a new journey with the product now called Microsoft Dynamics NAV and will bring the product to the .net platform. Next, we will introduce a new role-tailored client, enabling us to reach even more partners and customers moving forward.<br><br> Michael Nielsen, Director of Engineering, Microsoft Dynamics NAV About the Author David Studebaker is currently a Principal of Liberty Grove Software, Inc., with his partner Karen Studebaker. Liberty Grove Software provides development, consulting, training, and upgrade services for Microsoft Dynamics NAV resellers and Zrms using NAV internally. Liberty Grove Software is a Microsoft CertiZed Partner.<br><br> David has been recognized by Microsoft three times as a CertiZed Professional for NAV 4in Development, in Applications, and in Installation & ConZguration. He is also a CertiZed Microsoft Trainer for NAV. He began developing with C/AL in 1996.<br><br> David Studebaker has been programming since taking his Zrst Fortran II course in 1962. In the fall of 1963 he took the Zrst COBOL course taught at Purdue University, where the Zrst U.S. computer science department was later created.<br><br> The next spring, undergraduate student David was assigned to teach the graduate-level class. Since that time, David has been an active participant in each step of computing technology 4from the early mainframes to today's technology, from binary assembly coding to C/AL. He has worked with over 40 different models and brands of computers, over a dozen operating systems, and over two dozen different programming languages.<br><br> Special projects include the development of Zrst production SPOOL system in 1967. In the decades following, David was project manager and lead developer for several commercially distributed business application systems. Application areas in which David has worked range from engineering to manufacturing to freight carriage to general accounting to public mass transit to banking to not-for-proZt and association management to legal billing to distribution/inventory management to shop [oor data collection and production management.<br><br> David has a BS in Mechanical Engineering from Purdue University and an MBA from the University of Chicago, both with concentrations in Computer Science. David has been a computer operator, system programmer, application programmer, business analyst, consultant, service bureau operations manager, bureaucrat, teacher, project manager, trainer, documenter, software designer, mentor, writer, and entrepreneur. He has been partner or owner and manager of several computer systems businesses, while always maintaining a signiZcant role as a business application developer.<br><br> David's work with relational databases and 4th-generation languages with integrated development environments began in 1984. David assisted in script-writing for a series of audio training courses for early PC operating systems and wrote for a newsletter Computers in Education . A series of articles by David concerning the use of computer systems to track and help manage manufacturing shop [oor operations were published in several trade and professional magazines.<br><br> He was lead author of the Product IdentiZcation and Tracking section of the SME Tool and Manufacturing Handbook. For over ten years, David was a reviewer of business applications-related publications for Computing Reviews of the Association for Computing Machinery (ACM). David has been a member of the ACM since 1963 and was a founding ofZcer of two local chapters of the ACM.<br><br> About the Reviewers Luc Van Dyck is active as a software consultant and works for a Belgian Microsoft partner. He started working with Dynamics NAV in 1997 (at that time it was called Navision Financials 1.10). In the year 1999, he started the website http://myNavision.net to provide a forum and downloads for users of the Dynamics NAV ERP system.<br><br> When Microsoft bought Navision Software A/S in 2002, the site was renamed to http://mibuso.com ; mibuso.com is one of the largest on-line communities of Microsoft Dynamics professionals. This on-line community gives users and developers of products from the Microsoft Dynamics family (Navision, Axapta, CRM, Great Plains, ...) a place to exchange ideas and tools, and to Znd business partners and products. The website provides you with a forum where you can ask questions about the different Dynamics products.<br><br> It also contains a large selection of downloads, in different categories (code examples, demo versions, webcasts, factsheets, tools, etc.). Microsoft partners can submit their company details to the Business Directory and publish their add-ons or factsheets in the Product Directory. In October 2004, he was awarded with the MVP status (Most Valuable Professional) by Microsoft, for his active participation in the Dynamics community.<br><br> Mark Brummel is an all-round NAV expert. He started 10 years ago in 1997 as an end user, being an early adopter of the system. Two years later he started working for a local reseller and used his end-user perspective to develop add-ons for NAV.<br><br> In the following years he has developed Zve major add-ons for three NAV partners and was involved in over a hundred implementations. Next to the development projects he has guided and trained both experienced consultants and young talent in becoming NAV experts. Because of his experience in all aspects of NAV implementations Mark started to specialize in escalation engineering.<br><br> In the year 2006, he started his own company specialized in this Zeld, helping both end-users and partners with problems. To share knowledge he writes articles and gives workshops. He also assists Microsoft at events like Tech Ed and Convergence and participates in product development.<br><br> One of his special skills is performance-tuning of NAV systems, combining both technical and functional knowledge to establish better-running systems and happier end users. In the year 2006, Mark Brummel was rewarded with the MVP award by Microsoft. Table of Contents Preface 1 Chapter 1: The Basic Ingredients 11 Some Unique NAV Terms Defined 12 The C/SIDE Integrated Development Environment 13 Object Designer Tool Icons 14 Seven Kinds of NAV Objects 15 More Definitions (Related to NAV) 16 NAV Functional Terminology 18 Getting Started with Application Design 18 Tables 19 Example: Table Design 19 Example: Table Creation 20 Forms 22 Card Forms 23 Tabular Forms 24 Main/Sub Forms 24 Matrix Forms 25 Trendscape Forms 26 All Forms 27 Creating a Card Form 27 Creating a List Form 31 Reports 34 Creating a List Format Report 35 Codeunits 38 MenuSuites 39 Dataports 39 XMLports 40 Integration Tools 40 Backups and Documentation 41 Summary 42 Table of Contents [ ii ] Chapter 2: Tables 43 Overview of Tables 43 What Makes Up a Table?<br><br> 44 Table Naming 45 Table Numbering 45 Table Properties 45 Table Triggers 47 Keys 49 SumIndexFields 52 Expanding Our Sample Application 53 Table Creation and Modification 53 Keys 60 Adding Some Activity-Tracking Tables 61 New Tables 63 Keys and SumIndexFields in Our Examples 68 Types of Tables 72 Totally Modifiable Tables 72 Content-Modifiable Tables 82 Read-Only Tables 83 Summary 85 Chapter 3: Fields 87 Fields 87 Field Properties 87 Field Numbering 94 Renumbering a Field 95 Changing the Data Type of a Field 96 Field Triggers 98 Some Data Structure Examples 99 More Definitions 99 Variable Naming 100 Data Types 101 Fundamental Data Types 101 Numeric Data 101 String Data 102 Time Data 102 Complex Data Types 104 Data Item 104 DateFormula 104 Data Structure 110 Objects 111 Automation 111 Input/Output 111 References and Other 112 Table of Contents [ iii ] Data Type Usage 112 FieldClasses 113 Filtering 118 Defining Filter Syntax and Values 119 Experimenting with Filters 123 Summary 131 Chapter 4: Forms 133 What Is a Form? 133 Controls 134 Bound and Unbound 134 NAV Form Look and Feel 134 Types of Forms 136 Accessing the Form Designer 141 What Makes Up a Form? 141 Form Properties 143 Forms Controls 145 Explore 146 Inheritance 149 Experimenting with Controls 149 Control Triggers 151 Control Properties 153 Experimenting with Control Properties 155 Some Control Property Tips 155 More Illumination with C/ANDL 157 Update the Member Forms 161 Testing Forms 167 Creative Plagiarism 167 Form Design Hints 168 A Quick Tour of the Form Designer 169 Keys to Learning NAV 172 Summary 173 Chapter 5: Reports 175 What is a Report?<br><br> 176 NAV Report Look and Feel 176 NAV Report Types 177 Report Types Summarized 181 Report Naming 182 Report Components Overview 182 The Components of a Report Description 183 Report Data Flow 183 The Elements of a Report 186 Report Properties 186 Table of Contents [ iv ] Report Triggers 188 Data Items 189 Data Item Properties 190 Data Item Triggers 193 Data Item Sections 194 Run-Time Formatting 194 Report Wizard-Generated Sections 195 Report Section Descriptions 195 More Run-Time Formatting 198 Section Properties 198 Section Triggers 199 Controls for Reports 200 Control Properties 202 Inheritance 203 Request Form 203 Request Form Properties 205 Request Form Triggers 205 Request Form Controls 205 Request Form Control Triggers 206 Processing-Only Reports 206 Revising a Generated Report 207 Revision 4First Design 208 Revision 4Second Design 211 Creating a Report from Scratch 213 Creative Report Plagiarism 223 Special Output Issues 223 Printing PDF Files 224 Printing HTML Formatted Output 224 Printing to an Impact Printer 225 Summary 225 Chapter 6: Introduction to C/SIDE and C/AL 227 Essential Navigation 228 Object Designer 228 Starting a New Object 229 Some Designer Navigation Pointers 236 Exporting Objects 237 Importing Objects 238 Text Objects 240 Object Numbers 240 Some Useful Practices 241 Changing Data Definitions 242 Saving and Compiling 242 Some C/AL Naming Conventions 244 Table of Contents [ v ] Variables 245 Global Variables 245 Local Variables 245 Special Working Storage Variables 246 A Definition of Programming in C/SIDE 249 Functions 250 Basic C/AL Syntax 258 Assignment and Punctuation 258 Wild Cards 259 Expressions 260 Operators 260 Some Basic C/AL 264 MESSAGE, ERROR, CONFIRM, and STRMENU Functions 265 SETCURRENTKEY Function 270 SETRANGE Function 270 GET Function 271 FIND 3NEXT Functions 272 BEGIN 3END Compound Statement 274 IF 3THEN 3ELSE Statement 274 Indenting Code 275 Some Simple Coding Modifications 276 Adding a Validation to a Table 276 Adding Code to Enhance a Report 280 Summary 289 Chapter 7: Intermediate C/AL 291 Development 291 C/AL Symbol Menu 292 Internal Documentation 294 Computation 4Validation Utility Functions 296 TESTFIELD 296 FIELDERROR 297 VALIDATE 298 ROUND 299 TODAY, TIME, and CURRENTDATETIME Function 300 WORKDATE Function 300 Data Conversion Functions 301 FORMAT Function 301 EVALUATE Function 302 DATE Functions 302 DATE2DMY Function 302 DATE2DWY Function 302 DMY2DATE and DWY2DATE Functions 303 Table of Contents [ vi ] CALCDATE Function 303 FlowField-SumIndex Functions 304 CALCFIELDS Function 305 CALCSUMS Function 305 Flow Control 306 REPEAT 3UNTIL Control Structure 306 WHILE 3DO Control Structure 307 CASE 3ELSE Statement 307 WITH 3DO Statement 309 QUIT, BREAK, EXIT, SKIP, and SHOWOUTPUT Functions 310 QUIT Function 310 BREAK Function 311 EXIT Function 311 SKIP Function 311 SHOWOUTPUT Function 311 Input and Output Functions 312 NEXT Function (with FIND) 312 INSERT Function 313 MODIFY Function 313 Rec and xRec 313 DELETE Function 314 MODIFYALL Function 314 DELETEALL Function 315 Filtering 315 SETRANGE Function 316 SETFILTER Function 316 COPYFILTER and COPYFILTERS Functions 317 GETFILTER and GETFILTERS Functions 317 MARK Function 318 CLEARMARKS Function 318 MARKEDONLY Function 318 RESET Function 318 InterObject Communication 319 Via Data 319 Via Function Parameters 319 Via Object Calls 319 Use the New Knowledge 320 A Development Challenge for You 320 Phase 1 321 Phase 2 322 Phase 3 322 A Sample Approach to the Challenge 322 Phase 1 322 Table of Contents [ vii ] Phase 2 327 Phase 3 329 Summary 334 Chapter 8: Advanced NAV Development 335 Callable Functions 336 Codeunit 3 358 Date Filter-Calc 336 Codeunit 359 3 Period Form Management 337 Codeunit 365 3 Format Address 339 Codeunit 396 3 NoSeriesManagement 340 Codeunit 397 3 Mail 341 Codeunit 408 3 Dimension Management 342 Codeunit 412 3 Common Dialog Management 342 Sampling of Function Models to Review 344 Codeunit 228 3 Test Report-Print 344 Codeunit 229 3 Print Documents 345 Some other Objects to Review 345 Management Codeunits 345 Documenting Modifications 346 Multi-Language 347 Multi-Currency 348 Code Analysis and Debugging Tools 348 Developer's Toolkit 349 Relations to Tables 350 Relations from Objects 351 Source Access 352 Where Used 352 Try it Out 354 Working in Exported Text Code 356 Using Navigate 358 Testing with Navigate 359 The Debugger 362 The Code Coverage Tool 363 Dialog Function Debugging Techniques 364 Debugging with MESSAGE 364 Debugging with CONFIRM 364 Debugging with DIALOG 364 Debugging with Text Output 365 Debugging with ERROR 365 Summary 366 Chapter 9: Designing NAV Modifications 367 Starting a New NAV Enhancement Project 367 Design of NAV Modifications 368 Table of Contents [ viii ] Knowledge is Key 370 Creating a New Functional Area 370 Advantages of Designing New Functionality 371 Enhancing an Existing Functional Area 372 NAV Development Time Allocation 373 Data-Focused Design for New Functionality 373 Define the Big Picture: The End Goals 373 A Simple Sample Project 374 Then Define the Little Pictures 374 Sample Project Continued 41 375 Define What Data is Required to Create the Pictures 375 Sample Project Continued 42 375 Define the Sources for the Data 375 Sample Project Continued 43 376 Define the Data "Views" 377 Sample Project Continued 44 378 Other Factors Must Always be Considered 378 NAV Processing Flow 378 Data Preparation 379 Enter Transactions 379 Provide for Additional Data Testing 380 Post the Journal Batch 380 Access the Data 381 Continuing Maintenance 381 Designing a New NAV Application Functionality 381 Define the Data Tables 382 Design the User Data Access Interface 382 Design the Data Validation 382 Appropriate Data Design Sequence 383 Design Posting Processes 383 Design Support Processes 383 Double-Check Everything 384 Summary 384 Chapter 10: External Interfaces 385 MenuSuites 385 MenuSuite Levels 386 MenuSuite Structure 387 MenuSuite Internal Structure 388 MenuSuite Development 389 NAV Menus before V4.0 393 Dataports 394 Dataport Components 394 Table of Contents [ ix ] Dataport Properties 395 Dataport Triggers 397 Data Item 398 Data Item Properties 398 Data Item Triggers 400 Dataport Fields 401 Dataport Field Properties 405 Dataport Field Triggers 406 XMLports 406 XMLport Components 407 XMLport Properties 408 XMLport Triggers 410 XMLport Data Lines 410 XMLport Line Properties 414 Element or Attribute 417 XMLport Line Triggers 418 Advanced Interface Tools 419 Automation Controller 419 NAV Communication Component 420 Linked Server Data Sources 420 NAV ODBC 421 C/OCX 421 C/FRONT 421 NAV Application Server (NAS) 422 Summary 422 Chapter 11: Design to Succeed 423 Design for Efficiency 424 Disk I/O 424 Locking 424 C/SIDE versus SQL Server Databases 426 SQL Server I/O Commands 428 FINDFIRST Function 428 FINDLAST Function 429 FINDSET Function 429 Design for Updating 430 Customization Project Recommendations 430 One at a Time 431 Design, Design, Design 432 Test, Test, Test 432 Plan for Upgrading 436 Benefits of Upgrading 437 Coding Considerations 437 Good Documentation 438 Low-Impact Coding 438 Table of Contents [ x ] The Upgrade Process 439 Upgrade Executables Only 439 Full Upgrade 440 Tips for Small Successes 441 Cache Settings for Development 441 Two Monitors 442 Simple System Administration 442 Careful Naming 445 Tools 445 Code Coverage 446 Client Monitor 447 Creating Help for Modifications 448 Implementation Tool 448 Other Reference Material 448 Summary 450 Index 451 Preface There are two mistakes one can make along the road to truth... not going all the way, and not starting. 3 The Buddha By choosing to study C/AL and C/SIDE, you have started down another road.<br><br> The knowledge you gain here and subsequently about these tools can be applied to beneZt yourself and others. The information in this book will shorten your learning curve on how to program for the NAV ERP system using the C/AL language and the C/SIDE integrated development environment. By embarking on the study of NAV and C/AL, you are joining a high-quality, worldwide group of experienced developers.<br><br> There is a collegial community of C/AL developers on the Web who readily and frequently share their knowledge. There are formal and informal organizations of NAV-focused users, developers, and vendor Zrms both on the Web and in various geographic locations. The NAV product is one of the best on the market and it continues to grow and prosper.<br><br> Welcome aboard and enjoy the journey. A Business History Timeline The current version of Microsoft Dynamics NAV is the result of much inspiration and hard work along with some good fortune and excellent management decision-making over the last quarter century or so. The Beginning Three college friends, Jesper Balser, Torben Wind, and Peter Bang, from Denmark Technical University (DTU) founded their computer software business in 1984 when they were in their early twenties.<br><br> That business was Personal Computing & Consulting (PC & C) and its Zrst product was called PC Plus. Preface [ 2 ] Single User PC Plus PC Plus was released in 1985 with a primary goal of ease of use. An early employee said its functional design was inspired by the combination of a manual ledger journal, an Epson FX 80 printer, and a Canon calculator.<br><br> Incidentally, Peter Bang is the grandson of one of the founders of Bang & Olufsen, the manufacturer of home entertainment systems par excellence. PC Plus was PC DOS-based, a single user system. PC Plus' design features included: An interface resembling the use of documents and calculators Online help Good exception handling Minimal computer resources required The PC Plus product was marketed through dealers in Denmark and Norway.<br><br> Multi-User Navigator In 1987, PC & C released a new product, the multi-user Navigator and a new corporate name, Navision. Navigator was quite a technological leap forward. It included: Client/Server technology Relational database Transaction-based processing Version management High-speed OLAP capabilities (SIFT technology) A screen painter tool A programmable report writer In 1990, Navision was expanding its marketing and dealer recruitment efforts into Germany, Spain, and the United Kingdom.<br><br> Also in 1990, V3 of Navigator was released. Navigator V3 was still a character-based system, albeit a very sophisticated one. If you had an opportunity to study Navigator V3.x, you would instantly recognize the roots of today's NAV product.<br><br> By this time, the product included: A design based on object-oriented concepts Integrated 4GL Table, Form, and Report Design tools (the IDE) Structured exception handling Built-in resource management " " " " " " " " " " " " " " " Preface [ 3 ] The original programming language that became C/AL Function libraries The concept of regional or country-based localization When Navigator V3.5 was released, it also included support for multiple platforms and multiple databases. Navigator V3.5 would run on both Unix and Windows NT networks. It supported Oracle and Informix databases as well as the one developed in-house.<br><br> At about this time, several major strategic efforts were initiated. On the technical side, the decision was make to develop a GUI-based product. The Zrst prototype of Navision Financials (for Windows) was shown in 1992.<br><br> At about the same time, a relationship was established that would take Navision into distribution in the United States. The initial release in the US in 1995 was V3.5 of the character-based product, rechristened Avista for US distribution. Navision Financials for Windows In 1995, Navision Financials V1.0 for Microsoft Windows was released.<br><br> This product had many (but not all) of the features of Navigator V3.5. It was designed for complete look-and-feel compatibility with Windows 95. There was an effort to provide the ease of use and [exibility of development of Microsoft Access.<br><br> The new Navision Financials was very compatible with Microsoft OfZce and was thus sold as "being familiar to any OfZce user". Like any V1.0 product, it was fairly quickly followed by a V1.1 that worked much better. In the next few years, Navision continued to be improved and enhanced.<br><br> Major new functionalities were added: Contact Relation Management (CRM) Manufacturing (ERP) Advanced Distribution (including Warehouse Management) Various Microsoft certiZcations were obtained, providing muscle to the marketing efforts. Geographic and dealer base expansion continued apace. By 2000, according to the Navision Annual Report of that year, the product was represented by nearly 1,000 dealers (Navision Solution Centers) in 24 countries and used by 41,000 customers located in 108 countries.<br><br> " " " " " " Preface [ 4 ] Growth and Mergers In 2000, Navision Software A/S and its primary Danish competitor, Damgaard A/S, merged. Product development and new releases continued for the primary products of both original Zrms (Navision and Axapta). In 2002, the now much larger Navision Software, with all its products (Navision, Axapta, and the smaller, older C5 and XAL) was purchased by Microsoft, becoming part of the Microsoft Business Systems division along with the previously purchased Great Plains Software business and its several product lines.<br><br> Since that time, one of the major challenges for Microsoft has been to meld these previously competitive business into a coherent whole. One aspect of that effort was to rename all the products as Dynamics software, with Navision being renamed to Dynamics NAV. Fortunately for those who have been working with Navision, Microsoft has not only continued to invest in the product, but has increased the investment.<br><br> This promises to be the case for the foreseeable future. C/AL's Roots One of the Zrst questions often asked by developers and development managers new to C/AL is "what other language is it like?" The proper response is "Pascal". If the questioner is not familiar with Pascal, the next best response would be "C" or "C#".<br><br> At the time the three founders of Navision were attending classes at Denmark Technical University (DTU), Pascal was in wide use as a preferred language not only in computer courses, but in other courses where computers were tools and software had to be written for data analyses. Some of the strengths of Pascal as a tool in an educational environment also served to make it a good model for Navision's business applications development. Perhaps coincidentally (perhaps not) at DTU in this same time period, a Pascal compiler called Blue Label Pascal was developed by Anders Hejlsberg.<br><br> That compiler became the basis for what was Borland's Turbo Pascal, which was the "everyman's compiler" of the 1980s because of its low price. Anders went with his Pascal compiler to Borland. While he was there Turbo Pascal morphed into the Delphi language and IDE tool set under his guidance.<br><br> Anders later left Borland and joined Microsoft, where he led the C# design team. Much of the NAV-related development at Microsoft is now being done in C#. So the Pascal-C/AL-DTU connection has come full circle, only now it appears to be C#-C/AL.<br><br> Keeping it in the family, Anders' brother, Thomas Hejlsberg is also now working at Microsoft on NAV and AX at the campus in Copenhagen. Preface [ 5 ] In a discussion about C/AL and C/SIDE, Michael Nielsen of Navision and Microsoft, who developed the original C/AL compiler, runtime, and IDE, said that the design criteria were to provide an environment that could be used without: Dealing with memory and other resource handling Thinking about exception handling and state Thinking about database transactions and rollbacks Knowing about set operations (SQL) Knowing about OLAP (SIFT) Paraphrasing some of Michael's additional comments, the language and IDE design was to: Allow the developer to focus on design, not coding, but still allow [exibility Provide a syntax based on Pascal stripped of complexities, especially relating to memory management Provide a limited set of predeZned object types, reducing the complexity and learning curve Implement database versioning for a consistent and reliable view of the database Make the developer and end user more at home by borrowing a large number of concepts from OfZce, Windows, Access, and other Microsoft products Michael is still working as part of the Microsoft team in Denmark on new capabilities for NAV. Another example of how, once part of the NAV community, most of us want to stay part of that community.<br><br> The Road Ahead This book will not teach you programming from scratch, nor will it tutor you in business principles. To get the maximum out of this book, you should come prepared with some signiZcant experience and knowledge. You will beneZt most if you already have the following attributes: Experienced developer More than one programming language IDE experience Knowledgeable about business applications Good at self-directed study " " " " " " " " " " " " " " " Preface [ 6 ] If you have those attributes, then by careful reading and performance of the suggested exercises in this book, you should signiZcantly reduce the time it will take you to become productive with C/AL and NAV.<br><br> This book's illustrations are from the W1 Cronus database V5.0. Hopefully this book will smooth the road ahead and shine a little light on some of the potholes and the truths alike. Your task is to take advantage of this opportunity to learn and then use your new skills productively.<br><br> What This Book Covers Chapter 1 covers basic deZnitions as they pertain to NAV and C/SIDE. Also, an introduction to seven types of NAV objects, Form and Report Creation Wizards, and tools that we use to integrate NAV with external entities is provided. There is a brief discussion of how different types of backups and documentation are handled in C/SIDE at the end.<br><br> Chapter 2 focuses on the top level of NAV data structure: tables and their structures. You will work your way through hands-on creation of a number of tables in support of an example application. We will review most types of tables found in the out-of- the-box NAV application.<br><br> In Chapter 3 , you will learn about the basic building blocks of NAV data structure, Zelds and their attributes, data Zelds that are available, and Zeld structure elements (properties, triggers) for each type of Zeld. This chapter covers the broad range of Data Type options as well as Field Classes. You will see one of the date calculation tools that gives C/AL an edge in business.<br><br> We will also discuss the concept of Zltering and how it can be considered as you design your database structure. In Chapter 4 , we will review different types of forms and work with some of these, and review all the controls that can be used in forms. You will learn to use the Form Wizard and have a good introduction to the Form Designer.<br><br> You will expand your example system, creating a number of forms for data maintenance and inquiry. In Chapter 5 , we will learn about on the structural and layout aspects of NAV Report objects. Also, you will be experimenting with some of the tools and continue to expand your example application.<br><br> Chapter 6 will help you learn about the general Object Designer Navigation as well as more speciZc Navision individual (Table, Form, Report) Designers. This chapter also covers variables of various types created and controlled by the developer or by the system, basic C/AL syntax and some essential C/AL functions. Preface [ 7 ] Chapter 7 covers a number of practical tools and topics regarding C/AL coding and development.<br><br> You will learn about the C/AL Symbol Menu and how it assists in development. This chapter also discusses various Computation, Validation and Data Conversion functions, Dates, FlowZelds and SIFT, Processing Flow Control, Input 4Output, and Filtering functions. In Chapter 8 , we will review a number of tools and techniques aimed at making the life of a NAV developer easier and more efZcient.<br><br> There is also a section on Code Analysis and Debugging is provided. Chapter 9 will help you deal with the software design for NAV. This chapter covers designing NAV modiZcations, creating a new function area or enhancing an existing functional area.<br><br> The chapter also provides you the information needed for designing a new NAV application. Chapter 10 focuses on interfaces with NAV. Overall, you will learn about MenuSuites, Dataports, XMLports, and advanced Interfaces in this chapter.<br><br> Chapter 11 will help you become even more productive in C/AL development. It will provide you with some tips for design efZciency; it will help you learn about updating and upgrading the system and more about enjoying working with NAV. What You Need for This Book You will need some basic tools including at least the following: 1.<br><br> A copy of the Application Designer's Guide manual for C/AL 2. A license and database that you can use for development experimentation. An ideal license is a full Developer's license.<br><br> If the license only contains the Form, Report, and Table Designer capabilities, you will still be able to do many of the exercises, but you will not have access to the in inner workings of Forms and Tables. 3. The best database for your development testing and study would probably be a copy of the NAV Cronus demo/test database, but you may want to have a copy of a production database at hand for examination as well.<br><br> This book's illustrations are from the W1 Cronus database for V5.0. If you have access to other NAV manuals, training materials, websites and experienced associates, those will obviously be of beneZt as well. But they are not required for your time with this book to be a worthwhile investment.<br><br> Preface [ 8 ] Who is This Book For? The business applications software designer/developer who: Wants to become productive in NAV C/SIDE 4C/AL development as quickly as possible Understands business applications and the associated software Has signiZcant programming experience Has access to NAV including at least the Designer granules, preferably a full development license and a standard Cronus demo database Is willing to do the exercises to get hands-on experience The Reseller manager or executive who wants a concise, in depth view of NAV's development environment and tool set The technically knowledgeable manager or executive of a Zrm using NAV that is about to embark on a signiZcant NAV enhancement project The technically knowledgeable manager or executive of a Zrm considering purchase of NAV as a highly customizable business applications platform The reader of this book: Does not need to be expert in object-oriented programming Does not need to have previous experience with NAV Conventions In this book, you will Znd a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.<br><br> There are three styles for code. Code words in text are shown as follows: "We can include other contexts through the use of the include directive." A block of code will be set as follows: GLEntry."Posting Date" IN [0D,WORKDATE] Description[I+2] IN ['0'..'9'] "Gen. Posting Type" IN ["Gen.<br><br> Posting Type"::Purchase, "Gen. Posting Type"::Sale] SearchString IN ['','=><'] No[i] IN ['0'..'9'] "FA Posting Date" IN [01010001D..12319998D] " ° ° ° ° ° " " " " ° ° Preface [ 9 ] When we wish to draw your attention to a particular part of a code block, the relevant lines or items will be made bold: GLEntry."Posting Date" IN [0D,WORKDATE] Description[I+2] IN ['0'..'9'] "Gen. Posting Type" IN ["Gen.<br><br> Posting Type"::Purchase, "Gen. Posting Type"::Sale] SearchString IN ['','=><'] No[i] IN ['0'..'9'] "FA Posting Date" IN [01010001D..12319998D] New terms and important words are introduced in a bold-type font. Words that you see on the screen, in menus or dialog boxes for example, appear in our text like this: "clicking the Next button moves you to the next screen".<br><br> Important notes appear in a box like this. Tips and tricks appear like this. Reader Feedback Feedback from our readers is always welcome.<br><br> Let us know what you think about this book, what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of. To send us general feedback, simply drop an email to feedback@packtpub.com , making sure to mention the book title in the subject of your message.<br><br> If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email suggest@packtpub.com . If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide on www.packtpub.com/authors . Customer Support Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.<br><br> Preface [ 10 ] Errata Although we have taken every care to ensure the accuracy of our contents, mistakes do happen. If you Znd a mistake in one of our books 4maybe a mistake in text or code 4we would be grateful if you would report this to us. By doing this you can save other readers from frustration, and help to improve subsequent versions of this book.<br><br> If you Znd any errata, report them by visiting http://www.packtpub. com/support , selecting your book, clicking on the Submit Errata link, and entering the details of your errata. Once your errata are veriZed, your submission will be accepted and the errata added to the list of existing errata.<br><br> The existing errata can be viewed by selecting your title from http://www.packtpub.com/support . Questions You can contact us at questions@packtpub.com if you are having a problem with some aspect of the book, and we will do our best to address it. The Basic Ingredients He who has not &rst laid his foundations may be able with great ability to lay them afterwards, but they will be laid with trouble to the architect and danger to the building 4Niccolo Machiavelli To me programming is more than an important practical art.<br><br> It is also a gigantic undertaking in the foundations of knowledge 4Grace Murray Hopper In Chapter 1, we will deal with the basic foundations of Microsoft Dynamics NAV (pronounced as N-A-V, spelling it out), the objects that make up an NAV application, and their essential capabilities and limitations. While NAV has many structural and syntactical similarities to other programming languages, particularly Object Pascal; NAV has many unique features and facilities as well. Once you are through with Chapter 1, you will feel more comfortable with the NAV development environment, will get acquainted with the tools, and will look forward to getting more detail.<br><br> Also, you will develop knowledge that will allow you to begin thinking about application development within the NAV environment, using the NAV programming language. While learning the NAV development environment, we will develop a simple application as a functional enhancement to the base product. Our application will be designed for the management of a Zctitious association for those who work with C/SIDE and C/AL .<br><br> We'll call it the worldwide Charter/Association of NAV Developers Ltd, or C/ANDL for short. The goal of C/ANDL is to shed a little light into NAV Development. We will deal with member records, skills and education information, hold meetings, and offer some training publications for sale.<br><br> Our application will be designed as a new application function, but with the plan of using base functionality for various accounting functions. The Basic Ingredients [ 12 ] Some Unique NAV Terms Defined The following are some unique deZnitions in NAV: C/AL : Client/Application Language is the programming language meant for customization of NAV. It was built by the NAV development team using C++, though we never see any C++ code directly in the NAV product.<br><br> C/AL is the tool used to deZne the processes by which data is manipulated, to deZne the business rules that will control the various applications, and to control the [ow of all the logical processing sequences. C/AL is also used to manipulate objects, to control the execution [ow of objects, to create new functions complementing the functions that are built in, and to manipulate data in many different ways. C/SIDE : Client/Server Integrated Development Environment is the development tool speciZed for using C/AL.<br><br> It includes the language editor, compiler, debugger, reports and form generators and code management tools. Almost all the C/AL development is done within C/SIDE without the use of external tools. For most application development, NAV is entirely self sufZcient except for those services provided by the Windows operating systems.<br><br> It is possible, though generally not recommended, to write code using a text editor and then import it into C/SIDE. Filtering : The application of range constraints is to control what data is processed or made visible. For example, a Zlter for payment data for Customer No.<br><br> 20134 would show the payments for that customer only. Although not really unique to NAV, Zlters combined with other NAV features are uniquely powerful in NAV. The extreme [exibility of Zltering in NAV allows you to easily create very focused views into the data.<br><br> Filters can be deZned as ranges, boolean expressions, speciZc selections, etc. that delimit the data to be selected into a subset to be utilized in a process (display, calculation, report, etc.). Thus, NAV Zlters are a very powerful tool for both the developer and the user.<br><br> SIFT : Sum Index Field Technology is a very clever method of providing instantaneous response to user inquiries. Most application systems provide fast response to requests for summary information by maintaining pre-calculated totals ("bucketed data"). NAV retains all data in detail and, through the use of SIFT and applied data Zlters, it provides the activity totals or subsets of information subject to a wide range of selection constraints instantly.<br><br> Your data structure design will determine whether SIFT results are available and if available, how fast the response will be. Even though the designers of NAV were very clever in giving you special tools to use, you are still responsible for how well those tools will work for your users. " " " " Chapter 1 [ 13 ] C/FRONT : This is an application programming interface that allows you to develop applications in other programming languages to access a Microsoft NAV database, either the C/SIDE Database Server or the Microsoft SQL Server.<br><br> The primary component of C/FRONT is a library of callable C functions, which provide access to every aspect of data storage and maintenance. This allows creation of custom components written in C, C++, VB, Delphi, and the Visual Studio.NET languages as well as other languages that support compatible calling conventions. C/FRONT is only tested by Microsoft for use with code built using either the Watcom C or Microsoft C++ compilers.<br><br> C/AL triggers cannot be invoked via C/FRONT code. C/FRONT comes as a set of Zles to be installed guided by the instructions given in the C/FRONT manual. C/OCX : This is an application interface to allow integration between C/AL and a properly deZned OCX routine.<br><br> This allows access to many ActiveX controls available from third-party vendors. Such controls must be non-visual as far as NAV is concerned (but they may open their own windows for user interaction). The C/SIDE Integrated Development Environment The C/SIDE Integrated Development Environment is referred to as the Object Designer within NAV.<br><br> It is accessed through the Tools | Object Designer menu option as shown in the following screenshot: " " The Basic Ingredients [ 14 ] Object Designer Tool Icons The following screenshot shows an Object Designer form, containing a list of several tool icons. These Object Designer tool tool Icons are shown isolated in the screenshot and then described brie[y in the following table. Some of the terminologies in these descriptions will be explained later in this book.<br><br> Additional information is available in the C/SIDE C/SIDE Help Zles and the Microsoft NAV documentation. Microsoft NAV documentation.. Chapter 1 [ 15 ] Seven Kinds of NAV Objects NAV C/AL is not considered an object-oriented language even though C/AL uses seven kinds of objects.<br><br> These seven object types are listed on the left side of the Object Designer window as shown in the following screenshot: NAV is not an object-oriented language because you can only use the predeZned object types. The seven types of objects in C/AL are as follows: Table : These are the deZners and containers of data. Form : These are this screen display constructs for the user interface.<br><br> Report : These allow the display of data to the user in "hardcopy" format, either onscreen (preview mode) or via a printer device. Report objects can also update data in processes with or without accompanying data display output to the user. Dataport : These allow the importing and exporting of data from/to external Zles.<br><br> XMLport : These are similar to Dataport but speciZc to only XML Zles and XML formatted data. Codeunit : These are containers for code. MenuSuite : These contain menus and are structured differently from other objects .<br><br> " " " " " " " The Basic Ingredients [ 16 ] More Definitions (Related to NAV) The following are a few more deZnitions related to NAV: Database : This consists of two database deZnitions (physical and logical). There are two implementations of the physical database (C/SIDE Database Server and Microsoft SQL Server). The C/SIDE Database Server was formerly known as the "Native" database because for number of years, this proprietary server was the only database for NAV.<br><br> In earlier versions, it did not have a name other than "the NAV (or Navision) Server". The logical database deZnition relates to the sum total of the relationships between data, the indexes that control data access, and in NAV, the SumIndexFields and FlowFields (special data summing features, which are explained in detail in a later chapter). NAV is a relational database system.<br><br> The Development Environment (C/SIDE) and tools (C/AL), makes the choice of underlying database (C/SIDE Database Server or Microsoft SQL Server) platform almost transparent to the developer. In this book we will not concern ourselves with the physical database deZnition because, except in rare circumstances, our development work will not be guided by physical database factors. When you become involved in more complex design activities, you will likely need to be concerned about the differences between the two database options.<br><br> Properties : These are the attributes of the element (e.g. object, data Zeld, or control) that deZne some aspect of its behavior or use. For example, display length, font type or size, and if the elements are either editable or viewable.<br><br> Fields : These are the individual data items. Records : These are group of Zelds (data items) that are handled as a unit in most Input/Output operations. The table data consists of rows of records and columns consisting of Zelds.<br><br> Controls : These are containers for constants and data. The visible displays in reports and forms consist primarily of controls. Triggers : The generic deZnition is a mechanism that initiates (Zres) an action when an event occurs such as reaching a certain time or date or upon receiving some type of input.<br><br> A trigger generally causes a program routine to be executed. NAV triggers have some similarities to those in SQL, but they are not the same. NAV triggers are locations within the various objects where a developer can place comments or C/AL code.<br><br> The following are the NAV triggers: Documentation Triggers consist of comments only. Every object type except MenuSuite has a single Documentation trigger. Event Triggers are "Zred" when the speciZed event occurs.<br><br> Each object type has its own set of predeZned triggers. The event trigger name begins with the word "On" such as OnInsert , OnOpenForm , and OnNextRecord . " " " " " " æ æ Chapter 1 [ 17 ] Function Triggers are "functions" that can be deZned by the developer.<br><br> They represent callable routines that can be accessed from other C/AL code either within or outside the object where the called function resides. Many function triggers are provided as part of the standard product. As a developer, you may add your own custom function triggers as needed.<br><br> License : A data Zle supplied by Microsoft that allows a speciZc level of access to speciZc object number ranges. NAV licenses are very clever constructs, which allow distribution of a complete system, all objects, modules, and features while constraining exactly what is accessible and how it can be accessed. Of course, each license feature allowing access to various objects and system functions, including the ability to do development, has its price.<br><br> Microsoft Partners have access to licenses to provide support and customization services for their clients. The broadly featured Partner licenses are often referred to as a developer's license, but end-user Zrms can also purchase licenses allowing them developer access to NAV. Object numbers and *eld numbers : The object numbers from 1 (one) to 50,000 and in the 99,000,000 (i.e.<br><br> 99 million) range are reserved for use by NAV as part of the base product. Objects in this number range can be modiZed or deleted, but not created with a developer's license. Field numbers are often assigned in ranges matching the related object numbers (i.e.<br><br> starting with 1 Zelds relating to objects numbered 1 to 50,000, starting with 99,000,000 for Zelds in objects in the 99,000,000 and up number range). Object and Zeld numbers from 50,001 to 99,999 are generally available to the rest of us for assignment as part of an ad hoc customization developed in the Zeld using a normal development license. But object numbers from 90,000 to 99,999 should not be used for permanent objects as those numbers are often used in training materials.<br><br> Microsoft allocates other ranges of object and Zeld numbers to ISV (Independent Software Vendor) developers for their add-on enhancements. Some of these (in the 14,000,000 range in North America, other ranges for other geographic regions) can be accessed, modiZed, or deleted but not created, using a normal development license. Others (such as in the 37,000,000 range) can be executed but not viewed or modiZed with a typical development license.<br><br> The following table summarizes the content as: Object Number Range Usage 1 3 9,999 Base application objects 10,000 3 49,999 Country-speciZc objects 50,000 3 99,999 Customer-speciZc objects 100,000 3 99,999,999 Partner-created objects æ " " The Basic Ingredients [ 18 ] Work Date : This is a date controlled by the operator that is used as the default date for many transaction entries. The System Date is the date recognized by Windows. The work date can be adjusted at any time by the user, is speciZc to the workstation, and can be set to any point in the future or the past.<br><br> This is very convenient for procedures such as closing off Sales Order entry for one calendar day at the end of the Zrst shift, then having the Sales Orders entered by the second shift dated to the next calendar day. You can set the work date by selecting Tools|Work Date , and then entering a date. NAV Functional Terminology For various application functions, NAV uses terminology that is more akin to accounting terms than to traditional data processing terminology.<br><br> Some examples are as follows: Journal : A table of transaction entries, each of which represents an event, an entity, or an action to be processed. There are General Journals for general accounting entries, Item Journals for changes in inventory, etc. Ledger : A detailed history of transaction entries that have been processed.<br><br> For example, General Ledger, a Customer Ledger, a Vendor Ledger, an Item Ledger, etc. Some Ledgers have subordinate detail ledgers, typically providing a greater level of date plus quantity and/or value detail. Posting : The process by which entries in a Journal are validated, and then entered into one or more Ledgers.<br><br> Batch : A group of one or more Journal entries that were Posted in one group. Register : An audit trail showing a history by Entry No. ranges of the Journal Batches that have been Posted.<br><br> Document : A formatted report such as an Invoice, a Purchase Order or a Check, typically one page for each primary transaction. Getting Started with Application Design Our design for the C/ANDL application will start with the beginning of a Member Table, a Member Card, a Member List Form, and a Member List Report. Along the way we will review the basics of each of the NAV object types.<br><br> " " " " " " " Chapter 1 [ 19 ] Tables Table objects are the foundation of every NAV application. Every project should be started by designing the tables. Tables contain the deZnitions of the data structures, the data relationships within and between the tables, as well as many of the data constraints and validations.<br><br> The coded logic in table triggers not only provides the basic control on the insertion, modiZcation, and deletion of records, but also embodies many of the business rules of an application. As we see when we dig into tables further, such logic isn't just at the record level but also at the Zeld level. Putting as much of an application design as possible within the tables makes the application easier to develop, debug, support, modify, and upgrade.<br><br> Example: Table Design Let us try a simple introduction to creation of a table for our NAV Developer Association application. We will create a basic Member table. The Zrst thing we will do is inspect the existing deZnitions for tables containing name and address information, such as the Customer table (table object 18) and the Vendor table (table object 23).<br><br> From the common deZnitions in these tables, we see some patterns as to Zeld names and deZnitions that we decide to copy. The Member table will contain the following data Zelds: Field names De*nitions Member ID 10 character text (code) Title/PreZx 10 character text First Name 20 character text Middle Initial 3 character text Last Name 20 character text SufZx 10 character text Address 30 character text Address 2 30 character text City 30 character text State/Province 10 character text Post code 20 character text (code) Country/Region code 10 character text (code) This is a good illustration of how the design must begin with the tables. As you can see, in the preceding data Zeld list, three of the Zelds have special text formats.<br><br> That is because these are going to be referenced by or will reference to other data tables, so these are data codes rather than descriptive data. The Basic Ingredients [ 20 ] The Member ID will be a unique identiZer for our Member record as it will also be referenced by other subordinate tables. The Post code and Country/Region code will reference other existing tables for validation.<br><br> We choose the name, size, and data deZnition of these last two Zelds based on inspecting the equivalent Zeld deZnitions in the Customer and Vendor tables. We will have to design and deZne any referenced validation tables before we can eventually complete the deZnition of the Member Table. But our goal at the moment is just to get started.<br><br> Example: Table Creation Open the Object Designer , click on Table (on the left column of buttons) and click on New (on the bottom row of buttons). Enter the Zrst Zeld name ( Member ID ) in the Field Name column and then enter the data type in the Data Type column. For those data types where length is appropriate, enter the maximum length in the Length column.<br><br> Enter Description data as desired; these are only for display here as internal documentation. As you can see in the following screenshot (and will have noticed already if you are following along in your system), when you enter a Text data type, the Zeld length will default to 30 characters. This is simply an 'ease-of-use' default, which you should override as appropriate for your design.<br><br> The 30 character Text default and 10 character Code default are used because this matches many standard application data Zelds of those data types. The question often arises as to what Zeld numbering scheme to use. Various systems follow a variety of standard practices.<br><br> In one system you might increment the Zeld by twos, in another by Zves, and in another by thousands but in NAV, when you are creating a new table from scratch, it is a good idea to increment the Field No. by 10 as you have seen in the above screenshot. The default increment for Field No.<br><br> is 1. For a group of Zelds (such as an address block) where you are certain you will never add any intervening Zelds, you could leave the increment at 1. But there is no penalty or cost for using the larger increment, so it's not a bad thing to do all the time.<br><br> Chapter 1 [ 21 ] The numeric sequence of Zelds determines the default sequence in which data Zelds will display in a wide variety of situations. An example would be the order of the Zelds in any list presented to the user for setting up data Zlters. This default sequence can only be changed by renumbering the Zelds.<br><br> The compiler references each Zeld by its Field No . not by its Field Name , so the renumbering of Zelds can be a challenge once you have created other routines that reference back to these Zelds. At that point, it is generally better to simply add new Zelds where you can Zt them without any renumbering.<br><br> In fact, it can be irritatingly painful to renumber Zelds at any point after a table has been deZned and saved. In addition to the Zeld numbers controlling the sequence of presentation of Zelds, the Zeld numbers control bulk data transfer (those transfers that operate at the record level rather than explicitly Zeld to Zeld transfer 4e.g. the TRANSFERFIELD instruction).<br><br> In a record-level transfer, data is transferred from each Zeld in the source record to the Zeld of the same number in the target record. So you can see that it is a good idea to deZne an overall standard for Zeld numbering as you start. Doing so makes it easier to plan your Zeld numbering scheme for each table.<br><br> Before you begin, enter the deZnition into C/SIDE. Your design will be clearer for you and your user if you are methodical about your design planning before you begin writing code (i.e. try to avoid the Ready-Fire-Aim school of system development).<br><br> The increment of Field No. by 10 allows you to insert new Zelds in their logical sequence as the design matures. While it is not required to have the data Zelds appear in any particular order, it is frequently convenient for testing and often clariZes some of the user interactions.<br><br> When you have completed this Zrst table, your deZnition should be like the following screenshot: The Basic Ingredients [ 22 ] At this point, you can exit and save your Member Table. The easiest way to do this is to simply press Esc until you are asked to save your changes. When you respond by clicking Yes , you will be asked for the Object Number and Name you wish to assign.<br><br> In a normal development situation, you will want to plan ahead what Object Number and descriptive Object Name you want to use. We will discuss Object Numbering in more detail later. In this case, we will use table Object No.<br><br> 50000 and name it as Member. We are using 50000 as our Table Number just because it is the Zrst (lowest) number available to us for a custom table through our Table Designer granule license. Note that NAV likes to compile any object as it is saved, so the Compiled option is automatically checkmarked.<br><br> A compiled object is one that can be executed. If the object we were working on was not ready to compile without error, we could unselect the Compiled option in the Save As window as shown in the following screenshot. Be careful, as uncompiled objects will not be considered by C/SIDE when changes are made to other objects.<br><br> Until you have compiled an object, it is a "work in progress", not an operable routine. As a matter of good work habits, make sure that all the objects get compiled before you end work for the day. Forms Forms fulZll two basic purposes.<br><br> Firstly, they provide views of data or processes designed for on-screen display only. Secondly, they provide key points of user data entry into the system. In standard NAV, there are two basic types of forms: Card forms Tabular forms " " Chapter 1 [ 23 ] From a practical point of view, there are also special versions of Card forms that use a Matrix Control and are therefore often referred to as Matrix forms .<br><br> Beyond that, there is a variation of the Matrix form, which is called a Trendscape form . There are also combination forms consisting of a Card form plus a Tabular form, called a Main/ Sub Form . These are user interfaces that appear as forms but are not Form objects.<br><br> These user interfaces use various dialog functions. Card Forms Card forms display one record at a time. These are generally used for the entry or display of Master table records.<br><br> For example, Customer Card for customer data, Item Card for Inventory items, and G/L Account Card for General Ledger accounts. Card forms often have multiple pages (tabs) with each tab on the Customer Card (for example) focusing on a different set of related customer data. Card forms for Master records display all the Zelds into which data must be entered by users.<br><br> Typically, they also display summary data about related activity so that the Card form can be used as the primary inquiry form for its Master records. The following screenshot is a sample of a standard Customer Card: The Basic Ingredients [ 24 ] Tabular Forms Tabular forms display a simple list of any number of records in a single table. The Customer List form in the following screenshot shows a subset of the data for each customer displayed.<br><br> The Master record list show Zelds intended to make it easy to Znd a speciZc entry. Tabular forms for lists often do not allow entry or editing of the data. Tabular forms such as those for Journals are inherently intended for data entry.<br><br> Main/Sub Forms Another form style within NAV consists of a Card form plus a List form. These are called Main/Sub forms and are also referred to more casually as Header/Detail forms. An example is the Sales Order form as shown in the following screenshot.<br><br> In this example, the upper portion of the form (the Main form) is a Card form with several tabs showing Sales Order data Zelds that have one occurrence. The lower portion of the form (the Subform) is a Tabular form showing a list of all the line items on the Sales Order. Line items may include product to be shipped, special charges, comments and other pertinent order details.<br><br> The information to the right of the data entry is related data and computations that have been retrieved and formatted. On top of the form, the information is for the Ordering customer and the bottom contains information for the item on the selected line. Chapter 1 [ 25 ] Matrix Forms Matrix forms display multiple records at one time, and are also used to display the "intersect" of two related tables.<br><br> For example: a spreadsheet-style matrix form showing the "intersect" (stock on hand) for each item at each location. The Items ( No. and Description ) are shown on the Y axis (vertically) in the leftmost column and the Locations on the X axis (horizontally) across the top, and each intersect point contains the count of inventory for an item at a location.<br><br> In the following screenshot, the AMSTERDAM Lamp , item number 1928-S , has 149 lamps in stock in the BLUE warehouse and 55 in the GREEN warehouse. At the same time, we show a negative inventory in the RED warehouse, indicating that we have probably processed shipments for product for which the receipts have not yet been posted. The Basic Ingredients [ 26 ] Trendscape Forms Trendscape forms have similar format to Matrix forms but, with the addition of Trendscape Option Buttons and their underlying logic, the Trendscape forms are used to display time dependent data.<br><br> The X-axis of a Trendscape matrix form is always date based, generally using the system Virtual Date table. The Trendscape option buttons allow the Zltering and calculation of displayed information based on various accounting periods selected by the user. A Trendscape form is generally used for data that needs to be reviewed in summary form by various accounting periods (weeks, months, quarters, etc.).<br><br> The sample Trendscape f

less