本文介绍了Cloud系统中应付单与发票的核销逻辑。核心在于管理应付业务是否收到发票,并在相同物料数量下核销。若价税合计不同,需生成调整应付单;若价税合计相同但不含税金额不同,亦会产生调整单。调整单通过单据编码区分,并涉及应付付款核销,确保客户不多付款。反审核时需先反核销。
应付系统与应收系统是相同的逻辑,所以以下内容也适用于应收系统。
Cloud系统里抽象出应付单,应付单作为应付管理的核心,那就需要管理某笔应付业务是否有收到发票。所以也就存在着应付单和发票的核销了。
应付单和发票核销,首先是在相同物料的前提下进行,相同数量的数据进行核销。
例如应付单数量100个,单价1元,价税合计100元。
之后会有三种情况:
(1)下推发票数量40,单价1,价税合计是40。在相同数量基础下的价税合计相同,所以正常核销,不需要产生调整的应付单。
(2)下推发票数量40,单价1.1,价税合计是44。在相同数量基础下的发票的价税合计多了,所以核销后,需要产生调整的应付单,价税合计为4。
(3)下推发票数量40,单价0.9,价税合计是36。在相同数量基础下的发票的价税合计少了了,所以核销后,需要产生调整的应付单,价税合计为-4。
所以会有两种情况下生产调整的应付单,现在系统里调整的应付单是通过单据编码(APT)来区分的。
第3种情况,会产生负数的调整应付单,为了避免客户多付款,所以产生调整单的时候就将原应付与调整的应付单进行了应付付款核销。所以如果对这样的发票进行反审核,会提示用户先进行应付付款反核销。
以上是应付单与发票在相同数量基础下的价税合计不同情况下如果产生调整应付单的,如果是价税合计相同,但是不含税金额不同,也会产生调整单。
例如:应付单数量100,不含税金额100,税额17,价税合计117。下推发票数量100,不含税金额99,税额18,价税合计是117。因为不含税金额不同会影响存货核算,所以也会产生调整单,不含税金额为-1,税额为1,计税合计为0.
推荐阅读