问题描述：

付款单提交银企，银企交易成功返回付款单状态为已付款。

解决方案：

1.	客户诉求
付款单的状态应与银行处理结果保持一致
2.	产品设计的初衷
目前标准产品付款单有保存、已提交、已审核、已审批、已付款五种状态，银行付款单有准备提交、提交失败、待银行答复、银行处理中、交易成功、交易失败、交易未确认七种状态。
对于使用银企账户支付时，“审批”状态的付款单提交银企时状态更新为“已付款”，银行处理结果可以通过付款单序时簿的银行付款单状态进行确认。对于使用非银企账户支付时，付款单为系统台账，点击付款（包括登记应付票据和支票）后付款单变为“已付款”状态。付款单更新为已付款状态后会反写上游单据状态，付款单可进行凭证核算，单据登账时会登记银行日记账。
付款单银企支付时标准产品的逻辑是：提交银企时，将付款单状态更新为“已付款”并进行账务处理；提交银企后，系统可定期自动同步银行处理状态。标准产品的设计初衷是基于以下考虑：
	现有付款单业务逻辑与历史版本保持了一致，是在付款单台账的基础上增加线上银企支付功能。
	付款单提交银企后将审批通过状态更新为已付款，防止客户重复进行提交银企的操作。且付款单上有银行付款单状态来判断该笔交易银行是否已经处理成功。
	付款单提交银企后变为已付款可及时进行预算扣减，防止在银行支付环节处理的在途单据较多且都未扣减预算造成预算超支。
	在银企支付模式成熟、客户基础资料维护规范的情况下，一般提交银企后交易失败的机率比较低，提交银企后变为已付款可及时进行凭证核算和总账对账，以便及时形成各种财务报表。

• 3.	客户提出的方案及影响
  客户提出的方案为，在付款单提交银企后银行未返回最终交易状态前，付款单显示状态为“已提交银企”，银行交易成功后再将付款单状态更新为“已付款”。按照客户需求方案改造，会有以下影响：
  3.1付款单影响
  若付款单改造，增加状态“已提交银企”（付款单提交银企后银行未返回最终交易状态前），银行交易成功后再将付款单状态更新为“已付款”。需同时考虑：若银行返回交易失败付款单需新增“交易失败”状态（用于区分和其他付款单的区别，提醒用户进行后续处理）。即付款单需要同时增加两个状态枚举值“已提交银企”“交易失败”。
  3.2资金业务单据影响
  1）资金结算中的对外付款单、联动支付结算单和境外结算中的境外支付单与付款单保持相同的银企支付控制逻辑，若调整付款单则这三种单据需同步调整。
  2）资金结算中的对外付款单、联动支付结算单均由上游付款单生成，还需考虑这两种结算单增加状态后对上游单据的反写调整。
  3）单据登账状态下，付款单提交银企后直接登记日记账扣减日记账余额，账户管理策略也根据最新日记账余额进行禁止透支控制，若银行返回交易成功后付款单才变为已付款并登账会导致账户控制策略生效滞后。
  4）若付款单增加状态，所有付款单与付款节点相关参数（大约10个左右）控制逻辑都要同步调整。
  3.3其他业务单据影响
  出纳付款单与费用管理单据和应收应付单据进行了集成，付款单增加状态需同时调整上游业务单据的反写逻辑，需上游业务模块与资金模块一起调整。

• .4 异构系统影响
  很多客户现场存在异构业务系统与出纳系统集成的开发，出纳付款单增加状态，数据集成接口需要同步开发调整。
  3.5预算的影响
  出纳付款单与预算进行了集成，部分客户是通过付款单在付款节点进行预算扣减，若付款单增加状态，需预算同步调整，在提交银企时控制预算扣减，在交易失败时预算自动返还。
  3.6工作流的影响
  多数客户付款单使用工作流审批并进行状态判断，付款单增加状态需大多数客户调整现场工作流，否则可能会因状态值获取异常导致工作流挂起。
  3.7在途数据的影响
  若付款单增加两种状态，需客户将改动前所有已提交银企但银行未返回最终状态的单据处理完毕，否则会导致系统报错和重复支付风险。
  3.8在使用客户的影响
  使用EAS客户数量较多，虽然少数客户有同样需求，但是绝大多数客户比较认同和习惯付款单现在的管控模式，增加付款单中间状态会对这部分客户造成影响。
  4.研发建议方案
  客户提出付款单的状态应与银行处理结果保持一致的诉求合理。
  

   在此模式下其他客户也大部分自行进行了开发控制，但并没有采用增加付款单状态的方案，都是在与异构业务系统集成时做了二开处理，控制付款单状态为已付款且银行付款单状态为交易成功时，才将已付款状态回传给异构业务系统。
  综上：客户的需求合理，但是客户提出的处理方案对标准产品影响较大。目前EAS由于使用客户较多，且调整需多个研发部门同步处理。
  故我们建议的二开方案是：付款单生成了银行付款单，需银行付款单状态=交易成功（增加一个约束条件）时才将已付款状态回传已付款。