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

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

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

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

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

SAP业务顾问,一篇合格的SAP功能开发说明书如何写--接口篇 图1
赛锐信息,SAP ERP定制,ERP定制

导读

功能开发说明书,也称“功能说明书”,项目上也有称为“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功能开发说明书如何写--接口篇 图2
赛锐信息,SAP ERP定制,ERP定制

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

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

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

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

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

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

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

SAP业务顾问,一篇合格的SAP功能开发说明书如何写--接口篇 图3
赛锐信息,SAP ERP定制,ERP定制

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

上述这一部分,就可以理解为一个简单的接口架构(interface landscape)。

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

1.2.数据触发

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

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

a.自动触发

SAP业务顾问,一篇合格的SAP功能开发说明书如何写--接口篇 图4
赛锐信息,SAP ERP定制,ERP定制

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

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

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

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

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

b.手动触发

SAP业务顾问,一篇合格的SAP功能开发说明书如何写--接口篇 图4
赛锐信息,SAP ERP定制,ERP定制

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

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

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

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

SAP业务顾问,一篇合格的SAP功能开发说明书如何写--接口篇 图5
赛锐信息,SAP ERP定制,ERP定制

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

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

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

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

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

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

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

1.3.数据处理

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

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

a.直接处理

SAP业务顾问,一篇合格的SAP功能开发说明书如何写--接口篇 图6
赛锐信息,SAP ERP定制,ERP定制

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

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

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

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

b.先存储,再处理

SAP业务顾问,一篇合格的SAP功能开发说明书如何写--接口篇 图7
赛锐信息,SAP ERP定制,ERP定制

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

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

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

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

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

2.接口数据设计

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

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

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

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

SAP业务顾问,一篇合格的SAP功能开发说明书如何写--接口篇 图8
赛锐信息,SAP ERP定制,ERP定制

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

3.接口技术实现

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

4.总结

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

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

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

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

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

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

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

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

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

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

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

相关文章

联系我们

联系我们

130-0752-1773

在线咨询:点击这里给我发消息

邮件:info@sapzx.com

工作时间:周一至周五9:00-18:00,节假日正常休息

关注微信
关注微信
分享本页
返回顶部