เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงการชำระเงิน: การประมวลผลใบแจ้งหนี้
เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงการชำระเงิน: การประมวลผลใบแจ้งหนี้
- แอตทริบิวต์ที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- คำแนะนำในการดึงข้อมูลจาก Oracle Fusion Financials
แอตทริบิวต์สำหรับการประมวลผลใบแจ้งหนี้ในกระบวนการจัดซื้อจนถึงการชำระเงิน
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
หมายเลขใบแจ้งหนี้
InvoiceNumber
|
รหัสเฉพาะที่ใช้ระบุใบแจ้งหนี้จากผู้ขาย. | ||
|
คำอธิบาย
หมายเลขใบแจ้งหนี้เป็นรหัสหลักที่ใช้ระบุเคส โดยเชื่อมโยงกิจกรรมและเหตุการณ์ทั้งหมดของใบแจ้งหนี้จากผู้ขายแต่ละรายการ ตั้งแต่สร้างจนถึงชำระเงิน ใบแจ้งหนี้แต่ละรายการจึงเป็นเคสเฉพาะในการวิเคราะห์กระบวนการ. ใน process mining คุณสมบัตินี้เป็นข้อมูลพื้นฐานสำหรับสร้างลำดับการทำงานของใบแจ้งหนี้แต่ละรายการตั้งแต่ต้นจนจบ ช่วยวิเคราะห์ขั้นตอน ระยะเวลาของกระบวนการ และความแตกต่างของใบแจ้งหนี้แต่ละรายการ อีกทั้งยังเชื่อมกิจกรรมต่าง ๆ เช่น การตรวจสอบ การอนุมัติ และการชำระเงิน ให้เป็นเรื่องราวของกระบวนการเดียวกัน.
เหตุผลที่สำคัญ
นี่คือรหัสเคสสำคัญที่เชื่อมโยงขั้นตอนทั้งหมดของกระบวนการ ทำให้ติดตามวงจรของใบแจ้งหนี้ได้ตั้งแต่ต้นจนจบ.
แหล่งข้อมูล
โดยทั่วไปจะอยู่ในคอลัมน์ INVOICE_NUM ของตาราง AP_INVOICES_ALL.
ตัวอย่าง
ใบแจ้งหนี้-2023-001987654321เอซีเอ็มอี-การเงิน-5501
|
|||
|
กิจกรรม
ActivityName
|
ชื่อกิจกรรมทางธุรกิจหรือเหตุการณ์ที่เกิดขึ้นในกระบวนการใบแจ้งหนี้. | ||
|
คำอธิบาย
คุณสมบัตินี้อธิบายขั้นตอนหรือการเปลี่ยนสถานะในวงจรใบแจ้งหนี้ เช่น 'สร้างใบแจ้งหนี้' 'อนุมัติใบแจ้งหนี้แล้ว' หรือ 'ดำเนินการชำระเงินแล้ว' โดยกิจกรรมเหล่านี้เรียงต่อกันเป็นลำดับขั้นตอนของกระบวนการ. การวิเคราะห์ลำดับและความถี่ของกิจกรรมเป็นหัวใจของ process mining ช่วยค้นหาเส้นทางการทำงานจริง ระบุคอขวดที่ทำให้กิจกรรมล่าช้า และตรวจพบความเบี่ยงเบนหรือการทำงานซ้ำ เช่น ใบแจ้งหนี้ถูกปฏิเสธหลังจากได้รับอนุมัติแล้ว.
เหตุผลที่สำคัญ
คุณสมบัตินี้กำหนดขั้นตอนของกระบวนการ ซึ่งจำเป็นต่อการแสดงแผนผังกระบวนการ วิเคราะห์ความแตกต่างของขั้นตอน และระบุคอขวด.
แหล่งข้อมูล
โดยทั่วไป คุณสมบัตินี้ได้มาจากการรวมฟิลด์สถานะ ตารางบันทึกการตรวจสอบ หรือบันทึกเวิร์กโฟลว์ใน Oracle Fusion Financials เช่น AP_INVOICES_ALL.WFAPPROVAL_STATUS หรือตารางเวิร์กโฟลว์ที่เกี่ยวข้อง.
ตัวอย่าง
ตรวจสอบใบแจ้งหนี้แล้วระงับใบแจ้งหนี้แล้วอนุมัติใบแจ้งหนี้แล้วดำเนินการชำระเงินแล้ว
|
|||
|
เวลาเริ่มต้น
EventTime
|
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เกิดขึ้นเมื่อใด. | ||
|
คำอธิบาย
คุณสมบัตินี้ระบุวันที่และเวลาของแต่ละกิจกรรมในกระบวนการใบแจ้งหนี้ ซึ่งจำเป็นต่อการวิเคราะห์กระบวนการตามเวลา รวมถึงการคำนวณระยะเวลาของกระบวนการ ระยะเวลาทำงาน และเวลารอระหว่างขั้นตอน. เครื่องมือ process mining ใช้เวลานี้เรียงเหตุการณ์ตามลำดับเวลา เพื่อสร้างลำดับกิจกรรมที่เกิดขึ้นจริงของใบแจ้งหนี้แต่ละรายการ ช่วยคำนวณ KPI สำคัญ เช่น ระยะเวลารอบใบแจ้งหนี้เฉลี่ย และระบุได้ว่าขั้นตอนใดใช้เวลามากที่สุด.
เหตุผลที่สำคัญ
เวลานี้จำเป็นต่อการคำนวณตัวชี้วัดประสิทธิภาพด้านระยะเวลา เช่น ระยะเวลาของกระบวนการและคอขวด.
แหล่งข้อมูล
เวลานี้ได้มาจากฟิลด์วันที่ต่าง ๆ ในตาราง Oracle Fusion เช่น CREATION_DATE หรือ LAST_UPDATE_DATE ในตาราง AP_INVOICES_ALL รวมถึงตารางเวิร์กโฟลว์และการชำระเงินที่เกี่ยวข้อง.
ตัวอย่าง
2023-04-15T10:00:00Z2023-04-16T14:35:10Z2023-04-20T09:05:00Z
|
|||
|
ชื่อผู้ขาย
VendorName
|
ชื่อผู้ขายหรือผู้จัดหาที่ออกใบแจ้งหนี้. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุผู้จัดหาที่ออกใบแจ้งหนี้ ข้อมูลผู้ขายช่วยให้เข้าใจบริบททางธุรกิจของธุรกรรมทางการเงิน การวิเคราะห์กระบวนการแยกตามผู้ขายช่วยให้เห็นข้อมูลสำคัญเกี่ยวกับความสัมพันธ์และประสิทธิภาพของผู้จัดหา ตัวอย่างเช่น อาจพบว่าใบแจ้งหนี้จากผู้ขายบางรายมีปัญหาในการจับคู่ ถูกระงับ หรือเกิดความล่าช้าบ่อยกว่ารายอื่น ข้อมูลนี้นำไปใช้ปรับปรุงการเริ่มต้นทำธุรกิจกับผู้ขาย การสื่อสาร และประสิทธิภาพของห่วงโซ่อุปทานโดยรวมได้ อีกทั้งยังช่วยค้นหาการชำระเงินซ้ำที่อาจเกิดขึ้น.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์กระบวนการแยกตามผู้ขาย เพื่อค้นหาปัญหาจากผู้จัดหาบางรายที่ทำให้เกิดความล่าช้าหรือข้อยกเว้น.
แหล่งข้อมูล
อยู่ในตาราง POZ_SUPPLIERS โดยตารางใบแจ้งหนี้ AP_INVOICES_ALL มี VENDOR_ID ซึ่งใช้เชื่อมกับตารางผู้จัดหาได้.
ตัวอย่าง
Acme CorporationGlobal Tech Inc.Office Supplies Co.
|
|||
|
ชื่อผู้ใช้
UserName
|
ชื่อผู้ใช้ที่ดำเนินกิจกรรม. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุผู้ใช้หรือเอเจนต์ของระบบที่รับผิดชอบกิจกรรม เช่น ตรวจสอบใบแจ้งหนี้ ระงับรายการ หรืออนุมัติการชำระเงิน จึงช่วยให้วิเคราะห์กระบวนการในมิติของทรัพยากรบุคคลหรือระบบได้ การวิเคราะห์แยกตามผู้ใช้ช่วยให้เห็นการกระจายภาระงาน ระบุผู้ที่ทำผลงานได้ดี และค้นหาความจำเป็นในการฝึกอบรมหรือปัญหาด้านการปฏิบัติตามข้อกำหนด ตัวอย่างเช่น คุณอาจพบว่าผู้ใช้บางรายเกี่ยวข้องกับการแก้ไขงานซ้ำอยู่เสมอ หรือมีผู้อนุมัติคนเดิมรับผิดชอบขั้นตอนอนุมัติบางขั้นตอนทุกครั้ง ซึ่งอาจทำให้กระบวนการต้องพึ่งพาบุคคลใดบุคคลหนึ่งมากเกินไป.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ประสิทธิภาพของทรัพยากร ปรับสมดุลภาระงาน และระบุผู้ใช้หรือทีมที่เกี่ยวข้องในแต่ละขั้นตอนของกระบวนการ.
แหล่งข้อมูล
ข้อมูลนี้มักจัดเก็บในคอลัมน์ตรวจสอบ เช่น CREATED_BY หรือ LAST_UPDATED_BY ในตารางอย่าง AP_INVOICES_ALL หรือในบันทึกเวิร์กโฟลว์ที่เกี่ยวข้อง.
ตัวอย่าง
john.doejane.smithSystem.Admin
|
|||
|
ยอดเงินในใบแจ้งหนี้
InvoiceAmount
|
มูลค่ารวมของใบแจ้งหนี้. | ||
|
คำอธิบาย
ยอดเงินในใบแจ้งหนี้คือยอดรวมที่ต้องชำระให้ผู้ขายตามที่ระบุในใบแจ้งหนี้ ข้อมูลทางการเงินนี้มีผลต่อกระบวนการทั้งหมด โดยมักใช้กำหนดเส้นทางอนุมัติ ระดับการตรวจสอบ และลำดับความสำคัญในการชำระเงิน ในการวิเคราะห์ process mining ยอดเงินในใบแจ้งหนี้เป็นมิติสำคัญสำหรับการกรองและแบ่งกลุ่มข้อมูล ตัวอย่างเช่น นักวิเคราะห์สามารถเปรียบเทียบกระบวนการของใบแจ้งหนี้มูลค่าสูงกับมูลค่าต่ำ เพื่อดูว่าใช้เส้นทางต่างกันหรือใช้เวลาดำเนินการต่างกันมากหรือไม่ นอกจากนี้ยังจำเป็นต่อการคำนวณ KPI ทางการเงินและประเมินผลกระทบด้านมูลค่าเงินจากความไม่มีประสิทธิภาพ เช่น การชำระเงินล่าช้า.
เหตุผลที่สำคัญ
ค่านี้สำคัญต่อการวิเคราะห์ทางการเงิน การทำความเข้าใจความแตกต่างของกระบวนการตามมูลค่า และการคำนวณ KPI เช่น อัตราการปฏิบัติตามข้อกำหนดในการอนุมัติ.
แหล่งข้อมูล
อยู่ในคอลัมน์ INVOICE_AMOUNT ของตาราง AP_INVOICES_ALL.
ตัวอย่าง
1500.00250.75125000.50
|
|||
|
รหัสบริษัท
CompanyCode
|
รหัสนิติบุคคลหรือบริษัทที่ดำเนินการกับใบแจ้งหนี้. | ||
|
คำอธิบาย
รหัสบริษัทระบุนิติบุคคลภายในองค์กรที่รับผิดชอบด้านการเงินของใบแจ้งหนี้ สำหรับองค์กรที่มีหลายบริษัท ข้อมูลนี้เป็นข้อมูลพื้นฐานด้านโครงสร้างองค์กร แอตทริบิวต์นี้ช่วยแบ่งการวิเคราะห์กระบวนการตามนิติบุคคล ทำให้เปรียบเทียบประสิทธิภาพของกระบวนการในส่วนต่างๆ ของธุรกิจ ค้นหาคอขวดหรือปัญหาด้านการปฏิบัติตามข้อกำหนดของแต่ละนิติบุคคล และรายงาน KPI แยกตามบริษัทได้ นอกจากนี้ รหัสบริษัทยังมักเป็นปัจจัยที่ใช้กำหนดเวิร์กโฟลว์อนุมัติที่ถูกต้อง.
เหตุผลที่สำคัญ
ช่วยเปรียบเทียบกระบวนการและวัดประสิทธิภาพระหว่างนิติบุคคลหรือหน่วยธุรกิจต่างๆ ภายในองค์กร.
แหล่งข้อมูล
โดยทั่วไปข้อมูลนี้อยู่ในฟิลด์ LEGAL_ENTITY_ID หรือฟิลด์ที่คล้ายกันใน AP_INVOICES_ALL ซึ่งเชื่อมกับตารางบัญชีแยกประเภททั่วไปเพื่อดึงรหัสหรือชื่อได้.
ตัวอย่าง
1001US01DE01
|
|||
|
วันครบกำหนดชำระเงิน
PaymentDueDate
|
วันที่ต้องชำระเงินตามใบแจ้งหนี้ให้ผู้ขาย. | ||
|
คำอธิบาย
วันครบกำหนดชำระเงินคำนวณจากเงื่อนไขการชำระเงินที่ตกลงกับผู้ขาย โดยเป็นกำหนดเวลาที่ต้องชำระเพื่อหลีกเลี่ยงค่าปรับ รักษาความสัมพันธ์ที่ดีกับผู้ขาย และใช้ประโยชน์จากส่วนลดเมื่อชำระก่อนกำหนด แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด «ประสิทธิภาพการชำระเงินตรงเวลา» และ KPI ที่เกี่ยวข้อง เมื่อนำเวลาที่ชำระเงินจริงมาเปรียบเทียบกับวันครบกำหนดชำระเงิน ก็จะจำแนกได้ว่าชำระตรงเวลาหรือล่าช้า ช่วยให้องค์กรติดตามและปรับปรุงความตรงเวลาของการชำระเงินได้.
เหตุผลที่สำคัญ
ใช้เป็นเกณฑ์วัดประสิทธิภาพการชำระเงินตรงเวลา ซึ่งเป็น KPI สำคัญสำหรับการบริหารผู้ขายและสถานะทางการเงิน.
แหล่งข้อมูล
วันที่นี้มักอยู่ในตารางกำหนดการชำระเงิน เช่น AP_PAYMENT_SCHEDULES_ALL ซึ่งเชื่อมโยงกับใบแจ้งหนี้.
ตัวอย่าง
2023-05-152023-06-012023-06-30
|
|||
|
เวลาสิ้นสุด
EndTime
|
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด. | ||
|
คำอธิบาย
เวลาสิ้นสุดระบุว่ากิจกรรมหนึ่งเสร็จเมื่อใด ส่วนเวลาเริ่มต้นระบุจุดเริ่มต้น เมื่อนำเวลาทั้งสองมาใช้ร่วมกันจึงคำนวณระยะเวลาของแต่ละขั้นตอนได้อย่างแม่นยำ. ในการวิเคราะห์ เวลาสิ้นสุดลบด้วยเวลาเริ่มต้นจะได้เวลาที่ใช้ประมวลผลแต่ละกิจกรรม ซึ่งจำเป็นต่อการวิเคราะห์ประสิทธิภาพอย่างละเอียดและช่วยแยกเวลาทำงานจริงออกจากเวลารอ เช่น ใช้วัดเวลาที่ผู้อนุมัติใช้พิจารณางาน เทียบกับเวลาที่งานค้างอยู่ในคิว.
เหตุผลที่สำคัญ
ช่วยคำนวณเวลาประมวลผลของแต่ละกิจกรรมได้อย่างแม่นยำ และแยกเวลาทำงานจริงออกจากเวลารอ.
แหล่งข้อมูล
แอตทริบิวต์เชิงแนวคิดนี้ได้จากเวลาเริ่มต้นของกิจกรรมถัดไปในลำดับของเคสที่กำหนดไว้.
ตัวอย่าง
2023-04-15T10:05:12Z2023-04-16T15:00:00Z2023-04-20T09:15:30Z
|
|||
|
สถานะใบแจ้งหนี้
InvoiceStatus
|
สถานะปัจจุบันของใบแจ้งหนี้ในแต่ละช่วงของกระบวนการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงสถานะล่าสุดของใบแจ้งหนี้ เช่น «ตรวจสอบแล้ว» «ต้องตรวจสอบอีกครั้ง» «ชำระแล้ว» หรือ «ยกเลิกแล้ว» จึงช่วยให้ทราบว่าใบแจ้งหนี้อยู่ในขั้นตอนไหนของกระบวนการ ณ เวลานั้น สถานะใบแจ้งหนี้เป็นข้อมูลสำคัญสำหรับแดชบอร์ด «สัดส่วนสถานะใบแจ้งหนี้ปัจจุบัน» ซึ่งช่วยให้ผู้จัดการฝ่ายปฏิบัติการเห็นงานค้างและติดตามภาพรวมการประมวลผลใบแจ้งหนี้ได้ การวิเคราะห์การเปลี่ยนแปลงของสถานะตามเวลายังช่วยให้เห็นภาพรวมของลำดับขั้นตอนในกระบวนการได้ด้วย.
เหตุผลที่สำคัญ
แสดงสถานะปัจจุบันของใบแจ้งหนี้ ซึ่งจำเป็นต่อแดชบอร์ดการปฏิบัติการที่ใช้ติดตามงานค้างและภาระงาน.
แหล่งข้อมูล
ดูเอกสาร Oracle Fusion Financials โดยอาจอนุมานสถานะจากฟิลด์ เช่น WFAPPROVAL_STATUS ใน AP_INVOICES_ALL หรือตารางการอนุมัติและการชำระเงินที่เกี่ยวข้อง.
ตัวอย่าง
ตรวจสอบแล้วชำระแล้วยกเลิกแล้วต้องตรวจสอบอีกครั้ง
|
|||
|
ชำระเงินตรงเวลาหรือไม่
IsOnTimePayment
|
ค่าสถานะบูลีนที่ระบุว่าใบแจ้งหนี้ได้รับการชำระภายในวันครบกำหนดหรือไม่. | ||
|
คำอธิบาย
กำหนดค่านี้เป็น true หากชำระเงินในหรือก่อนวันครบกำหนดชำระเงินที่ระบุ และเป็น false หากชำระหลังจากนั้น ช่วยจัดประเภทใบแจ้งหนี้ที่ชำระแล้วแต่ละรายการได้อย่างชัดเจน แอตทริบิวต์ที่คำนวณนี้รองรับ KPI อัตราการชำระเงินตรงเวลาและแดชบอร์ดที่เกี่ยวข้อง ช่วยให้ผู้ใช้กรอง นับ และแสดงสัดส่วนการชำระเงินล่าช้าเทียบกับตรงเวลาได้ง่าย โดยไม่ต้องเปรียบเทียบวันที่ทุกครั้ง จึงช่วยให้เห็นขนาดของปัญหาการชำระเงินล่าช้าและติดตามการปรับปรุงตามเวลาได้รวดเร็ว.
เหตุผลที่สำคัญ
ช่วยให้วิเคราะห์ความตรงเวลาของการชำระเงินได้ง่ายขึ้น และใช้คำนวณ KPI อัตราการชำระเงินตรงเวลาโดยตรง.
แหล่งข้อมูล
แอตทริบิวต์นี้คำนวณจากการเปรียบเทียบเวลาของกิจกรรม «ดำเนินการชำระเงิน» กับแอตทริบิวต์ «PaymentDueDate».
ตัวอย่าง
truefalse
|
|||
|
ชื่อผู้อนุมัติ
ApproverName
|
ชื่อผู้ที่อนุมัติหรือปฏิเสธใบแจ้งหนี้. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกชื่อบุคคลที่ดำเนินการในขั้นตอนอนุมัติ เช่น กิจกรรม «อนุมัติใบแจ้งหนี้» หรือ «ปฏิเสธใบแจ้งหนี้» การวิเคราะห์ชื่อผู้อนุมัติช่วยให้เข้าใจภาระงานอนุมัติ วัดระยะเวลาที่ผู้อนุมัติแต่ละรายใช้ดำเนินการ และตรวจสอบการปฏิบัติตามนโยบายอนุมัติ สำหรับ KPI «อัตราการปฏิบัติตามข้อกำหนดในการอนุมัติ» สามารถตรวจสอบแอตทริบิวต์นี้กับกฎการมอบอำนาจอนุมัติตามยอดเงินในใบแจ้งหนี้และรหัสบริษัทได้.
เหตุผลที่สำคัญ
จำเป็นต่อการวิเคราะห์ระยะเวลาการอนุมัติ ตรวจสอบการปฏิบัติตามนโยบายตารางอำนาจอนุมัติ และทำความเข้าใจการกระจายภาระงาน.
แหล่งข้อมูล
ข้อมูลนี้อยู่ในตารางเวิร์กโฟลว์หรือประวัติการอนุมัติของ Oracle Fusion ที่เชื่อมโยงกับออบเจ็กต์ใบแจ้งหนี้.
ตัวอย่าง
David WilsonSarah JohnsonMichael Brown
|
|||
|
เป็นการแก้ไขงานซ้ำหรือไม่
IsRework
|
ค่าสถานะบูลีนที่ระบุกิจกรรมซึ่งเป็นส่วนหนึ่งของวงจรการทำงานซ้ำ. | ||
|
คำอธิบาย
กำหนดค่านี้เป็น true สำหรับกิจกรรมที่บ่งชี้ว่ากระบวนการเบี่ยงเบนจากเส้นทางที่ควรเป็น เช่น «แก้ไขใบแจ้งหนี้» หรือการเกิดกิจกรรม «ตรวจสอบใบแจ้งหนี้» ครั้งที่สองหลังจากถูกปฏิเสธ ช่วยระบุและวัดปริมาณวงจรการทำงานซ้ำที่ไม่มีประสิทธิภาพได้อย่างชัดเจน แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด «อัตราการแก้ไขงานซ้ำและการจัดการข้อยกเว้น» เมื่อติดป้ายกิจกรรมที่เป็นการแก้ไขงานซ้ำ นักวิเคราะห์จะวัดปริมาณและต้นทุนของงานซ้ำ ค้นหาสาเหตุที่แท้จริง และประเมินผลของโครงการปรับปรุงกระบวนการที่มุ่งทำงานให้ถูกต้องตั้งแต่ครั้งแรกได้ง่ายขึ้น.
เหตุผลที่สำคัญ
ระบุและวัดปริมาณงานที่ต้องแก้ไขซ้ำได้โดยตรง ทำให้วิเคราะห์ความถี่ สาเหตุ และผลกระทบของปัญหาในกระบวนการได้ง่ายขึ้น.
แหล่งข้อมูล
แอตทริบิวต์นี้คำนวณจากตรรกะที่กำหนดระหว่างการแปลงข้อมูล เพื่อระบุลำดับกิจกรรมที่ถือเป็นการทำงานซ้ำ.
ตัวอย่าง
truefalse
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบุระบบต้นทางที่บันทึกข้อมูลเหตุการณ์. | ||
|
คำอธิบาย
คุณสมบัตินี้ระบุแอปพลิเคชันหรือโมดูลต้นทางที่สร้างข้อมูล เช่น Oracle Fusion Financials ในสภาพแวดล้อมที่เชื่อมต่อหลายระบบ ฟิลด์นี้ช่วยแยกแหล่งที่มาของแต่ละขั้นตอนในกระบวนการ. การทราบระบบต้นทางมีประโยชน์ต่อการตรวจสอบข้อมูล การแก้ปัญหา และการวิเคราะห์ความแตกต่างของกระบวนการที่อาจเกิดจากระบบใดระบบหนึ่งโดยเฉพาะ อีกทั้งยังช่วยให้เห็นภาพชัดเจนในสภาพแวดล้อม IT ที่ซับซ้อน ซึ่งใบแจ้งหนี้อาจผ่านหลายแอปพลิเคชัน.
เหตุผลที่สำคัญ
ช่วยให้ทราบที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลข้อมูล การแก้ปัญหา และการวิเคราะห์พฤติกรรมของกระบวนการในแต่ละระบบ.
แหล่งข้อมูล
โดยทั่วไปจะเพิ่มค่าแบบคงที่ระหว่างการดึงข้อมูล เพื่อระบุแหล่งที่มาของชุดข้อมูล.
ตัวอย่าง
Oracle Fusion FinancialsOracle Payables Cloud
|
|||
|
วันที่ในใบแจ้งหนี้
InvoiceDate
|
วันที่ที่ระบุในเอกสารใบแจ้งหนี้ของผู้ขาย. | ||
|
คำอธิบาย
แอตทริบิวต์นี้คือวันที่ผู้ขายออกใบแจ้งหนี้อย่างเป็นทางการ ซึ่งเป็นข้อมูลสำคัญในเอกสารต้นทาง และใช้เป็นจุดเริ่มต้นในการคำนวณวันครบกำหนดชำระเงินตามเงื่อนไขที่ตกลงกัน แม้วันที่ในใบแจ้งหนี้จะไม่ใช่จุดเริ่มต้นของกระบวนการภายในเสมอไป แต่ก็เป็นข้อมูลประกอบที่สำคัญ เมื่อนำไปใช้ร่วมกับชื่อผู้ขายและยอดเงินในใบแจ้งหนี้ จะช่วยค้นหาใบแจ้งหนี้ซ้ำที่อาจเกิดขึ้นได้ นอกจากนี้ การวิเคราะห์ช่วงเวลาระหว่างวันที่ในใบแจ้งหนี้กับวันที่สร้างใบแจ้งหนี้ในระบบ ยังช่วยให้เห็นความไม่มีประสิทธิภาพในงานรับเอกสารหรือการนำใบแจ้งหนี้เข้าสู่ระบบ.
เหตุผลที่สำคัญ
เป็นข้อมูลสำคัญในการระบุใบแจ้งหนี้ซ้ำและคำนวณวันครบกำหนดชำระเงิน.
แหล่งข้อมูล
เป็นฟิลด์มาตรฐานในตาราง AP_INVOICES_ALL ชื่อ INVOICE_DATE.
ตัวอย่าง
2023-04-102023-05-012023-05-25
|
|||
|
สกุลเงิน
InvoiceCurrencyCode
|
สกุลเงินของยอดเงินในใบแจ้งหนี้. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุสกุลเงินของใบแจ้งหนี้ เช่น USD, EUR หรือ GBP และเป็นข้อมูลประกอบที่จำเป็นสำหรับฟิลด์ยอดเงินในใบแจ้งหนี้ สำหรับองค์กรระดับโลก การวิเคราะห์ใบแจ้งหนี้ตามสกุลเงินมีความสำคัญต่อการรายงานทางการเงินและการทำความเข้าใจความแตกต่างของกระบวนการในแต่ละภูมิภาค ช่วยให้ตีความมูลค่าเงินได้ถูกต้อง และวิเคราะห์แนวทางการชำระเงินหรือเกณฑ์อนุมัติแยกตามสกุลเงินได้.
เหตุผลที่สำคัญ
ให้ข้อมูลประกอบที่จำเป็นสำหรับยอดเงิน ช่วยให้ตีความและวิเคราะห์ได้ถูกต้อง โดยเฉพาะในการปฏิบัติการข้ามประเทศ.
แหล่งข้อมูล
อยู่ในคอลัมน์ INVOICE_CURRENCY_CODE ของตาราง AP_INVOICES_ALL.
ตัวอย่าง
USDEURGBPCAD
|
|||
|
หมายเลขใบสั่งซื้อ
PurchaseOrderNumber
|
รหัสใบสั่งซื้อที่เชื่อมโยงกับใบแจ้งหนี้. | ||
|
คำอธิบาย
แอตทริบิวต์นี้เชื่อมใบแจ้งหนี้กับใบสั่งซื้อ (PO) ที่ใช้อนุมัติการจัดซื้อสินค้าหรือบริการ ใบแจ้งหนี้อาจมี PO รองรับหรือไม่มี PO ก็ได้ การวิเคราะห์แยกตาม PO ช่วยเชื่อมโยงกลับไปยังส่วนจัดซื้อของกระบวนการ P2P ทำให้เข้าใจว่ากระบวนการจัดซื้อปฏิบัติตามข้อกำหนดมากน้อยเพียงใด และปัญหาในใบแจ้งหนี้ เช่น การจับคู่ข้อมูลไม่ตรงกัน มีสาเหตุมาจากปัญหาใน PO ตั้งแต่แรกหรือไม่ การมีหรือไม่มีหมายเลข PO เป็นวิธีหลักในการแบ่งกลุ่มและวิเคราะห์เส้นทางการประมวลผลใบแจ้งหนี้ที่แตกต่างกัน.
เหตุผลที่สำคัญ
เชื่อมใบแจ้งหนี้กลับไปยังกระบวนการจัดซื้อ และเป็นแอตทริบิวต์สำคัญสำหรับวิเคราะห์เส้นทางใบแจ้งหนี้ที่มี PO เทียบกับไม่มี PO.
แหล่งข้อมูล
ดึงข้อมูลนี้ได้โดยเชื่อมรายการใบแจ้งหนี้ใน AP_INVOICE_LINES_ALL กับรายการแจกแจงของ PO ผ่าน PO_DISTRIBUTION_ID.
ตัวอย่าง
PO-2023-5001600789PO-FIN-9981
|
|||
|
เหตุผลที่ข้อมูลจับคู่ไม่ตรงกัน
MatchingDiscrepancyReason
|
สาเหตุที่ข้อมูลในใบแจ้งหนี้ ใบสั่งซื้อ และใบรับสินค้าไม่ตรงกัน. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุสาเหตุที่ใบแจ้งหนี้ไม่ผ่านการจับคู่อัตโนมัติ สาเหตุที่พบบ่อย ได้แก่ ราคา จำนวน หรือรหัสสินค้าในใบแจ้งหนี้ไม่ตรงกับใบสั่งซื้อหรือใบรับสินค้าที่เกี่ยวข้อง ข้อมูลนี้สำคัญต่อแดชบอร์ด «อัตราความคลาดเคลื่อนในการจับคู่ใบแจ้งหนี้» เมื่อจัดหมวดหมู่และวิเคราะห์สาเหตุของความคลาดเคลื่อน บริษัทจะระบุปัญหาเชิงระบบในกระบวนการจัดซื้อหรือรับสินค้าได้ และนำไปแก้ไขเพื่อเพิ่มสัดส่วนใบแจ้งหนี้ที่ประมวลผลได้ตั้งแต่ต้นจนจบโดยไม่ต้องดำเนินการด้วยตนเอง.
เหตุผลที่สำคัญ
อธิบายสาเหตุที่ใบแจ้งหนี้จับคู่อัตโนมัติไม่ผ่าน ช่วยให้เห็นข้อมูลที่จำเป็นต่อการเพิ่มอัตราการจับคู่สำเร็จตั้งแต่ครั้งแรกและลดการแก้ไขงานด้วยตนเอง.
แหล่งข้อมูล
ดูเอกสาร Oracle Fusion Financials โดยข้อมูลนี้อาจบันทึกเป็นประเภทเหตุผลการระงับใน AP_HOLDS_ALL หรือตารางรายละเอียดการจับคู่ที่เกี่ยวข้อง.
ตัวอย่าง
ราคาต่อหน่วยไม่ตรงกับ POจำนวนที่เรียกเก็บ > จำนวนที่รับรายการสินค้าในใบแจ้งหนี้ไม่ถูกต้อง
|
|||
|
เหตุผลที่ระงับ
HoldReason
|
เหตุผลที่ระงับหรือบล็อกการชำระเงินของใบแจ้งหนี้. | ||
|
คำอธิบาย
เมื่อระงับใบแจ้งหนี้ แอตทริบิวต์นี้จะระบุสาเหตุ เช่น «ราคาไม่ตรงกัน» «จำนวนไม่ตรงกัน» หรือ «รอรับสินค้า» ช่วยให้เข้าใจว่าเหตุใดขั้นตอนปกติจึงหยุดชะงัก แอตทริบิวต์นี้เป็นมิติหลักของแดชบอร์ด «แนวโน้มและการวิเคราะห์การบล็อกการชำระเงิน» เมื่อวิเคราะห์ความถี่ของเหตุผลในการระงับ ธุรกิจจะค้นหาและแก้ไขสาเหตุที่แท้จริงของการบล็อกการชำระเงินได้ เช่น ปัญหาในกระบวนการจัดซื้อหรือความถูกต้องของใบแจ้งหนี้จากผู้ขาย ซึ่งจะช่วยลดความล่าช้าในการประมวลผล.
เหตุผลที่สำคัญ
แสดงสาเหตุที่แท้จริงของการบล็อกการชำระเงิน ช่วยให้ปรับปรุงได้ตรงจุดเพื่อลดการระงับและความล่าช้าในการชำระเงิน.
แหล่งข้อมูล
ข้อมูลการระงับมักจัดเก็บในตาราง AP_HOLDS_ALL ซึ่งเชื่อมโยงกับใบแจ้งหนี้และมีเหตุผลหรือรหัสการระงับ.
ตัวอย่าง
ราคาไม่ตรงกันจำนวนที่เรียกเก็บมากกว่าจำนวนที่รับหมายเลข PO ไม่ถูกต้อง
|
|||
|
อัปเดตข้อมูลล่าสุด
LastUpdateDate
|
เวลาที่ระบุว่าระเบียนได้รับการอัปเดตครั้งล่าสุดในระบบต้นทางเมื่อใด. | ||
|
คำอธิบาย
คุณสมบัตินี้ระบุเวลาที่แก้ไขข้อมูลต้นทางใน Oracle Fusion Financials ล่าสุด ใช้จัดการการโหลดข้อมูลแบบเพิ่มเฉพาะส่วนและช่วยให้โมเดล process mining เป็นปัจจุบัน. แม้จะไม่ได้ใช้วิเคราะห์ขั้นตอนของกระบวนการโดยตรง แต่เวลาทางเทคนิคนี้สำคัญต่อการรักษาความใหม่และความถูกต้องของข้อมูล ไปป์ไลน์ข้อมูลใช้เวลานี้ค้นหาเฉพาะระเบียนใหม่หรือระเบียนที่เปลี่ยนแปลงนับจากการอัปเดตครั้งก่อน จึงลดภาระของระบบต้นทาง.
เหตุผลที่สำคัญ
ช่วยให้ไปป์ไลน์ข้อมูลทำงานแบบเพิ่มเฉพาะส่วนได้อย่างมีประสิทธิภาพ ทำให้การวิเคราะห์กระบวนการเป็นปัจจุบันโดยไม่ต้องโหลดข้อมูลทั้งหมดใหม่.
แหล่งข้อมูล
โดยทั่วไปพบในชื่อ LAST_UPDATE_DATE ในตาราง Oracle Fusion หลายตาราง รวมถึง AP_INVOICES_ALL.
ตัวอย่าง
2023-05-20T11:00:00Z2023-05-21T16:45:00Z
|
|||
กิจกรรมในการประมวลผลใบแจ้งหนี้สำหรับกระบวนการจัดซื้อจนถึงการชำระเงิน
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
จับคู่ใบแจ้งหนี้กับ PO แล้ว
|
กิจกรรมนี้หมายถึงการจับคู่รายการใบแจ้งหนี้กับรายการ Purchase Order ที่เกี่ยวข้องสำเร็จ เพื่อยืนยันว่ามีการสั่งซื้อสินค้าหรือบริการตามที่เรียกเก็บเงิน โดยทั่วไประบบจะบันทึกการดำเนินการนี้ ไม่ว่าจะทำโดยอัตโนมัติหรือด้วยมือ. | ||
|
เหตุผลที่สำคัญ
เป็นขั้นตอนสำคัญของการจับคู่สามทางระหว่าง PO ใบรับสินค้า และใบแจ้งหนี้ หากจับคู่ไม่สำเร็จ มักทำให้เกิดกรณียกเว้นและความล่าช้า.
แหล่งข้อมูล
อนุมานได้จากการสร้างระเบียนในตาราง AP_INVOICE_DISTRIBUTIONS_ALL ที่เชื่อมใบแจ้งหนี้กับการกระจายรายการ PO (PO_DISTRIBUTION_ID) นอกจากนี้ยังใช้สถานะการจับคู่ระดับรายการใน AP_INVOICE_LINES_ALL ได้.
บันทึก
อนุมานจากข้อมูลการกระจายรายการ PO ที่ระบุในรายการใบแจ้งหนี้.
ประเภทเหตุการณ์
inferred
|
|||
|
ดำเนินการชำระเงินแล้ว
|
เป็นการยืนยันขั้นสุดท้ายว่าชำระเงินและเรียกเก็บเงินเรียบร้อยแล้ว สำหรับเช็คจะใช้วันที่เรียกเก็บเงิน ส่วนการชำระเงินทางอิเล็กทรอนิกส์จะใช้การยืนยันจากธนาคาร. | ||
|
เหตุผลที่สำคัญ
เป็นกิจกรรมสุดท้ายในวงจรใบแจ้งหนี้ แสดงว่ากระบวนการเสร็จสมบูรณ์ และเป็นจุดสิ้นสุดสำหรับคำนวณ 'ระยะเวลารอบใบแจ้งหนี้เฉลี่ย' และ 'อัตราการชำระเงินตรงเวลา'.
แหล่งข้อมูล
อนุมานได้จากการอัปเดตสถานะการชำระเงินเป็น 'Cleared' หรือ 'Reconciled' ในตาราง AP_CHECKS_ALL โดยใช้ CLEARED_DATE หรือใช้ข้อมูลการกระทบยอดธนาคารจากโมดูล Cash Management (CE_STATEMENT_LINES).
บันทึก
อนุมานจากการอัปเดตสถานะใน AP_CHECKS_ALL หรือการกระทบยอดในโมดูล CE.
ประเภทเหตุการณ์
inferred
|
|||
|
บันทึกบัญชีใบแจ้งหนี้แล้ว
|
ระบบบันทึกใบแจ้งหนี้ลงในบัญชีแยกประเภททั่วไปและสร้างรายการบัญชี เหตุการณ์นี้ยืนยันว่ามีการบันทึกผลกระทบทางการเงินของใบแจ้งหนี้อย่างเป็นทางการแล้ว. | ||
|
เหตุผลที่สำคัญ
เป็นจุดควบคุมทางการเงินที่สำคัญและเป็นเงื่อนไขก่อนชำระเงิน ยืนยันว่าใบแจ้งหนี้ผ่านการตรวจสอบและอนุมัติครบถ้วน พร้อมสำหรับการชำระ.
แหล่งข้อมูล
อนุมานได้จากสถานะในตาราง AP_INVOICE_DISTRIBUTIONS_ALL (ACCRUAL_POSTED_FLAG = 'Y') หรือจากการตรวจสอบรายการบัญชีที่เกี่ยวข้องในตารางบัญชีแยกประเภททั่วไป เช่น XLA_AE_HEADERS.
บันทึก
อนุมานจากแฟล็กใน AP_INVOICE_DISTRIBUTIONS_ALL หรือรายการบัญชีแยกประเภททั่วไปที่เชื่อมโยงกัน.
ประเภทเหตุการณ์
inferred
|
|||
|
ส่งใบแจ้งหนี้เพื่ออนุมัติแล้ว
|
ส่งใบแจ้งหนี้เข้าสู่เวิร์กโฟลว์การอนุมัติตามกฎทางธุรกิจที่ตั้งค่าไว้ ซึ่งเป็นจุดเริ่มต้นของรอบการอนุมัติอย่างเป็นทางการ. | ||
|
เหตุผลที่สำคัญ
เริ่มขั้นตอนสำคัญของกระบวนการ การติดตามเวลาเริ่มต้นนี้จำเป็นต่อการวัดและปรับปรุง 'ระยะเวลารอบการอนุมัติใบแจ้งหนี้'.
แหล่งข้อมูล
อนุมานได้จากการเปลี่ยนสถานะในตาราง AP_INVOICES_ALL เมื่อ APPROVAL_STATUS เปลี่ยนเป็นสถานะอย่าง 'Initiated' หรือ 'Pending Approval' ตารางเวิร์กโฟลว์อาจมีบันทึกเหตุการณ์นี้ด้วย.
บันทึก
อนุมานจากการเปลี่ยน AP_INVOICES_ALL.APPROVAL_STATUS เป็น 'Initiated'.
ประเภทเหตุการณ์
inferred
|
|||
|
สร้างใบแจ้งหนี้แล้ว
|
หมายถึงการสร้างระเบียนใบแจ้งหนี้ในระบบเป็นครั้งแรก ไม่ว่าจะกรอกข้อมูลด้วยมือ สแกน หรือส่งทางอิเล็กทรอนิกส์ โดยทั่วไปเหตุการณ์นี้จะบันทึกเมื่อมีการเพิ่มแถวใหม่ลงในตารางใบแจ้งหนี้หลัก. | ||
|
เหตุผลที่สำคัญ
เป็นจุดเริ่มต้นของวงจรการประมวลผลใบแจ้งหนี้ การวิเคราะห์เวลาตั้งแต่เหตุการณ์นี้ช่วยให้เข้าใจประสิทธิภาพการป้อนข้อมูลและความล่าช้าก่อนเริ่มกระบวนการโดยรวม.
แหล่งข้อมูล
ใน Oracle Fusion Financials เหตุการณ์นี้ตรงกับเวลาที่สร้างระเบียนในตาราง AP_INVOICES_ALL โดยเฉพาะคอลัมน์ CREATION_DATE.
บันทึก
เวลาที่สร้างระเบียนใน AP_INVOICES_ALL.
ประเภทเหตุการณ์
explicit
|
|||
|
อนุมัติใบแจ้งหนี้แล้ว
|
ผู้มีส่วนเกี่ยวข้องทุกคนในเวิร์กโฟลว์อนุมัติใบแจ้งหนี้ครบแล้ว ขณะนี้ใบแจ้งหนี้พร้อมสำหรับการบันทึกบัญชีและจัดกำหนดการชำระเงิน. | ||
|
เหตุผลที่สำคัญ
เป็นหมุดหมายสำคัญที่แสดงว่ากระบวนการอนุมัติเสร็จสมบูรณ์ ความล่าช้าก่อนถึงขั้นตอนนี้มักเป็นคอขวด.
แหล่งข้อมูล
อนุมานได้จากการเปลี่ยน APPROVAL_STATUS ในตาราง AP_INVOICES_ALL เป็นสถานะอนุมัติขั้นสุดท้าย เช่น 'Approved' หรือ 'Workflow Approved' โดยใช้ประวัติการตรวจสอบของฟิลด์นี้เพื่อระบุเวลา.
บันทึก
อนุมานจากการเปลี่ยน AP_INVOICES_ALL.APPROVAL_STATUS เป็น 'Approved'.
ประเภทเหตุการณ์
inferred
|
|||
|
แก้ไขใบแจ้งหนี้แล้ว
|
เกิดขึ้นเมื่อผู้ใช้แก้ไขใบแจ้งหนี้ โดยมักทำหลังถูกปฏิเสธหรือเพื่อแก้ข้อผิดพลาดในการป้อนข้อมูล นับเป็นขั้นตอนการแก้ไขด้วยมือในกระบวนการ. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้บ่งชี้ว่ามีการแก้ไขงานซ้ำ การวิเคราะห์ความถี่ช่วยวัดความไม่มีประสิทธิภาพของกระบวนการและใช้ประกอบ KPI 'อัตราการแก้ไขใบแจ้งหนี้'.
แหล่งข้อมูล
อนุมานได้จากการติดตามการอัปเดตข้อมูลสำคัญในระเบียนใบแจ้งหนี้ของ AP_INVOICES_ALL หลังจากตรวจสอบหรือส่งขออนุมัติแล้ว โดยต้องใช้เวลา LAST_UPDATE_DATE ร่วมกับข้อมูลบันทึกการตรวจสอบ.
บันทึก
อนุมานโดยเปรียบเทียบ LAST_UPDATE_DATE หลังการปฏิเสธหรือการระงับ.
ประเภทเหตุการณ์
inferred
|
|||
|
จัดกำหนดการชำระเงินแล้ว
|
เลือกใบแจ้งหนี้และรวมไว้ในคำขอประมวลผลการชำระเงิน ซึ่งมักเรียกว่ารอบการชำระเงินหรือชุดการชำระเงิน ขณะนี้ใบแจ้งหนี้อยู่ในคิวเพื่อรอชำระ. | ||
|
เหตุผลที่สำคัญ
เป็นขั้นตอนระหว่างการบันทึกบัญชีกับการชำระเงินจริง ระยะเวลาในขั้นตอนนี้ส่งผลต่อการคาดการณ์กระแสเงินสดและโอกาสใช้ส่วนลดเมื่อชำระก่อนกำหนด.
แหล่งข้อมูล
บันทึกเหตุการณ์นี้ในตาราง AP_INVOICE_PAYMENTS_ALL เมื่อสร้างระเบียนการชำระเงินแล้ว แต่ยังไม่ได้ยืนยันว่าชำระแล้ว นอกจากนี้ยังค้นหาได้ในตารางชุดการชำระเงิน เช่น IBY_PAYMENT_PROCESS_REQUESTS.
บันทึก
สร้างระเบียนการชำระเงินตามกำหนดใน AP_INVOICE_PAYMENTS_ALL.
ประเภทเหตุการณ์
explicit
|
|||
|
ตรวจสอบใบแจ้งหนี้แล้ว
|
หมายถึงใบแจ้งหนี้ผ่านการตรวจสอบความครบถ้วนและความถูกต้องของข้อมูลส่วนหัวและรายการในระบบแล้ว โดยมักอนุมานจากการเปลี่ยนสถานะของระเบียนใบแจ้งหนี้. | ||
|
เหตุผลที่สำคัญ
เป็นขั้นตอนสำคัญก่อนจับคู่และอนุมัติ หากล่าช้าอาจบ่งชี้ถึงปัญหาคุณภาพข้อมูลใบแจ้งหนี้หรือการตั้งค่าระบบ.
แหล่งข้อมูล
อนุมานได้จากการเปลี่ยนสถานะใบแจ้งหนี้เป็น 'Validated' ในตาราง AP_INVOICES_ALL โดยใช้ประวัติการเปลี่ยนแปลงหรือบันทึกการตรวจสอบของคอลัมน์ VALIDATION_STATUS.
บันทึก
อนุมานจากการเปลี่ยนแปลงฟิลด์ AP_INVOICES_ALL.VALIDATION_STATUS.
ประเภทเหตุการณ์
inferred
|
|||
|
ปฏิเสธใบแจ้งหนี้แล้ว
|
ผู้อนุมัติปฏิเสธใบแจ้งหนี้ระหว่างเวิร์กโฟลว์การอนุมัติ โดยทั่วไปใบแจ้งหนี้จะถูกส่งกลับไปแก้ไขหรือยกเลิก ทำให้เกิดขั้นตอนการทำงานซ้ำ. | ||
|
เหตุผลที่สำคัญ
เป็นผลลัพธ์ที่ไม่พึงประสงค์และเป็นสาเหตุสำคัญของงานแก้ไขซ้ำกับระยะเวลากระบวนการที่เพิ่มขึ้น การติดตามการปฏิเสธช่วยให้พบปัญหาคุณภาพใบแจ้งหนี้หรือการปฏิบัติตามข้อกำหนดของ PO.
แหล่งข้อมูล
อนุมานได้จากการเปลี่ยน APPROVAL_STATUS ในตาราง AP_INVOICES_ALL เป็น 'Rejected' ประวัติเวิร์กโฟลว์จะระบุว่าใครเป็นผู้ปฏิเสธและปฏิเสธเมื่อใด.
บันทึก
อนุมานจากการเปลี่ยน AP_INVOICES_ALL.APPROVAL_STATUS เป็น 'Rejected'.
ประเภทเหตุการณ์
inferred
|
|||
|
พบข้อมูลจับคู่ไม่ตรงกัน
|
เกิดขึ้นเมื่อระบบหรือผู้ใช้พบข้อมูลใบแจ้งหนี้ ใบสั่งซื้อ และใบรับสินค้าไม่ตรงกัน เช่น ราคา或จำนวน ซึ่งมักทำให้ระบบระงับใบแจ้งหนี้ไว้. | ||
|
เหตุผลที่สำคัญ
แสดงกรณียกเว้นในกระบวนการที่ต้องดำเนินการด้วยมือ การติดตามเหตุการณ์เหล่านี้จำเป็นต่อ KPI 'อัตราข้อมูลจับคู่ใบแจ้งหนี้ไม่ตรงกัน' และการวิเคราะห์หาสาเหตุ.
แหล่งข้อมูล
โดยทั่วไป ระบบจะบันทึกการระงับใบแจ้งหนี้เป็นประเภทเฉพาะ ตรวจสอบตาราง AP_HOLDS_ALL เพื่อหาประเภทการระงับที่เกี่ยวกับการจับคู่ เช่น 'QTY REC' หรือ 'PRICE' โดย HOLD_DATE จะระบุเวลาที่เกิดเหตุการณ์.
บันทึก
สร้างระเบียนใน AP_HOLDS_ALL โดยมีประเภทการระงับที่เกี่ยวข้องกับการจับคู่.
ประเภทเหตุการณ์
explicit
|
|||
|
ยกเลิกการระงับใบแจ้งหนี้แล้ว
|
เหตุการณ์นี้หมายถึงการแก้ไขการระงับที่เคยเกิดขึ้นกับใบแจ้งหนี้ ผู้ใช้หรือกระบวนการอัตโนมัติดำเนินการยกเลิกการระงับ เพื่อให้ใบแจ้งหนี้ดำเนินต่อในวงจรได้. | ||
|
เหตุผลที่สำคัญ
ระยะเวลาตั้งแต่ระงับจนถึงยกเลิกการระงับเป็นตัวชี้วัดสำคัญของประสิทธิภาพการจัดการกรณียกเว้น และใช้ประกอบ KPI 'เวลาเฉลี่ยในการแก้ไขกรณียกเว้น'.
แหล่งข้อมูล
บันทึกไว้ในตาราง AP_HOLDS_ALL เมื่อยกเลิกการระงับ ระบบจะกรอกฟิลด์ RELEASE_LOOKUP_CODE และ RELEASE_REASON พร้อมกับ LAST_UPDATE_DATE.
บันทึก
อัปเดตระเบียนในตาราง AP_HOLDS_ALL เพื่อระบุว่ายกเลิกการระงับแล้ว.
ประเภทเหตุการณ์
explicit
|
|||
|
ยกเลิกใบแจ้งหนี้แล้ว
|
ใบแจ้งหนี้ถูกยกเลิกหรือทำให้เป็นโมฆะ จึงไม่มีการดำเนินการต่อหรือชำระเงิน นับเป็นสถานะสิ้นสุดของกระบวนการ. | ||
|
เหตุผลที่สำคัญ
เป็นจุดสิ้นสุดสำคัญสำหรับใบแจ้งหนี้ที่ไม่มีการชำระเงิน การวิเคราะห์การยกเลิกช่วยให้พบปัญหาใบแจ้งหนี้ซ้ำหรือข้อมูลที่ผู้ขายส่งมาไม่ถูกต้อง.
แหล่งข้อมูล
อนุมานได้จากการเปลี่ยนสถานะใน AP_INVOICES_ALL โดยคอลัมน์ CANCELLED_DATE จะระบุเวลาที่ยกเลิก.
บันทึก
มีการกรอกฟิลด์ CANCELLED_DATE ในตาราง AP_INVOICES_ALL.
ประเภทเหตุการณ์
explicit
|
|||
|
ระงับใบแจ้งหนี้แล้ว
|
กิจกรรมทั่วไปที่หมายถึงการระงับใบแจ้งหนี้ไม่ว่าด้วยเหตุผลใด ซึ่งทำให้ใบแจ้งหนี้ดำเนินการต่อไปจนถึงการชำระเงินไม่ได้ สาเหตุอาจเป็นปัญหาการจับคู่ เงินไม่เพียงพอ หรือการดำเนินการด้วยมือ. | ||
|
เหตุผลที่สำคัญ
ส่งผลโดยตรงต่อระยะเวลาของกระบวนการและอาจทำให้ชำระเงินล่าช้า การวิเคราะห์การระงับเป็นกุญแจสำคัญในการระบุและแก้ไขปัญหาเชิงระบบของกระบวนการ และช่วยวิเคราะห์ 'แนวโน้มการระงับการชำระเงิน'.
แหล่งข้อมูล
บันทึกไว้อย่างชัดเจนในตาราง AP_HOLDS_ALL โดยแต่ละแถวแทนการระงับหนึ่งรายการ พร้อมวันที่สร้าง (HOLD_DATE) และเหตุผล.
บันทึก
สร้างระเบียนในตาราง AP_HOLDS_ALL.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้างรายการชำระเงินแล้ว
|
ระบบสร้างคำสั่งชำระเงินสำหรับใบแจ้งหนี้แล้ว เช่น สร้างเช็ค ไฟล์โอนเงินทางอิเล็กทรอนิกส์ (EFT) หรือเอกสารการชำระเงินรูปแบบอื่น. | ||
|
เหตุผลที่สำคัญ
เป็นจุดที่องค์กรจัดสรรเงินไว้สำหรับการชำระเงิน และเป็นหมุดหมายสำคัญก่อนที่เงินจะออกจากบัญชีธนาคาร.
แหล่งข้อมูล
บันทึกไว้ในตาราง AP_CHECKS_ALL ซึ่งเก็บข้อมูลการชำระเงินทั้งหมด โดย CHECK_DATE ระบุวันที่สร้างเอกสารการชำระเงิน.
บันทึก
สร้างระเบียนในตาราง AP_CHECKS_ALL.
ประเภทเหตุการณ์
explicit
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
เริ่มปรับปรุงการประมวลผลใบแจ้งหนี้ โดยเตรียมข้อมูลด้วยเทมเพลตนี้ ค้นพบข้อมูลเชิงลึกที่เป็นประโยชน์และปรับปรุงประสิทธิภาพการทำงานขององค์กรได้อย่างชัดเจน.
ปรับปรุงการประมวลผลใบแจ้งหนี้ P2P ให้รอบการทำงานเร็วขึ้น 30%
ลดคอขวดใน Oracle Fusion Financials และลดระยะเวลารอบการทำงานได้ 30%.
ไม่ต้องใช้บัตรเครดิต เห็นผลได้ภายในไม่กี่วัน.