R12 付款过程请求-功能和技术信息 (文档 ID 1537521.1)

In this Document

APPLIES TO:

ABSTRACT

这篇白皮书提供R12中处理付款的付款过程请求(PPR)的概述。本文包含PPR处理过程的技术细节和此过程中涉及到的不同的表。

HISTORY

作者：Gavin Zhang

创建日期 15-MAR-2013

更新日期 15-MAR-2013

DETAILS

付款过程请求

概要

在资金支出页面下。用户能够提交付款过程请求(PPR)产生付款。你能够选择提交单个付款处理请求也能够计划付款处理请求. 

付款处理请求一共同拥有四步. 
a) 付款单据选择 
b) 建立付款 
c) 格式化付款 
d) 确认付款 

付款单据选择和确认付款由应付账款(AP)编码处理，而建立付款和格式化付款是由付款(IBY)编码处理

提交单一付款处理请求

必填项目- 付款处理请求名称，付款截止日

付款属性子标签下-付款日期。付款汇率类型. 
付款处理配置文件和支付银行账户是可选字段. 

在处理子标签下，选项可用于在单据选择/付款后停止处理，和怎样创建付款指示. 

验证失败结果子标签下。选择最符合业务需求的关于怎样处理付款单据及发票的验证失败的选项.
点击提交button提交付款处理请求. 

付款单据选择-应付账款

代码: AP_AUTOSELECT_PKG 

当提交一个付款过程请求时，AP_INV_SELECTION_CRITERIA_ALL表就创建一条记录，该记录的checkrun_name与付款过程请求的名字一致. 

在选择发票的时候无需指定付款配置文件和支付该笔付款的内部银行账户。提交PPR的用户也不须要知道这些信息。这些值能够在后来的付款管理中提供. 

选择: 
依照用户在提交PPR时提供的到期日，折扣日，付款组和其他标准来选择发票。选择过程由调用程序运行。

被选中的发票存储在表AP_SELECTED_INVOICES_ALL内.

未选中的发票存储在表AP_UNSELECTED_INVOICES_ALL内. 

锁定: 
选择付款单据后。这些发票就被锁定以防止它们被其它支票选中。PPR的checkrun_id被更新到选中额付款单据的AP_PAYMENT_SCHEDULES_ALL.checkrun_id 中. 

复核: 
假设付款流程请求设置为“在选择计划付款后。停止复核流程”。流程就会停止以供用户复核。PPR的状态变成“发票等待复核”. 

假设没有启用设置“在选择计划付款后。停止复核流程”，选择发票后。建立程序会自己主动提交. 

假设没有发票符合选择的标准，且没有选中不论什么支付的付款计划，PPR自己主动取消且状态变成“取消-未选中发票”.

假设须要用户复核。在用户复核选中的付款计划后点击提交，AP调用IBYBUILD程序. 

验证状态和活动 
在此步骤结束是，有效的状态是 
a) 发票等待复核或 
b) 取消-未选中发票或 
c) 其他显示缺失信息的状态，比方缺失汇率 

假设PPR的状态是“取消-未选中发票”，则没有有效的行动. 
对于其他状态，能够採取的行动有 
a) 结束PPR 或 
b) 改动/继续提交PPR并启动创建付款流程. 

建立付款-付款

代码: IBY_DISBURSE_SUBMIT_PUB_PKG 

建立付款会在IBY_PAY_SERVICE_REQUESTS插入记录。此记录中call_app_pay_service_req_code = checkrun_name. 

主键: PAYMENT_SEVICE_REQUEST_ID 

主要栏位: 
CALL_AP_PAY_SERVICE_REQ_CODE -> PPR 名称
CALLING_APP_ID 
PAYMENT_SERVICE_REQUEST_STATUS 
INTERNAL_BANK_ACCOUNT_ID 
MAXIMUM_PAYMENT_AMOUNT 
MINIMUM_PAYMENT_AMOUNT 
DOCUMENT_REJECTION_LEVEL_CODE 
PAYMENT_REJECTION_LEVEL_CODE 
REQUIRE_PROP_PMTS_REVIEW_FLAG 
CREATE_PMT_INSTRUCTIONS_FLAG 

注意：该PPR显示的状态由ibyvutlb.pls 生成

由get_psr_status功能，在看板上显示PPR状态. 

提供给 PAYMENT_SERVICE_REQUEST_STATUS 的值主要有 
PAYMENT_SERVICE_REQUEST_STATUS 
------------------------------ 
DOCUMENTS_VALIDATED 
INFORMATION_REQUIRED 
INSERTED 
PAYMENTS_CREATED 
PENDING_REVIEW 
TERMINATED 
VALIDATION_FAILED 

建立付款程序将付款信息存入表IBY_DOCS_PAYABLE_ALL中，并通过栏位PAYMENT_SERVICE_REQUEST_ID连接到付款服务请求表. 

主要栏位: 
Payment_service_request_id 
Calling_app_doc_ref_number -> invoice_number 
Document_payable_id 
Document_status 
Payment_currency_code 
Payment_amount 
Document_amount 
Exclusive_payment_flag 
Payment_method_code 
Payment_id 
Formatting_payment_id 
Ext_payee_id 
Payee_party_id 
Payment_profile_id 
Internal_bank_account_id 
Calling_app_doc_unique_ref2 -> invoice_id 
Calling_app_doc_unique_ref3 -> payment number 


a) 内部银行账户/付款流程配置文件(PPP)分配: 
代码: IBY_ASSIGN_PUB 

假设付款流程请求有了一个内部银行账号并分配了一个付款配置文件(PPP)，则该PPR内全部的付款单据都被分配了相同的内部银行账号和付款配置文件. 

假设在提交PPR时没有默认内部银行账号和PPP，ORACLE PAYMENT就会寻找默认值。

假设找不到全部付款单据的默认值，PPR就会更新为“须要信息”状态。 PPR显示的信息是“须要信息-等待行动”. 
用户应该填补缺失的信息再继续执行付款流程. 

b) 付款单据验证 
代码: IBY_VALIDATIONSETS_PUB 

在此过程中，付款用基于验证的付款方法和基于验证的付款格式来验证全部的付款单据. 

b.1 - 假设全部的单据通过验证，全部的单据的状态更新为“已验证”，PPR的状态更新为‘单据已验证’. 

b.2 - 假设验证失败，Oracle Payments使用提交PPR时用到的系统配置选项确定下一步行动. 

当验证失败时，PPR的DOCUMENT_REJECTION_LEVEL_CODE用下面值确定怎样继续处理付款单据 
请求 - 拒绝此PPR的全部付款单据 
付款单据 - 仅仅拒绝有错误的付款单据 
收款人 - 拒绝与此供应商全部相关的付款单据 
无 - 停止请求以供复核 

b.2.1 – 请求  
付款过程请求的状态更新到“文件验证失败”。

Oracle Payments调出调用程序，AP释放出被拒绝的单据以使另外的付款过程请求能够支付这些单据. 

b.2.2 – 付款单据 
Oracle Payments拒绝全部验证失败的单据。

Oracle Payments调出调用程序，AP释放出被拒绝的单据以使另外的付款过程请求能够支付这些单据。其余的单据的状态更新为“已验证”，PPR的状态更新为“单据已验证”. 

b.2.3 – 收款人 
假设一个或者多个单据验证失败。则Oracle Payments拒绝该供应商全部的付款单据。Oracle Payments调出调用程序，AP释放被拒绝的单据以使另外的付款过程请求能够支付这些单据。

其余的单据的状态更新为“已验证”，PPR的状态更新为“单据已验证”. 

c) 创建付款 
代码: IBY_PAYGROUP_PUB 

已验证的付款单据依照分组规则分成建议付款，分组规则包含用户定义和系统默认组成. 

比如: 假设exclusive_payment_flag = Y，该付款单据需单独支付。 然后对该单据编号（内部识别。不是支票编号）并验证创建的付款. 

记录插入IBY_PAYMENTS_ALL。该表保存选定的付款单据的付款信息. 

创建付款程序将与支付该单据有关的付款payment_id和formatting_payment_id值更新表IBY_DOCS_PAYABLE_ALL中. 

通过栏位payment_service_request_id与IBY_PAYMENTS_ALL关联. 

主要栏位: 
Payment_service_request_id 
Payment_id 
Payment_method_code 
Payment_status 
Payments_complete_flag 
Payment_amount, 
Dicount_amount_taken 
Internal_bank_Account_id 
Ext_payee_id 
Payment_instruction_id 
Payment_profile_id 
Void_date 

当验证失败时，PAYMENT_REJECTION_LEVEL_CODE用下面值来确定付款流程怎样继续.
请求 - 拒绝此PPR的全部付款单据
付款单据 - 仅仅拒绝有错误的付款单据
无 - 停止请求以供复核

请求 - 整个PPR被拒绝。

Oracle Payments提交一个业务事件调用AP来释放这些付款单据。

付款流程请求的状态和建议的付款更新为“拒绝”. 

付款–验证失败的付款将被拒绝。AP释放出属于验证失败的付款的付款单据。接受验证通过的付款。

被接受的付款的状态更新为“建立”. 

无 - 验证失败的付款状态更新为“验证失败”，并同意用户的干预。PPR的状态更新为“等待复核” 

假设在PPR的设置中，启用选项“创建建议付款后。停止流程以复核”。则PPR状态就变更为“等待建议付款复核”。该PPR将暂停以防止进一步的处理直到用户採取行动。假设没有启用此选项，PPR的状态就变成“付款已创建”。这样的状态下，能够创建此PPR的付款指示.

格式化付款-付款

代码: IBY_PAYINTSR_PUB, IBY_CHECKNUMBER_PUB 

当提交了一个PPR以后。有两种选择 

CREATE_PMT_INSTRUCTIONS_FLAG能够是Y或者N 
Y – 当付款创建以后，付款指示自己主动生成. 
N – 应用软件程序等待提交付款指示的标准请求. 

IBY_PAYMENT_INSTRUCTIONS_ALL 存放着付款指示信息. 

假设PPR设定为自己主动提交指示。payment_service_request_id 就会更新到iby_payment_instructions_all ，程序将给PPR指定付款指示,此时这个付款指示通过 PAYMENT_SERVICE_REQUEST_ID关联到PPR. 

假设PPR正在处理子标签下设置。用户提交标准请求以建立付款指示。当指示请求提交后，付款指示通过该付款指示所选定的付款与PPR关联。这样的情况下的关联是通过 iby_payments_all.payment_instruction_id来实现的. 

IBY_PAYMENT_INSTRUCTIONS_ALL 中的主要栏位 
Payment_instruction_id 
Payment_profile_id 
Payment_instruction_status 
Payments_complete_code 
Payment_count 
Print_instruction_immed_flag 
Transmit_instr_immed_flag 
Internal_bank_account_id 
Payment_document_id 
Payment_date 
Payment_reason_code 
Payment_currency_code 

格式化: 
格式化步骤发生下面过程. 

a) 给付款编号 – 支票编号 
b) 创建XML提取信息 
c) 将提取信息传送至XML publisher 
d) Oracle XML Publisher (BI publisher) 应用格式模板 
e) BI publisher 格式化并储存输出信息 
f) Oracle Payments更新付款指示状态和付款状态。假设成功，付款和付款指示的状态为“格式化”. 

打印支票: 
a) 在这一步。用户能够将打印耗材装载到打印机上。打印支票. 
b) 确定支票打印是否成功。

假设不成功。请又一次打印.

确认付款-应付账款

代码: AP_PMT_CALLOUT_PKG 

记录支票的打印状态来确认付款。Oracle Payments调用ap_pmt_callout_pkg.payment_completed确认付款. 

包含下面步骤: 
a) 指定序号/值-文件编号. 
b) 将IBY表中对应数据更新到AP_CHECKS_ALL表中. 
Checkrun_name =IBY表中的 ppr name 。checkrun_id = IBY表中的checkrun_id. 
c) 相应支票的数据插入AP_INVOICE_PAYMENTS_ALL表中. 
d) 发票的AP_PAYMENT_SCHEDULES_ALL更新以显示付款信息和状态. 
e) 通过设定该付款计划中的checkrun_id为空值，释放PPR支付的付款单据. 
f) 更新AP_INVOICES_ALL表以显示付款状态 
g) 删除 AP_SELECTED_INVOICES_ALL 表中的数据 
h) 删除 AP_UNSELECTED_INVOICES_ALL 表中的数据 

本文转自mfrbuaa博客园博客，原文链接：http://www.cnblogs.com/mfrbuaa/p/5087144.html，如需转载请自行联系原作者