GV有兩筆重複的憑證號碼存在

這個發生的情況為憑證類別為海關代徵營業稅，使用者在不同發票上輸入相同的憑證號碼，資通的顧問說畫面上會提示，但允許存檔。 如果發現相同的話，如果 ap invoice 作刪除，也要順便把 GV的那一作刪除才行。

Oracle EBS R12 Doc ID 1489862.1 R12 Generic Data Fix (GDF) Patch for COMMONLY OCCURING INVOICE ISSUES 無法解決 Mat 3

前一陣子有用 single_trx.sql找出一筆 invoice需要作 data fix，使用 ap_one_off_scripts_sel(fix).sql來解決，於更新了 patch也執行了 fix程式，但此筆的問題還是存在，而且重新執行 single_trx.sql還是會建議你用相同的 datafix 解決，後來可行的作法就是
1.先請使用者先將 invoice line作 discard後存檔
2.我再跑一次 single_trx.sql，結果發現另一個 datafix的建議 R12: Generic Data Fix (GDF) Patch - Unable to Discard PO Matched Invoice Lines [ID 982072.1]
3.執行  ap_sync_po_qty_amt_sel(fix).sql後
4.重新 match就正常了。

Oracle EBS R12 AP Invoice Hold Troubleshooting

可參考如下連結：12: Invoice HOLDS: Causes and Troubleshooting [Video] (Doc ID 1472606.1)

今天有碰到使用者問我一張 invoice有一個 Matching Required的 hold，但我沒遇過，所以找到這篇文件，上面有寫到 supplier site設定上有一個參數 Unmatched Invoices 如果有打勾，代表 invoice line一定都要經過 match產生才可以，如果手動增加且沒有match就會出現這個 hold。  如果還有其它 hold的問題可以來這邊找找看如何解決。

Oracle EBS R12 為何更改 AP Invoice date但 due date確不會自動更新

請至 supplier設定功能先檢查 Invoice Management ==> Term ==> Terms Date Basis是不是有設定正確，如果想要更改 invoice date後 due date就會自動更新的話，請把它設為 Invoice，其它值的話，請就參考下列的文章



參考文件：R12: How is a Payables Invoice Due Date Calculated? (Doc ID 1136143.1)

已收料但後來 cancel 的 po還可以作退料嗎

跟據原廠的文件，答案是 no cancel line or line 是 final close的狀態，就不能作任何收退料的交易了。

Use the Receiving Returns window to return delivered items to receiving and to return received or delivered externally sourced items to the supplier if the purchase order has neither been cancelled nor final closed.

Build Payments 出現 ORA-06502

使用者在作大批付款 Payment Process Request，當執行到 Build Payments出現錯誤
view log 如下

Ｅxception occured when building payments. Payment creation will be aborted and no payments will be committed for payment request 146440
SQLCODE: -6502
SQLERRM: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
Build program error: Exception occured when attempting to create payments from the documents payable of the provided payment service request.

可能是 bug所造成的，但這一次不是
我的作法如下
1.啟用 FND Log机制
2.請使用者再作一次 Payment Process Request
3.檢示 FND Log 出現 ORA-06502的地方，找出 party id，再利用 party id找出是那一個 supplier
4.至 supplier維護畫面，看看 bank detail是否有些問題

最後被我找到是使用者把 bank account number和 bank account name的值相反了，而 account number太長了，所以造成錯誤。  請使用者把資料改成正確即可。

Voided 的 Payment 是否會拋至 NM

Voided 的 Payment 是否會拋至 NM ?

這要看 void前是否已經拋至 NM，如果使用者在一筆 Payment還沒作 void時已經拋至 NM的話，那之後再作 void，則 NM就會相對應產生一筆負數的資料。

如果使用者先 void一筆 Payment後再作 NM拋轉的動作，則這一筆就不會拋至 NM。

Fully Applied prepayment but status showed Available

目前有碰到過一張 prepayment 已經 fully applied了，但 status還顯示 Available，有作一些 data fix，但還是沒用，最後 oralce consultant建議 update ap_invoice_distributions_all將欄位 PREPAY_AMOUNT_REMAINING的值改為 0 就可以了。

如何取消void prepayment 的付款

Prepayment invoice, and it has been fully applied. Therefore, the check can be Voided only after the prepayment has been unapplied.

如果是 prepayment的發票且狀態是 fully applied的話，要先將此發票作 unapplied 的動作，其付款 payment才可以作void.

Oracle EBS R12 資料一直卡在 AP_Invoices_Interface無法拋轉

如果資料一直卡在 AP_Invoices_Interface無法拋轉，而且 Rejection Report 也沒有資料的話，可以開啟 FND Log再跑一次 Payables Open Interface Import Program，如果有 log 有出現
IBY_DISBURSE_SUBMIT_PUB_PKG.deriveExactPayeeIdFromContext: Fatal: Exception when attempting to perform exact match for given payee context.
IBY_DISBURSE_SUBMIT_PUB_PKG.deriveExactPayeeIdFromContext: SQL code: -1422
IBY_DISBURSE_SUBMIT_PUB_PKG.deriveExactPayeeIdFromContext: SQL err msg: ORA-01422: exact fetch returns more than requested number of rows
IBY_DISBURSE_SUBMIT_PUB_PKG.deriveExactPayeeIdFromContext: EXIT
IBY_DISBURSEMENT_COMP_PUB.Get_Default_Payment_Attribute : ERROR: Exception occured during call to API 
IBY_DISBURSEMENT_COMP_PUB.Get_Default_Payment_Attribute : ERROR: Exception occured during call to API 
IBY_DISBURSEMENT_COMP_PUB.Get_Default_Payment_Attribute : SQLerr is :ORA-01422: exact fetch returns more than requested number of rows
IBY_DISBURSEMENT_COMP_PUB.Get_Default_Payment_Attribute : SQLerr is :ORA-01422: exact fetch returns more than requested number of rows

請下載 Patch:13857555:R12.AP.B for 12.1 (

R12: Generic Data Fix (GDF): Duplicate Payee in IBY_EXTERNAL_PAYEES_ALL [ID 1315812.1]

)

後執行 data fix‧

不應帶稅的 AP Invoice 處理方式

可能因為 supplier 設定上的錯誤，造成原本沒有稅的 AP Invoice 產生了一筆 tax 的 line，處理的方式為兩種

1. 在 AP Invoice Line將 Tax Classification Code 清空後再執行 calculate tax，這樣 tax line的金額就會變成 0

2.將整張 AP Invoice cancel，再請倉管人員作 return to supplier後，請採購人員將 PO打開，執行 Actions - Manage Tax ，將 Tax Classification Code 刪除或清空後，再請倉管人員作收料後，重新拋轉至 AP的 Invoice就會沒有 tax line了

關於 po_line_locations_all QUANTITY 開頭的欄位

po_line_locations_all  儲存的是 PO Shipment的資料。

QUANTITY：屬於該 shipment的訂購量


QUANTITY_RECEIVED：為倉庫人員作暫收的數量

QUANTITY_ACCEPTED：為倉庫人員(驗收)入庫的數量

QUANTITY_REJECTED：為倉庫人員作 return to supplier的數量

QUANTITY_BILLED ：有轉成 AP Invoice 的數量

QUANTITY_CANCELLED ：採購人員 cancel 的數量

如何加大 OAF DataGrid 資料列數

OAF 的網頁如果有 DataGrid 的話，預設顯示最多列數為 200筆，可是財務部份在作大批付款 Payment Process Request時，筆數一家超過 200，要修改資料時就會造成不便，所以要至

administrator - system  profile
FND: View Object Max Fetch Size  目前設定為 1000

AP Invoice Validation 執行時出現錯誤

檢查 Invoice Validation view log看看有沒有 busy的字出現，如果有，可能是同時間 Pay On Receipt也在執行就會有這種情況發生，如果沒有，可能就是 bug.

AP 費用暫估 - Receipt Accrual Period-End 金額不正確或金額過小

a.    檢查上個月的 PO Period (上一期已關帳的 PO)是否已關閉，如果沒有請先關閉再重新執行費用暫估報表

b.    如果本月的 PO Period(這個月要關帳的 PO)已關閉的話，請把它再打開再執行費用暫估報表，但這個月就會有重複的暫估資料存在，必需要把原先有問題的那一筆在當有作 reverse

   參考文件：Duplicate accrual accounting entries created when period end program was run more than

once [ID 873394.1]  

     

If the Receipt Accrual Period-End program is run twice, and in between the period was closed and

re-opened :

     In this case duplicate entries do get created, because the period end POs which got accrued will have the flag in

po distributions, po_distributions_all.accrued_flag set to Y(資訊部人員在跑暫估報表時可以檢查是有有 Y的資料出現，如果有應該是不正常的). Once this period is closed, all these flags will

be reversed to N so as to make these POs eligible for accrual in the next period. 

     Now if the closed period is reopened and the period end program is re-submitted in the same period, the

POs  that were accrued in the first run, after the closing of the period will have the  accrued_flag changed to N,

hence these POs will be re-considered for accrual for the second run  again.

Oracle EBS R12 Invoice Validation 客製 (customize)

 在 Oracle ERP AP的標準 Invoice Validation報表中，使用者可以針對如 Batch Name 等條件去作 validate的動作，但以會計人員的角度是以每一張 Invoice 角度來看，不是各別 batch name or supplier，所以我們會在 Invoice Header上增加一個彈性欄位，值為 Y or N，當會計人員經作業流程確認這張 Invoice沒有問題之後，才去維護這一個彈性欄位，把值設為 Y。

接下來就是客製 Invoice Validation 的部份，在 R11來說是會 copy  APXAPRVL.rdf這一隻報表來改，相對來說比較簡單，只要加上 sql where string 將彈性欄位為 Y值作 validate即可。而使用者只能執行客制報表，不可以執行標準的 Invoice Validation。

為什說比較簡單呢，因為公司的政策是，如果需要客製的話，不可以直接改寫原廠的程式，必需是要作 Clone  ，再來改寫，而使用者就執行改寫的那隻報表。

但導入 R12時，原本想說應該也是這麼簡單，但很快地就發現我錯了。  因為在 R12，sql string 不是放在 Report 內，而是放在 AP_APPROVAL_PKG.pck 內，要改只能在這邊修正，可是公司的政策是，如果需要客製的話，不可以直接改寫原廠的程式，必需是要作 Clone  ，再來改寫，而使用者就執行改寫的那隻報表。   所以只能把 AP_APPROVAL_PKG.pck clone後，再拿來改，可是改完再 compile時，客製的 approve 程式出現了一堆錯誤，花了些時間檢查，又發現到 Oracle 原廠在開發這些 package時有用到類似物件導向的方式。pacakge A會使用 package B的變數， package B又會用到 package C 的變數，所以不得已，又去 Clone好幾隻原廠程式來改，總共 Clone  

     AP_ETAX_PKG.pck  

     AP_ETAX_SERVICES_PKG.pck

     AP_APPROVAL_MATCHED_PKG.pck

拿來改，改到 compile 都沒問題，且在測試 invoice validate 時沒有問題就上線。

因為 R12導入方式是全新導入，而非升級，且導入時 AP這邊沒上什麼 patch，所以導入後一大堆問題跑出來，需要上 patch來作 data fix or root cause fix，當初因為 clone出來而改寫的 package可能都有 bug 存在，所以客製  invoice validation 相關的程式就需要重新再改寫，如果有上的 patch有更動到這些 package的話，我又要再改寫一次。      這種方式真是爛透了，而且也不保證就一定正確，最後會陷入一種情境就是 作呷流汗，嫌呷流口水，吃力不討好。   所以就跟 ERP管理者討論是否可以直接修改原廠程式  AP_APPROVAL_PKG.pck 即可，討論之後的結果是 OK，那就著手進行修改。

可是另外一個問題來了，如果下次上 patch 時有更改 AP_APPROVAL_PKG.pck 時， 程式碼會被更新，自己加上的 where 條件就會不見了，造成每一張 Invoice 都會被拿來作 validate，所以要將客製的 APXAPRVL.rdf加上檢查條件，判斷 AP_APPROVAL_PKG.pck 的程式版本是否有更新，如果有的話，就不執行 validate並丟出一個錯誤讓使用者知道。作法如下

1. 建一個 table 記錄 AP_APPROVAL_PKG.pck 程式的版本，代表這個版本是你有修改過的。

2. 客製的 APXAPRVL.rdf加上檢查條件

    在BeforeReport 內讀取  AP_APPROVAL_PKG.pck的版本

    SELECT trim(text) into AP_APPROVAL_PKG_VER_Current

FROM dba_source  WHERE line = 2 AND type LIKE 'PACKAGE%'

and name ='AP_APPROVAL_PKG' AND owner = 'APPS'

and type = 'PACKAGE BODY'

ORDER BY name, type;

       再比對 兩個程式的版本，如果不同，代表可能有上 patch把程式更新了，這時再重新到      AP_APPROVAL_PKG.pck 把 where clause 加上即可 ，沒有問題後，更新  table 記錄 AP_APPROVAL_PKG.pck 程式的版本。

AP Payment Accounting 的條件

ap_invoice_payments_all欄位 Posted_flag, 如果此 check_id的posted_flag = Y，accounting 才會是 
Proceeded.

AP Invoice 相對應的 PO沒有作驗收但Hold卻沒有 Quality Hold

1.檢查對對應的 PO line shipment Item 的資料，Match approval Level是否為3-way，如果是代表不檢驗即可入庫，所以沒有 Quality Hold是正常的，如果不是 (4-way)可能就是系統的問題了。

原廠文件 FAQ - ORACLE PURCHASING [ID 1264331.1]

       2-way matching verifies that Purchase order and invoice information match within your tolerances as follows: 

       Quantity billed <= Quantity Ordered Invoice price <= Purchase order price (<= sign is used because of

tolerances) 

3-way matching verifies that the receipt and invoice information match with the quantity tolerances defined: 

       Quantity billed <= Quantity received 

4-way matching verifies that acceptance documents and invoice information match within the quantity tolerances

defined: 

       Quantity billed <= Quantity accepted.

Oracle EBS R12 Pay On Receipt AutoInvoice 出現錯誤

每天定時執行的 Pay On Receipt AutoInvoice，居然出現錯誤(其實是 Payable Open Invoice Import)，造成從收料那邊過來的無法產生發票，怎麼會每天順順的，今天就有問題，花了很多時間檢查，加上使用者在 AP 手動新增 Invoice 時，也出現了一個問題。
APP-SQLAP-10000: ORA-00001: unique constraint .......的問題

所以直接去查詢 table ap_payment_schedules_all 的資料才發現到有很多的怪資料存在，原來是當初在導入 R12時，顧問直接把 R11的舊資料直接 insert至 R12上了，所以作法是把這些舊資料刪除即可，不過記得選擇好導入的顧問真的很重要，上天堂或是天天加班的日子就要靠他們了。

Oracle EBS R12 Data Fix - undo accounting 注意事項

導入 ERP R12快滿一年了，負責模組 AP/GL/PO/NM/FA/GUIVAT
最多問題且花最多時間就是 AP 模組，當初顧問在幫忙導入的時候並沒有告知或建議那些重要的 patch要先 apply ，導致在上線後，使用者一直在告訴我那些操作或資料有問題，而我就一直到 oracle support 找文章，  create SR，我建立的 SR 跟別人比的話是用倍數計算的。 所以這邊先分享一個關於執行 Data fix 如果會 undo accounting的注意事項。

1.  如果 undo accounting 在不同的月份，在當月會產生一正一負的會科(reverse)，也會可能會產生匯兌損益的會科出現，會計人員要在 GL手動調帳。

2.   如果要在當月執行但已關帳的情況下，要打開 GL, AP, PO的 Period，作完之後再關閉