为了降低企业在实际业务中的
目前成都创新互联已为上1000+的企业提供了网站建设、域名、雅安服务器托管、网站托管、服务器托管、企业网站设计、米林网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
信贷风险，SAP系统提供了一个复杂的信贷管理解决方案，当客户超过它的信贷许可范围时，系统能够做出迅速而有效的反应。如下图所示显示了SAP系统中一个客户的信贷管理信息。
同一个企业所有客户的信贷管理信息是以信用主数据的方式维护到系统中的，完全实现了客户信贷管理信息的共享。而且每一个客户的信贷管理信息随着对其销售业务的开展，系统能够实现及时动态更新。SAP系统对客户信贷管理信息的及时动态更新，以及信贷控制策略的实现是通过SAP系统的后台配置完成的。在这里针对不同信贷控制范围、不同风险类别、不同信贷组的组合进行详细的信贷控制设置，以实现企业的信贷控制策略。
1.定义信贷控制范围。
信贷控制范围是SAP销售和应收账款模块中用于控制信用风险的组织机构。系统配置的后台路径为：企业结构=定义= gt;财务会计=定义信贷控制范围及组织值事例。为了提高工作效率，建议在“信贷控制范围明细项”里面维护客户信用主数据的默认值，实现在创建客户主数据时自动创建该客户的信用主数据。这样只需对不同风险类别的客户和授信客户的信贷限额进行维护。
2.给公司代码分配信贷控制范围。
根据不同的产品，不同的销售方式，一个公司代码可以有多个信贷控制范围。同时一个信贷控制范围也可以分配给多个公司代码，比如，集团公司的一个客户可以有一个总的信用限额，而在各个信贷控制范围内又可以设定该信贷控制范围内的信用限额。系统配置的后台路径为：财务会计=应收账目和应付账目=信用管理=信用控制会计科目=分配允许的信用控制范围给公司代码及组织值事例。
3.给销售范围分配信贷控制范围。
销售组织、分销渠道和产品组三者之间的有机组合构成一个销售范围。销售范围反应了一个企业不同的产品以及不同的销售方式的组合，一个信贷控制范围可以分配多个销售范围，一个销售范围只能分配给一个信贷控制范围，信贷控制范围和销售范围之间是一对多的关系。系统配置的后台路径为：企业结构=分配=销售分销=分配贷款控制范围的销售范围及组织值事例。
4.定义风险类别。
风险类别可以理解为风险等级，首先对客户区分不同的风险类别，然后针对不同的风险类别可以执行不同的信贷政策。系统配置的后台路径为：财务会计=应收账目和应付账目=信用管理=信用控制会计科目=定义风险类别及组织值事例。
5.定义信贷组。
信贷组可以理解为对信贷控制区分不同的控制环节，信贷控制一般可以在三个业务环节进行：销售订单、交货和发货过账。系统配置的后台路径为：销售分销=基本功能=信贷管理/风险管理=信贷管理=定义信贷组及组织值事例。
6.定义进行信贷控制的定价过程。
这一项主要是对包含哪些价格条件类型的值进行信贷控制。关键是需要对进行信贷控制的价格条件类型设置相应的标志，将需要控制的价格转到贷方价格。具体系统配置的后台路径为：销售分销=基本功能=信贷管理/风险管理=信贷管理/风险管理设置= gt;输入设置。
7.激活项目类别的信贷更新。
这一配置在项目类别层次控制实际的销售业务数据是否更新信贷总额。要实现客户信贷及时动态更新，需将相应销售单据类型的活跃信贷选中。系统配置的后台路径为：销售分销=基本功能=信贷管理/风险管理=信贷管理/风险管理设置=确定每一项目类别的有效的应收款及组织值事例。
8.给销售凭证和交货凭证分配信贷组和信贷控制方式。
通过这一配置实现了不同类型的销售订单和交货单与信贷组及系统信用控制的结合。
9.定义自动信贷控制。
在这里定义具体的怎样执行信贷控制，反映了一个企业的基本信贷政策。系统配置的后台路径为：销售分销=基本功能=信贷管理/风险管理=信贷管理=定义自动信贷控制及组织值事例。
SAP中的信用控制可以实现分公司代码、分销售范围、分不同风险类别的客户、分单据类型的控制。要实现信用控制，还需要首先对要进行信贷控制的定价过程做定义，其次是要激活项目类别的信贷控制。信贷控制范围的确定一般有四个层次：公司代码、销售范围、客户主数据以及用户出口，四者的优先级依次升高。
SAP系统的信用管理功能非常强大，而在销售管理过程中，信用管理也是主要的内部控制点，为此建议将风险类别按低、中、高划分成三个等级，按客户的信用状况，将客户划分成低风险客户、中风险客户、高风险客户，对客户实行分级管理。
在信用控制策略上，对不同的信贷控制范围，实现销售订单级的控制即可。对于低风险客户，当超信贷限额时，系统只是警告一下，不影响业务操作；对于中风险客户，当超信贷限额时，订单将会被冻结，后续的业务无法继续进行，经过相应的审批，将被冻结的订单释放后才能进行后续操作；而对于高风险客户，当超信贷限额时，订单根本无法保存。
为了保证创建新客户时同时创建该客户的信用主数据，建议通过系统配置实现创建客户主数据时自动创建该客户的信用主数据。
在具体实现策略方面，建议将内部客户维护成低风险客户，将外部客户维护成中风险或高风险客户。对需要授信的客户，由企业信用管理小组根据客户信用状况给予一定的授信额度，从而实现SAP系统对内控的有效支撑。
前台操作：
1、FD32
SAP系统对客户信贷管理信息的及时动态更新，以及信贷控制
策略的实现是通过SAP系统的后台配置完成的。在这里针对不同信贷控制范围、不同风险
类别、不同信贷组的组合进行详细的信贷控制设置，以实现企业的信贷控制策略。
2、SAP FD33 客户信贷数据解析事务代码FD32/FD33，输入customer（购货方编号）和credit control area（信贷控制范围），选择Status（状态），回车。
查看到的几个字段的理解如下：
Credit exposure（信贷风险总额）= receivables（应收总额） + special liabilities（特别往来债务） + sales value（销售值）。其中：
应收总额：指出具了发票的总金额扣减顾客付款之后的应收帐款余额；
特别往来债务：一般是预收款（customer down payment）。没有交货就预先收款，财务上当然视为我方债务，由于是债务，这个字段永远以负值表示；
销售值：sales value应理解为open sales value，并不是会计意义上的“因为开具发票而实现的销售收入”。在完整信用管理场景下，销售值可理解如下：
open sales value＝open order value + open delivery value + open billing value；
open order value：建立了销售订单，但尚未交付的价值；
open delivery value：建立了出埠交付单（outbound delivery note），但尚未出具发票的价值。“交付”以VL01N创建交付单为唯一标志，与是否过账出货无关；
open billing value：出具了发票，但没有生成会计凭证的价值。
open order value记录于S066-OEIKW，open delivery value记录于S067-OLIKW，open billing value记录于S067-OFAKW。
如果对credit exposure或者其三个细目的余额有疑问，可以用SE38调用标准程式RVKRED77运行有关的信用账户，刷新后再重新进入FD33观察。
出现不一致的情况请查询note，采用补充程序进行纠正。
注：改表改变不了实质，应补充完整的实际业务。
信贷数据不正确，请参考SAP notes: 1756125 - Wrong credit values - identify and correct
常见问题
1、我已经在OVAK和OVA8里面设置销售订单不进行信用检查了，为什么S066还更新未清订单信贷值？
再次强调，信用更新和信用检查是两个过程，您需要检查VOV7或者OVA7，项目“活跃信贷”是否被选择上了。
2、我已经设定VOV7里面“活跃信贷”为”X”了，为什么保存销售订单以后FD33看到未清订单信贷值没有更新？
请检查以下几项：
1.销售订单明细的VBAP-CMPRE是否有值，如果没有，请参照Note 18613在V/08维护销售价格;
2.销售订单明细计划行里是否有确定的数量；
3.OB45更新组是否选择了000015；
4.OMO1对信息结构S066的更新时间是否设置了同步更新。
3、FD33里面的销售值不正确应该怎么办？
首先报表RVKRED88可以用来检查到底销售值是否正确。
3.1 FD33-输入客户和贷方控制范围-查看状态-附加-销售值-记录以下项目值
未清订单信贷值
未清交货信贷值
未清开票凭证
3.2 SE38-RVKRED88-输入客户和贷方控制范围-执行（F8）-
对比执行结果和FD33是否一致
RVKRED88是重新进行信用更新会得到的值，所以如果以上不一致的时候，需要执行报表RVKRED77来修正数据库值。
此报表执行的时候需要没有user在系统上进行操作，因为需要冻结VBAK,VBAP等表格以保证系统数据的一致性。
请不要中途终止RVKRED77，这样会导致系统里的信用值不正确。
具体请参照SAP NOTE 716141。
4、FI SD显示预付款不一致
SD这边，客户A在FD33中显示的特别往来债务（即预付款）为2344.38，
FI这边，客户A在FD10N中显示的预付定金是30174.38；
这两个数据正常情况下是一样的，就只有这个客户A是不一样。经过排查，财务那边是对的，SD那边是错的，但找不到原因，请问有哪些可能的原因？
解决办法：
用F.28更新重置信贷数据后就可以了
信贷检查的常用后台程序
对于做信贷检查来说，几个常用的报表必须定期在后台运行；以便及时更新系统单据的冻结状态；
1、RVKRED06；检查被冻结的销售文档（销售订单、交货单）
这个是对冻结的单据，执行新的信用检查；比如客户前期的订单由于信用额度的原因而冻结了，本次客户及时支付了货款，那需要多这些单据重新做信用检查；系统会根据新的可分配额度，重新设定单据的冻结状态；
2、RVKRED08；检查低于信用限额的销售温度（销售订单、交货单）
对展望期的信贷检查；如果设定为动态展望期，那在展望期之外的单据是不考虑的；随着时间的推移，展望期之外的单据也会进入展望期内，这时候需要对这些单据重新做信贷检查；
3、RVKRED77；更新销售模块的信用数据
更新错误的信贷数据；客户信贷主数据中的信贷值、销售值用来判断客户的可用额度，但这个值有时候会更新错误；运行这个程序，可以重组信贷数据；
4、RVKRED09 检查正在后台处理的销售文档（销售订单、交货单）
5、RVKRED88 模拟更新后销售模块的信用数据
6、RFDKLI120 重新设置客户的信用限额
7、RFDKLI150 批量更改信用限额数据
RFDKLI10 搜索无信贷限制的客户
RFDKLI20 为选定的信贷控制范围重新设置信贷限额
RFDKLI30 汇总信贷限额概览。该程序为每个客户列出主要的和控制范围
RFDKLI40 信贷限额概览 (扩展的)
RFDKLI41 信贷主表
RFDKLI50 批量变更
RFDKLIAB 跨帐目变更显示
qq出售
精选推荐
广告

SAP 动态信贷管理
36下载·2评论
2012年6月11日
sap客户信贷_SAP信贷控制功能与配置详解
917阅读·0评论·0点赞
2020年12月19日
sap客户信贷_SAP SD 信贷控制范围-特别总账控制的信贷更新
1151阅读·0评论·0点赞
2020年12月19日
SAP中FI信贷额度FD32设置
4854阅读·0评论·0点赞
2016年12月27日
SAP SD 客户信贷管理解析
2030阅读·0评论·0点赞
2020年1月26日
sap客户信贷_FD32维护客户信贷数据
1291阅读·0评论·0点赞
2020年12月19日
高清播放机，图片大全，点击查看详情！

精选推荐
广告
sap客户信贷_012 【基础配置】信贷重组及S/4 HANA 信贷管理
2742阅读·0评论·1点赞
2020年12月31日
Credit Management(SD)
270阅读·0评论·0点赞
2015年4月24日
SAP SD：SAP信贷出口
1523阅读·0评论·1点赞
2017年9月5日
sap客户信贷_SAP 客户信贷重建一则
66阅读·0评论·0点赞
2020年12月19日
SAPS4HANA信用管理信贷配置手册v1.2.docx
5下载·0评论
2020年11月19日
SAP SD信贷管控
30下载·0评论
2018年7月26日
定义拒绝原因
1583阅读·0评论·1点赞
2017年8月2日
SAP 从零起步之 1.4 创建信贷控制范围
451阅读·0评论·0点赞
2022年4月24日
sap客户信贷_企业客户信用控制管理机制实践（2/2）
1518阅读·0评论·0点赞
2020年12月31日
sap客户信贷_信贷控制配置全过程-SAP
1341阅读·0评论·1点赞
2020年12月19日
SAP SD基础知识之信用控制范围
2759阅读·0评论·0点赞
2020年2月13日
sap信贷管理的操作流程
899阅读·0评论·0点赞
2021年12月31日
sap客户信贷_信贷控制，FD32的销售值不会变化，只有应收总额的变化
342阅读·0评论·0点赞
2021年2月11日
FD32 查询客户信贷管理中，销售值是怎么来的？
5767阅读·0评论·1点赞
2016年3月15日
在SAP财务处理中，对个人借款之类的账务处理操作是：
1、打开财务软件，点击凭证录入；
2、在记账凭证直接录入会计分录：
借：其他应收款-个人
贷：现金/银行存款
3、其他应收款是企业应收款项的另一重要组成部分。其他应收款科目核算企业除买入返售金融资产、应收票据、应收账款、预付账款、应收股利、应收利息、应收代位追偿款、应收分保账款、应收分保合同准其他应收款备金、长期应收款等以外的其他各种应收及暂付款项。 其他应收款通常包括暂付款，是指企业在商品交易业务以外发生的各种应收、暂付款项。
有个查科目余额试算表的代码，有期初、本期借贷发生额、期末余额的，你用FS10N 试下。
一、前台事务T-code方式
前台事务T-code方式的优点是基于系统标准功能，用户基本可以自行完成操作。其不足是报表清单功能比较简单，局限性很大，在输出字段，格式，选择条件等方面可供选择项很少，难以满足定制清单的输出需求。在实际的应用中用于查询多过用于输出。
二、BW方式
概念上可以自行搜索，笔者描述可能并不太准确。精略的讲，BW相当于是独立于SAP系统的一套数据库工具，其应用原理是访问SAP数据库，并将SAP中的数据进行提取，组织，加工，输出。BW可以弥补SAP标准报表功能的不足，符合逻辑的数据输出需求几乎都能满足。这是BW的优点。但BW需要先设计，再应用。不可能满足短期需求。所以，如果公司有上线BW系统，做为关键用户，在上线阶段，需要认真梳理和提出业务需求。当然，业务和需求会变化，二次开发也是可行的。操作上，BW由于是另一套系统，运行时需要开启单独的应用程序，用户账号可是基于BW的，与SAP系统独立开来。
