写在前面的话

这是一本实用的书。它的预期读者包括SAP从业者、企业财务人员（SAP应用者）以及高等学校的企业信息化研究人员（SAP研究者）等。

在为什么要学习这本书的问题上，前言中已经讲过，SAP入门容易但精通很难。如果缺乏对SAP的深刻理解，有可能在企业的实践中，采用了错误的方案，或者过分强调美好的期望而忽略现实基础；或者不能透彻理解SAP所能实现的程度，而采取了简单草率的方案。

遗憾的是，这样的问题在业界时有发生。

我曾拜访过一个企业，该企业的首席信息官（CIO）在SAP系统实施一年后，抱怨当时的实施公司将产成品的价格控制设计为“移动平均价”。他不无后悔地说，“这是我们系统实施过程中最大的失误”。

我曾经帮一个企业实施二期项目，结果在实施过程中，发现一期的一些设置不尽合理，例如，客户组的划分中除了常规有交易的“国内客户”和“国外客户”外，还设置了一个“国内潜在客户”和“国外潜在客户”。这就带来一个问题，如果有一天，某潜在客户变成了真实的客户，是否要新建一个客户呢？到了二期项目时，已经发现了这些配置的不合理，但由于这些配置属于系统的基础性配置，难以更改，于是，只能在“夹缝中”艰难地适应与微调。

我曾经多次帮助企业解决资产超过两年没有正常结算的情况。可能大家都认为，资产年终结算不是每年都要执行的程序吗？但事实上就存在这样的不规范操作：年终结算时系统报了错误，但没有人真正彻底地予以解决。如果一年没有成功结算，似乎没有问题；两年不执行，似乎也没有问题，但到了第三年初，问题就暴露了：前年的资产年终结算未完成，导致当前年度的财年无法打开；而如果回头处理前年的资产年终结算，可能会产生前年的折旧记账（前年的账务早就关闭了！）。但往往在操作层面，用户运行年终结算时，碰到问题，不知道如何解决，也没有足够重视此问题，认为不能成功结算就放置在一边，最终问题到了无法解决的时候被暴露出来，可惜为时已晚。

还有多个企业的IT负责人在新年后的第一个工作日打电话、发邮件寻求支持，告知由于新的年度的凭证编号没有及时维护，导致有些凭证进入了9999年度的编号范围，而发现此问题后，再维护当年度的凭证编号范围，结果又引发系统的“快件”（express，系统发送的通知消息）。

…………

凡此种种，都是由于SAP的设计者将系统设置得非常精细，而我们在实施或者操作时，没有充分地领会它的精细设计，更没有领会它背后的思想，于是做出了错误的决策或者没有及时正确地对待系统。

因此，我希望，每一个从业者或应用者都能拥有“扎实的知识”（solid knowledge），不仅仅限于表面。这也是我撰写这本书的初衷，也是希望读者能从这本书中领会到的。

为了将知识完整地呈现出来，书中除了介绍系统原理外，还安排了以下板块。

【业务操作】详细介绍每个业务操作的步骤，对屏幕上出现的关键字段予以解释。涉及后台配置的，也顺便介绍一下后台的知识。

业务实践 企业在某一业务操作上的惯常做法。它可以作为其他企业的参考。例如，讲到成本中心计划的“编制助手”时，介绍企业在什么情况下会用到该功能。

那么，各类阅读者应如何使用本书呢？

作为SAP从业者，尤其是咨询顾问，应首先从体系上了解SAP的知识架构，然后逐一了解在中国的企业实践中应掌握的知识。而对企业实践中应掌握的知识，首先要熟悉系统，包括原理、配置、操作方法，其次要了解在中国应该如何设计系统、如何应用系统，有哪些注意点。单纯掌握了配置或操作，并不能使自己成为一名好的咨询顾问。有很多咨询行业的入门者，希望一开始就配置一个全新的公司代码，然后用自己的公司代码来做练习。但是到头来他会发现，自己配置的公司代码什么都做不了，做凭证时处处碰壁，涉及后勤的业务也做不通。这就是方向上弄错了。

作为咨询顾问，最终的确要熟悉系统的配置，以便针对企业的业务需求，搭配出一套合理的系统，但是在此之前，要想快速学习系统，还是需要一些“逆向工程”的思维，即先熟悉现有的系统、现有的配置，然后在此基础上通过操作查看产生的效果，最后再去想，如果是我自己设计这样的系统，应该怎样取长补短。这就好比设计一种发动机，我们可以先拿已有的发动机进行试验，观察它的运作原理是怎样的，然后再对它进行拆解，分析它的构成，各机体怎样配合产生作用，最后我们自己设计时，就有了设计的思路或者改进的建议。也正因为如此，我认为，SAP公司的IDES是一个很好的学习系统。初学者可以借助IDES中的样本公司，开展学习。因为IDES中预装了很多的公司代码以及很多的交易数据，可以供我们走完企业基本的业务流程，而无须重新配置系统。在学习时，可以借助SAP词汇表4.6C（只有在这个版本中，才有关于IDES的详细介绍，包括可用的数据、可以测试的业务操作引导）的参考资料进行学习。本书提供了从原理到配置再到实际操作的合理的学习路线，可以帮助初学者结合IDES，一点一滴地积累起对SAP的认识，打下坚实的知识基础。

作为咨询顾问，除了需要熟练掌握SAP，还需要善于设计妥善的方案。考虑到企业应用SAP，可能是长达几年甚至数十年的事情，因此，方案必须经得起时间的考验，并且能够被企业用户代代传承下去。在本书若干章节的后面，还增加了一些有关中国企业设计参考和业务实践的篇幅，供咨询顾问参考。

作为SAP应用者，广大的企业用户可能没有太多的学习负担，不需要了解配置的细节，但是对业务原理的了解和掌握是必需的，对操作的细节也是应该熟悉的。在学习本书时，可以结合自身的日常操作，来理解该操作的作用、原理和注意点，这样，可以更有效地利用SAP系统。例如，使用某事务代码执行一个报表，理解了原理和不理解原理的效果是不一样的。前者可以更好地分析报表的结果是否正确，或者结果对我们有何指示意义，而后者只是看到“报表有数据产生”，无法判断，无法分析。在不了解原理的情况下，就很容易出现前面提到的“两年没有完成资产的年终结算”这种情况。

SAP是一个集成运转的、高度自动化的处理系统。这就要求处在该系统链条各环节的人员（企业各部门用户）能够自动集成为一个整体，干好各自的本职工作，不要出纰漏，或者出了纰漏能及时对症下药加以解决，这样，系统才会运转得顺利；否则，SAP成了带病的肌体，最终会给企业带来痛苦。

作为SAP研究者，我们既不要将SAP想得非常完美，也不要将它看得过于简单。SAP作为依靠软件技术建立起来的信息系统，必须遵从一定的数据结构和逻辑规则。离开了数据结构，任何天马行空的需求，只能是空中楼阁。例如，我经常听到这样的需求：能不能分析每一个采购订单从下单到收货、到收发票、到付款全过程的执行情况。某企业甚至为此提出了一个新名称，即“采购合同台账”，但结果四五年过去，证实这是个不可能实现的东西。为什么？因为这是一个在逻辑上存在缺陷的问题：针对采购订单的每一个行项目，收没收货是可以跟踪的，收没收发票也是可以跟踪的，但是如果多个采购订单的多个行项目合计开了一张发票，而且这张发票还只付了一部分的款项，那么，谁能知道付的这一部分款项是针对哪一个采购订单的哪一个行项目支付的呢？没人能知道。因为，到了付款环节，它的关联对象是发票了，不再是采购订单的行项目，如下图所示。除非这张发票的所有金额全部付清，我们可以说，它所关联的采购订单的行项目被全部付清了。而在只支付部分款项（下图所示的“付款1”）时，“采购合同台账”是不可能做出来的。

在理论研究上，我们听到很多类似的需求，如“费用科目直接区分制造费用、销售费用和管理费用”“在制品的盘点”“收发存报表”等，似乎只要是理论上说得通的，就一定能实现。但放之于SAP系统，由于系统本身的集成逻辑，并不一定能实现，或者是通过变通方式才能实现。因此，作为理论研究人员，必须熟悉SAP本身的原理甚至数据结构，才能使理论有厚实的基础。在SAP的应用上，我们更关注“终极需求”，即到底给企业带来什么样的好处，而不要过分追求在细节上保留传统的习惯。

本书最后专门增设的第11章“SAP财务应用方面深入思考的专题”，其中部分专题就是对国内企业常见的问题进行理论探讨，希望企业的信息化应用能轻松地走在正确的道路上。

希望本书有更广泛的读者，大家可以开展讨论、完善本书的内容，总之，愿本书使中国的企业在应用SAP的过程中，少走弯路，应用得更顺利、更有效。若能如此，本书将对中国企业信息化尽一份绵薄之力。