เทมเพลตข้อมูลกระบวนการจัดซื้อจนถึงชำระเงิน: คำขอซื้อ
เทมเพลตข้อมูลกระบวนการจัดซื้อจนถึงชำระเงิน: คำขอซื้อ
- แอตทริบิวต์ที่แนะนำให้รวบรวมเพื่อวิเคราะห์รายละเอียด
- กิจกรรมสำคัญที่ควรติดตามเพื่อค้นพบกระบวนการ
- แนวทางสกัดข้อมูลจาก SAP S/4HANA
แอตทริบิวต์ของกระบวนการจัดซื้อจนถึงชำระเงิน: คำขอซื้อ
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อกิจกรรมทางธุรกิจที่เกิดขึ้น ณ จุดหนึ่งในกระบวนการใบขอซื้อ. | ||
| คำอธิบาย ชื่อกิจกรรมใช้ระบุเหตุการณ์หรืองานที่เกิดขึ้นในวงจรชีวิตของใบขอซื้อ กิจกรรมเหล่านี้ได้มาจากบันทึกของระบบ เช่น เอกสารการเปลี่ยนแปลงและประวัติเวิร์กโฟลว์ โดยแสดงหมุดหมายสำคัญของกระบวนการ เช่น 'สร้างใบขอซื้อ' 'เริ่มขั้นตอนการอนุมัติ' หรือ 'สร้างใบสั่งซื้อ'. การวิเคราะห์กิจกรรมช่วยให้เห็นภาพการไหลของกระบวนการ ระบุคอขวด และวัดเวลาที่ใช้ในแต่ละขั้นตอน การทำความเข้าใจลำดับและความถี่ของกิจกรรม เช่น 'แก้ไขใบขอซื้อ' หรือ 'ปฏิเสธใบขอซื้อ' เป็นสิ่งสำคัญในการค้นหาความไม่มีประสิทธิภาพและจุดที่ควรปรับปรุง. เหตุผลที่สำคัญ แอตทริบิวต์นี้กำหนดขั้นตอนของกระบวนการ เป็นโครงสร้างหลักของแผนผังกระบวนการ และช่วยวิเคราะห์ลำดับงาน ความแตกต่าง และคอขวด. แหล่งข้อมูล แอตทริบิวต์นี้ได้จากการประมวลผล โดยทั่วไปสร้างจากการตีความข้อมูลในตารางเอกสารการเปลี่ยนแปลง (CDHDR, CDPOS) และบันทึกเวิร์กโฟลว์ เช่น SWWLOGHIST. ตัวอย่าง สร้างใบขอซื้อเสร็จสิ้นขั้นตอนการอนุมัติอนุมัติใบขอซื้อแล้วสร้างใบสั่งซื้อ | |||
| รหัสใบขอซื้อ PurchaseRequisitionId | รหัสเฉพาะของเอกสารใบขอซื้อ. | ||
| คำอธิบาย รหัสใบขอซื้อเป็นคีย์หลักที่ใช้ระบุคำขอซื้อสินค้าหรือบริการแต่ละรายการใน SAP S/4HANA โดยไม่ซ้ำกัน รหัสนี้ทำหน้าที่เป็นรหัสอ้างอิงกลางของแต่ละกรณี และเชื่อมกิจกรรมกับการเปลี่ยนแปลงทั้งหมดที่เกี่ยวข้องกับใบขอซื้อตั้งแต่สร้างจนถึงสถานะสุดท้าย เช่น อนุมัติ ปฏิเสธ หรือแปลงเป็นใบสั่งซื้อ. ใน process mining แอตทริบิวต์นี้เป็นพื้นฐานสำหรับสร้างภาพวงจรชีวิตของใบขอซื้อแต่ละรายการให้ครบถ้วน เมื่อนำเหตุการณ์ที่เกี่ยวข้องมาจัดกลุ่มด้วยรหัสใบขอซื้อเดียวกัน นักวิเคราะห์จะวัดระยะเวลาดำเนินการ ติดตามการเปลี่ยนสถานะ และวิเคราะห์เส้นทางต่างๆ ที่ใบขอซื้ออาจผ่านในกระบวนการอนุมัติได้อย่างแม่นยำ. เหตุผลที่สำคัญ นี่คือรหัสอ้างอิงสำคัญที่เชื่อมขั้นตอนทั้งหมดของกระบวนการเข้าด้วยกัน ทำให้เห็นวงจรชีวิตของใบขอซื้อได้ครบถ้วนและต่อเนื่อง. แหล่งข้อมูล แอตทริบิวต์นี้คือเลขที่ใบขอซื้อ ซึ่งอยู่ในตาราง EBAN ฟิลด์ BANFN. ตัวอย่าง 100178901001789110017892 | |||
| เวลาเกิดเหตุการณ์ EventTime | วันที่และเวลาที่แน่นอนของกิจกรรมหนึ่งๆ. | ||
| คำอธิบาย เวลาเกิดเหตุการณ์คือเวลาประทับที่บันทึกว่ากิจกรรมเกิดขึ้นเมื่อใด ข้อมูลนี้จำเป็นต่อการเรียงลำดับเหตุการณ์ตามเวลาในแต่ละกรณี และใช้คำนวณระยะเวลาและประสิทธิภาพทั้งหมดใน process mining ตัวอย่างเช่น เวลาระหว่างเหตุการณ์ 'ส่งใบขอซื้อ' กับ 'อนุมัติใบขอซื้อ' ใช้คำนวณระยะเวลาการอนุมัติ. เวลาประทับที่ถูกต้องช่วยให้วิเคราะห์ประสิทธิภาพของกระบวนการ ระบุความล่าช้า และติดตามการปฏิบัติตามข้อตกลงระดับการให้บริการได้ แอตทริบิวต์นี้ช่วยสร้างแดชบอร์ดเพื่อแสดงระยะเวลาดำเนินการ ติดตามใบขอซื้อที่ค้าง และเปรียบเทียบผลการดำเนินงานในช่วงเวลาต่างๆ. เหตุผลที่สำคัญ เวลาประทับนี้จำเป็นต่อการเรียงลำดับเหตุการณ์ คำนวณระยะเวลาดำเนินการ และวิเคราะห์ประสิทธิภาพของกระบวนการกับคอขวด. แหล่งข้อมูล โดยทั่วไป เวลาประทับมาจากส่วนหัวเอกสารการเปลี่ยนแปลง (CDHDR-UDATE, CDHDR-UTIME) หรือบันทึกเหตุการณ์ของเวิร์กโฟลว์. ตัวอย่าง 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ประเภทใบขอซื้อ RequisitionType | รหัสที่ใช้จัดประเภทใบขอซื้อ เช่น รายการสินค้าทั่วไป บริการ หรือรายจ่ายลงทุน. | ||
| คำอธิบาย ประเภทใบขอซื้อ หรือที่เรียกว่าประเภทเอกสารใน SAP เป็นฟิลด์การตั้งค่าสำคัญที่ใช้จัดหมวดหมู่ใบขอซื้อ ประเภทที่ต่างกันอาจเรียกใช้เวิร์กโฟลว์การอนุมัติและการตั้งค่าฟิลด์ที่ต่างกัน รวมถึงใช้กับวัตถุประสงค์ทางธุรกิจที่ต่างกัน เช่น สินค้าคงคลังทั่วไป บริการจากภายนอก หรือการซื้อสินทรัพย์. การวิเคราะห์กระบวนการตามประเภทใบขอซื้อช่วยให้องค์กรเข้าใจวิธีจัดการคำขอแต่ละประเภท และเปรียบเทียบผลการดำเนินงาน ระยะเวลาดำเนินการ และขั้นตอนการอนุมัติในแต่ละหมวดหมู่ เพื่อดูว่าประเภทใดมีประสิทธิภาพมากหรือน้อยกว่า และกำหนดแนวทางปรับปรุงกระบวนการให้เหมาะสมได้. เหตุผลที่สำคัญ จัดหมวดหมู่ใบขอซื้อเพื่อเปรียบเทียบและทำความเข้าใจว่าคำขอแต่ละประเภทมีลำดับงาน คอขวด หรือระยะเวลาดำเนินการต่างกันหรือไม่. แหล่งข้อมูล ฟิลด์ประเภทเอกสารอยู่ในตาราง EBAN ฟิลด์ BSART. ตัวอย่าง NBFORV | |||
| แผนก Department | แผนกหรือศูนย์ต้นทุนที่รับผิดชอบค่าใช้จ่ายของใบขอซื้อ. | ||
| คำอธิบาย แอตทริบิวต์แผนก ซึ่งมักแสดงด้วยศูนย์ต้นทุนใน SAP ใช้ระบุหน่วยธุรกิจที่รับผิดชอบการซื้อที่ร้องขอ เป็นข้อมูลด้านการเงินและโครงสร้างองค์กรที่สำคัญ ซึ่งกำหนดไว้ในระดับรายการของใบขอซื้อ. ใน process mining แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ผลการดำเนินงานของแต่ละแผนก โดยใช้แดชบอร์ดเปรียบเทียบตัวชี้วัดสำคัญ เช่น ระยะเวลาดำเนินการ อัตราการแก้ไข และอัตราการปฏิเสธระหว่างแผนก ช่วยให้เห็นแนวปฏิบัติที่ดีจากแผนกที่ทำผลงานได้ดี และระบุแผนกที่อาจต้องการการฝึกอบรมหรือการสนับสนุนด้านกระบวนการเพิ่มเติม. เหตุผลที่สำคัญ ช่วยเปรียบเทียบผลการดำเนินงานระหว่างหน่วยธุรกิจ โดยแสดงความแตกต่างของระยะเวลาดำเนินการหรืออัตราการปฏิเสธ เพื่อค้นหาแนวปฏิบัติที่ดีและจุดที่ควรปรับปรุง. แหล่งข้อมูล ข้อมูลนี้คือศูนย์ต้นทุน ซึ่งโดยทั่วไปอยู่ในตารางกำหนดบัญชี EBKN ฟิลด์ KOSTL. ตัวอย่าง FIN-1001IT-2005MKT-3010 | |||
| มูลค่าใบขอซื้อ RequisitionAmount | มูลค่ารวมของใบขอซื้อ. | ||
| คำอธิบาย มูลค่าใบขอซื้อคือค่าใช้จ่ายโดยประมาณทั้งหมดของสินค้าหรือบริการที่ร้องขอ มูลค่านี้มักเป็นปัจจัยสำคัญในการกำหนดความซับซ้อนและระยะเวลาของเวิร์กโฟลว์การอนุมัติ โดยใบขอซื้อที่มีมูลค่าสูงมักต้องผ่านการอนุมัติหลายระดับ. การวิเคราะห์แอตทริบิวต์นี้ช่วยแบ่งกลุ่มกระบวนการตามมูลค่า และตอบคำถามได้ เช่น ใบขอซื้อมูลค่าสูงใช้เวลาอนุมัตินานกว่าหรือไม่ หรือใบขอซื้อที่ถูกปฏิเสธบ่อยมีมูลค่าเท่าใด นี่เป็นมิติสำคัญในการทำความเข้าใจผลกระทบทางการเงินจากความไม่มีประสิทธิภาพของกระบวนการ. เหตุผลที่สำคัญ ช่วยแบ่งกลุ่มกระบวนการตามผลกระทบทางการเงิน ซึ่งมักสัมพันธ์กับความซับซ้อนในการอนุมัติและระยะเวลาดำเนินการ จึงจำเป็นต่อการวิเคราะห์กระบวนการตามมูลค่า. แหล่งข้อมูล มูลค่ารวมอยู่ในตาราง EBAN ฟิลด์ GFWERT ส่วนมูลค่าระดับรายการอยู่ใน EBAN-PREIS. ตัวอย่าง 1500.0075000.50250.75 | |||
| รหัสผู้ใช้ UserId | รหัสของผู้ใช้ที่สร้างใบขอซื้อหรือทำกิจกรรมหนึ่งๆ. | ||
| คำอธิบาย รหัสผู้ใช้ระบุพนักงานหรือผู้ใช้ระบบที่รับผิดชอบเหตุการณ์หนึ่งในวงจรชีวิตของใบขอซื้อ อาจเป็นผู้สร้างใบขอซื้อ ผู้จัดการที่อนุมัติ หรือผู้ดำเนินการแก้ไข หากเป็นขั้นตอนอัตโนมัติ รหัสนี้อาจเป็นรหัสผู้ใช้ระบบหรือผู้ใช้แบบแบตช์. การวิเคราะห์ตามรหัสผู้ใช้ช่วยให้เข้าใจพฤติกรรมและผลการดำเนินงานของผู้ใช้ รวมถึงการกระจายภาระงาน ข้อมูลนี้ช่วยระบุความต้องการในการฝึกอบรม ยกย่องผู้ที่ทำงานได้ดี และกำหนดความรับผิดชอบในกระบวนการ นอกจากนี้ยังใช้วิเคราะห์ผลการดำเนินงานของแต่ละแผนกได้เมื่อเชื่อมกับข้อมูลหลักของผู้ใช้. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพของผู้ใช้ การกระจายภาระงาน และการปฏิบัติตามข้อกำหนดของกระบวนการ อีกทั้งช่วยระบุโอกาสในการฝึกอบรมและคอขวดด้านทรัพยากร. แหล่งข้อมูล รหัสผู้สร้างอยู่ใน EBAN-ERNAM ส่วนการเปลี่ยนแปลงภายหลังอยู่ใน CDHDR-USERNAME และการอนุมัติอยู่ในบันทึกเวิร์กโฟลว์. ตัวอย่าง JSMITHRROEWF-BATCH | |||
| รหัสผู้อนุมัติ ApproverId | รหัสของผู้ใช้ที่ดำเนินการอนุมัติหรือปฏิเสธ. | ||
| คำอธิบาย รหัสผู้อนุมัติระบุผู้ใช้ที่ดำเนินการอนุมัติหรือปฏิเสธโดยเฉพาะ ต่างจากรหัสผู้ใช้ทั่วไป เพราะใช้ระบุผู้ตัดสินใจในเวิร์กโฟลว์การอนุมัติเท่านั้น การบันทึกข้อมูลนี้จำเป็นต่อการวิเคราะห์กระบวนการอนุมัติโดยละเอียด. แอตทริบิวต์นี้ช่วยวิเคราะห์พฤติกรรมการอนุมัติ เช่น ระบุผู้จัดการที่ใช้เวลาอนุมัตินานหรือปฏิเสธใบขอซื้อบ่อยครั้ง ข้อมูลนี้เป็นพื้นฐานของแดชบอร์ดที่เน้นระยะเวลาในแต่ละขั้นตอนอนุมัติและการวิเคราะห์คอขวดในเวิร์กโฟลว์ ช่วยระบุบุคคลหรือบทบาทที่อาจทำให้เกิดความล่าช้าได้ตรงจุด. เหตุผลที่สำคัญ ระบุผู้ตัดสินใจในแต่ละขั้นตอนอนุมัติ ช่วยวิเคราะห์ระยะเวลาและคอขวดแยกตามบุคคลหรือบทบาทได้อย่างละเอียด. แหล่งข้อมูล โดยทั่วไปดึงข้อมูลนี้จากตาราง SAP Business Workflow เช่น SWW_WI2OBJ และ SWWLOGHIST ซึ่งเชื่อมรายการงานกับผู้ใช้ที่ดำเนินการเสร็จ. ตัวอย่าง MJOHNSONCWILLIAMSLBLACK | |||
| สถานะใบขอซื้อ RequisitionStatus | สถานะปัจจุบันของการดำเนินการหรือการอนุมัติใบขอซื้อ. | ||
| คำอธิบาย สถานะใบขอซื้อแสดงสถานะปัจจุบันของใบขอซื้อในวงจรชีวิต ใน SAP มักแสดงด้วยตัวบ่งชี้การอนุมัติ ซึ่งระบุว่าใบขอซื้อถูกระงับ อยู่ระหว่างอนุมัติ อนุมัติบางส่วน หรืออนุมัติครบแล้ว สถานะนี้จะเปลี่ยนไปตามขั้นตอนที่ใบขอซื้อดำเนินผ่านในเวิร์กโฟลว์. การติดตามสถานะตามเวลาช่วยให้เข้าใจลำดับงาน ระบุได้ว่าใบขอซื้อค้างอยู่ที่ขั้นตอนไหนและนานเท่าใด การวิเคราะห์การเปลี่ยนสถานะช่วยให้เห็นรายละเอียดของกระบวนการอนุมัติและรูปแบบการดำเนินงานที่แตกต่างกัน. เหตุผลที่สำคัญ แสดงสถานะปัจจุบันของใบขอซื้อ ซึ่งจำเป็นต่อการติดตามความคืบหน้า ระบุคอขวด และวิเคราะห์ลำดับงาน. แหล่งข้อมูล สถานะการอนุมัติมักกำหนดจากตัวบ่งชี้การอนุมัติ ซึ่งอยู่ในตาราง EBAN ฟิลด์ FRGZU. ตัวอย่าง B1S | |||
| ชื่อขั้นตอนการอนุมัติ ApprovalStepName | ชื่อหรือคำอธิบายเฉพาะของขั้นตอนการอนุมัติใน workflow. | ||
| คำอธิบาย ชื่อขั้นตอนการอนุมัติเป็นคำอธิบายที่อ่านเข้าใจง่ายของแต่ละช่วงใน workflow การอนุมัติ เช่น 'ผู้จัดการอนุมัติ' หรือ 'รองประธานฝ่ายการเงินอนุมัติ' ซึ่งให้รายละเอียดมากกว่ากิจกรรมทั่วไปอย่าง 'ดำเนินการอนุมัติเสร็จแล้ว' แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด Approval Step Cycle Time และ Workflow Bottleneck Analysis โดยช่วยให้เห็นรายละเอียดของแต่ละช่วงในกระบวนการอนุมัติ และระบุได้อย่างชัดเจนว่าขั้นตอนใดทำให้เกิดความล่าช้ามากที่สุดหรืองานคั่งอยู่ตรงไหน ข้อมูลระดับนี้ช่วยให้ปรับปรุงห่วงโซ่การอนุมัติได้ตรงจุด. เหตุผลที่สำคัญ แสดงรายละเอียดของแต่ละขั้นตอนการอนุมัติ ช่วยระบุคอขวดใน workflow การอนุมัติหลายระดับได้อย่างแม่นยำ. แหล่งข้อมูล ข้อมูลนี้ได้มาจากคำอธิบายงานใน workflow ซึ่งค้นหาได้โดยเชื่อมบันทึก workflow กับตารางคำจำกัดความของงาน เช่น T528T. ตัวอย่าง อนุมัติโดยผู้จัดการอนุมัติโดยผู้อำนวยการอนุมัติโดยรองประธานฝ่ายการเงิน | |||
| ดำเนินการโดยอัตโนมัติ IsAutomated | แฟล็กที่ระบุว่ากิจกรรมดำเนินการโดยผู้ใช้ระบบแทนบุคคลหรือไม่. | ||
| คำอธิบาย แอตทริบิวต์ Is Automated เป็นค่าสถานะบูลีน โดยมีค่า true เมื่อกิจกรรมดำเนินการโดยระบบหรือผู้ใช้แบบแบตช์ เช่น 'WF-BATCH' สำหรับการดำเนินการของเวิร์กโฟลว์ ค่านี้ช่วยแยกขั้นตอนที่ทำด้วยตนเองออกจากขั้นตอนอัตโนมัติในกระบวนการ แอตทริบิวต์นี้จำเป็นต่อการวัดระดับการทำงานอัตโนมัติในกระบวนการใบขอซื้อ และคำนวณ KPI 'อัตราการอนุมัติอัตโนมัติ' นักวิเคราะห์สามารถกรองขั้นตอนอัตโนมัติหรือขั้นตอนที่ทำด้วยตนเองเพื่อเปรียบเทียบประสิทธิภาพ และหาโอกาสเพิ่มระบบอัตโนมัติเพื่อลดเวลาประมวลผลและภาระงานที่ต้องทำด้วยตนเอง. เหตุผลที่สำคัญ ช่วยแยกกิจกรรมที่บุคคลดำเนินการออกจากกิจกรรมที่ระบบดำเนินการ ซึ่งเป็นข้อมูลสำคัญสำหรับวัดอัตราการทำงานอัตโนมัติและหาโอกาสเปลี่ยนงานที่ทำด้วยตนเองให้เป็นระบบอัตโนมัติ. แหล่งข้อมูล แอตทริบิวต์นี้ได้จากการคำนวณ โดยทั่วไปจะใช้กฎตรวจสอบว่า User ID ของเหตุการณ์อยู่ในรายชื่อผู้ใช้ระบบหรือผู้ใช้แบบแบตช์ที่ทราบอยู่แล้วหรือไม่. ตัวอย่าง truefalse | |||
| เป็นงานแก้ไขซ้ำหรือไม่ IsRework | ค่าสถานะที่ระบุว่ากิจกรรมเป็นงานแก้ไขซ้ำหรือไม่ เช่น การแก้ไขคำขอหลังจากส่งแล้ว. | ||
| คำอธิบาย Is Rework เป็นค่าสถานะแบบบูลีนที่คำนวณขึ้น เพื่อระบุกิจกรรมที่เป็นงานซ้ำหรือไม่เพิ่มคุณค่า ตัวอย่างที่พบได้ในกระบวนการนี้คือกิจกรรม 'แก้ไขคำขอซื้อ' หลังจากส่งคำขอเพื่อขออนุมัติแล้ว ซึ่งทำให้ต้องเริ่มกระบวนการอนุมัติใหม่ แอตทริบิวต์นี้ช่วยวัดปริมาณงานแก้ไขซ้ำและผลกระทบต่อรอบเวลาดำเนินการโดยรวม แดชบอร์ด Requisition Amendment and Rework Rate ใช้ค่าสถานะนี้เพื่อแสดงจุดที่กระบวนการไม่มีประสิทธิภาพ การลดงานแก้ไขซ้ำมักเป็นเป้าหมายหลักของการปรับปรุงกระบวนการ เพราะช่วยประหยัดเวลาและแรงงานได้โดยตรง. เหตุผลที่สำคัญ ระบุกิจกรรมที่ทำให้เสียแรงงานโดยเปล่าประโยชน์หรือเป็นงานซ้ำ ช่วยวัดปริมาณงานแก้ไขซ้ำและผลกระทบต่อประสิทธิภาพกระบวนการได้โดยตรง. แหล่งข้อมูล แอตทริบิวต์นี้ได้จากการคำนวณ โดยทั่วไปจะระบุกิจกรรม 'แก้ไขคำขอซื้อ' ที่เกิดขึ้นหลังจากกิจกรรม 'ส่งคำขอซื้อเพื่อขออนุมัติ' ครั้งแรกว่าเป็นงานแก้ไขซ้ำ. ตัวอย่าง truefalse | |||
| ระดับความเร่งด่วน UrgencyLevel | การจัดระดับความเร่งด่วนของคำขอซื้อ ซึ่งอาจมีผลต่อลำดับความสำคัญในการดำเนินการ. | ||
| คำอธิบาย ระดับความเร่งด่วนแสดงลำดับความสำคัญของคำขอซื้อ แม้จะไม่มีฟิลด์มาตรฐานสำหรับข้อมูลนี้โดยเฉพาะ แต่บางองค์กรใช้ฟิลด์อย่าง Requirement Tracking Number เพื่อบันทึกข้อมูลนี้ ผู้ขอจึงสามารถระบุความต้องการเร่งด่วนที่อาจต้องดำเนินการเป็นพิเศษได้ การวิเคราะห์ผลของระดับความเร่งด่วนช่วยให้ประเมินได้ว่ากระบวนการให้ความสำคัญกับคำขอเร่งด่วนได้จริงหรือไม่ แดชบอร์ด Urgency Level Impact Analysis ใช้แอตทริบิวต์นี้เปรียบเทียบรอบเวลาดำเนินการและอัตราการอนุมัติของคำขอเร่งด่วนกับคำขอทั่วไป เพื่อดูว่าการจัดลำดับความสำคัญเป็นไปตามที่ตั้งใจไว้หรือไม่. เหตุผลที่สำคัญ ช่วยวิเคราะห์ความแตกต่างของประสิทธิภาพกระบวนการสำหรับคำขอที่มีลำดับความสำคัญสูง และตรวจสอบได้ว่ารายการเร่งด่วนได้รับการดำเนินการเร็วขึ้นจริงหรือไม่. แหล่งข้อมูล ไม่มีฟิลด์มาตรฐานสำหรับระบุความเร่งด่วน บางบริษัทใช้ Requirement Tracking Number (EBAN-BEDAR) เพื่อจุดประสงค์นี้ หรืออาจใช้ฟิลด์ที่กำหนดเอง. ตัวอย่าง สูงปานกลางต่ำ | |||
| ระบบต้นทาง SourceSystem | ระบุอินสแตนซ์ SAP S/4HANA ที่ดึงข้อมูลมา. | ||
| คำอธิบาย แอตทริบิวต์ระบบต้นทางระบุระบบที่สร้างข้อมูลกระบวนการ ในองค์กรที่มี SAP หลายอินสแตนซ์ เช่น ระบบพัฒนา ระบบประกันคุณภาพ และระบบใช้งานจริง หรือระบบแยกตามภูมิภาค ฟิลด์นี้จำเป็นต่อการกำกับดูแลข้อมูลและการทำความเข้าใจบริบท. ฟิลด์นี้ช่วยแยกข้อมูลจากแต่ละแหล่ง ป้องกันการรวมข้อมูลผิดพลาด และรองรับการวิเคราะห์แยกตามระบบ อีกทั้งจำเป็นต่อการติดตามที่มาของข้อมูลและตรวจสอบย้อนกลับข้อมูลกระบวนการ. เหตุผลที่สำคัญ ให้ข้อมูลสำคัญเกี่ยวกับที่มาและการกำกับดูแลข้อมูล โดยเฉพาะเมื่อมีหลายระบบ และช่วยให้ตรวจสอบย้อนกลับข้อมูลได้. แหล่งข้อมูล โดยทั่วไปคือ SAP System ID (SID) ซึ่งเรียกดูได้จากตัวแปรระบบหรือตารางการตั้งค่า. ตัวอย่าง S4PECCS4H_PROD_01 | |||
| เลขที่ใบสั่งซื้อ PurchaseOrderNumber | เลขที่ใบสั่งซื้อที่สร้างจากใบขอซื้อ. | ||
| คำอธิบาย เลขที่ใบสั่งซื้อใช้ระบุเอกสารจัดซื้ออย่างเป็นทางการที่สร้างจากใบขอซื้อที่อนุมัติแล้ว การสร้างใบสั่งซื้อมักเป็นผลลัพธ์สุดท้ายที่สำเร็จของใบขอซื้อ หมายความว่าคำขอถูกแปลงเป็นคำสั่งซื้ออย่างเป็นทางการกับผู้ขาย. แอตทริบิวต์นี้จำเป็นต่อการวัด KPI ระยะเวลาตั้งแต่ใบขอซื้อจนถึงใบสั่งซื้อ และอัตราการแปลงโดยรวม ทั้งยังเชื่อมกระบวนการขอซื้อกับกระบวนการจัดซื้อขั้นถัดไป ทำให้เห็นภาพวงจรจัดซื้อจนถึงชำระเงินได้ตั้งแต่ต้นจนจบ. เหตุผลที่สำคัญ เชื่อมใบขอซื้อกับเอกสารจัดซื้อที่สร้างต่อจากนั้น ช่วยวัดอัตราการแปลงจากใบขอซื้อเป็น PO และระยะเวลาดำเนินการ. แหล่งข้อมูล อยู่ในตาราง EBAN ฟิลด์ EBELN เมื่อสร้าง PO จากรายการใบขอซื้อแล้ว. ตัวอย่าง 450001789045000178914500017892 | |||
| วันที่ต้องการรับสินค้า RequiredByDate | วันที่ผู้ขอต้องการได้รับสินค้าหรือบริการที่ร้องขอ. | ||
| คำอธิบาย วันที่ต้องการรับสินค้า หรือวันที่ส่งมอบใน SAP ระบุวันที่ต้องการสินค้าหรือบริการในรายการใบขอซื้อ ผู้ขอเป็นผู้กำหนดวันที่นี้ และใช้เป็นเป้าหมายของกระบวนการจัดซื้อทั้งหมด. แอตทริบิวต์นี้จำเป็นต่อการคำนวณ KPI 'อัตราการดำเนินการใบขอซื้อเสร็จตรงเวลา' โดยเปรียบเทียบวันที่ต้องการรับสินค้ากับวันที่อนุมัติขั้นสุดท้ายหรือวันที่สร้าง PO องค์กรจะวัดได้ว่าสามารถทำตามระดับการให้บริการภายในและความต้องการทางธุรกิจได้หรือไม่ การวิเคราะห์ใบขอซื้อที่ไม่ทันกำหนดช่วยให้เห็นความล่าช้าที่เกิดขึ้นเป็นระบบในกระบวนการจัดซื้อ. เหตุผลที่สำคัญ กำหนดวันที่เป้าหมายที่ต้องดำเนินการตามคำขอให้เสร็จ ช่วยวัดการส่งมอบตรงเวลาและการปฏิบัติตามระดับการให้บริการภายใน. แหล่งข้อมูล ข้อมูลนี้คือวันที่ส่งมอบ ซึ่งอยู่ในระดับรายการของตาราง EBAN ฟิลด์ LFDAT. ตัวอย่าง 2023-11-152023-12-012024-01-20 | |||
| เวลาสิ้นสุด EndTime | วันที่และเวลาที่กิจกรรมหนึ่งเสร็จสิ้นอย่างแม่นยำ. | ||
| คำอธิบาย EndTime คือเวลาประทับที่บันทึกว่ากิจกรรมเสร็จสิ้นเมื่อใด เหตุการณ์ที่ระบบสร้างขึ้นหลายรายการเกิดขึ้นทันที จึงมี StartTime และ EndTime ตรงกัน ส่วนงานที่บุคคลทำ เช่น การอนุมัติ อาจมีเวลาเริ่มต้นและสิ้นสุดต่างกัน เวลานี้ระบุว่างานเสร็จเมื่อใด การบันทึก EndTime แยกต่างหากช่วยวัดเวลาที่ใช้ดำเนินงานจริงเทียบกับเวลารอได้แม่นยำขึ้น โดยใช้ร่วมกับ StartTime เพื่อคำนวณเมตริก ProcessingTime ข้อมูลที่ละเอียดขึ้นยังช่วยวิเคราะห์การใช้ทรัพยากรและประสิทธิภาพของงานที่ทำด้วยตนเองได้ด้วย. เหตุผลที่สำคัญ ระบุเวลาที่กิจกรรมเสร็จสิ้น ช่วยคำนวณเวลาที่ใช้ทำงานจริงและดูระยะเวลาของงานได้ละเอียดขึ้น. แหล่งข้อมูล ข้อมูลนี้ได้มาจากบันทึก workflow ซึ่งอาจบันทึกทั้งเวลาที่สร้างรายการงาน (StartTime) และเวลาที่ทำงานเสร็จ (EndTime). ตัวอย่าง 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| สกุลเงิน Currency | รหัสสกุลเงินของมูลค่าใบขอซื้อ. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุสกุลเงินของมูลค่าใบขอซื้อ เช่น USD, EUR หรือ JPY และให้บริบทที่จำเป็นสำหรับแอตทริบิวต์มูลค่าใบขอซื้อ โดยเฉพาะในองค์กรข้ามชาติที่ใช้หลายสกุลเงิน. การวิเคราะห์และรายงานทางการเงินให้ถูกต้องจำเป็นต้องคำนึงถึงสกุลเงิน เมื่อนำมูลค่าใบขอซื้อมารวมหรือเปรียบเทียบ ควรแปลงจำนวนเงินทั้งหมดเป็นสกุลเงินเดียวกันเพื่อให้ได้ผลลัพธ์ที่มีความหมาย แอตทริบิวต์นี้เป็นข้อมูลที่จำเป็นสำหรับการแปลงดังกล่าว. เหตุผลที่สำคัญ ให้บริบทที่จำเป็นสำหรับมูลค่าใบขอซื้อ ช่วยให้วิเคราะห์และเปรียบเทียบข้อมูลทางการเงินได้ถูกต้องในสภาพแวดล้อมที่ใช้หลายสกุลเงิน. แหล่งข้อมูล ข้อมูลนี้อยู่ในตาราง EBAN ฟิลด์ WAERS. ตัวอย่าง USDEURGBP | |||
| เหตุผลที่ปฏิเสธ RejectionReason | เหตุผลที่ระบุเมื่อมีการปฏิเสธใบขอซื้อ. | ||
| คำอธิบาย เหตุผลที่ปฏิเสธอธิบายว่าทำไมผู้อนุมัติจึงปฏิเสธใบขอซื้อ เช่น ใช้งบประมาณเกิน ข้อมูลไม่ถูกต้อง ไม่เป็นไปตามนโยบาย หรือเป็นคำขอซ้ำ ข้อมูลนี้ให้บริบทสำคัญในการทำความเข้าใจปัญหาของกระบวนการ. การวิเคราะห์เหตุผลที่ปฏิเสธช่วยค้นหาสาเหตุหลักของความไม่มีประสิทธิภาพและการทำงานซ้ำ ตัวอย่างเช่น หาก 'ศูนย์ต้นทุนไม่ถูกต้อง' เป็นเหตุผลที่พบบ่อย แสดงว่าควรฝึกอบรมผู้ใช้หรือเพิ่มการตรวจสอบในระบบ แอตทริบิวต์นี้เป็นข้อมูลหลักของแดชบอร์ดวิเคราะห์การปฏิเสธใบขอซื้อ และจำเป็นต่อการปรับปรุงกระบวนการให้ตรงจุด. เหตุผลที่สำคัญ ช่วยระบุสาเหตุหลักของปัญหาในกระบวนการ ทำให้ปรับปรุงได้ตรงจุด ลดการทำงานซ้ำ และเพิ่มอัตราการทำใบขอซื้อให้ถูกต้องตั้งแต่ครั้งแรก. แหล่งข้อมูล โดยทั่วไปไม่มีฟิลด์มาตรฐานสำหรับข้อมูลนี้ อาจบันทึกไว้ในองค์ประกอบของ workflow container ข้อความยาวที่เชื่อมกับใบขอซื้อ หรือฟิลด์ที่ปรับแต่งเอง. ตัวอย่าง เกินงบประมาณผู้ขายไม่ถูกต้องคำขอซ้ำ | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาประทับที่ระบุว่าข้อมูลของระเบียนนี้ได้รับการรีเฟรชจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงหรืออัปเดตข้อมูลจากระบบต้นทางครั้งล่าสุด เป็นข้อมูลกำกับที่สำคัญสำหรับตรวจสอบว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด นักวิเคราะห์และผู้ใช้ทางธุรกิจอาศัยเวลาประทับนี้เพื่อดูว่าข้อมูลกระบวนการสะท้อนสถานะการปฏิบัติการล่าสุดหรือไม่. การทราบว่าข้อมูลเป็นปัจจุบันเพียงใดเป็นพื้นฐานของการวิเคราะห์กระบวนการและการตัดสินใจอย่างมีข้อมูล แอตทริบิวต์นี้ช่วยให้ผู้ใช้เข้าใจสถานะของข้อมูล และมั่นใจได้ว่าข้อสรุปมาจากข้อมูลที่ใหม่พอสำหรับการวิเคราะห์นั้นๆ. เหตุผลที่สำคัญ แสดงความใหม่ของข้อมูล ซึ่งสำคัญต่อความน่าเชื่อถือของผลวิเคราะห์และการตัดสินใจทางธุรกิจได้ทันท่วงที. แหล่งข้อมูล ระบบสร้างและเพิ่มเวลาประทับนี้ระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL). ตัวอย่าง 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
กิจกรรมของกระบวนการจัดซื้อจนถึงชำระเงิน: คำขอซื้อ
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| ปฏิเสธใบขอซื้อ | ระบุการปฏิเสธใบขอซื้อขั้นสุดท้ายโดยผู้อนุมัติ ซึ่งทำให้กระบวนการหยุดลง ระบบบันทึกเหตุการณ์นี้ด้วยการอัปเดตสถานะที่ระบุว่าปฏิเสธ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดที่แสดงความล้มเหลว การวิเคราะห์ความถี่ เหตุผล และขั้นตอนที่มีการปฏิเสธช่วยให้พบปัญหาเกี่ยวกับการปฏิบัติตามนโยบาย งบประมาณ หรือคุณภาพของคำขอ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในตาราง EBAN โดยกำหนดสถานะการดำเนินการ (PROCSTAT) หรือตัวบ่งชี้การอนุมัติเป็นค่าที่หมายถึง 'ปฏิเสธ' โดยตรง. บันทึก ระบุเวลาที่สถานะโดยรวมใน EBAN เปลี่ยนเป็น 'ปฏิเสธ' โดยตรวจสอบเอกสารการเปลี่ยนแปลง. ประเภทเหตุการณ์ inferred | |||
| ปิดใบขอซื้อ | ระบุว่าดำเนินการกับรายการใบขอซื้อเสร็จสมบูรณ์แล้ว และไม่สามารถสร้างใบสั่งซื้อเพิ่มเติมจากรายการนี้ได้ โดยทั่วไปสถานะนี้จะถูกกำหนดโดยอัตโนมัติเมื่อสั่งซื้อครบตามจำนวน. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นการสิ้นสุดวงจรชีวิตของรายการใบขอซื้ออย่างสมบูรณ์และสำเร็จ ยืนยันว่าความต้องการทางธุรกิจได้รับการดำเนินการเป็นคำสั่งซื้อแล้ว. แหล่งข้อมูล อนุมานจากตาราง EBAN เมื่อกำหนดตัวบ่งชี้ 'ปิดแล้ว' (EBAKZ) ซึ่งมักเกิดขึ้นเมื่อจำนวนที่สั่งซื้อในใบสั่งซื้อเท่ากับจำนวนในใบขอซื้อ. บันทึก ค้นหาเหตุการณ์ที่กำหนดตัวบ่งชี้ 'ปิดแล้ว' (EBAKZ) ในตาราง EBAN โดยตรวจสอบเอกสารการเปลี่ยนแปลง. ประเภทเหตุการณ์ inferred | |||
| สร้างใบขอซื้อ | ระบุจุดเริ่มต้นที่มีการสร้างเอกสารใบขอซื้อในระบบ ระบบจะบันทึกเหตุการณ์นี้เมื่อผู้ใช้บันทึกใบขอซื้อใหม่เป็นครั้งแรก พร้อมบันทึกวันและเวลาที่สร้าง. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นหลักสำหรับวิเคราะห์วงจรชีวิตของใบขอซื้อ และจำเป็นต่อการวัดระยะเวลาตั้งแต่เริ่มระบุความต้องการจนถึงอนุมัติขั้นสุดท้ายหรือแปลงเป็นใบสั่งซื้อ. แหล่งข้อมูล เหตุการณ์นี้บันทึกไว้โดยตรงในตาราง EBAN โดยใช้ฟิลด์วันที่สร้าง (ERDAT) และเวลาที่สร้าง (ERZEIT) ของเลขที่ใบขอซื้อ (BANFN). บันทึก ใช้ฟิลด์วันและเวลาที่สร้าง (ERDAT, ERZEIT) จากตาราง EBAN สำหรับใบขอซื้อแต่ละรายการ (BANFN). ประเภทเหตุการณ์ explicit | |||
| สร้างใบสั่งซื้อ | ระบุว่ามีการสร้างใบสั่งซื้อที่อ้างอิงถึงรายการใบขอซื้อ เหตุการณ์นี้บันทึกไว้โดยตรงในระบบและเชื่อมใบขอซื้อกับเอกสารจัดซื้อที่สร้างต่อจากนั้น. | ||
| เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญและผลลัพธ์ที่สำเร็จของกระบวนการใบขอซื้อ ระยะเวลาตั้งแต่อนุมัติใบขอซื้อจนถึงสร้างใบสั่งซื้อเป็น KPI สำคัญสำหรับวัดประสิทธิภาพการจัดซื้อ. แหล่งข้อมูล บันทึกเหตุการณ์นี้โดยตรงเมื่อสร้างรายการใบสั่งซื้อ โดยเก็บลิงก์ไว้ในตาราง EKPO (รายการใบสั่งซื้อ) ซึ่งมีเลขที่ใบขอซื้อที่มา (BANFN) และเลขที่รายการ (BNFPO). บันทึก เชื่อมตาราง EKPO กลับไปยัง EBAN ด้วยเลขที่ใบขอซื้อและเลขที่รายการ วันที่สร้างรายการใบสั่งซื้อเป็นวันที่เกิดเหตุการณ์. ประเภทเหตุการณ์ explicit | |||
| เสร็จสิ้นขั้นตอนการอนุมัติ | เกิดขึ้นเมื่อผู้อนุมัติดำเนินการอนุมัติใบขอซื้อ ซึ่งเป็นการเสร็จสิ้นหนึ่งขั้นตอนในเวิร์กโฟลว์อนุมัติหลายระดับ อนุมานจากการเปลี่ยนแปลงสถานะการอนุมัติของใบขอซื้อ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ช่วยให้วิเคราะห์เวิร์กโฟลว์การอนุมัติได้อย่างละเอียด โดยวัดเวลาที่ใช้ในแต่ละขั้นตอน และช่วยแยกผู้อนุมัติที่ดำเนินการได้รวดเร็วออกจากจุดที่เป็นคอขวด. แหล่งข้อมูล อนุมานจากเอกสารการเปลี่ยนแปลง (CDHDR/CDPOS) ของตาราง EBAN การเปลี่ยนสถานะรหัสอนุมัติ เช่น ในฟิลด์ FRGZU จากยังไม่อนุมัติเป็นอนุมัติแล้วสำหรับรหัสที่ระบุ ถือเป็นเหตุการณ์นี้. บันทึก ติดตามการเปลี่ยนแปลงฟิลด์สถานะการอนุมัติใน EBAN สำหรับรหัสอนุมัติแต่ละรหัสที่กำหนดไว้ในกลยุทธ์. ประเภทเหตุการณ์ inferred | |||
| อนุมัติใบขอซื้อแล้ว | ระบุว่าใบขอซื้อได้รับอนุมัติครบถ้วนขั้นสุดท้ายแล้ว และพร้อมแปลงเป็นใบสั่งซื้อ อนุมานจากสถานะการอนุมัติโดยรวมที่เปลี่ยนเป็นสถานะอนุมัติขั้นสุดท้าย. | ||
| เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญที่แสดงความสำเร็จ และมักใช้เป็นจุดสิ้นสุดในการวิเคราะห์ระยะเวลาดำเนินการ หมายความว่าใบขอซื้อผ่านการตรวจสอบทั้งหมดและพร้อมให้ฝ่ายจัดซื้อดำเนินการ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในตาราง EBAN โดยเฉพาะเมื่อมีการปรับตัวบ่งชี้การอนุมัติโดยรวม (FRGZU) หรือสถานะการดำเนินการ (PROCSTAT) เป็นค่า 'อนุมัติแล้ว' ขั้นสุดท้าย. บันทึก ระบุเวลาที่กำหนดรหัสอนุมัติขั้นสุดท้าย หรือเวลาที่สถานะโดยรวมของใบขอซื้อเปลี่ยนเป็น 'อนุมัติแล้ว'. ประเภทเหตุการณ์ inferred | |||
| กำหนดแหล่งจัดหา | ระบุการดำเนินการที่ผู้ซื้อกำหนดผู้ขาย สัญญา หรือระเบียนข้อมูลให้กับรายการใบขอซื้อที่อนุมัติแล้ว ขั้นตอนนี้ช่วยเตรียมใบขอซื้อสำหรับสร้างใบสั่งซื้อ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เชื่อมขั้นตอนอนุมัติกับการสั่งซื้อ การวัดเวลาที่ใช้ในการกำหนดแหล่งจัดหาช่วยให้เห็นความล่าช้าในภาระงานของผู้ซื้อและประสิทธิภาพการจัดหา. แหล่งข้อมูล อนุมานจากการกรอกข้อมูลในฟิลด์ที่เกี่ยวข้องกับแหล่งจัดหาในตาราง EBAN เช่น ผู้ขายที่กำหนดไว้ (LIFNR) ระเบียนข้อมูล (INFNR) หรือสัญญา (KONNR). บันทึก ติดตามการกรอกข้อมูลในฟิลด์ เช่น LIFNR, INFNR หรือ KONNR ในตาราง EBAN ผ่านเอกสารการเปลี่ยนแปลง. ประเภทเหตุการณ์ inferred | |||
| แก้ไขใบขอซื้อ | เกิดขึ้นเมื่อผู้ใช้แก้ไขฟิลด์สำคัญของใบขอซื้อหลังจากสร้างแล้ว เช่น จำนวน ราคา หรือวัสดุ การแก้ไขนี้จะถูกบันทึกไว้อย่างชัดเจนในระบบเอกสารการเปลี่ยนแปลงของ SAP. | ||
| เหตุผลที่สำคัญ การติดตามการแก้ไขช่วยระบุการทำงานซ้ำและผลกระทบต่อระยะเวลาดำเนินการ หากมีการแก้ไขบ่อยครั้ง อาจสะท้อนปัญหาคุณภาพข้อมูลหรือความต้องการที่เปลี่ยนแปลง ซึ่งเป็นประเด็นสำคัญสำหรับการปรับปรุงกระบวนการ. แหล่งข้อมูล บันทึกการเปลี่ยนแปลงที่ทำกับตาราง EBAN ไว้โดยตรงในตารางเอกสารการเปลี่ยนแปลงของ SAP (CDHDR และ CDPOS) การเปลี่ยนแปลงแต่ละครั้งในฟิลด์ที่ติดตามจะสร้างรายการใหม่. บันทึก ดึงเหตุการณ์การเปลี่ยนแปลงจาก CDHDR/CDPOS โดยเลือก object class เป็น BANF สำหรับใบขอซื้อ. ประเภทเหตุการณ์ explicit | |||
| ถอนใบขอซื้อ | เกิดขึ้นเมื่อผู้ขอเดิมยกเลิกหรือลบใบขอซื้อก่อนดำเนินการเสร็จ โดยทั่วไปเป็นการดำเนินการโดยตรงที่กำหนดแฟล็กการลบให้กับรายการใบขอซื้อ. | ||
| เหตุผลที่สำคัญ การติดตามการถอนใบขอซื้อช่วยให้เข้าใจความผันผวนของความต้องการและสาเหตุการยกเลิก โดยถือเป็นสถานะสิ้นสุดของใบขอซื้อและไม่สามารถดำเนินการต่อได้. แหล่งข้อมูล บันทึกเหตุการณ์นี้โดยตรงเมื่อกำหนดฟิลด์ตัวบ่งชี้การลบ (LOEKZ) ในตาราง EBAN ให้กับรายการใบขอซื้อ การเปลี่ยนแปลงจะถูกบันทึกใน CDHDR/CDPOS. บันทึก ค้นหาเหตุการณ์ที่กำหนดตัวบ่งชี้การลบ (LOEKZ) ในตาราง EBAN เป็น 'L'. ประเภทเหตุการณ์ explicit | |||
| รีเซ็ตการอนุมัติ | ระบุเหตุการณ์ที่รีเซ็ตเวิร์กโฟลว์การอนุมัติทั้งหมด ซึ่งมักเกิดจากการแก้ไขใบขอซื้อครั้งสำคัญ ทำให้ต้องเริ่มกระบวนการอนุมัติใหม่ตั้งแต่ระดับแรก. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้แสดงให้เห็นการทำงานซ้ำครั้งสำคัญที่ส่งผลต่อระยะเวลาดำเนินการอย่างมาก การหาสาเหตุที่ทำให้ต้องรีเซ็ตการอนุมัติเป็นกุญแจสำคัญในการปรับกระบวนการให้กระชับและลดความล่าช้า. แหล่งข้อมูล อนุมานจากเอกสารการเปลี่ยนแปลง (CDHDR/CDPOS) ในตาราง EBAN โดยตรวจพบเหตุการณ์นี้เมื่อฟิลด์สถานะการอนุมัติ เช่น FRGKZ หรือ FRGZU ถูกล้าง หลังจากมีการกำหนดสถานะบางส่วนหรือทั้งหมดแล้ว. บันทึก ค้นหาการเปลี่ยนแปลงสถานะการอนุมัติจากสถานะอนุมัติแล้วกลับเป็นยังไม่อนุมัติในบันทึกการเปลี่ยนแปลง. ประเภทเหตุการณ์ inferred | |||
| เริ่มขั้นตอนการอนุมัติ | ระบุว่าใบขอซื้อกำลังรอการดำเนินการจากผู้อนุมัติหรือกลุ่มผู้อนุมัติรายใดรายหนึ่ง อนุมานจากสถานะของใบขอซื้อที่แสดงว่ารอรหัสอนุมัติที่ระบุ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้จำเป็นต่อการระบุคอขวดในลำดับการอนุมัติ การวิเคราะห์ระยะเวลาที่ใบขอซื้ออยู่ในสถานะนี้ช่วยให้พบรายการที่ค้างและผู้อนุมัติที่มีงานล้นมือ. แหล่งข้อมูล อนุมานจากฟิลด์สถานะการอนุมัติในตาราง EBAN เช่น FRGZU และการตั้งค่ากลยุทธ์การอนุมัติที่เกี่ยวข้อง เหตุการณ์เริ่มเมื่อรหัสอนุมัติที่ระบุเป็นรหัสถัดไปที่ต้องดำเนินการ. บันทึก ระบุเวลาที่ใบขอซื้อเข้าสู่สถานะรออนุมัติจากรหัสอนุมัติที่ระบุ โดยอ้างอิงจากบันทึกเวิร์กโฟลว์หรือฟิลด์สถานะ. ประเภทเหตุการณ์ inferred | |||
| ส่งใบขอซื้อเพื่ออนุมัติ | ระบุเวลาที่ผู้ขอส่งใบขอซื้ออย่างเป็นทางการ ซึ่งเป็นการเริ่มเวิร์กโฟลว์การอนุมัติ โดยทั่วไปอนุมานจากการกำหนดกลยุทธ์การอนุมัติของใบขอซื้อและสถานะที่เปลี่ยนเป็น 'อยู่ระหว่างอนุมัติ'. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้เป็นหมุดหมายสำคัญที่ใช้เริ่มนับระยะเวลาการอนุมัติสำหรับ KPI การวิเคราะห์เวลาตั้งแต่สร้างจนส่งใบขอซื้อช่วยให้เห็นความล่าช้าในขั้นตอนเตรียมใบขอซื้อ. แหล่งข้อมูล อนุมานจากเอกสารการเปลี่ยนแปลง (CDHDR/CDPOS) ของตาราง EBAN โดยดูเมื่อมีการกรอกฟิลด์กลยุทธ์การอนุมัติ เช่น FRGST หรือเมื่อสถานะโดยรวม (PROCSTAT) เปลี่ยนเป็นสถานะระหว่างอนุมัติ. บันทึก ค้นหารายการแรกในเอกสารการเปลี่ยนแปลงที่แสดงว่าเวิร์กโฟลว์การอนุมัติเริ่มต้นขึ้น หรือสถานะเปลี่ยนเป็น 'อยู่ระหว่างอนุมัติ'. ประเภทเหตุการณ์ inferred | |||
คู่มือการสกัดข้อมูล
ขั้นตอน
- ข้อกำหนดเบื้องต้น: ตรวจสอบว่าคุณมีบัญชีผู้ใช้ที่ได้รับสิทธิ์เหมาะสมใน SAP S/4HANA เพื่อเข้าถึง CDS view ที่จำเป็น โดยทั่วไปต้องมีสิทธิ์สำหรับออบเจ็กต์ เช่น S_TABU_NAM และสิทธิ์ใช้เครื่องมือแสดงข้อมูล
- เลือกวิธีเข้าถึงระบบ: กำหนดวิธีเชื่อมต่อฐานข้อมูล SAP S/4HANA เพื่อเรียกใช้คำสั่ง SQL เครื่องมือที่ใช้ได้ เช่น SAP HANA Studio, Eclipse IDE พร้อม ADT (ABAP Development Tools) หรือไคลเอนต์ SQL จากผู้ให้บริการภายนอก เช่น DBeaver ที่เชื่อมต่อผ่านไคลเอนต์ฐานข้อมูล SAP HANA ได้
- ตรวจสอบคำสั่ง SQL: ทำความเข้าใจกับสคริปต์ SQL ที่ให้มา สคริปต์ใช้ Common Table Expressions (CTE) เพื่อรวบรวมข้อมูลของกิจกรรมต่างๆ แล้วรวมเข้าด้วยกันเป็นบันทึกเหตุการณ์ชุดเดียว
- แก้ค่าตัวอย่าง: ค้นหาและแทนที่ค่าตัวอย่างในคำสั่งค้นหา กำหนดช่วงวันที่ในรูปแบบ
[YYYY-MM-DD]สำหรับช่วงเวลาที่ต้องการดึงข้อมูล และระบุรหัสบริษัทที่เกี่ยวข้อง ([Your Company Code]) ขององค์กร - เรียกใช้คำสั่งค้นหา: เรียกใช้คำสั่ง SQL ฉบับสมบูรณ์ที่ปรับแก้แล้วกับฐานข้อมูล SAP S/4HANA ระยะเวลาที่ใช้ขึ้นอยู่กับปริมาณข้อมูลและช่วงวันที่ที่เลือก
- ตรวจสอบข้อมูลเบื้องต้น: เมื่อคำสั่งค้นหาทำงานเสร็จ ให้ตรวจสอบข้อมูลสองสามแถวแรก ดูว่าทุกคอลัมน์ เช่น PurchaseRequisitionId, ActivityName และ EventTime มีข้อมูลตามที่คาดไว้ และรูปแบบข้อมูลถูกต้อง
- จัดการการแปลงข้อมูล: คำสั่งค้นหาที่ให้มาออกแบบให้ส่งออกข้อมูลในรูปแบบที่พร้อมใช้กับ process mining โดยใช้ฟังก์ชัน
CASTและCONCATเพื่อให้ชนิดข้อมูลสอดคล้องกัน จึงไม่จำเป็นต้องแปลงข้อมูลเพิ่มเติมมากนักหลังเรียกใช้คำสั่ง - ส่งออกบันทึกเหตุการณ์: ส่งออกผลลัพธ์ทั้งหมดจากไคลเอนต์ SQL เป็นไฟล์ CSV และตั้งค่าการเข้ารหัสไฟล์เป็น UTF-8 เพื่อป้องกันปัญหาเกี่ยวกับอักขระ
- เตรียมไฟล์สำหรับอัปโหลด: ก่อนอัปโหลดไปยังเครื่องมือ process mining ให้ตรวจสอบว่าไฟล์ CSV มีหัวคอลัมน์ถูกต้อง เช่น
PurchaseRequisitionId,ActivityName,EventTimeและรูปแบบวันที่กับเวลาของEventTimeสอดคล้องกันและรองรับโดยแพลตฟอร์มปลายทาง - อัปโหลดไปยัง ProcessMind: อัปโหลดไฟล์ CSV ที่เตรียมไว้ไปยังโปรเจกต์ ProcessMind ตั้งค่าโปรเจกต์โดยกำหนด
PurchaseRequisitionIdเป็นรหัสเคส,ActivityNameเป็นกิจกรรม และEventTimeเป็นการประทับเวลา
การกำหนดค่า
- CDS View หลัก: การดึงข้อมูลใช้
I_PurchaseRequisitionAPI01เป็นหลักสำหรับข้อมูลคำขอซื้อ ใช้I_ChangeDocumentและI_ChangeDocumentItemติดตามการเปลี่ยนแปลงและการอัปเดตสถานะ และใช้I_PurchaseOrderItemAPI01เชื่อมโยงกับใบสั่งซื้อ - สิทธิ์การเข้าถึง: ผู้เรียกใช้ต้องมีสิทธิ์อ่าน CDS view ที่กล่าวถึง โปรดปรึกษาทีมรักษาความปลอดภัย SAP เพื่อกำหนดบทบาทและสิทธิ์ที่จำเป็น
- การกรองช่วงวันที่: ควรกำหนดตัวกรองช่วงวันที่สร้างคำขอซื้อ (
CreationDate) เพื่อลดปริมาณข้อมูล แนะนำให้เริ่มวิเคราะห์จากข้อมูลย้อนหลัง 3 ถึง 6 เดือน - การกรองตามองค์กร: กรองข้อมูลด้วย
CompanyCodeเพื่อวิเคราะห์กระบวนการของหน่วยงานธุรกิจที่ถูกต้อง คุณอาจกรองด้วยPurchaseRequisitionTypeเพิ่มเติม เพื่อเน้นกระบวนการจัดซื้อบางประเภท เช่น สินค้าทั่วไปหรือบริการ - การตั้งค่าเอกสารการเปลี่ยนแปลง: การบันทึกกิจกรรมอย่าง 'แก้ไขคำขอซื้อ' และขั้นตอนอนุมัติต่าง ๆ ขึ้นอยู่กับการเปิดใช้บันทึกเอกสารการเปลี่ยนแปลงสำหรับฟิลด์ที่เกี่ยวข้องในระบบ SAP หากไม่พบเหตุการณ์เหล่านี้ ให้ตรวจสอบการตั้งค่าระบบสำหรับตาราง EBAN
- ประสิทธิภาพ: หากระบบมีคำขอซื้อหลายล้านรายการ การเรียกใช้ query กับข้อมูลช่วงยาวอาจกระทบประสิทธิภาพระบบ ควรเรียกใช้ในช่วงที่มีการใช้งานน้อย หรือในระบบที่ไม่ใช่ระบบจริงซึ่งมีข้อมูลอัปเดตล่าสุด.
ตัวอย่างคำค้น sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' ขั้นตอน
- ตรวจสอบว่ามีสิทธิ์อ่านโดยตรงใน schema ของ SAP HANA ที่มี EBAN และ EBKN และระบุออบเจ็กต์เอกสารการเปลี่ยนแปลงและเอกสารจัดซื้อที่ระบบใช้สำหรับการแก้ไขคำขอซื้อ การดำเนินการอนุมัติ การกำหนดแหล่งจัดซื้อ การอ้างอิงใบสั่งซื้อ และการปิดรายการ เนื่องจากออบเจ็กต์และฟิลด์เหล่านี้อาจต่างกันตามรุ่นและการตั้งค่า ให้แทนค่าตัวแปรในวงเล็บเหลี่ยมแต่ละรายการใน query ด้วยออบเจ็กต์หรือฟิลด์ที่ตรงกับระบบของคุณ
- ใน SAP GUI ใช้ธุรกรรม SE16H หรือเครื่องมือจัดการฐานข้อมูลที่ได้รับอนุมัติเพื่อตรวจสอบ EBAN และ EBKN ยืนยันฟิลด์คีย์ของคำขอซื้อ และตรวจสอบฟิลด์วันที่ เวลา ผู้ใช้ สถานะ การลบ การอนุมัติ การกำหนดบัญชี และการอ้างอิงเอกสารจัดซื้อที่มีอยู่ ใช้ SE11 หรือพจนานุกรมข้อมูล SAP เพื่อตรวจสอบคำจำกัดความของฟิลด์ อย่าเปิดเผยข้อมูลระบบจริงระหว่างทดสอบ
- ระบุแหล่งเอกสารการเปลี่ยนแปลงที่ตั้งค่าไว้สำหรับการแก้ไขคำขอซื้อและการเปลี่ยนแปลงการอนุมัติ query ต้องใช้แหล่งข้อมูลการเปลี่ยนแปลงที่ปรับรูปแบบแล้วชื่อ [Your requisition change document source] ซึ่งมีฟิลด์หมายเลขคำขอซื้อ หมายเลขรายการ ฟิลด์ที่เปลี่ยน ค่าเดิม ค่าใหม่ วันที่เปลี่ยน เวลาเปลี่ยน และผู้ใช้ ก่อนเรียกใช้ ให้เชื่อมแหล่งนี้กับตารางเอกสารการเปลี่ยนแปลงหรือ CDS view ที่เกี่ยวข้องในระบบของคุณ
- ระบุแหล่ง workflow หรือการอนุมัติที่ตั้งค่าไว้สำหรับการส่งคำขอ การรีเซ็ตการอนุมัติ การเริ่มขั้นตอนอนุมัติ การอนุมัติขั้นตอน การอนุมัติขั้นสุดท้าย และการปฏิเสธ query ต้องใช้ [Your requisition approval event source] ซึ่งมีหนึ่งแถวต่อการเปลี่ยนสถานะหรือการอนุมัติ และมีฟิลด์หมายเลขคำขอซื้อ หมายเลขรายการ ประเภทเหตุการณ์ รหัสการอนุมัติหรือกลุ่มผู้อนุมัติ ผู้อนุมัติ วันที่เกิดเหตุการณ์ เวลาเกิดเหตุการณ์ และสถานะ เชื่อมแหล่งนี้กับข้อมูลการอนุมัติหรือ workflow ที่ระบบ S/4HANA ของคุณใช้
- ระบุแหล่งข้อมูลการกำหนดแหล่งจัดซื้อ การอ้างอิงใบสั่งซื้อ และการปิดรายการ query ต้องใช้ [Your requisition source assignment source], [Your requisition purchase order reference source] และ [Your requisition closure source] ให้เชื่อมตัวแปรเหล่านี้กับตารางหรือ view ที่ได้รับอนุมัติในระบบ การสร้างใบสั่งซื้อต้องอ้างอิงอย่างชัดเจนจากรายการใบสั่งซื้อไปยังรายการคำขอซื้อ ห้ามอนุมานจากกิจกรรมจัดซื้ออื่นที่ไม่เกี่ยวข้อง
- กำหนดช่วงดึงข้อมูลด้วย [Start date] และ [End date] แนะนำให้เริ่มจากช่วง 3 ถึง 6 เดือน ขยายช่วงได้หลังตรวจสอบประสิทธิภาพฐานข้อมูลและปริมาณเหตุการณ์แล้ว query จะกรองวันที่สร้างและวันที่เกิดเหตุการณ์ พร้อมใช้รหัสคำขอซื้อเป็นรหัสเคส
- เรียกใช้ query ด้วย SQL client ที่ได้รับอนุมัติและเชื่อมต่อกับ SAP HANA แทนเฉพาะรายละเอียดการเชื่อมต่อที่อยู่นอก query พารามิเตอร์วันที่ ตัวกรองเฉพาะบริษัท และตัวแปรแหล่งข้อมูลกับฟิลด์ที่ระบุไว้อย่างชัดเจน คงชื่อคอลัมน์ผลลัพธ์ให้ตรงตามนี้ทุกประการ: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount และ RequisitionStatus
- ตรวจสอบเหตุการณ์ซ้ำ ความละเอียดของเวลาประทับ การจัดการเขตเวลา และระดับรายละเอียดว่าเป็นระดับรายการหรือเอกสาร query จะสร้างรหัสเคสระดับเอกสารและเก็บบริบทของรายการไว้ภายใน หากมีหลายรายการที่มีกิจกรรมและเวลาประทับเดียวกัน ให้เก็บแยกเป็นคนละแถว เว้นแต่การออกแบบใน ProcessMind ของคุณกำหนดให้ตัดรายการซ้ำโดยเฉพาะ
- ตรวจสอบว่ากิจกรรมที่จำเป็นปรากฏเป็นค่า ActivityName ทุกกิจกรรม มี EventTime และลำดับเวลาสมเหตุสมผล และรหัสเคสที่จำเป็นไม่เป็นค่าว่าง เปรียบเทียบจำนวนกับรายงาน SAP หรือข้อมูลการปฏิบัติการที่ได้รับอนุมัติในช่วงวันที่เดียวกัน
- ส่งออกผลลัพธ์เป็นไฟล์ CSV ที่เข้ารหัส UTF-8 หรือรูปแบบตารางอื่นที่ ProcessMind รองรับ ใส่แถวหัวตาราง ใช้เวลาประทับที่สอดคล้องกับ ISO เก็บค่าว่างเป็นช่องว่าง และอัปโหลดไฟล์โดยกำหนด PurchaseRequisitionId เป็นรหัสเคส ActivityName เป็นคอลัมน์กิจกรรม และ EventTime เป็นคอลัมน์เวลาประทับ.
การกำหนดค่า
- รหัสเคส: ใช้หมายเลขเอกสารคำขอซื้อจาก EBAN โดยกำหนดเป็น PurchaseRequisitionId หากตั้งค่ากระบวนการในระดับรายการ ให้ใช้คีย์ผสมที่มีเอกสารกำกับ เช่น หมายเลขคำขอซื้อและหมายเลขรายการ และใช้คีย์เดียวกันกับทุกเหตุการณ์
- แหล่งข้อมูลหลัก: ใช้ EBAN สำหรับข้อมูลรายการคำขอซื้อ และใช้ EBKN สำหรับข้อมูลการกำหนดบัญชีและรายละเอียดหน่วยงานหรือศูนย์ต้นทุน ตรวจสอบชื่อฟิลด์และชนิดข้อมูลที่แน่นอนในพจนานุกรมข้อมูล SAP ก่อนเรียกใช้
- แหล่งเหตุการณ์: query ใช้ตัวแปรแทนแหล่งข้อมูลการเปลี่ยนแปลง การอนุมัติ การกำหนดแหล่งจัดซื้อ การอ้างอิงใบสั่งซื้อ และการปิดรายการโดยตั้งใจ เนื่องจากแหล่งข้อมูลเหล่านี้ขึ้นอยู่กับรุ่น S/4HANA การออกแบบ workflow ขั้นตอนการอนุมัติ ฟังก์ชันธุรกิจที่เปิดใช้ และส่วนขยายของลูกค้า
- ช่วงวันที่: เริ่มจาก 3 ถึง 6 เดือน หากมีฟิลด์วันที่ที่จัดทำดัชนีหรือช่วยตัดพาร์ทิชันได้ ให้กำหนดช่วงวันที่แบบจำกัด สำหรับการโหลดข้อมูลเพิ่ม ให้ช่วงเวลาที่ดึงข้อมูลซ้อนทับกันเพียงพอเพื่อเก็บการเปลี่ยนแปลงที่มาถึงล่าช้า จากนั้นตัดรายการซ้ำโดยใช้เคส กิจกรรม เวลาประทับ รายการ และคีย์เหตุการณ์จากแหล่งข้อมูล
- ตัวกรองทางธุรกิจ: กำหนด [Company code filter], [Document type filter], [Purchasing group filter] และ [Plant filter] เฉพาะเมื่อมีฟิลด์เหล่านี้และยืนยันความหมายทางธุรกิจแล้ว อย่ากรองตามสถานะหากต้องการเก็บข้อมูลตลอดวงจร
- การจับคู่สถานะ: กำหนดค่าของ In Approval, final approved, rejected, reset, pending release code และ closed ให้ตรงกับกลยุทธ์การอนุมัติหรือการตั้งค่า workflow ในระบบเป้าหมาย อย่าคิดว่ารหัสสถานะเดียวกันใช้ได้กับ SAP ทุกระบบ
- การจับคู่การแก้ไข: รวมการเปลี่ยนแปลงปริมาณ ราคา วัสดุ วันที่ส่งมอบ การกำหนดบัญชี และฟิลด์อื่นที่กระบวนการของคุณถือเป็นฟิลด์สำคัญ query มีเงื่อนไขเฉพาะสำหรับฟิลด์สำคัญที่ระบุไว้ และแหล่งข้อมูลต้องแสดงชื่อฟิลด์ที่เปลี่ยนแปลง
- การจัดการเวลาประทับ: รวมวันที่และเวลาเกิดเหตุการณ์โดยใช้เขตเวลาของฐานข้อมูล แล้วบันทึกการแปลงเป็น UTC หากแหล่งข้อมูลมีเพียงวันที่ ให้ใช้เวลาเที่ยงคืนเฉพาะเมื่อไม่มีเวลาที่ละเอียดกว่านี้ และบันทึกข้อจำกัดดังกล่าวไว้
- ประสิทธิภาพ: จำกัดการดึงข้อมูลครั้งแรกด้วยวันที่และขอบเขตธุรกิจ เลือกเฉพาะคอลัมน์ที่จำเป็น หลีกเลี่ยงการ join ประวัติการเปลี่ยนแปลงหรือ workflow ขนาดใหญ่โดยไม่มีตัวกรอง และตรวจสอบแผนการทำงานของ HANA หากต้องดึงข้อมูลซ้ำ ให้จัดเก็บแหล่งเหตุการณ์ที่ปรับรูปแบบแล้วไว้ในตารางชั่วคราวหรือพื้นที่ staging
- สิทธิ์และข้อกำหนดเบื้องต้น: ขอสิทธิ์อ่าน EBAN, EBKN, แหล่งข้อมูลการเปลี่ยนแปลงและ workflow ที่ตั้งค่าไว้ ข้อมูลการกำหนดแหล่งจัดซื้อ ข้อมูลอ้างอิงใบสั่งซื้อ และข้อมูลการปิดรายการ ยืนยันว่าได้รับอนุมัติให้เข้าถึงฐานข้อมูลโดยตรง เปิดใช้ฟังก์ชันจัดซื้อและ workflow ที่เกี่ยวข้องแล้ว และมีไลเซนส์ฐานข้อมูล SAP HANA หรือเครื่องมือจัดการที่จำเป็น
- ความปลอดภัย: กำหนดสิทธิ์เข้าถึงเท่าที่จำเป็น ปกป้องรหัสผู้ใช้และผู้อนุมัติ และปฏิบัติตามกฎขององค์กรในการดึงข้อมูลจัดซื้อและข้อมูลการเงิน.
ตัวอย่างคำค้น sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เตรียมข้อมูลได้อย่างมั่นใจ และนำ process mining มาใช้วิเคราะห์กระบวนการจัดซื้อจนถึงชำระเงินในส่วนของคำขอซื้อ เริ่มปรับกระบวนการให้มีประสิทธิภาพขึ้นได้เลย!
หยุดความล่าช้าของคำขอซื้อ P2P ด้วยการปรับ workflow ให้มีประสิทธิภาพ!
ปรับกระบวนการให้คล่องตัว ลดระยะเวลาดำเนินการ และลดรอบเวลาลง 30%.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายใน 5 นาที.