一、业务背景简介
无论是手工做业务还是ERP系统做业务，采购订单与销售订单中，“付款条件/收款条件”均是必需项，用以指导采购/销售部门或财务会计部门（AP应付/AR应收）具体的工作方式，但作为系统“产品研发与交付实施”人员必须清楚的是，“手工业务”与“ERP系统业务”两者的实际处理方式是有重大区别的。
在手工业务模式下，付款/收款条件的具体执行是由采购/销售部门负责实施的，因为“手工业务数据分散、无法实现集成应用”等等的原因，会计部门实际并不具备实施执行“付款条件”的可能性。以采购付款为例，采购部门通常是根据付款条件的相关指引，向会计部门提报具体的采购付款申请，什么时候该提付款申请，每次提交的付款申请是否是预付，该付多少金额等等，完全由采购部门根据相关付款条件及其相关业务情况“人工”来决定与掌握，会计部门的职责只是根据收到的“采购付款申请”（请款单）“立即”做账并及时付出款项，会计部门并不需要关注“付款条件”的相关具体内容。
手工业务模式下，对于采购部门提交的所谓“预付款”，会计部门在实际工作中，通常并不会真的按照“预付款”（债权）入账，而是通常直接作为“应付账款”处理，并要求供应商提供相关“税务发票”，具体的账务处理方式与“普通付款”几乎没有区别。
手工业务模式下，例如一笔订单金额100万的采购款项（例如购买一台价格100万的机器设备），假定根据付款条件，以当前时间为准，30万为立即预付，剩余30万在30天后支付，剩余40万在60天后支付。则采购部门会在当前时间先提交一笔30万的（预付款）支付申请，再在当前时间或已收货/收票时间点的30天后提交一笔30万的支付申请，再在当前时间或已收货/收票时间点的60天后提交一笔40万的支付申请。会计部门只是根据在不同时间点收到的采购部门的“支付申请”做账并付出款项。付款是否及时、是否会出现错付等等问题，基本上完全取决于采购部门的“付款提报”的及时性、正确性与工作质量。
但在ERP系统业务模式下，“付款条件”的具体执行则是由会计部门基于系统的业务逻辑（自动）负责完成实施的，采购部门并不需要“人工”负责或掌控具体的付款进程。同样是一笔订单金额100万的采购款项，同样是先预付30万、30天之后再付剩余的30万，60天之后再付剩余的40万。ERP系统会将采购订单上的“付款条件”的相关“结构化”付款信息自动传递给会计部门。对于30万预付款申请，会计部门会在ERP的AP应付账系统以“30万债权”入账并（立即）完成支付。在收货/收票之后的时间点，由采购部门或由供应商自己直接向会计部门提交一笔原订单金额100万（而不是扣除已预付30万之后剩余的70万）的“付款申请”。该“付款申请”在ERP系统中称为“应付发票”或“应付单”。
会计部门在ERP的“AP应付账款系统”基于这100万的“付款申请（应付发票或应付单）”做账时，系统会自动提示“是否核销”系统中已经存在的30万的预付款，若“是否核销”选择为“是”，则AP应付系统会立即生成两条“付款计划行”数据，第一条付款计划行，付款金额是30万，付款时间点是“30天之后”的某具体时间点，第二条付款计划行，付款金额是40万，付款时间点是“60天之后”的某具体时间点。此后，出纳部门的工作原则上只是根据“付款计划行”的提示，在系统规定的时间点完成相应款项的实际支付。
在某些特殊情况下，例如针对该供应商又实际发生第二笔需要“预付款”的采购业务，则会计部门也可以在处理第一笔采购付款时，于应付发票/应付单上选择“不核销已存在的预付款（30万）”，或虽然选择核销为是，但在系统进一步提示选择确定核销金额时，仅选择核销已经发生的预付款（30万）的一部分（如15万），则系统为第一笔付款业务自动生成的“第一条付款计划行”的实际付款金额就为60万（不核销预付款）或45万（部分核销预付款）。
比较上述“手工业务模式”与“ERP系统模式”两者的不同，前者的实际付款进程是完全依靠“采购部门”人工去把握控制的，后者的实际付款进程则是完全由系统基于“规则（结构化的付款条件）”去自动生成并控制的，付款是否及时、能否防止错误的发生，甚少再受人为因素的影响，工作效率与质量大大提高。
ERP系统模式下，实际工作中的一个必需要求是：一旦采购业务已经发生并完成，就必须立即完成当前已交付数量或金额的采购应付的“立账”工作，由采购部门或供应商自己直接负责向会计部门立即完成“申付提报”工作。系统业务逻辑做这样的设计，理论与实践均已证明是有诸多大大好处的。其中（延伸）好处之一是“大大方便了财务部门的资金计划工作”，不再需要采购部门人工（滚动）提报未来一段时间的“用款计划”。
基于“结构化付款条件”的ERP系统业务模式，体现的是一种先进的“管理思想”与业界最佳实践经验，它对于付款及时性的保证以及防止错付情况的可能发生，具有人工业务模式无可比拟的优势。高端ERP软件（SAP/ORACLE）都是这么设计的，而国内大多数低端ERP软件则可能还是采取的是第一种“模拟手工业务方式”，其高下优劣，读者可以自己去深入体会，限于篇幅，本文这里就不再展开做详细讨论。
此外，“产品研发与交付实施”人员还需要特别注意的是，日常工作中人们所说的“分阶段付款”有“狭义（精确）与广义（泛化）”两种内涵，狭义（精确）的内涵是指一笔确定的“应付款”（例如前述购买一台价值100万的设备），在“会计阶段”分多个批次完成支付；广义（泛化）的内涵还包括“采购阶段”一个采购订单（总数量/总金额）按订单的实际已完成交付（数量/金额）分批次/阶段付款，例如“物品采购订单”基于已收货/交付数量的分批（申请）付款，“服务采购订单”基于已完成金额（如工程完成进度）的分批（申请）付款，它实际并不属于“付款条件”上的“分批次/分阶段”的定义范畴。两者不能混淆，付款条件上定义的“分批次/分阶段支付”特指是在会计阶段（而非采购阶段）一笔确定应付账款的分期、分批支付，它是财务行为而非采购行为。
二、ORACLE采购付款条件的定义
（以下这段内容摘录自笔者所著《ORACLE EBS入门及供应链核心系统详解教程（上）》一书的 第6章：ORACLE EBS采购管理系统（上）之6.4.3 定义付款条件，P307-P309页）
在实际采购工作中，采购部门在与供应商商谈并确定采购价格时，双方总是会同时考虑付款条件与方式问题，这是因为资金都是有利息成本的，付款条件不同也就意味着双方所承担的实际采购（销售）成本有所不同。例如，通常所谓的“采购赎期90天”与“采购赎期30天”相比，前者相当于采购方多占用了供应方60天的资金，而没有支付资金利息。
在ORACLE系统中定义的采购“付款条件”，除了供采购部门在确定采购价格与下达采购订单时参考引用之外，实际对采购系统流程本身的执行并没有多大影响，它主要影响的是会计部门在AP应付账款系统中的流程操作，因此，在ORACLE系统中，采购的“付款条件”定义实际是在AP应付账款系统中完成的。但由于“付款条件”对于采购工作的重要性，理解与熟悉系统的付款条件定义对于采购人员来说是必要的。
ORACLE系统关于采购付款条件的定义方式是基于业界最佳实践经验，高度“结构化”的抽象与总结，几乎囊括了各行各业所有可能用到的各种各样的复杂支付方式（对于企业来说，基于管理简化的需要，实际只应当常用部分方式），它是系统采购发票付款处理规范化、流程化，以及进行有效的财务资金计划工作的基础。付款条件在系统中的具体实现方式，可分为以下几个相对独立的组成部分：
第一部分，确定发票到期付款的时间基准：1、以买方收到货物的时间为基准；2、以买方收到发票的时间为基准；3、录入发票时的系统日期；4、（供应商）发票开票日期；（后两种不常用）
第二部分，在何时：1、（收货或收票后）延后天数；2、收票后当月或下月的某一固定日期支付，注意：这两种方式可以同时存在，即部分款项按第1种方式，部分款项按第2种方式；
第三部分，以何种方式付款：1、以发票总金额的一定比例；2、以发票中的部分金额；注意：这两种方式不可以同时存在；
第四部分，折扣方式：在前两部分组合的基础上，给出符合何种条件时的折扣，当实际适用的条件不同时，折扣率（可以）不同；
第五部分，分批分次：在前三部分的组合基础上，将整个支付进程分为多个阶段批次；
关于发票到期日计算的时间基准，系统在“应付系统选项、供应商定义”中均可设置（供应商层优先于应付系统选项层），最后在采购发票行上还可以手工更改。实际工作中大多数情况下，按采购订单付款的供应商会选择要求买方按“采购收货日期”作为发票到期日计算基准（如此供应商对于付款进程，相对比较容易掌握），因此，通常需要在供应商定义时作相关设置。
下面以具体的实例来说明在“确定的发票到期日计算基准”之下，系统是如何结构化付款条件设置的，如下图23所示：
上图中，付款条件“名称”字段，实际工作中应当根据具体业务惯例使用买卖双方都易懂的表述方式，因为“付款条件名称”一般会出现在采购订单或合同之中，例如“30%30天，30%60天，40%90天”，表示全部发票款项分三批付款，30、60、90天内各付30%、30%、40%。注意，发票付款条件只是供AP应付账款系统为应付发票自动生成“计划付款日期”作参考依据，系统可以允许在“计划付款日期”前后的实际付款操作（提前或推后）。
上图中，“付款条件”的“行数”表示拟分批数，对于“到期%”的支付方式，各行的总和必须是100%，而每行对应的“天数”即表示按发票到期日计算基准日期延后的天数。对于每行，可以至多再定义适用三个可选的“折扣方式”，如下图24所示：
上图中，AP应付款系统在（当前日期）为发票计算生成“付款”时，会自动查找并适用相关折扣：如果实际是在5天内而不是原定30天内支付第一批30%款项，则可以对这30%款项打5%的折扣（第一折扣）；对于第一批30%付款，还可以在“第二折扣”、“第三折扣”中定义在当前日期错过了“前一折扣”日期之后可用的折扣，例如10天内可折扣2.5%（第二折扣），20天内可折扣1.5%（第三折扣）。对于第二、第三批付款，依次类推。
以上所举“付款条件”实例在使用过程中的一个特点是，如果拟付款发票包含多个采购订单的多个不同日期的接收，则系统会以最后一个接收日期（Last Receipt）作为“计算付款日期基准”，这事实上有些拉长了供应商的平均回款时间，故实际工作中也经常采用所谓“30天月结、60天月结”的方式，即规定在供应商当月（多次）送货后，在下月或下下月的某个日期前，汇总开票做一次付款。类似这种方式的“付款条件”定义如下图25所示：
上图中，表示当月所有采购到货接收汇总成一张发票，将可以延迟一个月（提前月数为1），在下个月20号（计划付款“日”）付款（即“30天月结”），但如果供应商开票并送达后录入的系统日期晚于15号（截止日），则生成的发票计划付款日期将是下下个月的20号。
付款条件除了上述常见的“到期%—天数、日—提前月数”组合方式之外，还可以有“到期%—日期”、“金额—天数”、“金额—日期”等等各种不是很常用的组合方式，具体内容与涵义，可参见ORACLE相关说明文档，限于篇幅，这里不再赘述。
最后，需说明的是，实际采购工作中的所谓“付款条件”，很多时候可能还包括“预付款”的内容。但在ORACLE系统中关于“应付账款”的“付款条件”定义却并不考虑“预付款”问题，在采购系统的业务流程中也不考虑采购预付款如何处理，相关采购单据之上无有关预付款信息。（ORACLE系统将采购预付款的处理在采购PO系统与应付账款AP系统之间完全分离，在实际工作中于管理上确实多有不便）。
三、ORACLE销售付款条件的定义
（以下这段内容摘录自笔者所著《ORACLE EBS入门及供应链核心系统详解教程（下）》一书的 第8章：ORACLE EBS订单履行系统（上）之8.4.9 定义付款条件，P34-P36页）
确切地说，销售角度的“付款条件”实际是指针对客户的“收款条件”，它对应于客户采购订单上的“付款条件”，但基于销售收款管理的需要，在具体内容上又有所不同。系统在初始安装时，有两个预置的销售付款条件“30 NET（净额30天到期）”与“IMMEDIATE（拖欠收费或借项通知单的条件）”。通常用户需要根据实际情况事先定义所有可能使用到的销售“付款条件（名）”。如下图52所示R12的销售付款条件设置界面（R11稍有不同）。
上图中，“允许部分付款折扣”选项如选定，表示对于分期付款的情况，允许对部分付款计算付款折扣（应收AR系统的“允许部分付款折扣”也需同时选定）；“预付款”选项如选定，表示对于引用该付款条件的销售订单，在发运交货前需要完成（部分或全部）相关款项；“信用检查”选项如选定，则表示对于该付款条件的销售订单需要纳入客户“信用限额”检查的考虑范畴；
上图中，“（结转余额）开单周期（Billing Cycle）”选项是R12才有的功能，用以控制给客户的有关“结转余额账单”的打印。“结转余额账单”与“对账单”有相似之处，区别在于“结转余额账单”可代替“发票”用于客户付款，而“对账单”仅给客户作信息参考。“开单周期”可选用值需要在应收AR系统中的所谓“结转余额开单周期（Balance Forward Billing Cycles）”中定义（系统在初始安装时有一个植入的定义值“External”）。如果设置“付款条件”时“开单周期”字段留空，则表示引用当前付款条件定义的订单所对应的发票，不纳入“结转余额开单”并发流程（打印）程序的考虑范围；如果设置为“External（外部）”，则表示引用当前付款条件定义的订单所对应的发票，在打印“结转余额开单”被选定时，由外部系统所做的相关定义控制其打印频率或计划；如果设置为一个基于“每日/每周/每月”频率的确定值，则在打印“结转余额开单”被选定时，将按设定的相应频率实施打印。
上图中，“基准额”字段，默认值为 100，但可以进行更改。基准额是发票需分期付款时，系统计算每期比率所假定的分母。“折扣基准”字段可选项包括：“发票额（Invoice Amount）”，表示依据发票的税、运费和行金额的总额来计算折扣额；“仅限于行（Lines Only）”表示依据发票的行金额来计算折扣额；“行、运费项和税（Lines, Freight Items, and Tax）”表示根据发票的行项金额、运费额和税额，但不包括发票题头层的运费和费用，来计算折扣额；“行和税，而非运费项和税（Lines and Tax, not Freight Items and Tax）”，表示根据发票的行项金额及其税额，但不包括运费项及其税行，来计算折扣额。
上图中，“有效日期”字段输入值，表示当前付款条件（名）的有效使用日期范围；“打印提前天数”字段输入值，应收AR系统将在到期前的指定天数打印相关发票；“分期付款选项”字段可选值包括：“第一期付款含税与运费”，表示在首期付款中包括全部的税与运费；“分摊税和运费”，表示在所有各期付款中分摊税与运费。
上图中，“付款明细表”区域，可以输入分期付款明细。“序号”字段由系统自动生成，表示付款分期；“相关金额”字段输入的值与“基准额”之比即为每期付款比率。各期输入值之和应等于基准额，即各期比率之和应等于100%；如在“到期天数”字段输入值，则表示发票日期之后的到期天数；如在“日期”字段输入值，则表示一个确定的日期；如在“月日”字段输入值（1-31之间的某个值），同时在“提前月数”字段输入值（0-X），则表示发票在发票日期所在月的推后某月的某日到期。上述三种发票到期日只能选择其中一种；
对于付款条件中的每一分期付款行，系统也允许为之设置适用的“折扣”方式，如下图53所示：
上图中，“%”字段表示可以适用的折扣，而其后“天数、日期、月日、提前月数”字段输入方式与分期付款行相同，表示当前折扣适用时需满足的条件。
最后需指出的是，销售“付款条件”实际是在应收AR系统中定义的。由于销售订单在“登记（Book）”时，“付款条件”字段是必需项，除非使用系统安装时植入的销售“付款条件”，否则，设置付款条件是订单管理OM系统使用前的必需步骤。
四、简化版的ORACLE EBS 付款条件设置
考虑到ORACLE EBS的付款条件设置的具体功能设计比较抽象、比较复杂，用户的使用体验较差，故笔者在自己过去所设计研发的“EBS云平台套件”产品中，对之做了一定程度的简化，以便大大提高其易用性与用户体验。以下做简要介绍：
（1）查询条件及查询结果视图：系统界面有两部分组成，一是查询条件区域，二是查询结果视图区域，如下图：
（2）“新增”页面，如下图：
（3）“编辑”页面，如下图：
（4）“查看”页面，如下图：
（5）“行新增”页面，如下图：
（6）“行编辑”页面，如下图：
注意，“付款条件”是系统的一个“基础设置”，系统通常有预置（植入）值，用户可以根据需要进行修改或新增相关数据。对于同一个交易方/企业租户（SAAS版）来说，所有相关数据对于任何业务组织均有效及可用，即“付款条件”没有“业务组织”的上下文隔离与限制。
五、结语
需要说明的是，在上述笔者所展示的“简化版付款条件设置”功能设计中，并未考虑“预付”的问题，原因是采购订单或销售订单上在引用“付款条件”时，无论“付款条件”中是否有已经“预付”的相关设置，采购/销售订单（头层）中，通常还是需要将“是否预付”、“预付比例”字段单独列出。
若付款条件设置中没有考虑“预付”相关内容，则需要在采购/销售订单设计中，将“是否预付、预付比例”列为“（必需的）可编辑”模式；若付款条件设置中已经考虑有“预付”相关内容，则需要在采购/销售订单设计中，将“是否预付、预付比例”列为“不可编辑”模式，其具体赋值，则需要由已引用的 “付款设置”中的相关数据自动带出，以便保持相关数据的一致性。
总的来说，作为系统基础设置之一的“付款条件”，其本身的“结构化”定义与生成并不难，难的是如何在系统中进行实际应用（调用逻辑），即在AP应付/AR应收系统，基于应付开单（发票）或应收开单（发票）题头的总金额，如何正确生成一行（不分期）或多行（分期）“付款计划行”数据。
此外，相比于ORACLE的“付款条件”设置，被简化掉的有关设计内容，以后实际工作如有需要，还可以再丰富与添加，并同时修改实际的系统应用逻辑。
（杰夫 2021.4.5）
