对销售模块的几点认识.doc

对销售模块的几点认识采购的特点是供应商数量少，同时每个供应商的物料价格质量各不相同。而销售的特点则是客户数量很多，销售价格相对单一，所以销售模块中并不需要类似采购信息记录、货源清单、配额协议功能的主数据。一、物料主数据图1-1 销售单位和MM模块中的采购单位功能类似，也可以采用固定转换系数和变动转换系数，在此不再重复。图1-2 交货工厂和MM模块中不同的是，这里可以指定交货工厂。假如企业为了更好地分析控制成本在系统中创建半成品工厂、成品工厂，这时可以将交货工厂设置为成品工厂。或者企业有销售公司和生产公司之分，需要将交货工厂设置为生产公司下的工厂，这就形成了公司间销售。值得注意的是：ECC系统中创建的工厂并不一定要对应一个实体工厂，可以为了财务核算的方便一个实体工厂下创建多个逻辑工厂。图1-3 物料组期末报表分析用的，也可以作为条件控制采购事务图1-4 最小订单数量产品一般都是卖给大客户的，有个小客户跑来要个几百台，对不起，少于一千台无法创建订单。图1-5 最小交货数量销售人员创建了一张一千台的销售订单，跑到仓库去提货。仓库的兄弟说：这仓库有好几千平方米，货都堆得那么高，你上午要一千台，下午要两千台，我还不累死。对不起，少于五千台不发货。图1-6 交货单位发货时用了集装箱，每一千台一箱，这时交货单位就成了箱。图1-7 取整参数来了张销售订单需要5100台，四舍五入，就发5000台吧。销售把订单改成5600台，四舍五入后发6000台。当然取整参数的定义很丰富，这里不详解了。图2为销售的组织数据2，可以看出这个界面定义的大多是关键字，用于确定销售事务中的程序选择的。图2-1 统计组可以创建一个信息结构，在平时发生业务数据时自动将表中的数据处理后传送到信息结构，这样期末可以直接对信息结构进行分析。减轻了期末分析的工作量，提高了软件的性能。统计组即决定哪些信息需要传送到信息结构中的。图2-2 物料定价组和客户定价组一起确定定价程序，和MM模块中计算方案的概念类似。图2-3 量回扣组 用于确定给予客户的回扣。图2-4 账户分配组用于确定后台过账的账户，会在后面详细讨论。图2-5 一般项目类别组图2-6 项目类别组用于确定销售订单中的项目类别，会在后面详细讨论。图3为销售的一般/工厂数据图3-1 可用性检查成品销售出库需要作一个检查，看是否有足够的库存，所以SAP采用了可用性检查这个功能。可用性检查的定义参数非常丰富，这里不详解了。图3-2 运输组和运输路线相关。图3-3 装载组会和供应商主数据中的装运条件一起确定一个装运点，主要用在交货功能上。图101为K3的物料主数据的物料资料界面。可以看到物料主数据中销售相关的参数非常少，再回顾下ECC中物料主数据的设置，大多和交货类型有关，而K3并没有交货类型这个概念，只有简单的出库功能。图101-1 是否需要进行订补货计划的运算和ECC中的可用性检查类似，但是只有一个简单的控制开关图101-2 销售超交/欠交比例类似于ECC中的交货容差功能二、客户主数据图4-1 业务合作伙伴ECC中扩展了客户的概念，将其命名为业务合作伙伴。在实际的业务模型中，客户很有很多种角色：收货人、收票人、付款人等等，这时ECC的合作伙伴功能起了很大的作用，可以分别设置一个客户的收货人、收票人、付款人。还有其他很多的扩展概念，在此不详解图5为客户主数据创建的初始界面图5-1 销售区域ECC中有销售组织、销售渠道、产品组的概念。举一个业务模型为例：一个家电集团会有国内销售部和海外销售部，销售渠道会有零售渠道和大客户销售渠道两个部分，产品组则会有白家电和黑家电之分，这时可以自由组合销售组织、销售渠道、产品组为销售区域。比如国内销售部-零售渠道-白家电定为销售区域1，国内销售部-大客户销售渠道-黑家点定位销售区域2，总之三个条件可以自由组合。不同的销售区域可以设置客户的不同参数。图6为客户主数据公司视图下控制数据界面，值得注意的是客户主数据的销售视图并没有付款条件，这和供应商主数据的采购视图有所不同，客户主数据中只是财务视图才有付款条件。在客户主数据的销售区域视图中还会有一个装运条件。发货工厂装运条件（客户主数据销售区域视图装运)+装载组（物料主数据销售视图）可以唯一确定一个发运点。这也和交货的概念有关。图6-1 供应商一个公司下有很多工厂，工厂之间会有很多关联交易。可以为收货工厂创建一个客户，为交货工厂创建一个供应商，为财务的期末清帐提供了方便。图6-2 权限权限控制所用图6-3 运输区域用于交货时运输路线的确定图K02是K3的客户主数据的屏幕，相对比较简单。关于详细信息可以参考SAP ECC 6.0的MM模块和金蝶k3 V11相关模块的对比相关部分。图K02-1 参数设置在K3的很多主数据都出现了这样一个子屏幕，它的功能相当于SAP的屏幕格式+字段选择+消息设置（非消息输出，而是SAP控制程序运行的一个方式）等，建议在参数设置子屏幕中再进行细分。图K02-2 应收应付资料列出了结算方式、现金账户号码、收款条件等信息。三、其他主数据图7为销售的主数据列表，还有产品组、条件、消息输入、协议等，限于篇幅在这里不再一一讨论。ECC的SD模块和K3相关模块的对比（2）-销售凭证销售凭证的类型有很多，常用的有询价、报价、销售订单等等，值得注意的使SD模块中并没有类似采购申请的概念。想想也是，客户跟你买东西还要申请，也太牛了吧。值得注意的是，和MM模块不同，SD模块中的询价和报价是经常用到的。采购的供应商一般是相对稳定和长期合作的，不用询价和报价直接手工输入就可以了，所以采购中特别设置了采购信息记录这个主数据来作一个权限控制和流程节点。而销售则大不相同，客户繁多而复杂，询价和报价相对频繁，而且可以设置销售订单必须参考报价创建，这样可以把报价功能和销售功能分开，达到一个权限控制和流程节点的目的。由于篇幅的限制，下面只着重讨论销售订单。图8为销售凭证的类型定义，抬头的名称为maintain sales order，是SAP的一个小失误。在这里我们可以看出销售凭证全部放在一起维护，而且凭证类型要多得多，这和采购凭证的配置有很大的不同。在实际的业务中，销售需要面对各种各样数量庞大的客户，而采购需要面对的供应商相对简单，销售中的询价报价会非常的频繁，而采购则要少得多。所以SAP将这些凭证放在一个界面中进行配置。图8-1 滚动条看那滚动条可以拉那么长。看来预定义的凭证类型真的很多呵呵图9为一个销售凭证类型为标准销售订单的定义界面图9-1 销售凭证类别销售凭证一般有如下类别：销售订单、询价、报价、计划协议等等。在销售订单里当然选销售订单的类别了。在这里SAP有一个重要的设计思想就是将对象的大类设为类别，通过类别控制大方向，然后在类别中再细分为类型，控制小方向。这样的层次结构清晰，易于维护。图9-2 销售凭证冻结可以选择不冻结、只能参考创建、冻结三个标识。如果自定义了一个销售凭证，以后又不用了，就把它冻结。图9-3 强制参考这个功能非常的有用。假如一个大的集团，一线的销售人员因为种种原因经常杀价销售，搞得公司无利可图，这时可以设置专门报价的人员，在系统中创建报价单，然后销售人员的订单只能参考这个报价单创建，无法自定义价格。图9-4 读取信息记录看到这个标识的那一刻我糊涂了，莫非SD中也有类似采购信息记录的功能？再仔细看看，还是我没记错，这里的信息记录只是一个简单的参数控制功能，和采购信息记录相比没有定价条件，只是单纯地控制一些交货信息，不具备价格控制的功能。所以SAP也没有称之为销售信息记录，而用了客户-物料信息记录这样的名称。图9-5 检查信贷限制设置这个类型的销售订单必须检查客户的信贷状况，这个功能会在后面详细讨论。图9-6 信贷组控制信息的更新图9-7 不完整检查控制那些字段是必须输入的。可以灵活地用在权限控制上。图9-8 凭证定价过程就是给这个凭证类型一个标记，会和客户中的一个标记一起决定销售订单的价格计算方案。SAP给采购中的计算方案换了个马甲叫定价过程，其实是一个概念。图9-9 状态参数文件这个是用作审批的功能，会在后面详细讨论。图10依然为一个销售凭证类型为标准销售订单的定义界面，只是滚动条太长，一张图截不下，所以继续截。图10-1 交货类型定义销售凭证的后续交货类型图10-2 立即交货有些客户是长期而稳定的合作关系，而且对供应链的响应速度要求很好。设想下，客户那里跑MRP出来的采购订单，你收到采购订单后不紧不慢地慢慢创建销售订单、审批，再手工建交货单，肯定是不合适的。所以可以设置销售订单建好后就立刻自动创建发货订单。图10-3 交货冻结交货就是要把货往客户那里送了，收到货后客户才付钱，所以在交货前先冻结检查下。图10-4 交货相关的开票类型一个标准的流程是先创建销售订单，再参照销售订单创建交货单，再根据交货单开票。这里设置根据交货单开票的类型。图10-5 订单相关的开票类型设想这个一个业务场景：客户来了张大单，这时不能一次发完，只好分几批交货，这时参照交货单开票不太合适了，就直接按照销售订单来开票。这里设置根据订单开票的类型。图10-6 跨公司的开票类型一个大集团下会有很多家公司，公司间会有关联交易，这时可以配置跨公司销售。跨公司的开票类型就用在这里。跨公司的销售我们以后再讨论吧，要详细的写出来估计WORD文档要写上几十页。图10-7 开票冻结控制一些状况下自动冻结开票。图12为销售订单的概览界面图12-1 售达方/送达方前面我们曾经提到过客户会有很多种角色：售达方、送达方、收票方等等。集团一般会集中采购，再分发给下属的公司，所以售达方和送达方会经常性的不同。SAP干脆将它列在了销售订单的界面上。图12-2 交货日期图12-3 交货工厂图12-4 交货冻结图12-5 开票冻结图12-6 付款条件自动从供应商主数据中带出图12-7 销售区域在销售订单创建的初始界面选择图12-8 订单数量图13为销售订单的项目概览的视图，这和采购订单有所不同。图13-1 项目概览图13-2 项目细节图14为销售订单的项目列表的视图，SAP将其定义为项目细节，其实这个视图并不是项目的细节，而只是一个项目的简单罗列而已。图14-1 项目类别用于控制后续的计划行类别，会在后面详细讨论。图14-2 定价日期和采购中定价日期的概念类似图15是真正的项目细节的视图图15-1 销售A显示交货数量、定价日期、净价等信息图15-2 销售B定价确定和统计分析的字段设置图15-3 装运设置货物装运的信息图15-4 开票凭证开票凭证的参数设置，大多自动带出。图15-5 条件显示条件定价的信息图15-6 账户分配用作成本核算的利润分析和业务范围，和CO的概念相关，不详细讨论了。图15-7计划行交货的计划行，一般用在参照计划协议创建的销售订单。图15-8 合作伙伴自动带出客户主数据中设置的合作伙伴参数图15-9 状态销售订单的状态，常用的有创建、已审批。图15-10 附加数据销售分析报表所用图K03为K3销售订单的处理界面，可以看到功能相对简单，包含创建、修改、报表、进度查询等功能。图K03-1 销售订单-新增图K03-2 销售订单-维护图K04为销售订单的创建界面图K04-1 销售范围有模仿SAP的痕迹，但只是简单的一个字段定义，只能在报表选择的时候才能发挥点作用了。图K04-2 销售方式指定销售方式，常用的有现金销售、赊销等等。图K04-3 结算方式指定结算方式，常用的有现金、汇票等。图K04-4 交货方式因为K3并没有后勤执行相关的模块，所以在这里简单地设置了这个字段来表示交货的方式，常用的有FOB和送货等。图K04-5 交货地点类似于SAP装运点的概念，因为没有WM模块，只好设置到工厂一级。图K04-6 源单类型指定销售订单参考创建的凭证类型图K04-7 单价手动输入物料的销售单价图K04-8 含税单价需要手动输入税。可以看出未采用条件定价的缺点。由于无法灵活地集中设置价格，销售订单的价格管控乏力。图K04-9 审核简单的审批功能，可以看出K3内置了固定的三级审批。图K05依然是销售订单的创建界面，只是下面的滚动条向右拉动了1/3左右，剩下的1/3下面接着讲。因为没有子屏幕和后续屏幕的设计，所有的字段都挨在了一起，不美观，略显凌乱。图K05-1 税率图K05-2 折扣率由此看出，K3内置了最基本的定价元素，包括物料价格、税、折扣率等。图K05-3 折扣额根据图K05-2 折扣率算出图K05-4 交货日期设定交货的日期，交货功能的简单字段设置图K05-5 出库数量记录每次交货后的累计交货量。图K06是销售订单的创建界面剩下的1/3，滚动条终于拉完了图K06-1 辅助单位关联数量仓库中可能不按基本单位或销售单位来计算，而按托盘这样的存储单位计算，这就是记录存储单位的数量图K06-2辅助单位关联数量出库数量后面是生产和成本核算相关的字段，将在SAP ECC 6.0的PP模块和金蝶K3 V11相关模块的对比和SAP ECC 6.0的CO模块和金蝶K3 V11相关模块的对比中详细讨论ECC的SD模块和K3相关模块的对比（3）-交货交货的概念严格来说应该是WMS中的，ERP的中文翻译是企业资源计划，所以ERP在库存方面只需记一个出库入库就可以了。事实上国内erp都是如此设计的。现在我们来看一个业务模型：某跨国集团在全球范围内优化配置资源，客户和供应商遍布全球各大洲，货物的运输动辄需要几十天。这个时候光一个出库入库控制肯定是不行的，对交货这个过程的控制是非常有必要的。对于采购模块，SAP设计了内向交货这个概念，内向交货可以参考采购订单建立，详细记录到货的时间。对于销售模块，SAP设计了外向交货这个概念。外向交货参考销售订单建立。对于交货的功能SAP将其集成在了LE模块中，将其与仓库管理结合在一起，可以确定装运地点、运输路线等等。对于国内企业来讲，大多没有使用仓库管理模块。为什么不用？国内企业大多处于微笑曲线的下游，利润率较低，买个SAP玩玩就已经很不容易了，而且要想用好WM模块，必须建设高标准的自动化仓库，华为就建了一个，花了3000万美元，折合人民币2亿多，这个数字超过国内大部分企业的年净利润了。国内企业没有使用WM模块，这样物料的管理不能完全实现自动化，而SAP的流程设计是建立在用户使用了WM模块的基础上的，这样就带来了很多不适，简称水土不服。关于SAP流程和WM模块的关系，会在ECC的PP模块和K3相关模块对比中进行讨论。SAP销售的财务处理流程如下：先发货过账，根据物料的标准价或移动平均价产生交货成本，再开票根据销售订单中的条件定价产生对客户的应收。国内企业大多只使用了SD模块中交货的最基本的财务过账功能，所以这里也就简略地讨论下交货的基本创建界面的信息，关于财务过账功能，会在后面详细讨论。图20为SAP后勤执行模块的后台配置菜单，下次有时间再详细讨论，先来看看传说中的LE模块长什么样。图20-1 仓库管理企业仓库内部的设计图20-2 装运货物从仓库哪个地方出，哪个地方进，如何装货、怎么包装等等图20-3 运输货物除了仓库后选哪条运输路线，具体怎么个运法。图21为外向交货创建的概览界面。看着挺熟悉，好像在那个地方见过原来和图13的销售订单创建界面差不多，由此可以看出，SD模块和LE模块是SAP同一个团队设计开发的。图21-1 项目概览图21-2 拣配图21-3 装载拣配和包装完成后的一个动作。图21-4 运输图21-5 状态概览监控货运发运的状态，就是看看发货过程到哪一步了。图21-6 货物移动数据记录货物的移动类型等数据。图22为交货的项目细节界面，和SD的销售订单项目细节界面也挺像的，我就说嘛，肯定是同一个团队设计开发的。图22-1 处理我们知道交货一般会有如下步骤：拣配-仓库内取出-包装-发货过账这么几个步骤，可以灵活选取其中的几个步骤。还有质量检查数据，有些企业喜欢在出货前先进行质检，的确是那种把产品质量看成生命的角色，国内企业一般无此习惯。图22-2 物料记录下生产相关的数据，以及运输组合装载组，用于确定后面的运输路线和装运点。图22-3 批次分割企业的生产往往会有很多批次，一次发货可以一个批次不够，需要几个批次，这里就记录批次的信息。图22-4 拣配拣配相关信息都在其中图22-5 装载和装运包含了装载和送达方的信息。图22-6 财务处理包含了开票、利润中心、业务范围等信息。图22-7 条件记录从销售订单带来的条件定价的信息。K3并没有类似后勤执行模块的功能，没有交货过程的管控功能。ECC的SD模块和K3相关模块的对比（4）-开票图23为SD模块中的开票功能的后台配置界面，可以看出开票功能有这么几种：标准开票、跨公司销售开票、自动开票。图23-1 开票凭证会在下面详细讨论图23-2 跨公司开票限于篇幅暂不讨论图23-3 开票计划限于篇幅暂不讨论图24为开票凭证类型定义的初始界面，可以看出其设计逻辑和销售凭证类型定义相似。图25为开票凭证类型定义的界面，这里我们依然选取标准的，即F1类型的开票凭证类型为例。图25-1 项目号码增量指定项目号码以多少间隔增加图25-2 SD凭证类别和销售凭证类别的作用类似图25-3 事务组定义凭证类型允许的事务，并作为报表分析的选择字段。图25-4 开票凭证类别定义开票的发票类别，有预付要求、开票要求等图25-5 凭证类型控制后续的会计凭证类型图25-6 负过账指定该类型的凭证能否冲销，如果不允许冲销，则需要配置一个反向的凭证类型。图25-7 分支/总部前面我们提到，有这样的业务模型：总部统一采购，作为付款方，分发给下面的公司，下面的公司作为送达方。那么开票的时候应该开给总部。这里的选项就是为了满足类似的需求。图25-8 带值日期的贷项凭证用于贷项凭证类型的设置中，这里不详细讨论。图25-9 发票清单类型设想这样一个业务模型：一个客户短时间下了多个订单，开票参照销售订单创建，或者一个销售订单多次交货，开票参照交货单创建，这时就需要发票清单这样的功能来为多次业务开一张发票。发票清单类型控制发票清单的一些参数，这里限于篇幅，不详细讨论。图25-10 回扣处理指定回扣协议中规定的回扣的处理方式，一般在贷项凭证类型中设置。图25-11 取消凭证类型回顾图25-6中的设置，如果不允许冲销原凭证，则需要在此配置一个反向的凭证类型。图25-12 复制要求将在后面的复制控制中讨论。图25为竖型滚动条往下拉后剩下的开票凭证类型定义的界面图25-1 账户分配/定价指定账户确定程序和凭证定价过程图25-2 输出/合作伙伴/文本指定消息输出确定过程、项目输出过程、输出类型、抬头合作伙伴、项目合作伙伴、文本确定程序等参数。这里的消息输出功能和MM模块中的消息输出功能类似，但是SAP为了应对销售的复杂性，设计更多的消息输出条件技术，比如不光凭证可以作消息输出，连凭证的项目都可以作消息输出，的确是做得非常的仔细和认真。对于消息输入过程这里不再敷述。图27为发票的概览界面，非常的简洁明了。因为业务的处理和统计信息在销售凭证和交货凭证中已经处理和记录，这里要做的只是根据销售凭证和交换凭证汇总的结果开个票而已。图28为发票的项目细节界面，记录了销售凭证和交货凭证中信息的汇总。图K07是K3的销售发票创建界面图K07-1 源单类型指定参考的凭证类型，典型的有销售订单和销售出库。这里K3为了记录交货后产生的成本，设计了销售出库的凭证。这样的流程设计对于企业不负责货物运输的业务场景是没有问题的，单是对于企业负责货物运输的业务场景是有很大的漏洞的。假设企业货已出库，但是在客户收到确认以前，所有权还在企业这里，运输途中发生意外或者企业收货时对数量或者品质存有争议，而出库的期末存货已经核算，这时就产生帐实不符，还需要重新调整。图K07-2 选单号因为没有SAP复制控制类似的功能，所以K3只能选择一个参考凭证号，对于发票参考多个交货凭证或多个销售凭证创建的业务需求难以满足。而实际上多交货凭证或销售凭证开票不管是大集团还是中小企业都经常发生，K3在复制控制功能必须要增加。图K07-3 往来科目因为K3无法自动过账，只有在这里选择科目手动记账。ECC的SD模块和K3相关模块的对比（5）-复制控制设想一个业务模型：企业开了多个销售订单，然后需要参照这多个销售订单创建一张交货单，最后发票参照多张交货单创建。如果参考的多张凭证中的项目有可以合并的，当然需要合并，这样减少了业务处理量，降低了出错率。当然还有些项目比如说送达方不同，不可以合并的。为了灵活应对这类业务需求，SAP设计了复制控制这样的功能。图30为销售凭证相关的复制控制图30-1 为销售凭证维护复制控制点击进入后得到图30-2，图30-3图30-2 复制控制：销售凭证到销售凭证指定如报价单到销售订单的复制控制图30-3 复制控制：开票凭证到销售凭证怎么是开票凭证到销售凭证的复制控制的？SAP又出错了？当然不是，设想这样的一个业务模型：企业送货到客户那里，因路途遥远保管不慎，坏了不少，客户不愿意收，坚决要求退货，这时先开一张完整的发票，再做一张反向的开票凭证，冲销退货的部分。然后参照反向的开盘凭证创建一张退货销售凭证。这个复制控制主要是用来控制这样的反向业务流程的。图31为开票凭证相关的复制控制图31-1 为开票凭证维护复制控制点击进入后得到图31-2，图31-3，图31-4，图31-5图31-2 复制控制：销售凭证到开票凭证这是最常见的业务场景之一了图31-3 复制控制：开票凭证到开票凭证回顾在图30-3提到的业务模型，反向的开票凭证可以参照正向的开票凭证创建。图31-4 复制控制：交货凭证到开票凭证这也是最常见的业务场景之一图31-5 检查复制控制的配置设置SAP自检程序，用于检查配置的正确性。这是SAP值得借鉴的一个设计逻辑，就是内置一个自检程序自动检查配置的正确与否，在大型项目的实施中非常实用。图32为点击图31-2进入的界面，我们选取一个标准的复制控制为例来讨论。图32-1 目标凭证图32-2 源凭证图33为凭证抬头的复制规则定义界面。图33-1 复制需求确定哪些字段相同的凭证可以合并，哪些字段不同的凭证不可以合并。需求在SAP中应用相对广泛，它其实是一个例程，用户可以自行编写相关的判断和计算逻辑，在条件定价中有着同样的应用，这里不详细讨论。图33-2 分配号码/参考号码和后续的FI凭证相关，不详细讨论。图34为凭证项目的复制规则定义界面图34-1 复制需求图34-2 数据复制定义数据如何汇总分割图34-3 开票数量定义开票数量从哪个源凭证中复制图34-4 正/负数量假定这样的业务模型：一个开票凭证中有冲销的项目，这个时候冲销的项目类型需要设置为负，以在合并时冲减数量。图34-5 定价类型定义发票如何处理定价条件图34-6 定价源定义发票定价的来源ECC的SD模块和K3相关模块的对比（6）-审批在ECC6.0中有两种审批程序设计逻辑，第一种是采购中的审批程序，在ECC的MM模块和K3相关模块的对比中我们已经分析过，采购中的凭证类型单一，审批复杂，毕竟企业把钱花出去是很难受的一件事，现在都讲究成本压缩，采购是最需要把关的地方。而销售中的审批相对简单地多，连客户掏钱给你买东西你都要审批上好几回，也太牛了吧。所以销售中的审批程序是使用的第二种：状态参数文件。状态参数文件不光用在销售中，在CO等其他模块中也有广泛的应用。图40为状态参数文件的定义界面图40-1 状态在图41中会详解图40-2 短文本定义状态的描述图40-3 最低值定义审批凭证的最低额度图40-4 最高值定义审批凭证的最高额度图40-5 位置定义审批的顺序图40-6 权限组定义审批人的ID图41为点击图40-1后进入的界面图41-1 业务事务定义需要控制得事务码图41-2 允许图41-3 警告图41-4 禁止图41-2 3 4分别定义了审批的三种状态金蝶K3中的审批只有简单的三级审核人，没有金额之类的限制。中小企业一般来说组织架构相对简单，业务量也较小，可以是一个老板通审所有的凭证，但随着业务量的增加和组织架构的复制化，根据条件进行多级审批是非常有必要的。ECC的SD模块和K3相关模块的对比（7）-信用控制图50为SD模块的信用控制/风险管理的后台配置界面，我们只简单讨论下简单信用限制检查和自动信用控制。图50-1 简单信用限制检查图50-2 定义动态信用控制图51为简单信用限制检查的界面图51-1 检查信用设置信用的检查程序以及超出信用限制后的系统反应，是错误/警告还是冻结交货，信用限制额在财务模块中设置。图51-2 信用组和图9-6的设置相同，定义销售凭证的信用组。图52为动态信用控制的定义界面图52-1 没有信贷检查其实就是判断是否进行信贷检查一个条件例程，可以自行编写程序判断凭证是否进行信贷检查。图52-2 项目检查设置项目一级的信贷检查图52-3 偏移百分比设置信贷批准后的凭证数量增加的最大百分比。适用于这样的业务场景：一个销售订单已经通过信贷检查，这时客户提出要求多买一部分，可以在这里限制多买的比例。图52-4 天数一个凭证审批过了，可是过了好几天还没有动静，这时可能需要重新审批。这里可以定义重新审批的天数。图52-5 静态设置静态检查，和下面的动态检查相对图52-6 动态假设有这样的业务模型：客户有张销售订单过了一年还没付款，虽然没有超过信贷限制，但是他的信用状况已经值得怀疑了，这