[原创] SD从零开始62 不完全日志

不完全日志Incompletion log

      一个不完全日志是销售凭证中对你公司重要的而还没有在系统中输入的所有数据的清单；

      你可以在配置中为不完全日志定义这些数据字段；

      系统可以从不完全日志直接跳转到各个屏幕，在这里你可以编辑这些不完全的数据；

不完全订单清单Lists of incomplete orders

      每个员工都可以列出他们已经创建的不完全的销售订单；他们还可以在选择屏幕上显示为某个特定的步骤冻结的某些凭证，例如因不完全而冻结不能装运的所有凭证的清单；

      然后不完全订单可以从这个清单中调用并完成；当你已经完成处理后，系统自动地返回到不完全凭证清单；

不完全销售凭证Incomplete Sales Documents

      在销售凭证类型的配置中，字段“incomplete messages”允许你控制不完全销售凭证是否能够被保存；如果该开关没有设置，则业务流程的下一过程从不完全性程序的状态组确定；

      程序控制这些不完全数据在处理中有什么影响；

      例子：

          如果付款条件缺失，订单可以被交货但是不能被Billing；同时，你也不能参考一张不完全订单创建一张新订单；

          不完全日志告诉你采购订单号码是否缺失，但是你可以继续处理这张凭证；

控制不完全日志Controlling the Incompletion Log

      不完全日志区分以下层次：

          销售凭证抬头；

          销售凭证条目；

          销售凭证计划行；

      在每个程序中你确定那些字段要检查完整性；

      你通过分配程序来确定有效性的范围；例如，你可以使用销售凭证类型来为销售凭证抬头分配不完全性程序；

          抬头的程序->销售凭证类型；

          条目层的程序->条目类别；

          计划行层的程序->计划行类别；

      你也可以标记合作伙伴功能，文本和定价中的条件类型为必输的；如果这些项目缺失的话，会在不完全日志中出现一条记录；

不完全销售凭证的状态Status of Incomplete Sales Documents

      不完全凭证数据通过不同的方式影响进一步的处理；不完全性程序中的每个字段都分配了一个状态组；

      当你定义状态组时，你决定如果数据缺失的话那些步骤应该被阻止；

      例子：

          Incomplete for delivery -> No delivery is possible；

          Incomplete for billing -> No billing is possible；

          Incomplete for pricing -> No order confirmation or billing are possible；

      一个状态组能够包含任何数量的这些影响；

      这允许你独立地为每个字段控制不完全数据的影响；

[原创] SD从零开始63 业务伙伴以及业务伙伴确定

业务伙伴Business Partners

在一个市场中，存在不同的业务伙伴及他们相互之间不同的业务关系；

      业务伙伴的例子：

          客户；

          供应商；

          员工；

          联系人；

      业务关系的例子：

1.供应商-客户：供应商作为到客户的运输代理商；

2.联系人-客户：联系人是客户公司的雇员；

3.联系人-客户：联系人是客户的顾问但是不在其工作；

4.客户-客户：Sold-to party和Ship-to party是不同的人；

5.员工-联系人：联系人被单个地照看；

6.员工-客户：客户经理；

伙伴类型Partner types

      在R3系统中，在市场中存在的业务伙伴用一个伙伴类型来描述；

      在销售和分销应用模块的伙伴处理中定义了伙伴类型AP，KU，LI和PE；

      定义如下：

          AP：联系人；

          KU：客户；

          LI：供应商；

          PE：职员；

      在其他应用中（例如服务管理）不同的伙伴类型已经被定义了（例如，O代表组织单元，S代表职位，A代表工作中心）；

伙伴功能Partner functions

      伙伴类型允许我们区分不同的业务伙伴，伙伴功能则描述了他们在业务交易中扮演的角色；

          例如，不同的客户（客户伙伴）可在一个业务交易中呈现几个的角色；下订单的客户不需要和收货的客户或者负责付款的客户是同一个客户；

      在SAP系统中分配伙伴功能决定特定的伙伴在销售流程中的功能；一个伙伴可能呈现几个功能；

          最简单的情况是，客户伙伴类型中的所有伙伴功能都将分配给一个人；用其他的话说，同一个客户将会是Sold-to Party，ship-to party，payer和bill-to party；

      你可以直接在客户主数据中为一个客户输入联系人并且他们会自动地分配给那个客户；该联系人也可以分配给其他的客户，例如，一个顾问角色；

      运输代理商是供应商的一个例子；

      你自己公司的员工（例如销售代表或者职员）在员工主记录中管理；他们可以呈现伙伴类型“Personnel”的伙伴功能，例如伙伴功能ER，负责人；

销售流程中的伙伴Partners in the Sales Process

      你既可以在销售凭证也可以在主数据中维护伙伴关系；伙伴关系通常都已经在客户主数据中定义了；当你创建一张销售凭证时他们在凭证的抬头自动地带出；

      如果配置允许它，你可以通过进入到伙伴屏幕并修改功能分配来手工地修改或添加这些关系；

      在配置中，你决定几个伙伴是否能够被分配给客户主数据中的一个伙伴功能；如果维护了同一个功能的多个伙伴，则当你输入一张销售订单时，会出现一张包含这些伙伴的选择清单；

      在销售凭证中，系统被配置为只有一个伙伴能够被分配给每个伙伴功能；唯一的例外是outline agreements（伙伴功能AA和AW）；

      你也可以在销售凭证的条目层定义伙伴；然而，只在抬头定义的业务伙伴不能在条目层修改；

      你可以决定那些伙伴功能必须输入（必输功能）；

      你可以阻止任何人修改已经输入的伙伴（例如，你可以标示sold-to party不能在销售凭证中修改）；

      手工地输入或更改伙伴的地址也是可能的，例如ship-to party，这不会影响主记录；

伙伴功能确定程序1Partner Determination Procedure1

      客户主数据；

      销售凭证抬头；

      销售凭证条目；

      交货；

      Billing抬头；

      Billing条目；

      销售活动（CAS）；

伙伴功能确定程序2Partner Determination Procedure2  

      客户主记录的程序；

      销售凭证的程序；

伙伴功能确定程序3Partner Determination Procedure3

      可能的伙伴功能；   

伙伴功能确定程序4Partner Determination Procedure4

      销售凭证的程序分配给凭证类型；

      客户主记录的程序分配各帐户组；

      系统中伙伴在不同的层次出现，例如客户主数据，销售凭证抬头或者销售凭证条目；

      你可以为这些层次的每一个定义你自己的伙伴确定程序；

      一个伙伴确定程序是你可以在其中确定哪些伙伴功能应该或者必须出现；

      你通过分配程序来定义有效性的范围；例如，你使用帐户组来为客户主数据分配伙伴确定程序；伙伴程序分配给伙伴对象像如下：

              Partner object    Assignment key

              Customer master -> Account group；

              Sales document header -> Sales document type；

              Sales document item -> Item category in sales；

              Delivery -> Delivery type；

              Shipment -> Shipment type；

              Billing header -> Billing type；

              Billing item -> Billing type；

              Sales activities (CAS) -> Sales activity type；

客户主数据和帐户组Customer Master and Account Group

          帐户组控制数据的总量以及客户主记录的反应；帐户组已经定义在标准SAP系统中，例如帐户组001 sold-to party，002 Ship-to party，003 Payer等；你还可以按需要创建另外的帐户组；

          当你定义帐户组时，你决定：

              对每个数据字段，它是否显示以及维护是必须的，可选的，或者不可以的；

              编号范围；

              许多其他控制元素，例如客户主数据的伙伴和文本；

          例子：

              仅作为ship-to party（用帐户组002创建）的客户的客户主记录需要与装运相关的信息；Billing的信息是不需要的，这就是为什么相应的字段没有显示的原因；

          和控制客户主记录的帐户组相比，伙伴功能确定哪个伙伴在销售流程中呈现特定的业务功能；

 每个帐户组允许的伙伴功能Permitted Partner Functions per Account Groups

          对于有组织的销售处理，在凭证中，每个客户仅用于已经分配给他的功能是很重要的；你可以通过分配允许的伙伴功能给每个帐户组来确保这点；

          如果你为新的伙伴功能选择伙伴类型客户，然后你需要确定你的哪些客户能够为该伙伴类型输入；

          因为你通过帐户组来控制客户，你分配所有定义好的伙伴功能给每个帐户组；结果是，一个客户的帐户组也控制可能的伙伴功能；

          来自标准系统的例子：

              在下列帐户组的客户能够是sold-to party：

                  001，005，007，CPD等；

              在帐户组002（ship-to party），003（payer）或者004（bill-to party）的客户不能是sold-to party；

          Mark：这些设置在配置中为伙伴确定进行配置；路径：Environment->Assign functions to account group；

销售凭证的伙伴确定Partner Determination for Sales Document

          当你创建销售订单时，业务伙伴自动地从客户主数据中复制；在处理中，sold-to party的客户主数据被访问了；

          在sold-to party的客户主数据中存储了几个伙伴关系；系统也可以从其他客户主记录复制一个伙伴功能以通过指定伙伴功能的来源和确定顺序来为销售凭证创建一个伙伴；当你这样做时，你应该注意系统确定伙伴的顺序；

              间接伙伴功能的例子：

                  你在不同的区域有不同的正常供应商；你希望系统依赖于ship-to party确定销售凭证中的运输代理商；在配置中，你决定系统决定ship-to party首先通过访问sold-to party的主记录；然后访问ship-to party的主记录来确定运输代理商；

          你还可以使用其他的来源来自动地确定销售凭证中的业务伙伴，例如客户层次结构（KNVH），联系人（KNVK），信用代表（To24P）等等的表；

          有一个可用的分析功能用于详细地追踪销售凭证中业务伙伴的自动确定；

SD从零开始62-63，不完全日志，业务伙伴及业务伙伴确定