> การปรับปรุงกระบวนการอย่างต่อเนื่อง > จัดซื้อจนถึงชำระเงิน: ใบขอซื้อ > Oracle Fusion Financials > เทมเพลตข้อมูล

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

Oracle Fusion Financials

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

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

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

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

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

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

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

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

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

	ชื่อ	คำอธิบาย
	กิจกรรม ActivityName	ชื่อเหตุการณ์ทางธุรกิจที่เกิดขึ้น ณ จุดหนึ่งในกระบวนการจัดทำคำขอซื้อ.
คำอธิบาย กิจกรรมหมายถึงขั้นตอนหรือหมุดหมายที่แยกจากกันในวงจรชีวิตของใบขอซื้อ เช่น 'สร้างใบขอซื้อ', 'อนุมัติขั้นตอนการอนุมัติ' หรือ 'สร้างใบสั่งซื้อ' ข้อมูลกิจกรรมได้มาจากการเปลี่ยนสถานะ การดำเนินการของผู้ใช้ หรือเหตุการณ์ในระบบที่บันทึกไว้ในบันทึกการตรวจสอบหรือในตารางธุรกรรมของระบบต้นทาง แอตทริบิวต์นี้จำเป็นต่อการสร้างแผนผังกระบวนการ ซึ่งแสดงลำดับการทำงานของใบขอซื้อ การวิเคราะห์ลำดับและความถี่ของกิจกรรมช่วยระบุเส้นทางที่เกิดขึ้นบ่อย คอขวด งานที่ต้องทำซ้ำ และความเบี่ยงเบนจากขั้นตอนมาตรฐาน เหตุผลที่สำคัญ แอตทริบิวต์นี้เป็นแกนหลักของแผนผังกระบวนการ ช่วยให้เห็นภาพและวิเคราะห์เวิร์กโฟลว์ของคำขอซื้อได้. แหล่งข้อมูล ดึงข้อมูลจากรายการเปลี่ยนสถานะในตาราง เช่น POR_REQUISITION_HEADERS_ALL ประวัติธุรกรรม หรือบันทึกการตรวจสอบเวิร์กโฟลว์ เช่น FA_FUSION_SOAINFRA.WFTASK. ตัวอย่าง สร้างใบขอซื้ออนุมัติขั้นตอนการอนุมัติปฏิเสธใบขอซื้อสร้างใบสั่งซื้อ
	รหัสใบขอซื้อ PurchaseRequisitionId	รหัสเฉพาะของใบขอซื้อ ซึ่งใช้เป็นรหัสกรณีของกระบวนการ.
คำอธิบาย Purchase Requisition ID คือรหัสหลักที่ใช้เชื่อมโยงกิจกรรมทั้งหมดของคำขอซื้อสินค้า或บริการแต่ละรายการ ระบบกำหนดรหัสที่ไม่ซ้ำกันให้เมื่อสร้างคำขอ และรหัสนี้จะคงเดิมตลอดอายุของคำขอ ใน process mining ระบบใช้แอตทริบิวต์นี้จัดกลุ่มเหตุการณ์ที่เกี่ยวข้องกัน เช่น การสร้างคำขอ การส่งคำขอ ขั้นตอนการอนุมัติ และการปิดคำขอ ให้เป็นเคสเดียวกัน จึงวิเคราะห์เส้นทางของคำขอได้ตั้งแต่ต้นจนจบ ทั้งการแสดงแผนผังกระบวนการ การคำนวณระยะเวลาดำเนินการ และการวิเคราะห์รูปแบบกระบวนการของคำขอแต่ละรายการ. เหตุผลที่สำคัญ แอตทริบิวต์นี้เป็นพื้นฐานสำหรับติดตามวงจรชีวิตของคำขอตั้งแต่ต้นจนจบ และใช้วิเคราะห์ระดับเคสรวมถึงคำนวณ KPI ได้. แหล่งข้อมูล โดยทั่วไปจะเป็นคีย์หลักในตารางส่วนหัวของคำขอ เช่น POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID ใน Oracle Fusion Financials. ตัวอย่าง 100234810023491002350
	เวลาที่เกิดเหตุการณ์ EventTime	วันและเวลาที่ระบุว่ากิจกรรมเกิดขึ้นเมื่อใด.
คำอธิบาย เวลาที่เกิดเหตุการณ์คือวันที่และเวลาที่กิจกรรมหนึ่งเกิดขึ้นอย่างแม่นยำ การประทับเวลานี้เป็นข้อมูลพื้นฐานสำหรับเรียงเหตุการณ์ในเคสตามลำดับเวลา โดยดึงจากวันที่สร้าง วันที่อัปเดตล่าสุด หรือเวลาที่บันทึกการดำเนินการเฉพาะไว้ในระบบ ในการวิเคราะห์ จะใช้เวลาที่เกิดเหตุการณ์คำนวณตัวชี้วัดตามระยะเวลา เช่น รอบเวลาดำเนินการระหว่างกิจกรรม เวลารอ และระยะเวลารวมของเคส ข้อมูลนี้สำคัญต่อการระบุคอขวด วัดผลเทียบกับ SLA และทำความเข้าใจการเปลี่ยนแปลงตามเวลาของกระบวนการใบขอซื้อ เหตุผลที่สำคัญ แอตทริบิวต์นี้จำเป็นต่อการคำนวณ KPI ด้านเวลา การเรียงเหตุการณ์ให้ถูกต้อง และการวิเคราะห์ประสิทธิภาพกับคอขวดของกระบวนการ. แหล่งข้อมูล โดยทั่วไปดึงจากคอลัมน์ 'LAST_UPDATE_DATE' หรือ 'CREATION_DATE' ที่เกี่ยวข้องกับธุรกรรมหรือการเปลี่ยนสถานะ ซึ่งมักอยู่ในตาราง เช่น POR_REQUISITION_HEADERS_ALL หรือตารางประวัติเวิร์กโฟลว์. ตัวอย่าง 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	ระบบต้นทาง SourceSystem	ระบบสารสนเทศที่ใช้ดึงข้อมูลนี้.
คำอธิบาย แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูลกระบวนการ สำหรับโมเดลข้อมูลนี้ ค่าจะเป็น 'Oracle Fusion Financials' เสมอ ในองค์กรที่ใช้ ERP หลายระบบหรือเชื่อมต่อหลายระบบ ฟิลด์นี้สำคัญต่อการติดตามที่มาของข้อมูล การแก้ไขปัญหา และการตรวจสอบคุณภาพข้อมูล อีกทั้งยังช่วยให้ทราบว่าข้อมูลเหตุการณ์ที่นำมาวิเคราะห์มาจากระบบใด. เหตุผลที่สำคัญ ช่วยให้ทราบแหล่งที่มาของข้อมูล ซึ่งจำเป็นต่อการกำกับดูแลข้อมูลและการรวมข้อมูลจากหลายระบบ. แหล่งข้อมูล เป็นค่าคงที่ที่เพิ่มระหว่างการดึงและแปลงข้อมูล เพื่อระบุแหล่งที่มาของชุดข้อมูล. ตัวอย่าง Oracle Fusion Financials
	อัปเดตข้อมูลล่าสุด LastDataUpdate	วันและเวลาที่ดึงข้อมูลจากระบบต้นทางครั้งล่าสุด.
คำอธิบาย แอตทริบิวต์นี้ระบุวันและเวลาที่ดึงข้อมูลจาก Oracle Fusion Financials ครั้งล่าสุด โดยใช้กับชุดข้อมูลทั้งหมด ไม่ใช่เหตุการณ์แต่ละรายการ นักวิเคราะห์ใช้ข้อมูลนี้ตรวจสอบความใหม่ของข้อมูลและยืนยันว่ารวมธุรกรรมล่าสุดแล้วหรือไม่ ข้อมูลเมตานี้สำคัญต่อการรายงานบนแดชบอร์ดและช่วยให้มั่นใจว่าการวิเคราะห์อ้างอิงข้อมูลที่เป็นปัจจุบัน. เหตุผลที่สำคัญ ช่วยให้ผู้ใช้ทราบว่าข้อมูลเป็นข้อมูลล่าสุดเพียงใด เพื่อให้การวิเคราะห์ยังเกี่ยวข้องและอ้างอิงข้อมูลที่มีอยู่ล่าสุด. แหล่งข้อมูล ระบบสร้างและจัดเก็บเวลานี้ระหว่างการดึงข้อมูล โดยทั่วไปจะบันทึกผ่านเครื่องมือ ETL หรือ data pipeline. ตัวอย่าง 2023-10-27T02:00:00Z
	ชื่อผู้ขอซื้อ RequesterName	ชื่อพนักงานที่สร้างและส่งคำขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้ระบุผู้เริ่มขอซื้อสินค้าหรือบริการ โดยทั่วไปจะบันทึกข้อมูลนี้ตั้งแต่ต้นกระบวนการ เมื่อสร้างคำขอซื้อ การวิเคราะห์ประสิทธิภาพตามผู้ขอซื้อมีความสำคัญต่อแดชบอร์ด 'ตัวชี้วัดประสิทธิภาพผู้ขอซื้อ' ช่วยระบุผู้ใช้หรือกลุ่มที่อาจต้องได้รับการฝึกอบรมเพิ่มเติม โดยดูจากอัตราการแก้ไขหรือปฏิเสธคำขอที่สูง หรือระยะเวลาดำเนินการที่นาน นอกจากนี้ยังช่วยให้เห็นภาพกระบวนการจากมุมของผู้ปฏิบัติงาน. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพตามผู้ขอซื้อ ระบุความต้องการด้านการฝึกอบรม และเห็นผู้ใช้หรือแผนกที่ดำเนินงานได้มีประสิทธิภาพ. แหล่งข้อมูล ดึงจากข้อมูลส่วนหัวของคำขอซื้อ โดยมักเชื่อม ID ของผู้ขอซื้อกับตารางข้อมูลพนักงานหรือผู้ใช้ ให้ค้นหาฟิลด์ที่เกี่ยวข้องกับ 'PREPARER_ID' ใน POR_REQUISITION_HEADERS_ALL แล้วเชื่อมกับ PER_ALL_PEOPLE_F. ตัวอย่าง จอห์น สมิธเจน โดเอมิลี โจนส์
	แผนก DepartmentName	แผนกที่ผู้ขอซื้อสังกัดอยู่.
คำอธิบาย แอตทริบิวต์นี้ระบุหน่วยงานของผู้สร้างคำขอซื้อ เช่น 'การเงิน', 'ไอที' หรือ 'การตลาด' โดยทั่วไปจะดึงจากโปรไฟล์ผู้ขอซื้อในระบบ HR การวิเคราะห์แยกตามแผนกเป็นวิธีที่ใช้แบ่งกลุ่มข้อมูลกระบวนการ ช่วยให้เห็นรูปแบบเฉพาะของแต่ละแผนก เช่น อัตราการปฏิเสธที่สูงหรือระยะเวลาดำเนินการที่นานขึ้น และนำข้อมูลไปวางแผนปรับปรุงกระบวนการให้ตรงจุดได้ แอตทริบิวต์นี้ยังเป็นมิติสำคัญของแดชบอร์ด 'ตัวชี้วัดประสิทธิภาพผู้ขอซื้อ'. เหตุผลที่สำคัญ ช่วยวิเคราะห์กระบวนการแยกตามหน่วยธุรกิจ เพื่อให้เห็นรูปแบบ ประสิทธิภาพ และปัญหาการปฏิบัติตามข้อกำหนดของแต่ละแผนก. แหล่งข้อมูล โดยทั่วไปดึงจากโปรไฟล์ของผู้ขอซื้อ ซึ่งอาจต้องเชื่อมตารางคำขอซื้อกับตาราง HR หรือไดเรกทอรีผู้ใช้ที่มีข้อมูลแผนก. ตัวอย่าง เทคโนโลยีสารสนเทศการเงินการปฏิบัติการการตลาด
	ยอดรวมคำขอซื้อ RequisitionTotalAmount	มูลค่ารวมของคำขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้แสดงผลรวมมูลค่าของรายการสินค้าทั้งหมดในคำขอซื้อหนึ่งรายการ เป็นข้อมูลสำคัญที่ช่วยให้เข้าใจความสำคัญด้านการเงินของแต่ละคำขอ ใน process mining สามารถใช้ยอดรวมเพื่อวิเคราะห์ได้หลายรูปแบบ เช่น กรองคำขอซื้อที่มีมูลค่าสูง ซึ่งมักมีเส้นทางการอนุมัติหรือการตรวจสอบที่เข้มงวดกว่า แดชบอร์ดยังใช้แอตทริบิวต์นี้วิเคราะห์ความสัมพันธ์ระหว่างตัวชี้วัดกระบวนการ เช่น ระยะเวลาดำเนินการหรืออัตราการปฏิเสธ กับมูลค่าของคำขอซื้อได้. เหตุผลที่สำคัญ ช่วยให้เห็นบริบทด้านการเงิน วิเคราะห์ตามมูลค่าเพื่อจัดลำดับความสำคัญในการปรับปรุงกระบวนการ และทำความเข้าใจว่ามูลค่าคำขอซื้อส่งผลต่อรูปแบบการดำเนินงานอย่างไร. แหล่งข้อมูล อยู่ในส่วนหัวของคำขอซื้อ โดยมักอยู่ในฟิลด์ เช่น REQUISITION_TOTAL ใน POR_REQUISITION_HEADERS_ALL หรือคำนวณจากผลรวมมูลค่ารายการใน POR_REQUISITION_LINES_ALL. ตัวอย่าง 550.0012500.7599.99
	วันที่ต้องการสินค้า RequiredByDate	วันที่ผู้ขอต้องการได้รับสินค้าหรือบริการ.
คำอธิบาย ผู้ขอซื้อระบุวันที่นี้เพื่อกำหนดกำหนดเวลาที่ต้องการได้รับสินค้าที่ขอ โดยใช้เป็นเป้าหมาย SLA ภายในสำหรับกระบวนการจัดซื้อ แอตทริบิวต์นี้เป็นข้อมูลพื้นฐานของแดชบอร์ด 'ประสิทธิภาพตามวันที่ต้องการรับสินค้า' และ KPI 'อัตราการส่งมอบตามวันที่ต้องการ' เมื่อนำวันที่นี้ไปเปรียบเทียบกับวันที่สร้างใบสั่งซื้อหรือวันที่รับสินค้า การวิเคราะห์จะแสดงให้เห็นว่ากระบวนการจัดซื้อรองรับความต้องการของผู้ใช้ภายในได้ดีเพียงใด และช่วยระบุความล่าช้าที่เกิดขึ้นเป็นประจำ. เหตุผลที่สำคัญ จำเป็นต่อการวัดผลกระบวนการเทียบกับกำหนดเวลาภายใน และตรวจสอบว่ากระบวนการจัดซื้อรองรับความต้องการทางธุรกิจได้ทันเวลาหรือไม่. แหล่งข้อมูล โดยทั่วไปจัดเก็บไว้ในระดับรายการสินค้าในคำขอซื้อ ในตาราง เช่น POR_REQUISITION_LINES_ALL ภายใต้ฟิลด์อย่าง 'NEED_BY_DATE'. ตัวอย่าง 2023-11-012023-12-152024-01-31
	สถานะคำขอซื้อ RequisitionStatus	สถานะปัจจุบันหรือสถานะสุดท้ายของคำขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้ระบุสถานะโดยรวมของคำขอซื้อ ณ เวลาหนึ่งหรือผลลัพธ์สุดท้าย เช่น 'อนุมัติแล้ว', 'ปฏิเสธแล้ว', 'กำลังดำเนินการ' หรือ 'ปิดแล้ว' โดยมักใช้เป็นแหล่งข้อมูลสำหรับสร้างกิจกรรมหลายรายการในบันทึกเหตุการณ์ แอตทริบิวต์นี้เป็นข้อมูลหลักของแดชบอร์ด 'ภาพรวมสถานะคำขอซื้อ' ซึ่งแสดงปริมาณงานและงานค้างในปัจจุบัน นอกจากนี้ยังใช้คำนวณ KPI ตามผลลัพธ์ เช่น อัตราการปฏิเสธคำขอซื้อ โดยกรองเคสที่สิ้นสุดด้วยสถานะที่กำหนด. เหตุผลที่สำคัญ แสดงสถานะปัจจุบันของคำขอซื้อ และใช้ระบุผลลัพธ์สุดท้ายเพื่อคำนวณ KPI. แหล่งข้อมูล อยู่ในตารางส่วนหัวของคำขอซื้อ โดยทั่วไปอยู่ในฟิลด์ เช่น 'DOCUMENT_STATUS' หรือ 'APPROVAL_STATUS' ใน POR_REQUISITION_HEADERS_ALL. ตัวอย่าง อนุมัติแล้วกำลังดำเนินการถูกปฏิเสธถอนคำขอแล้ว
	หน่วยธุรกิจ BusinessUnit	หน่วยธุรกิจเฉพาะภายในองค์กรที่เป็นเจ้าของคำขอซื้อ.
คำอธิบาย Business Unit คือหน่วยงานทางกฎหมายหรือหน่วยงานตามหน้าที่ภายในบริษัทที่จัดทำคำขอซื้อ โดยเป็นกลุ่มองค์กรระดับสูงกว่าแผนก การวิเคราะห์ข้อมูลแยกตาม Business Unit ช่วยเปรียบเทียบประสิทธิภาพในส่วนต่างๆ ขององค์กรในภาพรวม ผู้บริหารจึงเห็นได้ว่าความไม่มีประสิทธิภาพเกิดเฉพาะบางส่วนหรือเกิดทั่วทั้งองค์กร และควรมุ่งปรับปรุงจุดใด แอตทริบิวต์นี้ยังเป็นมิติสำคัญสำหรับใช้กรองข้อมูลในแดชบอร์ดและ KPI เกือบทุกรายการ. เหตุผลที่สำคัญ ให้บริบทองค์กรในภาพรวม ช่วยเปรียบเทียบประสิทธิภาพและวิเคราะห์เชิงกลยุทธ์ระหว่างส่วนต่างๆ ขององค์กร. แหล่งข้อมูล เป็นฟิลด์พื้นฐานด้านองค์กรใน Oracle Fusion โดยทั่วไปมีอยู่ในส่วนหัวของคำขอซื้อในตาราง เช่น POR_REQUISITION_HEADERS_ALL. ตัวอย่าง หน่วยธุรกิจอเมริกาเหนือหน่วยธุรกิจยุโรปสำนักงานใหญ่บริษัท
	เหตุผลที่ปฏิเสธ RejectionReason	เหตุผลที่ผู้อนุมัติระบุเมื่อปฏิเสธคำขอซื้อหรือขั้นตอนการอนุมัติ.
คำอธิบาย เมื่อคำขอซื้อถูกปฏิเสธ ผู้อนุมัติมักระบุเหตุผลด้วยการเลือกจากรายการที่กำหนดไว้หรือพิมพ์ข้อความเอง แอตทริบิวต์นี้จะบันทึกคำชี้แจงดังกล่าว ข้อมูลนี้สำคัญต่อการวิเคราะห์หาสาเหตุที่แท้จริงของปัญหาในกระบวนการ และรองรับแดชบอร์ด 'แนวโน้มการแก้ไขและการปฏิเสธ' โดยแสดงเหตุผลเบื้องหลังการปฏิเสธ การวิเคราะห์เหตุผลช่วยให้เห็นปัญหาที่พบบ่อย เช่น การลงรหัสบัญชีไม่ถูกต้อง การใช้จ่ายเกินงบ หรือการไม่ปฏิบัติตามนโยบาย จากนั้นจึงแก้ไขได้ด้วยการฝึกอบรมหรือการควบคุมในระบบ. เหตุผลที่สำคัญ แสดงเหตุผลที่คำขอซื้อถูกปฏิเสธโดยตรง ช่วยให้ปรับปรุงได้ตรงจุด ลดการแก้ไขงานซ้ำ และเพิ่มอัตราการดำเนินการโดยไม่ต้องแทรกแซง. แหล่งข้อมูล ดึงจากความคิดเห็นในเวิร์กโฟลว์หรือฟิลด์รหัสเหตุผลการปฏิเสธใน audit trail ของเวิร์กโฟลว์ ซึ่งอาจอยู่ในตารางที่เกี่ยวข้องกับ FA_FUSION_SOAINFRA.WFTASK หรือตารางจัดเก็บความคิดเห็นที่เชื่อมโยงกัน. ตัวอย่าง บัญชี GL ไม่ถูกต้องเกินงบประมาณของศูนย์ต้นทุนเลือกซัพพลายเออร์ที่ไม่ใช่รายที่แนะนำคำขอซ้ำ
	ชื่อซัพพลายเออร์ SupplierName	ชื่อผู้ขายที่แนะนำหรือเลือกไว้ล่วงหน้าสำหรับสินค้าและบริการ.
คำอธิบาย แอตทริบิวต์นี้ระบุผู้ขายที่คาดว่าจะจัดซื้อสินค้าหรือบริการด้วย ผู้ขอซื้ออาจเป็นผู้แนะนำผู้ขาย หรือระบบอาจกำหนดจากแค็ตตาล็อกหรือข้อตกลงเดิม การวิเคราะห์แยกตามผู้ขายช่วยให้เห็นรูปแบบการจัดซื้อที่สำคัญ เช่น คำขอซื้อจากผู้ขายบางรายใช้เวลาอนุมัตินานกว่าหรือมีอัตราการปฏิเสธสูงกว่าหรือไม่ ข้อมูลนี้มีประโยชน์ต่อการบริหารความสัมพันธ์กับผู้ขายและการวางกลยุทธ์การจัดซื้อ. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพกระบวนการแยกตามผู้ขาย เพื่อนำไปใช้วางกลยุทธ์การจัดหาและบริหารความสัมพันธ์กับผู้ขาย. แหล่งข้อมูล อยู่ในตารางรายการคำขอซื้อ POR_REQUISITION_LINES_ALL โดยมักเชื่อมผ่าน VENDOR_ID กับตารางข้อมูลหลักของผู้ขาย เช่น POZ_SUPPLIERS. ตัวอย่าง Office Supplies Inc.โกลบอลเทคโซลูชันส์เอเจนซีครีเอทีฟมาร์เก็ตติง
	ชื่อผู้ใช้ UserName	ชื่อผู้ใช้ที่ดำเนินกิจกรรม เช่น ผู้อนุมัติหรือผู้แก้ไข.
คำอธิบาย ชื่อผู้ขอซื้อระบุผู้เริ่มต้นคำขอ ส่วน User Name ระบุผู้ดำเนินการในเหตุการณ์หนึ่ง เช่น การอนุมัติหรือปฏิเสธ ข้อมูลนี้สำคัญเป็นพิเศษกับเวิร์กโฟลว์การอนุมัติหลายขั้นตอนที่มีผู้เกี่ยวข้องหลายคน แอตทริบิวต์นี้ช่วยวิเคราะห์คอขวดในการอนุมัติและวัดประสิทธิภาพของผู้อนุมัติหรือทีมต่างๆ ได้โดยตรง อีกทั้งยังรองรับแดชบอร์ด 'คอขวดในเวิร์กโฟลว์การอนุมัติ' โดยช่วยวิเคราะห์เวลาที่ใช้ดำเนินการของผู้ใช้แต่ละคนในสายการอนุมัติ. เหตุผลที่สำคัญ ระบุผู้ดำเนินการในแต่ละเหตุการณ์ ซึ่งจำเป็นต่อการวิเคราะห์เวลาส่งต่องาน ประสิทธิภาพของผู้อนุมัติ และการจัดสรรทรัพยากร. แหล่งข้อมูล ดึงจากประวัติเวิร์กโฟลว์หรือตาราง audit trail เช่น FA_FUSION_SOAINFRA.WFTASK ซึ่งบันทึกผู้ใช้ที่เกี่ยวข้องกับการทำงานแต่ละรายการจนเสร็จ. ตัวอย่าง เดวิด ลีซูซาน เฉินไมเคิล บราวน์
	ดำเนินการโดยอัตโนมัติหรือไม่ IsAutomated	แฟล็กที่ระบุว่าระบบดำเนินกิจกรรมโดยอัตโนมัติหรือไม่.
คำอธิบาย แอตทริบิวต์นี้ระบุเหตุการณ์ในกระบวนการที่ดำเนินการโดยผู้ใช้ระบบหรือตัวแทนอัตโนมัติ แทนที่จะเป็นบุคคล ตัวอย่างเช่น การเปลี่ยนสถานะที่ระบบดำเนินการ หรือการอนุมัติอัตโนมัติสำหรับรายการมูลค่าต่ำ การวิเคราะห์แอตทริบิวต์นี้ช่วยวัดระดับการทำงานอัตโนมัติในกระบวนการ และใช้เปรียบเทียบความเร็วและประสิทธิภาพของขั้นตอนอัตโนมัติกับขั้นตอนที่ทำด้วยตนเอง รวมถึงระบุโอกาสในการเพิ่มงานอัตโนมัติ. เหตุผลที่สำคัญ ช่วยวัดระดับการทำงานอัตโนมัติในกระบวนการ และระบุงานที่ทำด้วยตนเองซึ่งอาจทำให้เป็นอัตโนมัติได้. แหล่งข้อมูล ตรวจสอบว่าผู้ใช้ที่เกี่ยวข้องกับกิจกรรมเป็นบัญชีระบบหรือบัญชีบริการหรือไม่ โดยต้องมีรายชื่อ ID ผู้ใช้ระบบที่ทราบอยู่แล้ว. ตัวอย่าง truefalse
	ดำเนินการต่อเนื่องโดยไม่ต้องแทรกแซงหรือไม่ IsStraightThrough	แฟล็กที่ระบุว่าคำขอซื้อได้รับอนุมัติโดยไม่มีการแก้ไขหรือการปฏิเสธหรือไม่.
คำอธิบาย แฟล็กที่คำนวณนี้ระบุคำขอซื้อที่ผ่านกระบวนการตั้งแต่ส่งจนถึงอนุมัติโดยไม่มีการวนกลับไปทำงานซ้ำ เช่น การแก้ไขหรือการปฏิเสธ ซึ่งหมายถึงเคสนั้นดำเนินการได้ตามขั้นตอนอย่างสมบูรณ์ แอตทริบิวต์นี้เป็นพื้นฐานของ KPI 'อัตราคำขอซื้อที่ดำเนินการได้โดยไม่ต้องแทรกแซง' การวิเคราะห์ลักษณะของคำขอซื้อที่ดำเนินการได้โดยไม่ต้องแทรกแซง เช่น แผนก ผู้ขอซื้อ หรือประเภทคำขอที่พบบ่อย อาจช่วยให้เห็นแนวทางปฏิบัติที่ดีและโอกาสในการทำงานอัตโนมัติ ส่วนการวิเคราะห์คำขอซื้อที่ต้องแก้ไขงานซ้ำจะช่วยชี้สาเหตุหลักของความไม่มีประสิทธิภาพ. เหตุผลที่สำคัญ วัดประสิทธิภาพกระบวนการโดยตรง และเป็นพื้นฐานของ KPI อัตราคำขอซื้อที่ดำเนินการได้โดยไม่ต้องแทรกแซง ช่วยระบุสาเหตุของการทำงานซ้ำ. แหล่งข้อมูล แอตทริบิวต์นี้คำนวณระหว่างการแปลงข้อมูล โดยกำหนดค่าเป็นจริงให้เคสที่ไม่มีกิจกรรม 'แก้ไขคำขอซื้อแล้ว' หรือ 'ปฏิเสธขั้นตอนการอนุมัติ'. ตัวอย่าง truefalse
	ประเภทคำขอซื้อ RequisitionType	หมวดหมู่ของคำขอซื้อ เช่น คำขอสินค้า หรือบริการ.
คำอธิบาย แอตทริบิวต์นี้จัดประเภทคำขอตามสิ่งที่ต้องการซื้อ ประเภทที่พบบ่อย ได้แก่ สินค้า บริการ หรือรายจ่ายลงทุน ประเภทคำขออาจมีผลต่อเวิร์กโฟลว์การอนุมัติและแนวทางการจัดซื้อ ในการวิเคราะห์ ประเภทคำขอซื้อใช้แบ่งกลุ่มและเปรียบเทียบข้อมูลได้ เช่น ตรวจสอบว่าคำขอบริการใช้เวลาอนุมัตินานกว่าคำขอสินค้าหรือไม่ และทำความเข้าใจว่าคำขอแต่ละประเภทมีรูปแบบการดำเนินงานหรือคอขวดต่างกันอย่างไร. เหตุผลที่สำคัญ ช่วยแบ่งการวิเคราะห์เพื่อดูว่ากระบวนการแตกต่างกันอย่างไรตามประเภทการซื้อ เช่น สินค้าหรือบริการ. แหล่งข้อมูล โดยทั่วไปกำหนดจากประเภทหรือหมวดหมู่รายการที่เลือกตอนสร้างคำขอซื้อ และอาจจัดเก็บในตารางรายการคำขอซื้อ POR_REQUISITION_LINES_ALL. ตัวอย่าง สินค้าบริการรายจ่ายลงทุน
	มีการแก้ไขหรือไม่ IsAmendedFlag	แฟล็กแบบบูลีนที่มีค่าเป็นจริงเมื่อมีการแก้ไขคำขอซื้ออย่างน้อยหนึ่งครั้ง.
คำอธิบาย แอตทริบิวต์ที่คำนวณนี้ระบุว่ามีการเปลี่ยนแปลงคำขอซื้อหลังจากส่งครั้งแรกหรือไม่ โดยตรวจสอบว่ามีกิจกรรม 'แก้ไขคำขอซื้อแล้ว' ในประวัติของเคสหรือไม่ แฟล็กนี้ช่วยให้วิเคราะห์และคำนวณ KPI ได้ง่ายขึ้น ใช้คำนวณ KPI 'อัตราการแก้ไขคำขอซื้อ' โดยตรง และระบุเคสที่ไม่ได้ดำเนินการต่อเนื่องโดยไม่ต้องแก้ไขงานซ้ำ นอกจากนี้ยังใช้กรองและเปรียบเทียบตัวชี้วัดกระบวนการระหว่างคำขอซื้อที่มีและไม่มีการแก้ไขได้. เหตุผลที่สำคัญ ช่วยคำนวณอัตราการแก้ไข และเปรียบเทียบคำขอซื้อที่มีการแก้ไขกับคำขอซื้อที่ไม่มีการแก้ไขได้ง่าย. แหล่งข้อมูล แอตทริบิวต์นี้ไม่มีในระบบต้นทาง แต่คำนวณระหว่างการแปลงข้อมูลจากการตรวจสอบกิจกรรมที่เกี่ยวข้องกับการแก้ไขในบันทึกเหตุการณ์. ตัวอย่าง truefalse
	รายละเอียดสินค้า ItemDescription	รายละเอียดของสินค้าหรือบริการที่ขอซื้อในรายการคำขอ.
คำอธิบาย แอตทริบิวต์นี้เก็บรายละเอียดข้อความของสินค้าที่ต้องการจัดซื้อ โดยระบุข้อมูลเฉพาะของสินค้าหรือบริการที่ขอ แม้ข้อมูลมักไม่ได้จัดโครงสร้างไว้ แต่รายละเอียดสินค้าก็ช่วยเพิ่มบริบทในการวิเคราะห์ได้ คุณสามารถใช้ตัวกรองเพื่อค้นหาคำขอซื้อสินค้าบางประเภทที่อาจไม่ปรากฏในประเภทคำขอซื้อ เช่น ค้นหาคำขอซื้อที่มีคำว่า 'ใบอนุญาตซอฟต์แวร์' เพื่อทำความเข้าใจเส้นทางกระบวนการและระยะเวลาดำเนินการของรายการเหล่านั้น. เหตุผลที่สำคัญ ให้รายละเอียดว่าสิ่งที่จัดซื้อคืออะไร ช่วยกรองและวิเคราะห์สินค้าหรือบริการแต่ละประเภทได้ละเอียดขึ้น. แหล่งข้อมูล อยู่ในตารางรายการคำขอซื้อ POR_REQUISITION_LINES_ALL ในฟิลด์ เช่น ITEM_DESCRIPTION. ตัวอย่าง แล็ปท็อป 15 นิ้ว, RAM 16GBบริการที่ปรึกษา, โครงการไตรมาส 4ต่ออายุบริการบำรุงรักษาซอฟต์แวร์รายปี
	สกุลเงิน CurrencyCode	รหัสสกุลเงินของยอดคำขอซื้อ เช่น USD หรือ EUR.
คำอธิบาย แอตทริบิวต์นี้ระบุสกุลเงินที่ใช้แสดงยอดรวมคำขอซื้อ องค์กรระดับโลกอาจสร้างคำขอซื้อด้วยสกุลเงินหลายประเภท ข้อมูลนี้จำเป็นต่อการตีความและรวมข้อมูลทางการเงินให้ถูกต้อง เมื่อต้องวิเคราะห์มูลค่าเงิน ต้องใช้รหัสสกุลเงินเพื่อเปรียบเทียบยอดได้อย่างถูกต้อง โดยกรองให้เหลือสกุลเงินเดียวหรือแปลงยอดทั้งหมดเป็นสกุลเงินเดียวกัน. เหตุผลที่สำคัญ ช่วยให้วิเคราะห์และรายงานข้อมูลทางการเงินได้ถูกต้อง โดยเฉพาะองค์กรข้ามชาติที่ใช้หลายสกุลเงิน. แหล่งข้อมูล โดยทั่วไปอยู่ในตารางส่วนหัวของคำขอซื้อร่วมกับฟิลด์ยอดเงิน เช่น POR_REQUISITION_HEADERS_ALL. ตัวอย่าง USDEURGBPJPY
	เส้นทางเวิร์กโฟลว์การอนุมัติ ApprovalWorkflowPath	ลำดับผู้อนุมัติหรือกลุ่มผู้อนุมัติที่กำหนดไว้สำหรับคำขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้ระบุขั้นตอนการอนุมัติมาตรฐานที่คาดว่าจะใช้กับคำขอซื้อแต่ละรายการตามนโยบายบริษัท โดยพิจารณาปัจจัยต่างๆ เช่น มูลค่า ประเภทคำขอ และแผนก ซึ่งแสดงถึงโมเดลกระบวนการที่ควรเป็น เส้นทางเวิร์กโฟลว์การอนุมัติเป็นข้อมูลสำคัญสำหรับการวิเคราะห์การปฏิบัติตามข้อกำหนดและความสอดคล้องของกระบวนการ รองรับแดชบอร์ด 'การวิเคราะห์การปฏิบัติตามข้อกำหนดและความเบี่ยงเบน' และ KPI 'ดัชนีความสอดคล้องของคำขอซื้อ' โดยใช้เปรียบเทียบขั้นตอนอนุมัติที่เกิดขึ้นจริงกับเส้นทางที่กำหนดไว้ ความเบี่ยงเบนอาจบ่งชี้ถึงการไม่ปฏิบัติตามนโยบายหรือความไม่มีประสิทธิภาพของกระบวนการ. เหตุผลที่สำคัญ ช่วยตรวจสอบความสอดคล้องของกระบวนการ โดยเปรียบเทียบขั้นตอนจริงกับลำดับการอนุมัติที่กำหนด และระบุคำขอซื้อที่ไม่เป็นไปตามข้อกำหนด. แหล่งข้อมูล ข้อมูลนี้กำหนดค่าไว้ใน Oracle Fusion BPM Worklist หรือ Approval Management Engine (AMX) การดึงเส้นทางที่กำหนดไว้ของคำขอซื้อแต่ละรายการอาจซับซ้อนและอาจต้องค้นจากตารางการกำหนดค่า. ตัวอย่าง ผู้จัดการ > ผู้อำนวยการ > รองประธานฝ่ายการเงินเจ้าของศูนย์ต้นทุน > ฝ่ายความปลอดภัยไอทีผู้จัดการ > หัวหน้าแผนก
	หมายเลขใบสั่งซื้อ PurchaseOrderNumber	รหัสของใบสั่งซื้อที่สร้างจากคำขอซื้อที่ได้รับอนุมัติ.
คำอธิบาย แอตทริบิวต์นี้เชื่อมคำขอซื้อกับใบสั่งซื้อที่สร้างตามมา เมื่อคำขอซื้อได้รับอนุมัติครบถ้วนแล้ว โดยทั่วไปจะเปลี่ยนเป็นใบสั่งซื้อหนึ่งรายการหรือหลายรายการเพื่อส่งให้ผู้ขาย ในการวิเคราะห์ ID นี้จำเป็นต่อการติดตามกระบวนการหลังจากจัดทำคำขอซื้อ ช่วยคำนวณ KPI 'ระยะเวลาตั้งแต่คำขอซื้อถึงใบสั่งซื้อ' และรองรับแดชบอร์ด 'ระยะเวลาดำเนินการจากคำขอซื้อถึงใบสั่งซื้อ' นอกจากนี้ยังช่วยรวมข้อมูลกระบวนการคำขอซื้อเข้ากับกระบวนการใบสั่งซื้อและการออกใบแจ้งหนี้ที่ตามมา เพื่อวิเคราะห์ Purchase-to-Pay ได้ตั้งแต่ต้นจนจบ. เหตุผลที่สำคัญ เชื่อมคำขอซื้อกับใบสั่งซื้อที่ตามมา ช่วยวัดระยะเวลาตั้งแต่คำขอซื้อถึงใบสั่งซื้อและวิเคราะห์กระบวนการตั้งแต่ต้นจนจบ. แหล่งข้อมูล ข้อมูลนี้จะจัดเก็บเมื่อสร้างใบสั่งซื้อแล้ว โดยทั่วไปค้นหาได้จากข้อมูลอ้างอิงคำขอซื้อในตารางการกระจายรายการใบสั่งซื้อ เช่น PO_DISTRIBUTIONS_ALL ซึ่งเชื่อมกลับไปยังรายการคำขอซื้อ. ตัวอย่าง PO-2023-5832PO-2023-5833PO-2023-5834

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

กิจกรรมในกระบวนการจัดซื้อจนถึงชำระเงินสำหรับคำขอซื้อ

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

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

	กิจกรรม	คำอธิบาย
	ปฏิเสธใบขอซื้อ	หมายถึงการปฏิเสธใบขอซื้อขั้นสุดท้าย ซึ่งยุติกระบวนการของคำขอนี้ อนุมานได้เมื่อสถานะโดยรวมของใบขอซื้อเปลี่ยนเป็น 'Rejected'.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดของคำขอที่ไม่สำเร็จ การวิเคราะห์กรณีเหล่านี้จำเป็นต่อการทำความเข้าใจ KPI อัตราการปฏิเสธใบขอซื้อและสาเหตุที่ไม่ผ่าน. แหล่งข้อมูล อนุมานจากสถานะเอกสารในตาราง POR_REQUISITION_HEADERS_ALL ที่เปลี่ยนเป็น 'REJECTED'. บันทึก ระบุเวลาที่สถานะเอกสารถูกตั้งเป็น 'Rejected' เป็นครั้งแรก. ประเภทเหตุการณ์ inferred
	ปิดใบขอซื้อ	หมายถึงการปิดวงจรของใบขอซื้อขั้นสุดท้าย เมื่อดำเนินการตามรายการทั้งหมดแล้ว เช่น แปลงเป็นใบสั่งซื้อหรือยกเลิก อนุมานได้จากการอัปเดตสถานะขั้นสุดท้าย.
เหตุผลที่สำคัญ นี่คือเหตุการณ์สิ้นสุดหลักที่แสดงว่ากระบวนการสำเร็จ ยืนยันว่าใบขอซื้อดำเนินการครบถ้วนแล้วและไม่ต้องดำเนินการต่อ. แหล่งข้อมูล อนุมานจากสถานะส่วนหัวใบขอซื้อใน POR_REQUISITION_HEADERS_ALL ที่เปลี่ยนเป็น 'CLOSED'. บันทึก ระบุเวลาที่สถานะเอกสารของใบขอซื้อเปลี่ยนเป็น 'Closed'. ประเภทเหตุการณ์ inferred
	ส่งใบขอซื้อ	หมายถึงการที่ผู้ใช้ส่งใบขอซื้อที่กรอกเสร็จแล้วเข้าสู่เวิร์กโฟลว์การอนุมัติ ระบบบันทึกเหตุการณ์นี้เมื่อสถานะใบขอซื้อเปลี่ยนจาก 'Incomplete' หรือ 'Draft' เป็นสถานะรออนุมัติ.
เหตุผลที่สำคัญ กิจกรรมนี้เริ่มรอบการอนุมัติ และเป็นหมุดหมายสำคัญในการวัดเวลารอบการอนุมัติใบขอซื้อและระยะเวลาดำเนินการโดยรวม. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในตาราง POR_REQUISITION_HEADERS_ALL เช่น สถานะเปลี่ยนเป็น 'PENDING APPROVAL' โดยมักมีการบันทึกวันที่ส่งไว้โดยตรงด้วย. บันทึก ระบุเวลาที่ฟิลด์สถานะเอกสารเปลี่ยนเป็น 'Pending Approval' เป็นครั้งแรก. ประเภทเหตุการณ์ inferred
	สร้างใบขอซื้อ	เป็นจุดเริ่มต้นของกระบวนการจัดซื้อ เมื่อผู้ใช้บันทึกใบขอซื้อใหม่เป็นครั้งแรก โดยทั่วไป ระบบบันทึกเหตุการณ์นี้เป็นการสร้างรายการ พร้อมเวลาที่เกิดเหตุการณ์.
เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการใบขอซื้อ การวิเคราะห์เวลาตั้งแต่สร้างจนถึงส่งใบขอซื้อช่วยให้พบความล่าช้าในการจัดทำคำขอให้เป็นทางการ. แหล่งข้อมูล บันทึกเหตุการณ์นี้ในตาราง POR_REQUISITION_HEADERS_ALL โดยใช้ค่าจากคอลัมน์ creation_date เมื่อระบบสร้างรหัสใบขอซื้อใหม่. บันทึก ใช้เวลาที่สร้างระเบียนส่วนหัวของใบขอซื้อ. ประเภทเหตุการณ์ explicit
	สร้างใบสั่งซื้อ	เหตุการณ์นี้เกิดขึ้นเมื่อใช้รายการใบขอซื้อที่อนุมัติแล้วเพื่อสร้างใบสั่งซื้อ ซึ่งเชื่อมกระบวนการใบขอซื้อกับกระบวนการจัดซื้อขั้นถัดไป.
เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญในการวัดระยะเวลาตั้งแต่ใบขอซื้อจนถึงใบสั่งซื้อ หากล่าช้า แสดงว่าอาจมีคอขวดในการส่งต่องานจากการอนุมัติไปยังการจัดซื้อ. แหล่งข้อมูล เหตุการณ์นี้มีการบันทึกไว้โดยตรง ตารางอย่าง PO_LINE_LOCATIONS_ALL จัดเก็บความเชื่อมโยงระหว่างใบขอซื้อกับใบสั่งซื้อ โดยมีการอ้างอิงรหัสรายการใบขอซื้อต้นทาง. บันทึก ค้นหาวันที่สร้างใบสั่งซื้อที่อ้างอิงรหัสใบขอซื้อที่ระบุ. ประเภทเหตุการณ์ explicit
	อนุมัติใบขอซื้อ	ระบุการอนุมัติขั้นสุดท้ายของใบขอซื้อ หลังจากผ่านทุกขั้นตอนในเวิร์กโฟลว์แล้ว อนุมานได้จากสถานะโดยรวมของใบขอซื้อที่เปลี่ยนเป็น 'Approved'.
เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญที่แสดงว่าคำขอพร้อมเข้าสู่ขั้นตอนจัดซื้อ และเป็นจุดสิ้นสุดที่ใช้วัดเวลารอบการอนุมัติใบขอซื้อทั้งหมด. แหล่งข้อมูล อนุมานจากฟิลด์สถานะเอกสารในตาราง POR_REQUISITION_HEADERS_ALL ที่เปลี่ยนเป็น 'APPROVED' โดยใช้วันที่เปลี่ยนสถานะเป็นเวลาเกิดเหตุการณ์. บันทึก ระบุเวลาที่สถานะเอกสารถูกตั้งเป็น 'Approved' เป็นครั้งแรก. ประเภทเหตุการณ์ inferred
	แก้ไขใบขอซื้อ	เหตุการณ์นี้หมายถึงผู้ใช้แก้ไขใบขอซื้อหลังจากส่งครั้งแรก ซึ่งมักทำให้ต้องเริ่มกระบวนการอนุมัติใหม่ อนุมานได้จากการตรวจพบการเปลี่ยนแปลงในฟิลด์ข้อมูลสำคัญ หรือการสร้างใบขอซื้อเวอร์ชันใหม่.
เหตุผลที่สำคัญ การแก้ไขบ่อยครั้งบ่งชี้ถึงปัญหาคุณภาพข้อมูลหรือข้อกำหนดที่เปลี่ยนแปลง ทำให้ต้องทำงานซ้ำและกระบวนการล่าช้า ข้อมูลนี้ใช้คำนวณ KPI 'อัตราการแก้ไขใบขอซื้อ' ได้โดยตรง. แหล่งข้อมูล อนุมานได้จากการติดตามหมายเลขเวอร์ชันของใบขอซื้อ หรือการตรวจพบว่าสถานะเปลี่ยนกลับเป็น 'Incomplete' หลังส่งแล้ว บันทึกการเปลี่ยนแปลงหรือตารางประวัติการตรวจสอบอาจเก็บข้อมูลการแก้ไขเหล่านี้ไว้ด้วย. บันทึก ระบุเวลาที่สร้างเวอร์ชันใหม่ของใบขอซื้อรหัสเดิมหลังจากส่งแล้ว. ประเภทเหตุการณ์ inferred
	ถอนใบขอซื้อ	เกิดขึ้นเมื่อผู้ขอยกเลิกหรือถอนใบขอซื้อที่ส่งแล้วก่อนอนุมัติครบทุกขั้นตอน โดยทั่วไปเป็นการดำเนินการของผู้ใช้ที่ทำให้สถานะเปลี่ยน.
เหตุผลที่สำคัญ การติดตามการถอนช่วยให้ทราบสาเหตุที่กระบวนการสิ้นสุดก่อนกำหนด เช่น ความต้องการทางธุรกิจเปลี่ยนไป หรือผู้ใช้แก้ไขข้อผิดพลาดหลังส่งใบขอซื้อ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะเป็น 'WITHDRAWN' ในตาราง POR_REQUISITION_HEADERS_ALL โดยมีการบันทึกการดำเนินการไว้ในประวัติของใบขอซื้อ. บันทึก ตรวจหาเวลาที่สถานะใบขอซื้อเปลี่ยนเป็น 'Withdrawn'. ประเภทเหตุการณ์ inferred
	ปฏิเสธขั้นตอนการอนุมัติ	ผู้อนุมัติรายหนึ่งปฏิเสธใบขอซื้อ ซึ่งโดยทั่วไปจะส่งกลับให้ผู้จัดทำแก้ไขหรือยุติคำขอ ระบบบันทึกการดำเนินการนี้ไว้ในประวัติเวิร์กโฟลว์โดยตรง.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นสาเหตุหลักของงานแก้ไขซ้ำและความล่าช้า การวิเคราะห์การปฏิเสธช่วยให้พบปัญหาด้านการปฏิบัติตามข้อกำหนด งบประมาณ หรือเหตุผลประกอบที่ไม่ชัดเจน. แหล่งข้อมูล ดึงข้อมูลจากประวัติการดำเนินการอนุมัติของใบขอซื้อ ระบบเวิร์กโฟลว์บันทึกการดำเนินการ 'REJECT' พร้อมเวลา. บันทึก ใช้เวลาของการดำเนินการ 'REJECT' จากบันทึกประวัติการดำเนินการในเวิร์กโฟลว์. ประเภทเหตุการณ์ explicit
	เริ่มขั้นตอนอนุมัติ	ระบุเวลาที่มอบหมายใบขอซื้อให้ผู้อนุมัติหรือกลุ่มผู้อนุมัติเฉพาะในเวิร์กโฟลว์ โดยดึงข้อมูลจากบันทึกรายการธุรกรรมของระบบเวิร์กโฟลว์.
เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการคำนวณเวลารอในแต่ละขั้นตอนการอนุมัติ และช่วยระบุคอขวดที่เกิดจากผู้อนุมัติหรือระดับการอนุมัติเฉพาะ. แหล่งข้อมูล ดึงข้อมูลจากตารางเวิร์กโฟลว์ของ Oracle Fusion ซึ่งบันทึกงานที่มอบหมายให้ผู้ใช้ โดยใช้เวลาที่มอบหมายงานอนุมัติ. บันทึก ใช้เวลาที่สร้างงานในประวัติเวิร์กโฟลว์ของใบขอซื้อรายการนั้น. ประเภทเหตุการณ์ explicit
	ส่งใบขอซื้อกลับในขั้นตอนอนุมัติ	ผู้อนุมัติส่งใบขอซื้อกลับไปยังผู้จัดทำเพื่อขอข้อมูลเพิ่มเติมหรือให้แก้ไขเล็กน้อย โดยไม่ได้ปฏิเสธอย่างเป็นทางการ โดยทั่วไปเป็นการดำเนินการที่บันทึกไว้โดยตรงในระบบเวิร์กโฟลว์.
เหตุผลที่สำคัญ เหตุการณ์นี้แสดงว่าต้องขอคำชี้แจงเพิ่มเติม และทำให้เกิดวงจรการแก้ไขซ้ำซึ่งยืดเวลารอบการทำงาน การแยกการส่งกลับออกจากการปฏิเสธช่วยให้เห็นจุดติดขัดของกระบวนการได้ชัดเจนขึ้น. แหล่งข้อมูล ดึงข้อมูลจากประวัติการดำเนินการอนุมัติของใบขอซื้อ ระบบเวิร์กโฟลว์บันทึกการดำเนินการ 'RETURN' หรือรายการที่มีความหมายใกล้เคียง พร้อมเวลา. บันทึก ใช้เวลาของการดำเนินการ 'RETURN' หรือ 'Request for Information' จากประวัติเวิร์กโฟลว์. ประเภทเหตุการณ์ explicit
	อนุมัติขั้นตอนการอนุมัติ	หมายถึงการที่ผู้อนุมัติแต่ละรายอนุมัติใบขอซื้อในขั้นตอนที่ได้รับมอบหมาย ระบบบันทึกเหตุการณ์นี้ไว้โดยตรงในประวัติการอนุมัติ.
เหตุผลที่สำคัญ การติดตามขั้นตอนอนุมัติแต่ละรายการช่วยให้เห็นเส้นทางการอนุมัติจริงและวัดเวลาดำเนินการในแต่ละระดับของลำดับการอนุมัติ. แหล่งข้อมูล ดึงข้อมูลจากประวัติการดำเนินการอนุมัติของใบขอซื้อ ซึ่งโดยทั่วไปจัดเก็บในตารางเวิร์กโฟลว์ (WF) หรือ Human Capital Management (HCM) ที่ใช้จัดการลำดับการอนุมัติ. บันทึก ใช้เวลาของการดำเนินการ 'APPROVE' จากบันทึกประวัติการดำเนินการในเวิร์กโฟลว์. ประเภทเหตุการณ์ explicit

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

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

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

ขั้นตอน

ไปที่ Reports and Analytics: ลงชื่อเข้าใช้ Oracle Fusion Financials เปิดเมนู Navigator ไปที่ Tools แล้วเลือก Reports and Analytics ซึ่งเป็นศูนย์กลางสำหรับงานรายงานทั้งหมด.
สร้างการวิเคราะห์ใหม่: ในพื้นที่ทำงาน Reports and Analytics คลิกปุ่ม 'Create' แล้วเลือก 'Analysis' จากเมนูแบบเลื่อนลง ระบบจะเปิดตัวแก้ไขการวิเคราะห์ Oracle Transactional Business Intelligence (OTBI) ในแท็บใหม่.
เลือก Subject Area: ระบบจะแจ้งให้เลือก Subject Area พิมพ์ 'Procurement - Requisitions Real Time' ในช่องค้นหา แล้วเลือกจากรายการ Subject Area นี้มีข้อมูลที่จำเป็นสำหรับเหตุการณ์ตลอดวงจรคำขอซื้อ.
สร้างการวิเคราะห์เหตุการณ์คำขอซื้อ: ขั้นตอนนี้ต้องรวมผลจากหลายคำค้นเพื่อเก็บเหตุการณ์แต่ละประเภท เนื่องจากหน้าจอ OTBI ไม่มีฟังก์ชัน UNION ALL โดยตรงสำหรับเหตุการณ์ต่างประเภท ให้สร้างรายงานเดียวที่ดึงฟิลด์วันที่และสถานะที่เกี่ยวข้องทั้งหมด ในแท็บ 'Criteria' ลากคอลัมน์ที่ระบุไว้ในส่วนคำค้นจากแผง 'Subject Areas' ทางซ้ายไปยังพื้นที่ 'Selected Columns' ซึ่งรวมถึงคอลัมน์วันที่สร้าง วันที่ส่ง วันที่อนุมัติ วันที่สร้าง PO และอื่นๆ.
เพิ่มประวัติการดำเนินการคำขอซื้อ: หากต้องการเก็บรายละเอียดขั้นตอนอนุมัติ เช่น อนุมัติ ปฏิเสธ ส่งกลับ และถอนคำขอ ให้เพิ่มฟิลด์จากโฟลเดอร์ 'Requisition Action History' ภายใน Subject Area ลาก 'Action Date', 'Action' และ 'Performer' ไปไว้ในคอลัมน์ที่เลือก.
ตั้งค่าตัวกรอง: ไปที่แท็บ 'Prompts' เพื่อสร้างตัวกรองสำหรับการวิเคราะห์ ควรกรองตามช่วงวันที่เพื่อควบคุมปริมาณข้อมูล สร้างตัวกรองที่ 'Requisition Header'.'Requisition Creation Date' และกำหนดช่วง เช่น 6 เดือนที่ผ่านมา นอกจากนี้ยังเพิ่มตัวกรอง 'Business Unit' หรือ 'Requester Name' เพื่อจำกัดข้อมูลได้.
เรียกใช้และตรวจสอบรายงาน: ไปที่แท็บ 'Results' เพื่อเรียกใช้การวิเคราะห์และดูตัวอย่างข้อมูล ผลลัพธ์จะเป็นตารางแบบ 'กว้าง' โดยมีหนึ่งแถวต่อรายการคำขอซื้อหรือการดำเนินการอนุมัติ พร้อมคอลัมน์วันที่และสถานะหลายรายการ.
ส่งออกข้อมูลดิบ: เมื่อตรวจสอบตัวอย่างแล้ว คลิกลิงก์ 'Export' ซึ่งมักอยู่ด้านล่างของหน้าผลลัพธ์ เลือก 'Data' > 'CSV File' เป็นรูปแบบไฟล์ ระบบจะดาวน์โหลดข้อมูลดิบจากการวิเคราะห์.
แปลงข้อมูลเป็นรูปแบบบันทึกเหตุการณ์: ไฟล์ CSV ที่ส่งออกจะอยู่ในรูปแบบกว้าง คุณต้องใช้เครื่องมือภายนอก เช่น สคริปต์ Python, Power Query ใน Excel หรือเครื่องมือเตรียมข้อมูลอื่น เพื่อแปลงข้อมูล โดยนำคอลัมน์วันที่มารวมเป็นคอลัมน์ 'EventTime' เดียว และสร้างคอลัมน์ 'ActivityName' ที่ตรงกับเหตุการณ์แต่ละประเภท เช่น 'Requisition Created' และ 'Requisition Submitted'.
จัดเตรียมไฟล์สำหรับอัปโหลด: หลังแปลงข้อมูลแล้ว ตรวจสอบให้แน่ใจว่าไฟล์มีคอลัมน์ที่จำเป็น ได้แก่ PurchaseRequisitionId, ActivityName, EventTime, SourceSystem และ LastDataUpdate บันทึกบันทึกเหตุการณ์ฉบับสมบูรณ์เป็นไฟล์ CSV แล้วอัปโหลดไปยัง ProcessMind ได้เลย.

การกำหนดค่า

Subject Area: Subject Area หลักที่ควรใช้คือ 'Procurement - Requisitions Real Time' ซึ่งมีข้อมูลหลักของส่วนหัวคำขอซื้อ รายการ การจัดสรร และประวัติการอนุมัติ.
ช่วงวันที่: ควรใช้ตัวกรองวันที่เพื่อจำกัดปริมาณข้อมูลและเพิ่มประสิทธิภาพการทำงาน เริ่มต้นได้ด้วยการกรอง 'Requisition Header'.'Requisition Creation Date' ให้ครอบคลุม 3 ถึง 6 เดือนที่ผ่านมา.
ตัวกรองสำคัญ: พิจารณาเพิ่มตัวกรอง 'Requisition Header'.'Business Unit' และ 'Requisition Header'.'Requisition Status' เพื่อเลือกหน่วยงานที่เกี่ยวข้อง และตัดสถานะที่ไม่จำเป็น เช่น 'Canceled' หากไม่ต้องใช้ในการวิเคราะห์.
การเลือกคอลัมน์: เลือกคอลัมน์ที่จะเพิ่มในการวิเคราะห์อย่างระมัดระวัง การใส่คอลัมน์มากเกินไป โดยเฉพาะจากหลายโฟลเดอร์ (มิติข้อมูล) อาจทำให้ประสิทธิภาพลดลง เลือกเฉพาะฟิลด์ที่จำเป็นสำหรับบันทึกเหตุการณ์.
สิทธิ์: ผู้ใช้ที่ดึงข้อมูลต้องมีบทบาทและสิทธิ์ที่จำเป็นในการเข้าถึงพื้นที่ทำงาน Reports and Analytics และ Subject Area 'Procurement - Requisitions Real Time' โดยทั่วไป บทบาทอย่าง 'BI Author' หรือ 'Procurement Analyst' จะมีสิทธิ์เหล่านี้.

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

/*
OTBI analyses are built visually, not with SQL. This conceptual query illustrates the logic required to extract the data for all specified activities. The user would build an analysis containing these fields and then transform the output into an event log.
*/

-- 1. Requisition Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Created' AS ActivityName,
  "Requisition Header"."Requisition Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Creation Date" IS NOT NULL

UNION ALL

-- 2. Requisition Submitted
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Submitted' AS ActivityName,
  "Requisition Header"."Submitted Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Submitted Date" IS NOT NULL

UNION ALL

-- 3, 5, 6, 7, 8. Approval History Events (Withdrawn, Started, Approved, Rejected, Returned)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  CASE "Requisition Action History"."Action"
    WHEN 'WITHDRAW' THEN 'Requisition Withdrawn'
    WHEN 'SUBMIT' THEN 'Approval Step Started' -- Assumes submit action assigns to first approver
    WHEN 'APPROVE' THEN 'Approval Step Approved'
    WHEN 'REJECT' THEN 'Approval Step Rejected'
    WHEN 'RETURN' THEN 'Approval Step Returned'
  END AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  CASE WHEN "Requisition Action History"."Action" = 'REJECT' THEN "Requisition Action History"."Action Note" ELSE NULL END AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Action History"."Action" IN ('WITHDRAW', 'SUBMIT', 'APPROVE', 'REJECT', 'RETURN')

UNION ALL

-- 4. Requisition Amended
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Amended' AS ActivityName,
  "Requisition Header"."Last Update Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Version" > 1 AND "Requisition Header"."Last Update Date" > "Requisition Header"."Submitted Date"

UNION ALL

-- 9. Requisition Approved (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Approved' AS ActivityName,
  "Requisition Header"."Approved Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'APPROVED'
AND "Requisition Header"."Approved Date" IS NOT NULL

UNION ALL

-- 10. Requisition Rejected (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Rejected' AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  "Requisition Action History"."Action Note" AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'REJECTED'
AND "Requisition Action History"."Action" = 'REJECT'
AND "Requisition Action History"."Sequence Number" = (SELECT MAX(T2."Sequence Number") FROM "Procurement - Requisitions Real Time" T2 WHERE T2."Requisition Header"."Requisition Number" = "Requisition Header"."Requisition Number")

UNION ALL

-- 11. Purchase Order Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Purchase Order Created' AS ActivityName,
  "Purchase Order Schedule"."PO Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Purchase Order Schedule"."PO Creation Date" IS NOT NULL

UNION ALL

-- 12. Requisition Closed
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Closed' AS ActivityName,
  "Requisition Line"."Line Close Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Line"."Line Close Date" IS NOT NULL AND "Requisition Line"."Line Status" = 'CLOSED'

ขั้นตอน

เข้าสู่ระบบ Oracle Fusion Financials ด้วยบัญชีผู้ใช้ที่มีสิทธิ์ BI Author หรือสิทธิ์ใกล้เคียง
ไปยังพื้นที่ทำงาน Reports and Analytics โดยคลิกไอคอน Navigator แล้วเลือก Tools > Reports and Analytics
คลิกปุ่ม "เรียกดูแค็ตตาล็อก" เพื่อเปิดแค็ตตาล็อก Business Intelligence Publisher
ในอินเทอร์เฟซ BI Publisher คลิก "ใหม่" แล้วเลือก "โมเดลข้อมูล" จากรายการแบบเลื่อนลง
ในคุณสมบัติของโมเดลข้อมูล ให้ระบุชื่อและคำอธิบายได้ คลิกไอคอน "+" เพื่อเพิ่มชุดข้อมูล แล้วเลือก "คิวรี SQL"
ในกล่องโต้ตอบชุดข้อมูลใหม่ ให้ระบุชื่อ เช่น Requisition_Event_Log เลือกแหล่งข้อมูลที่เหมาะสมสำหรับข้อมูล Financials เช่น ApplicationDB_FSCM แล้วตั้งค่าประเภท SQL เป็น "Standard SQL"
คัดลอกสคริปต์ SQL ทั้งหมดจากส่วน "query" ในเอกสารนี้ แล้ววางลงในช่องข้อความ SQL Query
คิวรีมีพารามิเตอร์ :p_start_date และ :p_end_date ซึ่ง BI Publisher จะตรวจพบโดยอัตโนมัติ คุณสามารถกำหนดค่าเริ่มต้นได้ตามต้องการ
บันทึกโมเดลข้อมูลไว้ในโฟลเดอร์แค็ตตาล็อกที่เหมาะสม เช่น Shared Folders/Custom
หากต้องการส่งออกข้อมูล ให้กลับไปที่แค็ตตาล็อก คลิก "ใหม่" แล้วเลือก "รายงาน" เชื่อมรายงานใหม่นี้กับโมเดลข้อมูลที่สร้างไว้
เรียกใช้รายงานและระบุพารามิเตอร์วันที่เริ่มต้นและวันที่สิ้นสุด เมื่อรายงานแสดงข้อมูลแล้ว ให้ใช้ฟังก์ชัน "ส่งออก" เพื่อดาวน์โหลดผลลัพธ์เป็นไฟล์ CSV
ตรวจสอบว่าไฟล์ CSV สุดท้ายบันทึกด้วยการเข้ารหัส UTF-8 และมีส่วนหัวคอลัมน์ที่จำเป็นสำหรับนำเข้าข้อมูลไปยังเครื่องมือ process mining

การกำหนดค่า

แหล่งข้อมูล: ต้องกำหนดค่าแหล่งข้อมูล BI Publisher ซึ่งมักใช้ชื่อ 'ApplicationDB_FSCM' หรือชื่อใกล้เคียง โดยใช้ผู้ใช้ที่มีสิทธิ์อ่านทุกตารางในคิวรี รวมถึงตารางจาก Procurement (POR, PO), Human Capital Management (PER, HR) และ Financials (FUN)
การกรองช่วงวันที่: คิวรีกำหนดพารามิเตอร์วันที่ที่จำเป็น (:p_start_date และ :p_end_date) เพื่อกรองตามวันที่สร้างใบขอซื้อ สำหรับการดึงข้อมูลครั้งแรกหรือระบบขนาดใหญ่ ควรแบ่งดึงข้อมูลเป็นชุดที่จัดการได้ เช่น ครั้งละ 3 ถึง 6 เดือน เพื่อป้องกันระบบหมดเวลาทำงาน
การกรองหน่วยธุรกิจ: มีตัวกรองชื่อหน่วยธุรกิจอยู่ในส่วน WHERE ของคิวรีในรูปแบบคอมเมนต์ แนะนำให้ยกเลิกคอมเมนต์และตั้งค่าตัวกรองนี้ เพื่อจำกัดข้อมูลเฉพาะหน่วยธุรกิจที่เกี่ยวข้องกับการวิเคราะห์ ซึ่งช่วยเพิ่มประสิทธิภาพได้อย่างมาก
ข้อกำหนดเบื้องต้น: ผู้สร้างและเรียกใช้รายงานต้องมีบทบาทที่ให้สิทธิ์ BI Publisher เช่น 'BI Administrator Role' หรือ 'BI Author Role' นอกจากนี้ ผู้ใช้ต้องได้รับสิทธิ์ด้านความปลอดภัยของข้อมูลที่จำเป็นเพื่อเข้าถึงข้อมูลการจัดซื้อ.

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

WITH BaseRequisitions AS (
    SELECT
        PRH.REQUISITION_HEADER_ID,
        PRH.REQUISITION_NUMBER,
        PRH.CREATION_DATE,
        PRH.LAST_UPDATE_DATE AS HEADER_LAST_UPDATE_DATE,
        PRH.DOCUMENT_STATUS,
        PRH.PREPARER_ID,
        PPNF_REQ.DISPLAY_NAME AS RequesterName,
        HOU.NAME AS DepartmentName,
        BU.BU_NAME AS BusinessUnit,
        SUM(PRL.AMOUNT) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequisitionTotalAmount,
        MIN(PRL.NEED_BY_DATE) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequiredByDate
    FROM
        POR_REQUISITION_HEADERS_ALL PRH
    JOIN
        POR_REQUISITION_LINES_ALL PRL ON PRH.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
    JOIN
        PER_USERS PU_REQ ON PRH.PREPARER_ID = PU_REQ.USER_ID
    LEFT JOIN
        PER_PERSON_NAMES_F PPNF_REQ ON PU_REQ.PERSON_ID = PPNF_REQ.PERSON_ID AND PPNF_REQ.NAME_TYPE = 'GLOBAL' AND SYSDATE BETWEEN PPNF_REQ.EFFECTIVE_START_DATE AND PPNF_REQ.EFFECTIVE_END_DATE
    LEFT JOIN
        PER_ALL_ASSIGNMENTS_F PAAF ON PU_REQ.PERSON_ID = PAAF.PERSON_ID AND PAAF.ASSIGNMENT_TYPE = 'E' AND PAAF.PRIMARY_FLAG = 'Y' AND SYSDATE BETWEEN PAAF.EFFECTIVE_START_DATE AND PAAF.EFFECTIVE_END_DATE
    LEFT JOIN
        HR_ORGANIZATION_UNITS_F_VL HOU ON PAAF.ORGANIZATION_ID = HOU.ORGANIZATION_ID AND SYSDATE BETWEEN HOU.EFFECTIVE_START_DATE AND HOU.EFFECTIVE_END_DATE
    JOIN
        FUN_ALL_BUSINESS_UNITS_V BU ON PRH.REQ_BU_ID = BU.BU_ID
    WHERE PRH.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
    -- AND BU.BU_NAME IN ('[Your Business Unit Name]') -- Recommended: Uncomment and specify your Business Unit(s)
)
-- 1. Requisition Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Created' AS "ActivityName",
    BR.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR

UNION ALL

-- 2. Requisition Submitted, 4. Requisition Amended
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    CASE 
        WHEN PAH.OBJECT_REVISION_NUM > 1 THEN 'Requisition Amended'
        ELSE 'Requisition Submitted'
    END AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'SUBMIT'

UNION ALL

-- 3. Requisition Withdrawn
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Withdrawn' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'WITHDRAW'

UNION ALL

-- 5. Approval Step Started
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Started' AS "ActivityName",
    PAH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE IN ('APPROVE', 'REJECT', 'SUBMIT', 'RETURN')

UNION ALL

-- 6. Approval Step Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'APPROVE'

UNION ALL

-- 7. Approval Step Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'

UNION ALL

-- 8. Approval Step Returned
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Returned' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'RETURN'

UNION ALL

-- 9. Requisition Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'APPROVED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'FINALLY CLOSE' AND BR.DOCUMENT_STATUS = 'APPROVED'

UNION ALL

-- 10. Requisition Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'REJECTED' AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'
AND BR.DOCUMENT_STATUS = 'REJECTED'
AND PAH.ACTION_DATE = (SELECT MAX(PAH2.ACTION_DATE) FROM PO_ACTION_HISTORY PAH2 WHERE PAH2.OBJECT_ID = BR.REQUISITION_HEADER_ID AND PAH2.ACTION_CODE = 'REJECT')

UNION ALL

-- 11. Purchase Order Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Purchase Order Created' AS "ActivityName",
    POH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN POR_REQUISITION_LINES_ALL PRL ON BR.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
JOIN PO_DISTRIBUTIONS_ALL POD ON PRL.REQUISITION_LINE_ID = POD.REQUISITION_LINE_ID
JOIN PO_HEADERS_ALL POH ON POD.PO_HEADER_ID = POH.PO_HEADER_ID

UNION ALL

-- 12. Requisition Closed
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Closed' AS "ActivityName",
    BR.HEADER_LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'CLOSED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
WHERE BR.DOCUMENT_STATUS = 'CLOSED'

ขั้นตอน

ข้อกำหนดเบื้องต้นและการตั้งค่าสภาพแวดล้อม: ตรวจสอบว่าติดตั้ง Python 3 ในระบบแล้ว ติดตั้งไลบรารี requests โดยเรียกใช้คำสั่งต่อไปนี้ในเทอร์มินัล: pip install requests นอกจากนี้ คุณต้องมีข้อมูลรับรอง API (ชื่อผู้ใช้และรหัสผ่าน) สำหรับบัญชี Oracle Fusion ที่มีสิทธิ์อ่านข้อมูลคำขอซื้อ และ URL หลักของ Oracle Fusion instance ของคุณ.
บันทึกสคริปต์ Python: บันทึกโค้ด Python ทั้งหมดจากส่วน 'query' เป็นไฟล์ เช่น extract_requisitions.py.
ตั้งค่าพารามิเตอร์ของสคริปต์: เปิดไฟล์สคริปต์ด้วยโปรแกรมแก้ไขข้อความ แล้วแก้ค่าตัวอย่างที่ด้านบนของสคริปต์ กำหนด FUSION_URL, USERNAME และ PASSWORD ให้ตรงกับสภาพแวดล้อม Oracle Fusion ของคุณ ปรับ START_DATE และ END_DATE เพื่อระบุช่วงเวลาที่ต้องการดึงข้อมูล.
ทำความเข้าใจ API Endpoint และฟิลด์: สคริปต์เรียกใช้ทรัพยากร REST API purchaseRequisitions โดยใช้พารามิเตอร์ fields เพื่อขอเฉพาะข้อมูลที่จำเป็น รวมถึงชุดข้อมูลซ้อน เช่น lines (ข้อมูล PO) และ actionHistory (เหตุการณ์อนุมัติ) ซึ่งช่วยเพิ่มประสิทธิภาพ.
เรียกใช้สคริปต์: เรียกใช้สคริปต์จากเทอร์มินัลด้วยคำสั่ง python extract_requisitions.py สคริปต์จะยืนยันตัวตนกับ API เริ่มดึงข้อมูล และแสดงความคืบหน้าในคอนโซล รวมถึงจำนวนคำขอซื้อที่ประมวลผลแล้ว.
จัดการการแบ่งหน้า: สคริปต์จัดการการแบ่งหน้าโดยอัตโนมัติ Oracle Fusion REST API ส่งข้อมูลเป็นชุด (หน้า) สคริปต์จะตรวจสอบค่า hasMore ในแต่ละการตอบกลับ และส่งคำขอซ้ำโดยปรับพารามิเตอร์ offset จนกว่าจะดึงคำขอซื้อทั้งหมดในช่วงวันที่ที่กำหนดได้.
การแปลงข้อมูล: สำหรับคำขอซื้อแต่ละรายการที่ดึงจาก API สคริปต์จะสร้างหลายแถวในบันทึกเหตุการณ์ โดยสร้างเหตุการณ์ 'Requisition Created' จาก CreationDate และเหตุการณ์ 'Requisition Submitted' จาก SubmittedDate จากนั้นวนอ่านชุดข้อมูล actionHistory เพื่อสร้างเหตุการณ์แยกตามขั้นตอนอนุมัติ เช่น Started, Approved, Rejected และ Returned.
ระบุเหตุการณ์สถานะสุดท้าย: สคริปต์ตรวจสอบ DocumentStatus สุดท้ายของคำขอซื้อ และใช้ LastUpdateDate เป็นเวลาของเหตุการณ์ เพื่อบันทึกผลลัพธ์สุดท้าย เช่น 'Requisition Approved' และ 'Requisition Rejected'.
สร้างเหตุการณ์ใบสั่งซื้อ: สคริปต์ตรวจสอบแต่ละรายการในคำขอซื้อ หากรายการมี PoHeaderId แสดงว่ามีการสร้างใบสั่งซื้อ ระบบจะเพิ่มเหตุการณ์นี้ลงในบันทึกเหตุการณ์และเชื่อมโยงคำขอซื้อกับกระบวนการจัดซื้อขั้นถัดไป.
ตรวจสอบไฟล์ผลลัพธ์: เมื่อสคริปต์ทำงานเสร็จ จะสร้างไฟล์ CSV ชื่อ oracle_fusion_requisitions_event_log.csv ในโฟลเดอร์เดียวกัน ไฟล์นี้มีบันทึกเหตุการณ์ที่ดึงมา.
เตรียมไฟล์สำหรับอัปโหลด: เปิดไฟล์ CSV ที่สร้างขึ้นในโปรแกรมสเปรดชีตเพื่อตรวจสอบเนื้อหา ตรวจสอบว่าคอลัมน์และรูปแบบข้อมูลตรงตามข้อกำหนดของเครื่องมือ process mining จากนั้นอัปโหลดไฟล์ไปยัง ProcessMind ได้เลย.

การกำหนดค่า

ข้อมูลรับรอง API: ต้องมีบัญชีผู้ใช้สำหรับการเชื่อมต่อโดยเฉพาะ พร้อมบทบาทที่ให้สิทธิ์อ่านอย่างเดียวสำหรับ Purchase Requisitions REST API ตัวอย่างบทบาท ได้แก่ Procurement Manager หรือบทบาทการเชื่อมต่อที่กำหนดเอง.
REST API Endpoint: สคริปต์ตั้งค่าให้ใช้ Endpoint .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions ตรวจสอบว่าหมายเลขเวอร์ชันใน URL ตรงกับสภาพแวดล้อม Oracle Fusion ของคุณ.
ตัวกรองช่วงวันที่: สคริปต์มีตัวแปร START_DATE และ END_DATE แนะนำให้แบ่งการดึงข้อมูลเป็นช่วงที่จัดการได้ เช่น ครั้งละ 3 ถึง 6 เดือน เพื่อหลีกเลี่ยง API หมดเวลาตอบสนองและปัญหาด้านประสิทธิภาพ ตัวกรองจะใช้กับ CreationDate ของคำขอซื้อ.
การเลือกฟิลด์: พารามิเตอร์ fields ในสคริปต์มีความสำคัญต่อประสิทธิภาพ โดยจำกัดข้อมูลตอบกลับให้เหลือเฉพาะแอตทริบิวต์ที่จำเป็นสำหรับบันทึกเหตุการณ์ ช่วยลดปริมาณการรับส่งข้อมูลและเวลาในการประมวลผล อย่าลบฟิลด์ที่จำเป็น เช่น RequisitionId, CreationDate, actionHistory หรือ lines.
ขีดจำกัดการแบ่งหน้า: กำหนดพารามิเตอร์ limit ไว้ที่ 100 ซึ่งเป็นค่าที่เหมาะสมสำหรับสภาพแวดล้อมส่วนใหญ่ คุณอาจลองเพิ่มเป็น 200 หรือ 500 เพื่อให้ดึงข้อมูลได้เร็วขึ้น แต่หากตั้งค่าสูงเกินไป อาจเกิดปัญหาหน่วยความจำหรือข้อจำกัดของ API.

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

import requests
import csv
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password.
FUSION_URL = class="hl-string">"https://[your-fusion-instance-url].oraclecloud.com"
USERNAME = class="hl-string">"your_api_user"
PASSWORD = class="hl-string">"your_api_password"

class=class="hl-string">"hl-comment"># Define the date range for the extraction.
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_requisitions_data():
    class="hl-string">"""Fetches and processes purchase requisition data from Oracle Fusion REST API."""
    
    api_url = fclass="hl-string">"{FUSION_URL}/fscmRestApi/resources/11.13.18.05/purchaseRequisitions"
    
    class=class="hl-string">"hl-comment"># Define the fields to retrieve to optimize the API call
    fields_to_get = [
        class="hl-string">"RequisitionId", class="hl-string">"RequisitionNumber", class="hl-string">"CreationDate", class="hl-string">"SubmittedDate", class="hl-string">"LastUpdateDate",
        class="hl-string">"DocumentStatus", class="hl-string">"PreparerName", class="hl-string">"BusinessUnitName", class="hl-string">"RequisitionTotal", class="hl-string">"NeedByDate",
        class="hl-string">"Department", class="hl-string">"RejectionReason", 
        class="hl-string">"actionHistory(ActionCode,ActionDate,PerformerName)",
        class="hl-string">"lines(PoHeaderId,LastUpdateDate)"
    ]
    
    class=class="hl-string">"hl-comment"># Parameters for the API request
    params = {
        class="hl-string">"q": fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">"fields": class="hl-string">",".join(fields_to_get),
        class="hl-string">"limit": 100,
        class="hl-string">"offset": 0
    }
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourceitem+json'
    }
    
    event_log = []
    has_more = True
    total_processed = 0
    now_iso = datetime.utcnow().isoformat() + class="hl-string">'Z'

    while has_more:
        print(fclass="hl-string">"Fetching requisitions from offset {params['offset']}...")
        try:
            response = requests.get(
                api_url, 
                auth=(USERNAME, PASSWORD), 
                params=params, 
                headers=headers
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes (4xx or 5xx)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break

        data = response.json()
        requisitions = data.get(class="hl-string">'items', [])

        if not requisitions:
            print(class="hl-string">"No more requisitions found.")
            break

        for req in requisitions:
            base_event = {
                class="hl-string">'PurchaseRequisitionId': req.get(class="hl-string">'RequisitionNumber'),
                class="hl-string">'RequesterName': req.get(class="hl-string">'PreparerName'),
                class="hl-string">'DepartmentName': req.get(class="hl-string">'Department'),
                class="hl-string">'RequisitionTotalAmount': req.get(class="hl-string">'RequisitionTotal'),
                class="hl-string">'RequisitionStatus': req.get(class="hl-string">'DocumentStatus'),
                class="hl-string">'RequiredByDate': req.get(class="hl-string">'NeedByDate'),
                class="hl-string">'RejectionReason': req.get(class="hl-string">'RejectionReason'),
                class="hl-string">'BusinessUnit': req.get(class="hl-string">'BusinessUnitName'),
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': now_iso
            }

            class=class="hl-string">"hl-comment"># 1. Requisition Created
            if req.get(class="hl-string">'CreationDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Created', class="hl-string">'EventTime': req[class="hl-string">'CreationDate']})

            class=class="hl-string">"hl-comment"># 2. Requisition Submitted
            if req.get(class="hl-string">'SubmittedDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Submitted', class="hl-string">'EventTime': req[class="hl-string">'SubmittedDate']})

            class=class="hl-string">"hl-comment"># 3-8. Approval Workflow Events from actionHistory
            po_created = False
            if class="hl-string">'actionHistory' in req and req[class="hl-string">'actionHistory'] is not None:
                for action in req[class="hl-string">'actionHistory']:
                    activity = None
                    action_code = action.get(class="hl-string">'ActionCode')
                    if action_code == class="hl-string">'SUBMIT':
                        class=class="hl-string">"hl-comment"># This is often the first step in the approval flow
                        activity = class="hl-string">'Approval Step Started'
                    elif action_code == class="hl-string">'APPROVE':
                        activity = class="hl-string">'Approval Step Approved'
                    elif action_code == class="hl-string">'REJECT':
                        activity = class="hl-string">'Approval Step Rejected'
                    elif action_code == class="hl-string">'RETURN':
                        activity = class="hl-string">'Approval Step Returned'
                    elif action_code == class="hl-string">'WITHDRAW':
                        activity = class="hl-string">'Requisition Withdrawn'
                    elif action_code == class="hl-string">'UPDATE':
                        activity = class="hl-string">'Requisition Amended'
                    
                    if activity:
                        event_log.append({**base_event, class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': action.get(class="hl-string">'ActionDate')})

            class=class="hl-string">"hl-comment"># 9-10 & 12. Final Status Events
            final_status = req.get(class="hl-string">'DocumentStatus')
            last_update_date = req.get(class="hl-string">'LastUpdateDate')
            if last_update_date:
                if final_status == class="hl-string">'APPROVED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Approved', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'REJECTED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Rejected', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'CLOSED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Closed', class="hl-string">'EventTime': last_update_date})

            class=class="hl-string">"hl-comment"># 11. Purchase Order Created
            if class="hl-string">'lines' in req and req[class="hl-string">'lines'] is not None:
                for line in req[class="hl-string">'lines']:
                    if line.get(class="hl-string">'PoHeaderId') and not po_created:
                        event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created', class="hl-string">'EventTime': line.get(class="hl-string">'LastUpdateDate', last_update_date)})
                        po_created = True class=class="hl-string">"hl-comment"># Create only one PO event per requisition
                        break
        
        total_processed += len(requisitions)
        print(fclass="hl-string">"Processed {total_processed} total requisitions so far.")

        class=class="hl-string">"hl-comment"># Check if there is more data to fetch for pagination
        has_more = data.get(class="hl-string">'hasMore', False)
        if has_more:
            params[class="hl-string">'offset'] += params[class="hl-string">'limit']

    class=class="hl-string">"hl-comment"># Write to CSV
    if event_log:
        filename = class="hl-string">'oracle_fusion_requisitions_event_log.csv'
        fieldnames = list(event_log[0].keys())
        with open(filename, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
            writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
            writer.writeheader()
            writer.writerows(event_log)
        print(fclass="hl-string">"\nSuccessfully extracted {len(event_log)} events to {filename}")
    else:
        print(class="hl-string">"\nNo events were generated.")

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

ขั้นตอน

ตรวจสอบว่า Oracle BI Cloud Connector เนื้อหาด้านการจัดซื้อที่จำเป็นของ Oracle Fusion Financials และสิทธิ์เข้าถึง Public View Objects ที่เกี่ยวข้องพร้อมใช้งานในสภาพแวดล้อมของคุณ ตรวจสอบด้วยว่าผู้ใช้ BICC หรือบัญชีเชื่อมต่อได้รับอนุญาตให้ดึงข้อมูลคำขอซื้อ ประวัติการอนุมัติ และใบสั่งซื้อ ชื่อบทบาทและเมนูอาจแตกต่างกันตามรุ่น Oracle ให้ใช้ส่วนดูแลระบบ BICC ที่เกี่ยวข้องใน tenant ของคุณ.
ระบุและเปิดใช้ PVO ที่จำเป็นสำหรับการดึงข้อมูล ใช้ RequisitionHeaderPVO หรือ PVO ส่วนหัวคำขอซื้อที่ตรงกันในสภาพแวดล้อมของคุณ ร่วมกับ PVO ที่แสดงรายการคำขอซื้อ ประวัติสถานะคำขอซื้อ ประวัติเวิร์กโฟลว์การอนุมัติ และข้อมูลอ้างอิงใบสั่งซื้อ อย่าสันนิษฐานว่า PVO เดียวมีประวัติเวิร์กโฟลว์หรือประวัติการสร้างใบสั่งซื้อ ให้บันทึกชื่อ PVO และแอตทริบิวต์ที่มีอยู่จริงใน tenant ของคุณ.
ตั้งค่างาน BICC สำหรับการดึงข้อมูลจำนวนมากแบบเพิ่มเฉพาะส่วนหรือย้อนหลัง กำหนดช่วงเวลาดึงข้อมูลด้วย [Start date parameter] และ [End date parameter] และตั้งค่าให้งานส่งไฟล์ CSV ไปยังตำแหน่งจัดเก็บบนคลาวด์ที่ได้รับอนุมัติ สำหรับการโหลดครั้งแรก ให้เลือกช่วงย้อนหลังที่ครอบคลุมเพียงพอ สำหรับการโหลดซ้ำ ให้ใช้ช่วงเวลาที่ทับซ้อนกันเพื่อเก็บการอัปเดตที่มาถึงล่าช้า จากนั้นลบเหตุการณ์ซ้ำโดยใช้รหัสกรณี กิจกรรม เวลาของเหตุการณ์ และรหัสเหตุการณ์ต้นทางเมื่อมี.
ตั้งค่าคอลัมน์ที่จะดึงข้อมูล โดยรวมรหัสคำขอซื้อ รหัสส่วนหัวและรายการคำขอซื้อ ผู้ขอ แผนก จำนวนเงิน สถานะ วันที่ต้องการ หน่วยธุรกิจ เหตุผลที่ปฏิเสธ เวลาที่สร้างและอัปเดต เวลาที่เปลี่ยนสถานะ เวลามอบหมายและดำเนินการอนุมัติ การดำเนินการอนุมัติ ข้อมูลอ้างอิงใบสั่งซื้อ และเวลารีเฟรช BICC ใช้ชื่อแอตทริบิวต์ตามที่ PVO ที่เลือกแสดง หากไม่มีแอตทริบิวต์ ให้แมปเป็น [Configure based on your system] และบันทึกข้อจำกัดไว้ แทนการใช้ฟิลด์ที่ยังไม่ได้ตรวจสอบ.
ดึงไฟล์ CSV ต้นทางและเก็บไฟล์ต้นฉบับไว้ โหลดแต่ละไฟล์ลงในพื้นที่ staging โดยเก็บชื่อ PVO ต้นทางและชื่อไฟล์ ปรับรูปแบบเวลาทั้งหมดให้เป็นเขตเวลาที่ตกลงกัน และแปลงค่าวันที่และเวลาของ Oracle ให้เป็นรูปแบบเดียวกัน เก็บรหัสต่างๆ เป็นข้อความเพื่อป้องกันเลขศูนย์นำหน้าหรือความแม่นยำสูญหาย.
ปรับโครงสร้างข้อมูลต้นทางเป็นตารางเหตุการณ์ โดยมีหนึ่งแถวต่อเหตุการณ์ทางธุรกิจที่เกิดขึ้นจริง ผลลัพธ์ต้องมี PurchaseRequisitionId, ActivityName, EventTime, SourceSystem และ LastDataUpdate เพิ่มแอตทริบิวต์ที่แนะนำเมื่อมีข้อมูล อย่าให้ ProcessMind อนุมานเหตุการณ์จากสถานะหรือการเปลี่ยนแปลงฟิลด์ การแปลงข้อมูลต้องสร้างแถวสำหรับกิจกรรมทั้ง 12 รายการที่ระบุไว้ในคำค้นอย่างชัดเจน.
สร้างแถวเหตุการณ์จากหลักฐานต้นทางที่เหมาะสม ใช้หลักฐานการสร้างระเบียนสำหรับ Requisition Created ใช้การเปลี่ยนสถานะการส่งอย่างชัดเจนสำหรับ Requisition Submitted ใช้การดำเนินการหรือการเปลี่ยนสถานะถอนคำขออย่างชัดเจนสำหรับ Requisition Withdrawn ตรวจจับการแก้ไขหลังส่งหรือเวอร์ชันใหม่สำหรับ Requisition Amended ใช้การมอบหมายในเวิร์กโฟลว์สำหรับ Approval Step Started และใช้การดำเนินการในประวัติการอนุมัติอย่างชัดเจนสำหรับ Approval Step Approved, Approval Step Rejected และ Approval Step Returned ใช้การเปลี่ยนสถานะโดยรวมอย่างชัดเจนสำหรับ Requisition Approved, Requisition Rejected และ Requisition Closed ใช้ระเบียนหรือเวลาสร้างใบสั่งซื้อที่เชื่อมโยงกับคำขอซื้ออย่างชัดเจนสำหรับ Purchase Order Created.
ลบข้อมูลซ้ำด้วยวิธีที่ให้ผลแน่นอน หากแถวต้นทางหลายแถวแทนเหตุการณ์เดียวกัน ให้เก็บไว้หนึ่งแถวโดยใช้เวลาของเหตุการณ์ที่เฉพาะเจาะจงที่สุดและรหัสต้นทางที่คงที่เมื่อมี อย่ารวมขั้นตอนอนุมัติที่แตกต่างกันเพียงเพราะใช้รหัสคำขอซื้อเดียวกัน ให้เก็บเหตุการณ์อนุมัติแยกกันสำหรับผู้อนุมัติหรือขั้นตอนเวิร์กโฟลว์แต่ละรายการ.
ตรวจสอบบันทึกเหตุการณ์ที่ได้ ยืนยันว่ามีกิจกรรมที่จำเป็นครบทุกประเภท ทุกเหตุการณ์มีรหัสกรณีและเวลาของเหตุการณ์ เวลาอยู่ในช่วงที่ดึงข้อมูลหรือมีคำอธิบายกรณีอัปเดตมาล่าช้า และมีแอตทริบิวต์ที่แนะนำเมื่อข้อมูลต้นทางมีให้ ตรวจสอบจำนวนคำขอซื้อและการเชื่อมโยงใบสั่งซื้อกับข้อมูลที่ดึงจากต้นทาง.
ส่งออกบันทึกเหตุการณ์ฉบับสุดท้ายเป็นไฟล์ UTF-8 CSV โดยมีแถวส่วนหัวหนึ่งแถวและหนึ่งเหตุการณ์ต่อแถว ใช้ชื่อคอลัมน์ PurchaseRequisitionId, ActivityName, EventTime, SourceSystem และ LastDataUpdate ให้ตรงตามนี้ พร้อมแอตทริบิวต์ที่แนะนำ อัปโหลดไฟล์ CSV ไปยัง ProcessMind และกำหนด PurchaseRequisitionId เป็นรหัสกรณี ActivityName เป็นกิจกรรม และ EventTime เป็นเวลาของเหตุการณ์.

การกำหนดค่า

วิธีดึงข้อมูล: ใช้ Oracle BI Cloud Connector ดึงข้อมูลจำนวนมากและส่งเป็นไฟล์ CSV ไปยังตำแหน่งจัดเก็บบนคลาวด์ที่กำหนดค่าไว้.
ออบเจ็กต์ต้นทาง: ใช้ RequisitionHeaderPVO และ PVO ที่เกี่ยวข้องสำหรับรายการคำขอซื้อ ประวัติสถานะ ประวัติเวิร์กโฟลว์การอนุมัติ และข้อมูลอ้างอิงใบสั่งซื้อที่มีใน tenant ต้องตรวจสอบชื่อ PVO และแอตทริบิวต์ที่ใช้ได้จริงในสภาพแวดล้อมของคุณ.
คอลัมน์ผลลัพธ์ที่จำเป็น: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem และ LastDataUpdate.
คอลัมน์ผลลัพธ์ที่แนะนำ: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason และ BusinessUnit.
ช่วงวันที่: ใช้ข้อมูลย้อนหลัง 3 ถึง 6 เดือนสำหรับการวิเคราะห์ตามปกติ หากต้องโหลดข้อมูลย้อนหลังครั้งแรก ให้ใช้ช่วงที่กว้างขึ้นตามความจำเป็น สำหรับการดึงข้อมูลซ้ำ ให้ใช้ช่วงเวลาที่ทับซ้อนกันเพื่อเก็บการอัปเดตที่มาถึงล่าช้า แล้วลบข้อมูลซ้ำ.
ตัวกรอง: ใช้ [Company-specific filter], [Document Type filter], [Business Unit filter] และ [Date range filter] เฉพาะเมื่อ PVO ที่เลือกมีแอตทริบิวต์เหล่านี้ ตรวจสอบว่าตัวกรองใช้กับวันที่สร้าง วันที่อัปเดต วันที่เปลี่ยนสถานะ หรือวันที่อื่นจากต้นทาง.
การดึงข้อมูลแบบเพิ่มเฉพาะส่วน: ควรใช้เวลาอัปเดตหรือกลไกการดึงข้อมูลแบบเพิ่มเฉพาะส่วนที่ BICC รองรับและเปิดเผยไว้ เก็บค่า watermark ของการดึงข้อมูลครั้งล่าสุดที่สำเร็จ และเผื่อช่วงเวลาทับซ้อนเล็กน้อยในการดึงข้อมูลครั้งถัดไป.
ความครบถ้วนของเหตุการณ์: ตั้งค่าการดึงข้อมูลจากต้นทางแยกกัน หากส่วนหัวคำขอซื้อไม่มีประวัติการอนุมัติ การเปลี่ยนสถานะ การแก้ไข หรือการสร้างใบสั่งซื้อ การดึงข้อมูลส่วนหัวที่แสดงเฉพาะสถานะปัจจุบันไม่เพียงพอสำหรับสร้างเหตุการณ์ย้อนหลังอย่างน่าเชื่อถือ.
ประสิทธิภาพ: จำกัดช่วงวันที่และคอลัมน์ที่เลือก แบ่งข้อมูลขนาดใหญ่เป็นส่วนๆ หากระบบรองรับ หลีกเลี่ยงแอตทริบิวต์คำอธิบายที่ไม่จำเป็น และประมวลผลไฟล์ CSV เป็นชุด เก็บไฟล์ต้นทางไว้สำหรับตรวจสอบเทียบข้อมูล.
พื้นที่จัดเก็บ: ตั้งค่าตำแหน่งจัดเก็บบนคลาวด์ที่ได้รับอนุมัติ โดยมีพื้นที่เพียงพอ กำหนดระยะเวลาเก็บรักษา การเข้ารหัส และการควบคุมการเข้าถึง ตรวจสอบว่าบัญชีที่ใช้ดึงข้อมูลเขียนไฟล์ได้ และกระบวนการแปลงข้อมูลอ่านไฟล์ได้.
ข้อกำหนดเบื้องต้น: ต้องมี BICC สิทธิ์เข้าถึงข้อมูลการจัดซื้อและการอนุมัติที่เกี่ยวข้องใน Oracle Fusion สิทธิ์การเชื่อมต่อที่เหมาะสม สิทธิ์เข้าถึง PVO ที่เลือก และการสมัครใช้บริการหรือสิทธิ์ใช้ฟีเจอร์ของ Oracle ตามที่กำหนด ชื่อบทบาท ไลเซนส์ และเส้นทางเมนูขึ้นอยู่กับรุ่น Oracle และการตั้งค่า tenant.
การจัดการเวลา: ปรับเวลาจากต้นทางทั้งหมดให้เป็นเขตเวลาที่ระบุไว้ และเก็บเวลาเดิมไว้เมื่อต้องตรวจสอบย้อนหลัง.
การกำหนดกรณี: ใช้ PurchaseRequisitionId เป็นรหัสกรณี อย่าใช้รหัสรายการคำขอซื้อเป็นรหัสกรณี เว้นแต่จะตั้งใจจำลองกระบวนการในระดับรายการ.

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

WITH
source_requisition AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([Creation timestamp attribute] AS TIMESTAMP) AS CreatedAt,
        CAST([Submission timestamp attribute] AS TIMESTAMP) AS SubmittedAt,
        CAST([Withdrawal timestamp attribute] AS TIMESTAMP) AS WithdrawnAt,
        CAST([Approval timestamp attribute] AS TIMESTAMP) AS ApprovedAt,
        CAST([Rejection timestamp attribute] AS TIMESTAMP) AS RejectedAt,
        CAST([Closure timestamp attribute] AS TIMESTAMP) AS ClosedAt,
        CAST([Last update timestamp attribute] AS TIMESTAMP) AS SourceLastUpdate,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition header extract or view]
    WHERE CAST([Last update timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Last update timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
      AND ([Company filter attribute] = '[Company-specific filter]' OR '[Company-specific filter]' = '[All companies]')
      AND ([Document type filter attribute] = '[Document Type filter]' OR '[Document Type filter]' = '[All document types]')
),
source_status_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Previous status attribute] AS VARCHAR(200)) AS PreviousStatus,
        CAST([New status attribute] AS VARCHAR(200)) AS NewStatus,
        CAST([Status change timestamp attribute] AS TIMESTAMP) AS StatusChangedAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition status history extract or view]
    WHERE CAST([Status change timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Status change timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_amendments AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Amendment timestamp attribute] AS TIMESTAMP) AS AmendedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition amendment or version extract or view]
    WHERE CAST([Amendment timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Amendment timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_approval_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Approval step identifier attribute] AS VARCHAR(200)) AS ApprovalStepId,
        CAST([Approver or approval group attribute] AS VARCHAR(500)) AS ApproverName,
        CAST([Approval action attribute] AS VARCHAR(200)) AS ApprovalAction,
        CAST([Approval assignment timestamp attribute] AS TIMESTAMP) AS ApprovalStartedAt,
        CAST([Approval action timestamp attribute] AS TIMESTAMP) AS ApprovalActionAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Approval workflow history extract or view]
    WHERE COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_purchase_orders AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) AS PurchaseOrderCreatedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Purchase order reference extract or view]
    WHERE CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT PurchaseRequisitionId, 'Requisition Created' AS ActivityName, CreatedAt AS EventTime, RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason, BusinessUnit, LastDataUpdate FROM source_requisition WHERE CreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Submitted', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('pending approval', 'submitted', 'pending') AND LOWER(COALESCE(h.PreviousStatus, '')) IN ('incomplete', 'draft')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Withdrawn', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('withdrawn', 'cancelled', 'canceled')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Requisition Amended', a.AmendedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_amendments a WHERE a.AmendedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Started', a.ApprovalStartedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalStartedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Approved', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('approved', 'approve')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Rejected', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('rejected', 'reject')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Returned', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('returned', 'return', 'sent back', 'send back')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Approved', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'approved'
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Rejected', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'rejected'
    UNION ALL
    SELECT p.PurchaseRequisitionId, 'Purchase Order Created', p.PurchaseOrderCreatedAt, p.RequesterName, p.DepartmentName, p.RequisitionTotalAmount, p.RequisitionStatus, p.RequiredByDate, p.RejectionReason, p.BusinessUnit, p.LastDataUpdate FROM source_purchase_orders p WHERE p.PurchaseOrderCreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Closed', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('closed', 'finally closed', 'complete', 'completed')
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    'Oracle Fusion Financials' AS SourceSystem,
    LastDataUpdate,
    RequesterName,
    DepartmentName,
    RequisitionTotalAmount,
    RequisitionStatus,
    RequiredByDate,
    RejectionReason,
    BusinessUnit
FROM events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

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

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

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

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

ลดระยะเวลากระบวนการจัดซื้อจนถึงชำระเงินสำหรับคำขอซื้อลง 30%

ปรับกระบวนการคำขอซื้อ Oracle P2P ให้กระชับขึ้น และลดระยะเวลาของวงจรลง 30%.

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

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

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

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

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

กิจกรรมในกระบวนการจัดซื้อจนถึงชำระเงินสำหรับคำขอซื้อ

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

ส่งออกข้อมูลจาก Oracle Transactional Business Intelligence (OTBI)

ขั้นตอน

การกำหนดค่า

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

ดึงข้อมูลด้วย SQL จาก Oracle BI Publisher Data Model

ขั้นตอน

การกำหนดค่า

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

ใช้สคริปต์ Python ผ่าน Oracle Fusion REST API

ขั้นตอน

การกำหนดค่า

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

ดึงข้อมูลจำนวนมากด้วย Oracle BI Cloud Connector (BICC)

ขั้นตอน

การกำหนดค่า

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

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

ลดระยะเวลากระบวนการจัดซื้อจนถึงชำระเงินสำหรับคำขอซื้อลง 30%