附表用软件做出来的与手工报表不一致，除非用K310.4版本，再说做附表凭证指定在理论上是做不出来的。
原因存在会计科目重分类的问题：如应付账款，应作“经营性应付项目的增加”，但如果月末出现借方余额，则重分类为“预付账款”，那就成了“经营性应收项目的减少”，所以平时做凭证是做不出来的。
最好的办法是用公式法。但金蝶这方面还无法达到。

我对 goodzsz 的说法，不敢苟同。

一、关于现金流量表的编制基础和原理：
我们知道，要谈现金流量问题，首先，要明确会计核算是基于权责发生制还是收付实现制的问题。
无论是实行收付实现制还是权责发生制，都必须辨明收入和费用的收支期间和应归属期。
收入和费用的收支期间，是指收入收到了现款和费用以现款支付了的会计期间；收入和费用的应归属期，是指应获得收入和应负担费用的会计期间。
收付实现制，也称现金制，它是以是否实际收到款项和支付款项为标准来确认某一会计期间的收人和费用。凡是本期收到的款项，不论其是否应该归属于本期收人，均作为本期收入处理；凡是本期支付的款项，不论其是否应该由本期负担，均作为本期费用处理。
在收付实现制下，会计核算主体的所有收入、费用都是以本期收付到款项作为是否入账的判断标准，而这个“款项”，实际上就是现金（广义，包括现金、银行存款和其他货币性资金），那么，会计核算主体中发生的当期的收入、成本和费用，实际上就是相关业务实际的现金流量，若不考虑会计核算制度的差异性的情况下，基本上，从相关现金科目的对应发生额，就可以确定相对应的现金流量项目。
所以，在收付现制下，编制现金流量表，没有实际的意义！
权责发生制，也称应计制，是与收付实现制相对应的概念。它把经营成果或损失归之于导致收人或支出发生的那个会计期间，而不是归之于实际收付现金的那个会计期间。
权责发生制是以滞取收到现金的权利或支付现金的责任权责的发生为标志，来确认本期收入和费用及债权和债务。即收入按现金收入及未来现金收入――债权的发生来确认；费用按现金支出及未来现金支出――债务的发生进行确认。而不是以现金的收入与支付来确认收入费用。
它的确认规则是：凡属本期已获得的收入，不论其款项是否收到，都作为本期的收入处理；凡属本期应负担的费用，不管其款项是否付出，都作为本期的费用处理。反之，凡是不应归属于本期的收入，即使其款项已经收到并人账，也不作为本期的收入处理；凡是不应归属本期的费用，即使其款项已经付出并入账，也不作为本期的费用处理。
权责发生制大反映企业的经营业绩时有其合理性，在实务中，现在几乎完全取代了收付实现制；但在反映企业的财务状况时却有其局限性：一个在看似经营很好、效率很高的企业，实际上却可能没有相应的变现资金而陷入财务困境。这是由于权责发生制把应计未收的收入和应付未付的费用都反映到了损益表上了，而却没有揭示损益、资产和债权债务是由哪部分现金收支形成的、哪部分是应计形成的。
为揭示这种情况，就应编制以收付实现制为基础的现金流量或财务状况变动表，来弥补权责发生制的不足。而管种控制，是必须的。
至于编制财务状况变动表还是现金流量表，不同的国家地区要求不责骂，但量一般基于国情和相应政策制度规定的。就中国来说，1999年以前，编制的的是财务状况变动表，1999年后，编制的的是现金流量表。
用一句通俗的来话，编制现金流量，实际上是基于权责发生制的基础上，将相应的业务数据调整为收付实现制，来体现会计核算主体的各项现金的真实的流入、流出及结存情况。


二、为什么软件做出来流量的与手工报表的流量不一致？
这个问题说起来有些复杂，而且说起来有些泛，但一般情况下，主要出在软件设计的解决思路、企业会计核算是否规范、会计人员是否能快速且准确无误地判定业务现金流量、会计理论界和政策法规对现金流量项目的定义及业务归属流量项目范围的规定、各国会计理论差异和制度差异、合并报表理论差异等几个方面。
1、关于软件设计的解决思路
就国内软件的解决思路来说，无非是公式法、科目(项目、凭证)拆分法、凭证分录指定流量法（代码跟踪法）和会计科目辅助核算法几种。
（1）、公式法
goodzsz 朋友在贴中的提到“最好的办法是用公式法。但金蝶这方面还无法达到。”
真的吗？
公式法，即先通过定义现金流量表的相应项目的报表公式，从资产负债表和损益表之间的报表项目，计算出相应的现金流量，例如，“销售产品提供劳务所收到的现金”通常被定义为：主营业务收入＋其他业务收入－应收账款
实际上，我是最反对使用通过公式，在资产负债表和损益表之间，取数得出现金流量的。
为什么？因为按核算制度的要求来说，绝大多数企业的会计核算业务处理是不完全规范的。
举个例子吧，销售产品时，给客户代垫的运费，会计分录，多数企业会摆到哪？
其他应收款还是应收账款？我想，多数是应收账款吧！
那么，现在问题就来了，应收账款，在表间取数时，大家设置的对应流量是什么？----“销售产品提供劳务所收到的现金”。
公式法的优点是，简单、简便，工作量少。缺点是数据准确性差，而且部分报表项目，可通要通过手工或其他方式获取。
国内的软件，不是处理不了公式法，而是这种处理，实质上没有多大的意义，不信，你去看，金蝶、用友，哪个没有表间、表页间取数函数？

（2）、科目(项目、凭证)拆分法
科目(项目、凭证)拆分法，原理同手工的 T 型账户法，但又略有区别（手工要做调整分录），即基于相应科目的 T 型账户，通过分拆和调整相应科目、核算项目或凭证分录，归集各现金流量项目流量。
科目(项目、凭证)拆分法在一定程度上避免了公式法的缺点，使得流量计算结果更准确，但另一方面，却加大了核算工作量。
科目(项目、凭证)拆分法最大的问题，一个是是流量项目的准确性问题，一般来说，拆分得越细，准确性越高、但工作量越大，拆分得越粗，准确性越小、但工作量越小。另外一个问题，就是没有将科目(项目、凭证)实现与业务的完全对应关系，人为地割裂了业务与之的对应关系，使操作人员容易误断流量的归属。
用友的现金流量表模块和金蝶的T型账户法，实际上都是基于这种原理设计的，只是金蝶的T型账户法，还能具体展开的凭证，能够实现与凭证分录指定流量法（代码跟踪法）的有机结合。

（3）、凭证分录指定流量法（代码跟踪法）
凭证分录指定流量法（代码跟踪法），是指事先定义现金流量项目的代码，在填制凭证编制会计分录时，指定或填列相应业务分录的现金项目代码，以达到归集现金流量的目的。
凭证分录指定流量法（代码跟踪法）的最优点是准确性高，当然这种准确性与会计人员对现金流量的准确判定有很大关系；缺点是工作量大，就日常填制凭证来说，可能的工作强度要成一倍增度。
实务中，凭证分录指定流量法（代码跟踪法）还可以基于工作量和业务需求考虑，在凭证录入时，是只指定现金流量表主表项目，还是同时指定现金流量表主表项目和附表项目。
用友和金蝶都有凭证分录指定流量法（代码跟踪法）的功能，从操作方便性和灵活性来说，金蝶的要强于用友。
goodzsz 朋友提到“附表用软件做出来的与手工报表不一致，除非用K310.4版本，再说做附表凭证指定在理论上是做不出来的。 ”
附表能不能得到数、附表凭证指定在理论上指定出来?在这里，我不再作过多争执，用过凭证分录指定流量法（代码跟踪法）的朋友，可能更清楚。
无论是理论还是软件上肯定可以做出来的来，只是工作量的问题。
实际上，除金蝶10.4产品外，金蝶的其他产品和用友的全系列产品，目前都没有会计科目的现金流量项目的预置功能。
这其实是一个相当好的功能点，我们知道，除了现金、银行存款等几个现金科目外，其他绝大部分科目，实质上都是对应副表的相关科目，比如2007版的企业会计准则制度，存货类科目有十几个，但它们对应流量实际上就是副表的“存货的增加（或减少）”。
不过，会计科目的流量预置功能，金蝶绝对不是国内首家，1999年，我初学用降龙九九（AC990）时，它就有了，只是市场如海、大浪淘少而已！

（4）、会计科目辅助核算
这种方法，说穿了，实质上还是凭证分录指定流量法（代码跟踪法）的一种，只不过是对现金、银行存款等几个科目采用“现金流量”辅助核算而已。
这种方法无甚优点可言，而且，当一笔会计业务混杂数笔现金流量时，要为了获得相应的流量，人为地将一笔会计业务拆分为数笔分录，影响了业务的清晰性。
不过这种方法，对有的软件，比如，用友财务基础版和用友通及版（10.2之前），用友出于产品差异化的考虑，特意屏蔽了凭证分录指定流量法，碰到非要在软件上实现现金流量表，不失为一种方法。

日常实施软件，就现金流量表来说，我常问客户会计的一句话：“你的现金流量表是做给谁看的？”
如果是对外，比如只是报税，可以从简，比如公式法，用软件的报表间取数，或 EXCEL版的《快速编制现金流量表》。
如果是企业内部管理用，应当从细，要求准确性，采用T型账户法或凭证分录指定流量法，日常就要处理。

2、企业会计核算是否规范、会计人员是否能快速且准确无误地判定业务现金流量的问题
这个问题对《现金流量表》的数据准确性，是显而易见的。没有谁敢保证一个核算不规范、会计人员人员连业务现金流量项目都拿不准的企业，它的《现金流量表》数据能准确？
就拿goodzsz 朋友提到“原因存在会计科目重分类的问题：如应付账款，应作“经营性应付项目的增加”，但如果月末出现借方余额，则重分类为“预付账款”，那就成了“经营性应收项目的减少”，所以平时做凭证是做不出来的。 ”
首先，我们要分析的是，为什么应付账款为什么月末会出现借方余额？实际上，很多企业，对账款的科目摆放，预收账款还是应收账款、预付账款还是应付账款，是严格规定的，预付就是预付、应付就是应付，预付款在核销时再作“预付冲应付”！一般况下，根本不允许此类科目出现红字余额。
再者，就应付账款、其他应付款科目来说，不能单纯地定义这个科目为“经营性应收”，实际上，企业核算中，就有固定资产等投资性采购应付款，入应付款科目。还有，预付账款，除投资性采购预付款外，经营性预付款，对应的项目不是“经营性应收项目的减少”，因为你的预付款的最终业务目的，不是以收回货款为结果、而是以收回材料和劳务为结果，当然多付的预付款且要退回企业是作另外论。
应该说，现金流量表的编制，要入门并不难，难的是精通。

3、会计理论界和政策法规对现金流量项目的定义及业务归属流量项目范围的规定的问题
先举两个例子吧。
1999版的《现金流量表制度》与2001版《现金流量表制度》，关于“销售产品所收到的增值税”流量项目的问题，1999版有这个项目，为了准确得到这个数据，要求企业的应收账款科目，所有的子目都区分货款本金和税款两个子目，别说加重了企业的核算的负担，且在实务中，谁能分得清，一笔款项的偿付，哪部分款项是本金哪部分款项是税金？后来，2001版就把这个项目取消了，直接并到“销售产品提供劳务所收到的现金”中去了。
再一个例子，就是以货易货或混杂以货易货的现金业务问题，例如，企业销售产品5万元给A客户，A客户以4万元材料和1万元现金偿付企业，这4万元算不算流量，销售产品所收到现金是5万元还是1万元、购买商品所支付的现金是4万元还是没有？这其是都是有争议的，除了一个做与不做的问题外，还存在一个公允价值的问题，这4万元材料值多少？
我记得，相关制度及解释原来并没有给出说明，很多业绩糟的上市企业就拿这个来做文章，关联交易、以货易货，人为地提升了企业的损益客度和现金流量，假报多了，规定后来也就出来了。
而就我们这些理论与制度规定的被动接受者，理论的变革与制度的变更，一旦频繁，我们稍不学习，便会落后、作出错误的业务判定。再者，由于制度只能做到标准加例举法，实务中出现的问题，可能是这些制度指向不到的，不同教课书、不同的师者，最终教出的结果，肯定会造成学生在认知上的争议。

4、各国会计理论差异和制度差异的问题
这个问题同问题3是一样的，只是基于对象不同而已。
这个问题，最好的例子，便是SAP屠夫在 BLOG 中提到的中石油项目问题，由于单位固定资产价值的入账价值要求的不同，中国是800元，美国是2000美元，沙特是又是一个值，一项固定资产是投资还是经营活动支出？在各国报表之间，流量数所，可能会有天躟之别。
除了核算要求不同外，报表的编制理论不同，同样会产生很大差异，举个例子，中国大陆与中国香港关于现金流量项目大类设置上，分类都有不同，更别说明细项目了。

5、合并报表理论差异
没做过上市企业会计，合并报表不熟悉，请熟悉的人谈谈吧！

---

图画曾识零陵郡，不到潇湘岂有诗！

没想到我随手点点的几行字，能得到Suntime兄的长篇捧场。
或许由于我打字不快，乃至词不达意等原因让Suntime兄没有全面理解我的意思。
我在这里就我的意思有待澄清的地方全面说明一下：
1、我所讲的“公式法”，指是的附表用公式法，并没有指主表，我个人感觉主表用金蝶的T型账户法是最好的办法，用凭证指定慢且效果不好，对某些多多借多贷凭证还不行，结果是T型账户法是等价的，这方面金蝶比用友快得多。
附表用公式法是一次性指定的，且效果能达到你所想要的任何结果，凭证指定往往与手工有些差距，而公式法却能满足。问题是金蝶提供的公式(函数)不是很方便。
2、 关于应付与预付是否可出现红字的问题。这在会计制度中是有明确规定的，无论新的或旧的，这说明在企业是很正常的情况。
Suntime兄所说的“严格规定的，预付就是预付、应付就是应付，预付款在核销时再作‘预付冲应付’！一般况下，根本不允许此类科目出现红字余额。”我做的企业不算多，才3、4家，在我所做的企业中，这类业务都是有出现红字的。至于其他企业，我就不太清楚。不过我觉得，这类不宜用“预付冲应付”工，这样查账非常不方便，如查一个单位付了多少款，就必须同时查应付和预付，等于增加了两倍的工作量，且还要手工加计汇总。而且这类出现红字的往来单位对一个单位来说也是不少的，如果要与对方对账，就要同时打印应付和预付往来单位项目账，我个人认为这不是一个好办法。
多谢捧场!

这个问题1年前我不是和大家讨论过了吗？K看看我的知识共享里面，虽然不是很完全，但是还是指明了方向，哈。

---

一切重新开始！892341599

继续讨论，呵呵：
一、再谈公式法、T型账户法、指定流量法之争的问题：公式法得出现金流量数据的准确度、效果的好坏，很大程度取决于企业会计科目的构建和核算内容的准确把握。核算基础的好坏，会直接影响到主表和副表。公式法有一个很大缺点，因为它无法细致到明细业务，仍正如日志所说，若把投资活动和筹资活动的应收款计入应收账款、把投资活动和筹资活动的应付款计入应付账款，在简单地应用公式法时、不分青红皂白地加减相应科目，取出来的副表“经营性应收项目的减少”、“经营性应付项目的增加”项目数据，照样让人看不到懂。
金蝶的T型账户法确实比用友现金流量表模块强，要拆分数据，可粗可细，灵活性确实蛮大，不过，拆分得越粗、数据准确性自然也就越差，拆分的粗细与否、流量项目指定的准确与否，这些操作完全由操作当事人的心态、工作态度和业务知识水平来所决定。数据的好坏，与软件无关，而是人的问题。不过，金蝶的T型账户法，能够实现与凭证分录指定流量法的有机结合，这是令人折服的。
指定流量法的工作量大、工作速度慢，这是肯定的，因为你要对每一笔业务都要进行流量业务判定，你在制证时，既要权责发生制确认的事、又要做收付实现制确认的事。
至于效果的好坏，我想还是人的问题。
一是会计人员是否能快速且准确无误地判定业务现金流量，一个连流量都不能判定的会计人员，你能指望他给你提供准确的现金流量报表数据？无论是公式法、T型账户还是指定流量法，他做出来的数据，谁敢相信？
也许，这个时候，若企业的企业会计科目的设置和核算内容把握得较准确的话，用公式法得出来的数据会更准确些，实际上这些事不是他做的，财务经理把大方向定好了、相关人员把报表都设置好了，他只是负责取数而已，但其中内在原理和业务逻辑，他仍不理解，可叹的是，现金流量表制度执行这么多年，这类型会计还有很多，也难怪，每一单软件实施，报表的设计设置，全让我们这些软件服务人员给代劳了。
二是价值认同的问题，试想，你花了很大力气去做这一件事，而公司的管理根本没有这方面的要求、相关管理层也根本看不懂，你还会去天天折腾吗？敲钟念经的和尚与不敲钟不念经的和尚，照样吃饭，谁在忽悠谁？现金流量表是好东东，可惜，会用以管理的企业和人却不多。
在指定流量法时，绝大部分流量项目的指定，聚集在现金、银行存款、其他货币资金等相关现金类科目，这确实是个工作量问题。而像存货、应收款、应付款等科目，实际上主要对应的流量在附表的相关项目，这个时候，频繁地去做同一件事情，就该想想办法了，好在K3 10.4 也了会计科目预置对应流量项目的功能，在填制凭证时，自动产生相应的流量项目及数据，若不同，可以修改。但对主表数据指定的工作量，会计科目的现金流量项目的预置功能，并没有起到多大减轻，除非企业的会计核算十分规范、业务又十分单纯。
不过，对于没有预置流量功能的软件，goodzsz 确实提出了思路，对于主表用指定流量法或T型账户法，副表用公式法，这样可以减轻一定的工作量，只是这种做法，在金蝶的现金流量表模块没有办法处理而已，不过，我想，可以考虑，通过金蝶BOS万能开发报表平台或财务报表平台来实现，因为二者支持 SQL 查询，没实践，不敢保证。

二、关于应收预收、应付预付的核算处理问题
应收预收直接通过“应收账款”核算、应付预付直接通过“应付账款”核算，月底，应账款和应付账款，可能有很多的红字余额，在报表时需要调整。这多是中小企业的会计业务处理，确实，会计制度特别是小企业会计制度是允许的，不过，我也没有说绝对的不允许，-:)，至少，我在小企业呆的日子，比大公司长。
但一般规范的上市公司，会计科目的核算范围，确实有很严格的要求，一是企业自身管理的需要，二是证券市场监管的要求，会计事务所在拿人钱财的同时，适当做点良心的事情，还是有的。
从软件应用的角度来看，如果企业有应收应付模块，应收和预收、应付和预付，相关的科目，还是分设的好，否则，像“预付冲应付”这类业务，要作核销，会出现
--------------------------------------------
借：应付账款 A客户
贷：应付账款 A客户
--------------------------------------------
这样的分录，相关凭证、明细账看起来，更不清楚。
至于说对账，清不清楚，有没有相关的账表，你用过应收应付模块就知道了。

三、关于应付账款红字余额、预付账款余额，对应的经营活动流量调整项是“经营性应付项目的增加”还是“经营性应收项目的减少”的问题
我的观点已经说得很明确了。我说过，几年不做会计，对会计业务、政策和法规是越来越远、越来越生疏了。但不过，做了些年头会计，我始终坚信一点，理论和制度是可以挑战的，别一味盲信专家和权威，合理合法合规才是最重要的。

以上讨论，对事不对人，goodzsz，若有什么高见，继续商榷！

---

图画曾识零陵郡，不到潇湘岂有诗！

1、首先感谢乌鸦和矮人对附表使用公式法的开创性工作，尽管当时列出的公式还有待完善。
2、“预付账款”作为“经营性应收项目的减少”、“预收账款”作为“经营性应付项目的增加”是一种主流的作法。
3、金蝶使用现有的公式基本上能作出正确的报表，只是使用不方便，使用ACCTEXT函数即可，如果金蝶能扩大成为月函数就方便了。如果财务功底较深，能做到报表的主表和附表所有项目能从账上取数，主表和附表自动平衡，且不会相差一分钱。我一个月的凭证1000多张，主表、附表能做到不差一分钱，没有任何项目是通过所谓项目之间的倒挤得出的，且与手工做的报表完全一致。
4、如果哪位能提单使金蝶ACCTEXT函数扩大成为月函数，就功德圆满了。