เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงการชำระเงิน: การประมวลผลใบแจ้งหนี้

Oracle Fusion Financials
เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงการชำระเงิน: การประมวลผลใบแจ้งหนี้

เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงการชำระเงิน: การประมวลผลใบแจ้งหนี้

เทมเพลตนี้ช่วยแนะนำการรวบรวมข้อมูลที่จำเป็นสำหรับวิเคราะห์กระบวนการจัดซื้อจนถึงการชำระเงิน โดยเน้นการประมวลผลใบแจ้งหนี้ใน Oracle Fusion Financials ภายในเทมเพลตระบุแอตทริบิวต์และกิจกรรมสำคัญ พร้อมคำแนะนำในการดึงข้อมูลจากระบบของคุณ เมื่อนำเทมเพลตนี้ไปใช้ คุณจะเตรียมบันทึกเหตุการณ์ได้อย่างถูกต้องและครบถ้วนสำหรับ process mining.
  • แอตทริบิวต์ที่แนะนำให้รวบรวม
  • กิจกรรมสำคัญที่ควรติดตาม
  • คำแนะนำในการดึงข้อมูลจาก Oracle Fusion Financials
เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

แอตทริบิวต์สำหรับการประมวลผลใบแจ้งหนี้ในกระบวนการจัดซื้อจนถึงการชำระเงิน

ฟิลด์ข้อมูลเหล่านี้เป็นรายการที่แนะนำให้ใส่ในบันทึกเหตุการณ์ เพื่อวิเคราะห์กระบวนการจัดซื้อจนถึงการชำระเงินและการประมวลผลใบแจ้งหนี้ได้อย่างครบถ้วน.
3 จำเป็น 7 แนะนำ 10 ไม่บังคับ
ชื่อ คำอธิบาย
หมายเลขใบแจ้งหนี้
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
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในการประมวลผลใบแจ้งหนี้สำหรับกระบวนการจัดซื้อจนถึงการชำระเงิน

ขั้นตอนและจุดสำคัญเหล่านี้เป็นข้อมูลที่ควรบันทึกในบันทึกเหตุการณ์ เพื่อค้นพบกระบวนการได้อย่างแม่นยำ.
6 แนะนำ 9 ไม่บังคับ
กิจกรรม คำอธิบาย
จับคู่ใบแจ้งหนี้กับ 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
แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

วิธีดึงข้อมูลจาก Oracle Fusion Financials

พร้อมเริ่มต้นหรือยัง?

เริ่มปรับปรุงการประมวลผลใบแจ้งหนี้ โดยเตรียมข้อมูลด้วยเทมเพลตนี้ ค้นพบข้อมูลเชิงลึกที่เป็นประโยชน์และปรับปรุงประสิทธิภาพการทำงานขององค์กรได้อย่างชัดเจน.

ปรับปรุงการประมวลผลใบแจ้งหนี้ P2P ให้รอบการทำงานเร็วขึ้น 30%

ลดคอขวดใน Oracle Fusion Financials และลดระยะเวลารอบการทำงานได้ 30%.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต เห็นผลได้ภายในไม่กี่วัน.