SAP-SD信用管理实施总结

server/2025/2/12 11:28:44/

SAP-SD

信用管理实施总结

摘要

信用管理是SAP-ERP系统(以下简称SAP) SD模块中的子模块,主要用于有效平衡赊销模式和资金回笼这两个业务层面之间的矛盾。本文档以信用管理在SAP系统中的实现方法为出发点,结合业务背景,以S4 HANA 1610版本的系统为操作平台,分别介绍其后台配置及前台业务。涉及的内容包括:信用控制范围、自动信贷控制、静态信用检查、动态信用检查等重要配置点及其应用分析。希望通过此次学习,能让大家对于信用管理这一块的内容有所收获。

目录

引言... 1

1.业务背景... 1

2.信用管理阶段... 2

第一章 后台配置... 3

1.信贷控制范围... 3

1.1 信贷控制范围简介... 3

1.2 定义信贷控制范围... 5

1.3 给信贷控制范围分配公司代码... 9

1.4 给信贷控制范围分配销售范围... 10

2.信用段... 12

2.1 信用段简介... 12

2.2 定义信用段... 13

2.3 关联信用段与信贷控制范围... 15

3.风险类别与风险类... 16

3.1 风险类别简介... 16

3.2 风险类简介... 17

3.3 定义风险类... 18

3.4 定义风险类别... 19

3.5 定义风险类评分及信贷限额计算规则... 21

3.5 定义计算公式... 24

4.信贷组... 26

4.1 信贷组简介... 26

4.2 定义信贷组... 27

4.3 给信贷组分配销售凭证和交货凭证... 28

5.自动信贷控制及检查规则... 30

5.1 自动信贷控制与检查规则简介... 30

5.2 定义自动信贷控制... 31

5.3 定义S4信贷检查规则... 36

6.激活信贷更新... 39

6.1 信贷激活简介... 39

6.2 给项目类别激活信贷... 40

6.3 激活信用参数文件页签... 41

6.4 激活信用段... 42

6.5 激活信用屏幕顺序... 43

第二章 前台操作... 44

1.信贷控制范围&信用段... 44

2.销售订单... 48

3.交货单... 50

引言

1.业务背景

现金销售和预收款销售一般指发生在垄断性行业,多数企业不得不面对产品赊销的两难选择,赊销是把双刃剑,如果不赊销,不能迅速扩大销量,从而影响企业的成长速度;如果赊销,则生意虽然做大,特别国内信用制度还未完善情况下,大笔坏帐也跑出来了,严重降低资金周转率和利润率,甚至导致企业资金链的破裂,企业的危机也就跟着出现。处理这个问题的关键就在于如何处理应收账款管理、进行信用管理和风险控制防范,在争取尽可能扩大销量和应收账款回收之间进行平衡,销售部门的工作是接单,而财务部门应收账款的目标是收款,中间环节是启用信用控制。有的企业可能是由销售业务部门进行信用额度控制,如果需要,可以单独设置信用风险管理部门,独立于财务部门及销售部门,指导整个集团或公司的信用政策和管理信用。为了加强应收账款管理,除信用管理外,SAP系统还可以利用其他的方式来做付款担保,如信用证明和支付卡等来减少应收账款的风险,而这部分担保应收额也直接影响客户信用额度。为了更好地研究信用管理功能在ERP系统中的应用,本次在S4 HANA 1610版本的系统做测试。

2.信用管理阶段

在SAP系统中,信用管理可以进行三阶段控制:事前计划、事中控制、事后评估。事前计划主要表现为给客户授信,确定信用检查规则;事中控制主要表现为对销售订单,交货单,发票单据,会计凭证等的变更控制;事后评估主要体现在如果在操作环节因为信贷额度不够等原因,需要对客户进行信用评估,最后再判断是否需要解除信用冻结。

第一章 后台配置

1.信贷控制范围

1.1 信贷控制范围简介

信贷控制范围是SAP销售和应收模块中用于控制信用风险的组织机构。客户信用限额的指定和控制都在这个组织范围里进行。根据需求可将一个或多个公司代码分配给同一个信贷控制范围,一个公司代码只能分配给一个默认的信贷控制范围,一个信贷控制范围只能一种货币保存信用数据。

目前SAP对客户的信贷管理有三种方式:集团式管控、公司管控、具体业务管控;集团式管控,是对客户在集团层面集中管控,比如一个集团下面有多个公司,对应多个公司代码,但是只有一个信贷控制范围,对客户的授信在集团层面统一授信;公司管控,在公司代码层控制授信,一个公司代码对应一个信贷范围;具体业务管控,是在销售范围层设定信贷范围,按照每个销售订单的销售范围,确定不同的信贷范围;在正常业务中,一般会按公司代码层设定信贷控制范围,对客户设定一个总的信贷额度,然后在各信贷范围之间分配。

在ERP集中实施的零售企业,比如一个省级销售公司下包含若干个市级销售分公司,假设只使用了一个省级公司公司代码,市级分公司被作为利润中心或业务范围,销售方式分为零售、直销或批发等,那么可以根据不同的业务范围/利润中心、不同分销方式或不同的产品类别在同一公司代码下设置多个信用控制范围,当然也可集中设置一个信用控制范围。

集中的信用控制提供了更加统一的、稳健的销售风险管理,很显然,可以防止某客户在A市欠钱未还后跑到B市分公司继续赊购。分散的信用管理可以发挥地市公司熟悉对当时当地销售环境这一优势,争取更多良好信用的客户,扩大市场份额,各有利弊,需要权衡扩大销售规模和风险控制。

信用控制范围一般来自SD与FI两个模块,涉及以下两个表(仅ECC可用)。

KNKA:客户主数据信贷管理的通用数据表。

KNKK:客户主数据信贷管理在信用控制范围维度下的数据表。

KNKA表作为通用数据表,为一个集团总的信用控制额度,尤其对于一个ERP集中应用的跨国集团,比如可以定义客户总的信用额度为USD金额,就保留在KNKA表格中。

同时,总的信用额度可被分配到各信用控制区域,很好理解,同一客户可能和集团中国区、日本或欧洲区的公司发生业务,假设该客户被设置对应三个分别使用货币类型为CNY、JPY或USD的信用控制区域,则KNKK保留的是该客户在三个信用控制区域的信用数据。

当然,集团内中国区、日本或欧洲区的公司使用了不同本位货币会计核算虽然分开,但对于客户的信用也可以统一管理的,只要将这些不同本位币的公司代码纳入同一信用控制范围,信用控制范围货币可以考虑使用总部集团的货币,各公司代码的信用发生额自动根据系统设定汇率转换为统一的信用控制范围货币。总之,信用统一或分散管理视集团实际需求,非常灵活。

信用控制范围的设置,类似于成本控制范围的设置。可以针对中国区、日本或欧洲区设置三个CO控制范围, 每个控制范围使用各自的货币,在整个集团盈利分析时,将三个控制范围再集中分配到一个经营范围,也可整个集团的中国区、日本或欧洲区所有公司代码都分配给同一控制范围,各有利弊,此处不再细述。

1.2 定义信贷控制范围

TCODE: SPRO

配置路径:IMG > 企业结构 > 定义 > 财务会计 > 定义信贷控制范围

配置路径截图:

图1-1-1 定义信贷控制范围的配置路径

配置点详解

图1-1-2 定义信贷控制范围的配置点

如图1-1-2,现对图中相应配置字段做解释。

信用控制范围:设定一个信用控制区域代码。

货币:信用控制范围层级的货币类型。

更新:一共有四个值,分别为空、000012、000015、000018。用于定义在哪些环节更新客户的信用数据。需要注意对客户应收清账与“更新”字段无关,不管设置哪个值,对客户应收进行清账都会更新信用数据。

1)空值:表示销售环节的任意操作都不会更新客户的信用数据。

2)000012表示从销售订单创建、交货创建、开具开票、发票过账这几个步骤都会影响客户的信用。对于企业来说,如果他们是常规销售业务流程(订单→交货→开票流)的话,一般都选择更新字段的值为:“000012”。具体影响如下:

A创建销售订单,会根据销售订单未清交货计划行,增加销售订单的未清值(更新后台表:S066的数据,增加未清订单字段值)。

B创建交货单,会减少参考销售订单的未清值(更新后台表:S066的数据,减少未清订单字段值),增加未清交货值(指交货单未开票的值,更新后台表:S067的数据,增加未清交货字段值)。

C开具发票,会减少参考交货单的未清值(指交货单未开票的值,更新后台表:S067的数据,减少交货未清值),增加未清发票数量(指已开票未过账的值,更新后台表:S067的数据,增加未清发票字段值)。

D释放到会计凭证,会减少未清发票数量(指已开票未过账的值,更新后台表:S067的数据,减少未清发票字段值),增加该客户的应收账款总额。后续需要通过F-28收款清账,或者其他方法抵消应收,减少客户的应收账款总额。

3)000015表示系统会从创建交货单、开具发票、发票过账这几个步骤会影响客户的信用,但是创建销售订单不影响客户的更新。如果企业对于合同信用管控要求不高,更倾向于对实物和资金流管控的话,建议使用“000015”的更新策略。具体影响如下:

A创建交货单,会增加未清交货值(指交货单未开票的值,更新后台表:S067的数据,增加未清交货字段值)。

B 开具发票,会减少参考交货单的未清值(指交货单未开票的值,更新后台表:S067的数据,减少交货未清值),增加未清发票数量(指已开票未过账的值,更新后台表:S067的数据,增加未清发票字段值)。

C释放到会计凭证,会减少未清发票数量(指已开票未过账的值,更新后台表:S067的数据,减少未清发票字段值),增加该客户的应收账款总额。后续需要通过F-28收款清账,或者其他方法抵消应收,减少客户的应收账款总额。

4)000018表示系统会从创建销售订单、开具发票、发票过账这几个步骤会影响客户的信用,但是创建交货单不影响客户的更新。对于服务类行业、或者实行项目工作制,没有实物销售的企业,仅需要对销售订单和发票层面做严格信用管控的,建议采用“000018”的更新策略。具体影响如下:

A创建销售订单,会增加未清交货值即使没有生成交货单,也会增加交货未清值。更新后台表:S067的数据,增加未清交货字段值)。

B 开具发票,会减少参考交货单的未清值(指交货单未开票的值,更新后台表:S067的数据,减少交货未清值),增加未清发票数量(指已开票未过账的值,更新后台表:S067的数据,增加未清发票字段值)。

C释放到会计凭证,会减少未清发票数量(指已开票未过账的值,更新后台表:S067的数据,减少未清发票字段值),增加该客户的应收账款总额。后续需要通过F-28收款清账,或者其他方法抵消应收,减少客户的应收账款总额。

S4的未清项后台表:销售订单和交货单的未清后台表:V_UKM_TOTALSS066S067的汇总),未清销售订单的信贷风险类别是100,未清交货的信贷风险类别是400,未清发票的信贷风险类别是500。未清会计凭证的后台表是:IFIRECPAYITEM(清账凭证与应收凭证的汇总表),需要对所有金额汇总,对应的风险类别是200。

FY变式:用于确定信用数据的过账期间,比如决定写入表S066,S067的信用数据时,写到哪个会计年度和期间中。

自动创建新客户配置数据:此处配置表示在创建新客户系统可以自动建立信用数据,这里的数据可作为缺省值默认带到客户信用数据中。

风险类别:维护在客户信贷主数据中,对客户在信用层面进行分级。主要用于信贷检查控制用。

信贷限额:在此信贷控制范围下,给客户维护的默认最大信贷额度。

代表组:给信用检测员(例如信用分析师小组或个人)进行分组。

所有公司代码:勾选表示此信用控制范围允许在所有公司代码下过账;同时,也意味着如果对该信用控制范围进行信用评估,将显示和评估所有公司代码下的数据。

1.3 给信贷控制范围分配公司代码

TCODE: SPRO

配置路径:IMG > 企业结构 > 分配 > 财务会计 > 给信贷控制区分配公司代码

配置路径截图:

图1-1-3 给信贷控制范围分配公司代码的路径

配置点详解

图1-1-4 给信贷控制范围分配公司代码的配置点

如图1-1-4,对应的后台表是:V_001_X。现对图中相应配置字段做解释。

公司:被分配的公司代码。

公司名称&城市:已在公司代码数据中维护。

CCAR分配的信贷控制范围。

覆盖CC范围:如勾选,则CCAR字段的值在公司代码过账的时候是一个默认的信贷控制范围,这个信贷控制范围在过账前可以被替换成其他的信贷控制范围。

1.4 给信贷控制范围分配销售范围

TCODE: OVFL

配置路径:IMG > 财务供应链管理 > 信用管理 > 与应收账款模块和销售与分销模块的集成 > 有销售与分销的集成 > 分配贷款控制范围的销售范围

配置路径截图:

图1-1-5 给信贷控制范围分配销售范围的路径

配置点详解

图1-1-6 给信贷控制范围分配销售范围的配置点

如图1-1-6,对应的后台表是:V_TVTA_KKB,现对图中相应配置字段做解释。

Sorg.销售组织

Dchl分销渠道

组:产品组

我们把销售组织,分销渠道,产品组这三个维度的组合,叫做销售范围。

CCAr信贷控制范围,即将信贷控制范围与销售范围做分配。

2.信用段

2.1 信用段简介

在S4版本中,客户的信用管理数据在事务代码BP维护,业务伙伴角色是UKM000。在维护过程中,我们并不能直接输入信贷控制范围这个组织架构,而是需要输入一个信用段,并且在信用段的维度下去维护相应信用管理数据。对于信用段,可以分为主信用段(信用段是0000)和其他次级信用段,我们可以通过配置把次级信用段的客户信贷负债汇总到主信用段。当然,在后台也有配置,会把信用段和信贷控制范围这两者进行关联,本章会有介绍。

2.2 定义信用段

TCODE: SPRO

配置路径:IMG > 财务供应链管理 > 信用管理 > 信贷风险监视 > 主数据 > 创建信用段

配置路径截图:

图1-2-1 定义信用段的配置路径

配置点详解

图1-2-2 定义信用段

如图1-2-2,为信用段的配置点,现对相关字段做介绍。

名称:信用段描述。

货币:信用段下维护信用额度之类数据的货币类型。

汇率类型:折算成外币的汇率类型。

对主信用段的附加缴纳:若勾选,表示会把该信用段的信贷发生额同步汇总到主信用段0000。

2.3 关联信用段与信贷控制范围

TCODE: SPRO

配置路径:IMG > 财务供应链管理 > 信用管理 > 与应收账款模块和销售与分销模块的集成 > 有销售和分销的集成 > 指定信用控制区域及信用部分

配置路径截图:

图1-2-3 关联信用段与信贷控制范围的配置路径

配置点详解

图1-2-4 关联信用段与信贷控制范围

如图1-2-2,为信用段和信用控制范围的分配截图,配置点不做赘述。

3.风险类别与风险类

3.1 风险类别简介

将客户风险类别分成3类,通过对客户的风险类别确定信用等级和信用额度,比如高风险客户会恶意拖欠,只能允许现金销售,不再允许赊销业务。通常,何评估客户风险是有一套严格的程序和方法,作为客户信用评估的基础依据,特别是在客户履约风险评价方面。比如传统的“5C”要素: 品质(character)、能力(capacity)、资本(capital)、担保品(collateral)和环境(condition),都是评价的基础。风险类别我们可以定义高、中、低三个类别,如A、B、C。

例如,中国石油ERP建设,将客户信用风险类别分为A、B、C三类:A类客户是中石油、中石化、中海油内部客户,不进行信用控制,日常发货按签订的合同执行;B类客户是各油田多种经营单位,属于高风险客户,设信用额度,信用额度按客户情况进行评定,严格执行设定的信用额度;C类客户是油田外部公司、私营企业、信用不良的客户,信用额度为零,不进行赊销业务,仅采取现金交易方式。

3.2 风险类简介

在S4 HANA 1610系统中,在客户主数据设置风险类这个概念,这个风险类和上面所说的风险类别具有同步关系。需要做配置:风险类和风险类别的值需要相同,然后风险类会和风险类别自动同步。

对于风险类,可以在客户主数据手工维护,也可以通过S4系统的客户评分功能(可配置计算公式),自动给客户归入相应的风险类,不同的分段就代表着不同的风险类(后台有配置,下面会介绍)。

3.3 定义风险类

TCODE: SPRO

配置路径:IMG > 财务供应链管理 > 信用管理 > 信贷风险监视 > 主数据 > 创建风险类

配置路径截图:

图1-3-1 定义风险类的配置路径

配置点详解

图1-3-2 定义风险类

如图1-3-2,为风险类的配置点。关于风险类,采用系统预设的A、B、C、D、E这五种风险类。后面的“计分从”和“计分至”就表示各个风险类对应的评分段。

3.4 定义风险类别

TCODE: SPRO

配置路径:IMG > 财务供应链管理 > 信用管理 > 与应收账款模块和销售与分销模块的集成 > 有销售与分销的集成 > 定义风险类别

配置路径截图:

图1-3-3 定义风险类别的配置路径

配置点详解

图1-3-4 定义风险类别的配置路径

如图1-3-4,为新建风险类别。风险类别是需要分配信贷控制范围的,如图中的1050就是给风险类别(参考风险类的字段值创建)A、B、C、D、E分配的信贷控制范围。

3.5 定义风险类评分及信贷限额计算规则

TCODE: SPRO

配置路径:IMG > 财务供应链管理 > 信用管理 > 信贷风险监视 >主数据 > 为记分和信贷限额计算创建规则

配置路径截图:

图1-3-5 定义风险评分及信贷限额计算规则的配置路径

配置点详解

图1-3-6 定义风险评分及信贷限额计算规则

图1-3-7 定义风险评分及信贷限额计算规则-评分

图1-3-8 定义风险评分及信贷限额计算规则-信用额度

图1-3-9 定义风险评分及信贷限额计算规则-分级程序

如图1-3-6,为系统预设的计算规则。“默认”字段表示,在新建客户主数据信贷视图的时候,会默认指定的一个评分计算规则。

如图1-3-7,为计算规则“B2B-EXIST:现有客户的规则 - 业务范围”下的风险评分规则,设置的评分计算公式为:SCORE_B2B。选中该行,点击按钮“

”即可查看对应公式的计算规则。对于图1-3-7中其他字段的解释如下:

有效性(天数):表示被分配的公式在该规则中的有效天数。

跟踪:影响客户主数据中,在列表:“计分”旁边的按钮“

”。如果希望点击这个按钮,可以显示整个评分的计算过程,就需要把跟踪这个钩打上。

BW-得分:应该翻译成BW-评分,该字段目前不可编辑。需要与BW模块配套才能使用的一种风险评分模式。

如图1-3-8,为计算规则“B2B-EXIST:现有客户的规则 - 业务范围”下的信贷限额确定规则,设置的限额计算公式为:LIMIT_B2B。选中该行,点击按钮“

”即可查看对应公式的计算规则。

有效性(天数):表示被分配的公式在该规则中的有效天数。

跟踪:影响客户主数据中,在列表:“定义的限额”旁边的按钮“

”。如果希望点击这个按钮,可以显示整个信贷限额的计算过程,就需要把跟踪这个钩打上。

最大信贷限额增加:中文翻译有误,正确翻译是最大信贷限额增加的百分比。该字段用于控制可提升信贷限额的幅度,在该最大百分比幅度下可以无需批准即可调整信贷限额。对于提升信贷限额的控制只对配置点“更改信贷限额请求”中的内容起作用(主要用于对一些BADI的控制)。

如图1-3-9,为计算规则“B2B-EXIST:现有客户的规则 - 业务范围”下的分级程序。定义分级程序及相关分析结果值可在以下路径做配置:

配置路径:IMG > 财务供应链管理 > 信用管理 > 信贷风险监视 >主数据 > 定义分级程序。

另外,对于图1-3-9中相关字段的解释如下:

分级程序:外部单位提供的信用评级方法。

有效性(天数):表示被分配的评级方法在该规则中的有效天数。

ID类型:对客户信用评级时,会给客户赋予ID,ID有多中分类,需要预先选定其中一种ID类型。默认设置为空,表示ID类型是BP编号。

日志:表示在评级方法运行过程中,日志需要记录的范围。主要对应BI相关的日志,待进一步研究。

3.5 定义计算公式

TCODE: SPRO

配置路径:IMG > 财务供应链管理 > 信用管理 > 信贷风险监视 >主数据 > 定义公式

配置路径截图:

图1-3-10 定义风险评分和信贷限额确定计算公式的配置路径

配置点详解

图1-3-11 定义风险评分和信贷限额确定计算公式的配置路径

如图1-3-11,为相关公式。其中的结果类型字段就表示公式的类型,如果为LIMIT类型的就表示该公式用于计算信贷限额;如果为SCORING类型的就表示该公式用于计算风险评分。

如需编辑公式,选中需要编辑的点击该图中红框内的按钮:“

”即可进行编辑。

4.信贷组

4.1 信贷组简介

定义信贷组,可根据不同业务交易定义信贷组,比如定义订单、交货和发货三个信贷组,实现在订单、交货和发货的自动信用控制。在设置自动信贷控制的时候,是需要考虑信贷组这个维度的。

4.2 定义信贷组

TCODE: SPRO

配置路径:IMG > 财务供应链管理 > 信用管理 > 与应收账款模块和销售与分销模块的集成 > 有销售与分销的集成 > 定义信贷组

配置路径截图:

图1-4-1 定义信贷组的配置路径

配置点详解

图1-4-2 定义信贷组

如图1-4-2,为系统预设的三个信贷组。分别用于控制创建销售订单,创建交货单,交货单过账。

4.3 给信贷组分配销售凭证和交货凭证

TCODE: SPRO、OVAK(分配销售凭证用)、OVAD(分配交货凭证用)

配置路径:IMG > 财务供应链管理 > 信用管理 > 与应收账款模块和销售与分销模块的集成 > 有销售与分销的集成 > 分配销售凭证和交货凭证

配置路径截图:

图1-4-3 给信贷组分配销售和交货凭证的配置路径

配置点详解

图1-4-4 给信贷组分配销售凭证

图1-4-5 给信贷组分配交货凭证

如图1-4-4,表示给销售订单分配相应的信贷组。信贷核查表示,信贷检查的方式。值D就表示进行自动信贷控制。信贷组的值01就表示之前设置的销售订单信贷组。

如图1-4-5,表示给交货凭证分配相应的信贷组。交货信贷组就表示在创建交货单时应用的信贷组,因此分配02;GI信贷组就表示交货单发货时应用的信贷组,因此分配03。

5.自动信贷控制及检查规则

5.1 自动信贷控制与检查规则简介

自动信用控制将针对同一信用控制范围的不同的客户风险类别和信贷组执行不同的信用控制政策。对于ECC系统而言,无需单独设置检查规则,可在自动信贷控制进行设置即可,如图1-5-2。在S4 HANA版本中,自动信贷控制和检查规则是分离的,如图1-5-3。S4系统需要在定义自动信贷控制的时候,给字段“SAP信用管理”打钩,激活检查规则,然后需要单独在检查规则页签设置检查规则。接下来,我们分别介绍ECC和S4 HANA系统中两种不同配置方式。

5.2 定义自动信贷控制

TCODE: SPRO

配置路径:IMG > 财务供应链管理 > 信用管理 > 与应收账款模块和销售与分销模块的集成 > 有销售与分销的集成 > 定义自动信贷控制

配置路径截图:

图1-5-1 定义自动信贷控制的配置路径

配置点详解

图1-5-2 定义自动信贷控制ECC

如图1-5-2,先对ECC版本的自动信贷控制配置点做介绍。

无信用检查:一个例程,在什么情况下可以不做信用检查;这里用户可以自己定义例程。

项目检查:是否要在行项目输入数据时,就做信用检查,并出具信用超额的信息。

下达的单据仍然未被处理:是指被信贷冻结的单据,当冻结被释放后,如果后续对单据做一些修改,是否要重新做信贷检查;具体由以下两个字段控制。

偏差在%指单据的修改金额偏差如果在这个设定的百分比内,就不会重新做信贷检查。

天数:自单据创建到修改的间隔天数,如果超过设定值就要重新做信贷检查。如果该字段为空白,则默认天数为1天。即超过1天,就要重新做信贷检查。

信贷限额季节因子:这个可以用于短期给客户增加或者降低信贷额度,比如因为季节性的促销,可以在短期内增加客户的信贷额度。以下4个参数。

百分比:输入一个百分比,代表在原来信贷基础上,增加或者减少的百分比。

减少:如果勾选,那就是降低信贷额度,或者就增加信贷。

从:指定一个有效起始期间。

至:指定一个有效终止期间。

付款方:仅仅针对付款方的未清项目(以及催款层次执行根据未清项、最早未清项和最高催款层次的信用检查)做核查。

允许天数:允许应收账款的最长天数。

允许小时:允许应收账款的最长天数下的小时数。

静态:系统比较客户信用额度与已分配金额,如果信贷已分配金额超过信用额度,则执行响应操作。

响应操作:如果超过某一指标,应该执行什么操作。相应的值有:A=警告,B=报错,C=A+超出的值,D=B+超出的值。

冻结:表示如果超出某一指标,是否要冻结单据。

未清订单:表示静态检查需要包含未清的销售订单。

未清交货:表示静态检查需要包含未清的交货单。

动态:动态检查和静态检查类似,但会考虑展望期;而且动态检查一定会考虑未清订单和未清交货;静态检查和动态检查只能选择一个,如果勾选动态检查,需要输入展望期。

展望期:是指系统指检查这个期间内的已分配金额是否超过信贷额度,对于这个期间外的单据,不做检查;动态检查必须定期运行报表RVKRED08,以重新启用动态信用检查;

单据值&最大凭证值:针对每个单据的金额是否做信贷检查,这里需要输入一个最大凭证值;超过这个值,就做系统响应操作。

关键字段:对销售凭证中关键字段的检查,关键字段有支付条款、附加起息日、定期价值等;如果这些字段做更改,系统会响应信贷检查操作

下一校验日期:指出系统是否在下个信用评估日期的基础上执行信用检查,,如果下一个信用检查期到了却未做更改至再下一未来日期,可以决定是否信用先冻结。

天数:作为缓冲天数,比如今天是12月27号,下一个信用检查日期是12月30号。原本下一个信用检查日期没到期,如果加上缓冲天数4,那么就满足超过该指标了(27+4=31>30),系统就会做出响应。

未清项目:系统对未清项目做信贷检查,需要输入两个参数:最大未清项%和未清项目天数。

最大未清项%过期未清项目占整个未清项目的百分比,如果操作这个百分比,那就执行响应操作。

未清项目天数:未清项目过期的天数,这个是计算过期未清项目的基准,如果想对过期的未清项有个宽容期,那可用在这里输入天数。最大未清项的值虽然已经超过30%了,但是没有超过10天的宽限期。还是可以算满足条件的,系统不做出响应。

最早的未清项目&天数:系统检查对未清项目最大的过期天数,如果超过这个天数,那就执行响应操作。因此,后面要输入一个最大过期天数。

最高拖欠级: 这个和催款程序相关,在F150运行了对客户催款后,系统会在客户主记录中输入催款等级:

用户123系统预留了三个用户检查端口,用于自定义的信贷检查;分别对应程序LVKMPFZ1、LVKMPFZ2、LVKMPFZ2;用户可以自己在这里写入程序,自定义信贷检查;比如发票计划中的,如果有预付款,可以检查预付款是否收到,以决定是否发货。

 信贷检查的常用后台程序

对于做信贷检查来说,几个常用的报表必须定期在后台运行;以便及时更新系统单据的冻结状态。

1RVKRED06

这个是对冻结的单据,执行新的信用检查;比如客户前期的订单由于信用额度的原因而冻结了,本次客户及时支付了货款,那需要多这些单据重新做信用检查;系统会根据新的可分配额度,重新设定单据的冻结状态。

2RVKRED08

对展望期的信贷检查;如果设定为动态展望期,那在展望期之外的单据是不考虑的;随着时间的推移,展望期之外的单据也会进入展望期内,这时候需要对这些单据重新做信贷检查。

3RVKRED77

更新错误的信贷数据;客户信贷主数据中的信贷值、销售值可以用来判断客户的可用额度,但这个值有时候会更新错误,运行这个程序,可以重组信贷数据。

图1-5-3 定义自动信贷控制S4 HANA

如图1-5-3,现对S4 HANA系统的自动信贷控制做解释。图中单据控制

无信用检查:一个例程,在什么情况下可以不做信用检查;这里用户可以自己定义例程。

项目检查:是否要在行项目输入数据时,就做信用检查,并出具信用超额的信息。

下达的单据仍然未被处理:是指被信贷冻结的单据,当冻结被释放后,如果后续对单据做一些修改,是否要重新做信贷检查;具体由以下两个字段控制。

偏差在%指单据的修改金额偏差如果在这个设定的百分比内,就不会重新做信贷检查。

天数:自单据创建到修改的间隔天数,如果超过设定值就要重新做信贷检查。如果该字段为空白,则默认天数为1天。即超过1天,就要重新做信贷检查。

SAP信用管理:表示激活在原来ECC部分,现被迁移的其他信贷检查规则,可以在信贷检查规则配置点单独进行配置(后续会讲)。在启用SAP信用管理的时候,需要先激活信用参数文件和信用段(在第六节会讲)。

响应操作:如果超过某一指标,应该执行什么操作。相应的值有:A=警告,B=报错,C=A+超出的值,D=B+超出的值。

冻结:表示如果超出某一指标,是否要冻结单据。

5.3 定义S4信贷检查规则

TCODE: SPRO

配置路径:IMG > 财务供应链管理 > 信用管理 > 信贷风险监视 > 信贷限额检查 > 定义检查规则

配置路径截图:

图1-5-4 定义信贷检查规则的配置路径

配置点详解

图1-5-5 定义信贷检查规则-概览

图1-5-6 定义信贷检查规则-检查

图1-5-7 定义信贷检查规则-信用段

如图1-5-5所示,为本次定义的信贷检查规则,下面的系统组一般使用默认设置00或空,表示从本Client做信用检查。图1-5-6为该检查规则下的详细检查步骤。现在逐个介绍。

使计分无效并重算计分:重新对客户的风险类进行评分。

信贷风险总额统计检查:即静态信贷检查。系统比较客户信用额度与已分配金额,如果信贷已分配金额超过信用额度,则执行响应操作。如果客户信用额度未分配,会参考在信用段层级分配的信用额度。

最大凭证值的检查:针对每个单据的金额是否做信贷检查,这里需要输入一个最大凭证值;超过这个值,就做系统响应操作。

用信贷水平的动态限制检查:即动态检查,但会考虑展望期;而且动态检查会考虑未清订单和未清交货,需要输入展望期(信用有效期天数)。

最大催款等级检查:在F150运行了对客户催款后,系统会在客户主记录中输入催款等级:

陈旧未清项目的年限检查:即最早的未清项目检查,系统检查对未清项目最大的过期天数,如果超过这个天数,那就执行响应操作。因此,后面要输入一个最大过期天数。

付款行为索引的检查:检查付款未清项目(应收款)的回款天数,如果超过设定值,就会触发检查响应。

检查到期未清项目:系统对未清项目做信贷检查,需要在信用段层级输入两个参数:最大未清项%和未清项目天数,如图1-5-7。

最大未清项%过期未清项目占整个未清项目的百分比,如果操作这个百分比,那就执行响应操作。

未清项目天数:未清项目过期的天数,这个是计算过期未清项目的基准,如果想对过期的未清项有个宽容期,那可用在这里输入天数。最大未清项的值虽然已经超过30%了,但是没有超过10天的宽限期。还是可以算满足条件的,系统不做出响应。

显示信用分析者:显示信贷分析的影响因素。

6.激活信贷更新

6.1 信贷激活简介

如果在SAP中启用信贷管理功能,就需要激活信贷功能。需要激活的内容包括,给项目类别激活信贷,激活信用段功能(S4功能),激活信贷参数文件页签并分配屏幕顺序(S4功能)。

6.2 给项目类别激活信贷

TCODE: SPRO/VOV7(在项目类别层面定义)

配置路径:IMG > 财务供应链管理 > 信用管理 > 与应收账款模块和销售与分销模块的集成 > 有销售和分销的集成 > 确定每一项目类别的有效的应收款

配置路径截图:

图1-6-1 给项目类别激活信贷的配置路径

配置点详解

图1-6-2 给项目类别激活信贷

如图1-6-2,信贷激活钩打上,即表示给相应的项目类别激活了信贷功能。

6.3 激活信用参数文件页签

TCODE: BUS1

配置路径:暂未发现路径(待提供)

配置路径截图:

(None)

图1-6-3 激活信用参数文件的配置路径

配置点详解

图1-6-4 激活信用参数文件

如图1-6-4,“活动”标签处,如果打上勾,就表示已经激活了该信用参数文件。

6.4 激活信用段

TCODE: SM31( 维护表:V_TBZJ1C)

配置路径:暂未发现路径(待提供)

配置路径截图:

(None)

图1-6-5 激活信用段的配置路径

配置点详解

图1-6-6 激活信用段

如图1-6-6,“扩展活动”标签处,如果打上勾,就表示已经激活了该信用段。

6.5 激活信用屏幕顺序

TCODE: BUS6

配置路径:暂未发现路径(待提供)

配置路径截图:

(None)

图1-6-7 激活信用屏幕的配置路径

配置点详解

图1-6-8 激活信用屏幕

如图1-6-7,“屏幕”标签处,就把屏幕UKM100分配给了屏幕顺序UKM000, 然后可以再把屏幕顺序UKM000分配给屏幕顺序种类UKM000。

第二章 前台操作

1.信贷控制范围&信用段

TCODE: BP

操作路径:SAP菜单 > 后勤 > 结算管理 > 环境 > 主数据 > 维护业务伙伴

操作路径截图:

图2-1-1 给客户维护信贷控制范围的操作路径

操作详解

图2-1-2 给客户维护信贷控制范围

如图2-1-2,现对图中相应配置字段做解释。

信用控制范围:在客户主数据销售视图维护,对应销售范围为1050,00,00(已启用通用分销渠道和产品组),在“出发票”页签的信贷控制范围设置。

在销售凭证确定信贷控制范围的过程中,优先级从高到低排列依次是:销售范围+客户维度(客户主数据销售视图)、销售范围维度(后台配置)、公司代码维度(后台配置)。所以,如果要按业务对客户信贷进行管控,那就用前两种维度确定方式;如果要按公司代码或者集中式管控,那就用公司代码维度确定方式。

有时候客户也是集团公司,有付款总部,有多个售达方或者运达方;这样一个集团公司可能存在多个客户账号,也对应多个信贷账号;那客户想采用集中式管理,比如只有一个授信账号,其他客户账号共享一个信用额度;即多个客户可以对应一个信用账号。

对于ECC系统而言,可以进行以下设置满足需求:

输入Tcode:FD32,在菜单栏,点击编辑 > 修改贷方科目。

图2-1-3 给客户维护信贷控制范围

如图2-1-3设置,客户号100092,就共用了100090的信贷账号。

对于S4 HANA系统而言,需要从BP的关系那儿进行配置处理,尚待研究。

图2-1-4 给客户维护信贷控制数据

如图2-1-4,给客户主数据信贷通用数据中,维护了风险评分计算规则,以及信贷检查规则。点击计算按钮“

”即可自动计算评分,并且根据配置自动确定风险类。点击公式信息按钮“

”即可查看详细的计算规则。

图2-1-5 给客户维护信贷段数据

如图2-1-5,对客户主数据信用段1050(该信用段已分配信贷控制范围1050)做维护。信贷限额也是根据评分规则自动计算出来的,可以手动更改。1050信用段是副段,可以再维护主信用段0000,这样就可以在主信用段汇总1050信用段的信用分配发生额。

2.销售订单

TCODE: VA01, VA02, VA03

图2-2-1 对销售订单的信贷检查-更改

图2-2-2 对销售订单的信贷检查-创建

如图2-2-1,是对销售订单做更改时报的错。表示销售订单的金额已经超过信贷限额了,所以系统提示警告并将冻结该笔销售订单。如需解冻销售订单,可通过Tcode:VKM1实现。

如图2-2-2,是对销售订单做创建的时候报的错。表示销售订单的金额已经超过信贷限额了,所以系统进行报错不允许保存销售订单。

3.交货单

TCODE: VL01N, VL02N

图2-3-1 对交货单编辑的信贷检查

如图2-3-1所示,经过配置对交货单保存的时候,也会触发信贷管理检查,如果检查不合格,会有警告信息。图中报错是因为,本次后台已配置了单次交货的金额不能超过50000HKD,此次超过了,所以在保存的时候会报错。

图2-3-2 对交货单过账的信贷检查

如图2-3-2所示,经过配置对交货单过账的时候,也会触发信贷管理检查,如果检查不合格,会有警告信息,不允许过账。图中报错是因为,本次后台已配置了单次交货的金额不能超过50000HKD,此次超过了,所以不让过账。


http://www.ppmy.cn/server/167043.html

相关文章

C语言简单练习题

文章目录 练习题一、计算n的阶乘bool类型 二、计算1!2!3!...10!三、计算数组arr中的元素个数二分法查找 四、动态打印字符Sleep()ms延时函数system("cls")清屏函数 五、模拟用户登录strcmp()函数 六、猜数字小游戏产生一个随机数randsrandRAND_MAX时间戳time() 示例 …

Deepseek使用途径以及Prompt 提示词编写原理

Deepseek使用途径以及Prompt 提示词编写原理 1.Deepseek使⽤途径 1.官⽹及APP ⽹址: deepseek.com 及移动应⽤(iOS/Android) 特征:完整版R1模型,⽀持深度搜索,但⽬前因流量⼤常遇到服务器繁忙问题。 2.…

PCM与G711A互转

PCM与G711A互转 工具类(Java)调用方法(Kotlin) 工具类(Java) public class G711Code {private final static int SIGN_BIT 0x80;private final static int QUANT_MASK 0xf;private final static int SEG…

ZooKeeper 的典型应用场景:从概念到实践

引言 在分布式系统的生态中,ZooKeeper 作为一个协调服务框架,扮演着至关重要的角色。它的设计目的是提供一个简单高效的解决方案来处理分布式系统中常见的协调问题。本文将详细探讨 ZooKeeper 的典型应用场景,包括但不限于配置管理、命名服务…

机器学习数学公式推导笔记

正定方程是凸函数证明 范数 向量的范数与内积 范数例子

Spring Boot 3.4 中 MockMvcTester 的新特性解析

引言 在 Spring Boot 3.4 版本中,引入了一个全新的 MockMvcTester 类,使 MockMvc 测试可以直接支持 AssertJ 断言。本文将深入探讨这一新特性,分析它如何优化 MockMvc 测试并提升测试的可读性。 Spring MVC 示例 为了演示 MockMvcTester 的…

【含文档+PPT+源码】基于python爬虫的豆瓣电影、音乐、图书数据分析系统

项目介绍 本课程演示的是一款基于python爬虫的豆瓣电影、音乐、图书数据分析系统,主要针对计算机相关专业的正在做毕设的学生与需要项目实战练习的 Python学习者。 1.包含:项目源码、项目文档、数据库脚本、软件工具等所有资料 2.带你从零开始部署运行…

将DeepSeek接入Excel实现交互式对话

引言 将DeepSeek接入Excel,为你带来前所未有的交互体验!“哪里不懂,选中哪里”,然后直接在侧边栏对话框向DeepSeek发问,非常地方便! 案例演示 设置接入方式 既可以通过本地部署的DeepSeek接入Excel&#…