Aloz 的 Oracle ERP 天地

今天使用 IE 開輸出格式為 XML 的報表, 可能是因為裡面有中文, 造成看不到 Output, 經過同事的指點, 將 FND: NATIVE CLIENT ENCODING 這個 Profile 修改為 UTF8 即可

註 : 看起來只是 View Output 問題, 其實資料面是正常的

上週發生了一個新的 Import Error : "Ship To is required on a booked order", 一直看 Ship To 相關欄位都看不出所以然, 後來才發現是別的欄位造成的

昨天將 Firefox 升級為 3.6, 結果發現 Oracle EBS 開不起來了 @@"

結論就是, Firefox 3.6 只支援 JRE............

http://blogs.oracle.com/stevenChan/2010/01/firefox_36_ebs.html

公司最近將 JInitiator 改為 JRE, 在測試時發現, 如果使用 Google Chrome 瀏覽器時, 在看 Output 為 XML 格式的報表時, 會無法正確顯示, 查詢之後發現目前 DEV 版本已經可以正確顯示, 但公開版本仍有問題, 不過安裝擴充功能就可以了

XML Tree https://chrome.google.com/extensions/detail/gbammbheopgpmaagmckhpjbfgdfkpadb

在之前的某篇文章有提到, Credit Check 中有一個功能 : Override Manual Release, 一直到昨天才發現我對這個功能的意義是錯的

FND_PROFILE.VALUE 是很常用的 Function, 整理起來以後就不需要翻書了

(資料來源 : User Guide)

去年因為 Alert 的問題, 上 Google 找到了 昭佑.天翔 的 Blog, 這位高手有客製了一個名為 "Graphic Alert", 當下真是驚為天人, 在天翔好心的指點之下, 我知道 UTL_SMTP 的存在

最近因為有些 Alert 因為資料量太大的問題 (超過 Alert 限制的 64K) (註一), 造成 Alert 無法正常寄送, 所以才認真的研究 UTL_SMTP 的實作. 剛好, 在 Oracle Metalink 上有一篇文章, 就是教我們怎麼使用 UTL_SMTP (Metalink DocID : 357385.1), 也附上完整範例檔, 基本上, 如果 DB Server 有開啟 SMTP 服務, 修正一下 Package 的設定, 應該就可以直接使用了. 不過, 可能會遇到的問題有 :

1. 中文字變亂碼
2. 內容太長, VARCHAR2 變數仍有長度問題
3. Attachment 的方式太過僵化

註一: Alert 64K 的限制在 Oracle Applications Technology 11i.ATG_PF.H.delta.7 (RUP 7) 將會更新, 不過, 上 RUP7 是一個不小的挑戰就是了

當在設定 Blanket Sales Agreement 的 Document Sequence 時候, 切記, Document Sequence Type 只能設定 Automatic, 不能夠設定 Gapless 或 Manual (Metalink Doc ID : 375086.1)

如果設定成 Gapless 或 Manual 時, 會跳出 "Invalid Document Sequence. (Document Sequence=Manual Numbering)" 的錯誤訊息, 就算去 Update Table, 將 Type 欄位改為 Automatic 也是無法正確取號

只能手動將設定刪除, 再重新設定

 SELECT A.ROWID, A.*
   FROM FND_DOCUMENT_SEQUENCES A
  WHERE 0 = 0
    AND NAME LIKE 'Quote%(2010%' -- 依所設定的名稱搜尋;

 SELECT A.ROWID, A.*
   FROM FND_DOC_SEQUENCE_ASSIGNMENTS A
  WHERE 0 = 0
    AND CATEGORY_CODE = '1002'
    AND TO_CHAR(START_DATE, 'YYYY') = '2010';

Delivery 已經做完 Ship Confirm 動作, 但是 Status 出現了 "In-transit", 好險看到這一篇文章,

本文引用自somebabyTina - {Issue}:D/N已做完Ship Confirm狀態沒Close為In-transit

除了緊急處理之外, 也另外用 Personalize 擋起來, 以後 User 就不會誤操作了

因為我們有做訂單外部簽核, 簽核完之後都是走標準的 Order Import, 所以常常會遇到很奇怪的問題......

目前最常遇到的情形是, "Blanket sales agreement is locked by another user", 這個其實是老問題, 當初很直覺的覺得, 就是使用者忘了把 BSA 畫面關掉所致, 但是在最近幾次與使用者確認過後才發現好像不是這樣, 上 Metalink 才發現這是一個"問題"

(PS. 新版的 Metalink 在 Search 方面好像有強化, 比舊版更精準地查到我的問題)

Metalink Doc ID : 727777.1

Applies to:
Oracle EDI Gateway - Version: 11.5.10 to 11.5.10.2
This problem can occur on any platform.

Symptoms
-- Problem Statement:
On 11.5.10 in Production:
When attempting to import order lines which referencing the same blanket agreement number,
the following error occurs:

ERROR
"Blanket sales agreement is locked by another user. Please try later. Blanket Number: XXXX"

-- Steps To Reproduce:
The issue can be reproduced at will with the following steps:
1. Interface EDI 850 (POI) Multiple Sales Orders (Headers / Lines / Pricing Attributes) all
referencing the same Blanket Agreement Number on the Header and Line.
2. The first order record will import successfully but subsequent order records will fail with
error message on step 1 above.

Cause
This issue is described in Bug 4673289
ORDER IMPORT - BLANKET SALES AGREEMENT LOCKED BY ANOTHER USER

At this time, we do not lock the record before calculating the cumulative,
we do it in the memory, causing the locking issue.
Because of this limitation we are suggesting as a workaround to group by Customer.
That way every BSA will tie up with only one customer.
In this case - can send sold_to_org_id as a parameter to Order Import.

Solution

-- To implement the solution, please execute the following steps:

1. Go into the responsibility: Order management responsibility

2. Run order import by passing parameter 'number of instances' as 1

3. Retest the issue.

4. Migrate the solution as appropriate to other environments.