เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงชำระเงิน: การประมวลผลใบแจ้งหนี้
เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงชำระเงิน: การประมวลผลใบแจ้งหนี้
- แอตทริบิวต์แนะนำสำหรับการวิเคราะห์เชิงลึก
- กิจกรรมสำคัญที่ควรติดตามตลอดวงจรการประมวลผลใบแจ้งหนี้
- แนวทางดึงข้อมูลจาก Microsoft Dynamics 365
แอตทริบิวต์สำหรับกระบวนการจัดซื้อจนถึงชำระเงิน: การประมวลผลใบแจ้งหนี้
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
ชื่อกิจกรรม
ActivityName
|
ชื่อเหตุการณ์ทางธุรกิจหรืองานที่เกิดขึ้น ณ เวลาหนึ่งในกระบวนการจัดการใบแจ้งหนี้. | ||
|
คำอธิบาย
ชื่อกิจกรรมอธิบายขั้นตอนหรือการเปลี่ยนสถานะในกระบวนการจัดการใบแจ้งหนี้ เช่น 'ลงทะเบียนใบแจ้งหนี้แล้ว' 'ส่งใบแจ้งหนี้เพื่อขออนุมัติ' หรือ 'ดำเนินการชำระเงินแล้ว' ข้อมูลนี้จำเป็นต่อการสร้างแผนผังกระบวนการและทำความเข้าใจลำดับเหตุการณ์. การวิเคราะห์คุณลักษณะนี้ช่วยให้เห็นลำดับการทำงาน ระบุเส้นทางที่พบบ่อย และค้นหาความเบี่ยงเบนหรือคอขวด นอกจากนี้ยังใช้คำนวณระยะเวลาระหว่างกิจกรรม เช่น เวลาตั้งแต่อนุมัติจนถึงลงบัญชี และวัดความถี่ของเหตุการณ์เฉพาะ เช่น การปฏิเสธหรือการบล็อกการชำระเงิน.
เหตุผลที่สำคัญ
ใช้กำหนดขั้นตอนในแผนผังกระบวนการ ทำให้เห็นภาพลำดับการทำงานและวิเคราะห์การเปลี่ยนผ่านระหว่างกิจกรรมต่างๆ ได้.
แหล่งข้อมูล
โดยทั่วไปได้คุณลักษณะนี้จากการรวมข้อมูลฟิลด์สถานะ ประเภทธุรกรรม หรือรายการในบันทึกการเปลี่ยนแปลงจากตาราง Dynamics 365 หลายตารางที่เกี่ยวข้องกับการจัดการใบแจ้งหนี้.
ตัวอย่าง
ส่งใบแจ้งหนี้เพื่อขออนุมัติแล้วพบข้อมูลไม่ตรงกันในการจับคู่ดำเนินการชำระเงินแล้ว
|
|||
|
เวลาที่เกิดเหตุการณ์
EventTime
|
เวลาที่ระบุอย่างแม่นยำว่าเกิดกิจกรรมหรือเหตุการณ์ใดขึ้น. | ||
|
คำอธิบาย
เวลาที่เกิดเหตุการณ์หรือการประทับเวลาใช้บันทึกวันที่และเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ เป็นส่วนสำคัญของบันทึกเหตุการณ์ เพราะให้ข้อมูลลำดับเวลาที่จำเป็นต่อการเรียงกิจกรรมและคำนวณระยะเวลา. ในการวิเคราะห์ การประทับเวลานี้เป็นพื้นฐานของตัวชี้วัดด้านเวลาทั้งหมด ใช้คำนวณระยะเวลาของกิจกรรม ระยะเวลารอบงานระหว่างขั้นตอนต่างๆ เช่น เวลาที่ใช้อนุมัติ และเวลาจัดการใบแจ้งหนี้ตั้งแต่ต้นจนจบ นอกจากนี้ยังใช้วิเคราะห์แนวโน้มตามช่วงเวลาได้.
เหตุผลที่สำคัญ
การประทับเวลานี้จำเป็นต่อการเรียงลำดับเหตุการณ์ คำนวณระยะเวลารอบงานและระยะเวลาต่างๆ รวมถึงระบุคอขวดในกระบวนการ.
แหล่งข้อมูล
ข้อมูลนี้มาจากฟิลด์วันที่และเวลาหลายรายการในหลายตาราง เช่น ฟิลด์ createdDateTime หรือ modifiedDateTime ใน VendInvoiceInfoTable, VendTrans หรือตารางประวัติเวิร์กโฟลว์.
ตัวอย่าง
2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
|
|||
|
หมายเลขใบแจ้งหนี้
InvoiceNumber
|
รหัสเฉพาะของใบแจ้งหนี้ผู้ขายแต่ละรายการ ใช้เป็นรหัสเคสหลักสำหรับติดตามวงจรการดำเนินงาน. | ||
|
คำอธิบาย
หมายเลขใบแจ้งหนี้เป็นคีย์เฉพาะที่เชื่อมโยงกิจกรรมทั้งหมดของใบแจ้งหนี้ผู้ขายแต่ละรายการ ช่วยติดตามใบแจ้งหนี้ตั้งแต่ต้นจนจบ ตั้งแต่รับและลงทะเบียน ไปจนถึงจับคู่ อนุมัติ และชำระเงิน. คุณลักษณะนี้เป็นพื้นฐานสำคัญของการวิเคราะห์ process mining เพราะใช้ระบุเคสและสร้างลำดับกระบวนการของใบแจ้งหนี้แต่ละรายการขึ้นใหม่ ทำให้คำนวณระยะเวลารอบงานทั้งหมด ระบุรูปแบบกระบวนการที่แตกต่างกัน และวิเคราะห์ลักษณะกับผลลัพธ์ของใบแจ้งหนี้แต่ละรายการได้.
เหตุผลที่สำคัญ
นี่คือรหัสเคสสำคัญที่เชื่อมโยงเหตุการณ์ทั้งหมดเข้าด้วยกัน ทำให้วิเคราะห์วงจรการดำเนินงานของใบแจ้งหนี้แต่ละรายการได้ครบถ้วน.
แหล่งข้อมูล
โดยทั่วไปพบในตารางใบแจ้งหนี้ผู้ขายหลัก เช่น ฟิลด์ Num ใน VendInvoiceInfoTable.
ตัวอย่าง
INV-10056773245-AUS-001-98432
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบหลักที่ใช้บันทึกข้อมูล ซึ่งเป็นแหล่งที่ดึงข้อมูลเหตุการณ์มา. | ||
|
คำอธิบาย
คุณลักษณะนี้ระบุแอปพลิเคชันต้นทางของข้อมูลกิจกรรม สำหรับกระบวนการนี้ โดยทั่วไปคือ 'Microsoft Dynamics 365'. หากมีหลายระบบ เช่น โซลูชัน OCR หรือระบบบันทึกข้อมูลภายนอก ฟิลด์นี้ช่วยแยกได้ว่าแต่ละขั้นตอนเกิดขึ้นในระบบใด ทำให้ตรวจสอบที่มาของข้อมูลได้ชัดเจนและช่วยแก้ปัญหาการดึงข้อมูล.
เหตุผลที่สำคัญ
ช่วยให้เข้าใจที่มาของข้อมูล ซึ่งสำคัญต่อการตรวจสอบความถูกต้องของข้อมูลและทำความเข้าใจระบบที่เกี่ยวข้องกับกระบวนการ.
แหล่งข้อมูล
เป็นค่าคงที่ 'Microsoft Dynamics 365' ซึ่งเพิ่มระหว่างการแปลงข้อมูลเพื่อระบุแหล่งที่มาของชุดข้อมูล.
ตัวอย่าง
Microsoft Dynamics 365
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่รีเฟรชข้อมูลของกระบวนการนี้จากระบบต้นทางครั้งล่าสุด. | ||
|
คำอธิบาย
คุณลักษณะนี้บันทึกเวลาที่ดึงและอัปเดตชุดข้อมูลจาก Microsoft Dynamics 365 ครั้งล่าสุด โดยทั่วไปค่าจะเหมือนกันในทุกรายการของการโหลดข้อมูลครั้งเดียว. ข้อมูลนี้ช่วยให้ผู้ใช้ทราบว่าข้อมูลที่กำลังวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด และใช้ประกอบการทำความเข้าใจว่าข้อมูลเชิงลึกเกี่ยวกับกระบวนการเป็นปัจจุบันแค่ไหน นอกจากนี้ยังจำเป็นต่อการจัดการกำหนดการรีเฟรชข้อมูลและตรวจสอบไปป์ไลน์ข้อมูล.
เหตุผลที่สำคัญ
แจ้งให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด เพื่อให้รู้ว่าการวิเคราะห์อ้างอิงข้อมูลล่าสุดเมื่อใด และคาดว่าจะอัปเดตข้อมูลครั้งต่อไปเมื่อใด.
แหล่งข้อมูล
กระบวนการดึงข้อมูลหรือ ETL จะสร้างและประทับเวลานี้ลงในชุดข้อมูลเมื่อเริ่มทำงาน.
ตัวอย่าง
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
ผู้ใช้
User
|
รหัสหรือชื่อผู้ใช้ของผู้ที่ทำกิจกรรม. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุพนักงานหรือผู้ใช้ระบบที่รับผิดชอบขั้นตอนหนึ่งของกระบวนการ สำหรับขั้นตอนอัตโนมัติ อาจเป็นบัญชีระบบหรือบัญชีบริการ การวิเคราะห์กระบวนการแยกตามผู้ใช้ช่วยให้เข้าใจการกระจายงาน ระบุความต้องการในการฝึกอบรม และเปรียบเทียบผลการดำเนินงานระหว่างบุคคลหรือทีม ข้อมูลนี้ยังจำเป็นต่อการวิเคราะห์งานที่ต้องแก้ไขซ้ำ ซึ่งอาจมีการส่งงานกลับไปมาระหว่างผู้ใช้ และช่วยให้เข้าใจว่าผู้ใช้แต่ละรายทำงานเดียวกันแตกต่างกันอย่างไร.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ผลการดำเนินงานและปริมาณงานแยกตามผู้ใช้หรือทีม รวมถึงระบุระดับการทำงานอัตโนมัติและสาเหตุของการแก้ไขงานซ้ำ.
แหล่งข้อมูล
ดึงข้อมูลจากฟิลด์รหัสผู้ใช้ในตารางรายการธุรกรรมหรือประวัติเวิร์กโฟลว์ เช่นฟิลด์ createdby หรือ modifiedby ข้อมูลนี้อาจอยู่ในตารางติดตามเวิร์กโฟลว์.
ตัวอย่าง
j.doea.smithAX_Admin
|
|||
|
ยอดเงินในใบแจ้งหนี้
InvoiceAmount
|
มูลค่ารวมของใบแจ้งหนี้. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงยอดเงินรวมที่ต้องชำระตามใบแจ้งหนี้จากผู้ขาย และเป็นข้อมูลทางการเงินพื้นฐานของแต่ละเคส ยอดเงินในใบแจ้งหนี้ใช้แบ่งกลุ่มและวิเคราะห์ข้อมูลได้หลายรูปแบบ เช่น ตรวจสอบว่าใบแจ้งหนี้มูลค่าสูงต้องผ่านขั้นตอนอนุมัติที่เข้มงวดกว่าหรือใช้เวลานานกว่าหรือไม่ นอกจากนี้ยังใช้ในแดชบอร์ดเพื่อวิเคราะห์จำนวนใบแจ้งหนี้ตามมูลค่า และรวมยอดเพื่อดูค่าใช้จ่ายทั้งหมดในข้อมูลที่กำลังวิเคราะห์.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ตามมูลค่าทางการเงิน จัดลำดับความสำคัญของการปรับปรุงกระบวนการสำหรับใบแจ้งหนี้มูลค่าสูง และทำความเข้าใจปัจจัยที่ทำให้เกิดค่าใช้จ่าย.
แหล่งข้อมูล
อยู่ในตารางส่วนหัวของใบแจ้งหนี้ เช่น VendInvoiceInfoTable ในฟิลด์อย่าง InvoiceAmount หรือ Amount.
ตัวอย่าง
1500.00250.7512500.50
|
|||
|
วันครบกำหนดชำระเงิน
PaymentDueDate
|
วันที่ต้องชำระใบแจ้งหนี้ตามเงื่อนไขการชำระเงินที่ตกลงกันไว้. | ||
|
คำอธิบาย
วันครบกำหนดชำระเงินคำนวณจากวันที่ในใบแจ้งหนี้และเงื่อนไขการชำระเงินของผู้ขาย โดยเป็นกำหนดเวลาชำระเงินตามสัญญา วันที่นี้สำคัญต่อการวัดผลทางการเงินและการบริหารความสัมพันธ์กับผู้ขาย ใช้เป็นเกณฑ์คำนวณ KPI “อัตราการชำระเงินตรงเวลา” โดยเปรียบเทียบกับวันที่ “ดำเนินการชำระเงิน” จริง การวิเคราะห์ข้อมูลนี้ช่วยระบุปัญหาเชิงระบบที่ทำให้ชำระเงินล่าช้า ซึ่งอาจกระทบความสัมพันธ์กับผู้ขายหรือทำให้พลาดส่วนลดเมื่อชำระก่อนกำหนด.
เหตุผลที่สำคัญ
ใช้เป็นเกณฑ์วัดการชำระเงินตรงเวลา ซึ่งเป็น KPI สำคัญที่สะท้อนสถานะทางการเงินและความสัมพันธ์กับผู้ขาย.
แหล่งข้อมูล
ระบบมักคำนวณวันที่นี้และบันทึกไว้ในตารางธุรกรรมผู้ขาย เช่น VendTrans โดยอ้างอิงวันที่ในใบแจ้งหนี้และเงื่อนไขการชำระเงิน.
ตัวอย่าง
2023-05-152023-06-302023-07-20
|
|||
|
เวลาสิ้นสุด
EndTime
|
เวลาประทับที่ระบุอย่างแม่นยำว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด. | ||
|
คำอธิบาย
เวลาสิ้นสุดบันทึกเวลาที่กิจกรรมเสร็จสิ้น เมื่อนำไปใช้ร่วมกับเวลาเริ่มต้น (EventTime) จะคำนวณระยะเวลาที่ใช้ในแต่ละขั้นตอนได้อย่างแม่นยำ แอตทริบิวต์นี้จำเป็นต่อการคำนวณ “ProcessingTime” ของแต่ละกิจกรรม ซึ่งเป็นตัวชี้วัดสำคัญในการวิเคราะห์ผลการดำเนินงาน ช่วยระบุได้อย่างชัดเจนว่าขั้นตอนใดใช้เวลามากที่สุด เพื่อนำไปปรับปรุงได้ตรงจุด เช่น วัดระยะเวลาที่ใช้ลงรหัสหรืออนุมัติด้วยตนเอง.
เหตุผลที่สำคัญ
ใช้คำนวณเวลาประมวลผลของแต่ละกิจกรรมโดยตรง ซึ่งเป็นข้อมูลพื้นฐานในการระบุขั้นตอนที่ใช้เวลามากที่สุด.
แหล่งข้อมูล
เช่นเดียวกับ StartTime ข้อมูลนี้มาจากฟิลด์วันที่และเวลาหลายแห่ง สำหรับบางกิจกรรมอาจใช้ StartTime ของกิจกรรมถัดไป ส่วนกรณีอื่นอาจใช้เวลาประทับ “เสร็จสิ้นเมื่อ” โดยเฉพาะ.
ตัวอย่าง
2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
|
|||
|
สถานะใบแจ้งหนี้
InvoiceStatus
|
สถานะปัจจุบันของใบแจ้งหนี้ ณ เวลาที่ดึงข้อมูล. | ||
|
คำอธิบาย
สถานะใบแจ้งหนี้แสดงขั้นตอนปัจจุบันของใบแจ้งหนี้ในวงจรการทำงาน เช่น “รออนุมัติ” “อนุมัติแล้ว” “บันทึกรายการแล้ว” หรือ “ชำระแล้ว” จึงช่วยให้เห็นความคืบหน้าของใบแจ้งหนี้ ณ เวลานั้น แอตทริบิวต์นี้ใช้เป็นหลักในการสร้างแดชบอร์ดสำหรับการปฏิบัติการ เพื่อแสดงปริมาณงานปัจจุบันและงานค้าง ช่วยให้ผู้จัดการเห็นจำนวนใบแจ้งหนี้ในแต่ละขั้นตอน และจัดสรรทรัพยากรพร้อมติดตามการปฏิบัติการได้ แอตทริบิวต์นี้เป็นข้อมูลสำคัญของแดชบอร์ด “ปริมาณงานและสถานะการประมวลผลใบแจ้งหนี้”.
เหตุผลที่สำคัญ
แสดงสถานะปัจจุบันของใบแจ้งหนี้ทั้งหมด ซึ่งจำเป็นต่อการติดตามการปฏิบัติการ การจัดการปริมาณงาน และการระบุคอขวดที่เกิดขึ้น.
แหล่งข้อมูล
โดยทั่วไปได้จากฟิลด์สถานะในตารางใบแจ้งหนี้หลัก เช่น VendInvoiceInfoTable.
ตัวอย่าง
รออนุมัติบันทึกรายการแล้วชำระแล้ว
|
|||
|
หมายเลขใบสั่งซื้อ
PurchaseOrderNumber
|
รหัสใบสั่งซื้อ (PO) ที่เกี่ยวข้องกับใบแจ้งหนี้. | ||
|
คำอธิบาย
หมายเลขใบสั่งซื้อใช้เชื่อมใบแจ้งหนี้กับเอกสารจัดซื้อฉบับต้นทาง ซึ่งสำคัญต่อกระบวนการตรวจสอบแบบ 2 ทางหรือ 3 ทางระหว่างใบแจ้งหนี้ PO และใบรับสินค้า แอตทริบิวต์นี้ช่วยวิเคราะห์ใบแจ้งหนี้ที่มี PO เทียบกับใบแจ้งหนี้ที่ไม่มี PO ซึ่งมักมีเส้นทางกระบวนการต่างกัน และช่วยประเมินประสิทธิภาพของการตรวจสอบข้อมูล วิเคราะห์สาเหตุที่ข้อมูลไม่ตรงกัน และวัดสัดส่วนการประมวลผลใบแจ้งหนี้ที่มี PO โดยไม่ต้องทำงานด้วยตนเอง.
เหตุผลที่สำคัญ
ใช้แยกใบแจ้งหนี้ที่มี PO ออกจากใบแจ้งหนี้ที่ไม่มี PO ซึ่งเป็นปัจจัยหลักที่ทำให้กระบวนการแตกต่างกัน และจำเป็นต่อการวิเคราะห์การตรวจสอบข้อมูล.
แหล่งข้อมูล
อยู่ในตารางส่วนหัวของใบแจ้งหนี้ เช่น VendInvoiceInfoTable โดยมักอยู่ในฟิลด์อย่าง PurchId.
ตัวอย่าง
PO-001234PO-005678PO-009101
|
|||
|
หมายเลขผู้ขาย
VendorNumber
|
รหัสเฉพาะของผู้ขายหรือซัพพลายเออร์ที่ส่งใบแจ้งหนี้. | ||
|
คำอธิบาย
หมายเลขผู้ขายเป็นรหัสที่ใช้ระบุซัพพลายเออร์แต่ละรายในข้อมูลหลักโดยไม่ซ้ำกัน รหัสนี้เชื่อมรายการใบแจ้งหนี้กับผู้ขายรายนั้น จึงวิเคราะห์กระบวนการแยกตามผู้ขายได้ แอตทริบิวต์นี้จำเป็นสำหรับแบ่งข้อมูลกระบวนการตามผู้ขาย และช่วยตอบคำถาม เช่น “ผู้ขายรายใดใช้เวลาอนุมัตินานที่สุด” หรือ “ผู้ขายบางรายมีปัญหาข้อมูลไม่ตรงกันบ่อยกว่าหรือไม่” การวิเคราะห์ผลการดำเนินงานแยกตามผู้ขายช่วยให้เห็นโอกาสในการทำงานร่วมกับซัพพลายเออร์และปรับปรุงกระบวนการ.
เหตุผลที่สำคัญ
ใช้กรองข้อมูลและวิเคราะห์หาสาเหตุที่แท้จริงแยกตามผู้ขาย เพื่อระบุปัญหาด้านผลการดำเนินงานหรือรูปแบบที่เกี่ยวข้องกับซัพพลายเออร์แต่ละราย.
แหล่งข้อมูล
โดยทั่วไปจะอยู่ในส่วนหัวของตารางใบแจ้งหนี้ผู้ขาย เช่น VendInvoiceInfoTable ซึ่งเชื่อมกับข้อมูลหลักของผู้ขายใน VendTable.
ตัวอย่าง
V-1001V-2050V-8342
|
|||
|
เงื่อนไขการชำระเงิน
PaymentTerms
|
ข้อตกลงการชำระเงินกับผู้ขาย เช่น “Net 30” หรือ “2% 10, Net 30”. | ||
|
คำอธิบาย
เงื่อนไขการชำระเงินกำหนดข้อตกลงที่ใช้ชำระเงินให้ผู้ขาย รวมถึงกรอบเวลาและส่วนลดที่อาจได้รับ โดยปกติข้อมูลนี้มาจากข้อมูลหลักของผู้ขายหรือใบสั่งซื้อ แอตทริบิวต์นี้ให้ข้อมูลประกอบที่สำคัญสำหรับวันครบกำหนดชำระเงินและ KPI อัตราการชำระเงินตรงเวลา การวิเคราะห์ว่าเงื่อนไขการชำระเงินบางแบบสัมพันธ์กับการชำระล่าช้าหรือไม่ ช่วยให้เห็นปัญหาในการปฏิบัติการ นอกจากนี้ยังช่วยวางแผนการเงินและบริหารเงินทุนหมุนเวียนได้อย่างมีประสิทธิภาพ.
เหตุผลที่สำคัญ
ให้ข้อมูลประกอบสำหรับวันครบกำหนดชำระเงิน และช่วยวิเคราะห์ผลกระทบทางการเงินจากช่วงเวลาชำระเงินและอัตราการใช้ส่วนลด.
แหล่งข้อมูล
ข้อมูลนี้จัดเก็บในข้อมูลหลักของผู้ขาย (VendTable) และคัดลอกไปยังตารางธุรกรรม เช่น VendInvoiceInfoTable.
ตัวอย่าง
Net 30Net 602% 10, Net 30
|
|||
|
ชำระเงินตรงเวลาหรือไม่
IsOnTimePayment
|
ตัวบ่งชี้ที่คำนวณขึ้นเพื่อระบุว่าใบแจ้งหนี้ได้รับการชำระภายในหรือก่อนวันครบกำหนดหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์แบบบูลีนนี้คำนวณโดยเปรียบเทียบเวลาประทับของกิจกรรม “ดำเนินการชำระเงิน” กับ “วันครบกำหนดชำระเงิน” หากวันที่ชำระเงินตรงกับหรือก่อนวันครบกำหนด ค่าจะเป็น true มิฉะนั้นจะเป็น false แอตทริบิวต์นี้ใช้คำนวณ KPI “อัตราการชำระเงินตรงเวลา” และแสดงข้อมูลในแดชบอร์ด “การปฏิบัติตามเงื่อนไขการชำระเงิน” โดยระบุผลลัพธ์ของใบแจ้งหนี้แต่ละรายการอย่างชัดเจน จึงกรองรายการที่ชำระล่าช้าและวิเคราะห์สาเหตุแยกตามผู้ขาย แผนก หรือประเทศได้ง่ายขึ้น.
เหตุผลที่สำคัญ
วัดการปฏิบัติตามเงื่อนไขการชำระเงินโดยตรง ช่วยให้คำนวณ KPI อัตราการชำระเงินตรงเวลาและวิเคราะห์ข้อมูลที่เกี่ยวข้องได้ง่ายขึ้น.
แหล่งข้อมูล
คำนวณแอตทริบิวต์นี้ในชั้นแปลงข้อมูล โดยใช้ตรรกะดังนี้: (เวลาประทับของกิจกรรม “ดำเนินการชำระเงิน”) <= (วันครบกำหนดชำระเงิน).
ตัวอย่าง
truefalse
|
|||
|
ประเภทข้อมูลไม่ตรงกัน
MatchingDiscrepancyType
|
จัดประเภทข้อมูลที่ไม่ตรงกันซึ่งพบระหว่างตรวจสอบใบแจ้งหนี้กับ PO. | ||
|
คำอธิบาย
เมื่อพบข้อมูลไม่ตรงกันระหว่างการตรวจสอบแบบ 2 ทางหรือ 3 ทาง แอตทริบิวต์นี้จะระบุลักษณะของปัญหา เช่น “ราคาไม่ตรงกัน” “จำนวนไม่ตรงกัน” หรือ “ไม่มีใบรับสินค้า” ข้อมูลนี้เป็นหัวใจของแดชบอร์ด “ระยะเวลาแก้ไขข้อมูลไม่ตรงกันจากการตรวจสอบ” การวิเคราะห์ความถี่ของข้อมูลแต่ละประเภทช่วยให้ธุรกิจระบุสาเหตุที่ทำให้การตรวจสอบไม่ผ่านได้ เช่น หากราคาที่ไม่ตรงกันเกิดขึ้นบ่อย อาจเป็นเพราะข้อมูลหลักล้าสมัย ส่วนจำนวนที่ไม่ตรงกันอาจบ่งชี้ถึงปัญหาในการจัดส่ง.
เหตุผลที่สำคัญ
ใช้จัดประเภทกรณีตรวจสอบไม่ผ่าน เพื่อวิเคราะห์หาสาเหตุที่แท้จริง ลดอัตราข้อมูลไม่ตรงกัน และเพิ่มสัดส่วนการประมวลผลโดยไม่ต้องทำงานด้วยตนเอง.
แหล่งข้อมูล
ข้อมูลนี้อาจจัดเก็บในตารางบันทึกการตรวจสอบหรือข้อยกเว้นโดยเฉพาะ หรืออาจต้องอนุมานจากข้อความสถานะหรือความคิดเห็นในเวิร์กโฟลว์.
ตัวอย่าง
ราคาไม่ตรงกันจำนวนไม่ตรงกันไม่มีใบรับสินค้า
|
|||
|
เป็นการทำงานอัตโนมัติหรือไม่
IsAutomated
|
ตัวบ่งชี้ว่าระบบหรือผู้ใช้เป็นผู้ดำเนินกิจกรรมโดยอัตโนมัติหรือด้วยตนเอง. | ||
|
คำอธิบาย
แอตทริบิวต์แบบบูลีนนี้ (true/false) ใช้แยกเหตุการณ์ที่ระบบดำเนินการออกจากงานที่ผู้ใช้ทำด้วยตนเอง เช่น ระบบอาจตรวจสอบใบแจ้งหนี้กับ PO โดยอัตโนมัติ แต่ต้องให้ผู้ใช้จัดการเมื่อพบข้อมูลไม่ตรงกัน การวิเคราะห์แอตทริบิวต์นี้ช่วยให้เข้าใจระดับการทำงานอัตโนมัติของกระบวนการ วัดผลความสำเร็จของโครงการระบบอัตโนมัติ ระบุคอขวดที่ยังต้องจัดการด้วยตนเอง และหาโอกาสเพิ่มระบบอัตโนมัติเพื่อให้ทำงานได้มีประสิทธิภาพขึ้นและลดข้อผิดพลาด.
เหตุผลที่สำคัญ
ช่วยวัดระดับการทำงานอัตโนมัติของกระบวนการ ระบุคอขวดที่ต้องจัดการด้วยตนเอง และหาโอกาสเพิ่มประสิทธิภาพ.
แหล่งข้อมูล
โดยทั่วไปอนุมานจากแอตทริบิวต์ “ผู้ใช้” หากเป็นบัญชีระบบหรือบัญชีบริการที่รู้จัก ค่าของตัวบ่งชี้นี้จะเป็น true.
ตัวอย่าง
truefalse
|
|||
|
แผนก
Department
|
ศูนย์ต้นทุนหรือแผนกที่จัดสรรค่าใช้จ่ายในใบแจ้งหนี้. | ||
|
คำอธิบาย
แผนกระบุหน่วยธุรกิจหรือศูนย์ต้นทุนที่รับผิดชอบค่าใช้จ่ายในใบแจ้งหนี้ โดยปกติจะกำหนดระหว่างกิจกรรมลงรหัสใบแจ้งหนี้ การวิเคราะห์กระบวนการแยกตามแผนกช่วยให้เข้าใจความแตกต่างด้านการใช้จ่าย ระยะเวลาอนุมัติ และการปฏิบัติตามข้อกำหนดของแต่ละแผนก อีกทั้งช่วยระบุว่าแผนกใดมีกรณียกเว้นในใบแจ้งหนี้มากที่สุดหรือใช้เวลาอนุมัตินานที่สุด เพื่อนำไปวางแผนสื่อสารและฝึกอบรมได้ตรงจุด.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ต้นทุนและกระบวนการแยกตามแผนก พร้อมแสดงความแตกต่างด้านผลการดำเนินงานและการปฏิบัติตามข้อกำหนดทั่วทั้งองค์กร.
แหล่งข้อมูล
ดึงข้อมูลจากมิติทางการเงินที่เชื่อมกับรายการหรือส่วนหัวของใบแจ้งหนี้ โดยต้องค้นจากโครงสร้างข้อมูลที่เกี่ยวข้องกับมิติ.
ตัวอย่าง
ฝ่ายขายการตลาดฝ่ายปฏิบัติการด้าน IT
|
|||
|
รหัสบริษัท
CompanyCode
|
รหัสนิติบุคคลหรือบริษัทในองค์กรที่ดำเนินการกับใบแจ้งหนี้. | ||
|
คำอธิบาย
รหัสบริษัทระบุนิติบุคคลที่รับผิดชอบด้านการเงินสำหรับใบแจ้งหนี้ ในองค์กรที่มีหลายบริษัท ข้อมูลนี้สำคัญต่อการแบ่งกลุ่มข้อมูลทางการเงิน แอตทริบิวต์นี้ช่วยกรองหรือเปรียบเทียบการวิเคราะห์กระบวนการระหว่างนิติบุคคลต่างๆ และช่วยให้เห็นว่าผลการดำเนินงาน นโยบาย หรือคอขวดของกระบวนการเกิดขึ้นเฉพาะในบริษัทใดบริษัทหนึ่งหรือไม่ เพื่อนำไปปรับปรุงกระบวนการให้เหมาะกับแต่ละบริษัท.
เหตุผลที่สำคัญ
ช่วยแบ่งการวิเคราะห์กระบวนการตามนิติบุคคล ซึ่งจำเป็นสำหรับองค์กรขนาดใหญ่ที่มีหลายบริษัท.
แหล่งข้อมูล
เป็นฟิลด์มาตรฐานในตารางการเงินส่วนใหญ่ของ Dynamics 365 โดยมักใช้ชื่อ DataAreaId.
ตัวอย่าง
USMFDEMFGBSI
|
|||
|
ระยะเวลารวมของกระบวนการ
TotalCycleTime
|
ระยะเวลารวมตั้งแต่รับใบแจ้งหนี้จนถึงชำระเงิน. | ||
|
คำอธิบาย
ระยะเวลารวมของกระบวนการใช้วัดเวลาทั้งหมดที่ใบแจ้งหนี้อยู่ในกระบวนการ โดยคำนวณจากเวลาระหว่างกิจกรรมแรกสุด เช่น “ลงทะเบียนใบแจ้งหนี้” กับกิจกรรมสุดท้าย เช่น “ดำเนินการชำระเงิน” ของหมายเลขใบแจ้งหนี้นั้น ตัวชี้วัดนี้เป็น KPI หลักสำหรับวัดประสิทธิภาพโดยรวมของกระบวนการ ช่วยให้เห็นภาพรวมผลการดำเนินงานและใช้ในแดชบอร์ด “ระยะเวลาตั้งแต่ต้นจนจบของใบแจ้งหนี้” การวิเคราะห์แนวโน้มและแบ่งข้อมูลตามแอตทริบิวต์ เช่น ผู้ขายหรือยอดเงิน ช่วยให้เห็นโอกาสในการปรับปรุงภาพรวม.
เหตุผลที่สำคัญ
เป็น KPI หลักที่ใช้วัดความเร็วและประสิทธิภาพโดยรวมของกระบวนการ พร้อมสรุปผลการดำเนินงานของใบแจ้งหนี้แต่ละรายการ.
แหล่งข้อมูล
คำนวณในระดับเคสภายในเครื่องมือ process mining หรือระหว่างเตรียมข้อมูล โดยหาผลต่างระหว่างเวลาประทับของเหตุการณ์แรกและเหตุการณ์สุดท้ายสำหรับ CaseId แต่ละรายการ.
ตัวอย่าง
P15DP22DT5H30MP7D
|
|||
|
สกุลเงินของใบแจ้งหนี้
InvoiceCurrency
|
รหัสสกุลเงินของยอดเงินในใบแจ้งหนี้ เช่น USD หรือ EUR. | ||
|
คำอธิบาย
สกุลเงินในใบแจ้งหนี้ระบุสกุลเงินที่ใช้แสดงยอดเงิน ซึ่งสำคัญสำหรับองค์กรข้ามชาติที่ทำธุรกิจกับซัพพลายเออร์ในหลายประเทศ แอตทริบิวต์นี้ให้ข้อมูลประกอบที่จำเป็นสำหรับยอดเงินในใบแจ้งหนี้ และใช้กรองข้อมูลและจัดทำรายงาน โดยเฉพาะในการปฏิบัติการระดับโลก ช่วยให้ตีความมูลค่าทางการเงินได้ถูกต้อง และวิเคราะห์แยกตามสกุลเงินหรือแปลงเป็นสกุลเงินมาตรฐานสำหรับรายงานได้.
เหตุผลที่สำคัญ
ให้ข้อมูลประกอบที่จำเป็นสำหรับยอดเงิน ช่วยให้ตีความและวิเคราะห์มูลค่าใบแจ้งหนี้จากแต่ละภูมิภาคได้อย่างถูกต้อง.
แหล่งข้อมูล
อยู่ในตารางส่วนหัวของใบแจ้งหนี้ ใกล้กับยอดเงิน เช่น ฟิลด์ CurrencyCode ใน VendInvoiceInfoTable.
ตัวอย่าง
USDEURGBP
|
|||
|
เหตุผลที่ปฏิเสธ
RejectionReason
|
เหตุผลที่ผู้อนุมัติระบุเมื่อปฏิเสธใบแจ้งหนี้. | ||
|
คำอธิบาย
เมื่อใบแจ้งหนี้ถูกปฏิเสธระหว่างเวิร์กโฟลว์อนุมัติ ผู้อนุมัติมักระบุเหตุผลไว้ แอตทริบิวต์นี้เก็บคำอธิบายดังกล่าว ซึ่งอาจเป็นรหัสที่กำหนดไว้หรือข้อความที่ผู้ใช้เขียนเอง ข้อมูลนี้สำคัญต่อแดชบอร์ด “วิเคราะห์การปฏิเสธใบแจ้งหนี้” เพราะช่วยให้เข้าใจสาเหตุของการปฏิเสธ เช่น “หมายเลข PO ไม่ถูกต้อง” “ใบแจ้งหนี้ซ้ำ” หรือ “ราคาไม่ตรงกัน” การวิเคราะห์เหตุผลเหล่านี้ช่วยจัดลำดับความสำคัญของการดำเนินการเพื่อลดอัตราการปฏิเสธ.
เหตุผลที่สำคัญ
ช่วยให้เห็นสาเหตุโดยตรงที่ใบแจ้งหนี้ถูกปฏิเสธ และดำเนินการแก้ไขได้ตรงจุดเพื่อลดงานแก้ซ้ำและเพิ่มอัตราการทำงานถูกต้องตั้งแต่ครั้งแรก.
แหล่งข้อมูล
โดยทั่วไปจะอยู่ในความคิดเห็นหรือบันทึกประวัติของตารางประมวลผลเวิร์กโฟลว์.
ตัวอย่าง
จำนวนไม่ถูกต้องใบแจ้งหนี้ซ้ำเกินวงเงินอนุมัติ
|
|||
|
เหตุผลที่ระงับการชำระเงิน
PaymentBlockReason
|
รหัสเหตุผลที่อธิบายว่าทำไมจึงระงับการชำระเงินของใบแจ้งหนี้. | ||
|
คำอธิบาย
การระงับการชำระเงินทำให้ไม่สามารถชำระใบแจ้งหนี้ได้ แอตทริบิวต์นี้บันทึกเหตุผลที่ระงับ ซึ่งโดยทั่วไปเป็นรหัสมาตรฐานที่ผู้ใช้เลือก เช่น “โต้แย้งยอดเรียกเก็บ” หรือ “รอรับสินค้า” แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด “ความถี่และระยะเวลาการระงับการชำระเงิน” การวิเคราะห์เหตุผลที่พบบ่อยช่วยระบุปัญหาต้นทางในกระบวนการ P2P การแก้ไขสาเหตุเหล่านี้ช่วยลดความล่าช้าในการชำระเงินและปรับปรุงความสัมพันธ์กับผู้ขายได้อย่างมาก.
เหตุผลที่สำคัญ
อธิบายสาเหตุที่ตั้งใจชะลอการชำระเงิน ช่วยระบุและแก้ไขปัญหาต้นทางที่ทำให้ต้องระงับการชำระเงิน.
แหล่งข้อมูล
โดยทั่วไปเป็นฟิลด์ในรายการธุรกรรมผู้ขายหรือระเบียนใบแจ้งหนี้ ซึ่งมักเกี่ยวข้องกับสถานะการระงับการชำระเงิน ให้ตรวจสอบตารางอย่าง VendTrans.
ตัวอย่าง
ข้อโต้แย้งด้านคุณภาพรอใบลดหนี้ระงับด้วยตนเอง
|
|||
กิจกรรมในกระบวนการจัดซื้อจนถึงชำระเงิน: การประมวลผลใบแจ้งหนี้
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
จับคู่ใบแจ้งหนี้กับใบสั่งซื้อแล้ว
|
หมายถึงการจับคู่เสร็จสมบูรณ์ โดยรายละเอียดใบแจ้งหนี้ตรงกับข้อมูลใบสั่งซื้อและการรับสินค้า อนุมานเหตุการณ์นี้เมื่อสถานะการจับคู่ใบแจ้งหนี้เปลี่ยนเป็น 'ผ่าน'. | ||
|
เหตุผลที่สำคัญ
การจับคู่สำเร็จเป็นหมุดหมายสำคัญของใบแจ้งหนี้ที่อ้างอิงใบสั่งซื้อ เพราะยืนยันความถูกต้องของรายการก่อนชำระเงิน และจำเป็นต่อการติดตามประสิทธิภาพและอัตราการทำงานอัตโนมัติของการจับคู่.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์สถานะการจับคู่ในส่วนหัวหรือรายการใบแจ้งหนี้ผู้ขาย เช่น VendInvoiceInfoTable เป็นค่า 'ผ่าน' หรือ 'จับคู่สำเร็จ'.
บันทึก
เวลาที่สถานะเปลี่ยนเป็น 'ผ่าน' ในรายละเอียดการตรวจสอบการจับคู่ใบแจ้งหนี้.
ประเภทเหตุการณ์
inferred
|
|||
|
ดำเนินการชำระเงินแล้ว
|
เป็นกิจกรรมสุดท้าย หมายถึงการลงบัญชีสมุดรายวันการชำระเงิน ซึ่งสร้างรายการชำระเงินและชำระใบแจ้งหนี้ เหตุการณ์ธุรกรรมนี้บันทึกไว้ในระบบโดยตรงและปิดกระบวนการจัดการใบแจ้งหนี้. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดของกระบวนการจัดการใบแจ้งหนี้จนถึงการชำระเงิน ใช้เป็นพื้นฐานในการวัด 'อัตราการชำระตรงเวลา' และระยะเวลารอบงานทั้งหมดตั้งแต่ต้นจนจบ.
แหล่งข้อมูล
เป็นเหตุการณ์ที่บันทึกโดยตรงเมื่อมีการลงบัญชีสมุดรายวันการชำระเงิน ข้อมูลการชำระจะบันทึกในตาราง เช่น VendSettlement ซึ่งเชื่อมโยงการชำระเงินกับใบแจ้งหนี้.
บันทึก
เวลาที่ลงบัญชีสมุดรายวันการชำระเงินเพื่อชำระธุรกรรมผู้ขาย.
ประเภทเหตุการณ์
explicit
|
|||
|
บันทึกใบแจ้งหนี้แล้ว
|
เป็นการบันทึกใบแจ้งหนี้เข้าระบบในขั้นต้น โดยสร้างรายการไว้ก่อนประมวลผลรายละเอียดทั้งหมด ระบบบันทึกกิจกรรมนี้เมื่อมีการสร้างรายการใหม่ในสมุดรายวันทะเบียนใบแจ้งหนี้ผู้ขาย. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดเริ่มต้นอย่างเป็นทางการของกระบวนการจัดการใบแจ้งหนี้ การวิเคราะห์เวลาตั้งแต่จุดนี้ช่วยวัดระยะเวลาจัดการทั้งหมดและระบุความล่าช้าในช่วงต้นได้.
แหล่งข้อมูล
เป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนเมื่อสร้างรายการในทะเบียนใบแจ้งหนี้ผู้ขาย โดยทั่วไปอยู่ใน VendInvoiceRegisterJournalTable หรือตารางใบแจ้งหนี้ค้างดำเนินการที่คล้ายกัน.
บันทึก
เวลาที่สร้างรายการในสมุดรายวันทะเบียนใบแจ้งหนี้ผู้ขาย.
ประเภทเหตุการณ์
explicit
|
|||
|
ลงบัญชีใบแจ้งหนี้แล้ว
|
เป็นรายการบัญชีอย่างเป็นทางการที่บันทึกใบแจ้งหนี้ที่อนุมัติแล้วลงในบัญชีแยกประเภททั่วไปและสร้างหนี้สิน เหตุการณ์นี้เป็นรายการธุรกรรมที่บันทึกไว้ในระบบโดยตรง. | ||
|
เหตุผลที่สำคัญ
การลงบัญชีเป็นขั้นตอนสุดท้ายก่อนชำระเงินและเป็นจุดควบคุมทางการเงินที่สำคัญ ระยะเวลาตั้งแต่ 'อนุมัติใบแจ้งหนี้แล้ว' จนถึง 'ลงบัญชีใบแจ้งหนี้แล้ว' ใช้วัดประสิทธิภาพของขั้นตอนบัญชีช่วงท้าย.
แหล่งข้อมูล
เป็นเหตุการณ์ที่บันทึกโดยตรงเมื่อสร้างรายการธุรกรรมผู้ขายที่ลงบัญชีแล้วในตาราง เช่น VendTrans รวมถึงรายการ GeneralJournalEntry และ LedgerEntry ที่เกี่ยวข้อง.
บันทึก
เวลาที่สร้างรายการในตารางธุรกรรมผู้ขาย (VendTrans).
ประเภทเหตุการณ์
explicit
|
|||
|
ส่งใบแจ้งหนี้เพื่อขออนุมัติแล้ว
|
กิจกรรมนี้หมายถึงการส่งใบแจ้งหนี้เข้าสู่เวิร์กโฟลว์อย่างเป็นทางการ เพื่อให้ตรวจสอบและอนุมัติ ระบบเวิร์กโฟลว์ของ Dynamics 365 จะบันทึกเหตุการณ์การส่งนี้โดยตรง. | ||
|
เหตุผลที่สำคัญ
นี่คือจุดเริ่มต้นสำหรับวัดระยะเวลาการอนุมัติทั้งหมด ช่วยให้เห็นว่าใบแจ้งหนี้รอนานเท่าใดก่อนเริ่มกระบวนการอนุมัติ และเป็นจุดเริ่มวัด KPI ที่เกี่ยวข้องกับการอนุมัติ.
แหล่งข้อมูล
เป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนในตารางประวัติเวิร์กโฟลว์ เช่น WorkflowTrackingStatusTable เมื่อส่งใบแจ้งหนี้เข้าสู่เวิร์กโฟลว์.
บันทึก
เวลาที่สร้างรายการส่งเวิร์กโฟลว์ในประวัติเวิร์กโฟลว์.
ประเภทเหตุการณ์
explicit
|
|||
|
อนุมัติใบแจ้งหนี้แล้ว
|
หมายถึงการอนุมัติใบแจ้งหนี้ในเวิร์กโฟลว์ขั้นสุดท้ายสำเร็จ ทำให้สามารถลงบัญชีและชำระเงินได้ ระบบเวิร์กโฟลว์จะบันทึกเหตุการณ์นี้โดยตรงเมื่อดำเนินการเสร็จ. | ||
|
เหตุผลที่สำคัญ
นี่คือหมุดหมายสำคัญที่สิ้นสุดกระบวนการอนุมัติ ระยะเวลาตั้งแต่ 'ส่งใบแจ้งหนี้เพื่อขออนุมัติ' จนถึงเหตุการณ์นี้เป็นตัวชี้วัดประสิทธิภาพการอนุมัติที่สำคัญ และช่วยระบุคอขวด.
แหล่งข้อมูล
เป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนในตารางประวัติเวิร์กโฟลว์ เช่น WorkflowTrackingStatusTable เมื่อสถานะเวิร์กโฟลว์เปลี่ยนเป็น 'อนุมัติแล้ว'.
บันทึก
เวลาที่บันทึกสถานะ 'อนุมัติแล้ว' ในประวัติเวิร์กโฟลว์.
ประเภทเหตุการณ์
explicit
|
|||
|
กำหนดรหัสบัญชีให้ใบแจ้งหนี้แล้ว
|
กิจกรรมนี้หมายถึงการกำหนดบัญชีแยกประเภททั่วไปให้กับรายการในใบแจ้งหนี้ โดยทั่วไปอนุมานจากการสร้างหรือยืนยันการจัดสรรบัญชีแยกประเภทที่เชื่อมโยงกับใบแจ้งหนี้. | ||
|
เหตุผลที่สำคัญ
การกำหนดรหัสบัญชีเป็นขั้นตอนสำคัญต่อความถูกต้องทางการเงิน การวัดเวลาที่ใช้ช่วยระบุคอขวดในขั้นตอนตรวจสอบบัญชี และใช้ประกอบ KPI 'เวลาเฉลี่ยตั้งแต่บันทึกข้อมูลจนกำหนดรหัสบัญชีเสร็จ'.
แหล่งข้อมูล
อนุมานจากการสร้างและตรวจสอบรายการในตารางการจัดสรรบัญชี เช่น AccountingDistribution ที่เชื่อมโยงกับใบแจ้งหนี้ผู้ขายที่รอดำเนินการ.
บันทึก
เวลาที่บันทึกและตรวจสอบการจัดสรรบัญชีของใบแจ้งหนี้เสร็จแล้ว.
ประเภทเหตุการณ์
inferred
|
|||
|
แก้ไขข้อมูลไม่ตรงกันในการจับคู่แล้ว
|
หมายถึงการแก้ไขข้อมูลที่จับคู่ไม่ตรงกันซึ่งพบก่อนหน้านี้ ทำให้ใบแจ้งหนี้ดำเนินการต่อได้ อนุมานจากกรณีที่ใบแจ้งหนี้ซึ่งมีสถานะจับคู่ 'ไม่ผ่าน' ถูกจับคู่ใหม่สำเร็จ หรือมีการข้ามขั้นตอนด้วยตนเอง. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดของกระบวนการย่อยสำหรับแก้ไขข้อมูลไม่ตรงกัน ระยะเวลาตั้งแต่ 'พบข้อมูลจับคู่ไม่ตรงกัน' จนถึงเหตุการณ์นี้เป็น KPI สำคัญในการวัดประสิทธิภาพการแก้ไข.
แหล่งข้อมูล
อนุมานจากเหตุการณ์จับคู่สำเร็จ ('จับคู่ใบแจ้งหนี้กับใบสั่งซื้อแล้ว') ที่เกิดขึ้นหลังเหตุการณ์ 'พบข้อมูลจับคู่ไม่ตรงกัน' สำหรับใบแจ้งหนี้เดียวกัน.
บันทึก
ระบุเวลาที่สถานะการจับคู่เป็น 'ผ่าน' ซึ่งเกิดหลังเวลาที่สถานะเป็น 'ไม่ผ่าน'.
ประเภทเหตุการณ์
inferred
|
|||
|
จัดตารางการชำระเงินแล้ว
|
กิจกรรมนี้เกิดขึ้นเมื่อเพิ่มใบแจ้งหนี้ที่ลงบัญชีแล้วลงในข้อเสนอการชำระเงินหรือสมุดรายวันการชำระเงิน แต่ก่อนดำเนินการชำระเงินจริง เป็นการดำเนินการที่สร้างรายการในสมุดรายวันการชำระเงินโดยตรง. | ||
|
เหตุผลที่สำคัญ
เป็นจุดเปลี่ยนจากงานบัญชีเจ้าหนี้ไปสู่การบริหารเงิน การวิเคราะห์ขั้นตอนนี้ช่วยให้เห็นความล่าช้าระหว่างการลงบัญชีใบแจ้งหนี้กับการเริ่มชำระเงิน.
แหล่งข้อมูล
เป็นเหตุการณ์ที่บันทึกโดยตรงเมื่อสร้างรายการในสมุดรายวันการชำระเงิน (LedgerJournalTrans) เพื่อชำระธุรกรรมผู้ขายที่ลงบัญชีแล้ว.
บันทึก
เวลาที่สร้างรายการในสมุดรายวันการชำระเงินซึ่งอ้างอิงใบแจ้งหนี้.
ประเภทเหตุการณ์
explicit
|
|||
|
ตั้งบล็อกการชำระเงินแล้ว
|
กิจกรรมนี้เกิดขึ้นเมื่อระงับใบแจ้งหนี้ไว้ ทำให้ไม่สามารถชำระเงินได้ ระบบบันทึกจากการเปลี่ยนแปลงฟิลด์บล็อกการชำระเงินหรือสถานะระงับในรายการใบแจ้งหนี้ที่ลงบัญชีแล้ว. | ||
|
เหตุผลที่สำคัญ
การบล็อกการชำระเงินเป็นสาเหตุหลักของการชำระล่าช้า การวิเคราะห์ว่าเริ่มบล็อกเมื่อใดและเพราะเหตุใดจึงสำคัญต่อการเพิ่มอัตราการชำระตรงเวลาและรักษาความสัมพันธ์กับผู้ขาย.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ระงับหรือบล็อกการชำระเงินในรายการธุรกรรมผู้ขายที่ลงบัญชีแล้ว (VendTrans) โดยใช้บันทึกการเปลี่ยนแปลงเพื่อระบุเวลาได้.
บันทึก
เวลาที่อัปเดตฟิลด์บล็อกการชำระเงินในรายการธุรกรรมผู้ขาย.
ประเภทเหตุการณ์
inferred
|
|||
|
บันทึกข้อมูลใบแจ้งหนี้แล้ว
|
หมายถึงการป้อนข้อมูลใบแจ้งหนี้ครบถ้วน ทั้งข้อมูลส่วนหัวและรายการ ก่อนส่งไปจับคู่หรืออนุมัติ โดยมักอนุมานจากการเปลี่ยนสถานะรายการใบแจ้งหนี้จาก 'ใหม่' หรือ 'ลงทะเบียนแล้ว' เป็น 'พร้อมดำเนินการ'. | ||
|
เหตุผลที่สำคัญ
การติดตามกิจกรรมนี้ช่วยวัดประสิทธิภาพการป้อนข้อมูล ไม่ว่าจะทำด้วยตนเองหรืออัตโนมัติด้วย OCR หากล่าช้าในขั้นตอนนี้ อาจส่งผลต่อกระบวนการทั้งหมด.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนสถานะของรายการใบแจ้งหนี้ผู้ขายที่รอดำเนินการ เช่น VendInvoiceInfoTable เหตุการณ์นี้เกิดขึ้นเมื่อกรอกข้อมูลที่จำเป็นครบและใบแจ้งหนี้พร้อมเข้าสู่ขั้นตอนถัดไป.
บันทึก
ตรวจจับการเปลี่ยนสถานะในตารางใบแจ้งหนี้ที่รอดำเนินการ ซึ่งบ่งชี้ว่าป้อนข้อมูลเสร็จแล้ว.
ประเภทเหตุการณ์
inferred
|
|||
|
ปฏิเสธใบแจ้งหนี้แล้ว
|
หมายถึงผู้อนุมัติปฏิเสธใบแจ้งหนี้ ทำให้กระบวนการหยุดและโดยทั่วไปจะส่งกลับไปแก้ไข ระบบเวิร์กโฟลว์จะบันทึกเหตุการณ์การปฏิเสธนี้โดยตรง. | ||
|
เหตุผลที่สำคัญ
การติดตามการปฏิเสธช่วยวัดปริมาณงานแก้ไขซ้ำและระบุสาเหตุที่พบบ่อย เช่น กำหนดรหัสบัญชีไม่ถูกต้องหรือไม่เป็นไปตามนโยบาย ข้อมูลนี้ใช้ประกอบ KPI 'อัตราการปฏิเสธใบแจ้งหนี้' โดยตรง.
แหล่งข้อมูล
เป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนในตารางประวัติเวิร์กโฟลว์ เช่น WorkflowTrackingStatusTable เมื่อสถานะเวิร์กโฟลว์เปลี่ยนเป็น 'ปฏิเสธแล้ว' หรือ 'ยกเลิกแล้ว'.
บันทึก
เวลาที่บันทึกสถานะ 'ปฏิเสธแล้ว' ในประวัติเวิร์กโฟลว์.
ประเภทเหตุการณ์
explicit
|
|||
|
พบข้อมูลไม่ตรงกันในการจับคู่
|
กิจกรรมนี้เกิดขึ้นเมื่อจับคู่ใบแจ้งหนี้ไม่สำเร็จ เนื่องจากข้อมูลใบแจ้งหนี้ ใบสั่งซื้อ หรือการรับสินค้าไม่ตรงกัน ระบบบันทึกเมื่อสถานะการจับคู่ใบแจ้งหนี้เป็น 'ไม่ผ่าน' หรือ 'ข้อมูลไม่ตรงกัน'. | ||
|
เหตุผลที่สำคัญ
การระบุว่าเกิดข้อมูลไม่ตรงกันเมื่อใดและเพราะเหตุใดเป็นเรื่องสำคัญต่อ KPI 'อัตราข้อมูลจับคู่ไม่ตรงกัน' กิจกรรมนี้เป็นจุดเริ่มต้นของการแก้ไข ซึ่งมักทำให้เกิดความล่าช้าอย่างมาก.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์สถานะการจับคู่ในใบแจ้งหนี้ผู้ขาย เช่น VendInvoiceInfoTable เป็นค่า 'ไม่ผ่าน' โดยมักมีการบันทึกสาเหตุที่จับคู่ไม่สำเร็จไว้ด้วย.
บันทึก
เวลาที่สถานะเปลี่ยนเป็น 'ไม่ผ่าน' หรือ 'ข้อมูลไม่ตรงกัน' ระหว่างการจับคู่.
ประเภทเหตุการณ์
inferred
|
|||
|
ยกเลิกบล็อกการชำระเงินแล้ว
|
หมายถึงการยกเลิกการระงับการชำระเงิน ทำให้ใบแจ้งหนี้เข้าสู่ขั้นตอนจัดตารางชำระเงินได้ ระบบบันทึกเมื่อฟิลด์บล็อกการชำระเงินถูกล้างหรือเปลี่ยนเป็นสถานะที่ไม่ถูกบล็อก. | ||
|
เหตุผลที่สำคัญ
ใช้วัดเวลาที่ต้องใช้ในการแก้ปัญหาที่ทำให้ระงับการชำระเงิน หากใช้เวลานานระหว่างการตั้งบล็อกกับการยกเลิกบล็อก แสดงว่ากระบวนการแก้ปัญหาอาจไม่มีประสิทธิภาพ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนแปลงที่ล้างฟิลด์ระงับหรือบล็อกการชำระเงินในรายการธุรกรรมผู้ขายที่ลงบัญชีแล้ว (VendTrans) โดยดูเวลาได้จากบันทึกการเปลี่ยนแปลง.
บันทึก
เวลาที่อัปเดตเพื่อล้างฟิลด์บล็อกการชำระเงินในรายการธุรกรรมผู้ขาย.
ประเภทเหตุการณ์
inferred
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เพื่อเริ่มต้นใช้ process mining และค้นหาข้อมูลเชิงลึกที่จะช่วยให้ประมวลผลใบแจ้งหนี้ได้เร็วและแม่นยำขึ้น เริ่มปรับปรุงการปฏิบัติงานของคุณได้วันนี้.
เริ่มปรับปรุงกระบวนการจัดซื้อจนถึงชำระเงินและการประมวลผลใบแจ้งหนี้วันนี้
ค้นหาจุดที่ทำงานได้ไม่เต็มประสิทธิภาพ และลดระยะเวลาประมวลผลใบแจ้งหนี้ได้ 30% หรือมากกว่า.
ไม่ต้องใช้บัตรเครดิต เริ่มต้นใช้งานได้ภายในไม่กี่นาที.