接下來就是客製 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 程式的版本。
沒有留言:
張貼留言