做实施项目，SD模块的静态主数据主要是客户主数据和价格主数据，这篇主要记录项目过程中关于客户主数据遇到的一些问题和看法。

业务

在HANA系统里，客户主数据和供应商主数据的创建、修改、查看都是用的T CODE BP。所有的业务伙伴数据都会在后台表BUT000中创建唯一一条记录。也就是说，如果是外部给号的话，必需理清楚是否存在一个业务伙伴既是客户也是供应商的情况。

如果既是客户，又是供应商，是要分开用不同的代码呢还是用同一个代码？通常，对于业务部门来说，采购部和销售部的用户是希望供应商编码和客户编码分开来，但是财务部出于核对账务等角度考虑，会希望同一个外部会计主体在SAP里用同一个代码。这个时候，资深的顾问可以从过往的经验给出建议，当然了，主要还是看用户最终采用哪一种方案。

客户和供应商采用不同代码

如果是分开用不同的代码，即，同一个外部会计主体，比如客户A，既是客户，也是供应商，那么当A作为客户和作为供应商的时候，其代码在SAP里是不一样的。由于是外部给号，需要采购部和销售部定好各自的编码规则，号码段需要在10位以内(SAP标准)，编码范围不可重叠。这种时候，客户和供应商的BP分组就可以分开来。(HANA的BP分组可以理解为ECC的account group. )通常来说，不建议弄太多个BP分组，客户最好两个分组即可，一个内部给号，一个外部给号。不同的BP分组赋予不同的视图，HANA的标准客户分组需要的视图有：000000业务伙伴常规视图、FLCU01客户视图、FLCU00财务视图。

关联公司

除此之外，对于关联公司(同集团下的其他分子公司)，通常既存在采购关系也存在销售关系，对于这种关联客户，最好是采用外部给号，并且用单独的一个BP分组，SAP HANA中针对这种关联公司客户有标准的BP分组-K400 关联方客商，建议直接用标准的即可。

客户和供应商采用同一代码

对于同一个外部会计主体，即是供应商又是客户的时候，如果采用同一个代码，那么建议客户和供应商公用一个BP分组，该BP分组可以参考上文提到K400复制创建。如果不用同一个BP分组，而是专门建一个Z001的BP分组给客户，一个Z002的BP分组给供应商，而一个业务伙伴只能有一个BP分组，这样就会对用户造成困惑。而且，对于后期给客户扩充供应商视图，给供应商扩充客户视图都比较麻烦。采用同一个BP分组，该BP分组同时存在客户和供应商所需要的视图，对于后期扩充等都比较方便。如果用户需要知道这个业务伙伴是客户还是供应商，可以在主数据中另外找一个字段来存储该信息。

配置

为客户定义科目组和字段选择

路径：实施指南>后勤 - 常规>业务伙伴>客户>控制>为客户定义科目组和字段选择

定义客户主数据的编号范围

路径: 实施指南>后勤 - 常规>商业伙伴>客户>控制>定义和分配客户编号范围>定义客户主数据的编号范围

定义分组和分配编号范围

路径：实施指南>跨组建应用>SAP业务伙伴>基本设置>编号范围和分组>定义分组和分配编号范围

指令客户到业务合作伙伴的BP角色 (即给BP分配视图)

路径：实施指南>跨组建应用>主数据同步>客户/供应商集成>业务伙伴设置>客户集成的设置>定义指令客户到业务合作伙伴的BP角色

定义方向业务伙伴到客户的编号分配(即给BP分组分配账户组)

路径：实施指南>跨组建应用>主数据同步>客户/供应商集成>业务伙伴设置>客户集成的设置>集成的字段分配>定义方向业务伙伴到客户的编号分配

定义合作伙伴功能

路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>合作伙伴功能

账户组-功能分配 (即哪些账户组可以作为哪些partner function)

路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>账户组-功能分配

定义合作伙伴确定过程

路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>合作伙伴确定过程

9.合作伙伴确定过程分配 (给账户组分配partner function dermination procedure)

路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>合作伙伴确定过程分配

开发

客户主数据涉及的开发主要有：批导程序、接口、报表

如果客户主数据是从外部系统传入的，则会涉及到接口，建议接口字段和批导字段以及报表字段保持一致，便于用户理解，也比较容易开发。

接口

接收接口

在与外围系统谈接口字段的时候，还需要注意的以下事项：

对于外部系统传入的客户主数据，一般需要区分3个动作：创建、修改、删除。因此在与外围系统谈接口字段的时候，需要指定一个字段用于区分是创建、修改还是删除？当然，SAP的客户主数据一般不做物理删除，而是打上冻结标记。

对于修改动作，需与外围系统确认是否有哪些SAP不可修改/不可随意修改但是在外围系统存在修改可能的字段，比如BP分组。我这个项目就遇到这个情况，业务把客户分成2类，因此我们也根据这2类客户建了2个BP分组，但是后来与外围系统沟通过程中发现，用户在外围系统可以修改客户的类别，但是SAP HANA的客户类别无法轻易修改。因此，后来我们把客户的这2个BP分组改成只留一个，另外用字段BPKIND来区分客户类别(常规视图-控制-业务伙伴类型，如下图所示)。

需要注意外围系统的客户号码是否是10位以内。SAP系统的业务伙伴代码最多10位，如果超过10位，则有两种解决方案。

方案一：最好让用户修改外围系统原有的客户代码规则以适应新的SAP系统，并给旧的超过10位的客户重新编码——虽然前期整理数据的时候麻烦，不过后期就轻松了。这种解决方案，从长远来看是值得的，能使整个集团的数据尽量统一，有利于统一规划。推荐方案一。

方案二：如果用户不同意修改原有的客户号码规则，那么，可以将外围系统的客户编号存储在字段BUT000-BPEXT中(常规视图-标识-外部业务伙伴编号，如下图所示), 然后SAP产生一个10位数以内的内部编号。但是，这么一来，如果外围系统修改客户数据，SAP需要先通过外部业务伙伴编号找到对应的SAP客户号码，然后再进行修改。如果业务下单也是在外围系统下单，销售订单传入SAP的时候，也需要对合作伙伴进行转换。方案二是下下之选。

外围系统对一个客户是否维护多个银行账号。如果外围系统会给一个客户维护多个银行账号，假设最多3个，则相应的，接口字段也要多几个。

就接口字段长度/格式/是否必填/默认值等跟外围系统达成一致。长度，比如地址长度、客户号码长度等；格式，比如日期的格式，最好采用20201001这种纯数字格式，尽量避免如2020-10-01或者2020/10/01这种非纯数字的格式；必填项检查，也叫做完整性校验，某些字段值对SAP来说是必填的，则要求外围系统必需传值，比如国家地区等，如果外围系统针对该字段是可填可不填，则最好要求外围系统改造，使用户在外围系统必需维护该字段，亦或者双方约定一个虚拟的默认值，比如说街道字段，如果用户在外围系统没有维护地址信息，则外围系统传入默认值999999给SAP等等；默认值，有些字段，SAP需要，但是外围系统也许没有维护该字段对应的信息，则最好让外围系统根据一定规则传输默认值，最好不要在SAP的接口里直接指定默认值，这样有利于后期业务拓展，比如，统驭科目字段，SAP客户主数据需要填写该字段，但一般来说，外围系统是没有该字段信息的，那么我们可以告诉外围系统根据特定规则传输某默认值。

与外围系统约定处理逻辑，是同步还是异步？同步，可以理解为外围系统发送信息给SAP后，需要等待接收SAP处理后返回的成功或者失败信息。如果SAP返回E(失败)，则需要外围系统处理或者重新发送；异步，则外围系统将信息发送给SAP即可，不需要等待SAP返回的信息。

未完待续。

接收接口的FS编写

在FS功能说明书编写这部分，我提供了接口字段模板作为例子。

以下为日志表ZTSD001_CMD所含字段，日志表中包含所有接口业务字段，另标黄的为接口外新增的字段。

对于这种主数据接收程序，程序处理逻辑可参考如下：

步骤1：对接口字段进行完整性校验。如果校验失败则返回错误信息给外围系统。不将信息保存到日志表。

步骤2：对接口字段进行字段逻辑性校验，主要针对长度，值/值域，格式进行校验。如果校验失败则返回错误信息给外围系统系统。不保存信息到日志表。

步骤3：校验成功则将字段信息记录到日志表ZTSD001_CMD，并进行到下一步。

步骤4：对日志表内部分字段根据一定逻辑赋值。

步骤5：根据日志表来创建\修改\冻结对应的客户主数据。

步骤6：如果创建\修改\冻结成功，则返回创建成功的客户号码。如果创建失败，则返回错误信息。

当然，除了接口处理逻辑，通常针对接口，还会有重处理程序，重处理程序需要读取日志表种消息类型为E (Eerror)的数据重新进行处理。如果需要重处理，则需要告知开发，逻辑与接口程序大体一致，需要能够后台处理。

以下是对各个步骤进行详细解析：

1) 将接口字段进行完整性校验。

外围系统推送了客户信息到SAP之后，SAP会进行字段完整性校验：表1第五列标记出了所有接口字段中要进行完整性检查的字段。检查完所有“必填”字段，只要“必填”字段中有一个的值未由外围系统在接口中提供，则针对此次推送返回“E”的错误消息(INFO=E, MESSAGE=Error)、针对错误字段返回Error: incomplete data。然后退出接口。只有表1中所有“必填”字段都有值，才能进入下一步的逻辑性校验。

2) 逻辑完整性校验:

通过完整性校验后，继续进行字段逻辑性校验。表1中第6第7列标出了要进行逻辑性校验接口字段及其校验内容。只要有一个字段逻辑性校验失败，针对此次推送返回“E”的错误消息、针对错误字段返回相应的错误消息，然后退出接口。只有逻辑性校验成功才进行到下一步。相应的错误信息列示如下：

a. 长度：所有字段传输值不能超过设定长度(下称“超长”，但“超长截转”的字段只截转不报错)，若因此项校验失败，则针对此字段返回 “错误：字符长度”，针对此字段返回错误消息(INFO=E, MESSAGE=Error);

b. 值/值域：部分字段只能传输值域内的值(下称“表值”)，部分字段只能传输具体几个值中的一个(下称“定值”)，如因此项校验失败，则针对此字段返回“错误：值域” ，针对此字段返回错误消息(INFO=E, MESSAGE=Error);

c. 检查：基于一定前提下进行完整性检查或唯一性检查，如因此项校验失败，则针对此字段返回“错误：检查” ，针对此字段返回错误消息(INFO=E, MESSAGE=Error);

若长度与值/值域这2种校验在同一字段上失败，则将错误消息内容拼起来(用”/”隔开)统一反馈，如”错误：长度/值域” ，针对此字段返回错误消息(INFO=E, MESSAGE=Error)。

3) 步骤1和步骤2都成功验证，则将字段信息存储在日志表ZTSD001_CMD中。

4) 创建函数ZSDIF001(客户主数据接口)，用于处理该接口相关业务，同时用于重处理调用；

5) 对检查通过并落地后的数据进行操作(也适用重处理机制)。

6) SAP需对日志表内部分字段根据一定逻辑赋值，具体赋值规则请查看表1最后一列中的红色部分。

7) 根据日志表来创建\修改\冻结对应的客户主数据。

如果XBLCK=1，则创建客户主数据；如果XBLCK=2，则修改客户主数据；如果XBLCK=3，则冻结客户主数据。

A. 创建客户主数据：

如果BU_GROUP=Z005，则创建客户主数据时，客户代码采用系统内部给号，不使用外围系统提供的客户号码。BU_GROUP=Z001，则使用外围系统传过来的客户号。

调用FUNCTION CVI_EI_INBOUND_MAIN创建客户主数据。

如果创建成功，则在日志表传输状态字段赋值“S”，消息字段清空内容后增加后续信息：“客户”+客户代码+“创建成功”。

如果创建失败，则在日志表传输状态字段赋值“E”，消息字段清空内容后增加后续：“客户创建失败”+系统错误消息代码。进行一次重处理。

创建成功或者失败的消息随后返回外围系统。

B. 修改客户主数据：

如果BU_GROUP=Z005，则需查找到该客户在SAP中的客户号码，再对该客户号码的主数据进行修改，需先在SAP表BUT000中查找BUT000- BPEXT=ZTSD001_CMD- BPEXT的时候，BUT000- PARTNER的值即为需要修改的SAP客户号码。

如果BP分组是其他，则客户号码直接取接口传入的KUNNR.

如果客户之前冻结过，则需解除冻结，即KNA1- AUFSD=“”。

调用BAPI/Function创建客户主数据。

如果修改成功，则在日志表传输状态字段赋值“S”，消息字段清空内容后增加后续信息：“客户”+客户代码+“修改成功”。

如果修改失败，则在日志表传输状态字段赋值“E”，消息字段清空内容后增加后续：“客户修改失败”+系统错误消息代码。进行一次重处理。

修改成功或者失败的消息随后返回外围系统。

C. 冻结客户主数据：

如果BU_GROUP=Z005，则需查找到该客户在SAP中的客户号码，再对该客户进行冻结。需先在SAP表BUT000中查找BUT000- BPEXT=ZTSD001_CMD- BPEXT的时候，BUT000- PARTNER的值即为需要冻结的SAP客户号码。

冻结客户即将T code： BP 中以下字段打上”01”， 即KNA1- AUFSD=“01”。

冻结成功或者失败的消息随后返回外围系统。

8)输出数据

输出的数据主要是外围系统客户号和对应产生的SAP系统产生的客户号码。同时SAP系统会将产生的结果通过接口反馈给外围系统。具体反馈的字段如下：

后续关于客户主数据发送接口、批导程序等的笔记留待下一篇讲解。