เทมเพลตข้อมูลสำหรับกระบวนการคืนสินค้าและคืนเงินของคุณ
เทมเพลตข้อมูลสำหรับกระบวนการคืนสินค้าและคืนเงินของคุณ
- แอตทริบิวต์ที่แนะนำให้เก็บรวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางการดึงข้อมูล
คุณลักษณะของกระบวนการรับคืนสินค้าและคืนเงิน
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อของกิจกรรมทางธุรกิจหรือเหตุการณ์ที่เกิดขึ้นในกระบวนการคืนสินค้าและคืนเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้อธิบายขั้นตอนหรือหมุดหมายหนึ่งในวงจรการคืนสินค้า กิจกรรมแสดงถึงงานที่เกิดขึ้น เช่น 'อนุมัติใบสั่งคืนสินค้า' หรือ 'ตรวจสอบสินค้าเสร็จแล้ว' ข้อมูลเหล่านี้ได้มาจากการเปลี่ยนสถานะ การสร้างเอกสาร หรือการดำเนินการของผู้ใช้ที่บันทึกไว้ใน SAP S/4HANA. การวิเคราะห์ลำดับและความถี่ของกิจกรรมเป็นหัวใจของ process mining ช่วยแสดงแผนผังกระบวนการ ระบุเส้นทางที่เกิดขึ้นบ่อยหรือไม่บ่อย และค้นหากิจกรรมที่ทำซ้ำบ่อย ซึ่งอาจบ่งชี้ถึงการแก้ไขงานหรือจุดที่ไม่มีประสิทธิภาพ. เหตุผลที่สำคัญ กิจกรรมเป็นองค์ประกอบหลักของแผนผังกระบวนการ ช่วยให้เห็นภาพและวิเคราะห์ลำดับงาน คอขวด และความแตกต่างของกระบวนการได้. แหล่งข้อมูล โดยทั่วไปชื่อกิจกรรมได้มาจากข้อมูลหลายประเภท เช่น การเปลี่ยนสถานะเอกสารในตารางอย่าง VBUK/VBUP เหตุการณ์การสร้างเอกสารในตารางส่วนหัวอย่าง VBAK (เอกสารการขาย) และ BKPF (เอกสารบัญชี) รวมถึงสถานะการเคลื่อนย้ายสินค้าใน MSEG. ตัวอย่าง เริ่มคำขอคืนสินค้ารับสินค้าเข้าคลังสินค้าสร้างใบลดหนี้ดำเนินการคืนเงินแล้ว | |||
| รหัสกรณีคืนสินค้า ReturnCaseId | รหัสเฉพาะของกระบวนการคืนสินค้าแต่ละรายการ ซึ่งเชื่อมโยงกิจกรรมทั้งหมดตั้งแต่เริ่มต้นจนถึงปิดเรื่อง. | ||
| คำอธิบาย รหัสกรณีคืนสินค้าเป็นรหัสหลักที่ใช้จัดกลุ่มเหตุการณ์และกิจกรรมทั้งหมดของการคืนสินค้าแต่ละรายการ คำขอคืนสินค้าของลูกค้าแต่ละรายการจะได้รับรหัสเฉพาะ ทำให้ติดตามกระบวนการได้ตั้งแต่ต้นจนจบ. ใน process mining แอตทริบิวต์นี้เป็นข้อมูลพื้นฐานสำหรับสร้างลำดับกระบวนการขึ้นใหม่ โดยเชื่อมเหตุการณ์ต่างๆ เช่น 'เริ่มคำขอคืนสินค้า' 'รับสินค้าเข้าคลังสินค้า' และ 'ดำเนินการคืนเงินแล้ว' ให้เป็นลำดับเวลาของการคืนสินค้าแต่ละรายการ จึงวิเคราะห์ระยะเวลาของกรณี รูปแบบกระบวนการ และคอขวดได้. เหตุผลที่สำคัญ นี่คือคีย์สำคัญสำหรับติดตามการคืนสินค้าตั้งแต่ต้นจนจบ และใช้วิเคราะห์ข้อมูลระดับกรณีได้ทั้งหมด รวมถึงเวลาของกระบวนการและการค้นหารูปแบบกระบวนการ. แหล่งข้อมูล โดยทั่วไปคือหมายเลขเอกสารการขาย (VBELN) จากตารางส่วนหัวใบสั่งคืนสินค้า VBAK โดยหมวดหมู่เอกสาร (VBTYP) ระบุว่าเป็นรายการคืนสินค้า. ตัวอย่าง 600001896000019060000191 | |||
| เวลาเกิดเหตุการณ์ EventTime | เวลาที่ระบุอย่างแม่นยำว่ากิจกรรมหนึ่งเกิดขึ้นเมื่อใด. | ||
| คำอธิบาย เวลาเกิดเหตุการณ์บันทึกวันที่และเวลาที่ระบบบันทึกเหตุการณ์ทางธุรกิจ ข้อมูลเวลานี้สำคัญต่อการเรียงกิจกรรมตามลำดับเวลาและการวิเคราะห์ที่อิงกับเวลา. ใน process mining ใช้แอตทริบิวต์นี้คำนวณระยะเวลาระหว่างกิจกรรม ระบุเวลาที่ใช้ในแต่ละขั้นตอน และวิเคราะห์ประสิทธิภาพของกระบวนการตามช่วงเวลา ข้อมูลนี้เป็นพื้นฐานสำหรับค้นหาคอขวด ติดตามการปฏิบัติตาม SLA และทำความเข้าใจการเปลี่ยนแปลงด้านเวลาของกระบวนการคืนสินค้า. เหตุผลที่สำคัญ เวลานี้จำเป็นต่อการเรียงลำดับเหตุการณ์ คำนวณระยะเวลาและเวลาของกระบวนการทั้งหมด รวมถึงระบุความล่าช้า. แหล่งข้อมูล โดยทั่วไปได้มาจากฟิลด์วันที่และเวลาที่เกี่ยวข้องกับการสร้างเอกสารหรือการเปลี่ยนสถานะ เช่น ERDAT (วันที่สร้าง) และ ERZET (เวลาที่สร้าง) ในตารางอย่าง VBAK, LIKP และ BKPF หรือวันที่ลงรายการ (BUDAT) ในเอกสารบัญชี. ตัวอย่าง 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| รหัสระบบต้นทาง SourceSystemId | รหัสของระบบต้นทางที่ใช้ดึงข้อมูล. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุระบบบันทึกข้อมูลต้นทางของเหตุการณ์ สำหรับกระบวนการนี้ โดยทั่วไปคือรหัสอินสแตนซ์ SAP S/4HANA. ในสภาพแวดล้อมที่มีหลายระบบ ฟิลด์นี้สำคัญต่อการติดตามที่มาของข้อมูล การแก้ไขปัญหา และการรักษาความถูกต้องของข้อมูล ช่วยแยกข้อมูลเมื่อมีการดำเนินการคืนสินค้าผ่านระบบ ERP หลายอินสแตนซ์ หรือเชื่อมต่อกับระบบภายนอก เช่น ระบบจัดการคลังสินค้า. เหตุผลที่สำคัญ ให้ข้อมูลสำคัญเกี่ยวกับแหล่งที่มาและเส้นทางของข้อมูล โดยเฉพาะในสภาพแวดล้อมที่มีหลายระบบ ช่วยให้ตรวจสอบย้อนกลับและเชื่อถือข้อมูลได้. แหล่งข้อมูล โดยปกติค่าดังกล่าวจะคงที่และกำหนดไว้ระหว่างการดึงข้อมูล สามารถดูได้จากข้อมูลการดูแลระบบ SAP เช่น System ID (SID). ตัวอย่าง S4H_PROD_100S4Q_DEV_200 | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdateTimestamp | เวลาที่ระบุว่ามีการรีเฟรชหรือดึงข้อมูลของเหตุการณ์นี้ครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงหรืออัปเดตข้อมูลครั้งล่าสุด เป็นข้อมูลกำกับที่บอกว่าชุดข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลใหม่เพียงใด. ข้อมูลนี้ช่วยให้เข้าใจว่าการวิเคราะห์ process mining เป็นปัจจุบันแค่ไหน ผู้ใช้ตรวจสอบได้ว่าข้อมูลล่าสุดเพียงใด ซึ่งสำคัญเป็นพิเศษสำหรับการติดตามการปฏิบัติการและแดชบอร์ดที่แสดงกรณีที่กำลังดำเนินอยู่. เหตุผลที่สำคัญ แสดงความใหม่ของข้อมูล ซึ่งสำคัญต่อการทำให้มั่นใจว่าการวิเคราะห์และแดชบอร์ดอ้างอิงข้อมูลล่าสุด. แหล่งข้อมูล โดยทั่วไปเครื่องมือ ETL หรือไปป์ไลน์ข้อมูลจะสร้างและประทับเวลานี้ลงในชุดข้อมูลขณะดึงข้อมูล. ตัวอย่าง 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| จำนวนเงินคืน RefundAmount | มูลค่าเงินคืนสุดท้ายที่จ่ายให้ลูกค้า. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงจำนวนเงินจริงที่ให้เครดิตหรือคืนแก่ลูกค้าเมื่อกระบวนการคืนสินค้าเสร็จสิ้น โดยบันทึกไว้ในเอกสารทางการเงิน เช่น ใบลดหนี้. นี่คือตัวชี้วัดทางการเงินสำคัญที่ใช้ในการวิเคราะห์หลายด้าน จำเป็นสำหรับแดชบอร์ด 'วิเคราะห์ส่วนต่างของจำนวนเงินคืน' เพื่อเปรียบเทียบกับยอดที่ร้องขอ และยังช่วยแบ่งกลุ่มการคืนสินค้าตามมูลค่า เพื่อดูว่ากรณีที่มีมูลค่าสูงมีขั้นตอนต่างออกไปหรือใช้เวลาแก้ไขนานกว่าหรือไม่. เหตุผลที่สำคัญ ติดตามผลกระทบทางการเงินจากการคืนสินค้า และจำเป็นต่อการวิเคราะห์ความถูกต้องของยอดคืนเงิน ระบุกรณีมูลค่าสูง และทำความเข้าใจต้นทุนโดยรวม. แหล่งข้อมูล ได้จากฟิลด์มูลค่าสุทธิ (NETWR) ของเอกสารใบลดหนี้ ซึ่งอยู่ในตารางอย่าง VBRK (ส่วนหัวเอกสารการเรียกเก็บเงิน) หรือ BSEG (รายการเอกสารบัญชี). ตัวอย่าง 125.50999.0049.99 | |||
| ชื่อผู้ใช้ UserName | รหัสผู้ใช้ของพนักงานที่ดำเนินกิจกรรม. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุผู้ใช้หรือระบบที่รับผิดชอบงาน เช่น อนุมัติการคืนสินค้าหรือสร้างใบลดหนี้ ใน SAP มักบันทึกไว้ในฟิลด์ที่ระบุผู้สร้างหรือผู้แก้ไขเอกสาร. การวิเคราะห์ตามผู้ใช้ช่วยระบุบุคคลหรือทีมที่ทำงานได้ดี ความต้องการในการฝึกอบรม และการกระจายภาระงาน นอกจากนี้ยังช่วยตรวจสอบความเบี่ยงเบน โดยเชื่อมโยงการดำเนินการในกระบวนการกับผู้ใช้แต่ละราย เพื่อสนับสนุนการปฏิบัติตามข้อกำหนดและการตรวจสอบบัญชี. เหตุผลที่สำคัญ ระบุผู้ใช้ที่ดำเนินกิจกรรมแต่ละรายการ ทำให้วิเคราะห์ประสิทธิภาพของทีม ภาระงาน และการปฏิบัติตามข้อกำหนดได้. แหล่งข้อมูล มักพบในตารางส่วนหัวเอกสาร เช่น ERNAM (สร้างโดย) ใน VBAK (ใบสั่งขาย), LIKP (การส่งมอบ) และ BKPF (เอกสารบัญชี) สามารถเพิ่มรายละเอียดผู้ใช้จากตารางข้อมูลหลักผู้ใช้ USR21 ได้. ตัวอย่าง CBROWNASMITHWF_BATCH | |||
| รหัสลูกค้า CustomerId | รหัสเฉพาะของลูกค้าที่เริ่มคำขอคืนสินค้า. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุลูกค้าที่ขอคืนสินค้า และเชื่อมโยงกระบวนการแต่ละรายการกับบุคคลในข้อมูลหลักลูกค้า. การวิเคราะห์การคืนสินค้าตามลูกค้าช่วยค้นหารูปแบบ เช่น ลูกค้าที่มีอัตราการคืนสินค้าสูงผิดปกติ ซึ่งอาจบ่งชี้ถึงการฉ้อโกงหรือความไม่พอใจ นอกจากนี้ยังช่วยแบ่งกลุ่มกระบวนการคืนสินค้าตามประเภท มูลค่า หรือประวัติของลูกค้า เพื่อกำหนดระดับการบริการให้เหมาะสมได้. เหตุผลที่สำคัญ เชื่อมโยงรายการคืนสินค้ากับลูกค้าแต่ละราย ทำให้วิเคราะห์พฤติกรรม แบ่งกลุ่มลูกค้า และระบุลูกค้าที่คืนสินค้าบ่อยได้. แหล่งข้อมูล พบในฟิลด์หมายเลขลูกค้า (KUNNR) ของตารางส่วนหัวใบสั่งคืนสินค้า (VBAK). ตัวอย่าง CUST-001234CUST-005678CUST-009012 | |||
| รหัสสินค้า ProductId | รหัสเฉพาะของสินค้าที่ส่งคืน. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุวัสดุหรือสินค้าที่ถูกส่งคืน และเชื่อมโยงกระบวนการคืนสินค้ากับสินค้าเฉพาะในแค็ตตาล็อกสินค้า. การวิเคราะห์การคืนสินค้าตามสินค้าเป็นพื้นฐานสำคัญในการระบุสินค้าที่มีอัตราการคืนสูง ซึ่งอาจบ่งชี้ถึงข้อบกพร่องด้านคุณภาพ คำอธิบายสินค้าที่ไม่ชัดเจน หรือปัญหาในการผลิต ข้อมูลนี้ช่วยให้ธุรกิจตัดสินใจเรื่องการออกแบบสินค้า การจัดการซัพพลายเออร์ และกลยุทธ์สินค้าคงคลังได้อย่างมีข้อมูล. เหตุผลที่สำคัญ เชื่อมโยงกระบวนการคืนสินค้ากับสินค้าแต่ละรายการ ทำให้วิเคราะห์อัตราการคืนสินค้าและระบุปัญหาด้านคุณภาพหรือคำอธิบายสินค้าได้. แหล่งข้อมูล พบในฟิลด์หมายเลขวัสดุ (MATNR) ของตารางรายการใบสั่งคืนสินค้า (VBAP) หรือตารางรายการใบส่งคืนสินค้า (LIPS). ตัวอย่าง FG-10023HW-45981SW-LICENSE-PREM | |||
| เวลาสิ้นสุดเหตุการณ์ EventEndTime | เวลาที่ระบุว่ากิจกรรมเสร็จสิ้น ใช้คำนวณระยะเวลาที่ใช้ในกิจกรรม. | ||
| คำอธิบาย StartTime (EventTime) ระบุเวลาเริ่มต้นของกิจกรรม ส่วน EventEndTime ระบุเวลาสิ้นสุด สำหรับเหตุการณ์ที่ระบบสร้างขึ้นหลายประเภท เวลาเริ่มต้นและสิ้นสุดจะตรงกัน เพราะเกิดขึ้นทันที แต่สำหรับกิจกรรมที่มีระยะเวลาวัดได้ เช่น 'ตรวจสอบสินค้า' แอตทริบิวต์นี้มีความสำคัญ. แอตทริบิวต์นี้ช่วยคำนวณเวลาที่ใช้ดำเนินกิจกรรมแต่ละรายการได้โดยตรง ซึ่งเป็นพื้นฐานของการวิเคราะห์ประสิทธิภาพ และช่วยระบุว่าขั้นตอนใดใช้เวลามากที่สุด ไม่ใช่แค่ช่วงเวลาระหว่างขั้นตอน. เหตุผลที่สำคัญ ช่วยคำนวณระยะเวลาของแต่ละกิจกรรมได้อย่างแม่นยำ ซึ่งสำคัญต่อการระบุจุดที่ไม่มีประสิทธิภาพในขั้นตอนเฉพาะของกระบวนการ. แหล่งข้อมูล ค่านี้มักได้จากการคำนวณ บางกิจกรรมอาจมีฟิลด์แยกต่างหาก แต่โดยทั่วไปจะใช้ StartTime ของกิจกรรมถัดไปในกรณีเดียวกัน. ตัวอย่าง 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| เหตุผลในการคืนสินค้า ReturnReason | เหตุผลที่ลูกค้าแจ้งว่าต้องการคืนสินค้า. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกเหตุผลที่ลูกค้าแจ้งสำหรับการคืนสินค้า เช่น 'สินค้าชำรุด' 'ขนาดไม่ถูกต้อง' หรือ 'ไม่ต้องการแล้ว' โดยทั่วไปลูกค้าจะเลือกจากรายการรหัสเหตุผลที่กำหนดไว้ขณะเริ่มคำขอคืนสินค้า. การวิเคราะห์เหตุผลในการคืนสินค้าช่วยค้นหาปัญหาด้านคุณภาพ ปรับปรุงคำอธิบายสินค้า หรือพัฒนากระบวนการขาย ข้อมูลนี้แสดงสาเหตุที่ลูกค้าไม่พอใจโดยตรง และช่วยจัดลำดับเรื่องที่ควรปรับปรุงเพื่อลดอัตราการคืนสินค้าโดยรวม. เหตุผลที่สำคัญ ช่วยให้เข้าใจสาเหตุสำคัญของการคืนสินค้า และวิเคราะห์หาต้นตอเพื่อแก้ปัญหาคุณภาพสินค้า ข้อผิดพลาดในการจัดส่ง หรือความคาดหวังของลูกค้าที่ไม่ตรงกัน. แหล่งข้อมูล โดยทั่วไปจัดเก็บในฟิลด์ ABGRU (เหตุผลในการปฏิเสธเอกสารการขาย) ของตารางรายการใบสั่งขายคืนสินค้า (VBAP). ตัวอย่าง 001 - คุณภาพไม่ดี002 - เสียหายระหว่างขนส่ง005 - จัดส่งสินค้าผิดรายการ | |||
| การปฏิบัติตาม SLA การคืนเงิน RefundSlaAdherence | ตัวบ่งชี้ว่าดำเนินการคืนเงินภายในกำหนดเวลาตามข้อตกลงระดับการให้บริการ (SLA) หรือไม่. | ||
| คำอธิบาย แอตทริบิวต์ที่คำนวณขึ้นนี้ตรวจสอบว่ากิจกรรม «ดำเนินการคืนเงินแล้ว» เกิดขึ้นในวันที่หรือก่อน «วันที่เป้าหมายตาม SLA สำหรับการคืนเงิน» หรือไม่ โดยแสดงผลเป็นจริงหรือเท็จสำหรับการปฏิบัติตาม SLA ของแต่ละกรณี. นี่คือตัวชี้วัดหลักของแดชบอร์ด «ติดตามการปฏิบัติตาม SLA การคืนเงิน» และ KPI «อัตราการปฏิบัติตาม SLA การคืนเงิน» ช่วยวัดผลการดำเนินงานเทียบกับคำมั่นที่ให้ไว้กับลูกค้า และระบุกรณีที่ไม่เป็นไปตามเป้าหมาย เพื่อนำไปวิเคราะห์สาเหตุของความล่าช้า. เหตุผลที่สำคัญ วัดผลการดำเนินงานเทียบกับคำมั่นที่ให้ไว้กับลูกค้าโดยตรง จึงเป็นตัวชี้วัดสำคัญของคุณภาพการบริการและความพึงพอใจของลูกค้า. แหล่งข้อมูล คำนวณโดยเปรียบเทียบ EventTime ของกิจกรรม «ดำเนินการคืนเงินแล้ว» กับ «RefundSlaTargetDate» ของแต่ละกรณี. ตัวอย่าง truefalse | |||
| การปฏิบัติตามนโยบายการคืนสินค้า ReturnPolicyAdherence | ตัวบ่งชี้ว่ากรณีคืนสินค้าเป็นไปตามนโยบายการคืนสินค้าที่กำหนดหรือไม่. | ||
| คำอธิบาย แอตทริบิวต์แบบบูลีนที่คำนวณขึ้นนี้ระบุว่าการคืนสินค้าเป็นไปตามเกณฑ์ของนโยบายที่ใช้หรือไม่ ตัวอย่างเช่น ตรวจสอบว่ามีการเริ่มคืนสินค้าภายในระยะเวลาที่กำหนดหรือไม่ หรือเหตุผลในการคืนสินค้าใช้ได้กับสินค้าหรือไม่. แอตทริบิวต์นี้ช่วยให้แดชบอร์ด «ภาพรวมการปฏิบัติตามนโยบายการคืนสินค้า» แสดงอัตราการปฏิบัติตามข้อกำหนด และเจาะลึกลงหนึ่งระดับเพื่อดูกรณีที่ไม่เป็นไปตามข้อกำหนดและทำความเข้าใจสาเหตุ ช่วยให้บังคับใช้นโยบายได้อย่างมีประสิทธิภาพยิ่งขึ้น. เหตุผลที่สำคัญ ใช้วัดการปฏิบัติตามกฎทางธุรกิจ ช่วยระบุและลดการละเมิดนโยบายที่อาจกระทบต่อกำไรหรือทำให้เกิดกรณียกเว้นในกระบวนการ. แหล่งข้อมูล คำนวณตามกฎทางธุรกิจ ตัวอย่างเช่น (วันที่เริ่มคืนสินค้า - วันที่ซื้อเดิม) <= [จำนวนวันที่อนุญาตให้คืนสินค้า] โดยต้องมีวันที่ซื้อเดิมและกฎของนโยบาย. ตัวอย่าง truefalse | |||
| จำนวนเงินคืนที่ร้องขอ RequestedRefundAmount | จำนวนเงินคืนที่ร้องขอหรือคาดว่าจะได้รับในช่วงเริ่มต้นของกระบวนการ. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกมูลค่าสินค้าที่ส่งคืนตามคำขอคืนสินค้าเริ่มต้น และใช้เป็นยอดตั้งต้นสำหรับเปรียบเทียบกับจำนวนเงินคืนสุดท้าย. ฟิลด์นี้จำเป็นสำหรับแดชบอร์ด 'วิเคราะห์ส่วนต่างของจำนวนเงินคืน' การเปรียบเทียบยอดที่ร้องขอกับยอดคืนเงินจริงช่วยค้นหาปัญหา เช่น การคืนเงินบางส่วนเนื่องจากสินค้าเสียหาย ค่าธรรมเนียมการนำสินค้ากลับเข้าคลัง หรือการปรับยอดอื่นๆ เพื่อให้ข้อมูลทางการเงินถูกต้องและโปร่งใส. เหตุผลที่สำคัญ ใช้เป็นค่าอ้างอิงเพื่อวัดความถูกต้องของการคืนเงิน และช่วยค้นหาและวิเคราะห์ความแตกต่างระหว่างยอดคืนเงินที่คาดไว้กับยอดที่คืนจริง. แหล่งข้อมูล โดยทั่วไปใช้มูลค่าสุทธิของสินค้าในใบสั่งขายคืนสินค้าเริ่มต้น ซึ่งเป็นมูลค่าสุทธิ (NETWR) ของรายการที่เกี่ยวข้องในตาราง VBAP. ตัวอย่าง 125.501050.0049.99 | |||
| เจ้าหน้าที่ผู้ดำเนินการ ProcessingAgent | เจ้าหน้าที่หรือกลุ่มทรัพยากรที่รับผิดชอบกิจกรรมที่ต้องดำเนินการด้วยตนเองโดยเฉพาะ. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุบุคคลหรือทีมที่ทำงานนั้น โดยอาจระบุบทบาทหรือทีมให้ชัดเจนกว่าฟิลด์ «ชื่อผู้ใช้» โดยเฉพาะในหน่วยงานบริการส่วนกลาง. ข้อมูลนี้ช่วยวิเคราะห์ประสิทธิภาพของเจ้าหน้าที่หรือทีมต่างๆ ในแดชบอร์ด «ประสิทธิภาพการอนุมัติคืนเงิน» และช่วยให้เข้าใจการกระจายงาน ระบุความต้องการด้านการฝึกอบรม รวมถึงค้นหาเจ้าหน้าที่หรือทีมที่มีผลงานดีและมีแนวปฏิบัติที่เป็นประโยชน์. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพในระดับเจ้าหน้าที่หรือทีม จัดการปริมาณงาน ระบุโอกาสในการฝึกอบรม และเพิ่มประสิทธิภาพ. แหล่งข้อมูล ข้อมูลนี้อาจมีอยู่ในฟังก์ชัน SAP Business Partner หากมีการกำหนดเจ้าหน้าที่ไว้ หรืออาจอนุมานจากแผนกหรือบทบาทของผู้ใช้ในโครงสร้างองค์กรของฝ่ายทรัพยากรบุคคล. ตัวอย่าง ทีมสนับสนุนระดับ 1ทีมตรวจสอบคลังสินค้าฝ่ายการเงิน - เจ้าหนี้การค้า | |||
| ดำเนินการโดยอัตโนมัติหรือไม่ IsAutomated | ตัวบ่งชี้ว่ากิจกรรมดำเนินการโดยระบบหรือบุคคล. | ||
| คำอธิบาย แอตทริบิวต์แบบบูลีนนี้แยกกิจกรรมที่ระบบดำเนินการโดยอัตโนมัติ เช่น ผ่านเวิร์กโฟลว์หรืองานเบื้องหลัง ออกจากกิจกรรมที่ผู้ใช้ดำเนินการด้วยตนเอง. ข้อมูลนี้จำเป็นต่อการคำนวณ KPI «อัตราการอนุมัติคืนเงินอัตโนมัติ» และช่วยค้นหาโอกาสเพิ่มการทำงานอัตโนมัติ เมื่อกรองเฉพาะงานที่ทำด้วยตนเอง ธุรกิจจะมุ่งปรับปรุงกระบวนการในจุดที่ระบบอัตโนมัติช่วยเพิ่มความเร็ว ลดต้นทุน และเพิ่มความถูกต้องได้มากที่สุด. เหตุผลที่สำคัญ แยกงานที่ทำด้วยตนเองออกจากงานอัตโนมัติ ซึ่งสำคัญต่อการค้นหาโอกาสใช้ระบบอัตโนมัติและวัดผลของการเปลี่ยนผ่านสู่ดิจิทัล. แหล่งข้อมูล โดยทั่วไปคำนวณจากชื่อผู้ใช้ ตัวอย่างเช่น หากผู้ใช้คือ «WF_BATCH» หรือรหัสระบบอื่น ระบบจะระบุกิจกรรมนั้นว่าเป็นงานอัตโนมัติ. ตัวอย่าง truefalse | |||
| เป็นงานแก้ไขซ้ำหรือไม่ IsRework | ตัวบ่งชี้ว่ากิจกรรมในกรณีหนึ่งเป็นการทำซ้ำจากกิจกรรมก่อนหน้าหรือไม่. | ||
| คำอธิบาย แอตทริบิวต์แบบบูลีนที่คำนวณขึ้นนี้ระบุงานที่ต้องทำซ้ำ ซึ่งเกิดขึ้นเมื่อทำกิจกรรมเดิมมากกว่าหนึ่งครั้งในกรณีเดียวกัน เช่น ต้องตรวจสอบสินค้าซ้ำ หรือสร้างใบลดหนี้ ยกเลิก แล้วสร้างใหม่. แอตทริบิวต์นี้จำเป็นสำหรับแดชบอร์ด «วิเคราะห์งานแก้ไขซ้ำในกระบวนการคืนเงิน» และ KPI «อัตราการทำงานซ้ำ» ช่วยวัดความไม่มีประสิทธิภาพของกระบวนการ โดยชี้ให้เห็นกิจกรรมที่มักเกิดข้อผิดพลาดหรือต้องทำหลายครั้ง และระบุจุดที่ควรปรับปรุงการควบคุมหรือจัดฝึกอบรมเพิ่มเติม. เหตุผลที่สำคัญ ชี้ให้เห็นความไม่มีประสิทธิภาพและข้อผิดพลาดในกระบวนการด้วยการระบุงานที่ทำซ้ำ ช่วยให้ปรับปรุงได้ตรงจุดเพื่อลดงานสูญเปล่าและความล่าช้า. แหล่งข้อมูล โดยทั่วไปเครื่องมือ process mining จะคำนวณตัวบ่งชี้นี้เอง หรืออาจคำนวณไว้ล่วงหน้าในขั้นตอนแปลงข้อมูล โดยตรวจสอบว่าชื่อกิจกรรมเดียวกันเคยปรากฏก่อนหน้าในกรณีเดียวกันหรือไม่. ตัวอย่าง truefalse | |||
| ผลการตรวจสอบสินค้า ItemInspectionOutcome | ผลการตรวจสอบสินค้าที่ส่งคืนด้วยการตรวจสอบสภาพจริง. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกผลการตรวจสอบสินค้าหลังจากคลังสินค้าได้รับสินค้าแล้ว ผลที่พบบ่อย ได้แก่ «รับสินค้าแล้ว» «ปฏิเสธ - สินค้าเสียหาย» หรือ «รับสินค้าแล้ว - จำหน่ายต่อได้». ข้อมูลนี้ช่วยให้เข้าใจขั้นตอนถัดไปของกระบวนการ และใช้ตัดสินใจว่าจะคืนเงินเต็มจำนวน คืนเงินบางส่วน หรือไม่คืนเงิน การวิเคราะห์ผลตรวจสอบช่วยค้นหาสาเหตุที่ปฏิเสธสินค้า และให้ข้อมูลย้อนกลับเกี่ยวกับบรรจุภัณฑ์หรือผู้ให้บริการขนส่ง หากสินค้ามักเสียหายระหว่างขนส่ง. เหตุผลที่สำคัญ ช่วยอธิบายเหตุผลเบื้องหลังการอนุมัติหรือปฏิเสธการคืนเงิน พร้อมให้ข้อมูลเกี่ยวกับสภาพสินค้าและสาเหตุที่มีการปรับยอดคืนเงิน. แหล่งข้อมูล ข้อมูลนี้อาจบันทึกไว้ในล็อตตรวจสอบของโมดูลการจัดการคุณภาพ (QM) หรือเป็นสถานะหรือรหัสเหตุผลในรายการส่งคืนสินค้า (LIPS) และอาจอยู่ในฟิลด์ที่กำหนดเองด้วย. ตัวอย่าง รับสินค้าแล้ว - จำหน่ายต่อได้รับสินค้าแล้ว - รอปรับสภาพปฏิเสธ - ลูกค้าทำสินค้าเสียหายปฏิเสธ - ส่งคืนสินค้าผิดรายการ | |||
| รหัสนโยบายการคืนสินค้า ReturnPolicyId | รหัสระบุนโยบายการคืนสินค้าที่ใช้กับกรณีคืนสินค้านี้โดยเฉพาะ. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุนโยบายการคืนสินค้าหรือชุดกฎที่ใช้กับรายการนั้น นโยบายอาจแตกต่างกันตามประเภทสินค้า กลุ่มลูกค้า หรือระยะเวลานับจากวันที่ซื้อ. ข้อมูลนี้จำเป็นสำหรับแดชบอร์ด «ภาพรวมการปฏิบัติตามนโยบายการคืนสินค้า» เมื่อเชื่อมโยงแต่ละกรณีกับนโยบาย ระบบจะตรวจสอบการปฏิบัติตามกฎได้โดยอัตโนมัติ เช่น กำหนดเวลาคืนสินค้าหรือเงื่อนไขสภาพสินค้า และแจ้งกรณีที่ไม่เป็นไปตามข้อกำหนดเพื่อนำไปวิเคราะห์. เหตุผลที่สำคัญ ช่วยตรวจสอบการปฏิบัติตามกฎทางธุรกิจโดยอัตโนมัติ เพื่อให้มั่นใจว่าดำเนินการคืนสินค้าอย่างสม่ำเสมอและเป็นไปตามนโยบาย. แหล่งข้อมูล ฟิลด์นี้มักไม่มีมาให้เป็นมาตรฐานใน SAP และอาจต้องคำนวณจากตรรกะทางธุรกิจโดยใช้ข้อมูล เช่น ประเภทสินค้า ลูกค้า และวันที่ขาย หากมีการนำไปใช้ อาจจัดเก็บไว้ในฟิลด์ที่กำหนดเอง. ตัวอย่าง นโยบายมาตรฐาน 30 วันสินค้าอิเล็กทรอนิกส์ รับประกัน 90 วันสินค้าขายขาด มีตำหนิ | |||
| วันที่เป้าหมายตาม SLA สำหรับการคืนเงิน RefundSlaTargetDate | วันที่ควรดำเนินการคืนเงินสำหรับกรณีคืนสินค้าให้เสร็จสิ้น. | ||
| คำอธิบาย แอตทริบิวต์นี้กำหนดกำหนดเวลาตามข้อตกลงระดับการให้บริการ (SLA) สำหรับการคืนเงิน โดยปกติจะคำนวณจากกฎทางธุรกิจ เช่น จำนวนวันที่กำหนดหลังอนุมัติการคืนสินค้าหรือหลังได้รับสินค้า. ฟิลด์นี้เป็นข้อมูลพื้นฐานของแดชบอร์ด «ติดตามการปฏิบัติตาม SLA การคืนเงิน» และ KPI ที่เกี่ยวข้อง ช่วยติดตามกรณีที่เสี่ยงเกินกำหนดล่วงหน้าและวิเคราะห์สาเหตุที่แท้จริงของความล่าช้า ซึ่งจะช่วยเพิ่มความพึงพอใจของลูกค้า. เหตุผลที่สำคัญ ใช้เป็นค่าอ้างอิงในการวัดการปฏิบัติตาม SLA ช่วยติดตามผลการดำเนินงาน จัดลำดับความสำคัญของกรณีที่ค้างนาน และเพิ่มความพึงพอใจของลูกค้า. แหล่งข้อมูล ฟิลด์นี้แทบจะเป็นค่าที่คำนวณขึ้นเสมอ โดยใช้วันที่สำคัญ เช่น วันที่สร้างคำขอคืนสินค้า บวกกับระยะเวลาที่กำหนดตามกฎทางธุรกิจ ซึ่งอาจขึ้นอยู่กับปัจจัยอย่างประเภทลูกค้าหรือเหตุผลในการคืนสินค้า. ตัวอย่าง 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| สถานะใบสั่งคืนสินค้า ReturnOrderStatus | สถานะปัจจุบันโดยรวมของกรณีคืนสินค้า. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงสถานะโดยรวมของกรณีคืนสินค้า ณ เวลานั้น เช่น «เปิด» «กำลังดำเนินการ» หรือ «ปิด» โดยมักคำนวณจากหมุดหมายสำคัญล่าสุดที่เสร็จสิ้น. ข้อมูลนี้จำเป็นสำหรับแดชบอร์ด «สถานะปัจจุบันของกรณีคืนสินค้า» ซึ่งแสดงภาพรวมการปฏิบัติการของปริมาณงานและการกระจายกรณี ช่วยให้ผู้จัดการเห็นจำนวนกรณีในแต่ละขั้นตอน และจัดสรรทรัพยากรกับบริหารปริมาณงานได้เหมาะสมขึ้น. เหตุผลที่สำคัญ แสดงภาพรวมว่ากรณีแต่ละรายการอยู่ในขั้นตอนใด ซึ่งจำเป็นต่อแดชบอร์ดการปฏิบัติการที่ติดตามปริมาณงานและสถานะปัจจุบัน. แหล่งข้อมูล คำนวณจากฟิลด์สถานะในเอกสารที่เกี่ยวข้อง เช่น สถานะส่วนหัว (GBSTK) หรือสถานะรายการ (LFSTK) ในใบสั่งขาย (VBUK/VBUP) หรือเอกสารการส่งมอบที่เกี่ยวข้อง. ตัวอย่าง รอรับสินค้าเข้าคลังรอตรวจสอบสินค้ารอคืนเงินปิดแล้ว | |||
| หมายเลขใบลดหนี้ CreditMemoNumber | รหัสเฉพาะของเอกสารใบลดหนี้ ซึ่งใช้อนุมัติการคืนเงิน. | ||
| คำอธิบาย ใบลดหนี้คือเอกสารการเรียกเก็บเงินที่ใช้บันทึกเครดิตเข้าบัญชีลูกค้าอย่างเป็นทางการสำหรับสินค้าที่ส่งคืน แอตทริบิวต์นี้คือหมายเลขเฉพาะของเอกสารทางการเงินดังกล่าว. การติดตามหมายเลขใบลดหนี้จำเป็นต่อการวิเคราะห์ขั้นตอนการชำระบัญชีทางการเงินของกระบวนการคืนสินค้า เป็นหมุดหมายสำคัญที่มักทำให้เริ่มจ่ายเงินจริง และจำเป็นต่อการกระทบยอดและตรวจสอบบัญชีการเงิน. เหตุผลที่สำคัญ หมายถึงธุรกรรมทางการเงินอย่างเป็นทางการสำหรับการคืนเงิน สำคัญต่อการติดตามขั้นตอนสุดท้ายของกระบวนการและการตรวจสอบบัญชีการเงิน. แหล่งข้อมูล คือหมายเลขเอกสารการเรียกเก็บเงิน (VBELN) จากตารางส่วนหัวเอกสารการเรียกเก็บเงิน (VBRK) โดยหมวดหมู่เอกสารระบุว่าเป็นใบลดหนี้. ตัวอย่าง 900003459000034690000347 | |||
| หมายเลขใบส่งคืนสินค้า ReturnDeliveryNumber | รหัสเฉพาะของเอกสารใบส่งคืนสินค้า. | ||
| คำอธิบาย เมื่อลูกค้าส่งสินค้าคืนจริง ระบบ SAP จะสร้างเอกสารใบส่งคืนสินค้าเพื่อจัดการโลจิสติกส์ขาเข้า แอตทริบิวต์นี้คือหมายเลขเฉพาะของเอกสารดังกล่าว. รหัสนี้สำคัญต่อการติดตามการเคลื่อนย้ายสินค้าคืนจริง และเชื่อมโยงข้อมูลด้านการเงินกับโลจิสติกส์ ช่วยวิเคราะห์ขั้นตอนรับสินค้าและตรวจสอบสินค้าได้อย่างละเอียด. เหตุผลที่สำคัญ เชื่อมโยงใบสั่งคืนสินค้ากับการรับสินค้าจริง ซึ่งสำคัญต่อการวิเคราะห์โลจิสติกส์และเวลาที่ใช้ดำเนินการในคลังสินค้า. แหล่งข้อมูล คือหมายเลขเอกสารการส่งมอบ (VBELN) จากตารางส่วนหัวการส่งมอบ (LIKP) โดยหมวดหมู่เอกสารระบุว่าเป็นใบส่งคืนสินค้า. ตัวอย่าง 840000128400001384000014 | |||
| องค์กรฝ่ายขาย SalesOrganization | หน่วยงานที่รับผิดชอบการขายเดิมและการคืนสินค้า. | ||
| คำอธิบาย องค์กรฝ่ายขายเป็นองค์ประกอบสำคัญของโครงสร้างองค์กรใน SAP หมายถึงหน่วยงานที่รับผิดชอบการขายและจัดจำหน่ายสินค้าและบริการ โดยกำหนดให้กับธุรกรรมการคืนสินค้า. แอตทริบิวต์นี้ช่วยกรองและเปรียบเทียบกระบวนการคืนสินค้าระหว่างหน่วยธุรกิจ ภูมิภาค หรือแผนกต่างๆ และช่วยตรวจสอบว่าองค์กรฝ่ายขายใดมีอัตราการคืนสินค้าสูง หรือจัดการการคืนสินค้าได้ไม่มีประสิทธิภาพ เพื่อใช้วิเคราะห์ผลการดำเนินงานขององค์กร. เหตุผลที่สำคัญ ช่วยเปรียบเทียบประสิทธิภาพและอัตราการคืนสินค้าระหว่างหน่วยธุรกิจ ภูมิภาค หรือช่องทางการขายต่างๆ. แหล่งข้อมูล พบในฟิลด์องค์กรฝ่ายขาย (VKORG) ของตารางส่วนหัวใบสั่งคืนสินค้า (VBAK). ตัวอย่าง 10002100US01 | |||
กิจกรรมในกระบวนการรับคืนสินค้าและคืนเงิน
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| ดำเนินการคืนเงินแล้ว | กิจกรรมนี้เป็นขั้นตอนสุดท้ายของกระบวนการคืนเงิน เมื่อชำระล้างเครดิตทางการเงินแล้ว แสดงว่ามีการส่งเงินให้ลูกค้า โดยอนุมานจากการสร้างเอกสารชำระล้างในโมดูลการเงิน ซึ่งใช้ปิดยอดเครดิตคงค้างในบัญชีลูกค้า. | ||
| เหตุผลที่สำคัญ นี่คือเวลาที่ลูกค้าได้รับเงินจริง ระยะเวลาตั้งแต่เริ่มคำขอคืนสินค้าจนถึงขั้นตอนนี้ส่งผลอย่างมากต่อความพึงพอใจของลูกค้า และเป็นตัวชี้วัดสำคัญในการติดตามการปฏิบัติตาม SLA. แหล่งข้อมูล อนุมานจากข้อมูลเอกสารชำระล้างในตารางรายการบัญชีการเงิน BSEG วันที่ชำระล้าง (BSEG-AUGDT) ในรายการบัญชีลูกค้าที่เชื่อมโยงกับใบลดหนี้ใช้ระบุวันที่ดำเนินการคืนเงิน. บันทึก อนุมานจากการมีการระบุวันที่ชำระล้างในฟิลด์ของเอกสารบัญชีที่เชื่อมโยงกับใบลดหนี้. ประเภทเหตุการณ์ inferred | |||
| ตรวจสอบสินค้าเสร็จสิ้น | หมายถึงการประเมินคุณภาพและสภาพของสินค้าคืนเสร็จสิ้น ใน Advanced Returns Management ขั้นตอนนี้มักบันทึกผลการตรวจสอบโดยตรง และใช้กำหนดการดำเนินการถัดไป เช่น คืนเงินหรือตัดจำหน่ายสินค้า. | ||
| เหตุผลที่สำคัญ ระยะเวลาและผลการตรวจสอบส่งผลโดยตรงต่อเวลาที่ใช้ดำเนินการคืนเงินและการจัดการสินค้าคงคลัง กิจกรรมนี้จึงสำคัญต่อการวิเคราะห์ประสิทธิภาพการตรวจสอบและการแก้ไขงาน. แหล่งข้อมูล ใน SAP Advanced Returns Management (ARM) อาจบันทึกเหตุการณ์นี้โดยตรงจากธุรกรรมการตรวจสอบ หรืออนุมานจากการเปลี่ยนสถานะของรายการใบสั่งคืนสินค้าที่ระบุผลการตรวจสอบ. บันทึก บันทึกจากบันทึกธุรกรรมหรือการเปลี่ยนสถานะที่เกี่ยวข้องกับกิจกรรมติดตามงานด้านโลจิสติกส์ใน ARM. ประเภทเหตุการณ์ explicit | |||
| ปิดกรณีคืนสินค้า | นี่คือกิจกรรมสุดท้าย หมายถึงกระบวนการคืนสินค้าเสร็จสมบูรณ์และไม่มีงานอื่นที่ต้องดำเนินการต่อ โดยทั่วไปอนุมานเมื่อเอกสารใบสั่งคืนสินค้ามีสถานะปิดขั้นสุดท้ายในระบบ. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้กำหนดจุดสิ้นสุดของวงจรกระบวนการ ทำให้คำนวณเวลารวมตั้งแต่ต้นจนจบได้ และยืนยันว่าดำเนินการเรื่องนี้เสร็จสมบูรณ์แล้ว. แหล่งข้อมูล อนุมานจากสถานะโดยรวมของใบสั่งคืนสินค้าในตาราง VBAK หรือรายการใน VBAP เมื่อเปลี่ยนเป็นสถานะ 'เสร็จสมบูรณ์' หรือ 'ปิดแล้ว' โดยพิจารณาตามการตั้งค่าการจัดการสถานะของระบบ. บันทึก อนุมานจากการเปลี่ยนสถานะเอกสารใบสั่งคืนสินค้าเป็น 'เสร็จสมบูรณ์'. ประเภทเหตุการณ์ inferred | |||
| รับสินค้าเข้าคลังสินค้า | เหตุการณ์นี้หมายถึงคลังสินค้าหรือศูนย์ดำเนินการได้รับสินค้าคืนแล้ว ระบบบันทึกเหตุการณ์เมื่อมีการลงรายการรับสินค้า (PGR) สำหรับใบส่งคืนสินค้า ซึ่งจะสร้างเอกสารวัสดุขึ้น. | ||
| เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญที่เริ่มนับเวลาสำหรับการตรวจสอบและตัดสินใจจัดการสินค้า ความล่าช้าก่อนถึงขั้นตอนนี้เกิดจากลูกค้า ส่วนความล่าช้าหลังจากนี้เกิดจากภายในองค์กร. แหล่งข้อมูล บันทึกจากตารางเอกสารวัสดุ MSEG และ MKPF สำหรับประเภทการเคลื่อนไหวรับสินค้าที่เกี่ยวข้องกับการคืนสินค้า วันที่ลงรายการ (MKPF-BUDAT) ใช้ระบุเวลาของเหตุการณ์. บันทึก เหตุการณ์นี้ตรงกับการลงรายการรับสินค้าสำหรับใบส่งคืนสินค้า. ประเภทเหตุการณ์ explicit | |||
| เริ่มคำขอคืนสินค้า | นี่คือจุดเริ่มต้นของกระบวนการคืนสินค้า เมื่อสร้างใบสั่งคืนสินค้าอย่างเป็นทางการในระบบ ระบบจะบันทึกเหตุการณ์นี้เมื่อบันทึกเอกสารการขายใหม่ที่มีประเภทเอกสารเป็นใบสั่งคืนสินค้าใน SAP S/4HANA. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นอย่างเป็นทางการของวงจรการดำเนินการคืนสินค้า การวิเคราะห์ระยะเวลาตั้งแต่เหตุการณ์นี้จนถึงปิดเรื่องช่วยวัดเวลารวมของกระบวนการคืนสินค้าและประเมินประสบการณ์ของลูกค้าได้. แหล่งข้อมูล ระบบบันทึกเหตุการณ์นี้โดยตรงเมื่อสร้างเอกสารการขายในตาราง VBAK โดยหมวดหมู่เอกสาร (VBAK-VBTYP) ระบุว่าเป็นใบสั่งคืนสินค้า ส่วนเวลาที่สร้างระบุใน VBAK-ERDAT. บันทึก ระบบบันทึกเหตุการณ์เมื่อบันทึกใบสั่งขายคืนสินค้าใหม่ เช่น ผ่านธุรกรรม VA01. ประเภทเหตุการณ์ explicit | |||
| สร้างคำขอใบลดหนี้ | หลังตรวจสอบสินค้าเรียบร้อย กิจกรรมนี้หมายถึงการสร้างคำขอออกเครดิตให้ลูกค้า ระบบบันทึกเป็นเอกสารการขายใหม่ประเภทคำขอใบลดหนี้ ซึ่งอ้างอิงใบสั่งคืนสินค้าเดิม. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้เป็นจุดเริ่มต้นของการชำระบัญชีทางการเงินในกระบวนการคืนสินค้า การวิเคราะห์ระยะเวลาตั้งแต่ตรวจสอบสินค้าจนถึงขั้นตอนนี้ช่วยให้เห็นประสิทธิภาพในการส่งต่องานจากฝ่ายโลจิสติกส์ไปยังฝ่ายการเงิน. แหล่งข้อมูล บันทึกจากการสร้างเอกสารการขายในตาราง VBAK โดยมีหมวดหมู่เอกสารเป็นคำขอใบลดหนี้ ลิงก์ไปยังรายการคืนสินค้าเก็บไว้ในตารางลำดับเอกสาร VBFA. บันทึก ระบบบันทึกเหตุการณ์เมื่อบันทึกเอกสารคำขอใบลดหนี้ใหม่. ประเภทเหตุการณ์ explicit | |||
| สร้างใบลดหนี้ | นี่คือการสร้างเอกสารการเรียกเก็บเงินอย่างเป็นทางการ เพื่อบันทึกเครดิตเข้าบัญชีลูกค้าสำหรับสินค้าที่คืน ระบบบันทึกเหตุการณ์นี้เมื่อสร้างใบลดหนี้จากคำขอใบลดหนี้. | ||
| เหตุผลที่สำคัญ การสร้างใบลดหนี้เป็นหมุดหมายสำคัญทางการเงิน เพราะยืนยันยอดเงินที่จะคืนและอนุมัติให้เริ่มขั้นตอนการจ่ายเงิน. แหล่งข้อมูล บันทึกจากการสร้างเอกสารการเรียกเก็บเงินในตาราง VBRK โดยหมวดหมู่เอกสารระบุว่าเป็นใบลดหนี้ เอกสารนี้เชื่อมโยงกับคำขอใบลดหนี้ในตาราง VBFA. บันทึก ระบบบันทึกเหตุการณ์เมื่อบันทึกเอกสารการเรียกเก็บเงินประเภทใบลดหนี้ใหม่ เช่น ผ่านธุรกรรม VF01. ประเภทเหตุการณ์ explicit | |||
| ปฏิเสธการคืนสินค้า | หมายถึงสินค้าคืนไม่เป็นไปตามเกณฑ์ของนโยบายการคืนสินค้า และคำขอคืนเงินหรือออกเครดิตถูกปฏิเสธ โดยทั่วไปบันทึกเหตุการณ์นี้ด้วยสถานะหรือรหัสเหตุผลเฉพาะที่กำหนดให้กับรายการใบสั่งคืนสินค้าหลังการตรวจสอบ. | ||
| เหตุผลที่สำคัญ การติดตามรายการที่ถูกปฏิเสธช่วยวิเคราะห์การปฏิบัติตามนโยบายการคืนสินค้าและค้นหาเหตุผลที่พบบ่อย เหตุการณ์นี้เป็นเส้นทางกรณียกเว้นที่สำคัญในกระบวนการ. แหล่งข้อมูล อนุมานจากการกำหนดเหตุผลการปฏิเสธ (VBAP-ABGRU) ให้กับรายการใบสั่งคืนสินค้า หรือการกำหนดสถานะเฉพาะระหว่างการตรวจสอบใน Advanced Returns Management. บันทึก อนุมานจากการกำหนดเหตุผลการปฏิเสธหรือสถานะ 'ปฏิเสธแล้ว' ให้กับรายการเอกสารคืนสินค้า. ประเภทเหตุการณ์ inferred | |||
| สร้างใบส่งคืนสินค้า | กิจกรรมนี้หมายถึงการสร้างเอกสารการส่งมอบขาเข้า ซึ่งใช้จัดการการรับสินค้าคืนจริง ระบบบันทึกเหตุการณ์เมื่อสร้างเอกสารการส่งมอบที่อ้างอิงใบสั่งคืนสินค้า. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้เป็นหมุดหมายสำคัญด้านโลจิสติกส์ ระยะเวลาตั้งแต่อนุมัติการคืนสินค้าจนถึงสร้างเอกสารการส่งมอบ แสดงให้เห็นว่าการแจ้งข้อมูลการคืนสินค้าไปยังคลังสินค้าหรือแผนกรับสินค้ามีประสิทธิภาพเพียงใด. แหล่งข้อมูล บันทึกจากการสร้างส่วนหัวเอกสารการส่งมอบในตาราง LIKP โดยเชื่อมโยงกับใบสั่งคืนสินค้าก่อนหน้าผ่านตารางลำดับเอกสาร VBFA. บันทึก ระบบบันทึกเหตุการณ์เมื่อบันทึกเอกสารการส่งมอบสินค้าคืนใหม่ เช่น ผ่านธุรกรรม VL01N. ประเภทเหตุการณ์ explicit | |||
| สร้างใบสั่งเปลี่ยนสินค้า | กิจกรรมนี้หมายถึงการแก้ไขปัญหาอีกแบบหนึ่ง โดยสร้างใบสั่งขายใหม่เพื่อส่งสินค้าทดแทนให้ลูกค้าแทนการคืนเงิน ระบบบันทึกเหตุการณ์นี้เมื่อสร้างใบสั่งขายใหม่ที่อ้างอิงรายการคืนสินค้าเดิม. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ช่วยแยกการคืนสินค้าเพื่อขอเงินคืนออกจากการคืนสินค้าเพื่อเปลี่ยนสินค้า ซึ่งมีขั้นตอนและผลลัพธ์ต่อลูกค้าต่างกัน จึงสำคัญต่อการวิเคราะห์รูปแบบกระบวนการ. แหล่งข้อมูล บันทึกจากการสร้างเอกสารการขายใหม่ใน VBAK ซึ่งเชื่อมโยงกับใบสั่งคืนสินค้าในตารางลำดับเอกสาร (VBFA). บันทึก ระบบบันทึกเหตุการณ์เมื่อบันทึกใบสั่งขายใหม่ที่ระบุว่าเป็นสินค้าทดแทน. ประเภทเหตุการณ์ explicit | |||
| สร้างเอกสารบัญชี | เหตุการณ์นี้เกิดขึ้นเมื่อบันทึกใบลดหนี้ลงในโมดูลบัญชีการเงินสำเร็จ ระบบจะสร้างรายการที่เกี่ยวข้องในบัญชีแยกประเภททั่วไป ทำให้เครดิตมีผลอย่างเป็นทางการทางบัญชี. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ยืนยันว่ามีการบันทึกเครดิตเข้าสู่ระบบการเงินแล้ว ระยะเวลาตั้งแต่สร้างใบลดหนี้จนถึงลงรายการบัญชีช่วยให้เห็นปัญหาที่อาจเกิดขึ้นระหว่างระบบเรียกเก็บเงินกับระบบการเงิน. แหล่งข้อมูล บันทึกจากการสร้างส่วนหัวเอกสารในตารางบัญชี BKPF ซึ่งเชื่อมโยงกับใบลดหนี้ใน VBRK (VBRK-BELNR). บันทึก ระบบบันทึกเหตุการณ์เมื่อลงรายการเอกสารการเรียกเก็บเงินในบัญชีการเงินสำเร็จ. ประเภทเหตุการณ์ explicit | |||
| อนุมัติใบสั่งคืนสินค้า | หมายถึงการอนุมัติหรือปล่อยใบสั่งคืนสินค้าอย่างเป็นทางการ เพื่อให้ดำเนินการในขั้นตอนถัดไปได้ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะที่ส่วนหัวหรือรายการของเอกสารการขาย ซึ่งแสดงว่าไม่มีการระงับรายการแล้ว. | ||
| เหตุผลที่สำคัญ ขั้นตอนการอนุมัติอาจทำให้เกิดความล่าช้าอย่างมาก การติดตามกิจกรรมนี้ช่วยระบุคอขวดในช่วงอนุมัติเบื้องต้นของกระบวนการคืนสินค้า. แหล่งข้อมูล อนุมานจากตารางจัดการสถานะหรือฟิลด์สถานะในตาราง VBAK หรือ VBAP โดยตรง การเปลี่ยนสถานะการอนุมัติหรือการนำบล็อกการส่งมอบออก (VBAP-LIFSP) อาจแสดงว่ามีการอนุมัติแล้ว. บันทึก อนุมานจากการเปลี่ยนฟิลด์สถานะที่ส่วนหัวหรือรายการของใบสั่งคืนสินค้า ซึ่งแสดงว่ามีการปล่อยหรืออนุมัติแล้ว. ประเภทเหตุการณ์ inferred | |||
คู่มือการดึงข้อมูล
ขั้นตอน
- ตรวจสอบข้อกำหนดเบื้องต้น: ตรวจสอบว่าบัญชีผู้ใช้ที่ใช้ดึงข้อมูลมีสิทธิ์ใน SAP S/4HANA เพื่อเข้าถึง CDS Views ที่จำเป็น โดย views หลัก ได้แก่ I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry และ I_ClearedItem
- เปิดเครื่องมือเรียกใช้คำค้น: เข้าสู่ระบบไคลเอนต์ SQL หรือเครื่องมือผสานข้อมูลที่คุณเลือก ซึ่งเชื่อมต่อกับฐานข้อมูล SAP S/4HANA แล้ว อาจใช้เครื่องมือของ SAP เช่น SAP Analytics Cloud หรือแพลตฟอร์ม ETL ของผู้ให้บริการรายอื่น
- กำหนดพารามิเตอร์คำค้น: ก่อนเรียกใช้ ให้แก้คำค้น SQL ที่ให้มา ค้นหาค่าตัวอย่างแล้วแทนด้วยพารามิเตอร์ที่ถูกต้องสำหรับสภาพแวดล้อมของคุณ เช่น
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]รวมถึงตัวกรองประเภทเอกสารหรือรหัสบริษัทอื่นๆ - เรียกใช้คำค้นเพื่อดึงข้อมูล: คัดลอกคำค้น SQL ทั้งหมดแล้วเรียกใช้ในเครื่องมือ คำค้นจะรวมผลลัพธ์จากคำสั่ง select หลายชุดให้เป็นชุดข้อมูลเดียว เพื่อรวบรวมกิจกรรมทั้งหมดที่ระบุ
- ทำความเข้าใจตรรกะของคำค้น: แต่ละบล็อก
SELECTในโครงสร้างUNION ALLใช้ดึงข้อมูลสำหรับกิจกรรมหนึ่งรายการ โดยเชื่อม CDS views หลายรายการเพื่อรวบรวมแอตทริบิวต์ที่ต้องใช้ กำหนดข้อความคงที่ให้ActivityNameและเลือกเวลาที่เกี่ยวข้องให้กับEventTime - ตรวจสอบข้อมูลดิบ: เมื่อคำค้นทำงานเสร็จ ให้ตรวจสอบผลลัพธ์เบื้องต้น ดูว่าจำนวนแถวสมเหตุสมผล และคอลัมน์สำคัญ เช่น
ReturnCaseId,ActivityNameและEventTimeมีข้อมูลตามที่คาดไว้ - แปลงข้อมูล: คำค้นจัดโครงสร้างผลลัพธ์ให้อยู่ในรูปแบบบันทึกเหตุการณ์แบบแบน โดยทั่วไปไม่ต้องปรับโครงสร้างเพิ่มเติมมากนัก แต่อาจต้องปรับรูปแบบการประทับเวลาหรือชนิดข้อมูลให้ตรงกับข้อกำหนดของระบบปลายทาง
- ส่งออกบันทึกเหตุการณ์: ส่งออกผลลัพธ์คำค้นเป็นไฟล์ CSV และใช้การเข้ารหัส UTF-8 เพื่อป้องกันปัญหาอักขระ โดยเฉพาะในชื่อผู้ใช้หรือคำอธิบายสินค้า
- อัปโหลดไปยังเครื่องมือ process mining: ไฟล์ CSV ที่ได้พร้อมอัปโหลดไปยังแพลตฟอร์ม process mining เช่น ProcessMind จับคู่คอลัมน์ในไฟล์กับฟิลด์ที่เกี่ยวข้องในเครื่องมือ เช่น
ReturnCaseIdกับรหัสเคส,ActivityNameกับกิจกรรม และEventTimeกับการประทับเวลา
การกำหนดค่า
- ข้อกำหนดเบื้องต้น: ผู้ใช้ที่เรียกใช้ต้องมีสิทธิ์ดูข้อมูลของออบเจ็กต์ที่เกี่ยวข้องกับเอกสารการขาย (VBAK), การจัดส่ง (LIKP), การเรียกเก็บเงิน (VBRK) และบัญชี (BSEG, BKPF) รวมถึงต้องเข้าถึง CDS View ที่เกี่ยวข้องได้.
- ตัวกรองขอบเขตข้อมูล: ต้องกรอง Query ตามประเภทเอกสารที่กำหนด เพื่อแยกกระบวนการรับคืนสินค้าออกมา ตั้งค่าตัวอย่างสำหรับประเภทคำสั่งซื้อคืนสินค้า (เช่น 'RE'), ประเภทคำขอใบลดหนี้ (เช่น 'G2') และประเภทคำสั่งซื้อแลกเปลี่ยน (เช่น 'SO') ขอแนะนำให้กรองตาม
CompanyCodeหรือSalesOrganizationด้วย เพื่อจำกัดขอบเขตข้อมูล. - ตัวกรองช่วงวันที่: ใช้ตัวกรองช่วงวันที่เสมอเพื่อควบคุมประสิทธิภาพและปริมาณข้อมูล เริ่มจากข้อมูลย้อนหลัง 3 ถึง 6 เดือน Query ใช้วันที่สร้างคำสั่งซื้อคืนสินค้าเริ่มต้น (
I_SalesDocument.CreationDate) เป็นเงื่อนไขกรองหลัก. - ข้อควรพิจารณาด้านประสิทธิภาพ: Query นี้เชื่อม CDS View ขนาดใหญ่หลายรายการ จึงอาจใช้ทรัพยากรของระบบ S/4HANA ต้นทางมาก ควรกำหนดเวลาการดึงข้อมูลนอกช่วงเวลาที่มีการใช้งานสูง เพื่อลดผลกระทบ หากชุดข้อมูลมีขนาดใหญ่มาก ให้พิจารณากลยุทธ์การโหลดข้อมูลแบบเพิ่มทีละส่วน.
ตัวอย่างคำค้น sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' ขั้นตอน
- ตรวจสอบว่ามีสิทธิ์อ่านโดยตรงใน SAP HANA schema ที่เก็บข้อมูลการขาย การจัดส่ง การเรียกเก็บเงิน เอกสารวัสดุ การตรวจสอบ สถานะ และบัญชี ชื่อ schema, view และฟิลด์จริงอาจแตกต่างกันตามการติดตั้ง SAP S/4HANA ให้แทนที่ตัวอย่างในวงเล็บเหลี่ยมแต่ละรายการด้วยออบเจ็กต์และฟิลด์ที่กำหนดค่าไว้ในระบบของคุณ.
- กำหนดขอบเขตการดึงข้อมูลด้วย [Start date], [End date], [Company Code filter] และ [Return document type filter] เริ่มดึงข้อมูลย้อนหลังสามถึงหกเดือน และขยายช่วงเวลาเมื่อยืนยันประสิทธิภาพและความครบถ้วนของข้อมูลแล้วเท่านั้น.
- ระบุรายการคำสั่งซื้อคืนสินค้าจาก [Your sales document header table] และ [Your sales document item table] จำกัดรายการให้เหลือประเภทเอกสารคำสั่งซื้อคืนสินค้าที่กำหนดไว้ใน [Your return order document type configuration] เก็บหมายเลขคำสั่งซื้อคืนสินค้าและหมายเลขรายการไว้เป็นข้อมูลหลักสำหรับเชื่อมโยงกับเอกสารที่เกี่ยวข้องในขั้นตอนถัดไป.
- ตรวจสอบลำดับเอกสารจากคำสั่งซื้อคืนสินค้าไปยังการจัดส่งสินค้าคืนขาเข้า คำขอใบลดหนี้ คำสั่งซื้อแลกเปลี่ยน และใบลดหนี้ โดยใช้ [Your document flow table or view] อย่าสันนิษฐานว่าข้อมูลลำดับเอกสารจัดเก็บอยู่ใน VBAK หรือ VBAP ให้กำหนดฟิลด์ความสัมพันธ์ตามรูปแบบลำดับเอกสารที่ใช้ในระบบ.
- ดึงเหตุการณ์การสร้างจากระเบียนส่วนหัวและรายการของเอกสารที่เกี่ยวข้องโดยตรง ส่วนเหตุการณ์อนุมัติ ปฏิเสธ ตรวจสอบ ปิดงาน รับสินค้า บัญชี และชำระบัญชี ให้ดึงจากแหล่งข้อมูลสถานะ การตรวจสอบ เอกสารวัสดุ บัญชี และการชำระบัญชีที่กำหนดไว้ ต้องส่งออกแต่ละกิจกรรมเป็นแถวเหตุการณ์แยกกัน เพราะ ProcessMind ไม่ได้อนุมานเหตุการณ์ให้.
- ปรับรูปแบบเวลาให้เป็นชนิดเวลาของฐานข้อมูลและเขตเวลาเดียวกัน ใช้ลำดับความสำคัญของเวลาที่กำหนดไว้สำหรับแต่ละกิจกรรม หากมีเพียงวันที่และเวลา ให้นำมารวมกันโดยใช้เขตเวลาของระบบที่กำหนดไว้ใน [Your system time zone].
- กำหนดค่า ReturnCaseId ให้กับทุกเหตุการณ์ ใช้หมายเลขคำสั่งซื้อคืนสินค้าต้นทาง หรือรหัสเคสคืนสินค้าที่กำหนดไว้ หาก Advanced Returns Management จัดเก็บคีย์เคสแยกต่างหาก ให้ตัดเหตุการณ์ที่เชื่อมโยงกับเคสคืนสินค้าไม่ได้ออก หรือส่งไปยังผลลัพธ์ข้อยกเว้นเพื่อแก้ไข.
- กำหนดคอลัมน์ที่จำเป็น ได้แก่ ReturnCaseId, ActivityName, EventTime, SourceSystemId และ LastDataUpdateTimestamp หากมีข้อมูล ให้เพิ่มคอลัมน์ที่แนะนำ เช่น EventEndTime, UserName, ReturnReason, RefundAmount, ProductId และ CustomerId เก็บหนึ่งแถวต่อการเกิดกิจกรรมแต่ละครั้ง และอย่ารวมกิจกรรมเป็นแถวเดียวต่อเคส.
- ตรวจสอบผลลัพธ์ตามรายการใน validationSteps ยืนยันว่ามีชื่อกิจกรรมครบทั้งสิบสองรายการ เวลาของแต่ละเคสเรียงลำดับอย่างสมเหตุสมผล และข้อมูลอ้างอิงเอกสารตรงกับตารางต้นทาง.
- ส่งออกผลลัพธ์เป็นไฟล์ CSV ที่เข้ารหัส UTF-8 หรือรูปแบบตารางอื่นที่ ProcessMind รองรับ คงชื่อคอลัมน์ให้ตรงตามที่กำหนด ใช้แถวหัวตารางเพียงแถวเดียว เก็บเวลาในรูปแบบ ISO ที่ไม่กำกวม แล้วอัปโหลดบันทึกเหตุการณ์โดยกำหนด ReturnCaseId เป็นรหัสเคส และ ActivityName เป็นคอลัมน์กิจกรรม.
การกำหนดค่า
- ช่วงวันที่: เริ่มจากข้อมูลย้อนหลังสามถึงหกเดือน ใช้พารามิเตอร์ [Start date] และ [End date] และรวมข้อมูลย้อนหลังให้เพียงพอสำหรับเคสที่เริ่มก่อนช่วงเวลาที่เลือกแต่เสร็จสิ้นภายในช่วงนั้น.
- รายการรับคืนสินค้า: กรองตามประเภทเอกสารคำสั่งซื้อคืนสินค้าที่กำหนดไว้ใน [Your return order document type configuration] อย่ากำหนดประเภทเอกสารตายตัวจนกว่าจะตรวจสอบในระบบปลายทางแล้ว.
- ตัวกรองตามหน่วยงาน: ใช้ [Company Code filter], sales organization, distribution channel, division, plant หรือตัวกรองลูกค้าเมื่อจำเป็นเท่านั้น ตรวจสอบว่าตัวกรองไม่ตัดเอกสารต่อเนื่องระหว่างบริษัทหรือระหว่างหน่วยงานในเครือออก.
- ออบเจ็กต์ต้นทาง: แทนที่ตัวอย่าง [Your table name] และ [Your view name] ด้วยตารางหรือ CDS View ของ SAP S/4HANA ที่ได้รับอนุมัติ ระบบที่ติดตั้งอาจมี VBAK, VBAP, VBRK และ VBRP แต่ต้องตรวจสอบการใช้งานและส่วนขยายก่อนเรียกใช้.
- การจัดการเวลา: กำหนดฟิลด์เวลาและเขตเวลาต้นทางสำหรับแต่ละกิจกรรม จัดเก็บ EventTime และ EventEndTime ให้สอดคล้องกัน โดยควรใช้ UTC หรือเขตเวลาของ ProcessMind ที่ตกลงกันไว้.
- การตีความสถานะ: กำหนดค่าสถานะ รหัสเหตุผล ผลการตรวจสอบ และตัวบ่งชี้การปิดงานที่ใช้แทนการอนุมัติ การปฏิเสธ การตรวจสอบเสร็จสิ้น และการปิดเคสในระบบให้ตรงตามจริง.
- รหัสระบบต้นทาง: แทนที่ [Source system identifier] ด้วยค่าคงที่ เช่น รหัสระบบ SAP ที่แพลตฟอร์มดึงข้อมูลใช้.
- เวลารีเฟรช: แทนที่ [Extraction timestamp] ด้วยเวลาที่เริ่มเรียกใช้ Query หรือเวลาที่สร้างสแนปชอตต้นทาง ใช้ค่าเดียวกันกับทุกแถวในการดึงข้อมูลหนึ่งครั้ง เว้นแต่จำเป็นต้องใช้เวลารีเฟรชแยกตามแถว.
- ประสิทธิภาพ: จำกัดรายการรับคืนสินค้าเริ่มต้นก่อนเชื่อมกับแหล่งข้อมูลลำดับเอกสาร บัญชี เอกสารวัสดุ และสถานะขนาดใหญ่ ใช้ฟิลด์ที่มีดัชนีหรือช่วยตัดพาร์ทิชัน หลีกเลี่ยงการสแกนข้อมูลโดยไม่มีเงื่อนไข และสร้างผลลัพธ์ระหว่างทางไว้ใช้ต่อเมื่อผู้ดูแลฐานข้อมูลอนุมัติเท่านั้น.
- การดึงข้อมูลแบบเพิ่มทีละส่วน: สำหรับการเรียกใช้ซ้ำ ให้ใช้ [Last successful extraction timestamp] พร้อมช่วงเวลาซ้อนทับที่ควบคุมไว้ เพื่อเก็บข้อมูลที่มีการอัปเดตล่าช้า ป้องกันข้อมูลซ้ำโดยใช้ ReturnCaseId, ActivityName, คีย์เอกสารต้นทาง และ EventTime.
- สิทธิ์และข้อกำหนดเบื้องต้น: ขอสิทธิ์อ่านออบเจ็กต์และฟิลด์ต้นทางที่กำหนดทั้งหมด ขออนุมัติการเข้าถึงฐานข้อมูลโดยตรง และยืนยันว่าเปิดใช้งานคอมโพเนนต์ SAP และฟังก์ชัน Advanced Returns Management ที่จำเป็นแล้ว หากเกี่ยวข้อง.
- การคุ้มครองข้อมูล: จำกัดฟิลด์ข้อมูลลูกค้าและการเงินให้เหลือเท่าที่จำเป็น ปฏิบัติตามมาตรการคุ้มครองข้อมูลส่วนบุคคลขององค์กร และจัดเก็บไฟล์ที่ส่งออกอย่างปลอดภัย.
ตัวอย่างคำค้น sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; พร้อมเริ่มต้นหรือยัง?
เทมเพลตนี้ให้ข้อมูลพื้นฐานที่คุณต้องใช้ในการดึงและวิเคราะห์ข้อมูลกระบวนการรับคืนสินค้าและคืนเงิน เริ่มปรับปรุงกระบวนการของคุณได้วันนี้.
ปรับปรุงกระบวนการรับคืนสินค้าและคืนเงินใน SAP S/4HANA ได้เลย
ค้นหาจุดที่ไม่มีประสิทธิภาพ ลดระยะเวลาดำเนินการ 30% และเพิ่มความพึงพอใจ.
ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงกระบวนการได้วันนี้.