SAP SD实施笔记-客户主数据（一）

做实施项目，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分组同时存在客户和供应商所需要的视图，对于后期扩充等都比较方便。如果用户需要知道这个业务伙伴是客户还是供应商，可以在主数据中另外找一个字段来存储该信息。

配置

1. 为客户定义科目组和字段选择
   路径：实施指南>后勤 - 常规>业务伙伴>客户>控制>为客户定义科目组和字段选择
2. 定义客户主数据的编号范围
   路径: 实施指南>后勤 - 常规>商业伙伴>客户>控制>定义和分配客户编号范围>定义客户主数据的编号范围
3. 定义分组和分配编号范围
   路径：实施指南>跨组建应用>SAP业务伙伴>基本设置>编号范围和分组>定义分组和分配编号范围
4. 指令客户到业务合作伙伴的BP角色 （即给BP分配视图）
   路径：实施指南>跨组建应用>主数据同步>客户/供应商集成>业务伙伴设置>客户集成的设置>定义指令客户到业务合作伙伴的BP角色
5. 定义方向业务伙伴到客户的编号分配(即给BP分组分配账户组)
   路径：实施指南>跨组建应用>主数据同步>客户/供应商集成>业务伙伴设置>客户集成的设置>集成的字段分配>定义方向业务伙伴到客户的编号分配
6. 定义合作伙伴功能
   路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>合作伙伴功能
7. 账户组-功能分配 （即哪些账户组可以作为哪些partner function）
   路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>账户组-功能分配
8. 定义合作伙伴确定过程
   路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>合作伙伴确定过程
   9.合作伙伴确定过程分配 （给账户组分配partner function dermination procedure）
   路径：实施指南>销售和分销>基本功能>合作伙伴确定>设置合作伙伴确定>设置客户主数据的合作伙伴确定>合作伙伴确定过程分配

开发

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

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

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

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

     

     3. 需要注意外围系统的客户号码是否是10位以内。SAP系统的业务伙伴代码最多10位，如果超过10位，则有两种解决方案。
        方案一：最好让用户修改外围系统原有的客户代码规则以适应新的SAP系统，并给旧的超过10位的客户重新编码——虽然前期整理数据的时候麻烦，不过后期就轻松了。这种解决方案，从长远来看是值得的，能使整个集团的数据尽量统一，有利于统一规划。推荐方案一。
        方案二：如果用户不同意修改原有的客户号码规则，那么，可以将外围系统的客户编号存储在字段BUT000-BPEXT中（常规视图-标识-外部业务伙伴编号，如下图所示）, 然后SAP产生一个10位数以内的内部编号。但是，这么一来，如果外围系统修改客户数据，SAP需要先通过外部业务伙伴编号找到对应的SAP客户号码，然后再进行修改。如果业务下单也是在外围系统下单，销售订单传入SAP的时候，也需要对合作伙伴进行转换。方案二是下下之选。
        

     4. 外围系统对一个客户是否维护多个银行账号。如果外围系统会给一个客户维护多个银行账号，假设最多3个，则相应的，接口字段也要多几个。
     5. 就接口字段长度/格式/是否必填/默认值等跟外围系统达成一致。长度，比如地址长度、客户号码长度等；格式，比如日期的格式，最好采用20201001这种纯数字格式，尽量避免如2020-10-01或者2020/10/01这种非纯数字的格式；必填项检查，也叫做完整性校验，某些字段值对SAP来说是必填的，则要求外围系统必需传值，比如国家地区等，如果外围系统针对该字段是可填可不填，则最好要求外围系统改造，使用户在外围系统必需维护该字段，亦或者双方约定一个虚拟的默认值，比如说街道字段，如果用户在外围系统没有维护地址信息，则外围系统传入默认值999999给SAP等等；默认值，有些字段，SAP需要，但是外围系统也许没有维护该字段对应的信息，则最好让外围系统根据一定规则传输默认值，最好不要在SAP的接口里直接指定默认值，这样有利于后期业务拓展，比如，统驭科目字段，SAP客户主数据需要填写该字段，但一般来说，外围系统是没有该字段信息的，那么我们可以告诉外围系统根据特定规则传输某默认值。
     6. 与外围系统约定处理逻辑，是同步还是异步？同步，可以理解为外围系统发送信息给SAP后，需要等待接收SAP处理后返回的成功或者失败信息。如果SAP返回E（失败），则需要外围系统处理或者重新发送；异步，则外围系统将信息发送给SAP即可，不需要等待SAP返回的信息。
     7. 未完待续。

• 接收接口的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系统会将产生的结果通过接口反馈给外围系统。具体反馈的字段如下：

该接口的FS模板下载链接：
客户主数据传入接口FS编写模板

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