เทมเพลตข้อมูล Purchase to Pay - Purchase Order
เทมเพลตข้อมูล Purchase to Pay - Purchase Order
- แอตทริบิวต์ที่แนะนำสำหรับการรวบรวมข้อมูลเพื่อการวิเคราะห์
- กิจกรรมหลักของกระบวนการที่ควรติดตามและวิเคราะห์
- ขั้นตอนการดึงข้อมูลจาก Oracle Fusion Financials
แอตทริบิวต์ของ Purchase to Pay - Purchase Order
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
ActivityName
|
ชื่อของเหตุการณ์หรือขั้นตอนทางธุรกิจที่เกิดขึ้นในวงจรการทำงานของใบสั่งซื้อ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุงานหรือการเปลี่ยนสถานะในกระบวนการ เช่น 'สร้างใบสั่งซื้อ' หรือ 'รับสินค้าแล้ว' กิจกรรมเหล่านี้เรียงต่อกันเป็นลำดับเหตุการณ์ของกระบวนการ. การวิเคราะห์ลำดับและช่วงเวลาของกิจกรรมเป็นหัวใจของ process mining ช่วยให้เห็นแผนผังกระบวนการ ระบุคอขวด ค้นหาความเบี่ยงเบนจากขั้นตอนมาตรฐาน และวัดระยะเวลาของแต่ละขั้นตอนได้.
เหตุผลที่สำคัญ
กิจกรรมเป็นองค์ประกอบพื้นฐานของแผนผังกระบวนการ การติดตามกิจกรรมช่วยให้เห็นและวิเคราะห์ลำดับงาน คอขวด และความเบี่ยงเบนได้.
แหล่งข้อมูล
ได้จากการเปลี่ยนสถานะในตาราง เช่น PO_HEADERS_ALL และ PO_ACTION_HISTORY หรือจากตารางธุรกรรมเฉพาะ เช่น RCV_TRANSACTIONS สำหรับการรับสินค้า.
ตัวอย่าง
สร้างใบสั่งซื้ออนุมัติใบสั่งซื้อรับสินค้าแล้ว
|
|||
|
ใบสั่งซื้อ
PurchaseOrder
|
รหัสเฉพาะของเอกสารใบสั่งซื้อ ใช้เป็น Case ID หลักสำหรับติดตามวงจรการจัดซื้อ. | ||
|
คำอธิบาย
หมายเลขใบสั่งซื้อเป็นรหัสหลักที่เชื่อมโยงกิจกรรมทั้งหมด ตั้งแต่การสร้างจนถึงการปิดขั้นสุดท้าย จึงใช้วิเคราะห์กรณีจัดซื้อแต่ละรายการได้ตั้งแต่ต้นจนจบ. ใน process mining หมายเลขใบสั่งซื้อแต่ละหมายเลขที่ไม่ซ้ำกันจะแทนกระบวนการหนึ่งกรณี การวิเคราะห์ข้อมูลโดยจัดกลุ่มตามรหัสนี้ช่วยให้เข้าใจความแตกต่างของกระบวนการ ระยะเวลาดำเนินการ และการปฏิบัติตามข้อกำหนดของใบสั่งซื้อแต่ละรายการ.
เหตุผลที่สำคัญ
นี่คือ Case ID หลักที่เชื่อมโยงเหตุการณ์ที่เกี่ยวข้องทั้งหมด ทำให้สร้างภาพและวิเคราะห์วงจรการทำงานของใบสั่งซื้อได้ครบถ้วน.
แหล่งข้อมูล
Oracle Fusion Cloud SCM, โมดูล Procurement, ตาราง PO_HEADERS_ALL, คอลัมน์ SEGMENT1.
ตัวอย่าง
100234510023461002347
|
|||
|
เวลาเริ่มต้น
EventTime
|
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เกิดขึ้นเมื่อใด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกวันที่และเวลาที่แน่นอนของแต่ละกิจกรรมในกระบวนการ ซึ่งจำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลาและการวิเคราะห์ตามช่วงเวลา. ใน process mining เวลาเริ่มต้นใช้สร้างบันทึกเหตุการณ์ คำนวณระยะเวลาระหว่างกิจกรรม วัดเวลารอ และวิเคราะห์ประสิทธิภาพกระบวนการในช่วงเวลาต่างๆ ข้อมูลนี้จำเป็นต่อแดชบอร์ดที่เกี่ยวกับระยะเวลาและประสิทธิภาพ.
เหตุผลที่สำคัญ
เวลานี้จำเป็นต่อการเรียงเหตุการณ์ให้ถูกต้องและคำนวณตัวชี้วัดตามระยะเวลาทั้งหมด เช่น ระยะเวลาดำเนินการและคอขวด.
แหล่งข้อมูล
ฟิลด์เวลา เช่น CREATION_DATE และ LAST_UPDATE_DATE จากตารางต่างๆ รวมถึง PO_HEADERS_ALL, PO_ACTION_HISTORY และ RCV_SHIPMENT_LINES.
ตัวอย่าง
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
|
|||
|
ชื่อผู้ขาย
VendorName
|
ชื่อผู้ขายหรือซัพพลายเออร์ที่จัดหาสินค้าหรือบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุผู้ขายภายนอกของใบสั่งซื้อ โดยเป็นข้อมูลหลักสำคัญที่เชื่อมโยงกับส่วนหัวของ PO. การวิเคราะห์ผู้ขายเป็นส่วนสำคัญของ process mining สำหรับกระบวนการ P2P การกรองหรือแบ่งกลุ่มตามผู้ขายช่วยให้บริษัทวิเคราะห์ประสิทธิภาพการส่งมอบ เปรียบเทียบอัตราการส่งมอบตรงเวลา และตรวจสอบอัตราการคืนสินค้า เพื่อค้นหาผู้ขายที่มีผลการดำเนินงานดีหรือควรปรับปรุง ข้อมูลนี้จำเป็นต่อการบริหารความสัมพันธ์กับผู้ขายและการจัดหาเชิงกลยุทธ์.
เหตุผลที่สำคัญ
จำเป็นต่อการวิเคราะห์ประสิทธิภาพผู้ขาย ช่วยเปรียบเทียบเวลาส่งมอบ อัตราการคืนสินค้า และความน่าเชื่อถือโดยรวมของผู้ขายแต่ละราย.
แหล่งข้อมูล
เชื่อมจาก PO_HEADERS_ALL.VENDOR_ID ไปยัง POZ_SUPPLIERS.VENDOR_NAME.
ตัวอย่าง
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
|
|||
|
ชื่อผู้อนุมัติ
ApproverName
|
ชื่อผู้ใช้ที่อนุมัติหรือปฏิเสธใบสั่งซื้อ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุผู้รับผิดชอบขั้นตอนอนุมัติในเวิร์กโฟลว์ โดยทั่วไปข้อมูลจะอยู่ในตารางประวัติการดำเนินการหรือบันทึกเวิร์กโฟลว์ที่เชื่อมโยงกับใบสั่งซื้อ. การวิเคราะห์ข้อมูลแยกตามผู้อนุมัติจำเป็นต่อแดชบอร์ด 'วิเคราะห์ระยะเวลาการอนุมัติ PO' และ 'ภาระงานของผู้อนุมัติ' ช่วยระบุผู้อนุมัติหรือกลุ่มผู้อนุมัติที่เป็นคอขวด ประเมินภาระงานอย่างเป็นธรรม และค้นหาโอกาสในการมอบหมายงานหรือปรับรูปแบบกระบวนการ.
เหตุผลที่สำคัญ
ระบุผู้รับผิดชอบในสายการอนุมัติ ทำให้วิเคราะห์คอขวด ภาระงาน และระยะเวลาดำเนินการตามผู้อนุมัติได้.
แหล่งข้อมูล
ผู้ใช้ที่ดำเนินการ ซึ่งระบุใน PO_ACTION_HISTORY.ACTION_PERFORMED_BY และเชื่อมกับตารางผู้ใช้เพื่อดึงชื่อเต็ม.
ตัวอย่าง
susan.managerdavid.directoremily.finance
|
|||
|
ผู้ใช้
UserName
|
รหัสหรือชื่อผู้ใช้ของผู้ที่ดำเนินกิจกรรม. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุพนักงานหรือผู้ใช้ระบบที่รับผิดชอบเหตุการณ์ เช่น สร้างใบขอซื้อ อนุมัติ PO หรือบันทึกรับสินค้า โดยทั่วไปดึงข้อมูลจากฟิลด์อย่าง 'Created By' หรือ 'Last Updated By'. การวิเคราะห์กระบวนการตามผู้ใช้ช่วยให้เข้าใจการกระจายภาระงานและประสิทธิภาพรายบุคคล รวมถึงค้นหาความต้องการในการฝึกอบรม ข้อมูลนี้เป็นพื้นฐานของแดชบอร์ด 'ภาระงานของผู้อนุมัติ' และใช้ตรวจสอบปัญหาการปฏิบัติตามข้อกำหนดที่เกี่ยวข้องกับการดำเนินการของผู้ใช้ได้.
เหตุผลที่สำคัญ
ระบุผู้ดำเนินการแต่ละรายการ ช่วยวิเคราะห์ภาระงาน ประเมินประสิทธิภาพ และค้นหาโอกาสในการฝึกอบรม.
แหล่งข้อมูล
เชื่อมกับตารางผู้ใช้โดยใช้รหัสในฟิลด์ เช่น CREATED_BY หรือ LAST_UPDATED_BY ในตารางอย่าง PO_HEADERS_ALL และ PO_ACTION_HISTORY.
ตัวอย่าง
john.doejane.smithsystem.batch
|
|||
|
แผนก
DepartmentName
|
ชื่อแผนกที่เริ่มดำเนินการหรือรับผิดชอบใบสั่งซื้อ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุหน่วยงาน เช่น 'การเงิน', 'ไอที' หรือ 'การผลิต' ที่เกี่ยวข้องกับการจัดซื้อ ใช้สำหรับจัดสรรค่าใช้จ่ายและจัดทำรายงานตามหน่วยงาน. ใน process mining การแบ่งกระบวนการตามแผนกจำเป็นต่อการเปรียบเทียบประสิทธิภาพ ระบุคอขวดเฉพาะแผนก และทำความเข้าใจความแตกต่างของการดำเนินงานในแต่ละหน่วยงาน อีกทั้งยังรองรับแดชบอร์ด เช่น 'วิเคราะห์ระยะเวลาการอนุมัติ PO' และ 'แนวโน้มการแก้ไขใบสั่งซื้อ'.
เหตุผลที่สำคัญ
ช่วยกรองและเปรียบเทียบประสิทธิภาพกระบวนการระหว่างหน่วยธุรกิจ เพื่อให้เห็นปัญหาหรือแนวปฏิบัติที่ดีเฉพาะแผนก.
แหล่งข้อมูล
ได้จากข้อมูลศูนย์ต้นทุนในตาราง เช่น PO_DISTRIBUTIONS_ALL ซึ่งเชื่อมโยงกับข้อมูลหลักของแผนก.
ตัวอย่าง
ฝ่ายปฏิบัติการไอทีการตลาดวิจัยและพัฒนา
|
|||
|
ยอดรวม PO
PurchaseOrderTotalAmount
|
มูลค่าเงินรวมของใบสั่งซื้อ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงต้นทุนรวมของสินค้าทั้งหมดในใบสั่งซื้อ ตามสกุลเงินที่ระบุ เป็นตัวชี้วัดทางการเงินสำคัญที่ช่วยให้เข้าใจมูลค่าธุรกรรมที่ผ่านกระบวนการ. การวิเคราะห์ยอดรวม PO ช่วยจัดลำดับความสำคัญของการปรับปรุงกระบวนการ เช่น อาจกำหนดให้ใบสั่งซื้อมูลค่าสูงผ่านขั้นตอนอนุมัติที่เข้มงวดขึ้น และใช้ประเมินผลกระทบทางการเงิน เช่น มูลค่าของ PO ที่มีการแก้ไขหรือล่าช้าบ่อยครั้ง.
เหตุผลที่สำคัญ
ช่วยให้เห็นบริบททางการเงินของกระบวนการ และวิเคราะห์ตามมูลค่าเงินได้ เช่น มุ่งดูใบสั่งซื้อมูลค่าสูง หรือประเมินผลกระทบทางการเงินจากความล่าช้า.
แหล่งข้อมูล
คำนวณโดยรวมยอดจาก PO_LINES_ALL สำหรับส่วนหัว PO แต่ละรายการ หรือใช้ยอดรวมระดับส่วนหัวหากมีข้อมูล.
ตัวอย่าง
5250.00120000.50750.99
|
|||
|
วันที่ต้องการรับสินค้า
RequestedDeliveryDate
|
วันที่ผู้ขอคาดว่าจะได้รับสินค้าหรือบริการ. | ||
|
คำอธิบาย
ระบุวันที่ต้องการไว้ในรายการใบสั่งซื้อ เพื่อแจ้งกำหนดส่งมอบที่ต้องการให้ผู้ขายทราบ และใช้เป็นเกณฑ์ตั้งต้นในการวัดประสิทธิภาพการส่งมอบตรงเวลา. แอตทริบิวต์นี้จำเป็นต่อการคำนวณ KPI 'อัตราการส่งมอบตรงเวลา' โดยเปรียบเทียบวันที่รับสินค้าจริงกับวันที่ต้องการรับสินค้า องค์กรจึงวัดและติดตามความน่าเชื่อถือของผู้ขายได้อย่างเป็นรูปธรรม พร้อมระบุความล่าช้าที่เกิดซ้ำในห่วงโซ่อุปทาน.
เหตุผลที่สำคัญ
ใช้เป็นเกณฑ์ตั้งต้นในการวัดประสิทธิภาพการส่งมอบตรงเวลา ซึ่งเป็น KPI สำคัญสำหรับประเมินความน่าเชื่อถือของผู้ขายและประสิทธิภาพห่วงโซ่อุปทาน.
แหล่งข้อมูล
อยู่ที่ระดับสถานที่จัดส่งของรายการ ในตาราง PO_LINE_LOCATIONS_ALL คอลัมน์ NEED_BY_DATE.
ตัวอย่าง
2023-05-202023-06-152023-07-01
|
|||
|
เวลาสิ้นสุด
EndTime
|
เวลาที่กิจกรรมเสร็จสิ้น สำหรับเหตุการณ์ที่เกิดขึ้นทันที มักตรงกับเวลาเริ่มต้น. | ||
|
คำอธิบาย
สำหรับกิจกรรมที่ใช้เวลา ค่านี้ระบุเวลาที่กิจกรรมเสร็จสิ้น ส่วนเหตุการณ์ที่เกิดขึ้นทันที โดยทั่วไปจะมีเวลาเดียวกับเวลาเริ่มต้น ข้อมูลนี้จำเป็นต่อการคำนวณเวลาที่ใช้ดำเนินกิจกรรมแต่ละรายการ. การระบุเวลาสิ้นสุดแยกต่างหากช่วยให้วิเคราะห์ระยะเวลาของกิจกรรมได้แม่นยำขึ้น ซึ่งอาจต่างจากเวลารอระหว่างกิจกรรม และช่วยแยกเวลาทำงานจริงออกจากเวลาว่าง เพื่อวิเคราะห์ภาระงานและประสิทธิภาพของทรัพยากร.
เหตุผลที่สำคัญ
ช่วยคำนวณเวลาที่ใช้ดำเนินกิจกรรมแต่ละรายการได้อย่างแม่นยำ ซึ่งจำเป็นต่อการวิเคราะห์ประสิทธิภาพของทรัพยากรและระบุงานที่ใช้เวลานาน.
แหล่งข้อมูล
สำหรับเหตุการณ์ที่เกิดขึ้นทันที อาจใช้เวลาเดียวกับเวลาเริ่มต้น หรือคำนวณจากเวลาของเหตุการณ์ถัดไป บางกิจกรรมอาจมีเวลาที่เสร็จสิ้นแยกต่างหาก.
ตัวอย่าง
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
|
|||
|
การอนุมัติเป็นไปตามข้อกำหนดหรือไม่
IsApprovalCompliant
|
ระบุว่า PO ได้รับอนุมัติก่อนส่งให้ผู้ขายหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์บูลีนที่คำนวณขึ้นนี้ใช้ตรวจสอบการปฏิบัติตามการควบคุมภายในที่สำคัญ ซึ่งกำหนดให้อนุมัติ Purchase Order ก่อนส่งให้ผู้ขาย ค่าจะเป็น true เมื่อ activity 'Purchase Order Approved' เกิดขึ้นก่อน activity 'Purchase Order Sent to Vendor' แอตทริบิวต์นี้จำเป็นสำหรับแดชบอร์ด 'PO Process Compliance Audit' และ KPI 'PO Approval Compliance Rate' ช่วยระบุและวัดการละเมิดข้อกำหนดได้อย่างตรงไปตรงมา เพื่อให้บังคับใช้นโยบายการจัดซื้อและลดความเสี่ยงจากการใช้จ่ายที่ไม่ได้รับอนุญาต.
เหตุผลที่สำคัญ
ใช้วัด KPI 'PO Approval Compliance Rate' โดยตรง และชี้ให้เห็นการละเมิดการควบคุมภายในที่สำคัญ เช่น การส่งคำสั่งซื้อให้ผู้ขายก่อนอนุมัติ.
แหล่งข้อมูล
ฟิลด์ที่คำนวณขึ้น กำหนดเป็น 'true' หากเวลาของ 'Purchase Order Approved' น้อยกว่าหรือเท่ากับเวลาของ 'Purchase Order Sent to Vendor'.
ตัวอย่าง
truefalse
|
|||
|
ใบขอซื้อ
PurchaseRequisitionNumber
|
รหัสใบขอซื้อที่จัดทำก่อนและใช้อนุมัติใบสั่งซื้อ. | ||
|
คำอธิบาย
ใบขอซื้อเป็นเอกสารภายในที่ใช้ขอจัดซื้อสินค้าหรือบริการ แอตทริบิวต์นี้เชื่อมใบสั่งซื้อกลับไปยังคำขอเริ่มต้น. การใส่หมายเลขใบขอซื้อช่วยให้วิเคราะห์กระบวนการจัดซื้อได้กว้างขึ้น โดยเริ่มตั้งแต่คำขอแรก ไม่ใช่เฉพาะ PO ช่วยวิเคราะห์ระยะเวลาตั้งแต่ขอซื้อจนถึงออกใบสั่งซื้อ และทำความเข้าใจว่ารายละเอียดในใบขอซื้อส่งผลต่อขั้นตอน PO อย่างไร.
เหตุผลที่สำคัญ
เชื่อม PO กับคำขอเริ่มต้น ทำให้เห็นกระบวนการตั้งแต่ขอซื้อจนถึงชำระเงินได้ครบถ้วนยิ่งขึ้น.
แหล่งข้อมูล
เชื่อมผ่านตาราง PO_DISTRIBUTIONS_ALL ซึ่งมี REQ_DISTRIBUTION_ID สำหรับย้อนกลับไปยังตาราง POR_REQUISITION_LINES_ALL.
ตัวอย่าง
PR-2023-05-001PR-2023-05-002PR-2023-05-003
|
|||
|
ประเภท PO
PurchaseOrderType
|
ประเภทของใบสั่งซื้อ เช่น 'มาตรฐาน', 'ข้อตกลงซื้อระยะยาว' หรือ 'สัญญา'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้จัดประเภทใบสั่งซื้อตามวัตถุประสงค์การจัดซื้อ PO แต่ละประเภทมักใช้กฎและวงจรการทำงานต่างกัน. PO 'มาตรฐาน' ใช้สำหรับการซื้อครั้งเดียว ส่วน PO แบบ 'ข้อตกลงซื้อระยะยาว' ใช้ทำข้อตกลงกับผู้ขายในระยะยาว การวิเคราะห์ตามประเภท PO ช่วยให้เห็นประสิทธิภาพกระบวนการได้แม่นยำขึ้น เพราะการนำระยะเวลาดำเนินการของ PO มาตรฐานไปเทียบกับข้อตกลงซื้อระยะยาวอาจทำให้เข้าใจผิด การเปรียบเทียบจึงควรทำระหว่างใบสั่งซื้อประเภทเดียวกัน.
เหตุผลที่สำคัญ
แยกสถานการณ์การจัดซื้อแต่ละแบบ ช่วยให้เปรียบเทียบประสิทธิภาพของใบสั่งซื้อประเภทเดียวกันได้อย่างเหมาะสมและแม่นยำขึ้น.
แหล่งข้อมูล
Oracle Fusion Cloud SCM, ตาราง PO_HEADERS_ALL, คอลัมน์ TYPE_LOOKUP_CODE.
ตัวอย่าง
มาตรฐานข้อตกลงซื้อระยะยาวสัญญา
|
|||
|
มีการแก้ไขงานหรือไม่
IsRework
|
ระบุว่า Purchase Order มีการแก้ไขหลังจากสร้างครั้งแรกหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์บูลีนที่คำนวณขึ้นนี้จะเป็น true เมื่อเคส Purchase Order มี activity 'Purchase Order Changed' ช่วยให้ระบุคำสั่งซื้อที่ต้องแก้ไขหรือปรับเปลี่ยนได้อย่างรวดเร็ว แฟล็กนี้ช่วยให้คำนวณ KPI 'PO Modification Rate' ได้ง่ายขึ้น และกรองหรือวิเคราะห์คำสั่งซื้อที่มีการแก้ไขได้สะดวก การทำความเข้าใจลักษณะของคำสั่งซื้อเหล่านี้ เช่น ผู้ขายหรือแผนกที่เกี่ยวข้อง อาจช่วยหาสาเหตุของข้อมูลที่ไม่ถูกต้องหรือข้อกำหนดที่เปลี่ยนแปลงได้.
เหตุผลที่สำคัญ
รองรับ KPI 'PO Modification Rate' โดยตรง และช่วยวิเคราะห์ความไม่เสถียรของกระบวนการ โดยระบุคำสั่งซื้อทั้งหมดที่มีการเปลี่ยนแปลง.
แหล่งข้อมูล
ฟิลด์ที่คำนวณขึ้น กำหนดเป็น 'true' หากบันทึกเหตุการณ์ของเคสมี activity 'Purchase Order Changed' มิฉะนั้นกำหนดเป็น 'false'.
ตัวอย่าง
truefalse
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบสารสนเทศที่ใช้ดึงข้อมูลนี้ออกมา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูล ซึ่งมีประโยชน์เป็นพิเศษเมื่อมีหลายระบบเชื่อมต่อกัน สำหรับกระบวนการนี้ โดยทั่วไปจะเป็น 'Oracle Fusion Financials'. แม้ค่านี้มักไม่เปลี่ยนแปลงในชุดข้อมูลเดียวกัน แต่ก็สำคัญต่อการกำกับดูแลข้อมูล การแก้ไขปัญหา และการตรวจสอบที่มาของข้อมูล หากการวิเคราะห์รวมข้อมูลจากหลายแหล่ง ก็สามารถกรองและแบ่งกลุ่มตามระบบต้นทางได้.
เหตุผลที่สำคัญ
ระบุแหล่งที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลข้อมูล การทำความเข้าใจบริบท และการเชื่อมต่อกับระบบอื่น.
แหล่งข้อมูล
โดยทั่วไป ค่านี้เป็นค่าคงที่ที่กำหนดและเพิ่มระหว่างกระบวนการดึงและแปลงข้อมูล (ETL).
ตัวอย่าง
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
|
|||
|
ส่งมอบล่าช้าหรือไม่
IsLateDelivery
|
ระบุว่าการรับสินค้าครั้งสุดท้ายเกิดขึ้นหลังวันที่ต้องการให้ส่งมอบหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์บูลีนที่คำนวณขึ้นนี้จะเป็น true เมื่อเวลาของ activity 'Goods Received' อยู่หลังวันที่ในแอตทริบิวต์ 'Requested Delivery Date' ของ Purchase Order นั้น แฟล็กนี้เป็นข้อมูลพื้นฐานสำหรับ KPI 'On-Time Delivery Rate' และช่วยแบ่งกลุ่มและวิเคราะห์คำสั่งซื้อที่ส่งล่าช้าหรือส่งตรงเวลาได้ง่ายขึ้น คุณจึงตรวจสอบสาเหตุของความล่าช้าได้ว่าเกี่ยวข้องกับผู้ขาย สถานที่ หรือหมวดหมู่สินค้าใด.
เหตุผลที่สำคัญ
รองรับ KPI 'On-Time Delivery Rate' โดยตรง ช่วยให้วิเคราะห์ผลงานของผู้ขายและความน่าเชื่อถือในการส่งมอบได้ชัดเจน.
แหล่งข้อมูล
ฟิลด์ที่คำนวณขึ้น กำหนดเป็น 'true' หากเวลาของ activity 'Goods Received' อยู่หลังแอตทริบิวต์ 'RequestedDeliveryDate'.
ตัวอย่าง
truefalse
|
|||
|
สถานที่จัดส่ง
DeliveryLocation
|
สถานที่หรือที่อยู่จริงที่จะจัดส่งสินค้า. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุที่อยู่สำหรับจัดส่งสินค้าตามใบสั่งซื้อ เป็นข้อมูลสำคัญด้านโลจิสติกส์. สำหรับ process mining การวิเคราะห์ตามสถานที่จัดส่งช่วยให้แดชบอร์ด 'ประสิทธิภาพการรับสินค้า' แสดงได้ว่าคลังสินค้าหรือสถานที่ใดใช้เวลารับสินค้านานกว่าแห่งอื่น ซึ่งอาจชี้ถึงปัญหาด้านทรัพยากรหรือกระบวนการในพื้นที่นั้น.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ประสิทธิภาพตามพื้นที่ และระบุคอขวดในกระบวนการรับสินค้าที่เกิดเฉพาะภูมิภาคหรือสถานที่ได้.
แหล่งข้อมูล
เชื่อมจาก PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID ไปยังมุมมอง HR_LOCATIONS_ALL.
ตัวอย่าง
คลังสินค้าหลัก - ท่าเทียบสินค้า Aอาคาร 3 - จุดรับสินค้าสำนักงานซานฟรานซิสโก - ชั้น 10
|
|||
|
สถานะ PO
PurchaseOrderStatus
|
สถานะปัจจุบันของเอกสารใบสั่งซื้อ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงสถานะปัจจุบันของใบสั่งซื้อตามวงจรการทำงาน เช่น 'เปิด', 'อนุมัติแล้ว', 'ปิดขั้นสุดท้ายแล้ว' หรือ 'ยกเลิกแล้ว' จึงช่วยให้เห็นความคืบหน้าของ PO ณ เวลานั้น. แม้ process mining จะเน้นลำดับกิจกรรม แต่สถานะปัจจุบันก็มีประโยชน์ในการกรองกรณี ตัวอย่างเช่น เลือกดูเฉพาะ PO ที่ยังเปิดอยู่เพื่อทำความเข้าใจงานที่กำลังดำเนินการ หรือเลือก PO ที่ปิดแล้วเพื่อวิเคราะห์กรณีที่เสร็จสิ้น ข้อมูลนี้จำเป็นต่อแดชบอร์ด 'สถานะและลำดับงานของใบสั่งซื้อ'.
เหตุผลที่สำคัญ
แสดงสถานะปัจจุบันของใบสั่งซื้อ ช่วยกรองการวิเคราะห์ให้เหลือเฉพาะรายการที่กำลังดำเนินการ เสร็จสิ้น หรือยกเลิกแล้ว.
แหล่งข้อมูล
Oracle Fusion Cloud SCM, ตาราง PO_HEADERS_ALL, คอลัมน์ AUTHORIZATION_STATUS หรือ DOCUMENT_STATUS.
ตัวอย่าง
เปิดอนุมัติแล้วปิดขั้นสุดท้ายแล้วยกเลิกแล้ว
|
|||
|
หน่วยธุรกิจ
BusinessUnitName
|
หน่วยธุรกิจเฉพาะภายในองค์กรที่เป็นผู้จัดซื้อ. | ||
|
คำอธิบาย
หน่วยธุรกิจเป็นหน่วยงานแยกภายในองค์กร ซึ่งมักมีบัญชีแยกประเภทและรายงานทางการเงินของตนเอง ใน Oracle Fusion หน่วยธุรกิจเป็นกลไกหลักสำหรับแยกข้อมูล. การวิเคราะห์ประสิทธิภาพกระบวนการตามหน่วยธุรกิจสำคัญสำหรับองค์กรขนาดใหญ่และบริษัทข้ามชาติ ช่วยเปรียบเทียบประสิทธิภาพการจัดซื้อ การปฏิบัติตามข้อกำหนด และค่าใช้จ่ายในแต่ละส่วนขององค์กร พร้อมชี้ให้เห็นแนวปฏิบัติที่ดีและจุดที่ควรปรับปรุง.
เหตุผลที่สำคัญ
จำเป็นสำหรับองค์กรขนาดใหญ่ที่ต้องการเปรียบเทียบประสิทธิภาพและการปฏิบัติตามข้อกำหนดระหว่างหน่วยงานปฏิบัติการต่างๆ.
แหล่งข้อมูล
ข้อมูลหน่วยธุรกิจมักอยู่ในส่วนหัว PO ที่ PO_HEADERS_ALL.PRC_BU_ID ซึ่งเชื่อมไปยังมุมมอง FUN_ALL_BUSINESS_UNITS_V.
ตัวอย่าง
หน่วยธุรกิจสหรัฐฯวิสัยทัศน์ EMEAบริการ APAC
|
|||
|
หมวดหมู่การจัดซื้อ
PurchaseCategory
|
ประเภทของสินค้าหรือบริการที่จัดซื้อ เช่น 'อุปกรณ์ไอที' หรือ 'เครื่องใช้สำนักงาน'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้จัดหมวดหมู่สินค้าในใบสั่งซื้อตามลำดับชั้นการจัดซื้อ ใช้สำหรับวิเคราะห์ค่าใช้จ่ายและบริหารผู้ขาย. ใน process mining การแบ่งกระบวนการตามหมวดหมู่การจัดซื้อช่วยให้เห็นรูปแบบการทำงานหรือระดับประสิทธิภาพที่แตกต่างกัน เช่น ขั้นตอนอนุมัติรายจ่ายลงทุนอาจใช้เวลานานกว่าการจัดซื้อวัสดุสิ้นเปลืองสำหรับการปฏิบัติงาน อีกทั้งยังรองรับแดชบอร์ด 'อัตราและเหตุผลการคืนสินค้า' โดยช่วยวิเคราะห์ว่าสินค้าหมวดใดถูกส่งคืนบ่อยที่สุด.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์กระบวนการตามประเภทค่าใช้จ่าย และเผยให้เห็นเส้นทางกระบวนการ คอขวด หรืออัตราการคืนสินค้าที่แตกต่างกันในแต่ละหมวดหมู่.
แหล่งข้อมูล
เชื่อมจาก PO_LINES_ALL.CATEGORY_ID ไปยังมุมมอง EGP_CATEGORIES_VL.
ตัวอย่าง
ไอที.ฮาร์ดแวร์.แล็ปท็อปสำนักงาน.เครื่องเขียนบริการวิชาชีพ.ที่ปรึกษา
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ดึงหรือรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงความใหม่ของข้อมูลที่นำมาวิเคราะห์ โดยบันทึกวันที่และเวลาที่ดึงข้อมูลจาก Oracle Fusion Financials ล่าสุด. ข้อมูลนี้ช่วยให้ผู้ใช้ทราบว่าการวิเคราะห์และแดชบอร์ดเป็นปัจจุบันเพียงใด และเข้าใจว่าข้อมูลธุรกรรมล่าสุดถูกรวมไว้แล้วหรือไม่.
เหตุผลที่สำคัญ
แสดงความใหม่ของข้อมูลอย่างชัดเจน เพื่อให้ผู้ใช้ทราบว่าการวิเคราะห์กระบวนการอ้างอิงข้อมูลล่าสุดเพียงใด.
แหล่งข้อมูล
เวลานี้สร้างและเพิ่มระหว่างกระบวนการดึงและแปลงข้อมูล (ETL).
ตัวอย่าง
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
กิจกรรมจัดซื้อจนถึงชำระเงิน - ใบสั่งซื้อ
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
ปิดใบสั่งซื้อขั้นสุดท้าย
|
ถือว่าใบสั่งซื้อเสร็จสมบูรณ์เมื่อรับสินค้าและ/หรือบันทึกใบแจ้งหนี้ครบแล้ว และไม่คาดว่าจะมีกิจกรรมเพิ่มเติม การดำเนินการนี้กำหนดสถานะสิ้นสุดให้ใบสั่งซื้อโดยตรง. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้แสดงว่าใบสั่งซื้อเสร็จสิ้นตามวงจรการทำงาน เป็นสถานะสิ้นสุดที่สำเร็จหลักของกระบวนการ การติดตามกิจกรรมนี้จึงจำเป็นต่อการวัดปริมาณงานและอัตราการเสร็จสิ้นโดยรวม.
แหล่งข้อมูล
บันทึกเหตุการณ์นี้ในตาราง PO_ACTION_HISTORY โดยมีค่า ACTION_CODE เป็น 'FINALLY CLOSE' และปรับปรุงสถานะใบสั่งซื้อใน PO_HEADERS_ALL เป็น 'Finally Closed' ด้วย.
บันทึก
กรองตาราง PO_ACTION_HISTORY ด้วย ACTION_CODE = 'FINALLY CLOSE'.
ประเภทเหตุการณ์
explicit
|
|||
|
ยกเลิกใบสั่งซื้อ
|
ยกเลิกใบสั่งซื้ออย่างถาวรและไม่คาดว่าจะมีธุรกรรมเพิ่มเติม การดำเนินการนี้เปลี่ยนสถานะสุดท้ายของเอกสารโดยตรง. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นสถานะสิ้นสุดที่ไม่สำเร็จของกระบวนการ การวิเคราะห์การยกเลิกอาจช่วยให้พบปัญหา เช่น สั่งซื้อซ้ำ งบประมาณเปลี่ยน หรือข้อกำหนดของโครงการเปลี่ยนแปลง.
แหล่งข้อมูล
บันทึกการดำเนินการนี้ในตาราง PO_ACTION_HISTORY โดยมีค่า ACTION_CODE เป็น 'CANCEL' และปรับปรุงสถานะใบสั่งซื้อใน PO_HEADERS_ALL ตามนั้น.
บันทึก
กรองตาราง PO_ACTION_HISTORY ด้วย ACTION_CODE = 'CANCEL'.
ประเภทเหตุการณ์
explicit
|
|||
|
รับสินค้าแล้ว
|
รับสินค้า ตรวจนับ และบันทึกเทียบกับใบสั่งซื้อแล้ว เหตุการณ์นี้เป็นรายการธุรกรรมที่ปรับปรุงสินค้าคงคลังและสถานะใบสั่งซื้อ. | ||
|
เหตุผลที่สำคัญ
นี่คือหมุดหมายสำคัญสำหรับวัดประสิทธิภาพการส่งมอบตรงเวลาของผู้ขายและระยะเวลานำโดยรวม อีกทั้งยังเป็นจุดเริ่มต้นของกิจกรรมถัดไป เช่น การตรวจสอบคุณภาพและการจับคู่ใบแจ้งหนี้.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้โดยตรงในตาราง RCV_TRANSACTIONS โดยระบุธุรกรรมได้จากค่า TRANSACTION_TYPE ที่เป็น 'RECEIVE'.
บันทึก
ใช้ค่า TRANSACTION_DATE จากตาราง RCV_TRANSACTIONS โดยเลือกแถวที่ TRANSACTION_TYPE เป็น 'RECEIVE'.
ประเภทเหตุการณ์
explicit
|
|||
|
ส่งใบสั่งซื้อให้ผู้ขาย
|
แจ้งใบสั่งซื้อที่อนุมัติแล้วให้ผู้ขายอย่างเป็นทางการ เช่น ทางอีเมลหรือ EDI โดยมักอนุมานเหตุการณ์นี้จากการเปลี่ยนสถานะหรือเวลาที่บันทึกไว้ในรายการสื่อสาร PO. | ||
|
เหตุผลที่สำคัญ
นี่คือจุดเริ่มต้นของระยะเวลาจัดส่งจากผู้ขาย และเป็นจุดสำคัญในการวัดผลการดำเนินงานของผู้ขาย ตั้งแต่การตอบรับจนถึงการส่งมอบสินค้า.
แหล่งข้อมูล
อนุมานเหตุการณ์นี้ได้จากสถานะเอกสาร PO ที่เปลี่ยนเป็น 'Open' และมีการกรอกวันที่สื่อสาร โดยฟิลด์ที่ใช้มักเป็น PO_HEADERS_ALL.communicated_date หรือสถานะที่เกี่ยวข้อง.
บันทึก
อนุมานจากเวลาที่อัปเดตสถานะการสื่อสารของ PO เป็น 'Communicated'.
ประเภทเหตุการณ์
inferred
|
|||
|
สร้างใบสั่งซื้อ
|
นี่คือจุดเริ่มต้นอย่างเป็นทางการของวงจรใบสั่งซื้อ เมื่อระบบสร้างเอกสาร PO ในสถานะฉบับร่างหรือยังไม่สมบูรณ์ ระบบบันทึกเหตุการณ์นี้ด้วยเวลาที่สร้างรายการส่วนหัว PO ใหม่. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นเหตุการณ์เริ่มต้นหลักของเคส PO และเป็นพื้นฐานสำหรับคำนวณเวลารอบงานทั้งหมด ใช้เป็นจุดเริ่มต้นในการวัดประสิทธิภาพของขั้นตอนถัดไป เช่น การอนุมัติและการสื่อสารกับผู้ขาย.
แหล่งข้อมูล
เหตุการณ์นี้อ้างอิงจากฟิลด์ CREATION_DATE ในตาราง PO_HEADERS_ALL สำหรับ Purchase Order ID (PO_HEADER_ID) ที่ระบุ.
บันทึก
ใช้เวลาที่สร้างจากตาราง PO_HEADERS_ALL.
ประเภทเหตุการณ์
explicit
|
|||
|
อนุมัติใบสั่งซื้อ
|
ใบสั่งซื้อได้รับการอนุมัติครบถ้วนแล้ว และพร้อมส่งให้ผู้ขาย เหตุการณ์สำคัญนี้บันทึกไว้อย่างชัดเจนในประวัติการดำเนินการของเอกสาร. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สำคัญนี้เป็นเงื่อนไขก่อนส่ง PO ให้ผู้ขาย จำเป็นต่อการวัดเวลารอบการอนุมัติและตรวจสอบการปฏิบัติตามนโยบายการใช้จ่าย.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้ในตาราง PO_ACTION_HISTORY โดยทั่วไปใช้ ACTION_CODE เป็น 'APPROVE' หรือดูเมื่อสถานะเอกสารใน PO_HEADERS_ALL เปลี่ยนเป็นสถานะอนุมัติ.
บันทึก
กรอง PO_ACTION_HISTORY เพื่อหา 'APPROVE' รายการสุดท้าย.
ประเภทเหตุการณ์
explicit
|
|||
|
แก้ไขใบสั่งซื้อ
|
มีการแก้ไขใบสั่งซื้อหลังจากได้รับอนุมัติครั้งแรก เช่น เปลี่ยนจำนวน ราคา หรือวันที่ส่งมอบ Oracle Fusion บันทึกการแก้ไขโดยสร้างเอกสารฉบับแก้ไขใหม่. | ||
|
เหตุผลที่สำคัญ
การเปลี่ยนแปลงใบสั่งซื้อถือเป็นงานที่ต้องทำซ้ำ และอาจสะท้อนว่าข้อมูลในใบสั่งซื้อครั้งแรกไม่ถูกต้อง หรือความต้องการทางธุรกิจเปลี่ยนไป การวิเคราะห์ความถี่และลักษณะของการเปลี่ยนแปลงช่วยให้เห็นโอกาสในการปรับปรุงประสิทธิภาพกระบวนการ.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้อย่างชัดเจนเมื่อมีการสร้างเอกสารฉบับแก้ไขใหม่ โดยตรวจสอบได้จากค่าในฟิลด์ REVISION_NUM ที่เพิ่มขึ้นในตาราง PO_HEADERS_ALL.
บันทึก
ระบุทุกกรณีที่ค่า REVISION_NUM ของ PO_HEADER_ID เพิ่มขึ้น.
ประเภทเหตุการณ์
explicit
|
|||
|
ตรวจสอบคุณภาพสินค้าแล้ว
|
ตรวจสอบสินค้าที่ต้องผ่านการควบคุมคุณภาพแล้ว และระบุผลว่าอนุมัติหรือปฏิเสธ กิจกรรมนี้เกิดขึ้นหลังจากรับสินค้าเบื้องต้น และบันทึกเป็นธุรกรรมแยกต่างหาก. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้สำคัญต่อการจัดการคุณภาพ การวิเคราะห์ระยะเวลาตรวจสอบช่วยปรับขั้นตอนควบคุมคุณภาพให้คล่องตัวขึ้น และลดความล่าช้าก่อนนำสินค้าไปใช้งาน.
แหล่งข้อมูล
บันทึกกิจกรรมนี้ในตาราง RCV_TRANSACTIONS โดยระบุจากธุรกรรมที่มีค่า TRANSACTION_TYPE เป็น 'ACCEPT' หรือ 'REJECT' ซึ่งเกิดหลังธุรกรรมรับสินค้า.
บันทึก
ใช้ค่า TRANSACTION_DATE จากตาราง RCV_TRANSACTIONS โดยเลือกแถวที่ TRANSACTION_TYPE เป็น 'ACCEPT' หรือ 'REJECT'.
ประเภทเหตุการณ์
explicit
|
|||
|
ปฏิเสธใบสั่งซื้อ
|
ผู้อนุมัติปฏิเสธใบสั่งซื้อและส่งกลับให้ผู้สร้างแก้ไข ระบบบันทึกเหตุการณ์นี้ไว้อย่างชัดเจนในประวัติการดำเนินการ ซึ่งแสดงว่ากระบวนการเบี่ยงเบนจากขั้นตอนปกติ. | ||
|
เหตุผลที่สำคัญ
การปฏิเสธทำให้ต้องแก้ไขงานและทำให้กระบวนการล่าช้า การติดตามกิจกรรมนี้ช่วยระบุสาเหตุที่ถูกปฏิเสธบ่อย ความจำเป็นในการฝึกอบรม หรือข้อกำหนดการอนุมัติที่ไม่ชัดเจน.
แหล่งข้อมูล
บันทึกการดำเนินการนี้ในตาราง PO_ACTION_HISTORY โดยมี ACTION_CODE เป็น 'REJECT' สำหรับ PO_HEADER_ID ที่เกี่ยวข้อง.
บันทึก
กรอง PO_ACTION_HISTORY ด้วย ACTION_CODE = 'REJECT'.
ประเภทเหตุการณ์
explicit
|
|||
|
ผู้ขายตอบรับใบสั่งซื้อ
|
ผู้ขายยืนยันว่าได้รับใบสั่งซื้อและยอมรับเงื่อนไขแล้ว โดยทั่วไปเจ้าหน้าที่จัดซื้อจะบันทึกเหตุการณ์นี้ด้วยมือจากการสื่อสารกับผู้ขาย หรือระบบบันทึกผ่านการตอบรับทางอิเล็กทรอนิกส์. | ||
|
เหตุผลที่สำคัญ
การตอบรับจากผู้ขายช่วยยืนยันว่าผู้ขายได้รับคำสั่งซื้อและกำลังดำเนินการ การติดตามข้อมูลนี้ช่วยจัดการการสื่อสารกับผู้ขายและระบุปัญหาที่อาจเกิดขึ้นในการจัดส่งได้ล่วงหน้า.
แหล่งข้อมูล
โดยทั่วไปอนุมานเหตุการณ์นี้จากการเปลี่ยนแปลงในฟิลด์สถานะการตอบรับของส่วนหัวหรือรายการ PO เช่น PO_HEADERS_ALL.acceptance_status เปลี่ยนเป็น 'Accepted'.
บันทึก
อนุมานจากการอัปเดตฟิลด์สถานะการตอบรับ PO.
ประเภทเหตุการณ์
inferred
|
|||
|
ยืนยันการส่งมอบบริการแล้ว
|
สำหรับใบสั่งซื้อบริการ กิจกรรมนี้เป็นการยืนยันว่าผู้ขายให้บริการตามที่ตกลงไว้แล้ว โดยมักบันทึกด้วยตนเองหรือผ่านใบรับรองการให้บริการ. | ||
|
เหตุผลที่สำคัญ
ขั้นตอนนี้เทียบเท่ากับการรับสินค้าในกรณีบริการ และต้องดำเนินการก่อนจ่ายใบแจ้งหนี้ หากยืนยันบริการล่าช้า อาจทำให้จ่ายเงินล่าช้าและกระทบความสัมพันธ์กับผู้ขาย.
แหล่งข้อมูล
โดยทั่วไป ระบบบันทึกกิจกรรมนี้เป็นการรับบริการในรายการบริการของใบสั่งซื้อ อาจใช้ฟิลด์เฉพาะหรือรายการรับบริการที่ซับซ้อนเพื่อบันทึกความคืบหน้าหรือการให้บริการเสร็จสิ้น.
บันทึก
ระบุธุรกรรมรับสินค้า (RCV_TRANSACTIONS) ที่เชื่อมโยงกับรายการใบสั่งซื้อบริการ.
ประเภทเหตุการณ์
explicit
|
|||
|
ส่งใบสั่งซื้อเพื่ออนุมัติ
|
ส่งใบสั่งซื้อที่สร้างแล้วเข้าสู่เวิร์กโฟลว์การอนุมัติ Oracle Fusion บันทึกการดำเนินการนี้อย่างชัดเจน พร้อมระบุผู้ใช้และเวลาที่ส่ง. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดเริ่มต้นของรอบการอนุมัติ การวิเคราะห์เวลาตั้งแต่ส่งจนถึงอนุมัติเป็นกุญแจสำคัญในการระบุคอขวดของขั้นตอนอนุมัติภายใน.
แหล่งข้อมูล
บันทึกการดำเนินการนี้ในตาราง PO_ACTION_HISTORY โดยมี ACTION_CODE เป็น 'SUBMIT' สำหรับ PO_HEADER_ID ที่เกี่ยวข้อง.
บันทึก
กรอง PO_ACTION_HISTORY ด้วย ACTION_CODE = 'SUBMIT'.
ประเภทเหตุการณ์
explicit
|
|||
|
ส่งสินค้าคืนผู้ขาย
|
ส่งสินค้าที่รับไว้ก่อนหน้านี้คืนให้ผู้ขาย โดยทั่วไปเกิดจากสินค้าชำรุด เสียหาย หรือจัดส่งไม่ถูกต้อง ระบบบันทึกรายการนี้เป็นธุรกรรมคืนสินค้าโดยเฉพาะในโมดูลรับสินค้า. | ||
|
เหตุผลที่สำคัญ
การติดตามสินค้าคืนจำเป็นต่อการประเมินคุณภาพผู้ขายและความถูกต้องของคำสั่งซื้อ หากอัตราการคืนสินค้าของผู้ขายรายใดสูง อาจบ่งชี้ถึงปัญหาที่เกิดซ้ำและควรได้รับการแก้ไข.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้โดยตรงในตาราง RCV_TRANSACTIONS โดยมีค่า TRANSACTION_TYPE เป็น 'RETURN TO VENDOR'.
บันทึก
ใช้ค่า TRANSACTION_DATE จากตาราง RCV_TRANSACTIONS โดยเลือกแถวที่ TRANSACTION_TYPE เป็น 'RETURN TO VENDOR'.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้างคำขอซื้อ
|
กิจกรรมนี้บันทึกการสร้างคำขอซื้อ ซึ่งเป็นคำขออย่างเป็นทางการสำหรับสินค้าและบริการก่อนออกใบสั่งซื้อ ระบบบันทึกกิจกรรมนี้เมื่อมีการสร้างรายการใหม่ในตารางส่วนหัวคำขอซื้อของ Oracle Fusion. | ||
|
เหตุผลที่สำคัญ
การวิเคราะห์กิจกรรมนี้ช่วยให้เข้าใจขั้นตอนเริ่มต้นของความต้องการ การติดตามเวลาตั้งแต่สร้างคำขอซื้อจนถึงสร้างใบสั่งซื้อช่วยระบุความล่าช้าที่อาจเกิดขึ้นระหว่างการแปลงความต้องการภายในให้เป็นคำสั่งซื้อเพื่อจัดซื้อ.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้อย่างชัดเจนเมื่อบันทึกคำขอซื้อใหม่ คุณตรวจสอบได้จากเวลาที่สร้างรายการในตาราง POR_REQUISITION_HEADERS_ALL.
บันทึก
เหตุการณ์นี้อ้างอิงจากวันที่สร้างรายการในตาราง POR_REQUISITION_HEADERS_ALL.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้างเอกสารรับสินค้า
|
ระบบเริ่มสร้างเอกสารรับสินค้าเพื่อเตรียมรับสินค้าที่จะมาถึงจริง กิจกรรมนี้เป็นจุดเริ่มต้นของกระบวนการรับสินค้าภายในองค์กร. | ||
|
เหตุผลที่สำคัญ
จุดนี้เป็นช่วงเปลี่ยนผ่านจากการจัดซื้อไปสู่การจัดการโลจิสติกส์ การวิเคราะห์เวลาตั้งแต่ขั้นตอนนี้จนถึงการบันทึกรับสินค้าขั้นสุดท้ายช่วยให้พบจุดที่ทำงานไม่มีประสิทธิภาพในคลังสินค้าหรือแผนกรับสินค้า.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้โดยตรงจากเวลาที่สร้างระเบียนใหม่ในตาราง RCV_SHIPMENT_HEADERS ซึ่งเชื่อมโยงกับใบสั่งซื้อ.
บันทึก
ใช้วันที่สร้างของระเบียนที่เกี่ยวข้องในตาราง RCV_SHIPMENT_HEADERS.
ประเภทเหตุการณ์
explicit
|
|||
|
อนุมัติคำขอซื้อ
|
ผู้มีอำนาจที่ได้รับมอบหมายอนุมัติคำขอซื้อแล้ว ทำให้ฝ่ายจัดซื้อสามารถสร้างใบสั่งซื้อได้ ระบบบันทึกเหตุการณ์นี้ไว้อย่างชัดเจนในประวัติการดำเนินการของคำขอซื้อ. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สำคัญนี้หมายถึงกระบวนการอนุมัติคำขอภายในเสร็จสิ้น ความล่าช้าในขั้นตอนนี้อาจส่งผลโดยตรงต่อระยะเวลาจัดซื้อทั้งหมด จึงควรติดตามระยะเวลาอย่างใกล้ชิด.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้ในประวัติการดำเนินการที่เชื่อมโยงกับคำขอซื้อ โดยทั่วไปติดตามได้จากตารางเวิร์กโฟลว์หรือช่องสถานะการอนุมัติเฉพาะในเอกสารคำขอซื้อ.
บันทึก
บันทึกเป็นการอนุมัติในประวัติเวิร์กโฟลว์ของเอกสารคำขอซื้อรายการนั้น.
ประเภทเหตุการณ์
explicit
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้ช่วยจัดระเบียบการรวบรวมข้อมูล และเริ่มค้นหาข้อมูลเชิงลึกเกี่ยวกับกระบวนการ Purchase Order ตั้งแต่จัดซื้อจนถึงชำระเงิน เริ่มปรับปรุงการปฏิบัติการได้เลย.
ปรับปรุงกระบวนการ Purchase to Pay - Purchase Order วันนี้
ระบุคอขวดที่ทำให้เกิดต้นทุนสูง และลดเวลารอบกระบวนการได้ 30% อย่างง่ายดาย.
ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงกระบวนการได้เลย.