應付模塊業務操作流程
供應商管理
供應商概述
在您使用 Oracle Purchasing 之前，需要定義供應商、供應商site，以及供應商聯系人， 供應商主數據（SUPPLIER MASTER DATA，簡稱SMD）是指供應商的基本信息，是企業和供 應商進行業務往來、交易付款等必須的基礎數據，主要包括兩類信息：
A 采購數據 ——例如，供應商名稱、聯系人、地址、溝通方法等；
B 付款數據 ——例如，付款條款、銀行帳號、稅號等。
應付發票管理
應付發票基本流程
應付發票分類
標准發票: 指由於采購貨物或接受勞務，從供應商處取得的發票（標准發票，既可以和訂單匹 配 ，也可以不匹配）。
貸項通知單: 指供應商對已開發票的貨物或勞務，所開的紅沖發票。
借項通知單: 指供應商未開紅沖發票，而由自已錄入的紅沖發票。
費用報表: 指與雇員相關費用的發票。
PO缺省: 指和采購訂單匹配的發票。輸入PO號碼后，Oracle應付自動地提供供應商信息。
預付: 指為供應商或雇員支付預付款的一種發票（視為發票）。
預扣稅: 為代扣代繳稅生成的發票。
混合發票: 指既可以和采購訂單又可以和發票匹配的發票。（既可以輸入正數，也可以輸入負數）。
應付發票與采購訂單匹配方式
二維匹配：應付發票與采購訂單的數量、單價的匹配;
三維匹配：應付發票與采購訂單、接收單的數量、單價的匹配;
四維匹配：應付發票與采購訂單、接收單、入庫單的數量、單價的匹配;
系統自動采用 2-way matching與采購訂單匹配.在 Purchasing Options 窗口可選擇附加使用 3-way或 4-way matching. 可以在供應商、供應商地點更改 invoice match option。
如果發票和采購訂單在您定義的數量和價格容限內不匹配，“審批”將在發票上標記匹配掛起。必須在支付發票之前釋放掛起。
應付發票分配類型
項目: 記錄向供應商購貨或勞務收費金額
稅: 記錄購買商品或勞務而產生的稅額
運費: 記錄供應商的運輸費用
雜項費用: 記錄一張發票的各項雜項費用
應付發票 錄入及會計分錄信息
應付發票可以手工錄入或通過接口導入。與采購有關的發票需要通過匹配采購訂單生成應付發票。 根據采購項目的稅信息，會自動或手工產生稅行。
發票錄入界面(R12):
如果收到的發票價格為10。稅碼為VAT17。
采購匹配的應付發票會計分錄為：
應付帳款-應付暫估 DR 10￥
進項稅 DR 10*0.17￥
應付帳款-發票款 CR 11.7
科目的余額變化如下：
科目 初 發生 余額
應付帳款-應付暫估 10 -10 0￥
進項稅 0 -1.7 -1.7￥（應交稅費屬於負債類科目）
應付帳款-發票款 0 +11.7 11.7￥
中轉科目應付帳款-應付暫估科目的余額已結平為0。因此我們實際的應付賬款為10+10*0.17。
會計分錄信息：
(1).錄入發票
AP發票的分配記錄了所有應付暫估和預付款核銷的科目，再加上應付發票本身的應付賬款科目,分錄查詢SQL為:
View Code
(2).創建會計分錄
有兩種方式可以創建會計分錄，R12創建會計科目有三個選項可選(Draft:建立草稿，不能傳送到總帳，Final:完成會計科目創建,可傳送到總帳,Final Post:完成會計科目創建，並傳送到總帳)
1.為單筆事務處理或事務處理批創建會計分錄，單筆事務處理可通過Action創建會計分錄來完成
2.可以通過提交請求(“Create Accounting”),來創建成批的AP分錄;
創建會計分錄后，會在xla中產生分錄信息(與11i有所不同，同11i不同點將在文檔后面介紹)，可以通過如下sql查詢：
View Code
(3).傳送總帳
1.單筆事務處理或事務處理批傳送到總帳(創建會計科目時已介紹)
2.運行請求(“Transfer Journal Entries to GL”),運行完，將在總帳產生日記帳分錄,來源為je_source=’ Payables’ and je_category=’Purchase Invoices‘,總帳追溯sql查詢:
View Code
應付發票掛起和釋放
掛起的作用：
使用掛起可阻止某個發票的付款，阻止某個發票的過帳。
系統提供了許多發票掛起的理由，也可根據發票審批的需要自己定義掛起。
比如可針對供應商或供應商地點掛起，不必只針對單個發票掛起。
Hold的應用對象：
對供應商地點發票掛起；
(掛起所有付款；發票數額限制；掛起不匹配發票；掛起未來發票）
對選擇的發票掛起；
發票暫掛分類及描述:
賬戶原因 : 標識無效、不正確應付賬款負債、匯率差異或分配賬戶的發票
資金原因：使用預算控制時，在發票分配資金不足或系統不能提供資金檢查時掛起
信息不充分：對沒有匯率的外幣發票掛起
發票原因：在輸入或調整發票時可對發票人工應用掛起
匹配原因：發票違背了預定義的匹配標准
期間原因：對GL日期在將來期間的發票應用此掛起
差異原因：“分配差異”；“稅差異”；“稅額范圍”
應付貸項通知單和借項通知單
貸項通知單與借項通知單比較
貸項通知單和借項通知單的金額只能是負數；實際上應付貸項通知單與應付借項通知應應收的概念並不等同：
應付貸項通知單：指供應商開給我們的表示應付減少的通知，負數，沖原始發票，可用0支付結清；常用於做采購退貨業務，發生采購退貨業務后，在應付錄入應付貸項通知單，同時匹配退貨生 成貸項通知單行（一般為供應商開的發票）；
應付借項通知單：指我們自己開出的表示應付減少的通知，同樣是負數，沖原始發票，可用0支付結清，適用於發票做錯后的反沖。功能上它與貸項通知單基本相似。也可用於退貨業務。在采購 退貨界面有是否生成借項通知單的復選框，通過采購系統選項控制是否啟用;(一般為企業自已開的發票);
貸項通知單匹配退貨
通過應付款發票界面錄入類型為貸項通知單的應付發票，然后通過匹配采購退貨產生貸項通知單行。
對於采購退貨業務的分錄如下(與應收發票的分錄方向恰恰相反)：
應付帳款-應付暫估 CR 5￥
進項稅 CR 5*0.17￥（應交稅費屬於負債類科目）
應付帳款-發票款 DR 5.85￥
相關科目的余額變化如下：
科目 初 發生 余額
應付帳款-應付暫估 -5 +5 0￥
進項稅 -1.7 +0.85 -0.85￥
應付帳款-發票款 11.7 -5.85 5.85￥
中轉科目應付帳款-應付暫估科目的余額已結平為0。
貨的最終結果就是使庫存成本和應付賬款-發票款相應減少;這樣，退貨的最終結果就是使庫存成本和應付賬款-發票款相應減少。可以通過上面應付發票SQL查詢貸項通知單有關的分錄信息。
其它應付業務
預付款發票
供應商的預付款和員工差旅或采購的借支都可以在應付系統中作為預付款發票管理；
預付款發票可與應付發票核銷，來進行預付和應付的抵消；
預付款發票只有在付款以后才能與應付發票核銷；
標准發票的分錄有所不同，不過技術實現上是一樣的。它的分錄通常是：
預付款發票創建：
借：預付賬款/其他應收款
貸：應付賬款/其他應付款
預付款發票付款：
借：應付賬款/其他應付款
貸：現金/銀行存款
應付發票創建：
借：費用
貸：應付賬款
預付款發票核銷：
借：應付賬款
貸：預付賬款/其他應收款
應付發票導入固定資產
應付發票可以成批增加為固定資產。有兩種方式建立應付發票：
1） 直接定義固定資產型物料，其屬性不可庫存，並制定它的銷售費用科目為固定資產中轉科目。該種類型物料接收、交貨通常不會產生會計分錄，然后通過正常采購並匹配應付發票。這 時候，
應付發票的分錄應為：
DR 固定資產中轉
CR 應付帳款
2） 手工錄入應付發票，並指定發票分配科目為固定資產中轉科目。它的分錄同上。最后，在應付模塊提交請求“創建成批增加”后，則可以在FA模塊成批增加資產。最終過賬后，會形成如 下分錄。
DR 固定資產
CR 固定資產中轉
固定資產中轉科目結清為0;
FA創建會計分錄后，有關固定資產的分錄信息查詢sql:
View Code
手工應付發票
應付除了用於與采購模塊集成外，還可以通過應付發票做些其他的雜項業務。記錄些與采購無關的業務。
例如:員工費用報銷…
會計分錄信息:
招待費 DR
其他應付款 CR
未上線網上報銷模塊時常常如上手工建立應付發票實現員工報銷
費用報表
費用報表是網上報銷模塊導入的一種類型的應付發票，當網上報銷流程結束並審核通過后，可以通過請求“導入費用報表”導入應付發票。
除了與標准應付發票的科目有所不同。其他作用等同於標准應付發票。
企業報銷的分錄通常如下：
員工報銷科目 DR
其他應付款-報銷 CR
付款管理
付款概述
發票生成並驗證通過以后，可以對發票進行付款。
可以在發票界面通過快速付款，付款界面錄入人工付款，或者進行批付款對發票進行批量付款。批付款常應用於員工報銷付款。
在付款界面，將藍票（應付發票）和紅票（貸項通知單）選入到同一個付款，進行付款。
付款的約定：
必須通過 “銀行帳戶” 支付，必須使用付款單據及單據號。
只能對供應商付款。
付款必須指定發票，且所選發票核銷總額必須與付款金額相同。
付款方式:
支票(Check): 發送給供應商的支票
結清(Clearing): 支付從公司其他實體轉來的發票，無需建立付款單據
電子(EFT): 電子轉賬至供應商開戶銀行
電匯(Wire)
付款錄入及會計分錄信息
對發票付款，實際上就是用現金支付應付欠款，現金與應付款都減少;
單筆收款錄入價面，批付款在文檔后面有介紹:
應付帳款-發票款 DR 5.85￥
銀行存款 CR 5.85￥
相關科目的余額變化如下：
科目 初 發生 余額
應付帳款-發票款 5.85 -5.85 0￥
銀行存款 100 -5.85 94.15￥
付款產生的會計分錄信息:
View Code
付款會計分錄傳送到總帳
跟前面講述的發票傳送總帳方式比較類似,產生的總帳信息為：來源為je_source=’ Payables’ and je_category=’ Payments ‘。
應付模塊11i跟R12差異比較
子分類帳差異
R12新增加SLA模塊用來管理子分類帳；請參照<<SLA專題>>了解詳細內容;
(1).子分類帳相關表變化
| 11i |
R12 |
| ap_accounting_events_all |
XLA_TRANSACTION_ENTITIES |
| ap_ae_headers_all |
XLA_EVENTS |
| ap_ae_lines |
XLA_AE_HEADERS |
|
|
XLA_AE_LINES |
(2).應付發票子分類帳SQL（其它類似，以應付發票為例）
11i:
View Code
R12
View Code
子模塊追溯
R12下總賬追溯子模塊比11i簡單統一了很多，通過gl_import_reference表
應付發票子模塊追溯SQL（其它類似，以應付發票為例）
11i:
View Code
R12
View Code
其它差異
- R12新增加ap_invoice_lines表；
官方解釋：
Oracle Payables introduces invoice lines as an entity between the invoice header and
invoice distributions. With the new model, the invoice header remains unchanged, and continues to store information about the supplier who sent the invoice, the invoice attributes, and remittance information.Invoice lines represent the goods (direct or indirect materials), service(s), and/orassociated tax/freight/miscellaneous charges invoiced. Invoice distributions store theaccounting, allocation and other detail information that makes up the invoice line. Thecharge allocation table used in prior releases to manage accounting allocations is obsolete.During the upgrade, Oracle Payables creates invoice lines for all existing invoices,creating one line for every distribution available in the Release 11i distributions table,except in the case of reversal pairs. In those cases, Payables creates one line with a zero amount.
- 供應商銀行信息表變化
| 11i |
R12 |
| AP_BANK_ACCOUNTS_ALL |
IBY_EXTERNAL_PAYEES_ALL |
|
|
IBY_EXT_BANK_ACCOUNTS
|
|
|
IBY_PMT_INSTR_USES_ALL
|
- 付款銀行表變化
| 11i |
R12 |
| AP_BANK_ACCOUNTS_ALL |
CE_BANK_ACCOUNTS |
| AP_BANK_ACCOUNT_USES_ALL |
CE_BANK_ACCT_USES_ALL
|
| AP_BANK_BRANCHES |
CE_BANK_BRANCHES_V
|
取付款銀行信息sql(R12):
View Code
4.供應商表變化
| 11i |
R12 |
| PO_VENDORS |
AP_SUPPLIERS |
| PO_VENDOR_SITES_ALL |
AP_SUPPLIER_SITES_ALL
|
| PO_VENDOR_CONTACTS |
AP_SUPPLIER_CONTACTS
|
5.Payment Documents 表變化
| 11i |
R12 |
| AP_CHECK_STOCKS_ALL |
CE_PAYMENT_DOCUMENTS |
取Payment Documents SQL（R12）:
View Code
6.Payment Batch
表變化:
| 11i |
R12 |
| AP_CHECKS_ALL |
AP_CHECKS_ALL |
| AP_INV_SELECTION_CRITERIA_ALL |
AP_INV_SELECTION_CRITERIA_ALL |
| AP_SELECTED_INVOICES_ALL |
AP_SELECTED_INVOICES_ALL |
| AP_SELECTED_INVOICE_CHECKS_ALL |
IBY_PAY_SERVICE_REQUESTS |
|
|
IBY_PAY_INSTRUCTIONS_ALL |
|
|
IBY_PAYMENTS_ALL
|
批付款操作界面變化:
11i:
7.稅
R11版本按照設置稅碼稅率計算稅；在R12版以后，在計稅方面有了重大改變，稅也成為一個獨立的模塊。其計稅的邏輯也從以前單純的稅碼和稅率的關聯轉換為通過稅則，來建 立會計分類代碼（fiscal classification code）與稅率的聯系。會計分類代碼可以應用至交易方（Party）、產品（Product）以及事務處理（Transaction）之上。 具體介紹請參 照<<TAX專題>>
官方解釋：
Oracle E-Business Tax manages tax across the E-Business Suite. In prior releases, the
setup, defaulting, and calculation of tax for Payables was managed within Payables
using tax codes, their associated rates, and a hierarchy of defaulting options. This method is still available in this release. During the upgrade, E-Business Tax migrates the tax codes as appropriate within E-Business Tax so that your tax processing can work the same way after the upgrade as it did before.New fields are added to the supplier, invoice, and invoice lines entities to track tax attributes used by E-Business Tax. Many of these attributes were implemented withglobal descriptive flexfields in prior releases and are upgraded to regular fields on these entities.
表變化:
| 11i |
R12 |
| AP_TAX_CODES_ALL |
ZX_LINES_SUMMARY |
|
|
ZX_LINES |
|
|
ZX_RATES_TL |
PO稅查詢sql:
View Code
AP Invoices應付發票【Open Interface】
以R12為例，具體介紹應付發票導入，R12導入應付發票較11i有部分不同，比如:
11i,ap_invoice_lines_interface彈性域寫入發票分配行，r12默認寫入發票行，可能過profile設定，把行上的彈性域帶到分配行上，profile:AP_COPY Invoice Lines Flex fied 設為Y;
發票稅導入：
11i通過稅碼，稅率產生稅，R12按照發票行上的稅信息產生稅，具體的規則見下表：
|
|
ITEM1 |
ITEM2 |
TAX1 |
TAX2 |
| LINE_NUMBER |
1 |
2 |
3 |
4 |
| LINE_GROUP_NUMBER |
1 |
2 |
1 |
2 |
| TAX_REGIME_CODE |
The set of tax rules that determines the treatment of one or |
|||
| TAX |
A classification of a charge imposed by a government through a fiscal or tax authority. |
|||
| TAX_RATE_CODE |
Tax rate name associated with tax rate identifier |
|||
| TAX_STATUS_CODE |
Tax status code |
|||
| TAX_JURISDICTION_CODE |
Internal ID of the Tax Jurisdiction |
|||
| TAX_RATE |
TAX_RATE |
|||
| TAX_RATE_ID |
TAX_RATE_ID is unique while the TAX_RATE_CODE may have different tax rates based on date ranges |
|||
| PRORATE_ACROSS_FLAG |
Y |
Y |
Y |
Y |
接口表，錯誤信息表
| 接口表 |
數據表 |
說明 |
|
|
|
|
| ap_invoices_interface |
ap_invoices_all |
AP頭 |
| ap_invoice_lines_interface |
ap_invoice_distributions_all |
AP行 |
| ap_interface_rejections |
|
錯誤信息表 |
並發程序Payables Open Interface Import
| 參數 |
說明 |
|
|
|
| Operating Unit |
ou |
| Source |
來源 |
| Group |
組ID，放空代表全部 |
| Batch Name |
批名 |
| Hold Name |
放空即可 |
| Hold Reason |
放空即可 |
| GL Date |
放空即可 |
| Purge |
Y，是否刪除成功導入的記錄 |
| Trace Switch |
N，是否啟用Trace，隱藏的參數 |
| Debug Switch |
N，是否啟用調式信息，隱藏的參數 |
| Summarize Report |
N，是否打印匯總報表，隱藏的參數 |
| Commit Batch Size |
放空即可，隱藏的參數 |
| User ID |
放空即可，隱藏的參數 |
| Login ID |
放空即可，隱藏的參數 |
關鍵字段
ap_invoices_interface
| 字段 |
說明 |
|
|
|
| org_id |
經營單位ID |
| invoice_id |
來自ap_invoices_interface_s |
| invoice_num |
發票號 |
| invoice_type_lookup_code |
STANDARD是標准發票，CREDIT是Credit Memo |
| invoice_date |
發票日期 |
| vendor_id |
供應商ID |
| vendor_site_id |
供應商地點 |
| invoice_amount |
發票金額 |
| invoice_currency_code |
發票幣種 |
| exchange_xxx |
如果是外幣，需要輸入匯率類型、日期、匯率 |
| SOURCE |
來源，來自快速編碼SOURCE |
| group_id |
組ID，可直接用invoice_id |
| 5個who字段 |
習慣上都給 |
ap_invoice_lines_interface
| 字段 |
說明 |
|
|
|
| org_id |
經營單位ID |
| invoice_id |
=ap_invoices_interface.invoice_id |
| invoice_line_id |
來自ap_invoice_lines_interface_s |
| accounting_date |
財務日期 |
| line_number |
行號 |
| line_type_lookup_code |
行類型 |
| amount |
金額 |
| dist_code_combination_id |
賬戶ID |
| 5個who字段 |
習慣上都給 |
View Code
AP常用API
使用API可在開發中得到便利，下面介紹AP模塊幾個常用的API:
AP_INVOICES_PKG
AP_INVOICES_INTERFACE_PKG
AP_INVOICE_LINES_INTERFACE_PKG
AP_IMPORT_INVOICES_PKG
AP_IMPORT_VALIDATION_PKG
R11
R12
附 ：R12中子模塊的帳是如何產生的
1) 在FORM:ARXRWMAI 的按鈕 SLACEXEC.OK_BP 觸發器中有提交創建的代碼:
arp_sla_submit.which_case;
2)包arp_sla_submit在pll文件ARSLAOLS.pll中。
3)在arp_sla_submit.which_case中執行以下過程，將FORM界面上的信息傳入過程
submit_xla_accounting
4) submit_xla_accounting過程調用以下數據庫package創建會計科目
XLA_ACCOUNTING_PUB_PKG.accounting_program_document
5)在XLA_ACCOUNTING_PUB_PKG中根據p_offline_flag的取值，分別調用
xla_accounting_pkg.accounting_program_document
或者調用創建會計科目的請求
6)在xla_accounting_pkg中調用下面過程
xla_accounting_pkg.accounting_program_events
7)在events_processor在調用handle_accounting_hook調根據application_id分別調用
CASE
WHEN p_application_id = 200 THEN
xla_ap_acct_hooks_pkg.main
WHEN p_application_id = 222 THEN
xla_ar_acct_hooks_pkg.main
WHEN p_application_id = 140 THEN
xla_fa_acct_hooks_pkg.main
WHEN p_application_id = 260 THEN
xla_ce_acct_hooks_pkg.main
WHEN p_application_id = 555 THEN
xla_gmf_acct_hooks_pkg.main
WHEN p_application_id = 801 THEN
xla_pay_acct_hooks_pkg.main
ELSE
END CASE;
其中event_name為extract。然后調用arp_xla_extract_main_pkg.extract 來取子模塊的分配。其主要作用是將來自子模塊的分配。AR的發票、調整、收款、核銷等子模塊的帳的分配插入 ar_xla_lines_extract臨時表，在這個package中可以看到xla是如何從業務模塊數據取數的。