关于NetSuite中的Reports模块

众所周知，报表模块一直都是ERP系统中的一个生产力工具，在每个完整的项目实施过程中，报表都扮演着独一无二的角色。三百六十行，行业间有自己的行业特性，但同一个行业下的不同企业都有其独特性，因此，每个企业的报表及报表体系也是不可完全复制的。从整体的角度来看，报表体系的设计对ERP系统来说是一个锦上添花的环节，因为一个好的报表体系可以进一步帮助ERP挖掘其功能，发挥其价值。

本篇文章咱们就一起先来梳理一下NetSuite中有关Reports模块的内容，至于Saved Search以及Analytics我们在本篇介绍中不做过多阐述，具体内容放在以后共同来探讨。

1. NetSuite报表工具体系介绍——Reports

1.1 Reports概述

报表所扮演的角色和它所发挥作用无比一致，和ERP性质一样，即它是工具，必定要为“我”所用。以我个人的理解，从类型来说，所有的报表大体上可分为两类，一类是执行层报表，也称为作业层报表，另一类是管理决策层报表。不同类型的报表使用对象自然也不相同，前者为作业人员，即针对具体业务操作人员和财务人员使用，后者则为管理或是决策层使用。

我们看到，NetSuite的标准报表体系在中心中占据两个位置，一个是Reports，另一个是Analytics，两位比肩而立。

中心中两个label的位置

Reports是系统提供给用户的标准报表类别的汇总，就是所有Reports的根据地。以管理员的Classical Center为例，这里的报表部分不以使用对象为划分点，我们看到的是被整合的报表分类及体系。刚好它展示给了我们另一个维度的思考，NetSuite提供给用户的报表体系是如何构建的？

点进Reports或Reports Overview，包括Saved Searches在内，可以看到常用的Reports部分包括Financial 财务类、Bank/Budgeting 银行/预算类，Purchases 采购类，Vendors/Payables 供应商/应付类，Inventory/Item 库存/货品类，Order Management 订单管理类，Customer/Receivables 客户/应收类，Sales 销售类，Sales Orders 销售订单类等多类型报表，如果涉及市场营销及销售预测部分，那就需要再加上两类报表（Marketing & Forecast）。由此可以看出整个标准体系结构相当完整，也提供给了用户多样性的选择空间。即使作为一个新手要根据需求自定义任何一个报表时，至少标准的分类可以提供给各位一个大的参考方向，不致于设计报表时跑得太偏，连方向都无法把握。

Reports分类概览

当你不熟悉整个报表框架时，可以点击“Expand All”，就可以看到所有展开的标准报表，截图还真是挺长的！

Reports报表详情

1.2 Reports详细介绍

这么多报表从何说起呢？我们就把常用的几大类报表拿出来稍微详细点跟大家介绍一下，大的分类分为财务及财务之外的。有一点报表上的不同是想跟大家提前说到，常规财务类的是需要编辑Layout的，简单理解就是定义行显示的信息，我们也叫做布局，而有一些报表是无需编辑Layout，只需要关注列的信息。

1.2.1 Financial 财务类

a) Income Statement（Summary/Detail/Comparative）利润表/损益表

常规的Income Statement，客户也会叫做P&L。它主要用来展示一定期间内企业的经营成果，通过这张报表可以知道在选择的期间内企业是否赚钱，在哪里赚了钱。所以，它在Layout上主要是由收入，成本，以及费用几部分构成，当然也包括GP，Net Income在内的几个计算值。标准的报表在列信息上仅留有Account和Amount的值。

Income Statement Summary

而Detail的表更多的是可以帮我们追溯到相关的Transaction记录，包括Type，Date，Document Number，Vendor/Customer Name以及Amount等信息。

Income Statement Detail

至于Comparative Income Statement，它是没有Detail表的。它的设计是在原有的Amount列之后，又加上了一列已经设定好Date Range的Comparative Amount值，用来和前一列的期间值进行比较，另外还有一列计算两个期间Amount的差异值，最后一列是差异百分比的值。为了便于使用，我们可以在自定义报表时就对Comparative Amount的Date Range进行选择，比如可以选择上一年的同一期间，这样就可以直接实现客户同比的需求。 

Comparative Income Statement

Date Range设置 

利润表在系统中的数据来源主要是Budget，Financial，以及Budget and Financial三部分，所以和我们后面提到的预算类报表也会有一定的联系。

b)  Balance Sheet（Summary/Detail/Comparative）资产负债表

Balance Sheet是非常标准的财务报表，它主要是让管理层了解自己家企业的财务状况，也能够知道投入公司的本金是否得到了保障，在整体Layout上是由资产、负债和所有者权益三个部分组成，在列信息上同样只留有Amount的值。对应Detail的表也是会显示相关的Transaction记录，包括Type，Date，Document Number，Vendor/Customer Name，Amount以及非常重要的Balance的值。

Balance Sheet Summary

Balance Sheet Detail

 而关于Comparative Balance Sheet，它在外貌上和前一个Comparative Income Statement长得很像，也是由四列值构成，分别是Amount，Comparative Amount，Variance，%Variance。同样你是可以通过Date Range的设定来实现资产负债表的同比需求的。

Comparative Balance Sheet 

它的取数来源主要是Budget，Financial，以及Budget and Financial三部分，和利润表是一致的。

c) Cash Flow Statement 现金流量表

现金流量表是反映企业在一定会计期间内现金和现金等价物流入和流出情况的报表，也是财务关键性报告之一。作为标准的财务报表，整体上是由经营活动现金流量，投资活动现金流量和融资活动现金流量三个部分组成的，在列上面同样也是只保留了Amount的值。它的数据源和利润表及资产负债表保持一致，来源于Budget，Financial，以及Budget and Financial三部分。但是和前两者不同的是，这张报表只有Summary Report而没有Detail Report。

 Cash Flow Statement

d) General Ledger 总账

标准的总账报告非常详细，能够很好地显示出底层数据的来源，它既没有自己的布局，也没有Detail Report。在列的信息上主要是由Account, Transaction Type，Date，Document Number，Vendor/Customer Name，以及最重要的Debit，Credit，Balance（勾选Add Running Balance Column）组成的, 一目了然。

这张报表的取数来源是Transactions以及Active Account by Type,并且它的借贷值来源于Transaction：Amount（Gross）而不是Amount，这一点还是比较特殊的。如果想要找到对应的Transaction记录，那就点到具体的行上就可以跳转到详细页面了。

General Ledger 

e) Trial Balance 试算平衡

试算平衡这个报表也是财务报表中会常用到的报表，同样它也是没有Layout和Detail表的。当你点进报表的时候，一般情况下它的科目是全部展开的状态，有点像总账报表一级一级全部展开的样子，当然展开还是合上在自定义报表的时候可以根据自己的需求进行设置。试算平衡表的界面比起总账报表就显得非常简洁了，只有Account，Debit以及Credit这三列数值组成。

它的取数来源是Account by Type和Trial Balance，这一点和总账报表略微有点不同，总账报告中的Account来源于Active Account by Type。尤其特别的一点是，借贷的取值直接取的是Trial Balance: Amount (Debit/Credit)即可，而在其他有些报表中，我们是需要将借贷分开取数的。

Trial Balance 

f) Transaction Detail 交易细节

交易细节这个报告类似于会计账里面的序时账，当你直接点进去的时候，它呈现的所有信息是直接铺开的，分别是Transaction Type，Date，Document Number，Vendor /Customer Name，Memo（Description），Account，Clr (Cleared)，Split，Quantity，Amount（Gross），这里的Amount是和总账报表里的保持一致的。这张报表的取数逻辑非常简单，全部都来源于Transactions，就是我们每一张原始事务处理单据上展示的信息。

不过，交易细节这张报表有一个限制点在于它不能在报表的展现形式上做选择，我们以Income Statement为例，它是可以在Column的地方选择按照Subsidiary，或是Accounting Period等形式展现的。这样就能在一张报表中看到每一个Subsidiary对应的数据，但是这张报表是只能在Subsidiary Context上面选择不同的公司，不能全部展现。当然如果必须要展示Subsidiary的名称，就需要在自定义的时候取到Subsidiary的值然后使Subsidiary之后的一列信息勾选Group With Precious Column，间接地实现这个需求。

 Transaction Detail

g) Realized/Unrealized Exchange Rate Gains and Losses 已实现/未实现的汇兑损益

虽然这是两张报表，但是我还是想放在一起来说，其实它们并不是每家企业都必须会用到的报表，当你想直接看已实现/未实现的汇兑损益，这两张报表用起来会比较方便。当你的企业不涉及到本位币和外币交易，不涉及汇率变动时，这个表就无需点开。但是当你的企业存在多种外币交易时，以及受月初及月末汇率变动所影响，当你在某一时刻进行Currency Revaluation（重估外币）这一动作后，就会产生汇兑损益，而这些汇兑损益包含已实现的汇兑损益和未实现的汇兑损益。

已实现的汇兑损益的底层单据就是Currency Revaluation，除了Subsidiary以外，其他的数据取的都是行上的信息，包括Account，Name，Source Trans Number，Source Accounting Period，Source Trans Date，Source Trans Type，Source Account，Source Exchange Rate，而Payment取的是Applied Line的值，包括Pmt Trans Number，Pmt Accounting Period，Pmt Trans Date，Pmt Trans Type，Pmt Exchange Rate，Transaction Currency，Applied Amount，Applied Amount (Base) ，Realized Gain/Loss Trans Number，Realized Gain/Loss Posting Period，Realized Gain/Loss Posting Date，Realized Gain/Loss，这么多的数据，它们都从Realized Gain/Loss来。关于Unrealized Gain/Loss的列信息在这里就不再一一列举了，它的取数源是Unrealized Gain/Loss。其实相应货币重估的Transaction是在交易细节表中可以直接看到主要信息，也是比较方便的，可以点进Transaction详情看到汇兑损益产生的来源。

Realized Exchange Rate Gains and Losses

 Unrealized Exchange Rate Gains and Losses

h) Intercompany Reconciliation 公司间账目核对

如果启用了公司间交易的功能，这个表可以帮助我们进行公司间的采购与销售账目核对，取数来源是Intercompany Reconciliation，列的构成主要是Mismatch Type，Purchasing Subsidiary，Subsidiary（Sales Subsidiary），以及单独的Purchase和Sales两部分的内容，Purchase的部分主要有Vendor，Purchasing Trans，Purchasing Trans Type，Purchasing Trans Date，Purchasing Trans Currency，Purchasing Amount (Trans Currency)，Purchasing Billed Amount (Trans Currency)，Inventory Item: Display Name，Quantity Received，Quantity Billed；Sales部分主要有Customer，Sales Trans，Sales Trans Type，Sales Trans Date，Sales Trans Currency，Sales Amount (Trans Currency)，Sales Billed Amount (Trans Currency)，Quantity Shipped，Quantity Invoiced。

这个报表的用途是能够让用户很清楚地看到公司间账目不匹配的原因是什么，比如在Unlinked Orders and Returns下如果只有PO而没有SO的任何信息，那就表示关联的SO还并未生成；如果是Mismatched Quantity，就可以看到是哪些单据上对应的数量不匹配，差异在是多少，到底是否有问题，这样便于核对后有针对性地解决公司间的单据/数据问题。

Intercompany Reconciliation 

1.2.2 Bank/Budgeting 银行/预算类

a) Bank Register 银行登记册

银行登记册这个报表在我所经历的项目中是没有用到过的,它的数据来源于Bank Register和Account，每一列的信息分别是Account（Report Section），Date，Document Number，Payee，Account（Split），Deposit/ Payment（Amount (Gross)），Balance（勾选Balance），关于银行科目的信息还是比较完整的，能够让我们知道付款/存款的时间，金额，付款/收款人和对门科目的信息。

乍一看这张表信息很完整，但是让我非常迷惑的是它的标准过滤器只显示Date，并且它只能显示一个科目。即使我想通过过滤器对科目进行限制或者筛选，也是没有办法实现的，所以一般我就“不会”使用标准的Bank Register。这个“不会”一方面是我不知道怎样去利用好这个报表，另一方面是我会选择其他报表替代它。因此，如果需要呈现一张所有银行类科目的报表，我们就可以选择用总账报表进行加工，只留下银行类的科目，然后再取到其他数值。

 Bank Register

b) Budget Income Statement 预算利润表

预算利润表在这里有点类似于预算和利润表的结合，它的Layout使用的是利润表的布局，有Summary Report和Detail Report，Summary Report对应列上的信息只取了一个标准的预算Amount，表示我们企业在收入，成本，费用类型的科目下分别做了多少的预算，当然也可以选择不同的预算版本进行查看。如果点进Detail Report，获得的信息则会更加详细一些，除了Amount之外，能够看到Subsidiary，Class，Department，Location的信息。

整张表的取数来源与Income Statement完全一致，这个时候如果想要实现预算和实际的对比值，那就再加上一列取自Financial的Amount，就变成了下一个我们要看的预算对比实际的表。这张表也是可以按照Subsidiary，Accounting Period等维度呈现的，符合多家子公司平铺展开看预算值的需求。

Budget Income Statement Summary 

 Budget Income Statement Detail

c) Budget VS Actual 预算对比实际

这张表的用处在我个人曾经参与过的一个项目中发挥的作用很大，因为它呈现的是两列可对比的值，也可以显示差异及差异百分比，四列呈现的数字主要是Actual Amount，Budget Amount，Amount over Budget（公式列Amount-Budget），%of Budget（公式列（Amount-Budget）/Budget）。

它的Layout和Income Statement是同一个布局，并且取数源也是一致的。在之前的一个项目中，客户所有的Income Statement都是需要将预算值和实际值进行对比的，所以我们在编制报表的时候底表都使用的是这个表。不管是YTD还是MTD或者是Rolling Income Statement，都能通过这个表再进行自定义，并且可以以不同的Subsidiary来呈现（Column选择Subsidiary），就帮助我们解决了所有关于Income Statement的问题。

Budget VS.Actual 

1.2.3 Purchases 采购类

a) Purchase by Vendor/Item 按供应商/货品排列的采购

采购类的报表自然归属到业务型的报表，by Vendor和by Item分别代表着两个不同的维度。Purchase by Vendor提供的是以供应商为维度对采购端进行的信息统计，在列的信息上只有Vendor以及Total （Amount（Gross））两列数值，它的取数源是Vendor及Purchases，即与某个供应商相关联的所有信息，以及所有采购动作的相关信息。

Purchase by Item的报表则呈现的是以货品为维度进行的统计信息，对应的有Item Type，Item Name，Qty. Bought（Purchases：Quantity），Total Purchased（Amount Gross），其实主要是货品的所属类型，货品名称，以及采购发生的数量及金额。它的取数源牵扯到Item Type，Purchases以及Quantity Purchased，包括货品类型，采购，采购数量。

站在两张报表的整体角度，by Vendor的列信息是可以按照Subsidiary/Week/Month/Quarter/Year展现的，但是by Item是不可以的，只有Subsidiary，Location等常见的展现列。但是两张报表同时是有Summary也有Detail的，Detail Report的目的是能够帮助我们直接看到Transaction的信息，以及更好地跳转到详细界面。

Purchase by Vendor Summary 

 Purchase by Vendor Detail

Purchase by Item Summary 

 Purchase by Item Detail 

b) Purchase Order Register 采购订单登记册

Register翻译过来代表“登记册”的意思，所有的采购订单都可以登记在册，也是全部展开的状态，而它的Subsidiary Context的过滤是包涵Consolidated的选项的，也就是我们可以看到的合并报表。

报表的列信息主要有Account，Date，Document Number，Vendor，Status，Amount，全部的取数全部来自Purchase Order Transactions，也就是与PO相关的所有交易，所以在Status这一列也会有全部的不同的订单状态。但是有一点需要注意的是这张报表是没有Column的展现形式的。

Purchase Order Register 

c) Open Purchase Orders 未完成采购订单 

对于“未完成”状态系统是有它的标准定义的，它的列信息和PO Register基本一致，但是有几列不太一样，其中Current Status表示当前Open PO的状态，Current Amount（Open Amount）表示的是未支付给供应商的金额，Total Transaction（Aggregate Amount）表示的是事务处理总金额。报表数据的取数来源是Open Purchase Orders，其实系统在这里已经帮我们在数据源头上做了一个过滤的处理，帮助我们选择了Is Open的PO，也就是Status字段中带有Pending/Partially字眼的，比如Pending Bill，Pending Receipt这些就表明了是正在等待下一步操作或者完成了部分操作的单据，相比较就是我们看不到Closed/Canceled/Fully Billed类似这样已经完成或者取消了的字样。

所以当我们想看所有未结采购订单的时候，可以以这个报表作为参考，当然这个报表是有Consolidated的选择但是没有Column的展现形式的。

Open Purchase Orders

d) Purchase Order History 采购订单历史记录

这张报表从字面意思上翻译是指所有采购订单的历史记录，它的取数来源是Purchase Order Transactions以及Transaction Dimension，前者恰巧也是采购订单登记册的取数来源，说明这一部分信息在源头上是重合的。而在列的信息上，它的信息会比Register更多一些。前三列的Entity，Item，Transaction Type都取自于Transaction Dimension，而Document Number，Status，Purchase Order Quantity，Receipt Quantity，Bill Quantity，Rate，Exchange Rate，Currency，Purchase Order Amount，Receipt Amount，Bill Amount都取自PO相关的交易事项，Receipt Minus Bill Amount则是公式列。

与PO Register相比，这张报表更关注的是Receipt与Bill之间数量和金额的关系，并且它的Subsidiary Context的过滤字段中没有公司的Consolidated的选项，说明我们不能看到合并的报表，并且在列的展现上也是没有选择的，所以我们在选择报表进行自定义的时候就要看自己具体的需求。

Purchase Order History ​​​​​​

1.2.4 Vendors/Payables 供应商/应付类

a) A/P Aging 应付账款账龄

账龄表是每家公司必备的报表之一，而且账龄表上的信息对于调整企业的预算是有实际意义的。NetSuite中标准的账龄表有Summary Report及Detail Report，Vendor和Open Payables是它的取数来源。

报表中第一列信息自然是Vendor的名称，即我们要支付的对象。后面几列数据是我们看到的不同账期内的Open Balance，也就是不同自定义的账期内我们应付出去的钱，系统报表上默认的账期是30/60/90，另外还有当前期间内的Current Open Balance和Total Open Balance。

在Aging Options中可以由客户确认是按照Transaction Date还是Due Date来计算Balance，当然也可以选择自定义的账期调整报表上的数据。如果是Detail Report，则是偏向于具体的Transaction信息，我们能够详细看到Open Balance的具体构成情况，所以也就不再有Aging Options的选择了。

A/P Aging Summary 

A/P Aging Detail 

b) A/P Register 应付款项登记册

Register没有Summary和Detail之分，Vendor Register Transactions 以及Account是它的取数来源。与应付账龄表相比，两者的侧重点有所不同：账龄表本身更在意的是不同账期内的金额总数，而登记册告诉我们的是应付账款的信息，更多的是与AP科目相关的Transaction交易数据与金额，即Bill/Bill Payment对应的信息。

在具体的列的信息上，主要有Account，Transaction Type，Date，Document Number，Vendor，Memo（Message），Date Due（Due Date），Billed/Paid（Amount Gross），Balance这些部分组成，而这里的Type主要是Bill，Bill Payment，因为针对供应商的付款在NetSuite中是分两步走的，先有Bill账单，之后再针对Bill进行付款，所以这里的Transaction Type主要涉及到这两种类型。

A/P Register 

c) A/P Payment History by Bill/Payment 按账单/付款排列的应付账款付款历史

这两张报表是分别从Bill和Bill Payment的角度来看具体的付款历史，它们都可以帮助我们看出Bill和Payment的对应关系，比如一笔Payment我们对应几笔Bill，在这样的报表上就更为清晰，但其实两张表在列信息的构成上基本相同。

从Bill的维度来看，报表的取数来源为Payments by Bill以及Transaction Dimension，列的信息呈现为Transaction（Transaction Number - Entity），Payment Type（Transaction Type），Date，Document Number，以及Amount（Amount Paid），Amount Due的值是否为0可以帮助我们判断Bill与对应的Payment金额是否抵消。

而从Payment的维度来看，报表的取数来源为Bills by Payments以及Transaction Dimension，列的信息呈现为Transaction（Transaction Number - Entity），Bill Type（Transaction Type），Date，Document Number，以及Amount（Amount Paid），同样也有Amount Unapplied的值是否为0帮助我们判断Bill与对应的Payment金额是否抵消。

这两张报表在展现形式上也是没办法呈现多个Subsidiary的，如果需要看到公司的信息那就需要把Subsidiary的信息单独拉出来，然后再根据子公司进行分组设置。

A/P Payment History by Bill 

 A/P Payment History by Payment

d) Open Bills 未付账单

未付账单，就是指我们有了Bill但是还没有相对应的Payment，还没有付出去款项的信息。在取数源上主要是Open Bills和Account，列的信息上主要有Account（A/P），Bill Number，Vendor，Bill Date，Memo，Date Due（Due Date），Amount Due，Payment Hold（Yes/No）。当我们的Bill产生了对应的Payment，相应的信息自然而然就会出现在Payment by Bill/Payment的报表上了。因此，报表互相之间都是有各自的逻辑关系和对应联系的，刚开始的时候我个人也不是特别熟悉的，慢慢地看得多了、试得多了才好了一些。

 Open Bills

​​​​​​​1.2.5 Inventory/Item 库存/货品类

a) Current Inventory Snapshot 当前库存快照

这张报表能够帮助我们快速地查看每一个仓库中的库存状况，仓库中对应货品的状态及其数量。但是这张表数据量会比较大，所以每次打开的时候可能需要多花费一点点时间，它在展开的时候是直接按照每个仓库展开的，所以仓库越多数据量越大，当然我们也可以在过滤器部分选择对应的Subsidiary和Location，只看到需要查看的公司及仓库数据。

它的取数源由两部分构成，一个是Quantity to Order，跟Transaction相关，另一个是Inventory Item，和货品本身相关。而在列的信息上，主要由Item Type，Item，Description，Pref. Vendor，Reorder Pt.，Preferred Stock Level，On Hand，On Order，Committed，To Order，In Transit的数据组成，最后一部分则是所有仓库的合计值。结合我参与过的项目来说，一般参考比较多的值是On Hand，On Order，Committed，In Transit的数量。

Current Inventory Snapshot 

b) Physical Inventory Worksheet 实际库存工作表

在过去的项目中，我个人并没有怎么用到这个报表，但是我们可以直接用它来看On Hand的值。它的取数源主要来自于在手的数量及货品，即Quantity On Hand以及Inventory Item。所以在列的构成上，有Item，Description，Pref. Vendor，On Hand，Physical Count。

Physical Inventory Worksheet 

c) Inventory Back Order Report 库存缺货定单报告

这张报表我使用到的次数也不多，因为我经历的项目在实际操作上并没有特意去关注每一个订单上缺货的数量，一般当数量上出现了问题才会去查看相关的原因。不过这张报表包含Item Type，Item，Transaction Type，Document Number，Customer的信息，另外在数量上它不仅会提供Back Ordered的数量，同样也会有Ordered，Fulfilled的数量。它能够告诉我们在等待发运的状态下的订单上的具体数量是多少，实际已经发了多少，缺货了多少，几部分的构成比较清晰。这三个数据来源于Order Items Pending Fulfillment以及ItemType，主要是事务处理中发运的信息，可能涉及到销售订单SO，工单WO，库存调拨单TO单等Transaction Type。

Inventory Back Order Report 

d)  Inventory Activity Detail 库存活动细节

这张报表可以说是我个人用得最多的报表，因为它能够告诉我一个货品对应的出入库IF/IR单的信息，当然也包括有装配件AB单，库存调整IA单的信息，有点类似Transaction Detail报表中单独拿出来跟库存相关的一部分。所以想要看到所有的出入库信息时，一般我都会直接把原生的或者稍稍按照需求去自定义这个报表，然后给到客户进行参考。

库存活动细节表的数据源主要是Quantity On Hand以及Inventory Item，也是对在手库存数量的一个分析，所以最重要的Quantity取值来源于在手数量。在对应列的信息上主要有Item Type，Item，Transaction Type，Date，Document Number，Description，以及Qty。

Inventory Activity Detail 

e) Stock Ledger 存货簿报告

关于这张报表我和它还是有点点故事的，曾经的我从来没有点开过这张表，直到在一个项目上客户方的财务总监及负责Inventory部分的同事提到说需要有一张展示“进销存”情况的报表，我才第一次认识了这张存货簿报告的结构和它包含的信息。

这张报表上包含的信息非常多，取数源为Stock Ledger和Item，对应的信息分别有Item，Location，Description，Class，Department，Subsidiary，Beginning Inv Qty On-hand，Beginning Average Cost，Beginning Inv On-hand Value，Receipts，Other Inv Inputs，Total Input Quantity，Value of Inputs，Last Receipt Date，Sales，Other Inventory Outputs，Total Output Quantity，Value of Outputs，Last Sales Date，Ending Inv Qty On-hand，Ending Average Cost，Ending Inv On-hand Value。简单来说，这张表能够告诉我们的信息就是原始货品的价值，过程中我又输入收到了多少，又输出销售了多少，最后手中的货品价值是多少。这张报表能够把货品在对应仓库的平均成本及价值变动体现得比较清楚，但是在时间上默认的是只抓到最后一次的收进仓库日期和销售出库的日期，不一定会满足客户的需求，这一点是需要注意的。

Stock Ledger 

f) Items Pending Fulfillment 货品待完成

我们知道，站在SO的角度，Pending Fulfillment是在SO创建完成之后的一个标准状态，我们在看所有SO的状态时就能够看到哪些是在等待发运的订单。当然这张报表站在了Item的维度，因此能够注意到Transaction Type里不仅包含了SO，同时也会包含有TO库存调拨，因为库存调拨创建完成后的第一步是需要先完成Fulfillment的。

这张表的取数来源是Order Items Pending Fulfillment和Item Type，在列的信息上有Item Type，Item，Transaction Type，Document Number，Customer，Ordered，Fulfilled，Committed这些信息，和Back Ordered的报表的样子长得有点像。

不过在项目中有时候我们并不会单独选择这个Item报表进行查看，一般都更习惯于直接利用SO Saved Search来做，不过如果要加入TO部分，那就可以参考货品待完成这个报表。

Items Pending Fulfillment 

g)  Transfer Order Register 库存转移订单登记簿

登记簿（登记册）这个名字出现过很多次，它就像一个展开的记事本，用户每相应操作一次，系统就会自动帮我们在这个本子上记下一笔，以防后面丢失了痕迹。库存转移登记册标准的信息不多，只有Date，Document Number，Status，Amount，数据来源也是Transfer Order Transactions。不过，一般我不会使用这个报表来看TO的信息，因为在Transaction-Transfer Order List下面我们也是能够直接看到这个信息的，甚至会更全面一些。

Transfer Order Register 

​​​​​​​1.2.6 Order Management 订单管理类

a) Sales Orders Register 销售订单登记册

有采购订单登记册必然也有对应的销售订单登记册，这张报表同样也没有展现形式的选择，在列的信息呈现上主要有Account，Date，Document Number，Customer，Status（ Validated Status），Total Revenue（Aggregate Amount）这几个信息。

这个报表的取数全部来自Sales Order Transactions，也就是和SO相关的事务处理信息，所以在Status这一列我们能够看到销售订单的不同状态。

Sales Order Register 

b)  Open Sales Orders 未付销售订单

对于Open系统有标准定义，它的列信息和SO Register基本一致，只是Open SO Status 和Open Amount会和Register有所不同，因为系统在取数来源上已经帮我们做了一个过滤，其条件是Order Status equal to Open。这张报表的取数来源是Open Sales Orders，因此Status中会带有Pending/Partially的字眼，类似于Pending Fulfillment，Partially Fulfilled，Pending Billing这些都表明正在等待下一步操作或者完成了部分操作的状态，已经过滤掉了Closed/Canceled/Billed的订单，所以当我们想看所有未结销售订单的时候，可以以这个Open的报表作为参考。

另外，这个报表是有Consolidated的选项的，因此我们可以看到合并的报表，但它是没有Column的展现形式的。

Open Sales Orders 

c) Sales Orders Pending Fulfillment 待完成销售订单

待完成的销售订单指的是等待我们完成的销售订单，这好像跟没有解释一样。我们知道，系统中SO创建完成后的第一步是需要进行Fulfillment的动作，所以这个报表会站在SO的维度，展现出SO上的哪些Customer的Item还没有进行发运，当然也会有Date，Ordered，Fulfilled（Quantity Shipped），Committed的值。当然它的取数来源是Order Items Pending Fulfillment和Item Type，所以通过后面的三个数量可以看到我订单上需要发给客户的数量，等待发运中已经发运的数量以及等待发运中的那些被占用的数量，能够帮助我们做到心中有数。

Sales Orders Pending Fulfillment

d) Sales Back Order Report 销售缺货定单报告

这张报表同样也是从SO的维度出发，帮助我们看到已经确定的SO货品中缺货的数量，其实它的取数来源和上一张我们说到的待完成销售订单的取数来源完全一致，在列的信息上包含Document Number，Date，Item，Customer，Ordered Quantity，Fulfilled，Back Ordered，以及On hand, On Order的数量。这张报表能够很直白地告诉我们，我们的SO上的Item需要发多少，实际上已经发走了多少，目前还缺多少，另外在手数量剩余量是否还有。

所以如果只是看缺货订单的话，这张报表还是非常方便的。当然这张报表同样也是不能按照子公司进行展现，但是可以根据Location对SO进行筛选。

Sales Back Order Report 

e) Shipping Report 付运报告

这张报表我在曾经参与过的项目上是没有用到过的，它能够告诉我们的是关于货品付运的相关情况。它的取数源来自于Item及Item Fulfillment，在列的信息上包含Addressee，Street Address，City，State，Zip Code，Shipping Weight，Shipping Method（Shipping Item），Order Type，Order #，Email，Phone Number的字段信息。但是在项目中，更多发运的信息我们会倾向于用Saved Search来选择所需要的字段，并没有专门用到Shipping Report的报告。

Shipping Report 

f) Return Authorizations Register 退货审批登记簿

退货相关的报表我猜想是企业最不想看到的报表，但也是必须要面对的报表。它的取数来源是Return Authorizations Transactions，是与退货审批相关的事务处理，所以用Saved Search也是可以抓取到这些信息的。

在列的信息上有Account，Date，Document Number，Customers ，Status（Validated Status），Total Amount（Aggregate Amount）。我们知道系统中退货退款的操作并不是一步就可以完成的，而是对应在销售订单上会有Return的按钮，当我们完成退货的操作后，需要在收到客户退回的货品时将其重新入库，最后完成退款Refund。所以这张报表简单来看就是汇总了所有退货单据的基本信息及所有状态，包括取消的以及关闭的也都会有对应的显示。

Return Authorizations Register 

g) Open Return Authorizations 未结退货审批

其实这张报表就像未结采购/销售订单一样，是系统提供给我们关于状态的一张报表。它的数据源和列信息构成和Register的报表完全一致，只是最后一列取的值是Open Amount。在Status字段上，系统依旧是帮我们自动过滤了Status的条件，在筛选条件的地方设置了Order Status equal to Open。所以，我们能够看到的Status是Pending Receipt，Partially Received， Pending Refund等部分完成的退货操作。一旦完成最终的退款Refund，那信息便会从这张报表上消失，表示完成退货到退款的全部操作。

Open  Return Authorizations

h) Return Authorizations Pending Receipt 待收退货审批

这张报表则是直接站在了退货审批单据的角度上，所以会牵扯到单据中的具体Item，这一点是和先前提到的两张退货审批报表的不同之处。之前的两张退货审批报表的数据源只涉及到Return Authorizations Transactions，而这张报表会另外再加上Item Type的部分，因此在每一列的信息上也会更加精确到具体的货品信息。

它的列信息有Document Number，Date，Customer，Item，Quantity，Received（Quantity Shipped），所以当我们打开这张表格更能直接看到的是货品的具体信息。但是有一点让我个人也非常迷惑的是这张报表并未在过滤数据的部分对状态字段进行限制，所以当我们把事务处理的状态放出来后，你会发现，状态字段的显示依旧有Pending Refund/Pending Receipt/Partially Received等字样，所以我不确定这是不是我操作的问题或是设计时出现的问题，也等待大家一同探讨。

Return Authorizations Pending Receipt 

​​​​​​​1.2.7 Customer/Receivables 客户/应收类

a) A/R Aging 应收账款账龄

A/R Aging和A/P Aging相似，只不过针对对象不同。A/R Aging能够看到的是公司在不同账期内尚未收回的账款，它的取数来源是Unpaid Receivables和Customers/Project。

所以，报表的第一列信息是Customer的信息，紧接着就是Current和Total的Open Balance以及默认的30/60/90的不同账期内的Open Balance。同样这张表是有Summary和Detail的，Detail则是更加侧重Transaction的相关信息，相关的Transaction Type会涉及Invoice，Payment等不同的类型。

A/R Aging Summary 

 

A/R Aging Detail 

b)  A/R Register 应收款项登记册

A/R Register所看到的是关于应收账款的所有事务处理信息，所以它的取数来源自然是Account和Transactions，在列的信息上分别是Account，Type，Date，Document Number，Customer，Memo，Date Due，Amount Charged/Amount Paid（Amount Gross），Balance。而这里的Type会涉及到Payment，Invoice，Customer Refund，Journal等不同类型。

A/R Register 

c) A/R Payment History by Invoice/Payment按发票/支付排列的应付账款付款历史

就像A/P Payment有两个不同的维度，同样A/R Payment也有两个维度，这两张报表是帮助我们判断Invoice和Payment对应关系的依据。前者从Invoice出发，因此它的取数来源是Payments by Invoice和Transaction Dimension；后者从Payment出发，它的取数来源则是Invoice by Payment以及Transaction Dimension，这些数据来源冥冥之中都是被打通的，都有着或多或少的联系。

从Invoice的角度来看，它的数据主要是Transaction（Transaction Number - Entity），Payment Type，Date，Payment Method（Name），Check Number ，Amount（Amount Paid）。我们还能够看到Amount Open是否为0，来判断客户的应收是否已经完全结清。

从Payment的角度来看，它的数据主要是Transaction（Transaction Number - Entity），Invoice Type，Date，Payment Method（Name），Check Number ，Amount（Amount Paid），和Invoice维度的信息基本保持一致。同样，我们还能够看到Amount Unapplied是否为0，来判断客户的应收款项是否已经完全结清。

A/R Payment History by Invoice 

 A/R Payment History by Payment

​​​​​​​1.2.8 Sales 销售类

a) Sales by Customers/Item 按客户/货品排列的销售

不管是从Customers还是Item出发，这两张Report都是有Summary和Detail的报表的。

Sales by Customer Summary这张报表是很简洁的，取值来源于Customer/Project和Sales，报表上也只有Customer和Sales两列值。这里的Sales对应的是Transaction Total（Revenue）。它能够按照Subsidiary/Week/Month/Quarter/Year进行展现的；当然如果需要看Detail的报表，它会呈现更偏向于Transaction的信息，比如Customer，Transaction Type，Date，Document Number，Memo（Description）以及Total Revenue（Amount），整张报表取值来源于Customer/Project和Sales Transactions。但是和Summary相比，Detail的表是不可以按照子公司及时间的列进行展示的。

Sales by Customer Summary 

Sales by Customer Detail  

Sales by Item Summary的报表会稍稍复杂一些，因为牵扯到Item便不再只是涉及到金额，往往数量也是很重要的一个参考数值。Summary的表取自Item Type和Sales，对应的信息有Item Type，Item Name，Item Description（Sales），Qty. Sold以及Transaction Total（Revenue）。而它的Detail表同样也是落在具体的Transaction上，能看到Invoice，Credit Memo等不同类型的事务处理信息。

Sales by Item Summary  

Sales by Item Detail   

b) Open Invoices 未结发票

Open这个单词咱们已经见了太多遍，表示这个事务处理还没有完成最终的操作，在列的信息上展示了Account，Customer，Invoice Date，Invoice Number，Memo，Date Due（Due Date），Amount Due的相关信息，取数源是Account和Open Invoices，因此在取数的时候就已经做出了限制，来源于所有未结的发票。这张报表告诉的是我们给客户开了发票后客户需要在哪个日期前完成最后的付款，但实际上即使过了Due Date，如果客户依旧还没有付款，Invoice的状态依旧也是Open，相关的信息也会出现在这张报表上。

Open Invoices ​​​​​​​

1.2.9 Sales Orders 销售订单类

a) Sales Orders by Customers/Item按客户/货品排列的销售订单

这两张报表点进去的时候都是有Summary和Detail的，并且这两张表的基本构造和Sales by Customers/Item非常相像。

Sales Orders by Customers Summary的表还是依旧保持简洁，只呈现Customers和Amount（Net）的值，且一个Customer只有一行数据，对应一个Amount，其数据来源是Customer/Project和Bookings，依旧在列的展现形式上可以按照Subsidiary/Class/Week/Month/Quarter/Year等多个形式展开。Detail的表点入之后会按照Customers的维度对所有SO进行合并，对应的信息有Customers，Transaction Type，Date，Document Number，Primary Sales Rep，Amount (Net)，它的数据源和Summary是同一个数据源，所以在自定义的时候根据自己的需求进行修改即可。当然Detail的表需要注意的是它没有办法对展现形式进行选择。

Sales Orders by Customer Summary 

 Sales Orders by Customer Detail

Sales Orders by Item Summary的表比Customers维度的信息会更多一些，列的信息上有Item Type，Item，Description，Qty. Sold，Amount，但是没有SO的相关信息，它的取数来源是Item Type和Bookings，所以涉及到相关的数量和金额的信息。其实它本质上和Customers维度的是同一个数据来源，只不过两张表站立的角度不一样。Detail的表更强调SO和Item的关系，包括Transaction的信息，所以所呈现的信息中包含Item Type，Item，Date，Document Number，Serial Numbers，Qty. Sold，Amount，最后两列的值和Summary的值是同一个值,数据源也是一致的。

 Sales Orders by Item Summary 

 Sales Orders by Item Detail  

2. NetSuite Reports工具的相关实践

报表的相关介绍在上一part基本阐述完毕，那如何在尽可能短的时间内将客户需求与标准基础报表匹配，则是实施顾问们需要长期修炼的一项本领。这项本领绝非是一朝一夕就可以练就，所以自己要在主动学习的同时也要结合实践，在项目中去熟悉并尝试制作各类型的报表就是一个绝佳的实践方式。我在上一个项目中便领下了制作报表的任务，当然Team里面所有伙伴们也都有各自需要负责的报表。

项目调研期间，我们收到了一张来自于财务及业务人员提出的报表需求的Report List，也拿到了一部分样表。客户原本的报表除了之前老系统中能够直接生成的报表，还有一部分是依赖于线下用Excel维护的报表。财务类主要涉及到GL，A/R，A/P，Cash，Fixed Assets，Inventory，Factor，Production，Sales以及Shipment这几个部分。最终，Team一起确定的原则是对原有的报表体系进行“继承和创新”，“继承”是指对其原本的报表名称不做改动继续保留，“创新”则是指我们会将所有报表全部汇总在一个自定义的列表中，并将这个自定义Tab命名为MGT Reports，即Management Reports的缩写。这样就形成了独一无二的，只属于客户自己企业的管理报表体系。

 

之所以选择自定义报表体系，其意义在于：

1.能够保证使用者根据标签的分类快速找到自己需求的报表；

2.管理决策层和作业层进入报表的路径保持统一，获取报表方式一致，这样就大大减少了后期不同人员找不到报表或者找的不是同一个报表的沟通成本；

3.将业务，财务的报表进行融合，站在企业的角度来说体系化程度更高，更加清晰；

4.对于顾问来说，行业之间是通的，每个行业都有其行业特性，在日后实施的项目中，其中类似需求的报表顾问们虽不可完全复制，但可以参考且加以改动。

在企业中，如果是“我”是管理者，我希望报表可以帮“我”打通企业中的数据联系，最好是每个层级部门、每个上下游环节的数据连接；而作为企业运行体系中强大的辅助工具，它可以帮“我”提供准确、可参考的数据给到不同的员工，并且也可以把信息定时同步与“我”，减轻层级之间沟通成本的同时也提高了沟通效率。实际工作中，管理者并没有很多时间去系统内逐个报表一一查看，因此当“我”对于所呈现报表上的数字产生疑问时，“我”可以直接进入系统中去找到原始数据及业务单据，这在一定程度上保证了信息的可追溯性和透明性。

如果“我”是财务及业务人员，“我”希望报表是一个强大的工具以及桥梁。系统可以利用完整的业财一体帮助“我”集成各部门的业务数据，通过日常“我“的操作生成对应的财务凭证，确保财务数据能够百分百地及时、准确，大大提升“我”的工作效率，做到任何数据有源可查，让“我”也不再只能依靠Excel去整理数据，无需二次加工，便可以直接给到上级。同时，“我”希望“我”能看到的报表，“我”的上级也可以直接找到，这样我们不会存在信息差，时间比较紧急的情况下也无需“我”将报表再一一发送给上级。

所以在项目实践中去接触各类型的报表，就需要顾问们站在相应角色的角度上考虑每一个报表的设计，是否能够满足不同使用对象的需求，一段时间的体验下来，相信每一个顾问对于报表的认知都会更加深刻～～

3. 体会NetSuite Reports的优势和局限

以上所总结的内容都是本人所理解的系统内标准默认的报表信息，我们都是可以根据自己的需求对这些报表进行自定义，但是报表终究只是工具，它在展现自身优势的同时也会展现出它本身带有的局限。

众所周知，NetSuite本身拥有自己相当标准的报表模块，也已经有了很明确的分类，所以当用户不知道选择哪一类报表时，从分类和名字上就可以帮助用户来分辨选择。毫无疑问，标准的都是通用的，而个性化的就需要自定义了，而且自定义的程度也有高有低。它就像有一天你想要建一座房子的时候你有几片面积很大的田地供你选择，那首先你就需要找到最适宜建房子的那片地，再在田地上一步一步搭房子，慢慢搭建起符合自己心理的房屋，你想让它满足你的各项基本需求，还想要尽可能地住得舒适。房子就相当于我们搭建的一个报表，最基本的要求是它要满足我所有的数据和功能需求，最好、最完美的状态则是使用起来非常顺手。

目前，我对NetSuite报表模块的强大点和限制点总结如下：

强大点：

结构性——类型全面，结构比较完整；

灵活性——自定义程度高，也可控制角色人员权限；

便捷性——全局搜索，有问题上级可自行查看，也可实现定期自动发送；

多样性——Search/Report/Analytics，选择类型上有一定的空间；

准确性——抓取底层数据的准确性；

限制点：

复杂性——新手及客户学习门槛高，需要时间和经验；

关联性——表与表之间的字段/数据关联会受到限制，抓取不到信息时需要开发；

支持性——如果报表数据量较大，查询速度慢，若列数过多则会报错。

作为实施顾问，初心是不会改变的，我们都希望每一张报表能够最大化地满足客户的需求，满足操作人员在实际场景中的操作需求。所以，在明白了系统的限制之后，我们在制作报表时就会有一个取舍的过程。

我们对NetSuite的Reports模块抱有绝对的信心，但使用标准报表做自定义之前，一定要明确报表的逻辑设计是否符合客户的实际需求，能够面对面地对接则能够更精准地明确客户需求，也是最快解决问题的途径。当使用者讲清数据来源时，我们在设计时才能做到心里有数。既然标准的系统是一个可配置的系统，那具体的需求就尽量通过配置的方式来帮助客户实现，实在不行咱们再找其他路径解决呗，办法总比困难多～

本篇心得体会与各位共勉～