> การปรับปรุงกระบวนการอย่างต่อเนื่อง > Order to Cash: การวางบิลและออกใบแจ้งหนี้ > Oracle Fusion Financials > เทมเพลตข้อมูล

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

Oracle Fusion Financials

← กลับไปยังคู่มือการปรับปรุง

แอตทริบิวต์ของกระบวนการตั้งแต่รับคำสั่งซื้อจนถึงรับชำระเงิน: การวางบิลและออกใบแจ้งหนี้(22) กิจกรรมในกระบวนการตั้งแต่รับคำสั่งซื้อจนถึงรับชำระเงิน: การวางบิลและออกใบแจ้งหนี้(13) คู่มือการดึงข้อมูล(2)

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

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

แอตทริบิวต์ที่แนะนำให้เก็บ
กิจกรรมสำคัญที่ควรติดตาม
แนวทางดึงข้อมูลจาก Oracle Fusion Financials

เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

ดาวน์โหลดเทมเพลต

แอตทริบิวต์ของกระบวนการตั้งแต่รับคำสั่งซื้อจนถึงรับชำระเงิน: การวางบิลและออกใบแจ้งหนี้

ฟิลด์ข้อมูลเหล่านี้เป็นรายการที่แนะนำให้ใส่ในบันทึกเหตุการณ์เพื่อวิเคราะห์กระบวนการตั้งแต่รับคำสั่งซื้อจนถึงรับชำระเงินในส่วนการวางบิลและออกใบแจ้งหนี้.

3 จำเป็น 5 แนะนำ 14 ไม่บังคับ

	ชื่อ	คำอธิบาย
	เลขที่ใบแจ้งหนี้ InvoiceNumber	รหัสเฉพาะของใบแจ้งหนี้แต่ละฉบับ ใช้เป็น Case ID หลักสำหรับติดตามกิจกรรมที่เกี่ยวข้องทั้งหมด.
คำอธิบาย เลขที่ใบแจ้งหนี้เป็นหัวใจสำคัญของการวิเคราะห์กระบวนการวางบิล โดยทำหน้าที่เป็น Case ID เพื่อรวบรวมเหตุการณ์ทั้งหมด ตั้งแต่สร้างใบแจ้งหนี้จนถึงรับชำระเงินและปิดรายการ ทำให้เห็นวงจรชีวิตของเอกสารวางบิลแต่ละฉบับตั้งแต่ต้นจนจบ ใน process mining การวิเคราะห์ด้วยเลขที่ใบแจ้งหนี้ช่วยให้เห็นรูปแบบกระบวนการ คำนวณรอบเวลาของใบแจ้งหนี้แต่ละฉบับ และระบุคอขวดหรือการทำงานซ้ำที่กระทบต่อรายการเฉพาะได้ ข้อมูลนี้จำเป็นต่อแดชบอร์ด เช่น 'รอบเวลาของใบแจ้งหนี้ตั้งแต่ต้นจนจบ' และการคำนวณ KPI พื้นฐานอย่าง Days Sales Outstanding (DSO) สำหรับใบแจ้งหนี้แต่ละฉบับ. เหตุผลที่สำคัญ แอตทริบิวต์นี้เชื่อมโยงกิจกรรมด้านการวางบิลและการชำระเงินที่เกี่ยวข้องให้เป็นเคสเดียวกัน จึงวิเคราะห์วงจรชีวิตของใบแจ้งหนี้ได้ครบถ้วนและแม่นยำ. แหล่งข้อมูล โดยทั่วไปคือ Transaction Number (TRX_NUMBER) จากตาราง RA_CUSTOMER_TRX_ALL ใน Oracle Fusion Financials. ตัวอย่าง INV-1002345983451CM-55432
	เวลาเริ่มต้น EventTimestamp	วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์เกิดขึ้น.
คำอธิบาย เวลาประทับเหตุการณ์บันทึกเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ และระบุลำดับเหตุการณ์ของใบแจ้งหนี้แต่ละฉบับ ซึ่งจำเป็นต่อการสร้างลำดับการทำงานและวิเคราะห์ข้อมูลตามเวลา แอตทริบิวต์นี้เป็นพื้นฐานของการคำนวณระยะเวลาและประสิทธิภาพทั้งหมด ใช้วัดช่วงเวลาระหว่างกิจกรรม คำนวณรอบเวลาตั้งแต่ต้นจนจบ ตรวจสอบว่าชำระเงินตรงเวลาหรือไม่ และวิเคราะห์แนวโน้มตามช่วงเวลา KPI เช่น 'เวลาอนุมัติใบแจ้งหนี้เฉลี่ย' และ 'รอบเวลาของใบแจ้งหนี้ตั้งแต่ต้นจนจบ' คำนวณจากเวลาประทับเหล่านี้โดยตรง. เหตุผลที่สำคัญ เวลาประทับจำเป็นต่อการคำนวณตัวชี้วัดประสิทธิภาพทั้งหมด ทั้งรอบเวลา ความล่าช้า และการทำงานตามกำหนดเวลา จึงเป็นพื้นฐานของการวิเคราะห์กระบวนการเชิงปริมาณ. แหล่งข้อมูล ข้อมูลนี้มาจากฟิลด์วันที่ต่างๆ ในตาราง Oracle Fusion Financials เช่น CREATION_DATE ใน RA_CUSTOMER_TRX_ALL หรือเวลาที่อัปเดตสถานะในตาราง workflow. ตัวอย่าง 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
	ชื่อกิจกรรม ActivityName	ชื่อเหตุการณ์ทางธุรกิจหรืองานที่เกิดขึ้น ณ เวลาใดเวลาหนึ่งในวงจรชีวิตของใบแจ้งหนี้.
คำอธิบาย ชื่อกิจกรรมอธิบายขั้นตอนในกระบวนการวางบิล เช่น 'สร้างใบแจ้งหนี้แล้ว' 'อนุมัติใบแจ้งหนี้แล้ว' หรือ 'ได้รับชำระเงินจากลูกค้าแล้ว' เหตุการณ์เหล่านี้เรียงต่อกันเป็นลำดับการทำงานของใบแจ้งหนี้แต่ละฉบับ แอตทริบิวต์นี้เป็นพื้นฐานของการค้นพบกระบวนการ ช่วยให้เครื่องมือ process mining สร้างแผนภาพแสดงวิธีดำเนินการกับใบแจ้งหนี้จริง ใช้วิเคราะห์รูปแบบกระบวนการ ระบุการทำงานซ้ำ เช่น การอนุมัติหลายรอบ และวัดความถี่กับระยะเวลาของแต่ละขั้นตอน แดชบอร์ดและ KPI ทั้งหมดใช้แอตทริบิวต์นี้เพื่อทำความเข้าใจลำดับการทำงาน. เหตุผลที่สำคัญ แอตทริบิวต์นี้กำหนดขั้นตอนในแผนผังกระบวนการ ทำให้เห็นภาพ วิเคราะห์ และระบุจุดที่ทำให้เวิร์กโฟลว์ใบแจ้งหนี้ไม่มีประสิทธิภาพได้. แหล่งข้อมูล ข้อมูลนี้ได้จากตารางและการเปลี่ยนสถานะหลายแห่งใน Oracle Fusion Financials เช่น ตารางประวัติ workflow ที่เกี่ยวกับการอนุมัติ และฟิลด์สถานะของรายการ. ตัวอย่าง สร้างใบแจ้งหนี้อนุมัติใบแจ้งหนี้ได้รับชำระเงินจากลูกค้าปิดใบแจ้งหนี้
	ชื่อลูกค้า CustomerName	ชื่อลูกค้าหรือนิติบุคคลที่ได้รับใบแจ้งหนี้.
คำอธิบาย แอตทริบิวต์นี้ระบุลูกค้าที่เกี่ยวข้องกับใบแจ้งหนี้ เป็นมิติหลักสำหรับแบ่งกลุ่มและกรองข้อมูลกระบวนการ การวิเคราะห์ตามชื่อลูกค้าช่วยให้ทราบว่าลูกค้ารายใดใช้เวลาชำระเงินนานที่สุด รายใดมีแนวโน้มโต้แย้งใบแจ้งหนี้ และรายใดชำระตรงเวลาอย่างสม่ำเสมอ ข้อมูลนี้สำคัญต่อแดชบอร์ดแนวโน้ม DSO และการปรับกลยุทธ์ติดตามหนี้ให้เหมาะกับพฤติกรรมของลูกค้าแต่ละราย. เหตุผลที่สำคัญ ช่วยแบ่งกลุ่มกระบวนการตามลูกค้า ทำให้เห็นพฤติกรรม รูปแบบการชำระเงิน และปัญหาความสัมพันธ์ที่อาจกระทบต่อกระแสเงินสด. แหล่งข้อมูล ได้จากการเชื่อมตารางรายการ (RA_CUSTOMER_TRX_ALL) กับตารางข้อมูลหลักของลูกค้า เช่น HZ_PARTIES. ตัวอย่าง Global Tech Inc.Innovate Solutions LLCApex Manufacturing
	มูลค่าใบแจ้งหนี้ InvoiceAmount	มูลค่าเงินรวมของใบแจ้งหนี้.
คำอธิบาย แอตทริบิวต์นี้ระบุยอดเงินรวมที่ต้องชำระตามใบแจ้งหนี้ เป็นตัวชี้วัดทางการเงินสำคัญที่ช่วยให้เข้าใจมูลค่าเงินที่ไหลผ่านกระบวนการวางบิล การวิเคราะห์ใช้ยอดเงินในใบแจ้งหนี้เพื่อจัดลำดับความสำคัญของรายการมูลค่าสูง คำนวณยอดลูกหนี้คงค้างทั้งหมด และถ่วงน้ำหนัก KPI เช่น Days Sales Outstanding (DSO) นอกจากนี้ยังช่วยแบ่งกลุ่มกระบวนการตามผลกระทบทางการเงิน เช่น ตรวจสอบว่าใบแจ้งหนี้มูลค่าสูงมีขั้นตอนอนุมัติต่างออกไปหรือใช้เวลารับชำระนานกว่าหรือไม่. เหตุผลที่สำคัญ ให้ข้อมูลด้านการเงินของแต่ละเคส ช่วยวิเคราะห์ตามมูลค่า จัดลำดับความสำคัญของใบแจ้งหนี้มูลค่าสูง และคำนวณ KPI ทางการเงินที่สำคัญ. แหล่งข้อมูล อยู่ในตาราง RA_CUSTOMER_TRX_ALL โดยอาจอยู่ในฟิลด์ INVOICE_AMOUNT หรือฟิลด์ที่เกี่ยวข้องซึ่งระบุยอดรวมของรายการ. ตัวอย่าง 5000.001250.75250000.00
	วันครบกำหนดชำระ DueDate	วันที่ต้องชำระเงินตามใบแจ้งหนี้.
คำอธิบาย วันครบกำหนดชำระเป็นแอตทริบิวต์วันที่สำคัญ ซึ่งระบุกำหนดชำระเงินของใบแจ้งหนี้ตามเงื่อนไขการชำระเงิน แอตทริบิวต์นี้จำเป็นต่อการติดตามการเรียกเก็บเงินและสถานะทางการเงิน ใช้เป็นเกณฑ์ตั้งต้นในการคำนวณ KPI อัตราการชำระเงินตรงเวลา และจัดทำรายงานอายุหนี้ ในแดชบอร์ดใช้คาดการณ์กระแสเงินสดจากวันที่คาดว่าจะได้รับชำระ และระบุใบแจ้งหนี้ที่เกินกำหนดซึ่งต้องติดตามเรียกเก็บ. เหตุผลที่สำคัญ เป็นเกณฑ์หลักในการวัดความตรงเวลาของการชำระเงิน คำนวณ DSO และจัดการอายุลูกหนี้การค้า. แหล่งข้อมูล อยู่ในตาราง AR_PAYMENT_SCHEDULES_ALL โดยทั่วไปอยู่ในฟิลด์ DUE_DATE. ตัวอย่าง 2023-05-302023-06-152023-07-01
	สถานะใบแจ้งหนี้ InvoiceStatus	สถานะปัจจุบันของใบแจ้งหนี้ในวงจรชีวิต เช่น 'Open', 'Closed' หรือ 'Disputed'.
คำอธิบาย สถานะใบแจ้งหนี้แสดงภาพรวมว่าใบแจ้งหนี้อยู่ในขั้นตอนใดของกระบวนการ สถานะที่พบบ่อย ได้แก่ เปิดอยู่ (ยังไม่ชำระ) ปิดแล้ว (ชำระแล้ว) โต้แย้ง หรือยกเลิก แอตทริบิวต์นี้มีประโยชน์สำหรับติดตามภาพรวมและกรองข้อมูล ตัวอย่างเช่น แดชบอร์ดคาดการณ์กระแสเงินสดแบบเรียลไทม์ใช้สถานะนี้จัดหมวดหมู่ยอดค้างชำระ ช่วยระบุใบแจ้งหนี้ที่เกินกำหนด อยู่ระหว่างโต้แย้ง หรือชำระครบแล้วได้อย่างรวดเร็ว. เหตุผลที่สำคัญ ช่วยให้เข้าใจสถานะปัจจุบันของใบแจ้งหนี้ได้อย่างรวดเร็วในภาพรวม และกรองหรือจัดหมวดหมู่ข้อมูลเพื่อรายงานทางการเงินและบริหารงานได้สะดวก. แหล่งข้อมูล ได้จากฟิลด์สถานะในตาราง เช่น RA_CUSTOMER_TRX_ALL หรือ AR_PAYMENT_SCHEDULES_ALL (ตัวอย่างเช่น ฟิลด์ STATUS). ตัวอย่าง เปิดอยู่ปิดแล้วโต้แย้งแล้วรออนุมัติ
	หน่วยธุรกิจ BusinessUnit	หน่วยธุรกิจเฉพาะภายในองค์กรที่ออกใบแจ้งหนี้.
คำอธิบาย หน่วยธุรกิจหมายถึงหน่วยงานในองค์กรที่รับผิดชอบรายการนั้น เป็นองค์ประกอบข้อมูลสำคัญสำหรับแบ่งกลุ่มและจัดทำรายงานทางการเงินในองค์กรขนาดใหญ่ แอตทริบิวต์นี้ช่วยเปรียบเทียบประสิทธิภาพของกระบวนการระหว่างส่วนต่างๆ ของบริษัท เช่น วิเคราะห์ว่า DSO แตกต่างกันมากระหว่างหน่วยธุรกิจหรือไม่ หรือหน่วยงานใดมีอัตราการแก้ไขงานวางบิลสูงกว่า ข้อมูลนี้ช่วยกำหนดจุดที่ควรเริ่มปรับปรุงให้ตรงกับความจำเป็น. เหตุผลที่สำคัญ ช่วยเปรียบเทียบประสิทธิภาพระหว่างหน่วยงานต่างๆ และระบุแนวปฏิบัติที่ดีหรือจุดที่ควรปรับปรุงในรายละเอียด. แหล่งข้อมูล มีอยู่ในตารางรายการ เช่น RA_CUSTOMER_TRX_ALL โดยมักใช้ ORG_ID ซึ่งเชื่อมโยงกับข้อมูลหน่วยธุรกิจ. ตัวอย่าง ที่ปรึกษาสหรัฐฯการผลิต EMEAบริการ APAC
	Days Sales Outstanding DaysSalesOutstanding	จำนวนวันระหว่างวันที่ในใบแจ้งหนี้กับวันที่ได้รับชำระเงิน.
คำอธิบาย Days Sales Outstanding (DSO) เป็นตัวชี้วัดทางการเงินสำคัญที่วัดเวลาเฉลี่ยในการรับชำระเงินหลังออกใบแจ้งหนี้ แอตทริบิวต์นี้คำนวณค่า DSO ของใบแจ้งหนี้แต่ละฉบับ แม้ DSO โดยรวมจะเป็น KPI สำคัญ แต่การคำนวณในระดับใบแจ้งหนี้แต่ละฉบับช่วยให้วิเคราะห์ได้ละเอียดขึ้น นำไปสร้างแดชบอร์ดแนวโน้ม ระบุลักษณะของใบแจ้งหนี้ที่มี DSO สูง และวัดผลกระทบทางการเงินจากความล่าช้าในกระบวนการได้ การคำนวณในระดับนี้ช่วยให้เข้าใจปัจจัยที่ทำให้ KPI DSO โดยรวมสูงขึ้น. เหตุผลที่สำคัญ คำนวณตัวชี้วัดกระแสเงินสดสำคัญในระดับใบแจ้งหนี้แต่ละฉบับ ช่วยวิเคราะห์ปัจจัยที่ส่งผลต่อระยะเวลาเรียกเก็บเงินและผลการดำเนินงานทางการเงินได้อย่างละเอียด. แหล่งข้อมูล คำนวณจากผลต่างระหว่างเวลาประทับของกิจกรรม 'ได้รับชำระเงินจากลูกค้าแล้ว' กับแอตทริบิวต์ 'วันที่ในใบแจ้งหนี้'. ตัวอย่าง 356228
	เงื่อนไขการชำระเงิน PaymentTerms	ข้อตกลงการชำระเงินตามใบแจ้งหนี้ เช่น 'Net 30' หรือ '2% 10, Net 30'.
คำอธิบาย เงื่อนไขการชำระเงินกำหนดหลักเกณฑ์ว่าควรชำระใบแจ้งหนี้เมื่อใดและอย่างไร รวมถึงส่วนลดที่อาจได้รับเมื่อชำระก่อนกำหนด ข้อมูลนี้สำคัญต่อการบริหารลูกหนี้และกระแสเงินสด แอตทริบิวต์นี้จำเป็นต่อการคำนวณวันครบกำหนดที่ถูกต้องและระบุโอกาสรับส่วนลดจากการชำระก่อนกำหนด KPI อัตราการใช้สิทธิส่วนลดจากการชำระก่อนกำหนดอาศัยข้อมูลนี้โดยตรง เพื่อพิจารณาว่าใบแจ้งหนี้รายการใดมีสิทธิได้รับส่วนลด. เหตุผลที่สำคัญ กำหนดหลักเกณฑ์การชำระเงินของใบแจ้งหนี้ ซึ่งส่งผลโดยตรงต่อการคำนวณวันครบกำหนดและการติดตามหรือเพิ่มโอกาสใช้สิทธิส่วนลดจากการชำระก่อนกำหนด. แหล่งข้อมูล อยู่ในตาราง RA_TERMS และเชื่อมกับรายการผ่าน term_id ใน RA_CUSTOMER_TRX_ALL. ตัวอย่าง Net 30Net 602% 10, Net 30
	ชำระตรงเวลา IsPaidOnTime	ค่าสถานะจริงหรือเท็จที่ระบุว่าชำระใบแจ้งหนี้ภายในหรือก่อนวันครบกำหนดหรือไม่.
คำอธิบาย แอตทริบิวต์ที่คำนวณนี้ระบุอย่างง่ายว่าการชำระเงินตรงเวลาหรือไม่ โดยเปรียบเทียบวันที่ของกิจกรรม 'ได้รับชำระเงินจากลูกค้าแล้ว' กับแอตทริบิวต์ 'วันครบกำหนดชำระ' ของใบแจ้งหนี้ สถานะนี้ช่วยให้วิเคราะห์และจัดทำรายงาน KPI อัตราการชำระเงินตรงเวลาได้ง่ายขึ้น สามารถกรองและแบ่งกลุ่มข้อมูลเพื่อดูว่าปัจจัยอย่างลูกค้า ภูมิภาค หรือยอดเงินในใบแจ้งหนี้เกี่ยวข้องกับการชำระล่าช้าอย่างไร เป็นตัวชี้วัดสำคัญสำหรับประเมินประสิทธิภาพการติดตามเรียกเก็บเงิน. เหตุผลที่สำคัญ ช่วยวัดประสิทธิภาพการติดตามเรียกเก็บเงินได้ง่ายขึ้น และวิเคราะห์ปัจจัยที่ทำให้ชำระตรงเวลาหรือล่าช้าได้สะดวก. แหล่งข้อมูล คำนวณโดยเปรียบเทียบเวลาประทับของกิจกรรมชำระเงินครั้งสุดท้ายกับแอตทริบิวต์ DueDate โดยใช้ตรรกะ: `PaymentTimestamp <= DueDate`. ตัวอย่าง truefalse
	เป็นงานแก้ไขซ้ำ IsRework	ค่าสถานะจริงหรือเท็จที่ระบุว่ากิจกรรมถือเป็นงานที่ทำซ้ำหรือไม่ เช่น การอนุมัติหรือแก้ไขซ้ำ.
คำอธิบาย แอตทริบิวต์ที่คำนวณนี้ทำเครื่องหมายกิจกรรมที่เป็นงานซ้ำซ้อนหรือไม่จำเป็น เช่น ใบแจ้งหนี้ถูกปฏิเสธแล้วส่งขออนุมัติใหม่ หรือมีการแก้ไขหลังจากสร้างครั้งแรก การทำเครื่องหมายงานที่ทำซ้ำช่วยให้วัดผลกระทบต่อกระบวนการได้ง่าย KPI อัตราการแก้ไขงานวางบิลคำนวณจากแอตทริบิวต์นี้โดยตรง แดชบอร์ดแสดงความถี่ของงานที่ทำซ้ำและวัดเวลาที่เพิ่มขึ้นจากการแก้ไขงาน ช่วยระบุต้นตอของความไม่มีประสิทธิภาพและข้อผิดพลาด. เหตุผลที่สำคัญ ระบุความไม่มีประสิทธิภาพของกระบวนการโดยตรง ด้วยการทำเครื่องหมายงานที่ไม่จำเป็นหรือทำซ้ำ จึงวัดผลกระทบด้านต้นทุนและเวลาอันเกิดจากปัญหาคุณภาพได้ง่าย. แหล่งข้อมูล คำนวณระหว่างการแปลงข้อมูลโดยอิงจากลำดับกิจกรรม ตัวอย่างเช่น หากกิจกรรม 'อนุมัติใบแจ้งหนี้แล้ว' มีเหตุการณ์ 'ปฏิเสธใบแจ้งหนี้' ของเคสเดียวกันเกิดขึ้นก่อนหน้า ระบบจะทำเครื่องหมายว่าเป็นงานที่ทำซ้ำ. ตัวอย่าง truefalse
	ผู้ใช้ User	พนักงานหรือผู้ใช้ระบบที่ดำเนินกิจกรรมหนึ่งๆ.
คำอธิบาย แอตทริบิวต์ผู้ใช้ระบุบุคคลหรือระบบอัตโนมัติที่รับผิดชอบขั้นตอนหนึ่งของกระบวนการ เช่น ผู้ใช้ที่สร้างใบแจ้งหนี้ ผู้จัดการที่อนุมัติ หรือเจ้าหน้าที่ติดตามหนี้ที่ส่งหนังสือเตือน การวิเคราะห์ตามผู้ใช้ช่วยระบุความต้องการด้านการฝึกอบรม การกระจายภาระงาน และความแตกต่างด้านประสิทธิภาพระหว่างบุคคลหรือทีม นอกจากนี้ยังช่วยให้เห็นว่าผู้ใช้บางรายเกี่ยวข้องกับอัตราข้อผิดพลาดที่สูง หรือผู้อนุมัติบางคนเป็นคอขวดอยู่เสมอหรือไม่. เหตุผลที่สำคัญ ระบุผู้รับผิดชอบในแต่ละขั้นตอน ช่วยวิเคราะห์ประสิทธิภาพและภาระงานของผู้ใช้ รวมถึงระบุความต้องการด้านการฝึกอบรม. แหล่งข้อมูล ดึงจากฟิลด์รหัสผู้ใช้ เช่น CREATED_BY หรือ LAST_UPDATED_BY ในตารางรายการและ workflow ต่างๆ จากนั้นนำรหัสไปเชื่อมกับตารางรายชื่อผู้ใช้ (เช่น PER_ALL_PEOPLE_F) เพื่อดึงชื่อผู้ใช้. ตัวอย่าง john.smithjane.doeCollectionsBot
	แผนกวางบิล BillingDepartment	แผนกหรือทีมภายในที่รับผิดชอบการสร้างและจัดการใบแจ้งหนี้.
คำอธิบาย แอตทริบิวต์นี้ระบุทีมงานหรือแผนกภายในองค์กรที่ดูแลกระบวนการวางบิล ช่วยเพิ่มบริบทด้านโครงสร้างองค์กรในการวิเคราะห์ เมื่อแบ่งข้อมูลตามแผนกวางบิล บริษัทจะเปรียบเทียบประสิทธิภาพและความถูกต้องของแต่ละทีมได้ ช่วยระบุแผนกที่มีการแก้ไขงานซ้ำ รอบเวลาการอนุมัตินาน หรือมีส่วนทำให้ DSO สูงกว่าแผนกอื่น เพื่อกำหนดการฝึกอบรมหรือปรับมาตรฐานกระบวนการให้ตรงจุด. เหตุผลที่สำคัญ ช่วยเปรียบเทียบประสิทธิภาพระหว่างทีมภายใน และระบุแนวปฏิบัติที่ดี ความต้องการด้านทรัพยากร หรือจุดที่ควรปรับปรุงกระบวนการ. แหล่งข้อมูล ข้อมูลนี้อาจได้จากผู้ใช้ที่สร้างใบแจ้งหนี้ โดยเชื่อมโยงผู้ใช้กับแผนกที่สังกัดในระบบ HR (เช่น ผ่าน PER_ALL_ASSIGNMENTS_F). ตัวอย่าง ฝ่ายวางบิลส่วนกลางทีมวางบิลบริการทีมวางบิลยอดขายผลิตภัณฑ์
	ภูมิภาค Region	ภูมิภาคทางภูมิศาสตร์ที่เกี่ยวข้องกับลูกค้าหรือรายการ.
คำอธิบาย ภูมิภาคให้บริบทด้านภูมิศาสตร์ของใบแจ้งหนี้ โดยทั่วไปอ้างอิงจากที่ตั้งของลูกค้า จึงนำไปวิเคราะห์ประสิทธิภาพของกระบวนการตามพื้นที่ได้ การวิเคราะห์ตามภูมิภาคช่วยให้เห็นความแตกต่างที่เกิดจากกฎระเบียบในท้องถิ่น สภาวะตลาด หรือประสิทธิภาพของทีมในแต่ละพื้นที่ สามารถแบ่งข้อมูลแดชบอร์ดแนวโน้ม DSO และรอบเวลาของใบแจ้งหนี้ตั้งแต่ต้นจนจบตามภูมิภาค เพื่อดูว่าพื้นที่ใดมีปัญหาเฉพาะในการรับชำระเงิน. เหตุผลที่สำคัญ ช่วยแบ่งข้อมูลกระบวนการตามภูมิภาค เพื่อให้เห็นความแตกต่างด้านประสิทธิภาพ พฤติกรรมลูกค้า หรือการปฏิบัติตามข้อกำหนดในแต่ละพื้นที่. แหล่งข้อมูล โดยทั่วไปได้จากข้อมูลที่อยู่ของลูกค้าใน TCA (HZ_LOCATIONS, HZ_PARTY_SITES) ไม่ใช่ฟิลด์โดยตรงในใบแจ้งหนี้. ตัวอย่าง อเมริกาเหนือยุโรปเอเชียแปซิฟิก
	รอบเวลาของใบแจ้งหนี้ InvoiceCycleTime	ระยะเวลารวมตั้งแต่สร้างใบแจ้งหนี้ครั้งแรกจนถึงปิดรายการ.
คำอธิบาย แอตทริบิวต์นี้วัดระยะเวลาตั้งแต่ต้นจนจบของวงจรชีวิตใบแจ้งหนี้หนึ่งเคส คำนวณจากผลต่างระหว่างกิจกรรมแรกสุด ซึ่งโดยทั่วไปคือ 'สร้างใบแจ้งหนี้แล้ว' กับกิจกรรมสุดท้าย 'ปิดใบแจ้งหนี้แล้ว' ตัวชี้วัดนี้แสดงประสิทธิภาพโดยรวมของกระบวนการ และเป็นตัวชี้วัดหลักของแดชบอร์ด 'รอบเวลาของใบแจ้งหนี้ตั้งแต่ต้นจนจบ' เมื่อวิเคราะห์ตามมิติต่างๆ เช่น ลูกค้าหรือหน่วยธุรกิจ องค์กรจะระบุได้ว่าใบแจ้งหนี้ประเภทใดใช้เวลาดำเนินการนานที่สุด และตรวจสอบสาเหตุที่แท้จริงได้. เหตุผลที่สำคัญ เป็นตัวชี้วัดสำคัญเพียงค่าเดียวที่แสดงความเร็วโดยรวมของกระบวนการ ช่วยระบุได้อย่างรวดเร็วว่าใบแจ้งหนี้ใดใช้เวลานานที่สุดตั้งแต่เริ่มจนเสร็จ. แหล่งข้อมูล เป็นตัวชี้วัดที่คำนวณจากผลต่างระหว่าง EventTimestamp ค่าสูงสุดและค่าต่ำสุดของ InvoiceNumber แต่ละรายการ. ตัวอย่าง 45 วัน 8 ชั่วโมง32 วัน 2 ชั่วโมง90 วัน 12 ชั่วโมง
	ระบบต้นทาง SourceSystem	ระบบบันทึกข้อมูลต้นทางที่ดึงข้อมูลเหตุการณ์ออกมา.
คำอธิบาย แอตทริบิวต์นี้ระบุแอปพลิเคชันต้นทางของข้อมูล โดยทั่วไปกระบวนการนี้ใช้ Oracle Fusion Financials แต่อาจระบุโมดูลเฉพาะภายในระบบ เช่น Oracle Receivables (AR) ได้ด้วย หากมีหลายระบบเชื่อมต่อกัน ฟิลด์นี้ช่วยแยกแหล่งข้อมูลและมีความสำคัญต่อการตรวจสอบความถูกต้องและการกำกับดูแลข้อมูล เพื่อให้มั่นใจว่าการวิเคราะห์ใช้ชุดข้อมูลที่ถูกต้องตามต้องการ. เหตุผลที่สำคัญ ระบุที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลข้อมูล การแก้ไขปัญหา และการตรวจสอบว่าการวิเคราะห์อ้างอิงระบบบันทึกข้อมูลที่ถูกต้อง. แหล่งข้อมูล โดยทั่วไปจะกำหนดค่าไว้ตายตัว ('Oracle Fusion Financials') ระหว่างการดึงและแปลงข้อมูล. ตัวอย่าง Oracle Fusion FinancialsOracle AR CloudFusion Apps
	วันที่ในใบแจ้งหนี้ InvoiceDate	วันที่อย่างเป็นทางการที่ออกใบแจ้งหนี้.
คำอธิบาย วันที่ในใบแจ้งหนี้ หรือที่เรียกว่าวันที่ทำรายการ คือวันที่ระบุในเอกสารใบแจ้งหนี้ และใช้เป็นจุดเริ่มต้นในการคำนวณเงื่อนไขการชำระเงิน วันที่นี้เป็นองค์ประกอบสำคัญในการคำนวณ Days Sales Outstanding (DSO) ซึ่งวัดระยะเวลาตั้งแต่วันที่ในใบแจ้งหนี้จนถึงวันที่ได้รับชำระเงิน วันที่นี้ต่างจากวันที่สร้างรายการในระบบ และเป็นจุดเริ่มต้นอย่างเป็นทางการของรอบการชำระเงินในมุมมองของลูกค้า. เหตุผลที่สำคัญ เป็นวันเริ่มต้นอย่างเป็นทางการของวงจรชีวิตใบแจ้งหนี้ และเป็นเกณฑ์ตั้งต้นในการคำนวณ KPI Days Sales Outstanding (DSO). แหล่งข้อมูล อยู่ในตาราง RA_CUSTOMER_TRX_ALL ในฟิลด์ TRX_DATE. ตัวอย่าง 2023-04-142023-05-182023-06-25
	วิธีชำระเงิน PaymentMethod	วิธีที่ลูกค้าใช้ชำระเงิน เช่น โอนเงินผ่านธนาคารหรือบัตรเครดิต.
คำอธิบาย แอตทริบิวต์นี้ระบุวิธีที่ลูกค้าใช้ชำระใบแจ้งหนี้ ข้อมูลนี้มีประโยชน์ต่อการวิเคราะห์แนวโน้มและต้นทุนการชำระเงิน วิธีชำระเงินแต่ละแบบอาจใช้เวลาดำเนินการและมีต้นทุนธุรกรรมต่างกัน การวิเคราะห์ตามวิธีชำระเงินช่วยให้ทราบว่าวิธีใดมีแนวโน้มเกิดข้อผิดพลาดในการกระทบยอดหรือล่าช้า และใช้ประกอบการวางแผนส่งเสริมช่องทางชำระเงินที่มีประสิทธิภาพกว่าได้. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพการดำเนินการชำระเงิน ต้นทุนธุรกรรม และอัตราข้อผิดพลาดในการกระทบยอดของช่องทางชำระเงินแต่ละแบบ. แหล่งข้อมูล อยู่ในตารางรับเงิน เช่น AR_CASH_RECEIPTS_ALL ซึ่งมีฟิลด์ระบุวิธีชำระเงิน. ตัวอย่าง ACHโอนเงินผ่านธนาคารบัตรเครดิตเช็ค
	เวลาสิ้นสุด EventEndTime	วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์เสร็จสิ้น.
คำอธิบาย เวลาสิ้นสุดเหตุการณ์บันทึกเวลาที่กิจกรรมเสร็จสิ้น แม้หลายเหตุการณ์จะเกิดขึ้นทันที แต่กิจกรรมบางอย่าง เช่น 'การอนุมัติใบแจ้งหนี้' อาจใช้เวลา โดยเริ่มตั้งแต่ส่งคำขอจนมีการตัดสินใจ การมีเวลาสิ้นสุดช่วยคำนวณระยะเวลาดำเนินกิจกรรมได้อย่างแม่นยำ และวิเคราะห์เวลาที่ผู้ใช้ใช้กับงานแต่ละอย่าง นอกจากนี้ยังช่วยให้วิเคราะห์คอขวดได้แม่นยำขึ้น โดยแยกเวลารอออกจากเวลาที่ใช้ดำเนินงานจริง. เหตุผลที่สำคัญ ช่วยคำนวณระยะเวลาดำเนินกิจกรรมได้อย่างแม่นยำ และแยกเวลาทำงานจริงออกจากเวลารอ ซึ่งจำเป็นต่อการวิเคราะห์คอขวดในรายละเอียด. แหล่งข้อมูล มักอนุมานจากเวลาเริ่มต้นของกิจกรรมถัดไปในกระบวนการ สำหรับบางกิจกรรม อาจมีฟิลด์เวลาสิ้นสุดโดยเฉพาะในบันทึก workflow. ตัวอย่าง 2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
	เหตุผลที่โต้แย้ง DisputeReason	เหตุผลที่ลูกค้าแจ้งเมื่อโต้แย้งใบแจ้งหนี้.
คำอธิบาย เมื่อลูกค้าโต้แย้งใบแจ้งหนี้ ระบบจะบันทึกเหตุผลไว้ ซึ่งอาจเกี่ยวกับราคา จำนวน คุณภาพบริการ หรือประเด็นอื่นๆ การวิเคราะห์เหตุผลที่โต้แย้งช่วยค้นหาสาเหตุที่แท้จริง เมื่อทราบเหตุผลที่พบบ่อย ธุรกิจจะจัดการปัญหาที่ต้นเหตุด้านราคา การจัดส่งสินค้า หรือคุณภาพข้อมูลได้ ช่วยลดเวลาเฉลี่ยในการแก้ไขข้อโต้แย้งเกี่ยวกับใบแจ้งหนี้และเพิ่มความพึงพอใจของลูกค้า. เหตุผลที่สำคัญ ช่วยให้เห็นสาเหตุที่แท้จริงของความล่าช้าในการชำระเงินและความไม่พอใจของลูกค้าโดยตรง ทำให้ธุรกิจแก้ไขปัญหาที่เกิดซ้ำได้. แหล่งข้อมูล ข้อมูลนี้อาจจัดเก็บใน Oracle Collections หรือโมดูลจัดการข้อโต้แย้งที่เกี่ยวข้อง อาจอยู่ในตารางข้อโต้แย้งเฉพาะหรือเป็นรหัสเหตุผลในรายการนั้น. ตัวอย่าง ราคาไม่ถูกต้องจำนวนไม่ตรงกันสินค้าเสียหายใบแจ้งหนี้ซ้ำ
	อัปเดตข้อมูลล่าสุด LastDataUpdate	เวลาประทับที่ระบุว่ามีการรีเฟรชหรือดึงข้อมูลเหตุการณ์จากระบบต้นทางครั้งล่าสุดเมื่อใด.
คำอธิบาย แอตทริบิวต์นี้ระบุเวลาที่ดึงข้อมูลล่าสุด เป็นฟิลด์เมทาดาทาที่ช่วยให้ทราบว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด นักวิเคราะห์ใช้ข้อมูลนี้ตรวจสอบว่ากำลังทำงานกับข้อมูลที่เป็นปัจจุบัน และดูได้ว่าข้อมูลถูกอัปเดตเมื่อใด ฟิลด์นี้สำคัญเป็นพิเศษสำหรับแดชบอร์ดที่ระบุว่าข้อมูลเป็น 'เรียลไทม์' หรือใกล้เคียงเรียลไทม์ เพราะช่วยให้เห็นความล่าช้าของข้อมูลที่อาจเกิดขึ้น. เหตุผลที่สำคัญ แจ้งให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด เพื่อให้มั่นใจว่าการวิเคราะห์และข้อสรุปอ้างอิงข้อมูลที่ทราบช่วงเวลาและยอมรับได้. แหล่งข้อมูล ฟิลด์เมทาดาทานี้สร้างขึ้นระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL) โดยทั่วไปจะตรงกับเวลาที่ไปป์ไลน์ข้อมูลทำงาน. ตัวอย่าง 2023-10-27T02:00:00Z2023-10-28T02:00:00Z

จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในกระบวนการตั้งแต่รับคำสั่งซื้อจนถึงรับชำระเงิน: การวางบิลและออกใบแจ้งหนี้

ขั้นตอนและจุดสำคัญของกระบวนการที่ควรบันทึกในบันทึกเหตุการณ์เพื่อค้นหากระบวนการได้อย่างแม่นยำ.

6 แนะนำ 7 ไม่บังคับ

	กิจกรรม	คำอธิบาย
	ได้รับชำระเงินจากลูกค้า	บันทึกการชำระเงินจากลูกค้าในระบบเป็นรายการรับเงินสด ในขั้นตอนนี้อาจยังไม่ได้จัดสรรยอดชำระให้กับใบแจ้งหนี้ฉบับใดโดยเฉพาะ.
เหตุผลที่สำคัญ หมุดหมายสำคัญนี้แสดงถึงเงินสดรับ ระยะเวลาตั้งแต่ได้รับเงินจนถึงนำยอดไปตัดกับใบแจ้งหนี้เป็นตัวชี้วัดสำคัญของประสิทธิภาพการบริหารเงินสด. แหล่งข้อมูล บันทึกเหตุการณ์นี้เมื่อสร้างรายการในตาราง AR_CASH_RECEIPTS_ALL โดย receipt_date ระบุวันที่ประมวลผลการชำระเงิน. บันทึก ใช้ creation_date หรือ receipt_date จากตาราง AR_CASH_RECEIPTS_ALL. ประเภทเหตุการณ์ explicit
	นำยอดชำระไปตัดกับใบแจ้งหนี้	จับคู่ยอดชำระจากลูกค้าที่ได้รับแล้วกับใบแจ้งหนี้ที่เกี่ยวข้องและนำไปตัดยอดสำเร็จ ทำให้ยอดค้างชำระลดลง โดยบันทึกเป็นรายการธุรกรรมแยกต่างหาก.
เหตุผลที่สำคัญ กิจกรรมนี้ยืนยันว่าจัดสรรเงินสดถูกต้อง ซึ่งจำเป็นต่อการจัดทำรายงานอายุหนี้และงบการเงินที่แม่นยำ นับเป็นขั้นตอนสุดท้ายในการบันทึกรับเงินเพื่อตัดยอดลูกหนี้. แหล่งข้อมูล บันทึกเหตุการณ์นี้ไว้อย่างชัดเจนในตาราง AR_RECEIVABLE_APPLICATIONS_ALL โดยฟิลด์ apply_date และ gl_date ระบุวันที่ดำเนินการจัดสรรยอด. บันทึก ใช้ apply_date จากตาราง AR_RECEIVABLE_APPLICATIONS_ALL ซึ่งเชื่อมโยงรายการรับเงินสดกับใบแจ้งหนี้. ประเภทเหตุการณ์ explicit
	ปิดใบแจ้งหนี้	เมื่อชำระใบแจ้งหนี้ครบและกระทบยอดแล้ว ถือว่ากระบวนการเสร็จสมบูรณ์ โดยทั่วไปอนุมานเหตุการณ์นี้เมื่อยอดค้างชำระเป็นศูนย์และมีการอัปเดตสถานะแล้ว.
เหตุผลที่สำคัญ นี่คือผลสรุปสุดท้ายของใบแจ้งหนี้และเป็นจุดสิ้นสุดของกระบวนการ ระยะเวลาตั้งแต่เริ่มจนถึงสถานะนี้คือรอบเวลาตั้งแต่ต้นจนจบ ซึ่งเป็น KPI หลักของกระบวนการวางบิล. แหล่งข้อมูล อนุมานจากตาราง AR_PAYMENT_SCHEDULES_ALL เมื่ออัปเดตสถานะเป็น 'CLOSED' และ amount_due_remaining เป็นศูนย์ ฟิลด์ 'gl_date_closed' ระบุวันที่ปิดรายการ. บันทึก ใช้ค่า gl_date_closed ของใบแจ้งหนี้รายการนั้นจาก AR_PAYMENT_SCHEDULES_ALL. ประเภทเหตุการณ์ inferred
	ส่งใบแจ้งหนี้ให้ลูกค้า	ส่งใบแจ้งหนี้ให้ลูกค้าผ่านช่องทางที่ลูกค้าต้องการแล้ว เช่น อีเมลหรือเอกสารพิมพ์ โดยทั่วไประบบจะบันทึกเวลาที่ดำเนินการส่ง.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นอย่างเป็นทางการของระยะเวลาชำระเงิน การวัดเวลาตั้งแต่อนุมัติจนถึงส่งใบแจ้งหนี้ช่วยให้เข้าใจประสิทธิภาพของกระบวนการจัดส่ง. แหล่งข้อมูล อนุมานได้จากฟิลด์ 'last_printed_date' ใน RA_CUSTOMER_TRX_ALL หรือจากบันทึกใน Oracle Business Intelligence Publisher หากส่งเอกสารทางอิเล็กทรอนิกส์. บันทึก ใช้เวลาจากบันทึกการจัดส่งหรือการพิมพ์ที่เกี่ยวข้องกับใบแจ้งหนี้. ประเภทเหตุการณ์ inferred
	สร้างใบแจ้งหนี้	การสร้างรายการใบแจ้งหนี้ครั้งแรกในระบบ ซึ่งมักมีสถานะเป็นฉบับร่างหรือยังไม่สมบูรณ์ ระบบบันทึกเหตุการณ์นี้เมื่อผู้ใช้บันทึกรายการใบแจ้งหนี้ใหม่เป็นครั้งแรกในโมดูล Accounts Receivable.
เหตุผลที่สำคัญ เหตุการณ์นี้เป็นจุดเริ่มต้นที่ชัดเจนของกระบวนการวางบิล การวิเคราะห์เวลาตั้งแต่สร้างจนเสร็จช่วยระบุความล่าช้าในการป้อนข้อมูลช่วงต้นหรือปัญหาประสิทธิภาพของระบบ. แหล่งข้อมูล บันทึกเหตุการณ์นี้จากวันที่สร้างรายการธุรกรรมในตาราง RA_CUSTOMER_TRX_ALL โดยสถานะเริ่มต้นมักเป็น 'Incomplete'. บันทึก ใช้ creation_date จากตาราง RA_CUSTOMER_TRX_ALL สำหรับหมายเลขใบแจ้งหนี้ที่ต้องการ. ประเภทเหตุการณ์ explicit
	อนุมัติใบแจ้งหนี้	ใบแจ้งหนี้ได้รับการอนุมัติครบถ้วนและพร้อมส่งให้ลูกค้า ระบบบันทึกเหตุการณ์นี้เมื่อเวิร์กโฟลว์อนุมัติเสร็จสมบูรณ์และอัปเดตสถานะใบแจ้งหนี้.
เหตุผลที่สำคัญ หมุดหมายสำคัญนี้เป็นเงื่อนไขก่อนส่งใบแจ้งหนี้ให้ลูกค้า หากล่าช้าจะส่งผลโดยตรงต่อเวลาที่เริ่มนับกำหนดชำระ และกระทบจำนวนวันขายค้างรับ (DSO). แหล่งข้อมูล อนุมานจากการอัปเดตสถานะอนุมัติขั้นสุดท้ายในรายการใบแจ้งหนี้ หรือเวลาที่งาน BPM ที่เกี่ยวข้องเสร็จสมบูรณ์. บันทึก บันทึกเวลาที่สถานะอนุมัติใบแจ้งหนี้เปลี่ยนเป็น 'Approved'. ประเภทเหตุการณ์ inferred
	กรอกข้อมูลใบแจ้งหนี้เสร็จสมบูรณ์	หมายถึงการป้อนข้อมูลใบแจ้งหนี้เสร็จสมบูรณ์ และรายการพร้อมสำหรับการตรวจสอบความถูกต้องและการบันทึกบัญชี โดยทั่วไปตรวจจับได้จากการเปลี่ยนสถานะใบแจ้งหนี้จาก 'Incomplete' เป็น 'Complete'.
เหตุผลที่สำคัญ หมุดหมายนี้แสดงจุดสิ้นสุดของขั้นตอนป้อนข้อมูล ระยะเวลาตั้งแต่สร้างจนเสร็จช่วยบ่งชี้ประสิทธิภาพของการป้อนข้อมูลและตรวจสอบในแผนกวางบิล. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะของรายการใบแจ้งหนี้ในตาราง RA_CUSTOMER_TRX_ALL โดยดูเวลาที่มีการอัปเดตสถานะเป็น 'Complete'. บันทึก ติดตามประวัติสถานะของรายการใน RA_CUSTOMER_TRX_ALL หรือตารางเวิร์กโฟลว์ที่เกี่ยวข้อง. ประเภทเหตุการณ์ inferred
	ถึงวันครบกำหนดชำระ	วันที่ครบกำหนดชำระใบแจ้งหนี้ตามสัญญาผ่านไปแล้ว เหตุการณ์นี้ไม่ใช่ธุรกรรม แต่คำนวณจากเงื่อนไขของใบแจ้งหนี้และวันที่ปัจจุบัน.
เหตุผลที่สำคัญ เหตุการณ์ที่คำนวณนี้เป็นพื้นฐานสำคัญสำหรับวิเคราะห์อายุหนี้และคำนวณ DSO ช่วยแยกใบแจ้งหนี้ที่ชำระตรงเวลาออกจากรายการค้างชำระ เพื่อให้ติดตามหนี้ได้ตรงจุด. แหล่งข้อมูล เหตุการณ์นี้คำนวณขึ้นเมื่อวันที่ปัจจุบันมากกว่าค่า due_date ในตาราง AR_PAYMENT_SCHEDULES_ALL ของใบแจ้งหนี้นั้น. บันทึก คำนวณโดยเปรียบเทียบวันที่ปัจจุบันกับฟิลด์ due_date ใน AR_PAYMENT_SCHEDULES_ALL. ประเภทเหตุการณ์ calculated
	ปฏิเสธใบแจ้งหนี้	ผู้อนุมัติปฏิเสธใบแจ้งหนี้ โดยทั่วไปเกิดจากข้อมูลผิดพลาด เช่น ราคา หรือจำนวนสินค้า เหตุการณ์นี้ส่งใบแจ้งหนี้กลับไปแก้ไขและทำให้เกิดวงจรการทำงานซ้ำ.
เหตุผลที่สำคัญ การติดตามรายการที่ถูกปฏิเสธช่วยให้เห็นปัญหาด้านความถูกต้องของการวางบิลและการควบคุมภายใน การวิเคราะห์ความถี่และเหตุผลที่ถูกปฏิเสธช่วยระบุจุดที่ควรปรับปรุงกระบวนการและฝึกอบรม. แหล่งข้อมูล อนุมานจากการอัปเดตสถานะในรายการใบแจ้งหนี้ หรือผลลัพธ์ 'Rejected' ในงาน BPM. บันทึก บันทึกเวลาที่สถานะอนุมัติใบแจ้งหนี้เปลี่ยนเป็น 'Rejected'. ประเภทเหตุการณ์ inferred
	ปรับยอดใบแจ้งหนี้	มีการแก้ไขยอดใบแจ้งหนี้ เช่น ตัดหนี้สูญหรือออกเครดิตโน้ต ซึ่งเป็นธุรกรรมที่ปรับยอดค้างชำระของใบแจ้งหนี้โดยตรง.
เหตุผลที่สำคัญ การปรับปรุงยอดมักบ่งชี้ถึงข้อโต้แย้ง การยอมลดราคา หรือการแก้ไขข้อผิดพลาด การวิเคราะห์ความถี่และมูลค่าของรายการปรับปรุงช่วยให้เห็นปัญหาที่ซ่อนอยู่ในกระบวนการ Order to Cash. แหล่งข้อมูล บันทึกเหตุการณ์นี้ไว้อย่างชัดเจนในตาราง AR_ADJUSTMENTS_ALL โดย creation_date ของรายการปรับปรุงเป็นเวลาที่เกิดเหตุการณ์. บันทึก ใช้ creation_date จากตาราง AR_ADJUSTMENTS_ALL สำหรับใบแจ้งหนี้ที่เกี่ยวข้อง. ประเภทเหตุการณ์ explicit
	เริ่มโต้แย้งใบแจ้งหนี้	ลูกค้าโต้แย้งใบแจ้งหนี้อย่างเป็นทางการ และมีการสร้างกรณีโต้แย้งในระบบ โดยทั่วไปบันทึกเหตุการณ์นี้ด้วยการเปลี่ยนค่าสถานะในกำหนดการชำระเงินของใบแจ้งหนี้.
เหตุผลที่สำคัญ ข้อโต้แย้งทำให้กระบวนการชำระเงินหยุดชะงักและต้องใช้แรงงานคนในการแก้ไข การวิเคราะห์ความถี่และเวลาแก้ไขข้อโต้แย้งช่วยค้นหาต้นเหตุ เช่น ข้อผิดพลาดด้านราคาหรือการจัดส่ง. แหล่งข้อมูล อนุมานได้จากฟิลด์สถานะในตาราง AR_PAYMENT_SCHEDULES_ALL ที่เปลี่ยนเป็นสถานะโต้แย้ง หรือจากรายการสร้างกรณีใน AR_DISPUTE_HISTORY. บันทึก ระบุเวลาที่เปิดใช้แฟล็กหรือสถานะโต้แย้งสำหรับกำหนดการชำระเงินของใบแจ้งหนี้. ประเภทเหตุการณ์ inferred
	ส่งการแจ้งเตือนการชำระเงิน	ส่งจดหมายทวงถามหรือหนังสือแจ้งเตือนให้ลูกค้าสำหรับใบแจ้งหนี้ที่ค้างชำระแล้ว โมดูลติดตามหนี้จะบันทึกการดำเนินการนี้ไว้อย่างชัดเจน.
เหตุผลที่สำคัญ การติดตามการแจ้งเตือนช่วยวัดประสิทธิผลของกระบวนการติดตามหนี้ และวิเคราะห์ได้ว่ากลยุทธ์การแจ้งเตือนแบบใดช่วยให้ได้รับชำระเงินเร็วขึ้น. แหล่งข้อมูล บันทึกไว้อย่างชัดเจนในโมดูล Oracle Advanced Collections ตารางประวัติการทวงถาม เช่น IEX_DUNNINGS จะบันทึกวันที่และระดับการแจ้งเตือนที่ส่ง. บันทึก ดึงข้อมูลจากตารางประวัติการทวงถาม โดยเชื่อมโยงรายการทวงถามกับใบแจ้งหนี้. ประเภทเหตุการณ์ explicit
	ส่งใบแจ้งหนี้เพื่อขออนุมัติ	ส่งใบแจ้งหนี้เข้าสู่เวิร์กโฟลว์อนุมัติอย่างเป็นทางการ หากมีการตั้งค่าไว้ ระบบบันทึกเหตุการณ์นี้เมื่อสถานะใบแจ้งหนี้เปลี่ยนเป็นรออนุมัติ และส่งการแจ้งเตือนไปยังผู้อนุมัติที่กำหนด.
เหตุผลที่สำคัญ เป็นจุดเริ่มต้นของรอบอนุมัติ การติดตามกิจกรรมนี้จำเป็นต่อการวัดและวิเคราะห์เวลาที่ใช้อนุมัติ ซึ่งเป็นส่วนสำคัญของระยะเวลารวมในวงจรใบแจ้งหนี้. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะของรายการใบแจ้งหนี้ หรือดึงจากตารางเวิร์กโฟลว์ Oracle Business Process Management (BPM) ที่บันทึกการเริ่มงานอนุมัติ. บันทึก ระบุเวลาที่สถานะอนุมัติของใบแจ้งหนี้เปลี่ยนเป็น 'Pending' หรือสถานะใกล้เคียง. ประเภทเหตุการณ์ inferred

แนะนำ ไม่บังคับ

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

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

ขั้นตอน

ไปที่ BI Publisher: เข้าสู่ระบบ Oracle Fusion Applications แล้วใช้เมนู Navigator ไปที่ Tools จากนั้นเลือก Reports and Analytics คลิก Browse Catalog เพื่อเปิด Business Intelligence Catalog.
สร้าง Data Model: ในแค็ตตาล็อก คลิกเมนู New แล้วเลือก Data Model เพื่อเปิดตัวแก้ไข Data Model.
กำหนดชุดข้อมูล SQL Query: ในแผง Data Model คลิกไอคอนบวกข้าง Data Sets แล้วเลือก SQL Query ในหน้าต่างใหม่ ตั้งชื่อชุดข้อมูล เช่น AR_INVOICE_LIFECYCLE แล้วเลือก Data Source ที่เหมาะสม ซึ่งโดยทั่วไปคือ ApplicationDB_FSCM.
ป้อน SQL Query: คัดลอก SQL query ทั้งหมดจากส่วน query ในเอกสารนี้ แล้ววางลงในช่อง SQL Query ระบบจะรู้จักพารามิเตอร์ เช่น :P_START_DATE, :P_END_DATE และ :P_BUSINESS_UNIT โดยอัตโนมัติ.
ตั้งค่าพารามิเตอร์และดูข้อมูล: ไปที่แท็บ Parameters เพื่อกำหนดค่าเริ่มต้นหรือตั้งค่าการแสดงผลสำหรับผู้ใช้ จากนั้นไปที่แท็บ Data ป้อนค่าพารามิเตอร์ เช่น ช่วงวันที่สั้นๆ แล้วคลิก View เพื่อทดสอบ query และดูตัวอย่างข้อมูลที่ได้.
บันทึก Data Model: เมื่อตรวจสอบแล้วว่าข้อมูลถูกต้อง คลิกไอคอน Save แล้วบันทึก Data Model ไว้ในโฟลเดอร์ที่เหมาะสม เช่น Shared Folders/Custom/ProcessMining.
สร้างรายงาน: กลับไปที่แค็ตตาล็อก คลิกเมนู New แล้วเลือก Report ในตัวช่วยสร้างรายงาน เลือก 'Use Data Model' แล้วค้นหา Data Model ที่เพิ่งบันทึกไว้.
ตั้งค่าเค้าโครงรายงาน: ในตัวแก้ไขเค้าโครงรายงาน ไม่ต้องสร้างเค้าโครงที่ซับซ้อน ให้เลือก 'Create Table' แล้วลากคอลัมน์ทั้งหมดจากชุดข้อมูลมาวาง เป้าหมายคือส่งออกข้อมูลดิบ ไม่ใช่สร้างรายงานที่จัดรูปแบบแล้ว.
กำหนด CSV เป็นรูปแบบเริ่มต้น: ในคุณสมบัติของรายงาน ตั้งค่ารูปแบบผลลัพธ์เริ่มต้นเป็น CSV เพื่อให้รายงานสร้างไฟล์ข้อความธรรมดาที่เหมาะกับ process mining.
ตั้งเวลารายงาน: ในแค็ตตาล็อก ค้นหารายงาน คลิก More แล้วเลือก Schedule สร้างงานใหม่ กำหนดพารามิเตอร์ เช่น ช่วงวันที่และหน่วยธุรกิจ แล้วเลือกปลายทาง โดยทั่วไปจะใช้ Content Server (UCM) หรือเซิร์ฟเวอร์ SFTP ภายนอก.
ดาวน์โหลดบันทึกเหตุการณ์: เมื่องานที่ตั้งเวลาไว้เสร็จแล้ว ไปยังปลายทางที่ระบุ เช่น คลังเนื้อหา UCM เพื่อดาวน์โหลดไฟล์ CSV ที่สร้างขึ้น ไฟล์นี้คือบันทึกเหตุการณ์ของคุณ.
เตรียมไฟล์สำหรับอัปโหลด: ตรวจสอบว่าไฟล์ CSV มีชื่อคอลัมน์ตามที่กำหนดใน query เช่น InvoiceNumber, ActivityName, EventTimestamp เป็นต้น จากนั้นอัปโหลดไฟล์ไปยังแพลตฟอร์ม process mining ได้เลย.

การกำหนดค่า

พารามิเตอร์ BI Publisher: query ใช้พารามิเตอร์เพื่อกำหนดขอบเขตข้อมูล โดยพารามิเตอร์จะแสดงขึ้นโดยอัตโนมัติเมื่อสร้างรายงานจาก Data Model.
- :P_START_DATE: วันเริ่มต้นของช่วงเวลาที่ดึงข้อมูล (รูปแบบ YYYY-MM-DD) query จะกรองกิจกรรมตามเวลาในบันทึก.
- :P_END_DATE: วันสิ้นสุดของช่วงเวลาที่ดึงข้อมูล (รูปแบบ YYYY-MM-DD).
- :P_BUSINESS_UNIT: ชื่อหน่วยธุรกิจที่ต้องการใช้กรองใบแจ้งหนี้ ช่วยลดปริมาณข้อมูลและจำกัดขอบเขตการวิเคราะห์.
ช่วงวันที่: สำหรับการทดสอบและวิเคราะห์เบื้องต้น ให้ดึงข้อมูลช่วงสั้นๆ เช่น 3 ถึง 6 เดือน หากต้องการวิเคราะห์เต็มรูปแบบ อาจดึงข้อมูล 12 ถึง 18 เดือนตามความต้องการของธุรกิจ.
ตั้งค่ารหัสสถานะ: ใน query มีข้อความตัวอย่าง เช่น '[Your Pending Approval Status]' คุณต้องแทนที่ด้วยรหัสสถานะจริงที่ใช้ในเวิร์กโฟลว์อนุมัติใบแจ้งหนี้ของ Oracle Fusion ที่องค์กรติดตั้งไว้ ปรึกษานักวิเคราะห์ระบบเพื่อค้นหาค่าเหล่านี้ในตาราง RA_CUST_TRX_TYPES_ALL หรือรายการค้นหาของระบบ.
ประสิทธิภาพ: การดึงข้อมูลเป็นเวลานานหรือจากทุกหน่วยธุรกิจพร้อมกันอาจใช้ทรัพยากรมาก แนะนำให้ตั้งเวลารายงาน BI Publisher ให้ทำงานนอกช่วงเวลาที่มีการใช้งานสูง เพื่อไม่ให้กระทบประสิทธิภาพของระบบสำหรับผู้ใช้อื่น.
ข้อกำหนดเบื้องต้น: คุณต้องมีบัญชีผู้ใช้ที่มีบทบาทซึ่งอนุญาตให้สร้าง Data Model และรายงานใน BI Publisher เช่น BI Administrator หรือบทบาทที่กำหนดเองซึ่งมีสิทธิ์ใกล้เคียงกัน ผู้ใช้ต้องมีโปรไฟล์ความปลอดภัยของข้อมูลที่อนุญาตให้เข้าถึงข้อมูลลูกหนี้ ลูกค้า และหน่วยธุรกิจที่จำเป็น.

ตัวอย่างคำค้น sql

WITH BaseInvoices AS (
    SELECT
        rct.trx_number,
        rct.customer_trx_id,
        hp.party_name AS customer_name,
        rct.trx_date,
        rct.creation_date,
        rct.last_update_date,
        rct.complete_flag,
        aps.status AS payment_schedule_status,
        aps.amount_due_original,
        aps.due_date,
        aps.dispute_flag,
        aps.gl_date_closed,
        rct.last_printed_date,
        rct.status_trx,
        bu.bu_name AS business_unit
    FROM
        ra_customer_trx_all rct
    JOIN
        hz_cust_accounts hca ON rct.bill_to_customer_id = hca.cust_account_id
    JOIN
        hz_parties hp ON hca.party_id = hp.party_id
    JOIN
        ar_payment_schedules_all aps ON rct.customer_trx_id = aps.customer_trx_id
    JOIN
        fun_all_business_units_v bu ON rct.org_id = bu.bu_id
    WHERE
        bu.bu_name = :P_BUSINESS_UNIT
        AND rct.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD') + 1
        AND aps.class = 'INV'
)
-- 1. Invoice Created
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Created' AS "ActivityName",
    bi.creation_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi

UNION ALL

-- 2. Invoice Completed
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Completed' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.complete_flag = 'Y'

UNION ALL

-- 3. Invoice Submitted for Approval
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Submitted for Approval' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Pending Approval Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 4. Invoice Approved
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Approved' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Approved Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 5. Invoice Rejected
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Rejected' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.status_trx = '[Your Rejected Status]' -- Placeholder: Configure status based on your system

UNION ALL

-- 6. Invoice Sent to Customer
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Sent to Customer' AS "ActivityName",
    bi.last_printed_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.last_printed_date IS NOT NULL

UNION ALL

-- 7. Payment Due Date Reached
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Due Date Reached' AS "ActivityName",
    bi.due_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.due_date <= CURRENT_TIMESTAMP

UNION ALL

-- 8. Payment Reminder Issued
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Reminder Issued' AS "ActivityName",
    dlt.trx_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_dunning_letters_trx dlt ON bi.customer_trx_id = dlt.customer_trx_id

UNION ALL

-- 9. Dispute Initiated
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Dispute Initiated' AS "ActivityName",
    bi.last_update_date AS "EventTimestamp", -- Uses last update as a proxy for dispute date
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    'Disputed' AS "InvoiceStatus", -- Overrides status
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.dispute_flag = 'Y'

UNION ALL

-- 10. Customer Payment Received
SELECT DISTINCT
    bi.trx_number AS "InvoiceNumber",
    'Customer Payment Received' AS "ActivityName",
    acr.receipt_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_receivable_applications_all ara ON bi.customer_trx_id = ara.applied_customer_trx_id
JOIN
    ar_cash_receipts_all acr ON ara.cash_receipt_id = acr.cash_receipt_id
WHERE
    ara.status = 'APP'

UNION ALL

-- 11. Payment Applied to Invoice
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Payment Applied to Invoice' AS "ActivityName",
    ara.apply_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_receivable_applications_all ara ON bi.customer_trx_id = ara.applied_customer_trx_id
WHERE
    ara.status = 'APP'

UNION ALL

-- 12. Invoice Adjusted
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Adjusted' AS "ActivityName",
    adj.creation_date AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    bi.status_trx AS "InvoiceStatus",
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
JOIN
    ar_adjustments_all adj ON bi.customer_trx_id = adj.customer_trx_id

UNION ALL

-- 13. Invoice Closed
SELECT
    bi.trx_number AS "InvoiceNumber",
    'Invoice Closed' AS "ActivityName",
    bi.gl_date_closed AS "EventTimestamp",
    bi.amount_due_original AS "InvoiceAmount",
    bi.customer_name AS "CustomerName",
    bi.due_date AS "DueDate",
    'Closed' AS "InvoiceStatus", -- Overrides status
    bi.business_unit AS "BusinessUnit"
FROM
    BaseInvoices bi
WHERE
    bi.payment_schedule_status = 'CL' AND bi.gl_date_closed IS NOT NULL

ขั้นตอน

ข้อกำหนดเบื้องต้น: ติดตั้ง Python 3.6 ขึ้นไป พร้อมไลบรารี requests และ pandas ติดตั้งได้ด้วย pip โดยใช้คำสั่ง pip install requests pandas.
ข้อมูลรับรอง Oracle Fusion: ขอข้อมูลรับรองที่จำเป็นสำหรับเข้าใช้ Oracle Fusion REST APIs ซึ่งประกอบด้วย URL หลักของ Fusion instance ชื่อผู้ใช้ และรหัสผ่านของบัญชีที่มีสิทธิ์อ่านข้อมูลลูกหนี้.
ตั้งค่า Script: เปิด Python script ที่ให้มาในโปรแกรมแก้ไขข้อความ ไปที่ส่วนตั้งค่าด้านบนของ script แล้วแทนค่าตัวอย่างใน FUSION_URL, USERNAME, PASSWORD และพารามิเตอร์ตัวกรอง เช่น start_date.
ทำความเข้าใจ API Endpoints: Script ใช้ endpoint receivablesInvoices เป็นหลักเพื่อดึงข้อมูลใบแจ้งหนี้ จากนั้นเรียก endpoint อื่น เช่น receivablesReceipts, receivablesReceiptApplications, receivablesAdjustments และ collectionsDelinquentTransactions เพื่อดึงกิจกรรมที่เกี่ยวข้อง.
จัดการการแบ่งหน้า: Script มีฟังก์ชันช่วย get_paginated_data ซึ่งจัดการการแบ่งหน้าของ API โดยอัตโนมัติ ด้วยการเรียกตามลิงก์ next ในการตอบกลับของ API จนกว่าจะดึงข้อมูลครบตาม query.
ดึงข้อมูล: ส่วนหลักของ script จะดึงรายการใบแจ้งหนี้ในช่วงวันที่ที่กำหนดก่อน จากนั้นวนดูใบแจ้งหนี้แต่ละรายการเพื่อดึงรายละเอียดและกิจกรรมที่เกี่ยวข้อง.
สร้างกิจกรรม: Script จะสร้างแถวกิจกรรมต่างๆ สำหรับใบแจ้งหนี้แต่ละรายการ กิจกรรมบางอย่าง เช่น 'สร้างใบแจ้งหนี้' ดึงมาจากฟิลด์ของใบแจ้งหนี้โดยตรง (CreationDate) ส่วนกิจกรรมอย่าง 'บันทึกการชำระเงินกับใบแจ้งหนี้' ต้องเรียก API แยกต่างหาก แล้วเชื่อมข้อมูลกลับไปยังหมายเลขใบแจ้งหนี้.
จัดการกิจกรรมที่คำนวณขึ้น: กิจกรรม 'ถึงกำหนดชำระเงิน' ไม่ได้มาจากธุรกรรมโดยตรง Script จะคำนวณกิจกรรมนี้โดยตรวจสอบว่าวันครบกำหนด (DueDate) ผ่านไปแล้วหรือไม่ และใบแจ้งหนี้ยังไม่ได้ชำระหรือไม่.
เรียกใช้ Script: เรียกใช้ script จากเทอร์มินัลด้วยคำสั่ง python your_script_name.py ระหว่างดึงข้อมูลใบแจ้งหนี้แต่ละรายการ script จะแสดงความคืบหน้าให้ทราบ.
ตรวจสอบผลลัพธ์: เมื่อทำงานเสร็จ ไฟล์ชื่อ oracle_fusion_ar_event_log.csv จะถูกสร้างในโฟลเดอร์เดียวกัน ไฟล์นี้มีบันทึกเหตุการณ์ที่ดึงมา.
เตรียมไฟล์สำหรับอัปโหลด: เปิดไฟล์ CSV ที่สร้างขึ้น ตรวจสอบว่าชื่อคอลัมน์เป็น CaseId, ActivityName และ EventTimestamp สำหรับแผนผังกระบวนการพื้นฐาน หรือจับคู่คอลัมน์ที่สร้างขึ้น เช่น InvoiceNumber, ActivityName, EventTimestamp, InvoiceAmount เป็นต้น ในเครื่องมือ process mining ระหว่างอัปโหลด.

การกำหนดค่า

URL หลักของ API: URL หลักของ Oracle Fusion Financials instance เช่น https://[your-pod].fa.em2.oraclecloud.com/fscmRestApi/resources/11.13.18.05.
การยืนยันตัวตน: Script ใช้ Basic Authentication ตรวจสอบว่าบัญชีผู้ใช้มีบทบาท เช่น 'Accounts Receivable Manager' หรือบทบาทที่กำหนดเองซึ่งมีสิทธิ์เข้าถึง REST resources receivablesInvoices, receivablesReceipts, receivablesReceiptApplications, receivablesAdjustments และ collectionsDelinquentTransactions.
ตัวกรองช่วงวันที่: Script ใช้พารามิเตอร์ q พร้อมตัวกรอง CreationDate เพื่อจำกัดชุดใบแจ้งหนี้เริ่มต้น แนะนำให้เริ่มจากช่วงสั้นๆ เช่น 3-6 เดือน เพื่อควบคุมเวลาดึงข้อมูลและภาระของ API ตัวอย่าง: CreationDate between 'YYYY-MM-DD' and 'YYYY-MM-DD'.
ขีดจำกัดการแบ่งหน้า: พารามิเตอร์ limit ในการเรียก API กำหนดจำนวนรายการที่ส่งกลับต่อคำขอ โดยทั่วไปค่า 100 ถึง 500 จะมีประสิทธิภาพเหมาะสม Script ตั้งค่าเริ่มต้นไว้แล้ว.
ตัวกรองหน่วยธุรกิจ: เพิ่มตัวกรองหน่วยธุรกิจในพารามิเตอร์ query (q) เพื่อจำกัดขอบเขตการดึงข้อมูลได้ เช่น BusinessUnitName = '[Your Business Unit Name]'.
ประสิทธิภาพ: การดึงข้อมูลทีละใบแจ้งหนี้อาจใช้เวลานานเมื่อมีข้อมูลจำนวนมาก เนื่องจาก script เรียก API หลายครั้งต่อใบแจ้งหนี้ หากมีใบแจ้งหนี้เกิน 100,000 รายการ ให้พิจารณาเรียกใช้ script เป็นชุดๆ หรือนอกช่วงเวลาที่มีการใช้งานสูง เพื่อหลีกเลี่ยงประสิทธิภาพที่ลดลงหรือการจำกัดอัตราการเรียก API.

ตัวอย่างคำค้น python

import requests
import pandas as pd
import datetime
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password
FUSION_URL = class="hl-string">"https://[your-pod].fa.em2.oraclecloud.com/fscmRestApi/resources/11.13.18.05"
USERNAME = class="hl-string">"YOUR_USERNAME"
PASSWORD = class="hl-string">"YOUR_PASSWORD"

class=class="hl-string">"hl-comment"># --- Filter Parameters ---
class=class="hl-string">"hl-comment"># Define the date range for the initial invoice query
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"
class=class="hl-string">"hl-comment"># Optional: Filter by a specific Business Unit
BUSINESS_UNIT_FILTER = class="hl-string">"" class=class="hl-string">"hl-comment"># e.g., class="hl-string">" and BusinessUnitName = 'US1 Business Unit'"

class=class="hl-string">"hl-comment"># API call settings
API_LIMIT = 100

def get_paginated_data(endpoint, params):
    class="hl-string">"""Helper function to handle pagination for Oracle Fusion REST API calls."""
    all_items = []
    url = fclass="hl-string">"{FUSION_URL}/{endpoint}"
    
    while url:
        try:
            response = requests.get(url, auth=(USERNAME, PASSWORD), params=params)
            response.raise_for_status()
            data = response.json()
            all_items.extend(data.get(class="hl-string">'items', []))
            
            class=class="hl-string">"hl-comment"># Get the next page link
            links = data.get(class="hl-string">'links', [])
            next_link = next((link[class="hl-string">'href'] for link in links if link[class="hl-string">'rel'] == class="hl-string">'next'), None)
            url = next_link
            class=class="hl-string">"hl-comment"># Params are only needed for the first request
            params = {}

        except requests.exceptions.HTTPError as e:
            print(fclass="hl-string">"HTTP Error fetching data from {url}: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Request Error: {e}")
            break
            
    return all_items


def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    event_log = []
    today = datetime.datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

    class=class="hl-string">"hl-comment"># 1. Fetch main invoice data
    print(class="hl-string">"Fetching invoices...")
    invoice_params = {
        class="hl-string">'q': fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'{BUSINESS_UNIT_FILTER}",
        class="hl-string">'fields': class="hl-string">'TransactionNumber,CreationDate,TransactionDate,CreatedBy,LastUpdateDate,LastUpdatedBy,Amount,AmountDueRemaining,Status,CompletedDate,CustomerName,DueDate,BusinessUnitName,ApprovalStatus,paymentSchedules,CustomerTransactionId',
        class="hl-string">'limit': API_LIMIT,
        class="hl-string">'expand': class="hl-string">'paymentSchedules'
    }
    invoices = get_paginated_data(class="hl-string">'receivablesInvoices', invoice_params)
    print(fclass="hl-string">"Found {len(invoices)} invoices.")

    class=class="hl-string">"hl-comment"># 2. Process each invoice to generate events
    for i, inv in enumerate(invoices):
        print(fclass="hl-string">"Processing invoice {i+1}/{len(invoices)}: {inv.get('TransactionNumber')}")
        
        case_id = inv.get(class="hl-string">'TransactionNumber')
        cust_trx_id = inv.get(class="hl-string">'CustomerTransactionId')
        common_attrs = {
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'InvoiceAmount': inv.get(class="hl-string">'Amount'),
            class="hl-string">'CustomerName': inv.get(class="hl-string">'CustomerName'),
            class="hl-string">'DueDate': inv.get(class="hl-string">'DueDate'),
            class="hl-string">'InvoiceStatus': inv.get(class="hl-string">'Status'),
            class="hl-string">'BusinessUnit': inv.get(class="hl-string">'BusinessUnitName')
        }

        class=class="hl-string">"hl-comment"># Event: Invoice Created
        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'CreationDate')})

        class=class="hl-string">"hl-comment"># Event: Invoice Completed
        if inv.get(class="hl-string">'CompletedDate'):
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Completed', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'CompletedDate')})
        
        class=class="hl-string">"hl-comment"># Events: Approval Cycle (based on final status)
        if inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'APPROVED':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Approved', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'REJECTED':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Rejected', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        elif inv.get(class="hl-string">'ApprovalStatus') == class="hl-string">'PENDING':
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Submitted for Approval', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        
        class=class="hl-string">"hl-comment"># Placeholder for class="hl-string">'Invoice Sent to Customer' - requires specific configuration
        class=class="hl-string">"hl-comment"># This might come from BI Publisher or another module. Using LastUpdateDate if status is class="hl-string">'COMPLETE' as an example.
        if inv.get(class="hl-string">'Status') == class="hl-string">'COMPLETE': class=class="hl-string">"hl-comment"># This is a proxy event
             event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})

        class=class="hl-string">"hl-comment"># Event: Payment Due Date Reached (calculated)
        if inv.get(class="hl-string">'DueDate') and inv.get(class="hl-string">'DueDate') < today and inv.get(class="hl-string">'AmountDueRemaining', 0) > 0:
            event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'DueDate')})

        class=class="hl-string">"hl-comment"># Event: Dispute Initiated
        for ps in inv.get(class="hl-string">'paymentSchedules', []):
            if ps.get(class="hl-string">'DisputeDate'):
                event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Dispute Initiated', class="hl-string">'EventTimestamp': ps.get(class="hl-string">'DisputeDate')})
                break class=class="hl-string">"hl-comment"># Assuming one dispute event per invoice for simplicity

        class=class="hl-string">"hl-comment"># Event: Invoice Closed
        if inv.get(class="hl-string">'AmountDueRemaining') == 0 and inv.get(class="hl-string">'Status') == class="hl-string">'CLOSED':
             event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Closed', class="hl-string">'EventTimestamp': inv.get(class="hl-string">'LastUpdateDate')})
        
        class=class="hl-string">"hl-comment"># 3. Fetch related events using other APIs
        if cust_trx_id:
            class=class="hl-string">"hl-comment"># Events: Payment Applied and Payment Received
            apps = get_paginated_data(class="hl-string">'receivablesReceipts', {class="hl-string">'q': fclass="hl-string">'AppliedCustomerTransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'ReceiptNumber,ReceiptDate,ActivityApplication.ApplyDate,ActivityApplication.AppliedCustomerTransactionId'})
            for app in apps:
                for activity_app in app.get(class="hl-string">'ActivityApplication', []):
                    if activity_app.get(class="hl-string">'AppliedCustomerTransactionId') == cust_trx_id:
                        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received', class="hl-string">'EventTimestamp': app.get(class="hl-string">'ReceiptDate')})
                        event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Applied to Invoice', class="hl-string">'EventTimestamp': activity_app.get(class="hl-string">'ApplyDate')})

            class=class="hl-string">"hl-comment"># Event: Invoice Adjusted
            adjustments = get_paginated_data(class="hl-string">'receivablesAdjustments', {class="hl-string">'q': fclass="hl-string">'CustomerTransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'ApplyDate'})
            for adj in adjustments:
                event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Adjusted', class="hl-string">'EventTimestamp': adj.get(class="hl-string">'ApplyDate')})

            class=class="hl-string">"hl-comment"># Event: Payment Reminder Issued (from Delinquency data)
            reminders = get_paginated_data(class="hl-string">'collectionsDelinquentTransactions', {class="hl-string">'q': fclass="hl-string">'TransactionId={cust_trx_id}', class="hl-string">'onlyData': class="hl-string">'true', class="hl-string">'fields': class="hl-string">'LastDunningLetterDate'})
            for rem in reminders:
                if rem.get(class="hl-string">'LastDunningLetterDate'):
                    event_log.append({**common_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued', class="hl-string">'EventTimestamp': rem.get(class="hl-string">'LastDunningLetterDate')})

    class=class="hl-string">"hl-comment"># 4. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events generated. Exiting.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTimestamp'])
    class=class="hl-string">"hl-comment"># Ensure required columns are present
    df_final = df[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'DueDate', class="hl-string">'InvoiceStatus', class="hl-string">'BusinessUnit']]

    output_filename = class="hl-string">'oracle_fusion_ar_event_log.csv'
    df_final.to_csv(output_filename, index=False)
    print(fclass="hl-string">"\nEvent log successfully saved to {os.path.abspath(output_filename)}")

if __name__ == class="hl-string">'__main__':
    main()

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

ใช้เทมเพลตนี้เตรียมข้อมูลและปรับปรุงกระบวนการวางบิลและออกใบแจ้งหนี้ เพื่อให้เปลี่ยนยอดขายเป็นเงินสดได้เร็วขึ้น ดูข้อมูลเชิงลึกและเพิ่มประสิทธิภาพการปฏิบัติการใน Oracle Fusion Financials ได้เลย.

กลับไปยังคู่มือการปรับปรุง

ดาวน์โหลดเทมเพลต

เริ่มปรับปรุงการวางบิลและออกใบแจ้งหนี้ใน Oracle ได้เลย

ลดระยะเวลารอบการวางบิลลง 30% และเพิ่มกระแสเงินสดด้วยโซลูชันของเรา.

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

ไม่ต้องใช้บัตรเครดิต ตั้งค่าได้ในไม่กี่นาที.

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

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

แอตทริบิวต์ของกระบวนการตั้งแต่รับคำสั่งซื้อจนถึงรับชำระเงิน: การวางบิลและออกใบแจ้งหนี้

กิจกรรมในกระบวนการตั้งแต่รับคำสั่งซื้อจนถึงรับชำระเงิน: การวางบิลและออกใบแจ้งหนี้

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

รายงาน Oracle BI Publisher สำหรับข้อมูลการวางบิลและออกใบแจ้งหนี้

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น sql

ดึงข้อมูลด้วย Python Script ผ่าน Oracle Fusion REST APIs

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น python

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

เริ่มปรับปรุงการวางบิลและออกใบแจ้งหนี้ใน Oracle ได้เลย