> การปรับปรุงกระบวนการอย่างต่อเนื่อง > Purchase to Pay ใบขอซื้อ > Coupa > เทมเพลตข้อมูล

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

Coupa

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

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

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

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

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

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

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

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

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

	ชื่อ	คำอธิบาย
	ID ใบขอซื้อ PurchaseRequisitionId	รหัสเฉพาะของใบขอซื้อแต่ละรายการ ใช้เป็น ID หลักของกรณีในกระบวนการ.
คำอธิบาย ID ใบขอซื้อเป็นรหัสหลักที่เชื่อมโยงกิจกรรมทั้งหมดของคำขอซื้อสินค้าหรือบริการหนึ่งรายการ ใบขอซื้อแต่ละรายการจะได้รับ ID เฉพาะเมื่อสร้าง และใช้รหัสเดิมตลอดวงจรชีวิต จึงติดตามได้ตั้งแต่สร้างและส่งคำขอ ผ่านขั้นตอนอนุมัติหรือปฏิเสธ ไปจนถึงการจัดหาและปิดรายการ ใน process mining รายการในบันทึกเหตุการณ์ทุกรายการจะเชื่อมโยงกับ ID นี้ ทำให้สร้างลำดับเหตุการณ์ทั้งหมดของแต่ละกรณีขึ้นใหม่ได้. เหตุผลที่สำคัญ นี่คือ Case ID หลักที่เชื่อมโยงทุกขั้นตอนของกระบวนการ ทำให้วิเคราะห์วงจรชีวิตของใบขอซื้อได้ตั้งแต่ต้นจนจบ. แหล่งข้อมูล ฟิลด์คีย์หลักนี้อยู่ในโมดูล Requisitions ของ Coupa และไฟล์ส่งออกข้อมูลที่เกี่ยวข้อง. ตัวอย่าง PR-102934PR-102935PR-102936
	ชื่อกิจกรรม ActivityName	ชื่อกิจกรรมทางธุรกิจหรือเหตุการณ์ที่เกิดขึ้นกับใบขอซื้อ ณ เวลาหนึ่ง.
คำอธิบาย แอตทริบิวต์นี้บันทึกขั้นตอนต่างๆ ในวงจรชีวิตของใบขอซื้อ ตัวอย่างเช่น “สร้างใบขอซื้อ” “อนุมัติขั้นตอนการอนุมัติ” และ “ส่งใบขอซื้อเข้าสู่การจัดหา” แต่ละกิจกรรมแสดงถึงหมุดหมายหรือการดำเนินการเฉพาะกับใบขอซื้อ การวิเคราะห์ลำดับและความถี่ของกิจกรรมเหล่านี้เป็นพื้นฐานของ process mining เพราะช่วยให้เห็นแผนผังกระบวนการ ระบุเส้นทางที่เกิดขึ้นบ่อย และตรวจพบความเบี่ยงเบนจากขั้นตอนมาตรฐาน. เหตุผลที่สำคัญ แอตทริบิวต์นี้กำหนดขั้นตอนในแผนผังกระบวนการ ทำให้เห็นภาพและวิเคราะห์ลำดับการดำเนินงานของใบขอซื้อได้. แหล่งข้อมูล โดยทั่วไปได้จากบันทึกเหตุการณ์ ระเบียนการเปลี่ยนสถานะ หรือบันทึกการตรวจสอบในระบบ Coupa อาจต้องจับคู่ข้อมูลจากฟิลด์สถานะหรือรหัสการดำเนินการ. ตัวอย่าง สร้างใบขอซื้อส่งใบขอซื้ออนุมัติขั้นตอนอนุมัติปฏิเสธใบขอซื้อสร้างใบสั่งซื้อ
	เวลาที่เกิดเหตุการณ์ EventTime	วันที่และเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ.
คำอธิบาย เวลาที่เกิดเหตุการณ์หรือเวลาประทับระบุช่วงเวลาที่บันทึกกิจกรรมของใบขอซื้อไว้อย่างแม่นยำ ข้อมูลนี้สำคัญต่อการเรียงเหตุการณ์ตามลำดับเวลาเพื่อสร้างลำดับการดำเนินงาน และเป็นพื้นฐานของการวิเคราะห์ตามเวลา ทั้งการคำนวณระยะเวลาดำเนินการ การระบุคอขวดจากระยะเวลาระหว่างกิจกรรม และการทำความเข้าใจผลการปฏิบัติงานของกระบวนการในช่วงเวลาต่างๆ การวิเคราะห์กระบวนการให้ได้ผลต้องอาศัยเวลาประทับที่ถูกต้องและละเอียด. เหตุผลที่สำคัญ เวลาประทับนี้จำเป็นต่อการเรียงเหตุการณ์ให้ถูกต้องและคำนวณตัวชี้วัดตามระยะเวลาทั้งหมด เช่น ระยะเวลาดำเนินการและคอขวด. แหล่งข้อมูล ข้อมูลนี้บันทึกไว้ในบันทึกการตรวจสอบหรือประวัติของใบขอซื้อแต่ละรายการใน Coupa โดยมักอยู่ในฟิลด์ “created_at” หรือ “updated_at” ของแต่ละการดำเนินการ. ตัวอย่าง 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
	ระบบต้นทาง SourceSystem	ระบุระบบต้นทางที่ดึงข้อมูลมา.
คำอธิบาย แอตทริบิวต์นี้ระบุระบบบันทึกข้อมูลต้นทางของข้อมูลกระบวนการ สำหรับการวิเคราะห์นี้ ค่าจะเป็น “Coupa” เสมอ การใส่ฟิลด์นี้เป็นแนวทางปฏิบัติที่ดี โดยเฉพาะเมื่อรวมข้อมูลจากหลายระบบ ช่วยให้เข้าใจที่มาของข้อมูลและจัดการธรรมาภิบาลข้อมูลกับกฎด้านคุณภาพได้. เหตุผลที่สำคัญ ช่วยระบุที่มาของข้อมูลได้ชัดเจน ซึ่งสำคัญต่อธรรมาภิบาลข้อมูลและการรวมข้อมูลจากระบบองค์กรหลายระบบ. แหล่งข้อมูล โดยทั่วไปจะกำหนดค่าไว้คงที่ระหว่างการดึงและแปลงข้อมูล เพื่อระบุแหล่งที่มาของชุดข้อมูล. ตัวอย่าง Coupa
	อัปเดตข้อมูลล่าสุด LastDataUpdate	เวลาประทับที่ระบุว่าดึงข้อมูลจากระบบต้นทางมาอัปเดตครั้งล่าสุดเมื่อใด.
คำอธิบาย แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงข้อมูลจาก Coupa ล่าสุด ช่วยให้เห็นว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลใหม่เพียงใด ผู้ใช้จำเป็นต้องทราบว่าข้อมูลสะท้อนสถานะการปฏิบัติการปัจจุบันหรือสถานะในช่วงก่อน โดยเฉพาะแดชบอร์ดที่ติดตามการปฏิบัติการที่กำลังดำเนินอยู่. เหตุผลที่สำคัญ ช่วยให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด เข้าใจช่วงเวลาที่ใช้วิเคราะห์ และตัดสินใจจากข้อมูลล่าสุด. แหล่งข้อมูล ระบบข้อมูลหรือเครื่องมือ ETL จะสร้างและเพิ่มเวลาประทับนี้เมื่อการดึงข้อมูลเสร็จสมบูรณ์. ตัวอย่าง 2024-05-21T02:00:00Z
	ผู้ขอ Requester	พนักงานที่สร้างและส่งใบขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้ระบุผู้เริ่มคำขอ การวิเคราะห์ข้อมูลตามผู้ขอช่วยให้เห็นรูปแบบที่เกี่ยวข้องกับผู้ใช้แต่ละคน เช่น การแก้ไขบ่อยหรือถูกปฏิเสธบ่อย ซึ่งอาจแสดงว่าควรจัดการฝึกอบรมเพิ่มเติม นอกจากนี้ยังใช้วิเคราะห์ปริมาณใบขอซื้อและพฤติกรรมในกระบวนการของผู้ใช้หรือกลุ่มผู้ใช้ต่างๆ ได้ด้วย. เหตุผลที่สำคัญ ช่วยวิเคราะห์พฤติกรรมในกระบวนการตามผู้ใช้ เพื่อระบุความต้องการในการฝึกอบรมและทำความเข้าใจว่าผู้ใช้แต่ละคนมีปฏิสัมพันธ์กับกระบวนการอย่างไร. แหล่งข้อมูล เป็นฟิลด์มาตรฐานในออบเจ็กต์ Requisition ของ Coupa ซึ่งมักเชื่อมโยงกับออบเจ็กต์ User และใช้ชื่อ “requester” หรือ “created_by”. ตัวอย่าง Alice JohnsonBob SmithCharlie Brown
	ผู้อนุมัติ Approver	ผู้ใช้หรือกลุ่มที่รับผิดชอบกิจกรรมการอนุมัติ.
คำอธิบาย แอตทริบิวต์นี้ระบุบุคคลหรือกลุ่มผู้อนุมัติที่ได้รับมอบหมายให้ดำเนินการในแต่ละขั้นตอน โดยจะมีข้อมูลสำหรับกิจกรรม เช่น “เริ่มขั้นตอนการอนุมัติ” “อนุมัติขั้นตอนการอนุมัติ” และ “ปฏิเสธขั้นตอนการอนุมัติ” การวิเคราะห์ข้อมูลตามผู้อนุมัติเป็นหัวใจสำคัญของแดชบอร์ด “ผลการปฏิบัติงานและภาระงานของผู้อนุมัติ” ช่วยวัดเวลาที่ใช้อนุมัติแต่ละรายการ ระบุคอขวดที่เกิดจากผู้อนุมัติบางราย และประเมินการกระจายภาระงาน. เหตุผลที่สำคัญ สำคัญต่อการวิเคราะห์ผลการปฏิบัติงานของผู้อนุมัติ การกระจายภาระงาน และการระบุคอขวดที่เกี่ยวข้องกับบุคคลหรือกลุ่มผู้อนุมัติโดยเฉพาะ. แหล่งข้อมูล ข้อมูลนี้อยู่ในรายละเอียดลำดับการอนุมัติของใบขอซื้อแต่ละรายการใน Coupa อาจต้องเชื่อมข้อมูลกับ User. ตัวอย่าง David Millerกลุ่มผู้อนุมัติฝ่ายการเงินระดับ 2Susan Chen
	แผนก Department	แผนกธุรกิจหรือศูนย์ต้นทุนที่รับค่าใช้จ่ายของใบขอซื้อ.
คำอธิบาย แอตทริบิวต์แผนกเชื่อมโยงใบขอซื้อแต่ละรายการกับหน่วยงานหรือศูนย์ต้นทุนที่ระบุ จึงเป็นมิติสำคัญสำหรับการเปรียบเทียบ คุณสามารถกรองและแบ่งข้อมูลในแดชบอร์ดกับ KPI ตามแผนก เพื่อให้ผู้จัดการเปรียบเทียบระยะเวลาการอนุมัติ อัตราการปฏิเสธ และการปฏิบัติตามข้อกำหนดในแต่ละส่วนขององค์กรได้ ช่วยระบุปัญหาหรือแนวทางปฏิบัติที่ดีเฉพาะแผนก. เหตุผลที่สำคัญ ช่วยเปรียบเทียบ KPI ของกระบวนการ เช่น ระยะเวลาดำเนินการและอัตราการปฏิเสธระหว่างหน่วยธุรกิจต่างๆ เพื่อระบุจุดที่ควรปรับปรุง. แหล่งข้อมูล ฟิลด์มาตรฐานในออบเจ็กต์ Requisition ของ Coupa ซึ่งมักเชื่อมโยงกับโปรไฟล์ผู้ขอ หรือระบุไว้ในรายการสินค้าในใบขอซื้อ. ตัวอย่าง การตลาดการปฏิบัติการด้าน ITอาคารสถานที่วิจัยและพัฒนา
	ยอดรวม TotalAmount	มูลค่ารวมของใบขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้แสดงค่าใช้จ่ายรวมของสินค้าและบริการทั้งหมดที่ขอซื้อ จำนวนเงินเป็นปัจจัยสำคัญในการวิเคราะห์กระบวนการ เพราะมักส่งผลต่อความซับซ้อนของเวิร์กโฟลว์การอนุมัติ โดยใบขอซื้อที่มีมูลค่าสูงมักต้องผ่านขั้นตอนอนุมัติมากกว่า การวิเคราะห์ตัวชี้วัดตามช่วงมูลค่า เช่น <$1000 หรือ $1000-$10000 ช่วยให้เห็นว่ากระบวนการจัดการใบขอซื้อที่มีมูลค่าต่างกันอย่างไร. เหตุผลที่สำคัญ ช่วยวิเคราะห์ความแตกต่างของกระบวนการตามมูลค่าใบขอซื้อ เนื่องจากยอดที่สูงขึ้นมักทำให้เวิร์กโฟลว์การอนุมัติซับซ้อนขึ้น. แหล่งข้อมูล ฟิลด์มาตรฐานในส่วนหัวของออบเจ็กต์ Requisition ใน Coupa ซึ่งมักใช้ชื่อ “total” หรือ “total_amount”. ตัวอย่าง 500.0012550.7599.99
	สถานะใบขอซื้อ RequisitionStatus	สถานะปัจจุบันหรือสถานะสุดท้ายของใบขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้ระบุสถานะโดยรวมของใบขอซื้อขณะดึงข้อมูล หรือผลลัพธ์สุดท้าย สถานะที่พบบ่อย ได้แก่ “รอการอนุมัติ” “อนุมัติแล้ว” “ปฏิเสธแล้ว” “ถอนแล้ว” และ “ปิดแล้ว” ใช้เป็นมิติหลักในการกรองและวิเคราะห์ข้อมูล รวมถึงคำนวณอัตราการอนุมัติและการปฏิเสธ ติดตามปริมาณใบขอซื้อที่ยังเปิดอยู่ และทำความเข้าใจผลลัพธ์สุดท้ายของคำขอ. เหตุผลที่สำคัญ จำเป็นต่อการทำความเข้าใจผลลัพธ์ของใบขอซื้อ คำนวณอัตราการอนุมัติและการปฏิเสธ และติดตามสถานะปัจจุบันของใบขอซื้อที่อยู่ระหว่างดำเนินการ. แหล่งข้อมูล ฟิลด์มาตรฐานในออบเจ็กต์ Purchase Requisition ของ Coupa ซึ่งมักใช้ชื่อ “status” หรือ “state”. ตัวอย่าง รอการอนุมัติอนุมัติแล้วปฏิเสธแล้วถอนแล้วปิดแล้ว
	ID ใบสั่งซื้อ PurchaseOrderId	รหัสของใบสั่งซื้อที่สร้างจากใบขอซื้อที่ได้รับอนุมัติ.
คำอธิบาย เมื่อใบขอซื้อได้รับอนุมัติครบถ้วนและผ่านการจัดหาแล้ว โดยทั่วไปจะสร้างใบสั่งซื้อ แอตทริบิวต์นี้เก็บ ID ของ PO ที่สร้างขึ้น และเชื่อมโยงกระบวนการใบขอซื้อในขั้นต้นกับกระบวนการใบสั่งซื้อในขั้นถัดไป ช่วยคำนวณ KPI “เวลาตั้งแต่อนุมัติใบขอซื้อจนถึงสร้าง PO” และวิเคราะห์วงจร Purchase-to-Pay ทั้งหมดตั้งแต่ต้นจนจบได้. เหตุผลที่สำคัญ เชื่อมโยงใบขอซื้อกับใบสั่งซื้อในขั้นตอนถัดไป ช่วยวิเคราะห์เวลาส่งต่องานและดูภาพรวม P2P ตั้งแต่ต้นจนจบ. แหล่งข้อมูล ฟิลด์มาตรฐานในออบเจ็กต์ Requisition ของ Coupa ซึ่งจะมีข้อมูลหลังจากสร้าง PO แล้ว. ตัวอย่าง PO-45000123PO-45000124PO-45000125
	จำนวนขั้นตอนการอนุมัติ ApprovalStepCount	จำนวนขั้นตอนการอนุมัติทั้งหมดที่ใบขอซื้อผ่าน.
คำอธิบาย แอตทริบิวต์ที่คำนวณนี้นับจำนวนกิจกรรม 'อนุมัติขั้นตอนการอนุมัติ' ที่ไม่ซ้ำกันของใบขอซื้อแต่ละรายการ ช่วยวัดความซับซ้อนของเวิร์กโฟลว์การอนุมัติในแต่ละกรณี และเป็นข้อมูลพื้นฐานสำหรับ KPI 'จำนวนขั้นตอนการอนุมัติเฉลี่ย' นอกจากนี้ยังช่วยระบุใบขอซื้อที่ผ่านเส้นทางอนุมัติยาวหรือซับซ้อนผิดปกติ ซึ่งอาจบ่งชี้ว่าควรปรับเวิร์กโฟลว์ให้กระชับขึ้น. เหตุผลที่สำคัญ ใช้วัดความซับซ้อนของเวิร์กโฟลว์การอนุมัติในใบขอซื้อแต่ละรายการ และช่วยระบุเส้นทางที่ซับซ้อนเกินไปซึ่งควรปรับให้กระชับขึ้น. แหล่งข้อมูล คำนวณเมตริกนี้ในเครื่องมือ process mining โดยนับจำนวนครั้งที่เกิด 'อนุมัติขั้นตอนการอนุมัติ' สำหรับ Case ID แต่ละรายการ. ตัวอย่าง 253
	ชื่อผู้จำหน่าย SupplierName	ชื่อผู้จำหน่ายหรือผู้ขายที่เลือกสำหรับใบขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้ระบุผู้จำหน่ายที่ต้องการซื้อสินค้าหรือบริการด้วย ผู้ขออาจระบุผู้จำหน่ายไว้ตั้งแต่ต้น หรือเพิ่มภายหลังระหว่างการจัดหา การวิเคราะห์ตัวชี้วัดของกระบวนการตามผู้จำหน่ายช่วยประเมินผลการดำเนินงานและดูว่าการติดต่อกับผู้จำหน่ายบางรายทำให้ระยะเวลาดำเนินการนานขึ้นหรือเกิดปัญหาอื่นหรือไม่ ข้อมูลนี้ยังช่วยประกอบการวางกลยุทธ์การจัดซื้อและการบริหารความสัมพันธ์กับผู้จำหน่าย. เหตุผลที่สำคัญ ช่วยวิเคราะห์ผลการดำเนินงานของกระบวนการตามผู้จำหน่ายที่เลือก และนำข้อมูลไปใช้วางกลยุทธ์การจัดหากับบริหารผู้จำหน่าย. แหล่งข้อมูล ข้อมูลนี้อยู่ในออบเจ็กต์ Requisition Line ของ Coupa โดยมักอยู่ในฟิลด์ “supplier” หรือ “vendor”. ตัวอย่าง StaplesDell TechnologiesAccentureCDW
	ประเภทใบขอซื้อ RequisitionType	หมวดหมู่หรือประเภทของใบขอซื้อ เช่น “รายจ่ายลงทุน” “ค่าใช้จ่ายในการดำเนินงาน” หรือ “ซอฟต์แวร์”.
คำอธิบาย ประเภทใบขอซื้อใช้จัดหมวดหมู่ตามวัตถุประสงค์ทางธุรกิจหรือลักษณะของสิ่งที่ขอซื้อ แอตทริบิวต์นี้มีประโยชน์ต่อการวิเคราะห์การปฏิบัติตามข้อกำหนดและทำความเข้าใจว่าคำขอแต่ละประเภทผ่านกระบวนการอย่างไร ตัวอย่างเช่น คำขอรายจ่ายลงทุนอาจมีขั้นตอนอนุมัติที่เข้มงวดและใช้เวลานานกว่าคำขอค่าใช้จ่ายในการดำเนินงานทั่วไป การวิเคราะห์กระบวนการตามประเภทใบขอซื้อช่วยให้พบแนวทางปรับปรุงกระบวนการได้. เหตุผลที่สำคัญ ช่วยแบ่งการวิเคราะห์ตามวัตถุประสงค์ทางธุรกิจของคำขอ เนื่องจากคำขอแต่ละประเภทอาจมีลำดับการดำเนินงานและนโยบายต่างกัน. แหล่งข้อมูล น่าจะเป็นฟิลด์จัดประเภทมาตรฐานหรือฟิลด์ที่กำหนดเองในออบเจ็กต์ Requisition ของ Coupa. ตัวอย่าง รายจ่ายลงทุนค่าใช้จ่ายในการดำเนินงานอุปกรณ์ ITบริการวิชาชีพ
	มีการแก้ไขหรือไม่ IsAmended	ค่าบูลีนที่เป็น true หากมีการแก้ไขใบขอซื้ออย่างน้อยหนึ่งครั้งหลังจากส่งครั้งแรก.
คำอธิบาย แอตทริบิวต์คำนวณนี้เป็นค่าสถานะอย่างง่าย (True/False) ที่ระบุว่ามีกิจกรรม “แก้ไขใบขอซื้อ” ในกรณีนั้นหรือไม่ ช่วยให้วิเคราะห์และกรองข้อมูลได้ง่าย โดยแยกใบขอซื้อที่ต้องแก้ไขออกมาได้สะดวก ใช้คำนวณ KPI อัตราการแก้ไขใบขอซื้อ และแสดงข้อมูลในแดชบอร์ด “ปริมาณการแก้ไขใบขอซื้อ” เพื่อช่วยค้นหาสาเหตุของการทำงานซ้ำและปรับปรุงคุณภาพตั้งแต่ครั้งแรก. เหตุผลที่สำคัญ ช่วยคำนวณ KPI อัตราการแก้ไขได้ง่ายขึ้น และแบ่งกรณีที่ต้องกลับไปแก้ไขออกจากกรณีที่ไม่ต้องแก้ไขได้สะดวก. แหล่งข้อมูล คำนวณในเครื่องมือ process mining โดยตรวจสอบว่ามีกิจกรรม “แก้ไขใบขอซื้อ” ในบันทึกเหตุการณ์ของแต่ละกรณีหรือไม่. ตัวอย่าง truefalse
	ระดับความเร่งด่วน UrgencyLevel	การจัดระดับความเร่งด่วนของใบขอซื้อ เช่น “สูง” “ปานกลาง” หรือ “ต่ำ”.
คำอธิบาย ระดับความเร่งด่วน ซึ่งมักเชื่อมโยงกับฟิลด์ลำดับความสำคัญ ช่วยให้ผู้ขอระบุคำขอที่ต้องดำเนินการเร่งด่วน แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด “ระยะเวลาดำเนินการใบขอซื้อเร่งด่วน” การเปรียบเทียบระยะเวลาดำเนินการของใบขอซื้อเร่งด่วนกับคำขอทั่วไปช่วยให้องค์กรประเมินได้ว่าการจัดลำดับความสำคัญได้ผลหรือไม่ และตอบสนองความต้องการเร่งด่วนทางธุรกิจได้ทันเวลาหรือไม่. เหตุผลที่สำคัญ ช่วยวิเคราะห์ว่าคำขอเร่งด่วนได้รับการดำเนินการเร็วกว่าคำขอทั่วไปหรือไม่ เพื่อประเมินว่านโยบายจัดลำดับความสำคัญได้ผลเพียงใด. แหล่งข้อมูล อาจเป็นฟิลด์มาตรฐานหรือฟิลด์ที่กำหนดเองในออบเจ็กต์ Requisition ของ Coupa โปรดตรวจสอบเอกสารหรือการตั้งค่าระบบของ Coupa. ตัวอย่าง สูงปานกลางต่ำ
	ระยะเวลาของขั้นตอนการอนุมัติ ApprovalStepDuration	เวลาที่ใบขอซื้อรออยู่ในขั้นตอนการอนุมัติหนึ่งขั้นตอน.
คำอธิบาย ตัวชี้วัดที่คำนวณนี้วัดระยะเวลาตั้งแต่กิจกรรม “เริ่มขั้นตอนการอนุมัติ” จนถึงกิจกรรม “อนุมัติขั้นตอนการอนุมัติ” หรือ “ปฏิเสธขั้นตอนการอนุมัติ” ที่เกี่ยวข้อง โดยแยกเวลารอในแต่ละขั้นตอนของลำดับการอนุมัติ ข้อมูลนี้สำคัญต่อแดชบอร์ด “คอขวดในขั้นตอนอนุมัติที่สำคัญ” เพราะช่วยระบุได้อย่างชัดเจนว่าผู้อนุมัติหรือขั้นตอนใดทำให้กระบวนการโดยรวมล่าช้ามากที่สุด. เหตุผลที่สำคัญ ระบุคอขวดในเวิร์กโฟลว์การอนุมัติได้อย่างชัดเจน โดยวัดเวลารอในแต่ละขั้นตอน แทนที่จะดูแค่เวลาตั้งแต่เริ่มจนจบทั้งหมด. แหล่งข้อมูล คำนวณในเครื่องมือ process mining โดยหาผลต่างระหว่างเวลาของเหตุการณ์ 'เริ่มขั้นตอนการอนุมัติ' กับเหตุการณ์อนุมัติขั้นสุดท้ายที่เกิดขึ้นถัดมา (อนุมัติ/ปฏิเสธ). ตัวอย่าง 1.2 วัน4 ชั่วโมง3.8 วัน
	สกุลเงิน Currency	รหัสสกุลเงินของยอดรวมใบขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้ระบุสกุลเงิน เช่น USD, EUR หรือ GBP ที่ใช้แสดงยอดรวมของใบขอซื้อ ซึ่งเป็นข้อมูลสำคัญสำหรับการวิเคราะห์ทางการเงิน โดยเฉพาะองค์กรข้ามชาติที่ใช้หลายสกุลเงิน ช่วยให้ตีความมูลค่าเงินได้ถูกต้อง และแปลงหรือรวมยอดสำหรับรายงานทางการเงินและแดชบอร์ดได้เหมาะสม. เหตุผลที่สำคัญ ให้ข้อมูลที่จำเป็นสำหรับแอตทริบิวต์ “ยอดรวม” เพื่อให้วิเคราะห์ทางการเงินในสภาพแวดล้อมที่ใช้หลายสกุลเงินได้อย่างถูกต้อง. แหล่งข้อมูล ฟิลด์มาตรฐานในออบเจ็กต์ Requisition ของ Coupa ซึ่งมักใช้ชื่อ “currency_code” หรือชื่อใกล้เคียง. ตัวอย่าง USDEURGBP
	เส้นทางเวิร์กโฟลว์การอนุมัติ ApprovalWorkflowPath	รหัสระบุลำดับการอนุมัติหรือเทมเพลตเวิร์กโฟลว์ที่ใช้กับใบขอซื้อ.
คำอธิบาย แอตทริบิวต์นี้ระบุลำดับผู้อนุมัติที่กำหนดไว้ ซึ่งใบขอซื้อควรผ่านตามลำดับ โดยกำหนดจากกฎทางธุรกิจที่มักพิจารณาปัจจัยต่างๆ เช่น จำนวนเงิน แผนก และประเภทใบขอซื้อ แอตทริบิวต์นี้เป็นข้อมูลหลักของแดชบอร์ด “การปฏิบัติตามนโยบายใบขอซื้อ” การเปรียบเทียบลำดับผู้อนุมัติที่เกิดขึ้นจริงกับเส้นทางเวิร์กโฟลว์ที่กำหนดไว้ช่วยตรวจพบความเบี่ยงเบน วัดระดับการปฏิบัติตามข้อกำหนด และระบุกรณียกเว้นที่ไม่มีการจัดการ. เหตุผลที่สำคัญ ช่วยวิเคราะห์การปฏิบัติตามข้อกำหนด โดยเปรียบเทียบขั้นตอนอนุมัติที่คาดไว้กับขั้นตอนที่เกิดขึ้นจริง เพื่อให้เห็นความเบี่ยงเบนของกระบวนการ. แหล่งข้อมูล โปรดตรวจสอบเอกสารของ Coupa ข้อมูลนี้อาจได้จากชื่อของลำดับการอนุมัติหรือกฎเวิร์กโฟลว์ที่เรียกใช้กับใบขอซื้อ. ตัวอย่าง อนุมัติมาตรฐาน <$5kอนุมัติอุปกรณ์ IT >$10kตรวจสอบรายจ่ายลงทุนโดย CFO
	หมวดสินค้า Commodity	หมวดหมู่ระดับสูงของสินค้าหรือบริการที่ขอซื้อ.
คำอธิบาย แอตทริบิวต์หมวดสินค้าและบริการใช้จัดประเภทสินค้าในใบขอซื้อให้เป็นมาตรฐาน เช่น “อุปกรณ์สำนักงาน” “อุปกรณ์คอมพิวเตอร์” หรือ “บริการด้านการตลาด” ช่วยวิเคราะห์รูปแบบการจัดซื้อและความแตกต่างของกระบวนการตามสินค้าที่ซื้อ สินค้าบางหมวดอาจต้องผ่านขั้นตอนอนุมัติหรือใช้กลยุทธ์การจัดหาเฉพาะ การวิเคราะห์กระบวนการตามหมวดสินค้าจึงช่วยปรับปรุงการจัดซื้อในแต่ละหมวดค่าใช้จ่ายได้. เหตุผลที่สำคัญ ช่วยวิเคราะห์หมวดค่าใช้จ่ายและดูว่าพฤติกรรมของกระบวนการ เช่น ระยะเวลาการอนุมัติ แตกต่างกันตามประเภทสินค้าหรือบริการที่ซื้อหรือไม่. แหล่งข้อมูล ฟิลด์มาตรฐานใน Coupa ซึ่งโดยทั่วไปมีอยู่ในระดับรายการสินค้าในใบขอซื้อ อาจต้องรวมข้อมูลขึ้นไปที่ระดับส่วนหัว. ตัวอย่าง อุปกรณ์สำนักงานอุปกรณ์คอมพิวเตอร์บริการด้านการตลาดการเดินทาง
	เหตุผลที่ปฏิเสธ RejectionReason	เหตุผลที่ผู้อนุมัติระบุเมื่อปฏิเสธใบขอซื้อหรือขั้นตอนการอนุมัติ.
คำอธิบาย เมื่อผู้อนุมัติปฏิเสธใบขอซื้อ มักระบุเหตุผลประกอบการตัดสินใจ แอตทริบิวต์นี้บันทึกคำอธิบายดังกล่าว การวิเคราะห์เหตุผลที่ปฏิเสธช่วยให้เข้าใจโดยตรงว่าทำไมใบขอซื้อจึงไม่ผ่าน และเป็นข้อมูลสำคัญสำหรับค้นหาสาเหตุหลัก เช่น การลงรหัสไม่ถูกต้อง งบประมาณไม่เพียงพอ หรือเหตุผลประกอบไม่ชัดเจน จากนั้นจึงแก้ไขได้ด้วยการฝึกอบรมหรือปรับปรุงกระบวนการ. เหตุผลที่สำคัญ ช่วยให้เห็นสาเหตุหลักของปัญหาในกระบวนการโดยตรง และระบุจุดที่ควรฝึกอบรมผู้ใช้หรือชี้แจงกระบวนการเพิ่มเติม. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้บันทึกไว้ในฟิลด์ความคิดเห็นหรือหมายเหตุที่เชื่อมโยงกับการเปลี่ยนสถานะเป็น “Rejected” ในประวัติการอนุมัติของใบขอซื้อ. ตัวอย่าง ศูนย์ต้นทุนไม่ถูกต้องเกินงบประมาณของไตรมาสนี้คำขอซ้ำให้เหตุผลประกอบไม่เพียงพอ

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

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

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

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

	กิจกรรม	คำอธิบาย
	ปฏิเสธใบขอซื้อ	ใบขอซื้อถูกปฏิเสธในระหว่างกระบวนการอนุมัติอย่างเด็ดขาด และจะไม่ถูกแปลงเป็นใบสั่งซื้อ อนุมานได้จากสถานะโดยรวมในส่วนหัวของใบขอซื้อที่เปลี่ยนเป็น “rejected”.
เหตุผลที่สำคัญ กิจกรรมนี้แสดงถึงความล้มเหลวที่ทำให้กระบวนการสิ้นสุดลง การวิเคราะห์เหตุการณ์เหล่านี้ช่วยลด “อัตราการปฏิเสธใบขอซื้อ” และค้นหาสาเหตุหลัก เช่น การไม่ปฏิบัติตามนโยบายหรือปัญหาด้านงบประมาณ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในตาราง “requisition_headers” เมื่อฟิลด์ “status” เปลี่ยนเป็น “rejected” โดยมีการบันทึกเวลาไว้ในบันทึกการตรวจสอบที่เกี่ยวข้อง. บันทึก ระบุเวลาที่สถานะโดยรวมของใบขอซื้อเปลี่ยนเป็น “rejected”. ประเภทเหตุการณ์ inferred
	ปิดใบขอซื้อ	ปิดใบขอซื้ออย่างเป็นทางการ หมายความว่าจะไม่มีการดำเนินการใดต่อไป อาจเกิดขึ้นหลังสร้างและดำเนินการตาม PO เสร็จแล้ว หรือเมื่อยกเลิกใบขอซื้อหลังได้รับอนุมัติแต่ก่อนสั่งซื้อ.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดที่ชัดเจนของวงจรชีวิตใบขอซื้อ ช่วยให้แต่ละกรณีมีข้อสรุปและไม่แสดงเป็น “active” อยู่ตลอดในการวิเคราะห์กระบวนการ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในตาราง “requisition_headers” เมื่อฟิลด์ “status” เปลี่ยนเป็น “closed” โดยมีการบันทึกเวลาไว้ในบันทึกการตรวจสอบที่เกี่ยวข้อง. บันทึก ระบุเวลาที่สถานะโดยรวมของใบขอซื้อเปลี่ยนเป็น “closed”. ประเภทเหตุการณ์ inferred
	ส่งใบขอซื้อ	ผู้ขอซื้อส่งใบขอซื้อที่กรอกข้อมูลครบแล้วเข้าสู่เวิร์กโฟลว์อนุมัติอย่างเป็นทางการ อนุมานเหตุการณ์นี้ได้จากการเปลี่ยนสถานะใบขอซื้อในบันทึกการตรวจสอบหรือประวัติของระบบ จาก 'draft' เป็น 'pending_approval'.
เหตุผลที่สำคัญ การส่งคำขอเป็นจุดเริ่มต้นของกระบวนการอนุมัติ จึงเป็นหมุดหมายสำคัญในการวัด KPI 'ระยะเวลาวงจรอนุมัติใบขอซื้อเฉลี่ย' ความล่าช้าก่อนถึงจุดนี้เกี่ยวข้องกับผู้ใช้ ส่วนความล่าช้าหลังจากนั้นเกี่ยวข้องกับกระบวนการ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในตาราง 'requisition_headers' โดยเฉพาะเมื่อฟิลด์ 'status' เปลี่ยนเป็น 'pending_approval' เวลาที่เปลี่ยนสถานะนี้อยู่ในบันทึกการตรวจสอบที่เกี่ยวข้อง. บันทึก ระบุเวลาที่สถานะใบขอซื้อเปลี่ยนเป็น 'pending_approval' เป็นครั้งแรก. ประเภทเหตุการณ์ inferred
	สร้างใบขอซื้อ	ผู้ใช้เริ่มสร้างใบขอซื้อใหม่และบันทึกเป็นฉบับร่าง นี่คือจุดเริ่มต้นของแต่ละกรณีใบขอซื้อ โดยทั่วไปอนุมานจากเวลาที่สร้างระเบียนใบขอซื้อ.
เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นของวงจรใบขอซื้อ การวิเคราะห์เวลาตั้งแต่สร้างจนถึงส่งคำขอช่วยให้เห็นความล่าช้าที่เกิดจากผู้ใช้ไม่แน่ใจหรือระบบซับซ้อน. แหล่งข้อมูล บันทึกเหตุการณ์นี้จากเวลาประทับ 'created-at' ในตาราง 'requisition_headers' สำหรับ Purchase Requisition ID ที่กำหนด. บันทึก ใช้เวลาประทับที่สร้างระเบียนส่วนหัวของใบขอซื้อ. ประเภทเหตุการณ์ inferred
	สร้างใบสั่งซื้อ	ระบบสร้างใบสั่งซื้อ (PO) จากข้อมูลในใบขอซื้อที่ได้รับอนุมัติเรียบร้อยแล้ว อนุมานเหตุการณ์นี้ได้เมื่อมีการสร้างระเบียน PO ที่อ้างอิง ID ของใบขอซื้อต้นทาง.
เหตุผลที่สำคัญ นี่คือผลลัพธ์หลักที่ต้องการจากกระบวนการขอซื้อ และเป็นจุดส่งต่องานไปยังขั้นตอนถัดไปของ Purchase-to-Pay การวิเคราะห์เวลาตั้งแต่ “อนุมัติใบขอซื้อ” จนถึงเหตุการณ์นี้ช่วยให้เห็นความล่าช้าในการดำเนินการ. แหล่งข้อมูล อนุมานจากการสร้างระเบียนในตาราง “purchase_orders” ซึ่งมีการอ้างอิงกลับไปยัง ID ของ “requisition_headers” หรือ “requisition_lines” ต้นทาง. บันทึก ใช้เวลาประทับ “created-at” ของระเบียน PO ที่เชื่อมโยงกับ ID ของใบขอซื้อ. ประเภทเหตุการณ์ inferred
	อนุมัติใบขอซื้อ	ใบขอซื้อผ่านขั้นตอนที่จำเป็นทั้งหมดในเวิร์กโฟลว์การอนุมัติแล้ว อนุมานได้จากสถานะโดยรวมในส่วนหัวของใบขอซื้อที่เปลี่ยนเป็น “approved”.
เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญที่แสดงว่ารอบการอนุมัติสิ้นสุดลงแล้ว ระยะเวลาจนถึงกิจกรรมนี้เป็น KPI หลัก และเป็นจุดเริ่มต้นของการจัดซื้อในขั้นตอนถัดไป. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในตาราง “requisition_headers” เมื่อฟิลด์ “status” เปลี่ยนเป็น “approved” โดยมีการบันทึกเวลาไว้ในบันทึกการตรวจสอบที่เกี่ยวข้อง. บันทึก ระบุเวลาที่สถานะโดยรวมของใบขอซื้อเปลี่ยนเป็น “approved”. ประเภทเหตุการณ์ inferred
	แก้ไขใบขอซื้อ	ผู้ขอซื้อหรือผู้ใช้ที่ได้รับอนุญาตรายอื่นแก้ไขใบขอซื้อหลังจากส่งแล้ว Coupa จะบันทึกการแก้ไขนี้เป็นเวอร์ชันใหม่หรือรายการในบันทึกการตรวจสอบอย่างชัดเจน ซึ่งมักทำให้ขั้นตอนอนุมัติบางส่วนหรือทั้งหมดเริ่มต้นใหม่.
เหตุผลที่สำคัญ การติดตามการแก้ไขเป็นกุญแจสำคัญในการทำความเข้าใจงานซ้ำและความไม่มีประสิทธิภาพของกระบวนการ การแก้ไขจำนวนมากอาจบ่งชี้ว่าข้อกำหนดตั้งต้นไม่ชัดเจนหรือนโยบายการจัดซื้อซับซ้อน ซึ่งส่งผลต่อ KPI 'อัตราการแก้ไขใบขอซื้อ'. แหล่งข้อมูล บันทึกข้อมูลนี้จากตารางบันทึกการตรวจสอบที่เชื่อมโยงกับตาราง 'requisition_headers' ซึ่งเก็บการเปลี่ยนเวอร์ชันหรือการดำเนินการ 'edit' โดยเฉพาะ. บันทึก ค้นหาเหตุการณ์ 'edit' หรือ 'update' ที่ระบุชัดเจนในบันทึกประวัติใบขอซื้อหลังจากส่งแล้ว. ประเภทเหตุการณ์ explicit
	ถอนใบขอซื้อ	ผู้ขอเดิมยกเลิกใบขอซื้อก่อนที่จะได้รับอนุมัติขั้นสุดท้าย การดำเนินการนี้เกิดจากผู้ใช้โดยตรงและทำให้กระบวนการของใบขอซื้อนั้นสิ้นสุดลง.
เหตุผลที่สำคัญ การถอนใบขอซื้ออาจบ่งชี้ว่าความต้องการทางธุรกิจเปลี่ยนไป มีคำขอซ้ำ หรือผู้ใช้หลีกเลี่ยงกระบวนการ การติดตามข้อมูลนี้ช่วยให้เข้าใจความผันผวนของความต้องการและปัญหาที่อาจเกิดขึ้นในการปฏิบัติตามกระบวนการ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในตาราง “requisition_headers” เป็น “withdrawn” หรือสถานะใกล้เคียง โดยอ้างอิงการดำเนินการของผู้ใช้ที่บันทึกไว้อย่างชัดเจนในบันทึกการตรวจสอบ. บันทึก ระบุเวลาที่สถานะใบขอซื้อเปลี่ยนเป็น “withdrawn”. ประเภทเหตุการณ์ inferred
	ปฏิเสธขั้นตอนการอนุมัติ	ผู้อนุมัติปฏิเสธใบขอซื้อในขั้นตอนที่ตนรับผิดชอบ โดยทั่วไปจะส่งกลับให้ผู้ขอแก้ไข Coupa บันทึกการดำเนินการนี้ไว้อย่างชัดเจน.
เหตุผลที่สำคัญ การปฏิเสธในขั้นตอนใดก็ตามทำให้ต้องกลับไปแก้ไขและทำให้ระยะเวลาดำเนินการยาวขึ้น การวิเคราะห์ว่าการปฏิเสธเกิดขึ้นที่ใดและเพราะเหตุใดจึงสำคัญต่อการปรับปรุงกระบวนการและการฝึกอบรมผู้ใช้. แหล่งข้อมูล ข้อมูลนี้ได้จากการดำเนินการ “reject” ที่บันทึกไว้อย่างชัดเจนในตาราง “approvals” หรือบันทึกการตรวจสอบ โดยเชื่อมโยงกับใบขอซื้อและผู้อนุมัติที่เกี่ยวข้อง. บันทึก กรองเหตุการณ์ “reject” ในประวัติการอนุมัติของใบขอซื้อ. ประเภทเหตุการณ์ explicit
	เริ่มขั้นตอนอนุมัติ	มอบหมายงานอนุมัติให้ผู้อนุมัติหรือกลุ่มผู้อนุมัติที่ระบุ และใบขอซื้อกำลังรอการดำเนินการจากผู้อนุมัติ อนุมานเหตุการณ์นี้ได้เมื่อมีการสร้างระเบียนอนุมัติที่เชื่อมโยงกับใบขอซื้อและมีสถานะ 'pending'.
เหตุผลที่สำคัญ เหตุการณ์นี้เป็นจุดเริ่มต้นของเวลารอการอนุมัติแต่ละรายการ การวัดระยะเวลาตั้งแต่จุดนี้จนถึง 'อนุมัติ/ปฏิเสธขั้นตอนอนุมัติ' ที่เกี่ยวข้อง ช่วยระบุคอขวดเฉพาะจุดในลำดับการอนุมัติ. แหล่งข้อมูล อนุมานจากเวลาที่สร้างระเบียนในตาราง 'approvals' ซึ่งเชื่อมโยงกับใบขอซื้อ โดยสถานะการดำเนินการของผู้อนุมัติเป็น 'pending' หรือสถานะที่มีความหมายเทียบเท่ากัน. บันทึก ใช้เวลาที่สร้างระเบียนการอนุมัติที่รอดำเนินการของบุคคลนั้นในลำดับการอนุมัติ. ประเภทเหตุการณ์ inferred
	ส่งใบขอซื้อเข้าสู่การจัดหา	ใบขอซื้อที่ได้รับอนุมัติถูกส่งเข้าสู่กิจกรรมการจัดหา เช่น RFQ หรือการประมูล แทนการแปลงเป็นใบสั่งซื้อทันที อนุมานเหตุการณ์นี้ได้เมื่อใบขอซื้อเชื่อมโยงกับออบเจ็กต์กิจกรรมการจัดหา.
เหตุผลที่สำคัญ กิจกรรมนี้แสดงเส้นทางอีกแบบหนึ่งที่สำคัญในกระบวนการจัดซื้อ ช่วยแยกการซื้อทั่วไปออกจากกิจกรรมการจัดหาเชิงกลยุทธ์ที่ซับซ้อนกว่า เพื่อให้วิเคราะห์ระยะเวลาดำเนินการได้ละเอียดขึ้น. แหล่งข้อมูล อนุมานได้จากการตรวจพบการเปลี่ยนสถานะเป็น “sourcing” หรือการสร้างลิงก์ระหว่างตาราง “requisition_lines” กับตารางกิจกรรมการจัดหา. บันทึก ตรวจสอบว่ามีการเปลี่ยนสถานะเป็น “sourcing” หรือสร้างลิงก์ไปยัง ID ของกิจกรรมการจัดหาหรือไม่. ประเภทเหตุการณ์ inferred
	อนุมัติขั้นตอนอนุมัติ	ผู้อนุมัติแต่ละคนอนุมัติใบขอซื้อในขั้นตอนที่ตนรับผิดชอบ ระบบบันทึกการดำเนินการนี้ไว้อย่างชัดเจน พร้อมเวลาที่เกิดเหตุการณ์และข้อมูลผู้ใช้.
เหตุผลที่สำคัญ กิจกรรมนี้ช่วยให้เห็นรายละเอียดของลำดับขั้นตอนการอนุมัติ เมื่อนำขั้นตอนเหล่านี้มารวมกัน จะคำนวณ “เวลารอเฉลี่ยต่อขั้นตอนการอนุมัติ” และวิเคราะห์ผลการปฏิบัติงานของผู้อนุมัติได้. แหล่งข้อมูล ข้อมูลนี้ได้จากการดำเนินการ “approve” ที่บันทึกไว้อย่างชัดเจนในตาราง “approvals” หรือบันทึกการตรวจสอบ โดยเชื่อมโยงกับใบขอซื้อและผู้อนุมัติที่เกี่ยวข้อง. บันทึก กรองเหตุการณ์ “approve” ในประวัติการอนุมัติของใบขอซื้อ. ประเภทเหตุการณ์ explicit

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

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

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

ขั้นตอน

เข้าสู่ระบบ Coupa: เข้าถึงระบบ Coupa ของคุณด้วยบัญชีผู้ใช้ที่มีสิทธิ์สร้างและตั้งเวลารายงาน.
ไปที่โมดูลรายงาน: เปิดแท็บ 'Setup' แล้วไปที่ส่วน 'Reporting' เลือก 'Reports' เพื่อเปิดแดชบอร์ดรายงาน.
สร้างรายงานแบบกำหนดเอง: คลิกปุ่ม 'Create' เพื่อเริ่มสร้างรายงานใหม่ แล้วเลือก 'Custom Report' เป็นประเภทรายงาน.
กำหนดแหล่งข้อมูลของรายงาน: ในเครื่องมือสร้างรายงาน ให้เลือกและเชื่อมแหล่งข้อมูลหลายรายการเพื่อรวบรวมข้อมูลที่จำเป็น เริ่มจาก 'Requisition Headers' เป็นแหล่งข้อมูลหลัก แล้วเพิ่มออบเจ็กต์ที่เกี่ยวข้องต่อไปนี้:
- 'Approvals': ใช้ดูรายละเอียดของแต่ละขั้นตอนการอนุมัติ รวมถึงผู้อนุมัติ สถานะ และเวลา.
- 'Requisition Lines': ใช้รวมยอดเงินทั้งหมดและดูรายละเอียดระดับรายการ.
- 'Purchase Order Headers': ใช้ระบุว่าใบขอซื้อถูกแปลงเป็น PO เมื่อใด.
- 'Users': ใช้ดึงชื่อและรายละเอียดแผนกของผู้ขอซื้อและผู้อนุมัติ.
กำหนดคอลัมน์รายงาน: ลากฟิลด์ที่ต้องการจากแหล่งข้อมูลที่มีไปวางในรูปแบบรายงาน ขั้นตอนนี้สำคัญที่สุด เพราะจะนำคอลัมน์เหล่านี้ไปสร้างบันทึกเหตุการณ์ ควรมีอย่างน้อยฟิลด์ต่อไปนี้:
- จาก Requisition Headers: Requisition #, Created At, Submitted At, Updated At, Status, Created by (Login ID), Total, Sourced Externally?
- จาก Users (สำหรับผู้ขอซื้อ): Full Name, Department Name.
- จาก Approvals: Created At, Updated At, Status, Approver (Login ID).
- จาก Purchase Order Headers: PO Number, Created At.
ตั้งค่าตัวกรองรายงาน: ใช้ตัวกรองเพื่อกำหนดขอบเขตข้อมูลที่ดึงมา โดยทั่วไปควรกรองตาม 'Requisition Headers - Created At' และกำหนดช่วงวันที่แบบเลื่อน เช่น 'Last 90 days' คุณอาจกรองตามรหัสบริษัทที่ต้องการได้ด้วย.
ตั้งเวลารายงาน: ไปที่แท็บ 'Schedule' ในเครื่องมือสร้างรายงาน แล้วกำหนดความถี่ในการเรียกใช้รายงาน เช่น รายวันหรือรายสัปดาห์ เลือกช่วงเวลาที่มีการใช้งานระบบน้อย.
ตั้งค่าการส่งรายงาน: ระบุวิธีส่งข้อมูล หากต้องการให้ทำงานอัตโนมัติ ให้เลือก 'SFTP' แล้วกรอกข้อมูลรับรองเซิร์ฟเวอร์และไดเรกทอรีปลายทาง หรือส่งไปยังอีเมลก็ได้ เลือก 'CSV' เป็นรูปแบบไฟล์.
บันทึกและเปิดใช้งาน: บันทึกรายงานและตรวจสอบว่าเปิดใช้งานกำหนดการแล้ว รายงานแรกจะทำงานตามเวลาที่ตั้งไว้ครั้งถัดไป.
แปลงข้อมูล: ไฟล์ CSV ที่สร้างขึ้นเป็นไฟล์ข้อมูลแบบแบน ไม่ใช่บันทึกเหตุการณ์ คุณต้องใช้สคริปต์ภายนอก เช่น Python หรือเครื่องมือ ETL เพื่อประมวลผลไฟล์ โดยสคริปต์ต้องจัดรูปข้อมูลใหม่ให้แต่ละกิจกรรมมีแถวของตัวเอง เช่น แถว 'สร้างใบขอซื้อ' ที่ใช้คอลัมน์ Created At แถวของแต่ละขั้นตอนการอนุมัติที่ใช้คอลัมน์จาก 'Approvals' และแถว 'สร้างใบสั่งซื้อ' ที่ใช้คอลัมน์ Created At ของ PO.
สร้างบันทึกเหตุการณ์ฉบับสมบูรณ์: สคริปต์แปลงข้อมูลควรสร้างไฟล์ CSV ที่มีคอลัมน์จำเป็น ได้แก่ PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate และแอตทริบิวต์แนะนำอื่นๆ จากนั้นไฟล์นี้ก็พร้อมอัปโหลด.

การกำหนดค่า

แหล่งข้อมูลหลัก: รายงานต้องเชื่อมออบเจ็กต์ Coupa หลายรายการ แหล่งข้อมูลสำคัญ ได้แก่ 'Requisition Headers', 'Approvals', 'Requisition Lines' และ 'Purchase Order Headers'.
กรองช่วงวันที่: ควรกรองวันที่เพื่อจำกัดปริมาณข้อมูล แนะนำให้เริ่มจากช่วงย้อนหลัง 3-6 เดือน โดยอิงจาก 'Requisition Headers - Created At'.
โหลดข้อมูลส่วนเพิ่ม: หากต้องการวิเคราะห์ต่อเนื่อง ให้ตั้งเวลารายงานเป็นรายวันและดึงข้อมูลของวันก่อนหน้า เช่น 'Yesterday' เพื่อโหลดเฉพาะข้อมูลส่วนที่เพิ่มเข้ามา.
ตั้งค่าการส่งข้อมูล: ตั้งค่าให้ส่งข้อมูลไปยังเซิร์ฟเวอร์ SFTP เพื่อเชื่อมต่อกับไปป์ไลน์ข้อมูลโดยอัตโนมัติและมีเสถียรภาพ ตรวจสอบว่าปลายทางปลอดภัยและมีพื้นที่จัดเก็บเพียงพอ.
สิทธิ์ที่จำเป็น: บัญชีผู้ใช้ที่ตั้งค่ารายงานต้องมีสิทธิ์ระดับผู้ดูแลระบบหรือสิทธิ์เฉพาะด้านรายงาน เพื่อสร้างและตั้งเวลารายงาน รวมถึงเข้าถึงออบเจ็กต์ข้อมูลที่จำเป็นทั้งหมด (ใบขอซื้อ, PO, การอนุมัติ และผู้ใช้).

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

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

ขั้นตอน

สิ่งที่ต้องเตรียม: ติดตั้งสภาพแวดล้อม Python 3 และไลบรารีที่จำเป็น ได้แก่ pandas และ requests โดยเรียกใช้ pip install pandas requests ในเทอร์มินัลหรือพรอมต์คำสั่ง.
รับ Coupa API Key: เข้าสู่ระบบ Coupa ในฐานะผู้ดูแลระบบ ไปที่ Setup > Company Setup > API Keys แล้วสร้าง API key ใหม่ที่มีสิทธิ์อ่านอย่างน้อยสำหรับขอบเขตต่อไปนี้: core.purchase_order.read, core.requisition.read และ core.user.read.
ตั้งค่าสคริปต์: สร้างไฟล์ Python ใหม่ เช่น extract_coupa_reqs.py แล้วคัดลอกสคริปต์ Python ที่ให้มาใส่ในไฟล์นี้ แทนค่าตัวอย่างของ COUPA_INSTANCE_URL ด้วย URL Coupa ของบริษัท เช่น https://yourcompany.coupahost.com และแทน API_KEY ด้วยคีย์ที่ได้จากขั้นตอนก่อนหน้า.
กำหนดพารามิเตอร์การดึงข้อมูล: ในส่วน main ของสคริปต์ ให้ปรับตัวแปร START_DATE และ END_DATE เพื่อกำหนดช่วงเวลาที่ต้องการดึงข้อมูล โดยระบบจะกรองใบขอซื้อตามวันที่สร้าง.
เรียกใช้สคริปต์: เรียกใช้สคริปต์จากเทอร์มินัลด้วยคำสั่ง python extract_coupa_reqs.py สคริปต์จะเชื่อมต่อกับ Coupa API ดึงข้อมูล และแสดงความคืบหน้าในคอนโซล.
จัดการการแบ่งหน้า API: สคริปต์มีฟังก์ชันจัดการการแบ่งหน้า API โดยอัตโนมัติ ระบบจะดึงข้อมูลครั้งละ 50 รายการต่อหน้า และทำต่อไปจนกว่าจะได้ใบขอซื้อทั้งหมดในช่วงวันที่กำหนด.
ประมวลผลข้อมูลใบขอซื้อ: สำหรับส่วนหัวใบขอซื้อแต่ละรายการที่ดึงมา สคริปต์จะสร้างเหตุการณ์ 'สร้างใบขอซื้อ' และ 'ส่งใบขอซื้อ' จากนั้นเรียก API เพิ่มเติมเพื่อดึงข้อมูลการอนุมัติและใบสั่งซื้อที่เกี่ยวข้อง.
สร้างเหตุการณ์กิจกรรม: สคริปต์ประมวลผลข้อมูลการอนุมัติเพื่อสร้างเหตุการณ์ 'เริ่มขั้นตอนการอนุมัติ', 'อนุมัติขั้นตอนการอนุมัติ' และ 'ปฏิเสธขั้นตอนการอนุมัติ' นอกจากนี้ยังตรวจสอบสถานะสุดท้ายของใบขอซื้อและข้อมูลที่เกี่ยวข้อง เพื่อสร้างเหตุการณ์ เช่น 'อนุมัติใบขอซื้อ', 'สร้างใบสั่งซื้อ' และ 'ถอนใบขอซื้อ'.
ตรวจหาการแก้ไข: สคริปต์ตรวจสอบแอตทริบิวต์ version ของใบขอซื้อแต่ละรายการ หากมีค่ามากกว่า 1 แสดงว่ามีการแก้ไข โดยจะสร้างเหตุการณ์ 'แก้ไขใบขอซื้อ' และใช้เวลา updated-at ของเวอร์ชันใหม่.
รวบรวมบันทึกเหตุการณ์: รวบรวมเหตุการณ์ทั้งหมดไว้ในรายการที่มีโครงสร้าง แต่ละเหตุการณ์มีแอตทริบิวต์ที่จำเป็น เช่น PurchaseRequisitionId, ActivityName และ EventTime รวมถึงแอตทริบิวต์แนะนำ เช่น Requester และ TotalAmount.
ส่งออกเป็น CSV: เมื่อประมวลผลใบขอซื้อทั้งหมดแล้ว สคริปต์จะแปลงรายการเหตุการณ์เป็น pandas DataFrame และบันทึกเป็นไฟล์ CSV ชื่อ coupa_requisition_event_log.csv ในไดเรกทอรีเดียวกัน ไฟล์นี้จัดรูปแบบไว้ให้พร้อมอัปโหลดไปยัง ProcessMind.

การกำหนดค่า

สิทธิ์ของ API Key: API key ที่ใช้ดึงข้อมูลต้องมีสิทธิ์อ่านออบเจ็กต์ requisition_headers, requisition_lines, approvals, purchase_orders และ users ใน Coupa หากไม่มีสิทธิ์เหล่านี้ สคริปต์จะทำงานไม่สำเร็จหรือส่งคืนข้อมูลไม่ครบ.
ช่วงวันที่: สคริปต์กรองช่วงวันที่โดยอิงจากวันที่สร้างใบขอซื้อ (created-at) แนะนำให้ดึงข้อมูลเป็นช่วงที่จัดการได้ เช่น ครั้งละ 3-6 เดือน เพื่อไม่ให้ใช้เวลานานหรือเกิด API timeout ปรับตัวแปร START_DATE และ END_DATE ให้ตรงกับช่วงที่ต้องการ.
กรองตามสถานะ: สคริปต์ที่ให้มาจะดึงใบขอซื้อทุกสถานะ หากต้องการวิเคราะห์เฉพาะบางกลุ่ม คุณสามารถเพิ่มพารามิเตอร์ status ในพจนานุกรม params ของการเรียก API ครั้งแรก เพื่อเลือกสถานะ เช่น approved, pending_approval หรือ ordered.
ขีดจำกัดการแบ่งหน้า: สคริปต์กำหนดให้ดึงข้อมูลครั้งละ 50 รายการต่อการเรียก API (limit=50) ซึ่งเป็นค่ามาตรฐานที่ใช้ได้ดีกับ Coupa API การเพิ่มจำนวนอาจไม่ได้ช่วยให้ทำงานเร็วขึ้น และอาจเพิ่มความเสี่ยงที่คำขอซับซ้อนจะหมดเวลา.
ข้อควรพิจารณาด้านประสิทธิภาพ: สคริปต์เรียก API หลายครั้งต่อใบขอซื้อแต่ละรายการ (ครั้งหนึ่งสำหรับส่วนหัว ครั้งหนึ่งสำหรับการอนุมัติ และอีกครั้งสำหรับ PO) การดึงข้อมูลใบขอซื้อหลายพันรายการอาจใช้เวลานานและอยู่ภายใต้ข้อจำกัดอัตราการเรียกใช้ API ของ Coupa แนะนำให้เรียกใช้สคริปต์นอกช่วงเวลาทำการที่มีการใช้งานสูง.

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

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL and API Key
COUPA_INSTANCE_URL = class="hl-string">"https://[your_instance].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

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

def get_coupa_data(endpoint, params={}):
    class="hl-string">"""Fetches paginated data from a Coupa API endpoint."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"X-COUPA-API-KEY": API_KEY
    }
    
    all_records = []
    offset = 0
    limit = 50
    
    while True:
        paginated_params = params.copy()
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = limit
        
        try:
            response = requests.get(fclass="hl-string">"{COUPA_INSTANCE_URL}{endpoint}", headers=headers, params=paginated_params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for 4xx/5xx errors
            data = response.json()
            
            if not data:
                break
                
            all_records.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
            
    return all_records

def main(start_date, end_date):
    class="hl-string">"""Main function to extract, transform, and save the event log.""" 
    print(class="hl-string">"Starting Coupa Requisition data extraction...")
    
    event_log = []
    current_time_utc = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Requisition Headers within the date range
    req_params = {
        class="hl-string">"created-at[gt]": start_date,
        class="hl-string">"created-at[lt]": end_date,
        class="hl-string">"fields": class="hl-string">'["id", "created-at", "submitted-at", "updated-at", "version", "status", "total", "requester", "currency", "sourcing-event-id"]'
    }
    requisition_headers = get_coupa_data(class="hl-string">"/api/requisition_headers", req_params)
    print(fclass="hl-string">"Found {len(requisition_headers)} requisitions to process.")

    for i, header in enumerate(requisition_headers):
        print(fclass="hl-string">"Processing requisition {i+1}/{len(requisition_headers)}: ID {header['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        case_id = str(header[class="hl-string">'id'])
        total_amount = header.get(class="hl-string">'total', {}).get(class="hl-string">'total')
        requester_name = fclass="hl-string">"{header.get('requester', {}).get('firstname', '')} {header.get('requester', {}).get('lastname', '')}".strip()
        department_name = header.get(class="hl-string">'requester', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name')

        base_event = {
            class="hl-string">"PurchaseRequisitionId": case_id,
            class="hl-string">"TotalAmount": total_amount,
            class="hl-string">"Requester": requester_name,
            class="hl-string">"Department": department_name,
            class="hl-string">"Approver": None,
            class="hl-string">"SourceSystem": class="hl-string">"Coupa",
            class="hl-string">"LastDataUpdate": current_time_utc
        }

        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        event_log.append({
            **base_event,
            class="hl-string">"ActivityName": class="hl-string">"Requisition Created",
            class="hl-string">"EventTime": header[class="hl-string">'created-at'],
            class="hl-string">"RequisitionStatus": class="hl-string">"draft"
        })

        class=class="hl-string">"hl-comment"># Activity: Requisition Submitted
        if header.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Submitted",
                class="hl-string">"EventTime": header[class="hl-string">'submitted-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval"
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Amended
        if header.get(class="hl-string">'version') and int(header[class="hl-string">'version']) > 1:
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Amended",
                class="hl-string">"EventTime": header[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Timestamp of the new version
                class="hl-string">"RequisitionStatus": header[class="hl-string">'status']
            })

        class=class="hl-string">"hl-comment"># 2. Fetch Approvals for this requisition
        approval_params = {
            class="hl-string">"approvable-id": header[class="hl-string">'id'],
            class="hl-string">"approvable-type": class="hl-string">"RequisitionHeader"
        }
        approvals = get_coupa_data(class="hl-string">"/api/approvals", approval_params)

        for approval in approvals:
            approver = approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname')
            approval_status = approval[class="hl-string">'status']

            class=class="hl-string">"hl-comment"># Activity: Approval Step Started
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Approval Step Started",
                class="hl-string">"EventTime": approval[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                class="hl-string">"Approver": approver
            })

            if approval_status == class="hl-string">'approved':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Approved
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Approved",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
            elif approval_status == class="hl-string">'rejected':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Rejected
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Rejected",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
        
        class=class="hl-string">"hl-comment"># 3. Handle final status and related events
        final_status_event_time = header[class="hl-string">'updated-at']
        final_status = header[class="hl-string">'status']

        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'withdrawn':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Withdrawn",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Sourced
        if header.get(class="hl-string">'sourcing-event-id'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Sourced",
                class="hl-string">"EventTime": final_status_event_time, class=class="hl-string">"hl-comment"># Assumes status update time reflects sourcing
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># 4. Fetch Purchase Orders to detect PO Creation
        po_params = {class="hl-string">"requisition-header-id": header[class="hl-string">'id']}
        purchase_orders = get_coupa_data(class="hl-string">"/api/purchase_orders", po_params)

        for po in purchase_orders:
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Purchase Order Created",
                class="hl-string">"EventTime": po[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"ordered" 
            })

    class=class="hl-string">"hl-comment"># 5. Create and save the DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">"PurchaseRequisitionId", class="hl-string">"EventTime"])
    df.to_csv(class="hl-string">"coupa_requisition_event_log.csv", index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to coupa_requisition_event_log.csv")

if __name__ == class="hl-string">"__main__":
    class=class="hl-string">"hl-comment"># Define the extraction period. Format: YYYY-MM-DDTHH:MM:SSZ
    START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
    END_DATE = class="hl-string">"2023-06-30T23:59:59Z"
    main(START_DATE, END_DATE)

ขั้นตอน

ตรวจสอบว่าแพลตฟอร์ม iPaaS หรือ process mining จากผู้ให้บริการภายนอกที่เลือกมีตัวเชื่อมต่อ Coupa ที่ผ่านการตรวจสอบ และเข้าถึงส่วนหัวใบขอซื้อ ประวัติใบขอซื้อหรือข้อมูลตรวจสอบ รายการอนุมัติ ความสัมพันธ์กับการจัดหา ความสัมพันธ์กับใบสั่งซื้อ และข้อมูลการปิดรายการได้ ชื่อตัวเชื่อมต่อ ชื่อออบเจ็กต์ และฟิลด์ที่มีให้ใช้อาจแตกต่างกันตามผู้ให้บริการ ให้ตั้งค่าตามเอกสารของตัวเชื่อมต่อและ Coupa tenant ของคุณ.
สร้างการเชื่อมต่อผ่านหน้าตั้งค่าการเชื่อมต่อของแพลตฟอร์ม ระบุ URL ของ Coupa tenant วิธีการยืนยันตัวตน ข้อมูลรับรอง รายละเอียด OAuth และ scopes ที่จำเป็น ใช้ค่าตัวอย่าง เช่น [Your Coupa tenant URL] และ [Your connector credentials] จนกว่าจะตั้งค่าการเชื่อมต่อในสภาพแวดล้อมเป้าหมาย.
กำหนดขอบเขตการดึงข้อมูล เริ่มจากช่วงวันที่ย้อนหลัง 3-6 เดือน แล้วค่อยขยายหลังตรวจสอบความสอดคล้อง ใช้เฉพาะตัวกรองที่ tenant ของคุณรองรับ เช่น [Your company filter] หรือ [Your document type filter] อย่ากรองใบขอซื้อออกเพียงเพราะสถานะปัจจุบันเป็นปิดแล้ว ปฏิเสธ ถอน หรืออนุมัติ เนื่องจากต้องใช้กรณีเหล่านี้ในการวิเคราะห์วงจรชีวิต.
จับคู่ออบเจ็กต์ต้นทางในตัวเชื่อมต่อ เลือกออบเจ็กต์ส่วนหัวใบขอซื้อ ประวัติหรือข้อมูลตรวจสอบใบขอซื้อ ออบเจ็กต์การอนุมัติ ออบเจ็กต์ความสัมพันธ์กับการจัดหา ออบเจ็กต์ความสัมพันธ์กับใบสั่งซื้อ และออบเจ็กต์ประวัติการปิดหรือสถานะที่ตัวเชื่อมต่อมีให้ หากไม่มีออบเจ็กต์ที่จำเป็น ให้ใช้รูปแบบประวัติหรือข้อมูลตรวจสอบที่ตัวเชื่อมต่อรองรับ หรือบันทึกข้อจำกัดไว้ก่อนเผยแพร่ข้อมูล.
ตั้งค่าการจับคู่กรณีและเหตุการณ์ จับคู่รหัสใบขอซื้อกับ PurchaseRequisitionId ป้ายชื่อเหตุการณ์กับ ActivityName เวลาในแหล่งข้อมูลกับ EventTime กำหนดค่าแหล่งข้อมูลเป็น Coupa ใน SourceSystem และจับคู่เวลารีเฟรชของตัวเชื่อมต่อกับ LastDataUpdate จับคู่ผู้ขอซื้อ แผนก จำนวนเงินรวม สถานะใบขอซื้อ และผู้อนุมัติ หากมีฟิลด์เหล่านี้.
ตั้งกฎเหตุการณ์ให้สร้างแถวสำหรับกิจกรรมทั้ง 12 รายการอย่างชัดเจน สร้าง Requisition Created จากเวลาที่สร้างใบขอซื้อ, Requisition Submitted จากการเปลี่ยนสถานะจาก draft เป็น pending_approval, Requisition Amended จากเวอร์ชันหรือรายการตรวจสอบหลังส่งใบขอซื้อ, Approval Step Started จากรายการอนุมัติที่รอดำเนินการ, Approval Step Approved จากการอนุมัติ, Approval Step Rejected จากการปฏิเสธ, Requisition Withdrawn จากการถอนหรือการเปลี่ยนสถานะที่ระบุชัดเจน, Requisition Approved จากการเปลี่ยนสถานะส่วนหัวเป็น approved, Requisition Rejected จากการเปลี่ยนสถานะส่วนหัวเป็น rejected, Requisition Sourced จากความสัมพันธ์ระหว่างใบขอซื้อกับการจัดหา, Purchase Order Created จากใบสั่งซื้อที่อ้างอิงใบขอซื้อ และ Requisition Closed จากการปิดหรือการเปลี่ยนสถานะที่ระบุชัดเจน.
ปรับข้อมูลที่ดึงมาให้เป็นรูปแบบเดียวกันก่อนรวมสตรีมเหตุการณ์ แปลงเวลาทั้งหมดให้อยู่ในเขตเวลาเดียวกัน โดยแนะนำให้ใช้ UTC รักษาความละเอียดของเวลาต้นทาง แปลงรหัสใบขอซื้อให้เป็นชนิดข้อความแบบเดียวกัน และเก็บค่าสถานะกับค่าผู้ใช้จากต้นทางไว้ ลบข้อมูลซ้ำเฉพาะรายการต้นทางที่เหมือนกันในเชิงเทคนิค โดยใช้รหัสใบขอซื้อ ชื่อกิจกรรม เวลาเหตุการณ์ รหัสรายการต้นทาง (หากมี) และผู้อนุมัติเป็นเกณฑ์เปรียบเทียบ.
เผยแพร่หรือตั้งเวลาการทำงานของตัวเชื่อมต่อ เริ่มด้วยการดึงข้อมูลทั้งหมดในช่วงวันที่เลือก จากนั้นรีเฟรชข้อมูลส่วนเพิ่มโดยอิงเวลาอัปเดตต้นทางหรือกลไกติดตามการเปลี่ยนแปลงที่ตัวเชื่อมต่อรองรับ กำหนดช่วงเวลาย้อนกลับเพื่อรวมรายการตรวจสอบที่มาช้าและรายการอนุมัติที่มีการแก้ไข.
ตรวจสอบบันทึกเหตุการณ์ที่ได้กับรายงาน Coupa หรือหน้าตัวอย่างของตัวเชื่อมต่อ ยืนยันว่าใบขอซื้อทุกรายการมีเหตุการณ์สร้าง ตรวจสอบว่าลำดับเวลาของการเปลี่ยนสถานะและการอนุมัติถูกต้อง และมีเหตุการณ์ความสัมพันธ์เมื่อมีการจัดหาหรือใบสั่งซื้อ.
ส่งออกผลลัพธ์สุดท้ายเป็น CSV แบบแบน หรือรูปแบบบันทึกเหตุการณ์อื่นที่ ProcessMind รองรับ ให้มีหนึ่งแถวต่อเหตุการณ์ โดยใช้ PurchaseRequisitionId เป็นรหัสกรณี ActivityName เป็นกิจกรรม และ EventTime เป็นเวลาเหตุการณ์ จากนั้นอัปโหลดไฟล์หรือเผยแพร่ชุดข้อมูลจากตัวเชื่อมต่อไปยัง ProcessMind โดยไม่ต้องพึ่ง ProcessMind ในการอนุมานเหตุการณ์ที่ขาดหายไป.

การกำหนดค่า

ตัวเชื่อมต่อและสิทธิ์เข้าถึง: ใช้ตัวเชื่อมต่อ Coupa ที่ผ่านการตรวจสอบและจัดหาโดยแพลตฟอร์ม iPaaS หรือ process mining ที่เลือก สิทธิ์ Coupa, API scopes, โมดูล และไลเซนส์ตัวเชื่อมต่อที่ต้องใช้ขึ้นอยู่กับผู้ให้บริการและการตั้งค่า tenant ตรวจสอบสิทธิ์เข้าถึงข้อมูลใบขอซื้อ ประวัติหรือข้อมูลตรวจสอบ การอนุมัติ การจัดหา ใบสั่งซื้อ และการปิดรายการก่อนนำไปใช้.
ช่วงวันที่: เริ่มจากข้อมูลย้อนหลัง 3-6 เดือน ใช้ช่วงเวลาดึงข้อมูลแบบเลื่อนสำหรับการรีเฟรชตามกำหนด และกำหนดช่วงเวลาย้อนกลับเพื่อเก็บข้อมูลอัปเดตที่มาช้า การอนุมัติ และใบขอซื้อที่มีการแก้ไข.
การจับคู่ที่จำเป็น: จับคู่รหัสใบขอซื้อกับ PurchaseRequisitionId ป้ายชื่อเหตุการณ์กับ ActivityName เวลาเหตุการณ์กับ EventTime ค่าแหล่งข้อมูลกับ SourceSystem และเวลารีเฟรชกับ LastDataUpdate.
การจับคู่ที่แนะนำ: จับคู่สถานะใบขอซื้อ ผู้ขอซื้อ แผนกหรือศูนย์ต้นทุน จำนวนเงินรวม และผู้อนุมัติ หากตัวเชื่อมต่อรองรับสแนปชอตย้อนหลัง ให้เก็บทั้งค่าปัจจุบันและค่าของแต่ละเหตุการณ์.
กฎเหตุการณ์: ตั้งค่าให้สร้างเหตุการณ์ทั้ง 12 รายการที่จำเป็นอย่างชัดเจน ProcessMind อ่านบันทึกเหตุการณ์ตามที่ได้รับ และไม่สร้างหรืออนุมานเหตุการณ์เพิ่มเติม.
ตัวกรอง: ใช้เฉพาะตัวกรองที่ตัวเชื่อมต่อรองรับและ tenant ใช้ได้ เช่น [Your company filter], [Your document type filter], [Your business unit filter] หรือ [Your requisition date range] หลีกเลี่ยงการตัดสถานะสิ้นสุดออก เว้นแต่การวิเคราะห์ต้องการเช่นนั้นโดยเฉพาะ.
การจัดการเวลา: แปลงเวลาให้อยู่ในเขตเวลาเดียวกัน รักษาความละเอียดของเวลาต้นทาง และกำหนดกฎเรียงลำดับที่แน่นอนสำหรับเหตุการณ์ที่มีเวลาเดียวกัน.
การรีเฟรชข้อมูลส่วนเพิ่ม: ใช้ฟิลด์ updated-at หรือฟิลด์ติดตามการเปลี่ยนแปลงที่ตัวเชื่อมต่อรองรับ กำหนดช่วงเวลาย้อนกลับ เนื่องจากประวัติการอนุมัติ ลิงก์การจัดหา ลิงก์ใบสั่งซื้อ และข้อมูลการปิดรายการอาจถูกเพิ่มหลังจากสร้างข้อมูลครั้งแรก.
ประสิทธิภาพ: จำกัดการดึงข้อมูลครั้งแรกด้วยช่วงวันที่และตัวกรองทางธุรกิจที่ใช้ได้ ดึงเฉพาะฟิลด์ที่จำเป็น แบ่งหน้าออบเจ็กต์ขนาดใหญ่ และหลีกเลี่ยงการเชื่อมชุดข้อมูลย้อนหลังทั้งหมดซ้ำๆ หากรองรับ ให้ดึงข้อมูลความสัมพันธ์และข้อมูลตรวจสอบแบบส่วนเพิ่ม.
คุณภาพข้อมูล: กำหนดให้ PurchaseRequisitionId, ActivityName, EventTime, SourceSystem และ LastDataUpdate ต้องมีค่า เก็บรหัสต้นทางไว้เพื่อช่วยตรวจสอบปัญหาและลบข้อมูลซ้ำ หากตัวเชื่อมต่อแสดงรหัสเหล่านี้.
ความแตกต่างของการตั้งค่า: ชื่อออบเจ็กต์ ชื่อฟิลด์ ค่าสถานะ รูปแบบข้อมูลตรวจสอบ และข้อมูลความสัมพันธ์ที่มีให้ อาจแตกต่างกันตาม Coupa tenant และตัวเชื่อมต่อ ใช้ [Configure based on your system] หากตัวเชื่อมต่อไม่มีฟิลด์ที่เทียบเท่าตามเอกสาร.

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

WITH
requisition_created AS (
    SELECT
        CAST(r.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        CAST(r.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(r.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your requisition header object] r
    WHERE r.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND r.created_at < CAST('[Your end date]' AS TIMESTAMP)
      AND [Your company filter]
),
requisition_submitted AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Submitted' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.previous_status AS VARCHAR(255))) = 'draft'
      AND LOWER(CAST(h.new_status AS VARCHAR(255))) = 'pending_approval'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_amended AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('amended', 'updated', 'version_created')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_started AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        CAST(a.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.status AS VARCHAR(255))) = 'pending'
      AND a.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_approved AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'approved'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_rejected AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'rejected'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_withdrawn AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('withdrawn', 'withdrawal', 'cancelled_before_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_approved AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'approved'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_rejected AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'rejected'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_sourced AS (
    SELECT
        CAST(s.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Sourced' AS ActivityName,
        CAST(s.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(s.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your sourcing relationship object] s
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(s.requisition_id AS VARCHAR(255))
    WHERE s.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND s.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
purchase_order_created AS (
    SELECT
        CAST(p.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        CAST(p.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(p.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your purchase order relationship object] p
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(p.requisition_id AS VARCHAR(255))
    WHERE p.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND p.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_closed AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('closed', 'closure', 'cancelled_after_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_submitted
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_amended
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_started
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_withdrawn
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_sourced
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM purchase_order_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_closed
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

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

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

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

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

ปรับปรุงใบขอซื้อ P2P ใน Coupa ลดเวลาตั้งแต่เริ่มจนจบได้วันนี้

ค้นหาจุดที่ไม่มีประสิทธิภาพและลดเวลาตั้งแต่เริ่มจนจบของใบขอซื้อ P2P ได้ 30%.

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

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

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

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

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

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

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

ส่งออกข้อมูลใบขอซื้อด้วยรายงานตามกำหนดเวลาของ Coupa

ขั้นตอน

การกำหนดค่า

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

ดึงข้อมูลด้วยสคริปต์ Python ผ่าน Coupa REST API

ขั้นตอน

การกำหนดค่า

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

ดึงข้อมูลด้วยตัวเชื่อมต่อ iPaaS จากผู้ให้บริการภายนอก

ขั้นตอน

การกำหนดค่า

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

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

ปรับปรุงใบขอซื้อ P2P ใน Coupa ลดเวลาตั้งแต่เริ่มจนจบได้วันนี้