标签：发布 financial 支付 tom 系统 business 原创 商家 创建
应收款风险最小化Risk Minimization for Receivables
每个信用政策的目的是减少由客户应收款带来的风险；
连同信用管理，你也有权限在业务处理中使用其他几种付款担保形式；这包括信用证，出口信用保险（外部连接）和付款卡；
这些付款担保形式因他们提供给你的安全水平而不同，且都集成在风险管理中；
当使用了一种付款担保（例如，信用证），系统首先尝试提供最适宜的风险最小化；
如果这是不可行的，然后你可以在第二阶段使用信用管理来创建一个信用限额并因此限制风险的水平；
MARK：你使用哪种付款担保形式更多地取决于正在处理的业务交易；信用证主要应用于大比例出口的交易；然而信用卡对于零售交易更为重要；
付款卡类别Payment Card Categories
付款卡代表了一种结算发票的方法，因为一个金额的授权保证了该金额的支付；
下列付款卡类别被用于付款卡处理：
信用卡Credit cards：
用于采购货物或者服务，定期给客户Billing（例如，每个月最后一天）；
客户卡Customer cards：
被客户用于从某个批发商或者一组批发商处购买货物和服务；
采购卡Procurement cards：
代表公司发给员工用于采购一个给定金额内的项目；
例如：为煤气；
信用证：业务流程Letters of Credit：Business Process
一张信用证的通常处理流程如下：
进口商发送一张采购订单给出口商；该采购订单是根据指定的付款条件购买货物的协议；
收到来自进口商的采购订单之后，出口商发回一张订单确认；订单确认是根据采购订单中指定的条件销售和交货的协议；
进口商在他/她选择的一个银行申请一张信用证，并依照由出口商指定的付款条件；来自出口商的订单确认形成了信用证的基础；银行和进口商之间商议的条件取决于进口商的信用价值；
承认信用证之后，开证银行opening bank（进口商的银行）可以联系在出口商所在国家的分支机构（用其他的话说，通知行Advising bank）以开出和确认该信用证；
通知行保证该信用证，并以保证邮件的方式发送给出口商，现在该信用证正式开出；信用证确认了进口商的付款能力，然后出口商可以根据协议的条件交货了；
信用证：物流和价值流；
交货的流程如下：
出口商根据在信用证中协议的条件交货给进口商；信用证通常包含细节例如运输模式和装载/卸载点；
发送货物以后，出口商出示有效的信用证和必需的货运票据给押汇银行negotiating bank；（出口商可以决定一个押汇银行；通常地，它是个出口商有帐户的银行；然而，通知行也可以作为押汇银行；）
押汇银行检查货运票据的有效性；如果这些票据以任何方式发生了背离，押汇银行可以拒绝接受这些凭证；如果货运票据没有问题，银行接受他们并支付给出口商为该交易协议的金额；银行费用可能要收费，依赖于信用证的条件；
开证银行偿还押汇银行支付给出口商的金额；开征银行接收到由出口商出示的货运票据；
开证银行议定来自进口商的付款作为货运票据的报答，然后进口商根据协议的条件付款给开证银行；
在从开证银行收到货运票据的基础上，进口商出示提货单给运输公司然后收到货物；
财务凭证Financial Document
信用证是一种财务凭证并且可以在SD外贸交易的菜单Documentary payments下找到；它是另一种形式的付款担保；
信用证可协议为可取消的revocable和不可取消的irrevocable；
系统也可以区别确认的和未确认的信用证：
当处理一张未确认的信用证时，出口商仅收到来自进口商银行的付款担保；当处理一张确认的信用证时，出口商的银行也担保付款；
开证银行显示在凭证的主屏幕上；然而你可以输入几个银行作为参与方；
在财务凭证屏幕中，你列出将要发送给银行的凭证清单；
如果信用证中的某一个参与方的姓名和/或地址与你的主数据中的不一样，则你应该在财务凭证地址屏幕中准确地输入和信用证中一样的名字/地址数据；如果你在这里不输入任何任何东西，则系统会复制主数据中的条目；
你可以在配置中设置以致信用证只有在被两位员工双重检查之后才被激活；
MARK：该课程仅处理在风险管理中用作付款担保功能的财务凭证；需要更详细的描述，看课程LO640 Foreign Trade；
在订单中输入一张信用证Entering a Letter of Credit in the Order
在订单中，你可以在抬头或者条目中输入一张财务凭证号码（信用证号码），只要这种付款担保形式允许用于相应的客户；
信用证通常覆盖订单的总金额；在例外的情况，一张协议可能仅覆盖一部分金额；
在这种情况下，相应的金额会从财务凭证中扣除；
Mark：为了让一张信用证被接受，一些存储在信用证中的数据必须和它分配到的订单中的数据保持一致；哪些数据会被检查在配置中控制；
确定付款担保形式Determining the Payment Guarantee Form
因为不同的付款担保可能都被激活了，你需要定义优先级来控制使用哪种可用的付款担保；
你通过一个付款担保程序来控制；它定义了一个顺序，在该顺序的基础上，分配付款担保形式给销售订单；
系统通过存储在付款方主记录中的一个客户程序以及分配给相应的销售凭证类型的一个凭证付款担保程序来确定付款担保形式程序并因此确定相应的付款担保形式；
Mark：没有确定逻辑用于付款卡和财务凭证；用其他的话说，这些付款担保形式必须手工在凭证中输入；然而，如果出口信用保险输入在付款担保程序中（外部连接），则系统自动地尝试为该订单确定一个有效的合同；
付款担保形式的比较Comparison of Payment Guarantee Forms
所有列示的付款担保形式代表为应收款减少风险的选项；
在主数据页面存在不同；
针对信用卡，信用证和出口信用保险的检查和信用管理中的个别检查使用相同的方式进行管理；在信用管理中，设置了一个会在确定全局状态时考虑的状态；
锁住的凭证的释放/拒绝时通过被锁销售凭证清单来实现的；
保险余额和信用证余额的更新是通过信息结构来执行的，就像在信用管理中一样；
信用证和付款卡之间一个明显的差异是如果信用证输入到一个付款担保程序中，则在订单中必须分配一个信用证，否则订单会被锁住；如果付款卡输入到程序中，则即使不输入付款卡订单也不会被锁；该差异的原因是使用这些付款担保形式的业务交易之间的差异；
付款卡处理的业务伙伴Business Partners for Payment Card Processing
付款卡代表了每天业务交易的一个重要的部分；
几个业务伙伴包含在付款卡处理中；
持卡人使用卡来采购货物或服务；
商家交货或提供服务给客户并接受付款卡作为付款方式；
票据交换所clearing house为卡发布授权并执行结算；
商家开户行代表商家参与结算和付款处理；
发卡银行负责发行卡给持卡人并且也参加结算和付款处理；
SAP目前支持商家和票据交换所之间的业务交易（不支持打印或客户卡管理）；
付款卡处理的处理链Process Chain for Payment Card Processing
付款卡处理支持下列功能：
一个付款卡计划在抬头分配给销售订单；该计划包含信息例如卡号，卡类型以及授权数据；
当创建交货时，会为授权执行一个有效性检查；如果授权不再有效，或者如果数量的增加需要价值的增加，则用户需要在销售订单中再次执行授权；
付款卡数据从订单复制到Billing凭证；
付款卡数据和授权数据在Billing凭证传输到FI时向前传送；在配置中，你可以配置系统以使当包含采购卡时，结算所需的额外数据从SD传输到FI；
使用付款卡的交易可以记账到deviating accounts（当控制Billing类型时查看字段Account determination for payment cards）；
最终结算处理是通过票据交换所在这些信息的基础上执行的；
使用外部系统为付款卡授权Payment Card Authorization with an External System
这种形式的处理发生在零售业；电子收款机系统（POS）是为货物付款的地方（通常是收银机）；
没有销售或者装运凭证产生；
当使用电子收款机系统，授权在一个外部系统中执行；
相应的数据导入到R/3系统，Billing凭证在R/3系统中创建；
客户主记录中的付款卡数据Payment Card Data in the Customer Master Record
付款卡数据可以通过Payment transaction screen存储在付款者主记录中（Payment cards button）；
这里，你指定付款卡类型（例如，VISA），付款卡号码，以及该卡的有效期；
一张卡也可以输入为默认值；这会出现在订单处理中的F4帮助中；
如果一张卡被锁，也可为相应的付款卡输入锁住的原因；（仅用于信息的目的，对于订单中的锁没有影响）；
当你在客户主数据中输入付款卡，下列检查会被执行：
系统检查卡号的有效性，倘若相应的检查程序已经在该卡类型的配置中维护了；
系统也检查是否该卡已经在另外的客户主记录中输入了；同样的卡不能输入到多个客户的主数据中；
带有付款卡计划的订单的结构Structure of an Order with Payment Card Plan
一个付款卡类型必须分配给允许付款卡处理的所有销售凭证类型（例如，如果没有付款卡计划类型分配给现货销售，则这里不会出现付款卡的输入字段）；
付款卡数据只能在抬头输入；
付款卡处理所需的信息存储在销售订单的不同水平：
订单抬头包含付款人的数据
订单条目包含定价信息；
计划行包含交货日期和数量；
付款卡计划包含付款卡数据和授权数据；
授权处理在订单被保存时自动地触发或者它可作为一个后台作业执行；
授权之后，授权号存储在订单中；如果例如数据传输有技术问题，该号码也可以手工的输入；
每个单个的授权都有一个详细屏幕，在这你可以查看附加的信息；
数据传输到票据交换所Data Transfer to the Clearing House
票据交换所为订单发布授权并且也负责结算；
和外部系统的透明接口允许商家传输和接收数据；
在标准的R3系统中，函数CCARD_AUTH_SIMULATION作为一个模板提供给你以创建用户定义的授权函数；
标准系统还包含了函数CCARD_SETTLEMENT_SIMULATION，用于创建用户定义的结算函数；
授权Authorization
授权通常在订单的抬头执行；用其他的话说，新的授权必须始终为整张订单创建；
使用检查组，你可以在配置中设置必要条件，用来控制在什么环境下授权会被确定；然后你可以设置系统以使授权仅为完整的订单执行；
依赖于检查组，你还可以指定授权范围（用其他话说，授权什么时候会被确定）；
如果你使用标准系统中提供的授权必要条件1，授权在你保存订单时触发；授权必要条件1供后台处理使用；
检查组必须分配给销售凭证类型；
在上面的例子中，一张订单已经在今天输入并且使用VISA卡支付；授权会在创建交货前一天执行并且有效期为14天；
依照计划行，下一次物料可用日期在3天后；这意味着授权处理必须在2天的时间内执行，根据指定的授权范围；
订单中的授权在Billing中使用；订单中的一个状态显示哪个授权已经被使用；
Mark：你可以在配置中使用检查组来控制是否在订单中执行初步授权（价值0，如果目前日期在授权范围之外）来检查卡数据的正确性；
结算Settlement
当会计凭证从传输过来的包含付款卡数据的Billing凭证创建时，会执行下列记账：
客户帐户的借方和贷方记账；
销售收入记账；
应收款记账到票据交换所的中间科目；
该记账流程可以解释为授权担保应收款并且票据交换所代表相应的业务伙伴付款；
应该为每个票据交换所建立一个中间科目，因此条件技术可用于执行记账到相关的科目（所有使用VISA和MC支付的应收款记账到GZS的中间科目；所有使用AMEX支付的应收款记账到AMEX票据交换所的中间科目，等等）；
每隔一定间隔，单笔记账可以在票据交换所的中间科目累积并作为一个总值记账到相应的中间银行科目；同票据交换所的结算由中间银行科目触发；现在该科目包含期待付款的来自票据交换所的应收款；应收款通过一次结算运行来传送；
后台处理号码可用于收款过程中作为分配的目的；
中间银行科目在票据交换所支付应收款的基础上被清帐；
标签：发布 financial 支付 tom 系统 business 原创 商家 创建
原文地址：http://www.cnblogs.com/jellour/p/7130237.html
