SAP业务顾问，一篇合格的SAP功能开发说明书如何写–接口篇

前几天，有朋友发私信咨询一般如何写功能开发说明书。这一篇，我们就简单聊聊一般情况下，如何写功能开发说明书。

功能开发说明书，是业务顾问和ABAP顾问在项目上进行有效沟通的基本工具之一。

作为业务顾问，写出一份逻辑清晰、表述合理的功能开发说明书，是必备的技能之一。

本篇，我们就简单聊聊SAP功能开发说明书一般该怎么写。

导读

功能开发说明书，也称“功能说明书”，项目上也有称为“Function Specification”，实际项目中，多为简称“Function Spec”,也有直接简称为“FS”。

以上是一些对“功能开发说明书”较为通用的称呼。这里之所以提到对功能开发说明书的多种不同称呼，是为了接触实际项目不多的朋友，多了解一些项目中的常用称呼。

如果有项目组同事、项目经理，甚至用户提到一些简称，我们不理解，虽然没有太多影响，但是可能在一瞬间，会让他人觉得你项目经验有限，特别是当你的用户将“功能开发说明书”称为“FS”时，你作为顾问还不清楚用户说的是什么，这就会让你在用户心里的专业性产生一定影响。当然，还有很多项目有其他专门的说法，这就另当别论了。

对于功能开发说明书来说，不同的项目组一般都有自己定义好的FS基本格式，所以，在实际项目中，我们需要按照既定的格式去写。但不论格式有何种变化，基于功能开发说明书的功能，基本的要素是要完整的。

SAP中常见的二次开发工作，包括：报表、增强、接口、对话程序，表单打印等。

系统接口，实际上就是实现系统间数据传输的功能，是企业信息系统间非常常见的功能。

本篇，就简单和大家聊聊接口的功能开发说明书，对业务顾问来说，应该如何分析接口、如何合理表述，从而能保证需求被有效传递。

本篇所分享的内容，更多从技术理解和思路方法上，分享一点内容，并不会固定于某种格式，其实如果对接口技术有比较深刻的理解，无论什么格式，都能够完成一份开发能理解，且能有效交付的功能开发说明书。

如有不合理之处，还请大家指正。希望分享内容对大家有一些作用。

思路分析

有过SAP中报表的使用经验，都应该清楚SAP表报的使用方法。比如，我们要通过一个报表查询某些数据，以下就是我们的操作顺序：

这里，我们就要考虑，设计自己的报表时，第一个要考虑的就是定义：SAP系统事务码（T-Code）。当然，不同项目中，都有事务码设计的基本准则，我们需要按照项目上的规则，去定义设计自己的T-Code。

正文

在实际工作中，数据接口从业务要求到技术实现，再到数据流向等不同维度上去区分，会有各种各样的接口方式。

比如，按照，外部系统从SAP中提取数据，或者SAP系统给外部系统主动推送数据，或者SAP从其他外部系统获取数据后进行处理等等。

再比如，数据传输方式，可能是调用远程函数，文件传输，或者，采用中间数据库等方式进行的。

当然，如果按照业务上的功能实现来说，也有各种各样的功能要求，不同的数据传输触发点等。

基于各种各样的接口，作为业务顾问，我们在接到数据接口传输的需求后，要有能力设计合理的数据交互，进而满足业务需求。

1.接口结构设计

作为业务顾问，我们必须有能力根据对用户业务需求的分析，设计出接口的基本结构，为接口的实现做准备。
对于很多新手顾问来说，之所以经常难以完成对接口的设计，主要是缺少以接口实现的思维去分析业务需求的能力。

接下来，我们就结合一个简单的实例，从接口的数据流向、触发和处理这三个方面，去展示如何进行接口的分析。

业务举例：

假定，企业希望在SAP系统中做采购订单，在相应订单到货后，能够在企业的一个专用收货系统中收货，在此系统中完成收货后，SAP系统相应的采购订单，也将自动收货，避免用户需要出现两个系统都要收货的重复操作。

1.1.数据流向

根据业务需求，我们做一个初步分析：

a.参考采购订单的收货，是在外部的专用收货系统进行的，可是当SAP系统中采购订单被创建完成后，这个收货系统是没有采购订单的，所以，我们能首先确认的是：采购订单的信息，需要被传输到收货系统，这样，这个收货系统才能在到货后，有可参考的采购订单信息；

b.当到货后，在收货系统进行收货操作，并要SAP系统执行相应的收货动作，所以我们能确定：收货系统中的收货信息，需要传输到SAP系统中，进而SAP系统能够参考相应信息进行收货。

基于上述的简单分析，我们能够得出一个简单的数据流向：

仅仅这样的数据流向，是否能够满足实际业务需要？

采购订单信息从SAP系统，被传输到收货系统，我们如何保证数据被传输到了收货系统？假定，我们从SAP端做了传输操作以后，但因为各种各样的问题，收货系统没有收到数据，这样就造成了，SAP端有这个采购订单，收货系统没有这个采购订单的问题？

如何解决这个问题？总不能整天让采购部的操作员传输后，还得让收货部门的人检查一下数据到没到？

同样的问题，也会出现在收货操作上，收货系统收货了，但是SAP没有接到数据，没法收货，这样也会造成差异。

这种隐藏需求是用户不会专门给顾问去提的。但是作为业务顾问，必须要有能力注意到这些隐藏需求，或者要注意到这些通用的问题。

所以，我们在设计数据流向时，或者叫设计数据交互时，一定要注意：数据接收系统在接收到系统后，需要给数据发出系统反馈已接收的信息，数据发出系统在接收到反馈信息后，可以将已接收的反馈信息，及时地显示在发出系统中，进而相关发出数据的操作人员，也就能知道自己发出的数据已经被成功接收了。

结合这个需求，我们的数据交互就大致如下了：

当然，实际业务情况，就得根据不同情况而定。

上述这一部分，就可以理解为一个简单的接口架构（interface landscape）。

在接口的功能说明书中，接口架构，或者叫接口设计结构等，是非常重要的一部分，它能够清晰地说明接口的数据流向。

1.2.数据触发

当我们设计好了接口的数据流向基本结构，对于从SAP系统发出的数据，我们得分析具体的数据触发点，或者理解为接口数据会在哪一个操作中产生。

对于数据触发，一般来说可以简单地分为：自动触发和手动触发。

a.自动触发

当我们在SAP系统中完成某项操作时，系统将自动触发接口功能，将相应的数据从接口传输出去。

比如，结合之前的业务举例，采购订单需要被传输到收货系统，我们就可以设计自动触发。

假定，采购订单的流程是：ME21N创建采购订单，ME29N一级领导审批采购订单，ME29N二级领导审批采购订单。经过二级部门领导审批后，此采购订单会被发送给供应商。

如果我们要设置自动数据的触发点，很明显，我们需要设置在二级部门领导审批的位置，也就是要在二级部门领导使用ME29N审批时，设置增强点，当ME29N审批通过采购订单时，触发增强程序，将相应采购订单信息传输出去。

这里，就需要业务顾问按照写增强逻辑的方式，在功能开发说明书中，表达清楚数据传输触发的功能了。

b.手动触发

这类触发，是我们可以专门设置某一个功能，用户可以选定自己要发出去的数据，比如，当我们需要把一些物料、供应商、客户、成本中心等主数据，有选择地传输出去，我们就可以设计一个功能，选择需要的数据，用户可以执行传输等操作。

这个功能在功能开发说明书的表述，可以按照报表的方式，表达清楚筛选条件，以及数据展示界面，以及传输按钮的设计等。

还以上述业务举例，当二级领导ME29N审批后，我们不做自动传输，而是由采购员在手动触发的程序中，每天统一选择被审批通过的采购订单，点击传输执行操作，进而进行数据的传输。这种设计也是可能存在的。

实际项目中，多数需求为：上述两种传输方式均存在的需求。

结合上述举例，用户肯定希望自动化的程度高一点，当领导审批通过后系统自动传输数据。

但是，如果数据传输不成功，用户就需要重新再传输一遍，但采购订单已经被审批过了，原则上不能要求领导撤销后再审批一遍。

这时，就需要设计系统功能，能够支持用户将没有成功传输的数据再传输一遍。

如果用户进一步要求，或者需要更完善的功能设计时，我们可以设置SAP的后台作业。

在前面接口数据流向设计中，当数据传输出去以后，在没有收到对方系统的反馈时，认为数据没有被成功传输。

因此，我们完全可以在SAP系统中设置后台作业，让每天凌晨某个时间点，系统自动将已经发出的，但没有接到对方信息反馈信息的数据，通过手动触发的程序，再发送一遍。

一般设计到这种情况，几乎能够满足所有接口数据传输的触发情况了。

1.3.数据处理

当SAP作为数据的接收方系统时，我们就需要考虑对于接收数据的处理。

一般常见的处理方式：直接处理和先存储再处理。

a.直接处理

有时候，我们对系统间的数据一致性要求非常严格，比如在出库业务中，扫描枪扫描货物出库，扫描系统将数据传输给SAP，一般会要求SAP系统根据传输的数据，做了成功过账出库后，并将出库信息反馈给扫描系统后，才允许扫描系统这笔出库完成，实际货物可以出库，否则，如果SAP没有反馈出库成功，扫描系统也不能认为出库成功。

在这种情况下，就意味着，SAP系统提供相应的可调用函数，扫描系统调用SAP系统提供的函数，执行出库过账等操作。

如果接口这样设计，作为业务顾问，就需要写清楚调用函数的业务参数，并由SAP开发人员开发好相应函数给对方系统，用以发生业务时的调用。

结合我们之前的举例，我们采购订单收货的接口，SAP就是数据的接收方，如果为了保证数据的绝对一致，也可以设置此方式。

b.先存储，再处理

有时候为了保证系统的处理业务的及时性，和系统一定程度上的独立性，当我们不希望数据的发出方系统，不收系统接收方数据的影响时，会建议数据接收方系统，先将收到的数据存起来即可，后续系统的接收方自行处理。

还是以之前的业务举例，当收货系统做了收货以后，将数据传输给SAP，SAP系统可以先将数据存储在自建表中，之后按照顺序逐一进行收货的操作。

这种先存储再处理的方式，可以直接将数据存储在自定义表中，如果接口是文件传输的模式，可以直接存储中间文件。

如果是这种方式，我们在写功能开发说明书的时候，就需要设计相应的自定义表，以及相应的程序读取自定义表中的数据，进行相应的系统操作。这个功能可能是ALV报表格式+调用业务处理的函数（BDC程序）等的执行。

还要注意，这种接口数据的处理方式，需要小心数据的不一致性，比如，当外部系统做了出库，传输相应数据给SAP，SAP系统只是存了起来，还没有做出库的操作，但外部系统默认已经出库成功，并且已经按照之后的业务流程进行了，此时，当SAP利用传输的数据出库时，发现数据有问题，无法出库，这个时候就会出现同一笔业务，在不同系统中的业务状态不一致，数据不一致等问题。

2.接口数据设计

接口数据的设计，其实我们可以理解为哪些数据需要通过接口被传输出去。
比如，上述举例中，采购订单的传输，假定在收货系统中扫描收货时，需要校验这批货物的供应商ID，物料编号，供货数量，以及送货日期，是否与原采购订单上的信息一致，如果一致才能收货。

如果是这种情况，这个采购订单信息的传输接口至少包含：采购订单号、行项目号、供应商号、物料号、采购数量、到货日期等基本信息。

在接口数据设计的信息中，我们需要将每个要传输的字段类型、长度、字段说明等信息罗列清楚。

下图只是一个简单举例，实际业务中，说明的内容要非常详细。

如果是中间文件的接口方式，我们需要清楚地说明文件格式，文件中每个字段的具体作用等。从而确保信息能够被有效地传递给开发人员，开发人员就能够根据文档信息生成相应格式的数据文件，或者根据相应格式解析对方系统传输过来的数据文件。

3.接口技术实现

系统接口的实现方式，这里就不做进一步的解释了，大家可以参考之前文章进行理解。

4.总结

当我们能够对结合系统接口的设计逻辑，对用户的接口业务需求进行合理分析，并按照上述的核心内容形成相应文档，基本上就能将自己的思路有效地传递给开发，以及相应的接口系统。

多数项目中，也有专门的文档：接口协议（interface contract），用于管理接口设计中，主要和外部系统相关的部分，这类文档主要包含了：接口的基本架构，数据流向，以及系统间的字段对应关系等。

好了，本篇就先写到这里吧，后面有机会给大家分享，接口相关的功能开发说明书在编写时，要注意哪些核心问题。

企业上SAP软件为何选择赛锐信息作为实施商?

1、致力于SAP ERP系统应用的服务商；

2、已为国内200多家SAP系统客户的ERP信息化建设提供了咨询及实施服务；

3、拥有完善的产品策划、研发、实验、测试、质量控制过程；

4、公司自主研发的AMS系列软件产品是国内首个用于SAP权限风险识别的增强系统；

5、为用户管理、风险规避和信息审计提供辅助工具；

6、帮助用户规范企业的管理行为，建立合规的管控流程，有效提高企业IT资产投资回报率；

7、技术指标上拥有完全的、独立的领先优势，可以满足市场竞争、技术许可和标准制定等方面的需要；