เทมเพลตข้อมูลกระบวนการจัดซื้อจนถึงการชำระเงินสำหรับใบสั่งซื้อ
เทมเพลตข้อมูลกระบวนการจัดซื้อจนถึงการชำระเงินสำหรับใบสั่งซื้อ
- แอตทริบิวต์ข้อมูลที่แนะนำ
- กิจกรรมหลักของกระบวนการ
- ขั้นตอนการดึงข้อมูลจาก Coupa
แอตทริบิวต์ของกระบวนการจัดซื้อจนถึงการชำระเงินสำหรับใบสั่งซื้อ
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
ActivityName
|
ชื่อเหตุการณ์หรืองานที่เกิดขึ้น ณ ช่วงเวลาหนึ่งในวงจรของใบสั่งซื้อ. | ||
|
คำอธิบาย
ชื่อกิจกรรมระบุขั้นตอนหนึ่งในกระบวนการจัดซื้อและชำระเงิน เช่น 'อนุมัติใบสั่งซื้อ' หรือ 'บันทึกรับสินค้าแล้ว' ลำดับกิจกรรมเหล่านี้ประกอบกันเป็นการไหลของกระบวนการสำหรับใบสั่งซื้อแต่ละรายการ ข้อมูลนี้เป็นพื้นฐานสำคัญของ process mining เพราะใช้สร้างแผนผังกระบวนการ ค้นหารูปแบบที่แตกต่าง และวิเคราะห์ความถี่กับลำดับของเหตุการณ์ ช่วยระบุคอขวด การแก้ไขงาน และขั้นตอนที่เบี่ยงเบนจากแนวทางมาตรฐาน ตัวอย่างเช่น การวิเคราะห์ลำดับกิจกรรม 'แก้ไขใบสั่งซื้อ' อาจช่วยให้เห็นจุดที่ทำให้ความถูกต้องของคำสั่งซื้อไม่มีประสิทธิภาพ.
เหตุผลที่สำคัญ
ข้อมูลนี้กำหนดขั้นตอนในกระบวนการ ทำให้แสดงการไหลของกระบวนการและระบุคอขวด การแก้ไขงาน และขั้นตอนที่เบี่ยงเบนได้.
แหล่งข้อมูล
ดึงจากบันทึกเหตุการณ์ บันทึกการตรวจสอบ หรือรายการเปลี่ยนสถานะที่เกี่ยวข้องกับออบเจ็กต์ Purchase Order ใน Coupa.
ตัวอย่าง
อนุมัติคำขอซื้อแล้วส่งใบสั่งซื้อเพื่ออนุมัติบันทึกรับสินค้าเข้าระบบแล้วได้รับใบแจ้งหนี้สำหรับ PO
|
|||
|
ใบสั่งซื้อ
PurchaseOrderNumber
|
รหัสเฉพาะของใบสั่งซื้อ ซึ่งใช้เป็นรหัสเคสหลักของกระบวนการ. | ||
|
คำอธิบาย
หมายเลขใบสั่งซื้อเป็นรหัสเคสหลักที่เชื่อมโยงกิจกรรมทั้งหมด ตั้งแต่คำขอซื้อครั้งแรกจนถึงการยืนยันขั้นสุดท้ายว่าได้รับสินค้าหรือบริการแล้ว หมายเลขใบสั่งซื้อแต่ละหมายเลขที่ไม่ซ้ำกันจะแทนกระบวนการจัดซื้อหนึ่งรายการ ข้อมูลนี้สำคัญต่อการทำ process mining เพราะช่วยติดตามเส้นทางการซื้อแต่ละรายการตั้งแต่ต้นจนจบ นักวิเคราะห์ใช้ข้อมูลนี้สร้างแผนผังกระบวนการ ค้นหาความแตกต่างของรูปแบบ และคำนวณ KPI ระดับเคส เช่น ระยะเวลารวมของคำสั่งซื้อ ระบบจะรวบรวมเหตุการณ์และข้อมูลที่เกี่ยวข้องไว้ภายใต้รหัสนี้ เพื่อให้เห็นภาพกระบวนการได้ครบถ้วน.
เหตุผลที่สำคัญ
ข้อมูลนี้จำเป็นต่อการติดตามวงจรของการซื้อแต่ละรายการ และสร้างกระบวนการแต่ละรายการขึ้นใหม่เพื่อวิเคราะห์อย่างละเอียด.
แหล่งข้อมูล
นี่คือฟิลด์คีย์หลักมาตรฐานของออบเจ็กต์ Purchase Order ใน Coupa.
ตัวอย่าง
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
เวลาเริ่มต้น
EventTime
|
เวลาที่ระบุอย่างแม่นยำว่าเกิดกิจกรรมหรือเหตุการณ์เมื่อใด. | ||
|
คำอธิบาย
เวลาเกิดเหตุการณ์บันทึกวันที่และเวลาที่ดำเนินกิจกรรมหนึ่ง ๆ สำหรับทุกกิจกรรมในกระบวนการ จะมีเวลาที่ระบุว่าเกิดกิจกรรมนั้นเมื่อใด ข้อมูลนี้สำคัญต่อการวิเคราะห์ตามเวลาใน process mining ใช้คำนวณเวลาระหว่างกิจกรรม วัดระยะเวลาของกระบวนการ และค้นหาความล่าช้า ตัวอย่างเช่น ใช้ผลต่างระหว่างเวลาที่ 'จัดทำร่างใบสั่งซื้อ' กับ 'อนุมัติใบสั่งซื้อ' เพื่อคำนวณ KPI ระยะเวลาการอนุมัติ PO.
เหตุผลที่สำคัญ
ข้อมูลนี้ระบุช่วงเวลาที่เกิดแต่ละเหตุการณ์ ซึ่งจำเป็นต่อการคำนวณเวลาของรอบการทำงาน วิเคราะห์ผลการดำเนินงาน และตรวจหาคอขวด.
แหล่งข้อมูล
ดูได้จากบันทึกเหตุการณ์หรือบันทึกการตรวจสอบใน Coupa โดยทั่วไปจะเชื่อมโยงกับการเปลี่ยนสถานะหรือการดำเนินการแต่ละครั้งของใบสั่งซื้อ.
ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่ดึงข้อมูลกระบวนการออกมา. | ||
|
คำอธิบาย
ข้อมูลนี้ระบุระบบสารสนเทศต้นทางที่บันทึกข้อมูลเหตุการณ์ สำหรับกระบวนการนี้ ค่าจะเป็น 'Coupa' เสมอ ในองค์กรที่ใช้ข้อมูลจากหลายระบบ เช่น Coupa สำหรับการจัดซื้อและ ERP อีกระบบสำหรับการออกใบแจ้งหนี้ ข้อมูลนี้ช่วยแยกแหล่งที่มาของข้อมูล ทำให้ตรวจสอบที่มาของข้อมูลได้ชัดเจน และกรองการวิเคราะห์ให้แสดงมุมมองของระบบที่ต้องการได้.
เหตุผลที่สำคัญ
ข้อมูลนี้ช่วยระบุที่มาของข้อมูล ทำให้ตรวจสอบย้อนกลับได้และกำกับดูแลข้อมูลได้เหมาะสม โดยเฉพาะเมื่อใช้หลายระบบ.
แหล่งข้อมูล
โดยทั่วไปจะเพิ่มค่าคงที่นี้ระหว่างการดึงและแปลงข้อมูล เพื่อระบุชุดข้อมูล.
ตัวอย่าง
Coupa
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ระบุว่ามีการรีเฟรชข้อมูลของกระบวนการนี้ครั้งล่าสุดเมื่อใด. | ||
|
คำอธิบาย
ข้อมูลนี้บันทึกเวลาที่อัปเดตชุดข้อมูลจากระบบต้นทางครั้งล่าสุด เป็นฟิลด์ข้อมูลกำกับที่ใช้กับชุดข้อมูลทั้งหมด ไม่ใช่เหตุการณ์แต่ละรายการ ในแดชบอร์ดวิเคราะห์ข้อมูล เวลานี้ช่วยให้ผู้ใช้ทราบว่าข้อมูลที่กำลังดูเป็นข้อมูลล่าสุดเพียงใด และมั่นใจได้ว่าข้อมูลเชิงลึกอ้างอิงข้อมูลที่เป็นปัจจุบัน ทั้งยังช่วยให้เข้าใจว่าข้อมูลได้รับการอัปเดตถึงเมื่อใด โดยทั่วไปจะแสดงเวลาไว้อย่างเด่นชัดในแดชบอร์ด.
เหตุผลที่สำคัญ
แจ้งให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด เพื่อให้เข้าใจว่าการวิเคราะห์กระบวนการและ KPI อ้างอิงข้อมูลล่าสุดแค่ไหน.
แหล่งข้อมูล
ระบบจะสร้างและจัดเก็บเวลานี้เมื่อไปป์ไลน์การดึงและโหลดข้อมูล (ETL) ทำงาน.
ตัวอย่าง
2023-11-01T05:00:00Z
|
|||
|
ชื่อผู้ขาย
VendorName
|
ชื่อซัพพลายเออร์หรือผู้ขายที่จัดหาสินค้าหรือบริการ. | ||
|
คำอธิบาย
ชื่อผู้ขายระบุบุคคลหรือองค์กรภายนอกที่จัดหาสินค้าตามใบสั่งซื้อ ข้อมูลนี้เป็นพื้นฐานสำคัญของการวิเคราะห์การจัดซื้อ การวิเคราะห์ประสิทธิภาพของกระบวนการแยกตามผู้ขายมีความสำคัญต่อการบริหารความสัมพันธ์กับซัพพลายเออร์ ช่วยประเมิน «ประสิทธิภาพระยะเวลานำส่งของซัพพลายเออร์» ระบุ «ความล่าช้าในกระบวนการรับสินค้า» และประเมินคุณภาพซัพพลายเออร์จาก «อัตราการคืนสินค้า» แอตทริบิวต์นี้ยังใช้คำนวณ KPI «สัดส่วนการใช้จ่ายกับผู้ขายที่ไม่ใช่รายที่ต้องการ».
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ประสิทธิภาพของซัพพลายเออร์ เพื่อปรับการคัดเลือก ต่อรองเงื่อนไขให้ดีขึ้น และระบุผู้ขายที่มีผลการดำเนินงานสูงหรือต่ำ.
แหล่งข้อมูล
เป็นฟิลด์มาตรฐานในส่วนหัวของใบสั่งซื้อใน Coupa และเชื่อมโยงกับข้อมูลหลักของซัพพลายเออร์.
ตัวอย่าง
อุปกรณ์สำนักงานโกลบอลTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
ผู้ใช้
User
|
รหัสหรือชื่อผู้ใช้ของผู้ที่ดำเนินกิจกรรม เช่น ผู้อนุมัติหรือผู้ขอซื้อ. | ||
|
คำอธิบาย
ข้อมูลนี้ระบุผู้รับผิดชอบในการดำเนินเหตุการณ์หนึ่ง ๆ ในกระบวนการ เช่น ผู้จัดทำร่างคำสั่งซื้อ ผู้จัดการที่อนุมัติ หรือเจ้าหน้าที่ที่บันทึกรับสินค้า การวิเคราะห์ผลการดำเนินงานตามผู้ใช้ช่วยระบุความต้องการในการฝึกอบรม ผู้ที่ทำงานได้ดี และการกระจายภาระงาน ตัวอย่างเช่น แดชบอร์ด 'ผลการดำเนินงานด้านระยะเวลาการอนุมัติ PO' ใช้ข้อมูลนี้แยกเวลาการอนุมัติตามผู้อนุมัติแต่ละคน เพื่อให้เห็นว่าใครอาจเป็นคอขวดในกระบวนการ.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ผลการดำเนินงานของกระบวนการตามบุคคลหรือบทบาท ทำให้ระบุคอขวด โอกาสในการฝึกอบรม และปัญหาการจัดสรรทรัพยากรได้.
แหล่งข้อมูล
เชื่อมโยงกับแต่ละเหตุการณ์ในบันทึกการตรวจสอบหรือประวัติ Purchase Order ใน Coupa โดยทั่วไปจะใช้ฟิลด์อย่าง 'Created By', 'Approved By' หรือ 'Updated By'.
ตัวอย่าง
j.doea.smithm.jones
|
|||
|
แผนก
Department
|
แผนกธุรกิจหรือศูนย์ต้นทุนที่รับผิดชอบค่าใช้จ่ายของใบสั่งซื้อ. | ||
|
คำอธิบาย
แอตทริบิวต์แผนกระบุหน่วยงานที่เริ่มการซื้อหรือรับผิดชอบค่าใช้จ่าย โดยมักเชื่อมโยงกับผู้ขอซื้อหรือข้อมูลศูนย์ต้นทุนในรายการสินค้าและบริการของใบสั่งซื้อ มิตินี้จำเป็นต่อการแบ่งกลุ่มเพื่อวิเคราะห์กระบวนการและ KPI ผู้จัดการสามารถเปรียบเทียบประสิทธิภาพกระบวนการ การปฏิบัติตามข้อกำหนด และรูปแบบการใช้จ่ายระหว่างหน่วยงานต่างๆ ได้ ตัวอย่างเช่น แดชบอร์ด «วิเคราะห์การใช้จ่ายตามหมวดหมู่การซื้อ» ใช้แผนกเพื่อแสดงให้เห็นว่าแต่ละหน่วยธุรกิจใช้งบประมาณอย่างไร.
เหตุผลที่สำคัญ
ช่วยกรองและเปรียบเทียบการวิเคราะห์กระบวนการและการใช้จ่ายระหว่างหน่วยธุรกิจต่างๆ เพื่อให้เห็นความแตกต่างด้านประสิทธิภาพและการปฏิบัติตามข้อกำหนด.
แหล่งข้อมูล
มีอยู่ในส่วนหัวหรือรายการสินค้าและบริการของใบสั่งซื้อใน Coupa โดยมักเชื่อมโยงกับศูนย์ต้นทุนหรือหน่วยงาน.
ตัวอย่าง
การตลาดเทคโนโลยีสารสนเทศการปฏิบัติการการเงิน
|
|||
|
มูลค่ารวมของใบสั่งซื้อ
TotalOrderAmount
|
มูลค่าเงินรวมของใบสั่งซื้อ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงค่าใช้จ่ายรวมของสินค้าและบริการทั้งหมดในใบสั่งซื้อ โดยระบุเป็นสกุลเงินหนึ่งๆ และใช้กับใบสั่งซื้อทั้งรายการ ข้อมูลทางการเงินนี้สำคัญต่อการวิเคราะห์การใช้จ่ายและการจัดลำดับความสำคัญของการปรับปรุงกระบวนการ ใบสั่งซื้อมูลค่าสูงอาจต้องผ่านการตรวจสอบละเอียดขึ้นหรือใช้เส้นทางอนุมัติที่ต่างออกไป ข้อมูลนี้ใช้โดยตรงในแดชบอร์ด «วิเคราะห์การใช้จ่ายตามหมวดหมู่การซื้อ» และเป็นส่วนหนึ่งของการคำนวณ KPI «สัดส่วนการใช้จ่ายกับผู้ขายที่ไม่ใช่รายที่ต้องการ».
เหตุผลที่สำคัญ
ให้ข้อมูลทางการเงินประกอบการซื้อแต่ละครั้ง ช่วยวิเคราะห์การใช้จ่าย จัดลำดับความสำคัญของใบสั่งซื้อมูลค่าสูง และประเมินผลกระทบทางการเงิน.
แหล่งข้อมูล
มีอยู่ในส่วนหัวของใบสั่งซื้อใน Coupa โดยทั่วไปใช้ชื่อ «Total» หรือ «Grand Total».
ตัวอย่าง
1500.00250.7512500.50
|
|||
|
หมวดหมู่การซื้อ
PurchaseCategory
|
การจัดประเภทสินค้าหรือบริการที่ซื้อ เช่น อุปกรณ์ไอทีหรือบริการวิชาชีพ. | ||
|
คำอธิบาย
หมวดหมู่การซื้อ หรือที่เรียกว่าหมวดสินค้าโภคภัณฑ์หรือกลุ่มวัสดุ เป็นการจัดประเภทเพื่อรวมรายการซื้อที่คล้ายกันไว้ด้วยกัน ข้อมูลที่จัดโครงสร้างเช่นนี้ช่วยให้วิเคราะห์การใช้จ่ายและกระบวนการจัดซื้อได้อย่างเป็นระบบ ใน process mining แอตทริบิวต์นี้ใช้แบ่งกลุ่มและกรองข้อมูลได้ แดชบอร์ด «วิเคราะห์การใช้จ่ายตามหมวดหมู่การซื้อ» ใช้ข้อมูลนี้เพื่อแจกแจงรูปแบบการใช้จ่าย นอกจากนี้ยังช่วยให้เห็นว่าหมวดหมู่บางประเภท เช่น บริการที่ซับซ้อน ใช้เวลาตลอดวงจรนานกว่าหรือมีอัตราการเปลี่ยนแปลงสูงกว่าหมวดอื่น เช่น อุปกรณ์สำนักงานทั่วไปหรือไม่.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์การใช้จ่ายและกระบวนการตามหมวดหมู่ เพื่อระบุรูปแบบการจัดซื้อ ต่อรองกับผู้ขาย และกำหนดการควบคุมกระบวนการให้เหมาะสม.
แหล่งข้อมูล
โดยทั่วไปอยู่ในระดับรายการสินค้าและบริการของใบสั่งซื้อใน Coupa และมักเชื่อมโยงกับรหัสสินค้าโภคภัณฑ์หรือแค็ตตาล็อกการจัดซื้อ.
ตัวอย่าง
อุปกรณ์ไอทีอุปกรณ์สำนักงานบริการวิชาชีพสื่อการตลาด
|
|||
|
จัดส่งตรงเวลาหรือไม่
IsDeliveryOnTime
|
แฟล็กที่คำนวณขึ้นเพื่อระบุว่าได้รับสินค้าตรงกับหรือก่อนวันที่ต้องการให้จัดส่งหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์แบบบูลีนนี้คำนวณโดยเปรียบเทียบเวลาของเหตุการณ์ «Goods Receipt Posted» กับ «RequestedDeliveryDate» โดยกำหนดเป็น true หากได้รับสินค้าในหรือก่อนวันที่ต้องการ แฟล็กนี้รองรับ KPI «การส่งมอบตรงตามวันที่ต้องการของซัพพลายเออร์» และแดชบอร์ด «ความคลาดเคลื่อนของวันที่จัดส่งและการคืนสินค้า» โดยแสดงผลการส่งมอบตรงเวลาเป็นค่าที่ชัดเจนสองสถานะ ซึ่งนำไปรวมและแสดงผลได้ง่าย ช่วยให้ระบุปัญหาด้านประสิทธิภาพของผู้ขายหรือกระบวนการรับสินค้าภายในได้รวดเร็ว.
เหตุผลที่สำคัญ
ให้ตัวชี้วัดประสิทธิภาพการจัดส่งที่ชัดเจนแบบสองค่า ช่วยคำนวณ KPI การส่งมอบตรงเวลาและวิเคราะห์แนวโน้มได้ง่ายขึ้น.
แหล่งข้อมูล
คำนวณระหว่างการแปลงข้อมูล โดยเปรียบเทียบ «RequestedDeliveryDate» กับเวลาของกิจกรรม «Goods Receipt Posted».
ตัวอย่าง
truefalse
|
|||
|
ชื่อผู้ขอซื้อ
RequesterName
|
ชื่อบุคคลที่เริ่มขอซื้อสินค้าหรือบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุพนักงานที่สร้างใบขอซื้อซึ่งนำไปสู่ใบสั่งซื้อ ผู้ขอซื้อคือผู้ใช้ในหน่วยธุรกิจที่ต้องการสินค้า ซึ่งอาจไม่ใช่ผู้ซื้อหรือผู้อนุมัติ การวิเคราะห์รูปแบบการทำงานแยกตามผู้ขอซื้อช่วยให้เห็นรูปแบบที่เกี่ยวข้องกับผู้ใช้หรือแผนกต่างๆ แดชบอร์ด «วิเคราะห์การเปลี่ยนแปลงใบสั่งซื้อ» ใช้ข้อมูลนี้ตรวจสอบว่าผู้ขอซื้อบางรายมีการเปลี่ยนแปลงคำสั่งซื้อบ่อยกว่าหรือไม่ ซึ่งอาจบ่งชี้ว่าควรอบรมเรื่องการระบุข้อกำหนดให้ชัดเจนขึ้น.
เหตุผลที่สำคัญ
ช่วยระบุที่มาของการซื้อในหน่วยธุรกิจ และวิเคราะห์พฤติกรรมการจัดซื้อกับความถูกต้องในระดับผู้ขอซื้อ.
แหล่งข้อมูล
โดยปกติข้อมูลนี้จัดเก็บไว้ในใบขอซื้อต้นทางและส่งต่อไปยังใบสั่งซื้อใน Coupa.
ตัวอย่าง
Alice CooperBob DylanCharlie Parker
|
|||
|
เป็นการทำงานซ้ำหรือไม่
IsRework
|
แฟล็กที่คำนวณขึ้นเพื่อระบุว่าใบสั่งซื้อมีการเปลี่ยนแปลงหรือไม่. | ||
|
คำอธิบาย
แฟล็กแบบบูลีนนี้กำหนดเป็น true สำหรับใบสั่งซื้อที่มีเหตุการณ์ «Purchase Order Changed» อย่างน้อยหนึ่งครั้งในประวัติ เป็นแอตทริบิวต์ระดับเคสที่คำนวณจากบันทึกเหตุการณ์ แอตทริบิวต์นี้ช่วยให้คำนวณ KPI เช่น «อัตราการเปลี่ยนแปลงใบสั่งซื้อ» ได้ง่ายขึ้น และกรองหรือแบ่งกลุ่มข้อมูลเพื่อเปรียบเทียบกระบวนการของใบสั่งซื้อที่มีและไม่มีการทำงานซ้ำ ช่วยวัดผลกระทบของการเปลี่ยนแปลงต่อระยะเวลาตลอดวงจรและค่าใช้จ่าย แอตทริบิวต์นี้เป็นองค์ประกอบหลักของแดชบอร์ด «วิเคราะห์การเปลี่ยนแปลงใบสั่งซื้อ».
เหตุผลที่สำคัญ
ช่วยให้วิเคราะห์การทำงานซ้ำได้ง่าย โดยกรองและรวมข้อมูลใบสั่งซื้อทั้งหมดที่มีการเปลี่ยนแปลงอย่างน้อยหนึ่งครั้ง.
แหล่งข้อมูล
คำนวณระหว่างการแปลงข้อมูล โดยตรวจสอบว่ามีกิจกรรม «Purchase Order Changed» สำหรับ PurchaseOrderNumber แต่ละรายการหรือไม่.
ตัวอย่าง
truefalse
|
|||
|
เป็นผู้ขายรายที่ต้องการหรือไม่
IsPreferredVendor
|
แฟล็กแบบบูลีนที่ระบุว่าซื้อจากผู้ขายรายที่ต้องการหรือผู้ขายเชิงกลยุทธ์หรือไม่. | ||
|
คำอธิบาย
แฟล็กนี้ระบุว่าผู้ขายในใบสั่งซื้ออยู่ในรายชื่อซัพพลายเออร์เชิงกลยุทธ์ที่ผ่านการอนุมัติล่วงหน้าหรือไม่ โดยทั่วไปจะตรวจสอบชื่อหรือ ID ผู้ขายกับรายชื่อผู้ขายที่ต้องการ แอตทริบิวต์นี้สำคัญต่อการจัดหาเชิงกลยุทธ์และการบริหารการใช้จ่าย ใช้คำนวณ KPI «สัดส่วนการใช้จ่ายกับผู้ขายที่ไม่ใช่รายที่ต้องการ» ซึ่งช่วยให้องค์กรติดตามและควบคุมการจัดซื้อนอกนโยบาย รวมทั้งรวมยอดใช้จ่ายไว้กับคู่ค้าหลักเพื่อรับส่วนลดตามปริมาณและเงื่อนไขที่ดีขึ้น.
เหตุผลที่สำคัญ
ช่วยติดตามการปฏิบัติตามนโยบายการจัดซื้อและเป้าหมายการจัดหาเชิงกลยุทธ์ โดยตรวจสอบการใช้จ่ายกับซัพพลายเออร์รายที่ต้องการและรายอื่นๆ.
แหล่งข้อมูล
ข้อมูลนี้มักไม่มีเป็นฟิลด์มาตรฐานใน Coupa แต่คำนวณได้จากการเปรียบเทียบ Vendor ID ใน PO กับรายชื่อผู้ขายที่ต้องการจากภายนอก.
ตัวอย่าง
truefalse
|
|||
|
วันที่ต้องการให้จัดส่ง
RequestedDeliveryDate
|
วันที่ผู้ขอซื้อระบุว่าต้องการให้จัดส่งสินค้าหรือบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้คือวันที่เป้าหมายในการจัดส่ง ซึ่งผู้ใช้ในหน่วยธุรกิจระบุไว้ระหว่างขั้นตอนขอซื้อ และแสดงความคาดหวังของธุรกิจว่าควรได้รับสินค้าตามคำสั่งซื้อเมื่อใด วันที่นี้เป็นเกณฑ์สำคัญในการวัดประสิทธิภาพของซัพพลายเออร์และการทำงานภายใน โดยใช้คำนวณ KPI «การส่งมอบตรงตามวันที่ต้องการของซัพพลายเออร์» ด้วยการเปรียบเทียบกับวันที่เกิดเหตุการณ์ «Goods Receipt Posted» แดชบอร์ด «ความคลาดเคลื่อนของวันที่จัดส่งและการคืนสินค้า» แสดงความแตกต่างระหว่างวันที่ต้องการกับวันที่ได้รับสินค้าจริง ช่วยให้จัดการความคาดหวังและปรับปรุงการคาดการณ์ได้.
เหตุผลที่สำคัญ
ใช้เป็นเกณฑ์หลักในการวัดการส่งมอบตรงเวลาของผู้ขายและประสิทธิภาพของกระบวนการรับสินค้าภายใน.
แหล่งข้อมูล
เป็นฟิลด์มาตรฐานในรายการสินค้าและบริการของใบสั่งซื้อใน Coupa.
ตัวอย่าง
2023-11-152023-12-012024-01-10
|
|||
|
สกุลเงิน
Currency
|
รหัสสกุลเงินที่ใช้กับมูลค่าเงินในใบสั่งซื้อ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุสกุลเงิน เช่น USD, EUR หรือ GBP ที่ใช้แสดงยอดรวมใบสั่งซื้อ จึงจำเป็นต่อการตีความข้อมูลทางการเงินขององค์กรที่ดำเนินงานในหลายประเทศอย่างถูกต้อง สำหรับบริษัทข้ามชาติ การวิเคราะห์การใช้จ่ายโดยไม่คำนึงถึงสกุลเงินอาจทำให้เข้าใจผิด แอตทริบิวต์นี้ช่วยแปลงสกุลเงินและจัดทำรายงานทางการเงินในแดชบอร์ดให้สอดคล้องกัน เพื่อให้เปรียบเทียบมูลค่าในหน่วยเดียวกันได้.
เหตุผลที่สำคัญ
ช่วยให้วิเคราะห์และรายงานข้อมูลทางการเงินขององค์กรข้ามชาติได้อย่างถูกต้อง โดยให้ข้อมูลที่จำเป็นสำหรับการแปลงสกุลเงิน.
แหล่งข้อมูล
เป็นฟิลด์มาตรฐานในส่วนหัวของใบสั่งซื้อใน Coupa.
ตัวอย่าง
USDEURGBPJPY
|
|||
|
สถานที่รับสินค้า
ReceivingLocation
|
สถานที่จริง เช่น คลังสินค้าหรือสำนักงาน ที่ต้องจัดส่งสินค้าไป. | ||
|
คำอธิบาย
สถานที่รับสินค้าระบุปลายทางของสินค้าที่สั่งซื้อใน PO ซึ่งอาจเป็นคลังสินค้า โรงงาน หรือที่อยู่สำนักงานแห่งใดแห่งหนึ่ง แอตทริบิวต์นี้ใช้วิเคราะห์ประสิทธิภาพด้านโลจิสติกส์และการรับสินค้าของแต่ละสถานที่ คุณสามารถกรองแดชบอร์ด «ความล่าช้าในกระบวนการรับสินค้า» ด้วยแอตทริบิวต์นี้ เพื่อดูว่าสถานที่ใดใช้เวลาจัดการสินค้าขาเข้านานกว่า ซึ่งช่วยระบุจุดที่การปฏิบัติการไม่มีประสิทธิภาพหรือมีทรัพยากรไม่เพียงพอ.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์กระบวนการรับสินค้าตามสถานที่ และแสดงความแตกต่างด้านประสิทธิภาพระหว่างคลังสินค้า โรงงาน และสำนักงาน.
แหล่งข้อมูล
ข้อมูลนี้เป็นส่วนหนึ่งของที่อยู่ «Ship-To» ในใบสั่งซื้อของ Coupa.
ตัวอย่าง
คลังสินค้า A - ชิคาโกอาคาร 5 - สำนักงานลอนดอนโรงงานแฟรงก์เฟิร์ต
|
|||
|
หมายเลขใบขอซื้อ
PurchaseRequisitionNumber
|
รหัสเฉพาะของใบขอซื้อที่จัดทำก่อนใบสั่งซื้อ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้เชื่อมโยงใบสั่งซื้อกับใบขอซื้อที่เป็นต้นทาง ใบขอซื้อหนึ่งรายการอาจนำไปสู่ใบสั่งซื้อตั้งแต่หนึ่งรายการขึ้นไป การเชื่อมโยงนี้จำเป็นต่อการวิเคราะห์ระยะเวลาตั้งแต่ขอซื้อจนถึงออกใบสั่งซื้อ โดยเชื่อมเหตุการณ์สร้างใบขอซื้อกับเหตุการณ์สร้างและส่งใบสั่งซื้อ องค์กรจึงวัดประสิทธิภาพของกระบวนการเริ่มจัดซื้อทั้งหมดได้ ตั้งแต่การขอซื้อจนถึงการจัดส่ง.
เหตุผลที่สำคัญ
เชื่อมช่วงการขอซื้อกับช่วงการออกใบสั่งซื้อ ช่วยวิเคราะห์ระยะเวลาตั้งแต่ขอซื้อจนถึงออกใบสั่งซื้อและอัตราการเปลี่ยนคำขอเป็นคำสั่งซื้อ.
แหล่งข้อมูล
โดยทั่วไปเป็นฟิลด์อ้างอิงในรายการสินค้าและบริการของใบสั่งซื้อใน Coupa ซึ่งเชื่อมกลับไปยังใบขอซื้อต้นทาง.
ตัวอย่าง
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
เหตุผลที่แก้ไข
ChangeReason
|
เหตุผลที่ระบุเมื่อมีการแก้ไขใบสั่งซื้อหลังจากสร้างครั้งแรก. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกเหตุผลที่แก้ไขใบสั่งซื้อ เช่น «ปรับปรุงจำนวน» หรือ «แก้ไขราคา» โดยมักบันทึกไว้ในประวัติการตรวจสอบเมื่อผู้ใช้ดำเนินกิจกรรม «Purchase Order Changed» การเข้าใจสาเหตุที่มีการเปลี่ยนแปลงคำสั่งซื้อเป็นหัวใจสำคัญของแดชบอร์ด «วิเคราะห์การเปลี่ยนแปลงใบสั่งซื้อ» ช่วยแยกการเปลี่ยนแปลงที่หลีกเลี่ยงไม่ได้ เช่น ผู้ขายมีสินค้าไม่พอ ออกจากกรณีที่ป้องกันได้ เช่น กรอกข้อมูลครั้งแรกไม่ถูกต้อง และช่วยกำหนดแนวทางเพิ่มความถูกต้องของคำสั่งซื้อและลด KPI «อัตราการเปลี่ยนแปลงใบสั่งซื้อ».
เหตุผลที่สำคัญ
อธิบายสาเหตุหลักของการเปลี่ยนแปลง PO เพื่อให้แก้ไขได้ตรงจุด เพิ่มความถูกต้องของใบสั่งซื้อตั้งแต่ครั้งแรก และลดการทำงานซ้ำ.
แหล่งข้อมูล
มักพบในบันทึกการตรวจสอบหรือความคิดเห็นที่เชื่อมโยงกับเหตุการณ์เปลี่ยนแปลงใบสั่งซื้อใน Coupa.
ตัวอย่าง
ผู้ขายปรับราคาปรับวันที่จัดส่งแก้ไขรหัสสินค้า
|
|||
|
เหตุผลที่ปฏิเสธ
RejectionReason
|
เหตุผลที่ระบุเมื่อใบขอซื้อหรือใบสั่งซื้อถูกปฏิเสธในขั้นตอนอนุมัติ. | ||
|
คำอธิบาย
เมื่อผู้อนุมัติปฏิเสธใบสั่งซื้อ มักระบุเหตุผลไว้ด้วย แอตทริบิวต์นี้บันทึกคำอธิบายดังกล่าว เช่น «รหัสงบประมาณไม่ถูกต้อง» หรือ «เกินวงเงินที่กำหนด» การวิเคราะห์เหตุผลที่ปฏิเสธช่วยให้เห็นสาเหตุหลักของการทำงานซ้ำและปัญหาในกระบวนการ ข้อมูลเชิงคุณภาพนี้ช่วยระบุข้อผิดพลาดที่พบบ่อยในขั้นตอนขอซื้อ เพื่อนำไปวางแผนอบรมหรือปรับปรุงระบบให้ตรงจุด ป้องกันการถูกปฏิเสธซ้ำและเพิ่มอัตราการอนุมัติในครั้งแรก.
เหตุผลที่สำคัญ
ช่วยให้เห็นสาเหตุที่ใบสั่งซื้อถูกปฏิเสธอย่างชัดเจนและนำไปแก้ไขได้ เพื่อจัดการต้นเหตุของการทำงานซ้ำและความล่าช้าในกระบวนการ.
แหล่งข้อมูล
โดยทั่วไปบันทึกไว้ในช่องความคิดเห็นหรือหมายเหตุที่เชื่อมโยงกับกิจกรรม «Purchase Order Rejected» หรือ «Purchase Requisition Rejected» ในเวิร์กโฟลว์การอนุมัติของ Coupa.
ตัวอย่าง
คำขอซ้ำงบประมาณไม่ได้รับอนุมัติเลือกผู้ขายไม่ถูกต้อง
|
|||
|
อนุมัติผ่านในครั้งแรกหรือไม่
IsFirstPassApproval
|
แฟล็กที่คำนวณขึ้นและมีค่า true หากอนุมัติ PO โดยไม่มีการเปลี่ยนแปลงหลังจากร่างเสร็จ. | ||
|
คำอธิบาย
แฟล็กแบบบูลีนนี้กำหนดเป็น true หากระหว่างเหตุการณ์ «Purchase Order Drafted» กับ «Purchase Order Approved» ไม่มีเหตุการณ์ «Purchase Order Changed» หรือ «Purchase Order Rejected» เกิดขึ้น แอตทริบิวต์นี้ใช้วัด KPI «อัตราการอนุมัติ PO ในครั้งแรก» โดยตรง อัตราที่สูงแสดงว่าการดำเนินการครั้งแรกมีประสิทธิภาพและถูกต้อง การวิเคราะห์กรณีที่แฟล็กนี้เป็น false ช่วยค้นหาสาเหตุของการทำงานซ้ำและปรับปรุงคุณภาพข้อมูลของใบสั่งซื้อตั้งแต่ต้น.
เหตุผลที่สำคัญ
วัดประสิทธิภาพของขั้นตอนสร้างและอนุมัติครั้งแรกโดยตรง พร้อมแสดงจำนวนใบสั่งซื้อที่ดำเนินไปได้โดยไม่ต้องทำงานซ้ำ.
แหล่งข้อมูล
คำนวณระหว่างการแปลงข้อมูล โดยวิเคราะห์ลำดับเหตุการณ์ของ PurchaseOrderNumber แต่ละรายการ.
ตัวอย่าง
truefalse
|
|||
กิจกรรมในกระบวนการจัดซื้อจนถึงการชำระเงินสำหรับใบสั่งซื้อ
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
บันทึกรับสินค้าเข้าระบบแล้ว
|
เหตุการณ์นี้เป็นการยืนยันอย่างเป็นทางการว่าได้รับ ตรวจสอบ และยอมรับสินค้าแล้ว พร้อมอัปเดตข้อมูลสินค้าคงคลังและยืนยันว่าซัพพลายเออร์ส่งมอบสินค้าครบตามหน้าที่แล้ว. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สำคัญนี้เป็นจุดสิ้นสุดของระยะเวลารอจากซัพพลายเออร์ และใช้วัดว่าการส่งมอบตรงตามวันที่กำหนดหรือไม่ หากบันทึกรับสินค้าล่าช้า ก็อาจทำให้มองไม่เห็นระดับสินค้าคงคลังจริง.
แหล่งข้อมูล
นี่คือธุรกรรมหลักใน Coupa ซึ่งบันทึกไว้ในออบเจ็กต์ Receipt ระบบจะบันทึกเหตุการณ์เมื่อสถานะการรับสินค้าเปลี่ยนเป็น 'Posted' หรือ 'Received'.
บันทึก
บันทึกเมื่อธุรกรรมรับสินค้าเสร็จสมบูรณ์ในระบบ.
ประเภทเหตุการณ์
explicit
|
|||
|
ปิดใบสั่งซื้อ
|
กิจกรรมสุดท้ายนี้หมายถึงใบสั่งซื้อเสร็จสมบูรณ์แล้ว โดยถือว่าปิดใบสั่งซื้อเมื่อได้รับสินค้าครบและได้รับใบแจ้งหนี้ครบแล้ว และไม่มีธุรกรรมอื่นที่คาดว่าจะเกิดขึ้น. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดอย่างเป็นทางการของวงจรใบสั่งซื้อ การวิเคราะห์เวลาที่ใช้ปิดรายการช่วยให้เห็นความไม่มีประสิทธิภาพในการกระทบยอดและจัดเก็บบันทึกขั้นสุดท้าย.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนสถานะของออบเจ็กต์ Purchase Order เป็น 'Closed' โดย Coupa มักกำหนดสถานะนี้โดยอัตโนมัติตามกฎธุรกิจเกี่ยวกับเกณฑ์การรับสินค้าและใบแจ้งหนี้.
บันทึก
อนุมานจากเวลาที่สถานะเปลี่ยนเป็น 'Closed'.
ประเภทเหตุการณ์
inferred
|
|||
|
ยกเลิกใบสั่งซื้อ
|
กิจกรรมนี้หมายถึงการยกเลิกใบสั่งซื้อก่อนดำเนินการเสร็จสิ้น การยกเลิกอาจเกิดขึ้นได้หลายขั้นตอน เช่น เมื่อคำขอไม่จำเป็นแล้วหรือสร้างใบสั่งซื้อผิดพลาด. | ||
|
เหตุผลที่สำคัญ
การติดตามการยกเลิกซึ่งเป็นอีกทางหนึ่งที่กระบวนการอาจสิ้นสุด ช่วยให้เข้าใจว่าคำขอซื้อไม่สำเร็จตรงจุดใด และค้นหาเหตุผลที่ทำให้มีการละทิ้งคำขอ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนสถานะของออบเจ็กต์ Purchase Order เป็น 'Canceled' โดยใช้เวลาที่สถานะเปลี่ยนเป็นเวลาเกิดเหตุการณ์.
บันทึก
อนุมานจากเวลาที่สถานะเปลี่ยนเป็น 'Canceled'.
ประเภทเหตุการณ์
inferred
|
|||
|
ส่งใบสั่งซื้อให้ผู้ขาย
|
กิจกรรมนี้บันทึกเวลาที่ส่งใบสั่งซื้อที่ได้รับอนุมัติให้ผู้ขายอย่างเป็นทางการ เช่น ทางอีเมลหรือ Coupa Supplier Portal เหตุการณ์นี้เปลี่ยนใบสั่งซื้อจากเอกสารภายในให้เป็นข้อผูกพันกับผู้ขาย. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สำคัญนี้ปิดรอบการทำงานภายในตั้งแต่ขอซื้อจนถึงออกใบสั่งซื้อ และเริ่มนับระยะเวลารอจากซัพพลายเออร์ จึงจำเป็นต่อการวัดทั้งประสิทธิภาพภายในและผลการดำเนินงานของซัพพลายเออร์.
แหล่งข้อมูล
มักอนุมานจากการเปลี่ยนสถานะของใบสั่งซื้อเป็น 'Ordered' หรือ 'Sent' นอกจากนี้ Coupa อาจมีฟิลด์เวลาบนรายการใบสั่งซื้อโดยเฉพาะ เช่น 'last_exported_at' หรือ 'sent_to_supplier_at'.
บันทึก
อนุมานจากเวลาที่สถานะเปลี่ยนเป็น 'Ordered' หรือจากฟิลด์เวลาที่บันทึกการส่งโดยเฉพาะ.
ประเภทเหตุการณ์
inferred
|
|||
|
สร้างคำขอซื้อ
|
กิจกรรมนี้บันทึกการสร้างคำขอซื้อ ซึ่งเป็นคำขออย่างเป็นทางการสำหรับสินค้าหรือบริการ และเกิดขึ้นก่อนออกใบสั่งซื้อ ใน Coupa ระบบจะบันทึกเหตุการณ์นี้เมื่อผู้ใช้บันทึกและส่งเอกสารคำขอซื้อใหม่. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้มักเป็นจุดเริ่มต้นของกระบวนการจัดซื้อ จึงจำเป็นต่อการวัดเวลาตั้งแต่ขอซื้อจนถึงออกใบสั่งซื้อทั้งหมด และทำความเข้าใจประสิทธิภาพของขั้นตอนก่อนหน้า.
แหล่งข้อมูล
เหตุการณ์นี้ตรงกับรายการสร้างข้อมูลในออบเจ็กต์หรือตาราง Purchase Requisitions ของ Coupa โดยดูเวลาได้จากฟิลด์วันที่สร้างที่ระบบกำหนด เช่น 'created_at' หรือฟิลด์ที่เทียบเท่า.
บันทึก
บันทึกโดยตรงเมื่อสร้างรายการคำขอซื้อใหม่.
ประเภทเหตุการณ์
explicit
|
|||
|
อนุมัติใบสั่งซื้อแล้ว
|
เหตุการณ์สำคัญนี้หมายถึงใบสั่งซื้อผ่านเวิร์กโฟลว์การอนุมัติภายในครบถ้วน และได้รับอนุญาตให้ส่งให้ผู้ขาย โดยทั่วไปเป็นขั้นตอนอนุมัติสุดท้ายในกระบวนการที่มีหลายขั้นตอน. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้สำคัญต่อการคำนวณระยะเวลาการอนุมัติใบสั่งซื้อและระบุคอขวดในการอนุมัติ อีกทั้งยังเป็นจุดตรวจสอบสำคัญด้านการปฏิบัติตามข้อกำหนด.
แหล่งข้อมูล
ดึงจากบันทึกประวัติการอนุมัติของ Purchase Order ใน Coupa โดยใช้เวลาที่อนุมัติขั้นสุดท้ายเป็นเวลาเกิดเหตุการณ์.
บันทึก
บันทึกในประวัติการอนุมัติเมื่อผู้อนุมัติขั้นสุดท้ายทำงานเสร็จ.
ประเภทเหตุการณ์
explicit
|
|||
|
แก้ไขใบสั่งซื้อ
|
เหตุการณ์นี้หมายถึงการแก้ไขใบสั่งซื้อหลังจากจัดทำร่างครั้งแรก ใน Coupa มักติดตามการแก้ไขผ่านการกำหนดเวอร์ชันของเอกสารใบสั่งซื้อ. | ||
|
เหตุผลที่สำคัญ
การติดตามการแก้ไขมีความสำคัญต่อ KPI เช่น อัตราการแก้ไขใบสั่งซื้อและอัตราใบสั่งซื้อที่ไม่เป็นไปตามข้อกำหนด หากมีการแก้ไขบ่อย อาจแสดงว่ากระบวนการไม่เสถียรหรือคำขอซื้อครั้งแรกไม่ถูกต้อง.
แหล่งข้อมูล
อนุมานได้จากการติดตามเวอร์ชันต่าง ๆ ของ Purchase Order หากหมายเลขเวอร์ชันใหม่มากกว่าเวอร์ชันแรก แสดงว่ามีการแก้ไข โดยใช้วันที่สร้างเวอร์ชันใหม่เป็นเวลาเกิดเหตุการณ์.
บันทึก
อนุมานจากเวลาที่สร้างเวอร์ชันใหม่ของใบสั่งซื้อ.
ประเภทเหตุการณ์
inferred
|
|||
|
คืนสินค้าให้ผู้ขาย
|
บันทึกกิจกรรมนี้เมื่อส่งสินค้าที่รับไว้ก่อนหน้านี้คืนให้ผู้ขาย โดยทั่วไปเกิดจากปัญหาคุณภาพ สินค้าเสียหาย หรือส่งสินค้าผิด. | ||
|
เหตุผลที่สำคัญ
การติดตามการคืนสินค้าจำเป็นต่อการคำนวณอัตราการคืนสินค้าและค้นหาปัญหาด้านคุณภาพของซัพพลายเออร์หรือความถูกต้องของคำสั่งซื้อ หากมีการคืนสินค้าสูง มักแสดงว่ากระบวนการมีข้อผิดพลาดที่ทำให้เกิดค่าใช้จ่าย.
แหล่งข้อมูล
ดึงข้อมูลจากธุรกรรม 'Return to Supplier' หรือธุรกรรมรับสินค้าติดลบใน Coupa โดยใช้เวลาของธุรกรรมเป็นเวลาเกิดเหตุการณ์.
บันทึก
บันทึกเมื่อสร้างธุรกรรมคืนสินค้าที่เชื่อมโยงกับ PO หรือใบรับสินค้าต้นทาง.
ประเภทเหตุการณ์
explicit
|
|||
|
จัดทำร่างใบสั่งซื้อ
|
เหตุการณ์นี้หมายถึงการสร้างเอกสารใบสั่งซื้อครั้งแรกในระบบ ซึ่งมักสร้างจากคำขอซื้อที่ได้รับอนุมัติ ในขั้นตอนนี้ ใบสั่งซื้อยังเป็นร่างภายใน ยังไม่ได้ส่งเพื่ออนุมัติหรือส่งให้ผู้ขาย. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดเริ่มต้นในการวัด KPI ระยะเวลาการอนุมัติใบสั่งซื้อ และเป็นขั้นตอนอย่างเป็นทางการขั้นแรกในวงจรของใบสั่งซื้อ.
แหล่งข้อมูล
ตรงกับเวลาที่สร้างรายการใบสั่งซื้อใน Coupa ซึ่งมักอยู่ในฟิลด์อย่าง 'created_at'.
บันทึก
ดึงจากเวลาที่ระบบบันทึกเมื่อสร้างรายการใบสั่งซื้อ.
ประเภทเหตุการณ์
explicit
|
|||
|
ได้รับใบแจ้งหนี้สำหรับ PO
|
เหตุการณ์นี้บันทึกการรับและลงรายการใบแจ้งหนี้จากซัพพลายเออร์ที่อ้างอิงถึงใบสั่งซื้อ และเป็นจุดเริ่มต้นของขั้นตอนประมวลผลใบแจ้งหนี้และชำระเงินในรอบ P2P. | ||
|
เหตุผลที่สำคัญ
แม้จะเป็นส่วนหนึ่งของกระบวนการ AP แต่การเชื่อมโยงการรับใบแจ้งหนี้กับใบสั่งซื้อช่วยให้เห็นวงจรธุรกรรมตั้งแต่ต้นจนจบ และวิเคราะห์ช่วงเวลาระหว่างการส่งมอบกับการออกใบแจ้งหนี้ได้.
แหล่งข้อมูล
ดึงจากเวลาที่สร้างเอกสาร Invoice ใน Coupa ซึ่งใบแจ้งหนี้จะจับคู่กับหมายเลข Purchase Order ที่เกี่ยวข้อง.
บันทึก
บันทึกเมื่อสร้างรายการใบแจ้งหนี้ที่เชื่อมโยงกับใบสั่งซื้อ.
ประเภทเหตุการณ์
explicit
|
|||
|
ตรวจสอบคุณภาพสินค้าแล้ว
|
เหตุการณ์นี้หมายถึงสินค้าที่ได้รับผ่านการตรวจสอบคุณภาพแล้ว ขั้นตอนนี้อาจแยกจากการบันทึกรับสินค้าครั้งแรก ทั้งนี้ขึ้นอยู่กับกระบวนการของบริษัท. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้สำคัญต่อการวัดประสิทธิภาพของกระบวนการควบคุมคุณภาพ หากล่าช้า อาจเกิดคอขวดระหว่างการรับสินค้ากับการนำสินค้าไปใช้งาน.
แหล่งข้อมูล
อาจบันทึกเป็นการเปลี่ยนสถานะของรายการสินค้าในใบรับสินค้า หรือบันทึกผ่านออบเจ็กต์ตรวจสอบแยกต่างหากใน Coupa ข้อมูลนี้จะมีหรือไม่ขึ้นอยู่กับว่ามีการใช้โมดูลคุณภาพหรือเวิร์กโฟลว์ที่ปรับแต่งเองหรือไม่.
บันทึก
อนุมานจากการเปลี่ยนสถานะของใบรับสินค้า หรือเวลาที่บันทึกไว้ในรายการตรวจสอบที่เกี่ยวข้อง.
ประเภทเหตุการณ์
inferred
|
|||
|
บันทึกการยืนยันรับบริการ
|
สำหรับใบสั่งซื้อบริการ กิจกรรมนี้เทียบเท่ากับการรับสินค้า โดยยืนยันว่าให้บริการตามเงื่อนไขในใบสั่งซื้อแล้ว. | ||
|
เหตุผลที่สำคัญ
การติดตามการยืนยันรับบริการมีความสำคัญต่อการบริหารค่าใช้จ่ายด้านบริการ และช่วยให้มั่นใจว่าจะจ่ายเงินเฉพาะงานที่ตรวจสอบแล้วว่าเสร็จสมบูรณ์.
แหล่งข้อมูล
บันทึกเหตุการณ์นี้เมื่อสร้างหรืออนุมัติใบรับบริการหรือใบบันทึกงานบริการที่เชื่อมโยงกับ Purchase Order ใน Coupa.
บันทึก
บันทึกเมื่อสร้างและอนุมัติใบบันทึกงานบริการ.
ประเภทเหตุการณ์
explicit
|
|||
|
ปฏิเสธใบสั่งซื้อ
|
กิจกรรมนี้เกิดขึ้นเมื่อผู้อนุมัติปฏิเสธใบสั่งซื้อระหว่างเวิร์กโฟลว์การอนุมัติ โดยทั่วไปใบสั่งซื้อจะถูกส่งกลับไปยังผู้สร้างเพื่อแก้ไขหรือยกเลิก. | ||
|
เหตุผลที่สำคัญ
การวิเคราะห์รายการที่ถูกปฏิเสธช่วยค้นหาปัญหาด้านคุณภาพข้อมูล การละเมิดนโยบาย หรือช่องว่างในการฝึกอบรม อีกทั้งยังแสดงวงจรการแก้ไขงานที่ทำให้กระบวนการล่าช้าอย่างมาก.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกไว้อย่างชัดเจนในประวัติการอนุมัติของ Purchase Order ใน Coupa โดยบันทึกจะแสดงการดำเนินการ 'Reject' พร้อมเวลาที่เกี่ยวข้อง.
บันทึก
บันทึกในประวัติการอนุมัติด้วยสถานะ 'Reject'.
ประเภทเหตุการณ์
explicit
|
|||
|
ผู้ขายยืนยันคำสั่งซื้อ
|
เหตุการณ์นี้หมายถึงผู้ขายได้รับและยืนยันใบสั่งซื้อแล้ว โดยมักบันทึกการยืนยันทางอิเล็กทรอนิกส์ผ่านพอร์ทัลซัพพลายเออร์ เช่น Coupa Supplier Portal (CSP). | ||
|
เหตุผลที่สำคัญ
การยืนยันจากผู้ขายช่วยให้มั่นใจว่ากำลังดำเนินการตามคำสั่งซื้อ ทำให้คาดการณ์การส่งมอบได้แม่นยำขึ้นและลดความไม่แน่นอนในห่วงโซ่อุปทาน.
แหล่งข้อมูล
โดยทั่วไปข้อมูลนี้จะอยู่ใน Purchase Order หากผู้ขายใช้ Coupa Supplier Portal เพื่อดำเนินการ 'Acknowledge' โดยใช้เวลาที่ดำเนินการดังกล่าว.
บันทึก
บันทึกเมื่อผู้ขายดำเนินการ 'Acknowledge' ในพอร์ทัลซัพพลายเออร์.
ประเภทเหตุการณ์
explicit
|
|||
|
เริ่มรับสินค้า
|
กิจกรรมนี้หมายถึงการเริ่มกระบวนการรับสินค้า เช่น เมื่อสร้างเอกสารรับสินค้าใน Coupa หลังสินค้ามาถึงจริง แต่ยังไม่ได้บันทึกรับเข้าคลังอย่างเป็นทางการหรือยืนยันว่าได้รับสินค้าแล้ว. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้เป็นจุดเริ่มต้นในการวัด KPI ระยะเวลาประมวลผลการรับสินค้า และช่วยแยกเวลาที่สินค้ารออยู่ที่จุดรับออกจากเวลาที่ใช้ประมวลผลในระบบ.
แหล่งข้อมูล
อนุมานได้จากเวลาที่สร้างเอกสารรับสินค้าซึ่งมีสถานะ 'Draft' หรือ 'Pending' เหตุการณ์นี้เกิดก่อนบันทึกรับสินค้าเป็นขั้นสุดท้าย.
บันทึก
อนุมานจากเวลาที่สร้างรายการรับสินค้าในสถานะที่ยังไม่ได้บันทึกเข้าระบบ.
ประเภทเหตุการณ์
inferred
|
|||
|
ส่งใบสั่งซื้อเพื่ออนุมัติ
|
หลังจัดทำร่างใบสั่งซื้อแล้ว จะส่งเข้าสู่เวิร์กโฟลว์การอนุมัติอย่างเป็นทางการ การดำเนินการนี้เป็นการกระทำของผู้ใช้ที่แยกต่างหาก ซึ่งเปลี่ยนสถานะใบสั่งซื้อจากร่างเป็นรออนุมัติ. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้ช่วยแยกเวลาจัดทำร่างออกจากเวลาที่ใบสั่งซื้อเริ่มรออนุมัติจริง ทำให้เห็นพฤติกรรมของผู้ใช้และการส่งต่องานได้ชัดเจนขึ้น.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนสถานะของออบเจ็กต์ Purchase Order เช่น จาก 'draft' เป็น 'pending approval' โดยใช้เวลาที่สถานะเปลี่ยน.
บันทึก
อนุมานจากเวลาที่สถานะเปลี่ยนเป็น 'pending approval'.
ประเภทเหตุการณ์
inferred
|
|||
|
อนุมัติคำขอซื้อแล้ว
|
คำขอซื้อต้องผ่านเวิร์กโฟลว์การอนุมัติก่อนแปลงเป็นใบสั่งซื้อ เหตุการณ์นี้หมายถึงคำขอซื้อได้รับอนุมัติขั้นสุดท้ายและพร้อมสำหรับการสั่งซื้อ. | ||
|
เหตุผลที่สำคัญ
การติดตามการอนุมัติคำขอซื้อช่วยระบุคอขวดในขั้นตอนก่อนสั่งซื้อ หากล่าช้า ก็จะส่งผลโดยตรงต่อความเร็วในการออกใบสั่งซื้อ.
แหล่งข้อมูล
โดยทั่วไปจะดึงข้อมูลจากประวัติการอนุมัติของออบเจ็กต์คำขอซื้อใน Coupa การอนุมัติขั้นสุดท้ายจะมีเวลาและชื่อผู้ใช้ที่เกี่ยวข้อง.
บันทึก
บันทึกในประวัติการอนุมัติเมื่อผู้อนุมัติขั้นสุดท้ายดำเนินการ.
ประเภทเหตุการณ์
explicit
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เตรียมข้อมูลสำหรับ process mining และค้นหาข้อมูลเชิงลึกที่นำไปใช้ปรับปรุงได้ เริ่มปรับปรุงกระบวนการจัดซื้อจนถึงการชำระเงินสำหรับใบสั่งซื้อของคุณได้เลย.
ปรับปรุงใบสั่งซื้อ P2P เพิ่มประสิทธิภาพได้ตั้งแต่วันนี้
ลดระยะเวลารอบการทำงาน P2P ลง 30% และเริ่มเห็นผลได้เร็ว.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายในไม่กี่นาที.