SD从零开始51-54 信用控制范围, 信用范围数据维护, 自动信用控制, 信用控制-阻止后续功能

[原创] SD从零开始51 信用控制范围

分散的组织结构Decentralized Organization

信用控制范围是一个为客户指定和控制信用限额的组织单元；

依赖于你公司的需求，应收款可以使用集中的或者分散的信用政策来管理；

使用分散的信用政策，每个公司代码可以为它的客户确定它自己的信用数据；

一个销售组织只可以分配给一个公司代码，一个业务交易只可以分配给一个信用控制范围；

集中的组织结构Centralized Organization

在集中的组织结构中，公司代码组合到信用管理的一个信用控制范围；通过这种方式，你可以为客户执行跨公司代码的信用管理；

信用控制范围的货币-分散的Currency of Credit Control Area-Decentralized

每个信用控制范围设置了一个缺省的货币；

下列的缩写在这个课程中会用到：

CCA=Credit control area

CCd=Company code

信用控制范围的货币-集中的Currency of Credit Control Area-Centralized

如果信用控制范围包含的公司代码的本地货币不同于信用控制范围的货币，则应收款会按信用控制范围的货币重新计算；

任何未清的订单，交货或者Billing价值也都会按信用控制范围的货币重新计算；

确定信用控制范围Determining the Credit Control Area

到4.0版本，附加的标准可以影响信用控制范围的确定；确定按照如下顺序执行：

　　　　1.      用户出口（EXIT_SAPFV45K_001）；

　　　　2.      来自付款人主记录的销售范围段（Credit control area field in Billing view）；

　　　　3.      销售范围

　　　　4.　　销售组织的公司代码

通过公司代码来确认是以前可用的功能，这种形式的分配任然设置为标准的；

只有来自销售订单的抬头数据会被用户出口考虑；

只有在没有后续凭证存在的时候才可以修改信用控制范围；

单个客户或客户组信用限额Credit Limit for Individual Customers or Groups of Customers

为集团公司统一指定信用数据是可能的；这些统一的数据，例如风险类别和信用限额，对所有成员公司都有效；

所有成员公司的未清订单价值和应收款在一个通用信用管理科目中管理；

MARK：A credit limit for a group of customers is independent of the question of payment，in other words the members assigned to a central credit account can be independent as far as payment is concerned；

新客户的信用限额Credit Limit for New Customers

在业务场景A，如果还没有为客户输入信用数据，则不会执行信用控制；

在业务场景B，立即为新客户确定信用数据，这意味着信用控制从一开始就执行；

你可以在信用控制范围的配置中控制风险类别的自动分配，销售代表组和信用限额；

[原创] SD从零开始52 信用范围数据维护

内部地划分信用控制范围Dividing credit control areas internally

你可以在一个信用控制范围内建立信用代表组；

在销售订单中输入一个分配给客户的信用代表组；然后它可用作分析或者释放功能中的选择标准；

你可以在信用代表组中指定哪些员工会保持邮件通知；

分类客户Classifying customers

你可以根据客户表现的信用风险分配一个风险类别给他们以分类和执行信用检查；

风险类别决定在订单和交货处理中会执行哪些信用检查；

使用客户信用控制组，你可以根据你公司的特定需要将客户分组（例如，按行业或按国家）；信用代表可使用这些组来为回顾和统计分析生成锁住的凭证；

可以在报告中自由地定义和包括客户分组；使用这种方式，信用代表可以按行业或者产品组分组客户；

集中数据和各信用控制范围数据Central Data and Data in each Credit Control Area

总信用限额

使用总信用限额，你决定一个客户在所有信用控制范围内允许的信用限额；所有信用控制范围内的信用限额的和不能超过总信用限额；

最大单个信用限额

最大单个信用限额限制了某个特定的信用控制范围的信用限额；在这种状况下，你不是为某个信用控制范围决定一个特定的信用限额而最好是一个允许的信用限额；

单个信用限额

用单个信用限额，你可以为一个客户在某个信用控制范围内确定一个特定的信用限额；该允许的单个限额必须没有超过最大单个信用限额；当建立一个信用控制范围时你可以为单个信用限额指定一个默认值；当你在公司代码中创建一个客户并且该默认值已经设置了，系统会自动地给该客户分配一个分配一个合适的信用限额；用其他的话说系统会创建合适的信用主记录；

参考日期Reference Dates-Check Dates

下次内部检查日期（Next Internal Review）允许你为客户输入一个日期，在该日期信用限额会重新评估；

如果该日期已经到达或者过期，它不会像下次检查字段（next check）那样导致自动信用检查的通知消息；

上次内部检查日期可用于在信用预览和信用主数据表中的选择和排序；

[原创] SD从零开始53 自动信用控制

信用检查可执行的时间点Points At Which a Credit Check Can Be Carried Out

使用系统设置来指定你想什么时候执行信用检查；你可能，例如，要求只在销售订单处理过程中执行检查；

只要相关的凭证被信用检查block了，销售和装运中的后续的功能就不能执行；

在发货时执行的检查不能再block该交易，因为发货是装运的最后的功能；如果在发货时执行了信用检查并且交货超过了信用限额，它不会为交货记账；系统发行一个错误消息；

自动设置Automatic Settings

客户的信用控制范围，风险类别，以及业务交易都影响自动信用检查的类型和范围；

信用组组合在信用检查中以相同方式处理的不同的业务处理；这些信用组被分配给会为其执行信用限额检查的销售凭证类型和交货凭证类型；

你为每个条目类别决定，是否该条目类别的条目包括在信用功能中（检查和更新未清信用价值）；在信用检查中会被考虑的条目类别的字段“active recievables”必须激活；

检查类型预览Overview of Check Types

你也可以从自动信用控制的的控制表中调用一个检查，该检查可在用户出口中编程；

更多的信息参考在线实施指南：Sales and Distribution System modifications User exits-> User exits for credit checks and risk management；在这里你可以找到一个程序列表，在程序中你需要定义不同于标准设置的检查；

静态和动态检查Static and Dynamic Checks

客户信用揭示可以划分为一个静态部分（未清项，未清Billing价值和交货价值）以及一个动态部分（未清订单价值）；

未清订单价值包含所有部分交货或未交货的订单；它按在一个自由定义的时间或期间单位（日，周，月）的信息结构内的物料可用日期累计；

当定义信用检查，你指定某些数量的相应期间，从这些期间会确定一将来日期；

这样确保了计划在未来的销售订单在确定信用揭示时不会被考虑；

该例子中的“actual date”是在信用水平轴上确定未清订单价值的初始日期；“actual date”是每个检查的当前日期；在一张订单中，该日期是订单创建或修改的日期；在交货中，该日期是交货创建或修改的日期；

检查最大凭证价值Checking Against Maximum Document Values

销售订单或交货价值可能不能超过信用检查中定义的特定值；该价值存储为信用控制范围的货币；这对于尚未为其定义信用限额的新客户特别适用；你可以使用一个为新客户定义的风险类别来启动该检查；

检查对关键字段的修改Checking Against Changes in Critical Fields

付款条件，固定起息日和额外固定起息日定义为关键字段；该检查用于监控客户主记录中这些默认值的修改；

目前不可以定义更多的关键字段；

记住，当你执行这种类型的检查时，系统不能辨别是对客户有利的还是不利的修改；每次对客户主记录中的这些默认值的修改都会调用该信用检查；

检查下次检查日期Check Against Next Review Dates

在这里，你不需要指定许多天数，没有这些“buffer days”，只要系统知道下一检查日期已经到达，系统就会执行检查；

检查未清项Checking Against Open Items

超过某一天数的未清项和客户余额之间的关系可能是不能超过某一百分比；

延期未支付的天数从付款的基准日期开始计算，用其他的话说，如果付款条件是净30天，则系统仅开始计算30天时间内的延期未支付的天数；

检查催款等级的最大数量Checking Against the Maximum Number of Dunning Levels

在客户主数据的公司代码数据中存储当前的催款等级；

[原创] SD从零开始54 信用控制-阻止后续功能

订单的后续功能Subsequent Functions for Orders

标准版本包含预定义的必要条件，它们确认销售和分销凭证的信用状态；如果凭证是锁住的，则这些必要条件是不满足的；

必要条件是用来阻止锁住的订单或者交货的后续功能的执行；

你必须首先在配置中为每个条件和相应的后续功能进行适当的设置；

确保为自动信用控制在检查规则中设置的锁标识符只有在一个相应的必要条件也在凭证中确认了这个标识符时才会被激活；

这允许你决定在你公司中当一张凭证被锁住时哪些后续功能被允许或者阻止；

MARK：你可以阻止为一个交货创建确认的数量，但是需求传输无论如何都会发生；这是因为假定在绝大多数情况下一个交货会在未来某一时点开始；

后续交货功能Subsequent Delivery Functions

像订单一样，交货也具有许多的后续功能，这些功能可以在被信用检查锁住的交货中使用相应的必要条件来阻止；