Aloz 的 Oracle ERP 天地

Oracle OM 模組有一個功能, 是精華也是特色, 就是 OM 的 Defaulting Rule, 它可以讓 Superuser 設定每個層級所需要的資料, 個別來自於哪一個地方, 好比說 Payment Term, 它可以設定在很多地方, Customer Level / Site Level / Price List 等等, 這時就看公司的需要而自行定義.

大部份的 Defaulting Rule 都是 Seeded (System) 所設定, 也就是系統"不太想"讓你修改, 真的要改的話, 那就是拿出一千零一招 :
1. 先將 DEFCONDN_RULE.SYSTEM_FLAG 改成 N, 然後存檔
2. 修改 Defaulting Sourcing Rule
3. 記得要跑 Tools > Generate Defaulting Handler Package
4. 關掉畫面之後重新查詢, 系統會把 SYSTEM_FLAG 改回 Y

---

當我開始學習 OM 模組時, 顧問就告訴我 : "Defaulting Rule 只會在 Create 時產生作用", 如果這樣想, 那你就把 Oracle 想簡單了

事實證明, 再 Update 時, Defaulting Rule 也是會生效的, 拿最簡單的例子來說 : Ordered Date.

這個欄位應該是記錄 Sales Order Header 的建立日期或是拿來當做手動維護的接單日期, 理論上應該是只能在 Create 時被輸入或塞值, 但是如果 User 在 Book Order 之後去修改任一欄位, Ordered Date 就會被修改為 SYSDATE, 這就是因為 Defaulting Rule 在作用.

Oracle 也不認為這是 BUG, 因為每一間公司都會有它的定義, 所以 Oracle 只提供修改的方式 : 改 OE_DEPENDENCIES 或 OE_DEPENDENCIES_EXTN

OE_DEPENDENCIES 應該是用來定義欄位之間的主從關係, 當主欄位有任何變動時, 設定的從屬欄位就會依 Defaulting Rule 的設定去重抓資料, 修改這個 Package 比較有破壞力, 所以我覺得還是不要隨便修改比較好, 還是修改 OE_DEPENDENCIES_EXTN 就好. OE_DEPENDENCIES_EXTN 是可以把 OE_DEPENDENCIES 設定的主從關係, 做生失效的動作, 如果修改之後有任何問題,把程式碼刪除或失效就可以, 也可以比較可以判斷出做了哪些修改.

一樣拿 Ordered Date 來說, 因為在 OE_DEPENDENCIES 有定義與 Transaction Phase 的關係, 所以當 Transaction Phase 有變動, Ordered Date 都會去重抓 SYSDATE, 那我們可以在 OE_DEPENDENCIES_EXTN 的 IF P_ENTITY_CODE = OE_GLOBALS.G_ENTITY_HEADER THEN 下新增 :

X_EXTN_DEP_TBL ( L_INDEX ).SOURCE_ATTRIBUTE := OE_HEADER_UTIL.G_SHIP_TO_ORG;
X_EXTN_DEP_TBL ( L_INDEX ).DEPENDENT_ATTRIBUTE := OE_HEADER_UTIL.G_INVOICE_TO_ORG;
X_EXTN_DEP_TBL ( L_INDEX ).ENABLED_FLAG := 'N';
L_INDEX := L_INDEX + 1;

紅字的部分可以參考 OE_DEPENDENCIES 的程式碼, 其餘的部份都不會有變動, L_INDEX 好像一定要加, 因為 Package 裡面的 Example 是這樣寫的.

每個欄位的主從關係也可以參考 OE_DEPENDENCIES 的程式碼.

這篇算是個警訊吧,

如果有在使用 Oracle BI Publisher 寫報表, 而且你的 Word 有更新到 2003 SP3, 那編輯出來的 RTF 檔會有不相容的情況發生, 會造成產出的 PDF 檔沒有表頭表尾,  Metalink 目前沒有看到相關文章, 可能是因為 Word 2003 SP3 剛出沒有很久, 要嘛就等 Patch, 要嘛就先灌回 SP2, 請小心

我們家的 User 很喜歡系統發 Mail 通知他們一些事情, 可能這樣會讓他們覺得系統很聰明吧 , 所以, 這段時間 Alert 就寫了一堆 XD

一樣, 也是寫一些簡單的心得 :

- Alert 只能發出純文字的內容, 不能夾檔, 也不能用 HTML 去寫, 所以 Alert 不能跟 Notifications 一樣漂亮

- Alert 的觸發可以分成 Schedule 與 Event, Schedule 就是自己訂時間, 系統就依照 SQL 把串出來的資料寄出. Event 就是利用 DB Trigger 的方式觸發, 不過預設的 DB Trigger 是針對整個 Table, 如果需要針對特定欄位做觸發, 就需要自己手動去 Trigger 加條件. Alert 產生的 DB Trigger 有 Naming Rule, 所以很好分 : ALR_<TABLE_NAME>_<字尾>, 字尾就看你是 After Insert = IAR, After Update = UAR 來決定

- Event 的 Alert SQL 都必須要加上 XXX.ROWID = :ROWID, 這樣才能夠正確判斷出是哪一筆資料觸發了 Event

- 如果要針對同一個 Table 發出兩封不同的 Alert, 好像是因為 Trigger 無法區分, 會造成兩封會有衝突 (有一封會一直有 Error), 在沒找到解法前, 我的做法是 :
    A. 對個別的情況先寫各別的 DB Trigger, 把相關資料寫到 Temp Table
    B. Alert 的 Event 再針對 Temp Table 做監看即可

- 發出的信也可以分成兩種 : Detail 與 Summary, Detail 就是 SQL 串出幾筆, Mail 就寄出幾筆, Summary 就是可以有表頭表身, 那表身像表格, 標題是可以重複的. 我個人比較喜歡把 Event 的 Alert 發成 Detail, 而 Schedule 的 Alert 發成 Summary

- Summary 的表身資料, 每一行的最前面都必須要空兩格, 我也不知道為什麼, 只知道不空的話前兩個字會被截斷

- 每一封 Alert 都要設定 Actions (Mail內容), Action Sets, Alert Details, Alert Details 是比較容易被忘記的, 因為裡面的 Installations 沒有指定 APPS 的 OU 的話, 是不會正常動作的

- 如果內容有純數字資料, 建議去 Alert Details 裡定義最長長度, 這樣格式比較好抓不會亂跑

噗，我已經管到 INV 模組了，哈

在做 Pick Confirm 的畫面：Transact Move Order 發現兩個問題

1. Move Order 無法正確的 Closed
    在資料面系統已經完成所有的 Transaction，但是 Move Order 還是掛在 Move Order LOV 裡面，是不影響整體動作，但是還是怪怪的。幸運的是，在 Metalink 找到相關的修正：
    Subject : Move Order Outstanding Reservation for Cancelled or Closed Order Lines
    Doc ID : Note:396254.1
   
    A. CORRECT DATA
    To implement the solution, please execute the following steps:

    1. Ensure that you have taken a backup of your system before applying the recommended solution.

    2. Run scripts that remove the reservations and move orders in a TEST environment first.
    The script names are i2471362.sql and INVCLRMO.sql. See the following notes for details:
    Note 199887.1 For the Reservation Cleanup - i2471362.sql
    Note 169677.1 For the Move Order Cleanup - INVCLRMO.sql

    3. If you are satisfied with the results, issue a commit.

    4. Confirm that the data is corrected when viewed in the Oracle Applications.

    5. Migrate the solution as appropriate to other environments.

    B. AVOID ISSUE
    1. Download and review the readme and pre-requisites for Patch 5037043.

    2. Ensure that you have taken a backup of your system before applying
    the recommended patch.

    3. Apply the patch in a test environment.

    4. Confirm the following file versions:
    INVVTROB.pls 115.128.115100.19
    MOTransaction.java 115.13.115100.2

    You can use the commands like the following:
    grep '$Header' $INV_TOP/patch/115/sql/INVVTROB.pls
    strings -a $JAVA_TOP/oracle/apps/inv/transaction/server/MOTransaction.class |grep '$Header'

    5. Retest the issue.

    6. Migrate the solution as appropriate to other environments.

2. 不能 Transact Multiple Line
    正常的情形下，按下 Transact Button，應該可以把這整張的 Move Order 的 Line 全都 Transact 掉，不過，那是正常的情況 

        To implement the solution, please execute the following steps:

    1. Download and review the readme and pre-requisites for <Patch>.5633132

    2. Ensure that you have taken a backup of your system before applying
    the recommended patch.

    3. Apply the patch in a test environment.

    4. Confirm the following file versions:
    forms/US/INVTOTRX.fmb 115.256.115100.36
    You can use the commands like the following:
    strings -a $XX_TOP/INVTOTRX.fmb |grep '$Header'

    5. Retest the issue.

    6. Migrate the solution as appropriate to other environments.

原本以為這會是偶發的狀況，沒想到上線之後幾乎是每天都有 User 碰到這樣的問題

目前確定以下狀況在輸入中文時會造成整個 Oracle ERP 當機 (應該是 Java 當掉)：
1. 使用新注音的使用者，要做選字動作時，要先把字 "選" 起來再按 ↓，不然會當機
2. 使用舊注音或舊倉頡，如果注音符號或倉頡字碼在輸入時超過該欄最大字數，也會當機
    (這個好解一點，因為大部份會打很多中文字的欄位大多是備註欄，把該欄位拉長一點就可以)

---

謝謝 CK 提供的資訊, 我已順利的跟 Oracle Support 要到修改方式, 測試過也已經 OK, 再次感謝

ACTION PLAN
============
1. Edit the appsweb_<SID>_<machine>.cfg as follows:
* Backup the file pointed to by $FORMS60_WEB_CONFIG_FILE
* Edit this file
* Locate the line: networkRetries=0
* After networkRetries=0, add the following line:
inlineIME=false

2. Edit the appsbase.htm as follows:
* Backup the $OA_HTML/US/appsbase.htm file
* Edit $OA_HTML/US/appsbase.htm
* Locate the section labled "IE Section"
* At around line 430, add the parameter inlineIME as follows:
(Aloz: 此動作需重開 Apache )
...
// Separate the less-than character from PARAM to prevent Appletviewer
// from seeing these as param tags outside of an applet tag.
IEhtml += '<' + 'PARAM name=type value="' + xpluginmimetype + ' ">';
IEhtml += '<' + 'PARAM name=codebase value="' + xcodebase + '">';
IEhtml += '<' + 'PARAM name=code value="' + xcode + '">';
IEhtml += '<' + 'PARAM name=inlineIME value="' + false + '">';

正式上線還真夠忙的，每天光修問題看設定就花掉一整天的時間 Orz

上線之後遇到比較大的問題是 Oracle 的 Credit Check Rule，不過網路上對這方面的討論好像不多(還是我找不到 @@")，簡單的寫點心得

---

Credit Check 要正常運作有三個地方要同時設定，缺一不可：
1. Customer / Address Profile
2. Order Transaction Type
3. Payment Term

其中，Transaction Type 的設定要配合 Main Page 的 Credit Check 設定 Check Rule，而且只能設定在 Order Type 上，不能設在 Line Type。

---

Credit Check Rule 設定：
1. Credit Check Level / Credit Hold Level
    這個很明白，不過如果 Check Level 要 by Line，Exposure 的 "Use Pre-Calculated Exposure" 會被強制打勾，那在被打勾的情況之下，"Initialize Credit Summaries" 就要安排定期執行，Customer 的 Credit Limit 才會被 Refresh
2. Override Manual Release / Days to Honor Manual Release
    簡單的說，就是該訂單如果被 Release Hold，幾天之內不會再被套用該 Check Rule
3. Exposure
    這個頁面就是選擇 Credit 要計算到的數值，一般比較常用的就是：
    A. Include Open Receivable Balance (Open AR)
    B. Include Uninvoice Orders (Open SO)
    C. Include Orders Currently On Hold
    D. Maximum Days Past Due
    不過，Oracle 也大多數的系統一樣，不會計算在 AR Interface 的資料，但是如果 AR 的 Autoinvoice 有常常執行的話，這個問題就不算大

---

雖然 Oracle 只能針對 Order Type 去設定要不要做 Credit Check，但是一個 Order Type 可以有很多 Line Type，對我們公司來說，有些 Line Type 是不需要 Check Credit 的，可是 Oracle 又不能針對 Line Type 去設定是否檢查，所以我利用 OM 模組特有的 Defaulting Rule + Payment Term (No Credit Check) 去達成；不過這樣的設定當然還是有風險，因為 Defaulting Rule 只是幫 User 把預設值帶出來，如果 User 還是有權力把預設值改掉，那效果就不見了。

連上了三天的 Oracle Discoverer On-Site Training，收穫還不錯多，老師講的也很仔細，讓我發現很多 Discoverer 的優點與限制

不過有一些東西是很關鍵的，先列出來做個整理：

1. It Is Not Possible To Grant Discoverer Privileges To 'PUBLIC' User In An Applications Mode EUL
    Metalink Doc ID : 468007.1 
    Discoverer 在針對 Privileges 時，有一個  User : "PUBLIC"，是可以針對全部的 User 統一做設定修改，不過，只限於 DB User，如果想要套用在 Application EUL User 的話，是不  Work 的，所以，要一個一個 User 個別調整 

2. How To Revoke Privileges For Multiple Discoverer Apps Users
    Metalink Doc ID : 420357.1
    因為上面的 Doc 寫的很清楚，但我們 User 又很多的話，要怎麼修改它的 Privileges，Oracle 提供了 Command 的方式，下指令總比一個一個改快 XD

3. Complex Folders
    目前我在設計 Folder 時，習慣都使用 Custom Folder，也就是自己把 SQL Statment 寫好再整個丟上去，雖然很快很直接，但是就不夠模組化，Discoverer 可以利用 Complex Folder，先把每個 Table / View 設成 DB Folder / Custom Folder，再用 Complex Folder 串接，如此一來，如果一個部份的 Folder 有新增欄位或變更，只要修改一次，有套用到的 Folder 都會同步更新，在之後 Discoverer 數量越來越多的情況之下，維護效率會高很多。不過，現在的 Folders 都要重新調過就是了 Orz

4. Privileges
    這是跟前兩點有關；在 Discoverer Administrator 中，雖然可以使用 Responibilites 去給予，但是並沒有作用，還是要用 User 去設定，但是使用第二點的 Command 卻可以，所以這個可能是 Client 軟體的問題。

AR 模組雖然不是我負責的，但是跟 OM 模組息息相關，多少還是要了解一下囉。

當訂單模組做完出貨動作 ( Ship Confirm ) 之後，系統會把資料拋轉到 AR 模組的 Interface，再由 AR User 執行 Autoinvoice 把資料真正轉入 AR 模組。AR 的 Transaction 會有兩個重要的日期：AR Transaction Date 與 GL Date。在做 Autoinvoice 時，系統會幫 User 先決定一個 Default Value，如果 User 一時不察，轉入的日期就可能不是他真正期望的。舉例來說：

目前 Interface 有以下資料

Delivery Number	Actual Shipping Date
1000	2008-01-07
1001	2008-01-05
1002	2008-01-02
1003	2008-01-10

此時執行 Autoinvoice，這四筆的 AR Transaction Date 都會等同於各自的 Actual Shipping Date，但是 GL Date 就不一定了，如果是將這四筆包在同一次的 Autoinvoice 轉入 AR，那系統會自動將這四筆的 GL Date 帶入 "2008-01-02"，原因是，這一包裡面最早的日期就是 "2008-01-02"。

這個情況詳細發生的原因還不是很確定，也有可能是因為資料在 Interface 時，User 沒有維護 GL Date 有關，要等 Interface 有資料之後才能測試。

---

https://metalink.oracle.com/metalink/plsql/f?p=130:14:6901207646735683383::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,220251.1,1,1,1,helvetica#q17
https://metalink.oracle.com/metalink/plsql/f?p=130:14:6901207646735683383::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,29288.1,1,1,1,helvetica

Q: How does the GL date get derived?

A:
For invoices without Rules:

AutoInvoice first uses the GL date in the interface table (RA_INTERFACE_LINES_ALL), if one exists.

If one does not exist then it is derived as follows:

If the Derive Date box is checked for your batch source (Menu: Setup>Transactions>Sources, query your batch source, alternate region Accounting), AutoInvoice first uses the ship date in the interface table. If the ship date does not exist, AutoInvoice uses the sales order date. If the sales order date does not exist, AutoInvoice uses the date entered in the Submit Request window when AutoInvoice was run.

If the Derive Date box is not checked for your batch source, AutoInvoice uses the date entered in the Submit Request window when AutoInvoice was run.

For Invoices with Rules:

AutoInvoice first uses the GL date in the interface table (RA_INTERFACE_LINES_ALL), if one exists.

If the Invoicing Rule is 'Bill In Advance', AutoInvoice uses the Rule Start Date for the GL date.

If the Invoicing Rule is 'Bill in Arrears' and the invoice line has an accounting rule of type 'Accounting, Fixed Duration' and a period of 'Specific Date', AutoInvoice computes an end date using the earliest accounting rule date.

For all other Accounting rules, AutoInvoice computes an ending date for each invoice line, and then takes the earliest date of these lines and uses it as the GL date of the invoice.

If your invoice does not use a fixed rule accounting duration and the rule start date is not provided in the interface table, GL date is derived as follows:

If the Derive Date box is checked in batch source options, AutoInvoice first uses the ship date. If the ship date does not exist, AutoInvoice uses the sales order date. If the sales order date does not exist, AutoInvoice uses the date entered in the Submit Request window.

If the Derive Date box is not checked, AutoInvoice uses the date entered in the Submit Request window.

---

這個問題在目前有新的發現，GL Date 的抓取規則有點問題，如果 User Run Autoinvoice 時，是整包 ( 多筆 ) 去跑的話，那全部 AR 的 GL Date 都會變成第一筆 AR 的 GL Date，問了很多有 Oracle AR 經驗的人，也去 Metalink、Oracle 論壇 等等找過，也都沒人問過類似的問題，原因可能 Autoinvoice 不會這樣去 Run，看來是需要 Log TAR 了

	Doc ID:	Note:433359.1	Type:	REFERENCE
	Last Revision Date:	13-SEP-2007	Status:	PUBLISHED

In this Document
  Purpose
  Scope
  Tracking Workflow Notification Event Messages
     Track Outbound Notification Event Message
     Track Inbound Notification Event Message 

---

Applies to:

Oracle Workflow Cartridge - Version: 11.5.2 to 12.1
Information in this document applies to any platform.

Purpose

The purpose is to provided a summarised steps on how to:

1) Track an Outbound Workflow Notification Event Message whenever such an event is raised but the end user does not receive the email

2) Track an Inbound Worklfow Notification Event Message whenever a notification is responded to and the transaction does not seem to progress further.

Scope

Applications DBAs

Support Analysts

Tracking Workflow Notification Event Messages

Track Outbound Notification Event Message

1. oracle.apps.wf.notification.send event is raised when a notification is sent.
   The event is raised with Notification ID as the event key.

2. The e-mail notification is sent only if all of following are true.

    i) Notification status is OPEN or CANCELED 

   ii) Notification mail_status is MAIL or INVALID

        SELECT status, mail_status
        FROM wf_notifications
        WHERE notification_id = '&nid';

   iii) Recipient Role has a valid e-mail address and notification preference is in the format MAIL% 

        SELECT email_address, 
        nvl(WF_PREF.get_pref(name, 'MAILTYPE'),notification_preference)
        FROM wf_roles
       WHERE name = upper('&recipient_role');

   iv) Workflow Deferred Agent Listener is running

   v) Workflow Notification Mailer is running

3. The message makes two stops before it is sent as e-mail. 

 Raised --> WF_DEFERRED Queue --> Processed by Deferred Agent Listener --> WF_NOTIFICATION_OUT Queue --> Processed by Notification Mailer and sent as e-mail

4. If an error occurs during dispatch of oracle.apps.wf.notification.send, the message is enqueued to WF_ERROR queue. The Error Agent Listener dispatches the ERROR subscription for oracle.apps.wf.notification.send that executes WF_XML.Error_Rule. 

5. Run $FND_TOP/sql/wfmlrdbg.sql for a notification id and check the status of the message in WF_DEFERRED and WF_NOTIFICATION_OUT queue.

    PROCESSED in WF_DEFERRED - The message is enqueued to WF_NOTIFICATION_OUT

    PROCESSED in WF_NOTIFICATION_OUT - The message is sent as e-mail

    READY in WF_DEFERRED - Check if Deferred Agent Listener is running

    READY in WF_NOTIFICATION_OUT - Check if Notification Mailer is running

6. Analysing outbound XML message for a notification id. The wfmlrdbg.sql output provides the XML message generated by WF_XML.Generate at the time the script is run. If the original XML message used by the mailer is required to be analyzed following SQL may be used.

    SELECT tab.user_data.text_lob text_lob
    FROM applsys.aq$wf_notification_out tab
    WHERE dbms_lob.instr(tab.user_data.text_lob,'&1') > 0
    /

7. Try rebuilding the WF_NOTIFICATION_OUT queue if necessary

The wfntfqup.sql script rebuilds the WF_NOTIFICATION_OUT queue by dropping and recreating
that queue, removing pending notification messages from the WF_DEFERRED queue, and
repopulating the WF_NOTIFICATION_OUT queue from the Oracle Workflow Notification System
tables.

Wfntfqup.sql Version >=115.9

If you have implemented Oracle Alert and the WF_NOTIFICATION_OUT queue contains any pending
alert e-mail messages, those messages must be processed before the queue can be rebuilt. The
wfntfqup.sql script checks the queue for any alert e-mail messages and, if it finds any, the
script returns an error message that specifies how many alert e-mail messages are pending
and indicates that these messages must be processed before the script can run.

Wfntfqup.sql Version <= 115.8

If you have implemented Oracle Alert and the WF_NOTIFICATION_OUT queue contains any pending
alert e-mail messages, those messages must be processed before the queue can be rebuilt. The
wfntfqup.sql script checks the queue for any alert e-mail messages and, if it finds any,
exits without performing any changes.

Stop Notification Mailer, rebuild Mailer Queue using $FND_TOP/patch/115/sql/wfntfqup.sql.

Track Inbound Notification Event Message 

1. Workflow Notification Mailer's inbound thread reads the response e-mail from IMAP inbox. It then parses the content and identifies the notification id using NID string in the response e-mail and it identifies the response it expects. Using this information it parses the e-mail and finds out the response value. Using this information it builds a XML message under event name oracle.apps.wf.notification.receive event and enqueues to WF_NOTIFICATION_IN.

2. Workflow Inbound Notifications Agent Listener listens to WF_NOTIFICATION_IN agent.

3. The inbound agent listener dispatches event oracle.apps.wf.notification.receive that executes WF_XML.RECEIVE rule function. This rule function parses the response XML and applies the response value to the corresponding notification. It then calls WF_NOTIFICATION.Respond that completes the Notification Activity and the complete flow following the Notification Activity till a blocking activity is encountered.

4. The message makes one stop before making it to the Notification Activity.

Inbox -> WF_NOTIFICATION_IN Queue --> Processed by Inbound Agent Listener --> Workflow Engine

5. Run $FND_TOP/sql/wfmlrdbg.sql for notification id and check the status of the message in WF_NOTIFICATION_IN queue.

6. wfmlrdbg.sql output also provides the Inbound XML message in the later 11i.ATG_PF.H RUP releases. If the XML message is not available following SQL may be used.

    SELECT tab.user_data.text_lob text_lob
    FROM applsys.aq$wf_notification_in tab
    WHERE dbms_lob.instr(tab.user_data.text_lob,'&1') > 0;
   
7. If there is an error during response event processing the message is enqueued to WF_ERROR queue. The Error Agent Listener dispatches the ERROR subscription for oracle.apps.wf.notification.receive event that executes WF_RULE.Error_Rule.

8. If there is an exception thrown from WF_NOTIFICATION APIs when the response is applied, the Inbound Agent Listener sets the mail_status of the notification to INVALID and raises event oracle.apps.wf.notification.send that results in the INVALID response e-mail sent to the respoder.

這篇是直接引述 Metalink 上，有關如果改變 Sales Order Header Close 週期的文章，參考參考

---

Applies to:

Oracle Order Management - Version: 11.5.9
Information in this document applies to any platform.

Goal

"Checked for relevance on 27-Oct-2007"

How to change the Workflow so that the Order Header Closes as soon as all the lines are Closed ?

Solution

There is a standard WorkFlow Wait process defined just before the Close Header WF process, that waits for the end of the month in which the Sales order was created, before closing the Sales Order. This is to ensure that there is enough time to add new items to a Sales Order before it is closed, in case the customer wants to call back and add aditional items to the same Sales Order.

It is possible to open the OEOH workflow by connecting to the database using the WF Builder and then change this setting.

Open the Process "Close - Order" and then Right Click on the WAIT-1 that is just before the "CLOSE_WAIT_FOR_L" In the Properties, Choose Node Attributes Tab and place cursor on the "Day of the month" and remove the Value that is currently set as "Last".

Instead, set this Node Attribute same as the other Wait further down in this flow.
Change the setting as Wait Mode as Releative Time and then set the Relative Time as 1.

With this setting, as soon as all the Lines are closed, the Header will become eligible to be closed.

This will affect only new orders that uses this newly modified Flow. For the existing orders, one needs to wait till the end of the month - the month in which the Sales Order was created. Pls note that this happens only for the month the Sales order is created. For eg. if 9 of the 10 lines in a Sales Order created in July was closed and the 10th line is closed on Augst 1st, the Sales Order will Close on August 1st itself and will NOT wait till the end of August. FYI.

If there is a TEST instance where there are sample Orders, one can open the Work Flow in the Sysadmin User and System Administrator Responsibility and try and do a Skip on this Wait, so that this progresses further. If that is successful and satisfactory, one can do that in PROD too. Pls note that Support and DEV generally recommends not doing Expedite -> Skip or Expedite -> Retry unless has been consulted.