Oracle EBS: AP invoice稅額未正常帶出

問題: AP invoice稅額未正常帶出

狀況:
1.費用性PO上只有一個item, PO上的稅別及稅額正確
2.AP invoice上兩個line, Type分別是Item及Tax, 但Tax amount是0
3.Tax line上的Prorate Across All Item Lines未打勾
4.Invoice上Genenal頁籤的Total欄位金額未包含稅額, 且以紅色字體顯示

測試:
1.直接按[Calculate Tax], 無效
2.以Examine功能把Prorate Across All Item Lines打勾, 再按[Calculate Tax], 無效

最後解法, 直接改Tax Amount:
1.改Tax Line的Distributions中Amount
2.改Tax Line的Tax Amount
  改了以上兩項後, General頁籤上的Tax仍是0
3.按[Tax Details], 改其中的Tax Amount

改完, 看起來數字是對了, 但Distributions中的Tax有6筆資料, 其中5筆是0, 希望不會有其他問題.   -__-

Oracle EBS: PR未送簽核通知信給主管

狀況:
1.PR開立後送簽, 主管未收到系統通知信
2.hirarchy設定正確, 主管在ERP worklist有看到待簽PR,  簽核也正常
3.email server沒有送信記錄, 所以不是user忽略了通知信


處理過程:
1.查帳號的preference, 其中mail style設定為Disable, 改為HTML mail, 狀況依舊
2.查帳號中的email address, 有錯, 多了個字母, 已修正, 狀況依舊
3.查看Employee中設定的email, 是正確的


在覺得沒救時, 突然想到hz_parties table.

以employee中的party_id查hz_parties, email_address欄位是空的, 可能當初email資料真的有問題, 但沒有完整修正.

補上後請user再試, 還是有問題.


最後解法:
在Employee和User的設定畫面上, 清空email, 存檔, 再填入email, 存檔. 好了.   -__-

Oracle EBS: PO送簽時出現PO_EMAIL_ADD_SINGLE error

狀況: 在PO送簽時, 有手動填入email address, 要approve時, 出現PO_EMAIL_ADD_SINGLE error

原因: email中包含特殊字元. 以這次的資料來說, 是有個 & 符號.

解決方式: 修改email address


Oracle所提供說明如下:

Ref:
1.POXPOEPO: Can Multiple Supplier E-Mail Addresses Be Entered On The Approval Submission Form of the Buyers Work-Bench ? (Doc ID 1665583.1)

Oracle EBS: 使用 po_actions.close_po API 來 close BPA

試了試, 跟close PO相似, 不難.

    v_value := po_actions.close_po (p_docid       => r1.po_header_id,

                              p_doctyp          => 'PA',
                              p_docsubtyp       => 'BLANKET',
                              p_lineid          => r1.po_line_id, --
                              p_shipid          => null , --r1.line_location_id,--
                              p_action          => 'CLOSE',
                              p_reason          => '因應改為議價',
                              p_calling_mode    => NULL,
                              p_conc_flag       => 'N',
                              p_return_code     => v_return_code,
                              p_auto_close      => 'N',
                              p_action_date     => sysdate, --NULL,
                              p_origin_doc_id   => NULL);


但太久沒執行這類API, 忘了先執行前置動作, 多花了一些時間:

  fnd_global.apps_initialize (user_id => 1,

                              resp_id => 201,
                              resp_appl_id => 53289);


再加個cursor就批次作完了~

Oracle EBS: APP-PO-14694: This doucment is not updateable.

狀況: user更改PO資料時, 出現APP-PO-14694的訊息, 無法作業

  APP-PO-14694: This doucment is not updateable.

  Cause: You have tried to update a document that is currently not updateable.

  Action: No action required.

原因: PO_ACTION_HISTORY table中的Action History記錄, 有 NULL action_code

解決方式:
1.在Purchase Order Summary中查出PO
2.以 Tools -> Control 功能作 On Hold
3.儲存
4.再次使用 Tools -> Control功能, 作 Release Hold , 並儲存
4.完成


Ref:
1.[PO.Purchase Order.ISSUE] APP-PO-14694: This doucment is not updateable.
http://sammijou.blogspot.com/2014/07/app-po-14694-this-doucment-is-not.html

2.Unable to Update Approved Purchase Order Due to APP-PO-14694 Error (Doc ID 402206.1)

Oracle EBS: WIP Pending Resource Transactions中的資料停在Pending, resubmit無效

問題: WIP Pending Resource Transactions中的資料停在Pending, resubmit無效

狀況:
1.Pending Resource Transactions中的資料停在Pending, 沒有error
2.只有在特定時間的兩個工單資料有此狀況
3.group_id有值, transaction_id是空的
4.後續進來的交易沒有問題
5.resubmit沒用

解法: 在table中把狀態改為error, 再resubmit, 好了.   :O


目前看來, 可能是原先資料異常, 導致未被處理, 改成error後反而符合要處理的條件.


有篇文章沒派上用場, 但還是記一下:

Oracle WIP Jobs Pending Resource Transactions, Pending Transactions in WIP_COST_TXN_INTERFACE Table
https://oracleappsdna.com/2011/07/oracle-wip-jobs-pending-resource-transactions-pending-transactions-in-wip_cost_txn_interface-table/

Oracle EBS: 設定為incompatible的程式, 已submit後要改為可同時執行

先說解法:

  在 Conflict Resolution Manager 上, 點擊 [Verify] 按鈕

Conflict Resolution Manager的Status欄會出現 Verifying 訊息, 待系統處理完後, 就會依現有設定檢查是否程式互斥, 已submit的程式也會變更為可同時執行.

這方法先前有試過, 不知為何無效, 再作一次就有成果, 是時間差還是業障太重.


再來說說走了哪些冤枉路:

1.直接修改fnd_concurrent_requests的queue_method_code和crm_tstmp欄位('I', null), 結果是concurrent不會被執行, 改回才正常

2.直接修改fnd_concurrent_requests的status_code和crm_release_date('I', sysdate), 沒用, 因為過沒多久又被系統改為原值


Ref:
Removed Incompatible To Itself But Still Runs Serial, Not Parallel : Must Use Conflict Resolution Manager > Verify Button (Doc ID 2448116.1)

Oracle EBS: 庫存由費用倉轉至資產倉

在系統上有個profile:

  INV: Allow Expense to Asset Transfer

設定為No , 代表不允許費用倉轉至資產倉.

設定為Yes , 則允許費用倉轉至資產倉.

Oracle EBS: AR關帳問題 (Credit Memo Incomplete)

狀況: user關帳執行Subledger Period Close Exception Report, 在Receivable有幾筆Credit Memo的Status是Incomplete.

嘗試單純的方式, 以Examine在Form上直接把complete_flag改為N, 存檔時出現APP_AR_11017 error , 失敗.

搜尋一些文章, 有個del_orphans_xla_120.sql可用, 但Oracle support上可能已把這檔案移掉, 找不到了.

最後處理方式:
1.以SQL找出orphan record, 比對與出問題的那幾筆相符
2.針對其中一筆以diagnostics功能查看資訊, XLA_EVENTS出現兩列資料, 其中一列的event_status_code和process_status_code都是P (10/4建立), 另一列則分別是I和U (10/15建立)
3.為避免刪資料會有問題, 直接把event_status_code和process_status_code都改為P
4.重跑Subledger Period Close Exception Report, 已無異常資料

不知是否會有其他影響, 後續再觀察.


SQL: Orphan records

select xte.*, --xte.source_id_int_1 source_id,

       users.user_name user_name
  from xla_events xe,
       xla.xla_transaction_entities xte,
       fnd_user users
 where xe.created_by = users.user_id
   and xte.entity_code = 'TRANSACTIONS'
   AND xte.upg_batch_id is NULL
   and xte.entity_id = xe.entity_id
   and xte.application_id = 222
   and xe.application_id = 222
   and xe.event_status_code not in ('P','Z')
   and not exists
     (select 'x'
        from ra_cust_trx_line_gl_dist_all dist
       where dist.customer_trx_id = xte.source_id_int_1
         and dist.posting_control_id = -3
         and ((dist.event_id is null
               and not exists (select 'x'
                                 from ra_cust_trx_line_gl_dist_all dist2
                                where dist2.customer_trx_id = dist.customer_trx_id
                                  and dist2.account_set_flag = 'N'
                                  and dist2.latest_rec_flag = 'Y'
                                  and dist2.account_class = 'REC'))
             OR
             dist.event_id = xe.event_id)
      union
      select 'x'
        from ar_receivable_applications_all
       where customer_trx_id = xte.source_id_int_1
         and posting_control_id = -3
         and event_id = xe.event_id
      union
      select 'x'
        from ar_receivable_applications_all
       where applied_customer_trx_id = xte.source_id_int_1
         and posting_control_id = -3
         and event_id = xe.event_id
     )
 

Ref:
1.Orphan Records In XLA_TRANSACTION_ENTITIES table (Doc ID 1066982.1)
2.How to Find Orphan Records in Subledger Accounting Related to Oracle Receivables? (Doc ID 549020.1)

Oracle EBS: SQL類型concurrent program的註解問題

問題: SQL程式排程每天執行, 但改掉了不該更改的資料

狀況:
1.concurrent正常執行完成, 但應該不更動的資料被改了
2.直接在Toad執行, 結果符合預期
3.SQL很單純, 只針對一個table, where條件有四項

原因: 中文註解造成程式誤判

處理方式: 把原先第二個where條件後的中文註解移到最後面, 好了


這問題太詭異, 逐項測試才找到, 中文註解為:

  兩個 Table 出現大小寫不一的案例，因此全用 Upper 比較，才不會漏改


看起來很正常, 卻讓concurrent不正常, 目前有只有遇到這支SQL有問題.

Oracle EBS: 折讓的SO未拋至AR (Cust_trx_type_ID is required for Invoice Interface)

狀況:
1.折讓作業已作完, 資料未拋至AR
2.line的status為 Awaiting Invoice Interface - Incomplete Data
3.Progress Order可作的Activity是 Invoice Interface - Eligible
4.作Progress Order後出現訊息: Cust_trx_type_ID is required for Invoice Interface

原因: 在AR transaction type中的銷項設定未指定Credit Memo Type (此銷項設定對應至折讓所reference之SO/invoice)

解決方式: 指定Credit Memo Type

Ref: Progressing SO Line Displays "Cust_trx_type_id Is Required For Invoice Interface" Message (Doc ID 1367912.1)

Oracle EBS: ASCP Workbench中demand與supply的order type列表

針對MSC_DEMANDS - ORIGINATION_TYPE欄位:

SELECT meaning, lookup_code
  FROM mfg_lookups
 WHERE lookup_type = 'MSC_DEMAND_ORIGINATION'
 ORDER BY lookup_code;


針對MSC_SUPPLIES - ORDER_TYPE欄位:

SELECT meaning, lookup_code
  FROM mfg_lookups
 WHERE lookup_type = 'MRP_ORDER_TYPE'
 ORDER BY lookup_code;


Ref:
List Of Order Types For Demands And Supplies In ASCP Workbench (Doc ID 2246358.1)

書摘: 供應鏈, 不是有料就好

採購基本職責: 在公司利潤目標的前提下, 確保物料供給或服務可適時滿足公司的需求
1.公司的需求指的是企業產出所需要的物品或內部需求
2.物料或服務指的是"對的"物料或服務
3.適時滿足主要是關係到"進料的時間點與數量", 持續供貨、不讓產線斷料是採購與物管最重要的工作要點
4.與公司利潤相關的就是成本

採購的五大要素: 對的供應商、時間、價格、數量與品質(supplier、time、price、quantity、quality)

採購相關工作流程:
1.物料需求、物料需求規劃
2.採購訂單作業流程: 詢議價、下單
3.未結訂單處理流程
4.設計變更流程
5.物料異常處理流程
6.清倉與物料報廢流程: 報廢、清倉

交期管理基礎:
1.正向排程與逆向排程:
  正向排程(forward scheduling)為完成一成品的各段作業花費時間, 向未來推算最快完成的日期
  逆向排程(backward scheduling)則是在確定一個訂單或交貨的完成日後, 往回推算日期來計算每一個作業何時要開始
2.入用存: 當期庫存 = 前存 - 當期用量(需求量) + 當期入料數量
3.期望交期與交量: 催料時, 一定要表達清楚期望交期與交量, 而且是時間與數量要一起給, 並定義是ETA或ETD

催料追貨三要點:
1.方法: 精確提問(precision questioning)、5 whys、有系統地呈報主管、PDCA(Plan, Do, Check, Action)
2.材料熟悉度: 產業特性與動態, 各個供應商的產能與彈性, 材料製程, 前置時間的組成
3.勢: 掌握勢態追求的是營造一種局勢, 表達非追到物料不可的決心, 並讓供應商清楚知道這件事很重要, 同時運用有利害關係的各方幫助來快速解決缺料問題.

成本分類:
1.固定成本(Fixed Cost)
2.變動成本(Variable Cost)
3.半變動成本(Semi-Variable Cost)
4.直接成本(Direct Cost)
5.間接成本(Indirect Cost)

其他影響成本的因素:
1.產品製造流程與技術
2.良率(或拋料率)與學習曲線
3.貿易條件、運輸方式與交貨地點
4.付款天數(payment term)
5.採購模式: 包含保稅進口、一般貿易進口、國內採購、轉(深加工結轉)等模式
6.巿場與供應商策略

重要觀念與指標:
1.總成本
2.性價比
3.物料成本占平均售價比重

供應鏈(supply chain): 從原物料的獲取、加工製造, 直到完成成品送至終端消費者手上, 整個價值鏈中所包含的一連串相關的組織活動. 涉及原物料供應商、生產廠商、經銷商、零售商; 包含金流、物流(全球運籌)、資訊流, 以滿足終端客戶需求為目標.

生產型態:
1.接單後設計生產(engineering to order)
2.接單生產(build to order)
3.存貨生產型(build to stock, make to stock)
4.組合生產型(assembly to order)
5.連續生產型(continuous production)

長鞭效應(bullwhip effect): 終端消費者需求的小幅波動, 造成上游供應商需求大幅波動.

供應鏈整體概況:
1.需求供給無法適配的風險程度
2.缺料導致無法賣出成品所產生的機會損失

最常見的缺料原因:
1.需求上升導致前置時間不足
2.供應商交期延誤
3.品質問題或是產線過度耗損物料

需求管理議題:
1.需求預測的準確性
2.生產計劃的安排

提升供應鏈彈性的作法:
1.共用料
2.替代物料
3.採購合約
4.供應鏈上的庫存調節
5.縮短前置時間
6.策略性庫存
7.消除工廠的原料倉庫
8.供應倉儲(supply hub)
9.供應商管理庫存(vendor managed inventory, VMI)
10.資訊與通訊科技

物料清單風險分析: 藉由檢視產品的物料清單內容, 找出斷料風險高的物料, 進而規劃持續供給計劃, 以達到避免斷料的目的.

花費分析與採購策略: 利用歷史採購資料或一年的銷售預測來進行花費分析, 進而找出降低成本的機會, 甚至調整採購策略.

巿場敏感度: 基於巿場事件與數據, 將巿場敏感度具體化為有用與前瞻的規劃與行動; 同時, 可以參考總體經濟指標(PMI, 股價指數)來印證與檢討.

庫存管理:
1.源頭管理: 檢視採購單對公司庫存金額的影響
2.微觀管理: 每週、每天都要進料以備生產之需. 管理者必須仔細管理庫存
3.異常管控: 包含呆料與廢料的處理
4.訓練與學習

庫存管理的關鍵績效指標:
1.庫存周轉率(inventory turnover rate)
2.總金額(total amount)
3.供給水位衡量(pipeline excess)
4.供給天數

呆殘料定義:
1.呆料(surplus; slow moving inventory; excess parts): 尚在使用但多餘的物料與產品, 可能是需求下修、或是產品滯銷所造成
2.廢料或殘料(obsolete parts): 已喪失物料原有之功能特性、邊角料、餘料, 或在公司中不再具有使用價值的物料, 或因品質問題或是工程師換料導致此料不再使用

呆殘料的誕生:
1.殘料的產生: 供應商來料品質不良、產品設計不良或是設計工程師換料、製程中損壞零件或剩餘、物料使用保存期限過期.
2.呆料的產生: 需求數量急速下修、需求數量反覆變動、產品生命週期規劃不周全、輕率搶單、最小訂購量、採購備忘錄或採購合約、最後一次購買的備料、人為的執行錯誤或不到位

呆殘料處理原則:
1.活用呆殘料
2.魔鬼就在細節裡: 資料彙整與分析

獲得呆殘料更佳成果之作法:
1.根因與績效的連結
2.執行力與紀律
3.及早發現、及早治療
4.規劃、控制功能的績效提升
5.關鍵人物

逆向供應鏈: 由客戶手中獲得廢棄或已使用過的產品或資源, 而後重新處置或再利用的一系列活動.

企業提高作逆向供應鏈的原因:
1.環保法規
2.科技: 例如Apple的Liam機器人拆解手機

企業作逆向供應鏈的誘因:
1.獲得稀少、貴重或戰略性資源
2.成本降低
3.塑造供應鏈彈性
4.改善環境、永續發展, 提升品牌效益、塑造企業形象

企業建構正向與逆向供應鏈融合體系可採取的行動:
1.工業4.0的運用, 以及新技術導入製程
2.前期產品設計與產品生命週期的考量
3.建立回收基礎設施與消費者推廣點
4.外部成本的揭露
5.商業模式與流程的改善

供應鏈在本質上要解決的三個基本問題:
1.需求難預測, 供需不適配; 如何即時滿足公司所需要的物料或服務(供需適配)
2.在公司創造附加價值的過程中, 如何以最低總成本來達成公司目標(全球最佳化)
3.如何透過供應鏈配合商業模式(business model)來應對外在環境變化, 包含了提升競爭力、體現社會責任、創造價值

精確提問與回答之三原則:
1.傾聽
2.鳥瞰全局、狀況分析
3.問題分析與行動方案

工作上問題的類型:
1.必要性
2.本質性
3.假設前題
4.真實性
5.結果
6.原因
7.行動

Oracle ASCP: ASCP執行Planning Data Pull時error (Staging tables' data is not collected)

Error message:

  Staging tables' data is not collected.  Please submit the request - Planning ODS LOAD.

原因: 可能先前的data collection失敗造成


解決方式: 執行[Planning Data Collection - Purge Staging Tables], 參數Validation設定為No.

Ref:
Error Data Collection "Staging tables' data is not collected" (Doc ID 1531482.1)

Oracle EBS: 輸入SO line耗時過久問題

狀況:
1.輸入銷退資料時, 一個line耗時近一分鐘, 嚴重時超過三分鐘
2.trace發現有段SQL執行20秒

解決方法: 更改profile設定:
  QP: Debug = Request Viewer Off
  OM: Debug Level = 0

備註: 原先[OM: Debug Level]是設定為5.


Ref:
Pricing Sql Statement Running Long (Doc ID 950810.1)

Oracle EBS: PO approval API

     SELECT  i_po_header_id
           || '-' || TO_CHAR(PO_WF_ITEMKEY_S.NEXTVAL)
      --INTO V_ITEM_KEY
      FROM DUAL;

 

     mo_global.init('PO');
     mo_global.set_policy_context('S', V_ORG_ID);
 
 
      PO_REQAPPROVAL_INIT1.START_WF_PROCESS(ItemType               => V_ITEM_TYPE, --'POAPPRV',
                                            ItemKey                => V_ITEM_KEY,
                                            WorkflowProcess        => 'POAPPRV_TOP',
                                            ActionOriginatedFrom   => 'PO_FORM',
                                            DocumentID             => I_HEADER_ID,
                                            DocumentNumber         => V_SEGMENT1, -- Purchase Order Number
                                            PreparerID             => V_PREPARER_ID, -- Buyer/Preparer_id
                                            DocumentTypeCode       => V_DOCUMENT_TYPE_CODE,
                                            DocumentSubtype        => V_DOCUMENT_SUBTYPE,
                                            SubmitterAction        => 'APPROVE',
                                            forwardToID            => NULL,
                                            forwardFromID          => NULL,
                                            DefaultApprovalPathID  => NULL,
                                            Note                   => NULL,
                                            PrintFlag              => 'N',
                                            FaxFlag                => 'N',
                                            FaxNumber              => NULL,
                                            EmailFlag              => 'N',
                                            EmailAddress           => NULL,
                                            CreateSourcingRule     => 'N',
                                            ReleaseGenMethod       => 'N',
                                            UpdateSourcingRule     => 'N',
                                            MassUpdateReleases     => 'N',
                                            RetroactivePriceChange => 'N',
                                            OrgAssignChange        => 'N',
                                            CommunicatePriceChange => 'N',
                                            p_Background_Flag      => 'N', --N:標準API會COMMIT
                                            p_Initiator            => NULL,
                                            p_xml_flag             => NULL) --,
                                            --FpdsngFlag             => 'N',   --12.0.6無此參數
                                            --p_source_type_code     => NULL); --12.0.6無此參數


備註: 執行API時不可開著PO, 否則雖然狀態變為IN PROCESS, 但workflow會有exception.

Ref:
Oracle ERP R12. - Approval PO By API
http://doggww.blogspot.com/2012/12/oracle-erp-r12-approval-po-by-api.html


依官方說法, 不提供此API:
Is There An API To Submit Incomplete PO's, Releases And Requisitions For Approval? (Doc ID 1326541.1)