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

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

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

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

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

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

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

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

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

แหล่งข้อมูล

นี่คือธุรกรรมหลักใน 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
แนะนำ ไม่บังคับ

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

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

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

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

ปรับปรุงใบสั่งซื้อ P2P เพิ่มประสิทธิภาพได้ตั้งแต่วันนี้

ลดระยะเวลารอบการทำงาน P2P ลง 30% และเริ่มเห็นผลได้เร็ว.

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

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