用 Power Automate 自動處理電子郵件送達的訂購單・請款單 PDF ── 儲存・分類・通知・讀取的設計

「把訂單郵件附件裡的訂購單 PDF，每天早上保存到共用資料夾，再抄錄到 Excel 的收單台帳。」承辦人員每天花 30 分鐘手動做這件事──有這種情況的公司並不少見。實際上，在 Power Automate 的諮詢當中，「想把電子郵件送達的單據處理自動化」這類話題，也算是相當多的一類。

乍看是簡單的自動化，但實際動手做，卻是個充滿細節陷阱的領域。連簽名圖片都被保存下來，讓資料夾塞滿垃圾檔案；不該處理的郵件也讓流程跑動，造成誤存；只有附件較大的郵件不知為何沒被處理。這篇文章會依序整理從接收觸發程序到保存、分類、通知的基本流程、實務上容易踩到的陷阱、要不要進一步做到 AI Builder 讀取（抄錄自動化）的判斷，以及電子郵件附件這種接收方式本身的極限。

1. 先講結論

• Office 365 Outlook 連接器的「收到新郵件時 (V3)」觸發程序，備有資料夾、寄件者、主旨篩選、「僅限含附件的郵件」等篩選條件。條件應盡量放在觸發程序端指定，而不是放在後段的條件分支動作。¹²
• 接收窗口不要用承辦人員個人的收件匣，而是用共用信箱（例如 order@自家網域）。有專用觸發程序「共用信箱收到新郵件時 (V2)」，只要連線帳戶擁有該共用信箱的存取權限即可使用。³
• 只用「有附件」這個判斷條件的話，簽名或標誌等內嵌圖片也會被當成附件撿起來。以附件中繼資料裡的 Is Inline 屬性搭配副檔名來篩選，是基本的對策。⁴
• 保存位置建議設為 SharePoint 文件庫，用「建立檔案」動作寫入，再用 Teams 或電子郵件通知保存完成，這種架構比較容易處理。⁵
• 若要進一步做到讀取（抄錄自動化），會用到 AI Builder 的文件處理，但另外需要用量計費的點數（容量），而且擷取結果必須設計成需要人工確認。授權體系自 2025 年起正在變化，導入前需要確認最新資訊。⁶⁷
• 以有密碼的 ZIP (PPAP) 送達的附件，不該想著在流程裡解開，改變接收方式本身才是本質上的對策。

2. 整理對象業務 ── 「電子郵件附件送達的單據」能自動化到什麼程度

首先，先確認這篇文章鎖定的業務形態。

• 交易對象以電子郵件附件送來訂購單、請款單、送貨單等 PDF
• 承辦人員開啟後，保存到共用資料夾中固定的位置
• 把內容（交易對象名稱、金額、品項等）抄錄到 Excel 或業務系統
• 通知承辦人員或相關人員「訂單來了」

接收受發訂的方式，有 FAX、電子郵件附件、Web 表單、EDI 等不同階段。電子郵件附件比 FAX 更容易資料化，但比不上 EDI 或數位發票這類結構化的資料串接，處於中間的位置。這個整體樣貌，已在另一篇文章「什麼是 EDI？如何讓企業間的訂購作業更輕鬆 ── 從傳真、電子郵件、手動輸入邁向資料連動」中整理過。

在此基礎上，若把維持電子郵件附件運作模式、可以靠自動化爭取到的範圍區分開來，可以分成以下 3 個階段。

這篇文章的主戰場是 (1) 和 (2)。建議的做法是，先做 (1) 就已經有足夠的日常效果，(2) 則看投資報酬率再判斷是否要做。(3) 會在第 7 章談到。

3. 基本流程 ── 從接收觸發程序到保存、通知

基本形式是「接收觸發程序 → 篩選 → 逐一附件迴圈 → 保存到 SharePoint → 通知」。

flowchart TD
    Start([共用信箱收到新郵件時<br/>V2<br/>order@自家網域]) --> Filter[以觸發條件篩選<br/>寄件者、主旨篩選、僅限含附件的郵件]
    Filter --> Each[Apply to each<br/>逐一處理每個附件]
    Each --> Check{Is Inline = false<br/>且副檔名為 .pdf ?}
    Check -- 否 --> Skip[不處理<br/>排除簽名圖片等]
    Check -- 是 --> Save[SharePoint - 建立檔案<br/>存入交易對象/年月資料夾<br/>檔名含收件時間]
    Save --> Notify[張貼到 Teams 頻道 或 電子郵件通知<br/>記載保存位置連結、寄件者、主旨]
    Notify --> End([完成])
    Save -. 失敗時 .-> Err[錯誤通知<br/>通知管理員失敗]

主要動作與設計要點如下。

3.1 觸發程序中要填入的具體設定值

觸發程序的篩選條件，預設不會顯示。在觸發程序卡片中開啟「顯示進階選項 (Show advanced options)」後，下方的項目才會出現。這裡把實際要填入的值一併列出。¹²

「僅限含附件的郵件」和「包含附件」名稱相似，但角色不同，兩者都要開啟，基本流程才會動。只開前者，附件內容就取不到；只開後者，即使沒有附件的郵件也會啟動流程。

若像「交易對象/年月」這樣動態決定保存資料夾，也別忘了在流程端保證保存資料夾確實存在。來自新交易對象的第一封郵件、或每月第一封郵件時，保存資料夾往往還不存在。SharePoint 連接器有「建立新資料夾 (Create new folder)」動作，可以一次建立整個資料夾路徑⁵，只要在「建立檔案」之前先加入準備資料夾的步驟，就能避免在這裡卡住保存流程的事故。

之所以把保存位置設為 SharePoint、而不是傳統的檔案伺服器，是因為雲端流程可以直接寫入、能用連結通知、之後也容易與 AI Builder 或搜尋功能組合。若有只能放在地端檔案伺服器的情況，也可以透過地端資料閘道，但架構會變得比較沉重，若可行的話，建議連保存位置一起遷移到 SharePoint。

另外，關於整個流程的錯誤處理（失敗時的通知、確認執行紀錄）的思路，已在另一篇文章「用 Power Automate 自動化業務 ── 雲端流程與桌面流程的分工，以及錯誤處理設計」中詳細說明。

4. 陷阱與對策

第一版能動的流程，花半天就能做出來。問題在那之後：能不能撐得住實際運作，取決於有沒有把接下來這些陷阱都堵住。

4.1 簽名、標誌圖片被當成「附件」保存下來

這是最常見的諮詢。因為嵌入郵件內文中的簽名圖片、公司標誌，在資料上會被當成內嵌附件處理，若只用「有附件」這個條件來保存，就會把大量像 image001.png 這種檔案，跟本命的 PDF 一起保存下來。

在 Office 365 Outlook 連接器中，觸發程序或動作回傳的附件中繼資料，包含 Id、Name、Content Type、Size、Is Inline，這些不論「包含附件」的設定如何都一律可以取得。Is Inline 為 true 的就是內嵌附件。⁴

對策分兩層。

1. 在 Apply to each 中，用條件動作只放行 Is Inline 為 false 的項目
2. 再確認檔名末尾是否為 .pdf（除了交易對象在內文中以圖片貼出單據的情況外，這樣幾乎能確實篩出目標）

條件動作用「全部符合 (And)」設成兩行。

items('Apply_to_each') 是指向 Apply to each 目前項目的運算式。若改了迴圈的名稱，就要把該名稱中的空格換成底線。副檔名有時會以大寫送達，因此先套用 toLower 再判斷比較安全。

另外，若日常會收到大量或大容量附件，也可以把觸發程序的「包含附件」關閉，先用中繼資料篩選出目標，再用「取得附件 (V2)」動作，只個別取得需要的附件，這也是一種可選的架構。¹ 由於附件的中繼資料（Is Inline 或名稱）不論「包含附件」的設定為何都能取得，因此不管哪種架構，篩選邏輯都一樣。⁴ 這樣能讓觸發程序傳遞的資料量保持較小，當流程成長、附件處理變得沉重時，可以考慮切換成這種形式。

4.2 篩選目標郵件 ── 專用地址+共用信箱

個人的收件匣裡，也會收到大量非訂購單的郵件。不論用寄件者或主旨再怎麼努力篩選，只要交易對象改變寫郵件的方式，就會漏掉。根本的對策，是準備訂單受理專用的地址，請交易對象寄到那裡。

這時接收窗口要設為共用信箱，理由有兩個。

• 可以把接收入口從承辦人員個人的信箱切割開來。能防止因為承辦人員異動、離職，接收窗口整個消失，或後任看不到過去郵件的事故
• 共用信箱本身不需要個別授權，只要存取的使用者一方擁有授權即可⁹

觸發程序要用「共用信箱收到新郵件時 (V2)」。前提條件是，流程連線所用的帳戶必須擁有該共用信箱的存取權限。注意事項是，授予權限後，平台端可能需要約 2 小時才會生效，另外 Microsoft 365 群組的地址不能指定為共用信箱。³

不過要注意，改用共用信箱並不代表流程就此擺脫個人依賴。流程的連線（對 Outlook 的驗證）仍然綁定在建立連線的使用者帳戶上，共享出去的連線也只能在那個流程裡使用，其他擁有者無法變更別的擁有者所建連線的憑證。¹⁰ 也就是說，只要用於連線的帳戶因離職而失效，即使接收窗口是共用信箱，流程也會停止運作。連線應盡量用能與離職計畫切割開的運維帳戶建立，同時設定共同擁有者，打造「萬一發生狀況，其他擁有者能把連線換成自己的、維持流程運作」的體制。

4.3 同名檔案的覆蓋與重複

名為「訂購單.pdf」的附件，會從多個交易對象反覆送來。若直接用收到的名稱保存，必然會發生同名檔案衝突。保存時的檔名，要用收件郵件的資訊機械式組成，確保唯一。實務上，命名成「收件時間（到秒）+寄件者網域+原始檔名」這樣，幾乎能避開衝突，之後與郵件核對也比較輕鬆。

SharePoint「建立檔案」的檔名欄，填入下列運算式。

concat(
  convertFromUtc(triggerOutputs()?['body/receivedDateTime'], 'Tokyo Standard Time', 'yyyyMMdd-HHmmss'),
  '_',
  last(split(triggerOutputs()?['body/from'], '@')),
  '_',
  items('Apply_to_each')?['name']
)

這三個部件的意義如下。

• 收件時間：receivedDateTime 是以 UTC 回傳的，若只用 formatDateTime 整形，會跟日本時間差 9 小時，跨日的傍晚以後郵件會變成前一天的檔名。把 Windows 時區 ID Tokyo Standard Time 傳給 convertFromUtc 的第 2 個參數，並在第 3 個參數指定格式，才是穩妥的做法。收件時間本身也可以從動態內容中選取。
• 寄件者網域：用 split 以 @ 前後分開，再用 last 取後段（網域）。之所以用網域而非寄件者的顯示名稱，是因為顯示名稱可能含有空格或符號，不好處理。
• 原始檔名：是 Apply to each 目前的附件檔名。連副檔名都包含在內，所以不需要再另外加上 .pdf。

另外，SharePoint 的檔名不能使用 \ / : * ? " < > | 這些字元。若把主旨或寄件者的顯示名稱混入檔名，只要出現這些字元，保存就會立刻失敗。像上面那樣，只用格式機械式決定的值來組成，才是安全的做法。

另外，像修改流程後用測試手動重新執行等情況，也會發生把同一封郵件重複處理兩次的場面。以收件時間為基準命名的話，這時寫入的目標，只會是來自同一封郵件的同名檔案，不會牽連、覆蓋掉其他交易對象的檔案。不過對同名檔案的第二次寫入本身仍會衝突（不論結果是覆蓋還是失敗，內容都是相同的），若想偵測重複處理本身，可以把觸發程序輸出中包含的訊息 ID，放進保存清單的欄位或檔名中，就能機械式比對是否已經處理過。¹

4.4 偵測遺漏 ── 能不能發現「觸發程序沒有動作的郵件」

這一點常被忽略，但接收觸發程序並非萬能。文件中明確記載的限制，有以下幾種情況。

• 總大小超過 Exchange 管理員設定的上限，或 50 MB 兩者中較小的一方，觸發程序就會跳過該郵件。受保護的郵件（加密郵件），以及內文、附件不正常的郵件，也可能被跳過¹
• 同時有大量郵件送達時，由於系統端的限制，觸發程序偶爾會漏掉郵件¹¹

也就是說，可能發生的不是「流程出錯」，而是「根本沒有執行」的郵件。就算只監控錯誤通知，也發現不了這種遺漏。對策上，除了流程成功、失敗的通知之外，保留讓人定期確認收件匣的作業（用流程把已處理的郵件移動到資料夾，讓留在收件匣裡的郵件一看就知道是未處理）是比較現實的做法。

這個資料夾移動，要用 Office 365 Outlook 連接器的「移動郵件 (Move email (V2))」動作。¹² 放在通知動作之後，移動到共用信箱的「已處理」資料夾。用「將郵件標示為已讀或未讀 (Mark as read or unread (V3))」也能標示是否已處理，但已讀的郵件仍會留在收件匣裡。若要打造「留在收件匣裡＝未處理」這種一目了然的狀態，移動比較確實。移動目的地，請設為觸發程序所監控資料夾（通常是收件匣）以外的其他資料夾。若移動到監控對象的資料夾，移動本身就可能被視為新郵件，留下被重新執行的餘地。郵件本身的大小上限，由 Exchange Online 端的設定決定，預設接收上限為 36 MB，管理員可在 1～150 MB 的範圍內變更。有大容量附件往來的交易對象，可以考慮後述的檔案共享連結等其他交付方式。¹³

5. 要不要進一步做到讀取（抄錄自動化） ── AI Builder 的文件處理

保存和通知開始順利運作之後，接下來會想要的，就是「連讀取 PDF 內容、寫入台帳都自動化」。這時要用的，就是 AI Builder 的文件處理。

5.1 預先建置模型與自訂模型

AI Builder 為請款單準備了預先建置的請款單處理模型。請款單編號、請款日期、付款期限、交易對象名稱、合計金額、明細行等共通欄位，不需要訓練模型就能直接擷取，支援語言中也包含日文。輸入格式為 JPEG/PNG/PDF，檔案大小限制在 20 MB 以內。¹⁴

另一方面，像訂購單這種每家公司版面都不同的單據，或即使是請款單也想擷取標準欄位以外的項目（如自家的管理編號等）時，就要建立文件處理自訂模型。從「固定範本文件」「一般文件」「請款單（延伸自預先建置模型）」3 種類型中選擇，把相同版面的單據彙整成集合，每個集合至少上傳 5 份範例文件，標記想擷取的欄位或表格來進行訓練。¹⁵

兩者要組進流程都很簡單，請款單處理模型只要用「從請款單擷取資訊」動作，自訂模型則用「處理文件」動作，把保存在 SharePoint 的 PDF 檔案內容傳進去即可。¹⁶⁸

5.2 準確度與例外處理 ── 用信心分數轉交人工確認

讀取自動化中最重要的一點，是以「擷取有可能出錯」為前提來設計。AI Builder 的擷取結果，每個欄位都會附上 0～1 的信心分數。實務上，會用這個分數讓流程分支。¹⁶

• 分數高（例如 0.9 以上）→ 直接寫入台帳，通知標示為「已自動處理」
• 分數低 → 在台帳中以「待確認」寫入，並通知承辦人員「請確認這個項目」

上面的 0.9 只是舉例說明，並非適用於所有單據的數值。門檻值要用自家的單據來決定，用以下步驟推導出來。

1. 先不設門檻值跑一次。準備 20～50 份與正式運作相同交易對象、相同版面的單據，不加分支，讓所有單據都讀取一次。把擷取值與信心分數原封不動輸出到 SharePoint 清單或 Excel 中。
2. 與正確答案核對。逐份目視標記正確與否，查看每個欄位「擷取錯誤的分數最大值」。門檻值的下限，就設在這個值再高一點的地方。
3. 依欄位分別設定。像合計金額、請款單編號這種一旦出錯就會影響下游的項目，門檻值設高一點；像備註這種之後還能修正的項目，門檻值可以設低一點。若想用一個門檻值裁決所有欄位，一定會有地方變得不便。
4. 上線後定期檢討。記錄「轉交待確認的件數」與「實際需要修正的件數」，每季檢討一次。若幾乎都被轉去待確認，就增加訓練用範例；反之，若幾乎沒有待確認，卻有錯誤漏網，就調高門檻值。

Microsoft 的文件本身，就介紹了組合預先建置模型與自訂模型、信心分數過低時回退到另一個模型的架構範例。¹⁴ 若設計成「能全部自動讀取算是賺到，讀不到的部分才由人來看」，就不必追求 100% 的準確度，導入的門檻會大幅降低。

5.3 授權與點數 ── 這裡務必事先確認

AI Builder 的動作，每次執行都會使用一種消耗型容量。過去這種容量稱為 AI Builder 點數，除了 AI Builder 容量附加元件（每個附加元件每月 100 萬點數）之外，Power Automate Premium 等 Premium 授權，也會附帶少量點數（Power Automate Premium 為 5,000 點數）。點數以租用戶為單位統一管理，分配到環境中使用。環境若沒有容量，流程就會因 NoCapacity 之類的錯誤而停止。⁶

不過，這套體系在本文執筆時點（2026 年 7 月）正處於轉換期。2025 年 10 月已宣布 AI Builder 點數的階段性終止，Premium 授權附帶的起始點數將於 2026 年 11 月 1 日終止，新客戶已無法購買 AI Builder 容量附加元件，改為購買 Copilot 點數。AI Builder 的功能本身仍可透過 Copilot 點數繼續使用，但雲端流程的優先順序是先消耗 AI Builder 點數，用盡後才消耗 Copilot 點數。⁷¹⁷

簡而言之，就是「若要做到讀取，就會有額外成本。而這套體系在 2026 年 7 月這個時間點，正在變化之中」。若您在起始點數的終止日（2026 年 11 月 1 日）之後閱讀本文，前提很可能已經改變，請務必以第一手資訊確認目前的體系。以下把導入判斷的參考標準整理成表格。

6. 收到有密碼的 ZIP (PPAP) 時 ── 這不是該用流程解決的問題

「附件是用有密碼的 ZIP 送來的，能用流程解壓縮嗎？」這也是常見的提問。結論先講：請不要想著在流程中解開它。

有密碼的 ZIP 這種運用方式，是建立在「密碼會用另一封郵件送達，由人讀取後手動輸入來開啟」這個前提上的。密碼的通知時機和格式都由對方決定，並非為機器處理而設計的機制。若硬要把這裡自動化，就會背上解析密碼郵件、保管密碼這類原本不必做、卻很危險的機制。

PPAP 本來就是在用同一條路徑送出鑰匙和貨物的時間點，作為安全對策的意義就很薄弱，讓接收端的病毒檢查形同虛設的害處反而更大的運用方式。這個問題點與替代手段（如檔案共享連結）已在另一篇文章「為什麼郵件安全裡 PPAP 行不通？正確的做法是什麼？」中詳細說明。就自動化的脈絡而言，用 PPAP 送達的單據，是「該交涉改變接收方式的對象清單」中的第一名。對交易對象提出「基於自動處理的考量，希望改用明文 PDF 附件或檔案共享連結，而非有密碼的 ZIP」這樣的請求，隨著停用 PPAP 的風潮，也比過去更容易被接受。

7. 更進一步 ── 電子郵件附件運作方式的極限與分階段轉移

把保存、通知、讀取都整頓好之後，剩下的，是「本來就用電子郵件附件往來單據」這件事本身的極限。

• 單據的版面有多少交易對象就有多少種，讀取模型的維護，會隨著交易對象增加而愈來愈沉重
• 讀取準確度不會達到 100%，人工確認的工序會永遠留存
• 郵件有時會送不到（大小超過、被判定為垃圾郵件），遺漏監控也會持續存在

這些問題不論把 Power Automate 的設計磨得多精細，都不會消失。只要工序的起點在於「把非結構化資料（PDF）送給人」，讀取與確認就會作為必要成本一直留存。正因如此，中期而言，值得把一開始就用結構化資料接收的方向，也就是分階段轉移到 Web 接單表單、EDI，若是請款單則轉移到數位發票（Peppol / JP PINT），納入考量範圍。

轉移不必一次全部切換。從願意配合的交易對象開始，依序轉移到新的接收方式，剩下的則用電子郵件附件+自動處理來接收，這種雙軌運作才是現實的做法。這種分階段轉移的設計，已在「把 FAX 收單搬到網路上 ── 雙軌並行期的設計與分階段轉移實務」中整理過，數位發票的機制，則在「什麼是數位發票（Digital Invoice）？──與「把請款單 PDF 寄送 email」有何不同」中整理過。本文的流程，適合定位為支撐轉移期間內「持續以電子郵件附件接收的部分」的機制。

8. 總結

電子郵件送達的訂購單、請款單 PDF 處理，作為 Power Automate 的自動化主題，算是入門的一類，但要做到能撐得住實際運作，該掌握的重點是明確的。

首先，把接收窗口設為共用信箱的專用地址，篩選條件盡量放在觸發程序端。附件的篩選用 Is Inline 與副檔名兩層來排除簽名圖片。檔名以收件時間為基準確保唯一，並以觸發程序會跳過的情況（超過 50 MB、加密郵件、同時大量收件）為前提，保留能發現遺漏的運作方式。做到這裡是第一階段。

若要進一步做到讀取，就要把 AI Builder 的預先建置模型或自訂模型，搭配信心分數的分支一起使用，並事先確認消耗型點數的成本，以及轉換期間的授權體系。而有密碼的 ZIP，不要用流程解開，而是當成交涉改變接收方式的對象。若電子郵件附件這種形式本身的極限已經浮現，就考慮分階段轉移到 Web 表單、EDI、數位發票──按這個順序推進，就是一個能穩健成長、不會大幅返工的領域。

相關文章

• 用 Power Automate 自動化業務 ── 雲端流程與桌面流程的分工，以及錯誤處理設計
• 為什麼郵件安全裡 PPAP 行不通？正確的做法是什麼？
• 什麼是 EDI？如何讓企業間的訂購作業更輕鬆 ── 從傳真、電子郵件、手動輸入邁向資料連動
• 把 FAX 收單搬到網路上 ── 雙軌並行期的設計與分階段轉移實務
• 什麼是數位發票（Digital Invoice）？──與「把請款單 PDF 寄送 email」有何不同

相關諮詢領域

合同會社小村軟體處理用 Power Automate 進行電子郵件・單據處理自動化設計，以及受發訂業務數位化分階段轉移方面的諮詢。

• 技術諮詢・設計審查
• Windows 應用程式開發
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

共用信箱收到的郵件，也能啟動 Power Automate 的流程嗎？

可以。Office 365 Outlook 連接器有一個專用觸發程序「共用信箱收到新郵件時 (V2)」，可以用送達訂單受理用共用信箱的郵件作為起點來啟動流程。前提是，用於連線的帳戶必須擁有該共用信箱的存取權限。要注意的是，授予權限後可能需要約 2 小時才會生效，而且 Microsoft 365 群組的地址不能指定為共用信箱。用共用信箱而非承辦人員個人的收件匣來接收，比較容易把接收窗口交接下去，但流程的連線本身仍會綁定在建立流程的使用者帳戶上，因此也需要一併決定連線所用帳戶的處理方式，以及共同擁有者的設定。

為什麼電子郵件簽名的圖片會被當成附件保存下來？

因為嵌入郵件內文中的簽名圖片或標誌，在資料上屬於附件的一種（內嵌附件）。若只用「有附件」這個條件來處理，就會把簽名的 PNG 或 GIF 和本命的 PDF 一起保存下來。對策是利用 Office 365 Outlook 連接器針對每個附件回傳的 Is Inline 這項中繼資料，在條件分支中只處理 Is Inline 為 false 的項目。再疊加一層檔名副檔名是否為 .pdf 的判斷，就能更確實地縮小目標範圍。

要用 AI Builder 把 PDF 的讀取也自動化，需要準備什麼？

AI Builder 提供了預先建置的請款單處理模型，能從請款單擷取請款單編號、日期、合計金額等資訊，也支援日文的請款單。至於訂購單這類版面各異的獨特單據，則要用文件處理自訂模型來處理，用範例文件（每種版面至少 5 份）來訓練模型。執行時需要 AI Builder 點數之類的用量計費容量，若環境未分配到容量，流程就會因錯誤而停止。此外，2025 年 10 月已宣布 AI Builder 點數的階段性終止，今後會逐步移轉到 Copilot 點數，因此新導入時請務必確認最新的授權體系。

以有密碼的 ZIP (PPAP) 送達的附件，也能用流程處理嗎？

有密碼的 ZIP 與自動處理在本質上就合不來，不應該以「在流程中解壓縮」為前提來設計。因為密碼要另外用一封郵件送達、由人讀取後才能開啟，這種運用方式本身就沒有預設要給機器處理。雖然可以把 ZIP 原封不動保存到人可以開啟的位置，但這樣並不能連結到抄錄或讀取的自動化。現實的做法是與交易對象交涉，請對方停用 PPAP，也就是改變檔案的接收方式本身，這才是本質上的對策。PPAP 在安全性上也有不少問題，可參考另一篇整理 PPAP 問題點的文章，作為交涉的材料。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。