Approval Management Engine - 第5篇 (重要的屬性)

這篇就來試著列出一些重要的屬性 (Attribute)，可以搭配 AME 第二篇 一起參考。

(也許日後會再陸續新增)

JOB_LEVEL_NON_DEFAULT_STARTING_POINT_PERSON_ID

依組織架構簽核時的起始點的人員編號 (Person ID)

一般來說，就是按下送簽 (Submit) 的那個員工的第一層主管。

但是，如果有特殊的需求，這個屬性就可以讓你有很多的變化。比如說，Oracle iProcurement (請購單系統) 雖然標準就有支援代辦功能，可是設定上還是有很多的限制，我相信在多數的需求下，是沒有完美地滿足需求的。所以，我們就可以例用彈性欄位 (Descriptive Flexfield) 來滿足公司的需求，並透過指定這個屬性值，來讓被代辦人變成第一個簽核的人員。

TOP_SUPERVISOR_PERSON_ID

依組織架構簽核時的最終核准的人員編號 (Person ID)

一般來說，就是依據核決權限來決定的最終批准的人員。

但是，跟上面的理由差不多，都是會有例外情況的。如果，今天是 CEO 送出的單子 (我知道，哪有公司最大的主管會自己送單子，不過，誰知道呢？)，依一般的組織架構來說，CEO 本身是沒有主管的，這種情況下用標準的設定是一定會拋出 "找不到核准人員 (No Approver Found)" 的錯誤的，我們也不可能為了這種特殊特殊情況開啟 "送單人員可以核准自己單子" 的設定。這時候，從這邊下手就簡單一點了，客製的 Function 可以回傳如 CFO 等的人員，也就是可以選擇跳脫出核決權限以及組織架構的框架，這樣的核決設定就會相對合理。

FIRST_STARTING_POINT_PERSON_ID

使用 dual-chains approval type 時，第一起始點的人員編號 (Person ID)

SECOND_STARTING_POINT_PERSON_ID

使用 dual-chains approval type 時，第二起始點的人員編號 (Person ID)

dual-chains 的應用上比較難去舉例或想像的，功能上就是把"兩段"依據組織架構簽核的流程組合在一起。