Dynamics NAV作为一个有二十多年历史的ERP系统，其内部的业务逻辑流程已经十分标准化。顾问掌握了NAV的标准业务逻辑之后，就能清晰地知道数据在系统中的流转方向，当遇到一些客制化需求时，也能够准确地找到切入点，并快速地对客制化需求进行评估。
在NAV中，数据基本可分为几大类：
Master Data就是我们常说的主数据，比如customer, vendor, item等等，我就不多说了。
Setup Data更好理解，就是系统的设置参数，你使用的模块越多，需要设置的参数表就越多。
下面重点讲一下另外的三个数据类别以及它们之间的关系：
1.Document
你可以把Document理解成日常的业务单据，比如销售订单、采购订单、生产订单等等，document通常都会与用户进行交互的，是NAV系统数据的主要来源之一。在实施过程中，Document表现为客户向我们提交的各种需要用户输入的表单（报表除外）。每一种Document过帐都会由相应的Codeunit来进行，比如Sales Order由Codeunit Sales-Post来过帐，Purchase order由Codeunit Purch.-post来过帐。另外，Document过帐之后，通常会进行归档，将数据写入Archived xxx表中存为历史数据。
2.Journal
Journal通常称为日记帐。在NAV中，journal可以与用户直接进行交互，但同时它是document转化为entry的唯一媒介。比如一张销售订单过帐时，订单的数据通过CodeUnit Sales-Post中的function写入到不同的journal中，库存的变化数据会写入到Item journal，同时根据数据内容和设置的不同以及是否过帐发票，还写入到General journal, resource journal, warehouse journal等。随后，Codeunit Sales-Post会对这些journal进行Post，将最终数据写入到不同的Entry中去。
这是Document到Entry的流程。在NAV中，Journal也可以直接让用户输入数据来进行相关的业务，比如item journal可以进行库存调整、盘点等操作，而财务模块中，用户都是通过不同类型的General Journal来输入凭证的。
简单来说，Journal是用户与系统Entry数据进行交互的最低层界面，任何对Entry数据的操作都要直接或间接地通过Journal来完成。它的另外一个特点是journal在过帐之后是不会有归档的。
3.Entry
Entry是NAV系统中最终的业务数据，比如G/L Entry记录了财务数据，Item ledger entry记录了物料的库存变化数据，value entry记录了物料的价值变化数据。这些数据都是不允许用户直接进行修改的，所有的改动都需要通过Journal来进行，也就是通过Post journal来进行。而对进行Post操作的CodeUnit在系统中基本上是一对一的，一个entry就会有一个Codeunit。比如Item ledger entry是由Codeunit Item jnl. -post line对item journal进行post操作，而写入数据的；G/L entry是由Gen. jnl. -post line对Gen. journal进行post操作，而写入数据的。
所以，只要我们明白了这个基本的流程，数据的流向就很清楚了。如果某个客户要求在销售订单行中增加一个字段，这个字段的值是要带入到item ledger entry的。我们在标准系统中又找不到类似的字段可以替代时，只要写几句代码和增加几个字段就能完成这个需求的开发工作。
6步就完成了，一般只需要2句代码和新增3个字段。是不是觉得很容易？是的，在NAV中进行客制化就是这么容易。
联系客服
