เทมเพลตข้อมูลสำหรับกระบวนการคืนสินค้าและคืนเงิน
เทมเพลตข้อมูลสำหรับกระบวนการคืนสินค้าและคืนเงิน
- ฟิลด์ข้อมูลที่แนะนำให้รวบรวม
- ขั้นตอนหลักของกระบวนการที่ควรติดตาม
- คำแนะนำในการดึงข้อมูล
แอตทริบิวต์ของกระบวนการคืนสินค้าและคืนเงิน
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| รหัสกรณีคืนสินค้า ReturnCaseId | รหัสเฉพาะของกรณีคืนสินค้าและคืนเงินของลูกค้า ใช้เชื่อมโยงกิจกรรมที่เกี่ยวข้องทั้งหมด. | ||
| คำอธิบาย Return Case ID เป็นรหัสหลักที่ใช้ระบุกรณีคืนสินค้าแต่ละรายการ โดยเชื่อมโยงกิจกรรมทั้งหมดที่เกี่ยวข้องกับการคืนสินค้าหรือคำขอคืนเงินของลูกค้ารายหนึ่ง ตั้งแต่สร้างใบสั่งคืนสินค้าจนถึงปิดกรณี ในการวิเคราะห์กระบวนการ รหัสนี้เป็นข้อมูลสำคัญสำหรับสร้างเส้นทางการคืนสินค้าแต่ละรายการตั้งแต่ต้นจนจบ ช่วยติดตามวงจรทั้งหมด วัดเวลารวมของกรณี และเปรียบเทียบความแตกต่างระหว่างกรณีต่างๆ ระบบใช้รหัสนี้รวบรวมและเชื่อมโยงเหตุการณ์ ข้อมูล และตัวชี้วัดทั้งหมดเข้าด้วยกัน. เหตุผลที่สำคัญ นี่คือรหัสกรณีหลักที่เชื่อมโยงทุกขั้นตอนของกระบวนการ ทำให้ติดตามและวิเคราะห์การคืนสินค้าแต่ละรายการได้ตั้งแต่ต้นจนจบ. แหล่งข้อมูล โดยทั่วไปคือหมายเลข Return Material Authorization (RMA) หรือหมายเลข Sales Order ประเภท 'Returned Order' ในโมดูล 'Sales and marketing' พบได้ในตารางอย่าง 'SalesTable' ซึ่งมี 'SalesType' เป็น 'Returned Order'. ตัวอย่าง RMA-001234RMA-001235RMA-001236 | |||
| เวลาเกิดเหตุการณ์ EventTime | เวลาที่ระบุว่าเกิดกิจกรรมหรือเหตุการณ์ใดเหตุการณ์หนึ่งขึ้นเมื่อใด. | ||
| คำอธิบาย เวลาเกิดเหตุการณ์หรือการประทับเวลาใช้บันทึกวันที่และเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ กิจกรรมแต่ละรายการในบันทึกเหตุการณ์จะมีเวลาที่เกี่ยวข้อง ซึ่งช่วยเรียงลำดับเหตุการณ์ตามเวลา แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ process mining ที่อิงเวลา ใช้คำนวณเวลาระหว่างกิจกรรม ระบุเวลารอและคอขวด วัดระยะเวลารวมของแต่ละกรณี และตรวจสอบการปฏิบัติตามข้อตกลงระดับการให้บริการ (SLA) ความแม่นยำของเวลาที่บันทึกมีผลโดยตรงต่อความน่าเชื่อถือของการวิเคราะห์ผลการดำเนินงาน. เหตุผลที่สำคัญ เวลานี้จำเป็นต่อการคำนวณตัวชี้วัดด้านระยะเวลาทั้งหมด เช่น เวลาระหว่างขั้นตอนและเวลารอ ซึ่งเป็นพื้นฐานของการวิเคราะห์ผลการดำเนินงาน. แหล่งข้อมูล ตรงกับฟิลด์วันที่สร้างหรือวันที่แก้ไขในตารางต่างๆ เช่น 'SalesTable.createdDateTime' สำหรับการสร้างใบสั่ง หรือ 'WMSJournalTrans.createdDateTime' สำหรับสมุดรายวันคลังสินค้า. ตัวอย่าง 2023-10-26T10:00:00Z2023-10-26T14:30:15Z2023-10-27T09:05:42Z | |||
| ชื่อกิจกรรม ActivityName | ชื่อของเหตุการณ์ทางธุรกิจหรืองานเฉพาะที่เกิดขึ้นในกระบวนการคืนสินค้าและคืนเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุขั้นตอนหรือเหตุการณ์เฉพาะในวงจรการคืนสินค้าและคืนเงิน เช่น 'สร้างใบสั่งคืนสินค้า' 'รับสินค้าแล้ว' หรือ 'ลงรายการใบลดหนี้แล้ว' แต่ละกิจกรรมแสดงจุดหนึ่งในกระบวนการที่มีการบันทึกไว้ในระบบ การวิเคราะห์ลำดับและความถี่ของกิจกรรมเหล่านี้เป็นหัวใจของ process mining ช่วยแสดงแผนภาพกระบวนการ ระบุคอขวดระหว่างขั้นตอน และค้นหาเส้นทางกระบวนการที่พบได้บ่อยหรือไม่บ่อย รายการกิจกรรมเป็นตัวกำหนดขอบเขตของกระบวนการที่นำมาวิเคราะห์. เหตุผลที่สำคัญ แอตทริบิวต์นี้กำหนดขั้นตอนของกระบวนการ ช่วยแสดงลำดับการทำงานและระบุคอขวด งานซ้ำ และจุดที่เบี่ยงเบนจากขั้นตอนปกติ. แหล่งข้อมูล นี่คือแอตทริบิวต์เชิงแนวคิดที่ได้จากเหตุการณ์ในระบบ โดยสร้างได้จากการจับคู่การเปลี่ยนสถานะในตาราง เช่น 'SalesTable' และ 'WMSJournalTable' หรือจากบันทึกเหตุการณ์เฉพาะ แล้วตั้งชื่อให้อ่านเข้าใจง่าย. ตัวอย่าง สร้างใบสั่งคืนสินค้าแล้วรับสินค้าแล้วกำหนดรหัสการจัดการสินค้าแล้วลงรายการใบลดหนี้แล้ว | |||
| ช่องทางการคืนสินค้า ReturnChannel | วิธีหรือช่องทางที่ลูกค้าใช้เริ่มต้นการคืนสินค้า. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุช่องทางที่ลูกค้าใช้เริ่มต้นการคืนสินค้า เช่น 'พอร์ทัลออนไลน์' 'ที่ร้านค้า' 'โทรติดต่อฝ่ายบริการลูกค้า' หรือ 'ส่งทางไปรษณีย์'. การแยกวิเคราะห์กระบวนการตามช่องทางการคืนสินค้าช่วยประเมินประสิทธิภาพและความคล่องตัวของแต่ละช่องทาง ธุรกิจสามารถเปรียบเทียบระยะเวลาดำเนินการ ต้นทุน และความพึงพอใจของลูกค้า เพื่อหาแนวทางปฏิบัติที่ดี รวมถึงจุดที่ควรลงทุนหรือปรับปรุง ข้อมูลนี้เป็นส่วนสำคัญของแดชบอร์ด 'ประสิทธิภาพการใช้ช่องทางการคืนสินค้า'. เหตุผลที่สำคัญ ช่วยเปรียบเทียบประสิทธิภาพของช่องทางการคืนสินค้าแต่ละช่องทาง เพื่อปรับปรุงช่องทางที่ทำงานได้คล่องตัวและคุ้มค่าที่สุด. แหล่งข้อมูล ข้อมูลนี้อาจจัดเก็บไว้ที่ส่วนหัวของใบสั่งคืนสินค้า ('SalesTable') หรืออนุมานจากผู้ใช้ที่สร้างใบสั่ง อาจต้องใช้ตรรกะที่กำหนดเองหรือเพิ่มฟิลด์เฉพาะ. ตัวอย่าง พอร์ทัลเว็บไซต์ตู้บริการตนเองในร้านค้าฝ่ายบริการลูกค้า | |||
| ผู้ใช้ที่รับผิดชอบ ResponsibleUser | ผู้ใช้หรือพนักงานที่ดำเนินกิจกรรมหรือรับผิดชอบกิจกรรมนั้น. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุผู้ใช้ที่รับผิดชอบการดำเนินการในแต่ละขั้นตอน เช่น พนักงานคลังสินค้าที่รับสินค้า ผู้ตรวจสอบคุณภาพ หรือเจ้าหน้าที่การเงินที่ลงรายการใบลดหนี้ การวิเคราะห์กระบวนการแยกตามผู้ใช้ช่วยให้เข้าใจการกระจายภาระงาน ระบุผู้ที่ทำงานได้ดี และค้นหาความต้องการในการฝึกอบรม นอกจากนี้ยังใช้ตรวจสอบกรณีที่บุคคลหรือทีมใดทีมหนึ่งเป็นผู้ดำเนินการ และช่วยให้มั่นใจว่ามีการแบ่งแยกหน้าที่อย่างเหมาะสม. เหตุผลที่สำคัญ ช่วยวิเคราะห์การกระจายภาระงานและผลการดำเนินงานของแต่ละคนหรือทีม รวมถึงค้นหาโอกาสในการฝึกอบรมหรือจัดสรรทรัพยากร. แหล่งข้อมูล พบได้ในฟิลด์ 'created by' หรือ 'modified by' ของระเบียนธุรกรรม เช่น 'SalesTable.createdBy' หรือ ID ผู้ใช้ที่เชื่อมโยงในตารางสมุดรายวัน. ตัวอย่าง Alice.WBob.JChris.P | |||
| รหัสการจัดการสินค้า DispositionCode | รหัสที่ระบุผลการตรวจสอบสินค้าและการดำเนินการถัดไป. | ||
| คำอธิบาย กำหนดรหัสการจัดการสินค้าในระหว่างตรวจสอบคุณภาพสินค้าที่ส่งคืน รหัสนี้กำหนดขั้นตอนถัดไปของกระบวนการ เช่น 'Credit' 'Replace' 'Scrap' หรือ 'Return to Customer' แอตทริบิวต์นี้เป็นจุดตัดสินใจสำคัญในกระบวนการคืนสินค้า การวิเคราะห์ตามรหัสการจัดการสินค้าช่วยให้องค์กรเข้าใจผลลัพธ์ของการคืนสินค้า ติดตามผลกระทบทางการเงินจากการตัดจำหน่ายสินค้า และประเมินประสิทธิภาพของแนวทางจัดการต่างๆ เช่น การเปลี่ยนสินค้าหรือการคืนเงิน. เหตุผลที่สำคัญ รหัสนี้กำหนดเส้นทางของรายการคืนสินค้าหลังการตรวจสอบ จึงสำคัญต่อการวิเคราะห์รูปแบบกระบวนการและผลลัพธ์ทางธุรกิจ. แหล่งข้อมูล ฟิลด์นี้เป็นข้อมูลสำคัญในโมดูลการจัดการคุณภาพ และเกี่ยวข้องกับการดำเนินการใบสั่งคุณภาพหรือใบสั่งตรวจสอบ. ตัวอย่าง CRDTREPL-DSCRAPRTV | |||
| รหัสสินค้า ProductId | รหัสเฉพาะของสินค้าที่ลูกค้าคืน. | ||
| คำอธิบาย รหัสสินค้า ซึ่งมักเป็น Stock Keeping Unit (SKU) ใช้ระบุสินค้ารายการที่ลูกค้าคืน ใบสั่งคืนสินค้าแต่ละรายการจะเชื่อมโยงกับรหัสสินค้า. การวิเคราะห์การคืนสินค้าแยกตามผลิตภัณฑ์ช่วยระบุสินค้าที่มีอัตราการคืนสูง ซึ่งอาจบ่งชี้ถึงปัญหาการควบคุมคุณภาพ คำบรรยายสินค้าที่ไม่ถูกต้อง หรือข้อบกพร่องจากการผลิต ผลการวิเคราะห์นี้ช่วยจัดลำดับความสำคัญของการตรวจสอบและปรับปรุงสินค้า. เหตุผลที่สำคัญ ช่วยวิเคราะห์การคืนสินค้าแยกตามผลิตภัณฑ์ เพื่อระบุสินค้าที่มีปัญหาด้านคุณภาพหรือมีปริมาณการคืนสูง. แหล่งข้อมูล ข้อมูลนี้ตรงกับฟิลด์ 'ItemId' ในตาราง 'SalesLine' ของใบสั่งคืนสินค้า. ตัวอย่าง SKU-A-123SKU-B-456SKU-C-789 | |||
| รหัสเหตุผลการคืนสินค้า ReturnReasonCode | เหตุผลที่ลูกค้าแจ้งเมื่อต้องการคืนสินค้า. | ||
| คำอธิบาย รหัสเหตุผลการคืนสินค้าบันทึกเหตุผลที่ลูกค้าแจ้ง เช่น 'สินค้าชำรุด' 'ขนาดไม่ถูกต้อง' 'สินค้าไม่ตรงตามคำบรรยาย' หรือ 'ไม่ต้องการแล้ว' โดยปกติจะเก็บข้อมูลนี้เมื่อเริ่มดำเนินการคืนสินค้า. การวิเคราะห์เหตุผลการคืนสินค้าช่วยค้นหาสาเหตุที่แท้จริง ธุรกิจจะระบุปัญหาด้านคุณภาพสินค้า คำบรรยายสินค้าที่ไม่ถูกต้อง หรือข้อผิดพลาดด้านโลจิสติกส์ได้ ข้อมูลเชิงลึกนี้ช่วยปรับปรุงการออกแบบสินค้า การตลาด และการปฏิบัติการในห่วงโซ่อุปทาน เพื่อลดการคืนสินค้าในอนาคต. เหตุผลที่สำคัญ ช่วยให้เห็นสาเหตุที่ลูกค้าคืนสินค้า และวิเคราะห์ต้นตอของปัญหาเพื่อลดอัตราการคืนสินค้าและเพิ่มความพึงพอใจของลูกค้า. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้จัดเก็บในระดับรายการของใบสั่งคืนสินค้า ให้ค้นหาฟิลด์รหัสเหตุผลในตาราง 'SalesLine' ของใบสั่งคืนสินค้า. ตัวอย่าง DEFECTWRONG_ITEMNO_LONGER_WANTEDDAMAGED_IN_TRANSIT | |||
| จำนวนเงินคืนจริง ActualRefundAmount | มูลค่าเงินคืนสุดท้ายที่จ่ายให้ลูกค้า. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงจำนวนเงินสุดท้ายที่ยืนยันแล้วว่าคืนให้ลูกค้า โดยบันทึกเมื่อสร้างและลงรายการใบลดหนี้. ข้อมูลนี้สำคัญต่อการวิเคราะห์ทางการเงิน และใช้โดยตรงในแดชบอร์ด 'การวิเคราะห์ส่วนต่างของจำนวนเงินคืน' และ KPI 'อัตราความถูกต้องของจำนวนเงินคืน' การวิเคราะห์ข้อมูลนี้ช่วยให้เข้าใจผลกระทบทางการเงินจากการคืนสินค้าและการปรับยอดที่เกิดขึ้นระหว่างกระบวนการ. เหตุผลที่สำคัญ แสดงผลกระทบทางการเงินจริงจากการคืนสินค้า จึงจำเป็นต่อการคำนวณความถูกต้องของเงินคืนและทำความเข้าใจผลลัพธ์ทางการเงิน. แหล่งข้อมูล ดูค่านี้ได้จากรายละเอียดรายการใบลดหนี้ที่ลงบัญชีแล้ว โดยเกี่ยวข้องกับตาราง 'CustTrans' และ 'CustInvoiceJour' ของใบลดหนี้. ตัวอย่าง 99.99135.000.00 | |||
| จำนวนเงินคืนที่ร้องขอ RequestedRefundAmount | มูลค่ารวมของเงินคืนที่ลูกค้าร้องขอ. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงจำนวนเงินคืนเริ่มต้นที่ลูกค้าร้องขอหรือคาดว่าจะได้รับเมื่อเริ่มกระบวนการคืนสินค้า โดยทั่วไปคำนวณจากราคาซื้อเดิมของสินค้าที่คืน. ค่านี้ใช้เป็นฐานสำหรับ 'การวิเคราะห์ส่วนต่างของจำนวนเงินคืน' เมื่อเปรียบเทียบจำนวนเงินที่ร้องขอกับยอดคืนเงินจริง ธุรกิจจะระบุส่วนต่างที่เกิดจากค่าธรรมเนียมการนำสินค้ากลับเข้าคลัง การคืนเงินบางส่วนสำหรับสินค้าที่เสียหาย หรือการปรับยอดอื่น ๆ ได้ ซึ่งช่วยติดตามความถูกต้องทางการเงินและการปฏิบัติตามนโยบาย. เหตุผลที่สำคัญ ใช้เป็นฐานตรวจสอบความถูกต้องทางการเงิน โดยเปรียบเทียบกับจำนวนเงินคืนที่ดำเนินการจริง. แหล่งข้อมูล โดยทั่วไปคือยอดเงินของรายการหรือยอดรวมจากรายการในใบสั่งขายเดิมที่นำมาคืน ซึ่งดูได้จาก 'SalesLine.LineAmount'. ตัวอย่าง 99.99150.0024.50 | |||
| ประเภทการคืนสินค้า ReturnType | จัดประเภทการคืนสินค้าตามผลลัพธ์ที่ต้องการ เช่น คืนเงินหรือเปลี่ยนสินค้า. | ||
| คำอธิบาย แอตทริบิวต์นี้จัดประเภทกรณีคืนสินค้าตามวิธีแก้ไขที่ลูกค้าต้องการหรือธุรกิจเสนอให้ ประเภทที่พบบ่อย ได้แก่ 'คืนเงิน' 'เปลี่ยนสินค้า' หรือ 'ซ่อมแซม'. การจัดประเภทนี้ช่วยวิเคราะห์เส้นทางกระบวนการที่แตกต่างกัน เพราะขั้นตอนการคืนเงินต่างจากการจัดส่งสินค้าใหม่อย่างมาก การแยกข้อมูลตามประเภทการคืนสินค้าช่วยให้วิเคราะห์ระยะเวลาดำเนินการและคอขวดของแต่ละเส้นทางได้แม่นยำขึ้น. เหตุผลที่สำคัญ ช่วยแยกการวิเคราะห์ตามผลลัพธ์ที่ต้องการ เนื่องจากกระบวนการคืนเงินและเปลี่ยนสินค้ามีขั้นตอนและระยะเวลาดำเนินการต่างกัน. แหล่งข้อมูล ข้อมูลนี้อาจเป็นฟิลด์ที่กำหนดเองในส่วนหัวใบสั่งคืนสินค้า หรืออนุมานจากรหัสการจัดการสินค้า หรือธุรกรรมที่เกิดขึ้นภายหลัง เช่น การสร้างใบสั่งขายสำหรับสินค้าใหม่. ตัวอย่าง คืนเงินเปลี่ยนสินค้าเครดิตสำหรับใช้ซื้อสินค้าในร้าน | |||
| เป็นไปตามนโยบายหรือไม่ IsPolicyAdherent | ตัวบ่งชี้ว่าการอนุมัติคืนสินค้าเป็นไปตามนโยบายการคืนสินค้าที่กำหนดไว้หรือไม่. | ||
| คำอธิบาย แอตทริบิวต์แบบบูลีนที่คำนวณขึ้นนี้ระบุว่าการคืนสินค้าเป็นไปตามเกณฑ์ทั้งหมดในนโยบายการคืนสินค้าของบริษัทหรือไม่ โดยอาจพิจารณาจากปัจจัยต่าง ๆ เช่น ระยะเวลาที่อนุญาตให้คืน สภาพสินค้า หรือเหตุผลในการคืน. แอตทริบิวต์นี้ใช้กับแดชบอร์ด 'ภาพรวมการปฏิบัติตามข้อกำหนดในการอนุมัติคืนสินค้า' และ KPI 'อัตราการอนุมัติคืนสินค้าที่เป็นไปตามข้อกำหนด' โดยตรง ธุรกิจสามารถวัดการปฏิบัติตามนโยบาย ระบุกรณีที่อนุมัติเป็นข้อยกเว้น และวิเคราะห์เหตุผลกับความถี่ของข้อยกเว้นได้ ซึ่งจำเป็นต่อการกำกับดูแลและควบคุมต้นทุน. เหตุผลที่สำคัญ ใช้วัดการปฏิบัติตามกฎทางธุรกิจโดยตรง ช่วยระบุและลดการอนุมัติคืนสินค้าที่ไม่เป็นไปตามข้อกำหนด ซึ่งอาจทำให้สูญเสียรายได้. แหล่งข้อมูล แอตทริบิวต์นี้ได้มาจากการคำนวณ โดยต้องเปรียบเทียบข้อมูลของรายการคืนสินค้า เช่น วันที่คืนเทียบกับวันที่ซื้อและเหตุผลในการคืน กับกฎทางธุรกิจที่กำหนดไว้ล่วงหน้า. ตัวอย่าง truefalse | |||
| รหัสคลังสินค้า WarehouseId | รหัสคลังสินค้าหรือสถานที่ที่รับสินค้าที่ส่งคืน. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุคลังสินค้าหรือศูนย์รับคืนสินค้าจริงที่ดำเนินการกับสินค้าที่ส่งคืน แต่ละสถานที่อาจมีขั้นตอน ทรัพยากร หรือระดับประสิทธิภาพแตกต่างกัน. การวิเคราะห์กระบวนการแยกตามคลังสินค้าช่วยเปรียบเทียบผลการดำเนินงานระหว่างสถานที่ต่าง ๆ และระบุศูนย์ที่จัดการคืนสินค้าได้มีประสิทธิภาพที่สุด นอกจากนี้ยังช่วยชี้ให้เห็นคอขวดในแต่ละภูมิภาค และใช้ประกอบการตัดสินใจจัดสรรทรัพยากรหรือกำหนดมาตรฐานกระบวนการในเครือข่ายโลจิสติกส์. เหตุผลที่สำคัญ ช่วยเปรียบเทียบผลการดำเนินงานของคลังสินค้าหรือศูนย์รับคืนสินค้าแต่ละแห่ง เพื่อระบุคอขวดในแต่ละภูมิภาคและแนวทางปฏิบัติที่ดี. แหล่งข้อมูล ข้อมูลนี้จัดเก็บในฟิลด์ 'InventLocationId' ของรายการธุรกรรมที่เกี่ยวข้องกับสินค้าคงคลัง เช่น สมุดรายวันรับสินค้า ('WMSJournalTable') หรือใน 'SalesLine'. ตัวอย่าง WH-EASTWH-WESTCENTRAL-DC | |||
| รหัสใบลดหนี้ CreditNoteId | รหัสเฉพาะของเอกสารใบลดหนี้ที่สร้างขึ้นสำหรับการคืนเงิน. | ||
| คำอธิบาย เมื่อดำเนินการคืนเงิน ระบบจะสร้างเอกสารทางการเงินที่เรียกว่าใบลดหนี้หรือ credit memo แอตทริบิวต์นี้เก็บรหัสเฉพาะของเอกสารดังกล่าว. รหัสนี้เชื่อมโยงกระบวนการคืนสินค้าเข้ากับข้อมูลทางการเงินในระบบบัญชีโดยตรง จึงมีประโยชน์ต่อการตรวจสอบและวิเคราะห์ส่วนต่างทางการเงิน นักวิเคราะห์สามารถติดตามรายการคืนสินค้าไปจนถึงธุรกรรมทางการเงินที่ใช้ชำระรายการนั้นได้. เหตุผลที่สำคัญ เชื่อมโยงกระบวนการคืนสินค้าเข้ากับธุรกรรมทางการเงินที่เกี่ยวข้อง ซึ่งจำเป็นต่อการตรวจสอบและกระทบยอดทางการเงิน. แหล่งข้อมูล โดยทั่วไปหมายเลขใบลดหนี้อยู่ในฟิลด์ 'InvoiceId' ของตาราง 'CustInvoiceJour' โดยมีประเภทธุรกรรมเป็น 'Credit note' และสามารถเชื่อมโยงกลับไปยังใบสั่งคืนสินค้าได้. ตัวอย่าง CN-10056CN-10057CN-10058 | |||
| รหัสลูกค้า CustomerId | รหัสเฉพาะของลูกค้าที่เริ่มต้นการคืนสินค้า. | ||
| คำอธิบาย รหัสลูกค้าเป็นรหัสเฉพาะของบัญชีลูกค้าที่เกี่ยวข้องกับการคืนสินค้า ซึ่งเชื่อมโยงรายการคืนสินค้ากับลูกค้ารายใดรายหนึ่งใน CRM หรือฐานข้อมูลลูกค้า. การวิเคราะห์การคืนสินค้าแยกตามลูกค้าช่วยระบุลูกค้าที่มีการคืนสินค้าบ่อยผิดปกติ ซึ่งอาจบ่งชี้ถึงการฉ้อโกงหรือความไม่พึงพอใจเรื้อรัง นอกจากนี้ยังใช้แบ่งกลุ่มลูกค้าได้ เช่น เสนอบริการคืนสินค้าระดับพิเศษให้ลูกค้าที่มีมูลค่าสูง. เหตุผลที่สำคัญ เชื่อมโยงกระบวนการคืนสินค้ากับลูกค้าแต่ละราย ช่วยวิเคราะห์ข้อมูลระดับลูกค้าและระบุรูปแบบการคืนสินค้าหรือความเสี่ยงที่อาจเกิดการฉ้อโกง. แหล่งข้อมูล ข้อมูลนี้อยู่ในฟิลด์ 'CustAccount' ของตาราง 'SalesTable' สำหรับใบสั่งคืนสินค้า. ตัวอย่าง CUST-00045CUST-00192CUST-00315 | |||
| ระบบต้นทาง SourceSystem | ระบบสารสนเทศที่ใช้ดึงข้อมูลเหตุการณ์ออกมา. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุระบบสารสนเทศต้นทางของข้อมูล ในกรณีนี้ ระบบหลักคือ 'Microsoft Dynamics 365' ในองค์กรขนาดใหญ่ กระบวนการหนึ่งอาจเกี่ยวข้องกับหลายระบบ การระบุระบบต้นทางของแต่ละเหตุการณ์มีความสำคัญต่อการกำกับดูแลข้อมูล การแก้ปัญหาการดึงข้อมูล และการทำความเข้าใจระบบเทคโนโลยีที่เกี่ยวข้องกับกระบวนการ ทั้งยังช่วยยืนยันที่มาของข้อมูลที่นำมาวิเคราะห์. เหตุผลที่สำคัญ แอตทริบิวต์นี้ให้ข้อมูลสำคัญเกี่ยวกับที่มาของข้อมูล ซึ่งจำเป็นต่อการกำกับดูแลและตรวจสอบข้อมูล รวมถึงการทำความเข้าใจระบบที่เกี่ยวข้องกับกระบวนการ. แหล่งข้อมูล โดยทั่วไปจะเพิ่มค่าแบบคงที่นี้ระหว่างขั้นตอนการดึง แปลง และโหลดข้อมูล (ETL) เพื่อระบุที่มาของชุดข้อมูล. ตัวอย่าง Microsoft Dynamics 365 F&OD365-PROD | |||
| วันที่เป้าหมายตาม SLA สำหรับการคืนเงิน RefundSlaTargetDate | วันที่กำหนดให้ดำเนินการคืนสินค้าและคืนเงินจนเสร็จสิ้น. | ||
| คำอธิบาย แอตทริบิวต์นี้กำหนดเส้นตายตามข้อตกลงระดับการให้บริการ (SLA) สำหรับการแก้ไขรายการคืนสินค้า โดยเป็นวันที่ลูกค้าควรได้รับข้อสรุปสุดท้าย เช่น การลงรายการคืนเงินหรือการจัดส่งสินค้าใหม่. วันที่เป้าหมายนี้จำเป็นต่อการติดตามผลการดำเนินงานตามข้อตกลงการให้บริการ ใช้คำนวณ KPI 'อัตราการดำเนินการตาม SLA สำหรับการแก้ไขรายการ' และแสดงผลในแดชบอร์ด 'ประสิทธิภาพ SLA สำหรับการแก้ไขรายการคืนเงิน' เมื่อนำวันที่นี้ไปเปรียบเทียบกับวันที่ดำเนินการเสร็จจริง ธุรกิจจะระบุกรณีที่ไม่เป็นไปตาม SLA และจัดการรายการที่ค้างนานได้ล่วงหน้า. เหตุผลที่สำคัญ ใช้เป็นเกณฑ์วัดผลการดำเนินงานของกระบวนการ ช่วยติดตามการปฏิบัติตาม SLA และระบุรายการที่ล่าช้า. แหล่งข้อมูล ฟิลด์นี้อาจไม่มีมาให้เป็นมาตรฐาน โดยมักคำนวณจากวันที่สร้างรายการคืนสินค้าบวกกับระยะเวลา SLA ที่กำหนดไว้ล่วงหน้า เช่น 14 วัน และอาจจัดเก็บไว้ในฟิลด์ที่กำหนดเอง. ตัวอย่าง 2023-11-10T23:59:59Z2023-11-15T23:59:59Z | |||
| เวลาสิ้นสุด EndTime | เวลาที่ระบุว่ากิจกรรมใดกิจกรรมหนึ่งเสร็จสิ้นเมื่อใด. | ||
| คำอธิบาย เวลาสิ้นสุดคือเวลาที่กิจกรรมเสร็จสมบูรณ์ ส่วน StartTime ระบุเวลาเริ่มต้น และ EndTime ระบุเวลาสิ้นสุด จึงใช้คำนวณเวลาที่ใช้ทำงานนั้นได้ แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์ผลการดำเนินงานอย่างละเอียด โดยเฉพาะงานที่มีระยะเวลาวัดได้ เช่น 'ตรวจสอบสินค้า' เมื่อนำ StartTime มาเปรียบเทียบกับ EndTime นักวิเคราะห์จะวัดเวลาที่ใช้ทำงานจริงได้อย่างแม่นยำ และแยกออกจากเวลารอระหว่างงาน ช่วยค้นหาจุดที่ไม่มีประสิทธิภาพภายในแต่ละกิจกรรม ไม่ใช่เฉพาะช่วงระหว่างกิจกรรม. เหตุผลที่สำคัญ ช่วยคำนวณเวลาทำงานจริงของแต่ละกิจกรรม และแยกเวลารอออกจากเวลาที่ใช้ทำงานได้. แหล่งข้อมูล โดยมากต้องคำนวณจากข้อมูลอื่น เช่น ใช้ 'modifiedDateTime' ของการเปลี่ยนสถานะที่ทำให้กิจกรรมสิ้นสุด หรือใช้ StartTime ของกิจกรรมถัดไป. ตัวอย่าง 2023-10-26T10:15:00Z2023-10-26T14:45:20Z2023-10-27T09:55:12Z | |||
| สถานะ SLA SlaStatus | ระบุว่าดำเนินการแก้ไขรายการเสร็จภายในเป้าหมาย SLA หรือไม่. | ||
| คำอธิบาย แอตทริบิวต์ที่คำนวณขึ้นนี้แสดงสถานะการปฏิบัติตาม SLA อย่างชัดเจน โดยทั่วไปคือ 'ตรงเวลา' หรือ 'ล่าช้า' ระบบจะเปรียบเทียบเวลาของกิจกรรมสุดท้าย เช่น 'ปิดใบสั่งคืนสินค้า' กับ 'RefundSlaTargetDate'. แอตทริบิวต์นี้ช่วยให้รายงานผลการดำเนินงานในแดชบอร์ด เช่น 'ประสิทธิภาพ SLA สำหรับการแก้ไขรายการคืนเงิน' เข้าใจง่ายขึ้น ผู้ใช้ไม่ต้องเปรียบเทียบวันที่เอง เพราะมีสถานะที่ชัดเจนให้กรองและสรุปผล เพื่อคำนวณ 'อัตราการดำเนินการตาม SLA สำหรับการแก้ไขรายการ' โดยรวมได้รวดเร็ว. เหตุผลที่สำคัญ แสดงสถานะการปฏิบัติตาม SLA ให้เห็นได้ทันที ช่วยกรองรายการที่ล่าช้าและวิเคราะห์สาเหตุของความล่าช้าได้ง่าย. แหล่งข้อมูล แอตทริบิวต์นี้ได้มาจากการคำนวณ โดยเปรียบเทียบเวลาของกิจกรรมที่แก้ไขรายการเสร็จสิ้นกับแอตทริบิวต์ 'RefundSlaTargetDate'. ตัวอย่าง ตรงเวลาล่าช้า | |||
| สถานะใบสั่งคืนสินค้า ReturnOrderStatus | สถานะโดยรวมของใบสั่งคืนสินค้า ณ เวลาที่เกิดเหตุการณ์. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุสถานะปัจจุบันของส่วนหัวใบสั่งคืนสินค้า เช่น 'เปิด' 'ออกใบแจ้งหนี้แล้ว' หรือ 'ยกเลิกแล้ว' ช่วยให้เห็นภาพรวมว่ารายการอยู่ในขั้นตอนใด. กิจกรรมแสดงขั้นตอนของกระบวนการโดยละเอียด ส่วนสถานะโดยรวมช่วยกรองและแบ่งกลุ่มรายการได้ เช่น นักวิเคราะห์อาจดูเฉพาะรายการที่ 'เปิด' เพื่อทำความเข้าใจภาระงานปัจจุบัน หรือวิเคราะห์เส้นทางกระบวนการของรายการที่ถูก 'ยกเลิก' ในท้ายที่สุด. เหตุผลที่สำคัญ สรุปสถานะของรายการในภาพรวม ช่วยกรองรายการและทำความเข้าใจผลลัพธ์ เช่น การยกเลิก. แหล่งข้อมูล ข้อมูลนี้อยู่ในฟิลด์ 'SalesStatus' หรือ 'DocumentStatus' ของตาราง 'SalesTable'. ตัวอย่าง ใบสั่งเปิดอยู่จัดส่งแล้วออกใบแจ้งหนี้แล้วยกเลิกแล้ว | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ระบุว่ามีการรีเฟรชข้อมูลของกระบวนการครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงข้อมูลจากระบบต้นทางและอัปเดตในเครื่องมือ process mining ครั้งล่าสุด เพื่อให้ทราบว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด การทราบเวลาอัปเดตข้อมูลล่าสุดช่วยให้เข้าใจว่าการวิเคราะห์เป็นปัจจุบันแค่ไหน และช่วยให้ผู้ใช้ตีความแดชบอร์ดและ KPI ได้ถูกต้อง โดยทราบว่ากำลังดูข้อมูลล่าสุดหรือข้อมูล ณ เวลาใดเวลาหนึ่ง ซึ่งสำคัญต่อการติดตามการปฏิบัติการ. เหตุผลที่สำคัญ ระบุความใหม่ของข้อมูล เพื่อให้นักวิเคราะห์ทราบว่าข้อมูลเชิงลึกเกี่ยวกับกระบวนการเป็นปัจจุบันเพียงใด. แหล่งข้อมูล แอตทริบิวต์เมทาดาทานี้สร้างและจัดเก็บระหว่างขั้นตอนนำเข้าข้อมูล โดยทั่วไปจะแสดงเวลาที่งาน ETL เสร็จสิ้น. ตัวอย่าง 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
กิจกรรมในกระบวนการคืนสินค้าและคืนเงิน
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| กำหนดรหัสการจัดการสินค้าแล้ว | กิจกรรมนี้แสดงว่าการตรวจสอบเสร็จสิ้นและมีการตัดสินใจว่าจะจัดการสินค้าที่ส่งคืนอย่างไร โดยกำหนดรหัสการจัดการสินค้าให้กับรายการคืนสินค้า เช่น 'Credit', 'Scrap' หรือ 'Replace'. | ||
| เหตุผลที่สำคัญ นี่คือจุดตัดสินใจสำคัญที่กำหนดเส้นทางถัดไปของกระบวนการ ไม่ว่าจะเป็นการคืนเงิน การเปลี่ยนสินค้า หรือการปฏิเสธคำขอ หากล่าช้าในขั้นตอนนี้ อาจส่งผลต่อเวลาสรุปผลโดยรวมอย่างมาก. แหล่งข้อมูล บันทึกเหตุการณ์นี้เมื่อมีการกรอกฟิลด์ DispositionCode ในธุรกรรมสินค้าคงคลังของรายการใบสั่งคืนสินค้า หรือในสมุดรายวันที่เกี่ยวข้อง. บันทึก เหตุการณ์อัปเดตเมื่อกำหนด DispositionCode ให้กับรายการในใบสั่งคืนสินค้า. ประเภทเหตุการณ์ explicit | |||
| ปิดใบสั่งคืนสินค้าแล้ว | ใบสั่งคืนสินค้าถึงสถานะสุดท้าย หมายความว่าธุรกรรมด้านสินค้าและการเงินเสร็จสมบูรณ์ โดยทั่วไปเกิดขึ้นหลังลงรายการใบลดหนี้หรือจัดส่งสินค้าทดแทนแล้ว. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์สิ้นสุดหลักของกระบวนการคืนสินค้าที่เสร็จสมบูรณ์ ระยะเวลาตั้งแต่สร้างใบสั่งจนถึงจุดนี้คือเวลารวมของกรณี. แหล่งข้อมูล อนุมานได้จากการเปลี่ยนฟิลด์สถานะของ ReturnOrder เป็นสถานะสุดท้าย เช่น 'Invoiced' หรือ 'Closed' ซึ่งแสดงว่าไม่ต้องดำเนินการต่อแล้ว. บันทึก เปลี่ยนฟิลด์ SalesTable.Status หรือ SalesTable.DocumentStatus เป็นสถานะสุดท้าย. ประเภทเหตุการณ์ inferred | |||
| รับสินค้าแล้ว | บันทึกการรับสินค้าที่ส่งคืน ณ คลังสินค้าหรือศูนย์รับคืนที่กำหนด ระบบบันทึกเหตุการณ์นี้เมื่อลงรายการสมุดรายวันรับสินค้าเข้าที่เชื่อมกับใบสั่งคืนสินค้า. | ||
| เหตุผลที่สำคัญ นี่คือจุดเปลี่ยนสำคัญจากการดำเนินการของลูกค้าไปสู่การจัดการภายในองค์กร และเป็นจุดเริ่มต้นสำหรับคำนวณเวลาจัดการภายในทั้งหมด เช่น การตรวจสอบและการกำหนดแนวทางจัดการสินค้า. แหล่งข้อมูล เวลาที่ลงรายการ WMS Journal หรือ Item Arrival Journal ซึ่งเชื่อมกับรายการใน ReturnOrder การดำเนินการนี้จะปรับปรุงธุรกรรมสินค้าคงคลังให้มีสถานะ 'Registered' หรือ 'Received'. บันทึก เหตุการณ์ลงรายการ Item Arrival Journal ที่เชื่อมกับรายการในใบสั่งคืนสินค้า. ประเภทเหตุการณ์ explicit | |||
| ลงรายการใบลดหนี้แล้ว | ลงรายการใบลดหนี้ในบัญชีแยกประเภททางการเงินอย่างเป็นทางการ ทำให้ลูกค้าใช้วงเงินเครดิตได้ และแสดงว่าบริษัทดำเนินการคืนเงินเสร็จสิ้นแล้ว. | ||
| เหตุผลที่สำคัญ นี่คือจุดสำคัญทางการเงินที่ยืนยันว่าระบบดำเนินการคืนเงินแล้ว มักใช้เป็นกิจกรรมหลักในการวัดการปฏิบัติตาม SLA การคืนเงิน. แหล่งข้อมูล เวลาที่ลงรายการสมุดรายวันใบแจ้งหนี้ของใบสั่งคืนสินค้า ซึ่งเป็นการสรุปใบลดหนี้ให้เสร็จสิ้น สถานะใบสั่งคืนสินค้าจะเปลี่ยนเป็น 'Invoiced'. บันทึก ลงรายการสมุดรายวันใบแจ้งหนี้ของใบสั่งคืนสินค้า. ประเภทเหตุการณ์ explicit | |||
| สร้างใบสั่งคืนสินค้าแล้ว | กิจกรรมนี้เป็นจุดเริ่มต้นของกระบวนการคืนสินค้า เมื่อสร้าง Return Material Authorization (RMA) หรือใบสั่งคืนสินค้าในระบบ ระบบบันทึกเหตุการณ์นี้อย่างชัดเจนเมื่อมีการสร้างระเบียน ReturnOrder ใหม่ใน Dynamics 365. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการคืนสินค้าทั้งหมด การวิเคราะห์เวลาตั้งแต่กิจกรรมนี้จนถึงกิจกรรมอื่นช่วยให้เห็นระยะเวลารวมของกระบวนการ และค้นหาคอขวดในช่วงต้นได้. แหล่งข้อมูล บันทึกเหตุการณ์นี้จากเวลาที่สร้างส่วนหัว ReturnOrder โดยทั่วไปจะพบข้อมูลใน SalesTable ซึ่งมี SalesType เป็น 'Returned Order'. บันทึก เหตุการณ์สร้างระเบียน SalesTable ที่มี SalesType = 'Returned Order'. ประเภทเหตุการณ์ explicit | |||
| จัดส่งสินค้าทดแทนแล้ว | ลงรายการใบส่งสินค้า (packing slip) ของสินค้าทดแทน เพื่อระบุว่าจัดส่งให้ลูกค้าแล้ว นี่คือจุดสิ้นสุดของกระบวนการจัดส่งสินค้าทดแทน. | ||
| เหตุผลที่สำคัญ นี่คือจุดสำคัญของเส้นทางเปลี่ยนสินค้า ซึ่งแสดงว่าบริษัทได้ทำตามข้อตกลงกับลูกค้าแล้ว และจำเป็นต่อการติดตามระยะเวลาของกระบวนการเปลี่ยนสินค้า. แหล่งข้อมูล วันที่ลงรายการสมุดรายวันใบส่งสินค้าของใบสั่งขายสินค้าทดแทน การดำเนินการนี้จะปรับสถานะใบสั่งเป็น 'Delivered'. บันทึก ลงรายการใบส่งสินค้าของใบสั่งขายสินค้าทดแทน. ประเภทเหตุการณ์ explicit | |||
| ยกเลิกใบสั่งคืนสินค้าแล้ว | ยกเลิกใบสั่งคืนสินค้าก่อนดำเนินการเสร็จ อาจเกิดจากลูกค้าร้องขอหรือไม่ได้ส่งสินค้าคืน. | ||
| เหตุผลที่สำคัญ นี่คือผลลัพธ์สิ้นสุดอีกแบบหนึ่งที่กระบวนการไม่สำเร็จ การวิเคราะห์สาเหตุที่ยกเลิกการคืนสินค้าช่วยให้เข้าใจพฤติกรรมลูกค้าหรือปัญหาในกระบวนการ. แหล่งข้อมูล อนุมานได้จากการเปลี่ยนฟิลด์สถานะของ ReturnOrder เป็น 'Cancelled' ซึ่งเป็นสถานะสิ้นสุดที่ต่างจากการปิดใบสั่งที่เสร็จสมบูรณ์. บันทึก เปลี่ยนฟิลด์ SalesTable.Status เป็น 'Cancelled'. ประเภทเหตุการณ์ inferred | |||
| ยืนยันใบสั่งคืนสินค้าแล้ว | แสดงการยืนยันใบสั่งคืนสินค้าอย่างเป็นทางการในระบบ ซึ่งมักเป็นการเริ่มการทำงานในขั้นตอนถัดไป โดยทั่วไปบันทึกเป็นการดำเนินการที่ชัดเจนหรือการเปลี่ยนสถานะของส่วนหัว ReturnOrder. | ||
| เหตุผลที่สำคัญ การยืนยันเป็นขั้นตอนสำคัญก่อนเริ่มงานด้านโลจิสติกส์ หากใช้เวลานานระหว่างการสร้างกับการยืนยัน อาจบ่งชี้ว่ามีงานค้างด้านธุรการหรือระบบ. แหล่งข้อมูล ระบุได้จากการลงรายการสมุดรายวัน 'Confirmation' ของใบสั่งคืนสินค้า หรือการเปลี่ยนแปลงฟิลด์ DocumentStatus ใน SalesTable. บันทึก เรียกใช้ฟังก์ชัน 'Confirm sales order' สำหรับใบสั่งคืนสินค้า. ประเภทเหตุการณ์ explicit | |||
| สร้างใบลดหนี้แล้ว | สร้างใบลดหนี้ตามรหัสการจัดการสินค้า 'Credit' เพื่ออนุมัติการคืนเงินให้ลูกค้า นี่คือจุดเริ่มต้นอย่างเป็นทางการของขั้นตอนชำระเงินคืน. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้แสดงว่าการคืนเงินได้รับอนุมัติทางการเงินแล้ว เวลาระหว่างการกำหนดแนวทางจัดการสินค้ากับการสร้างใบลดหนี้ช่วยให้เห็นความล่าช้าด้านธุรการก่อนเริ่มคืนเงิน. แหล่งข้อมูล อนุมานได้จากการสร้างระเบียน SalesTable ใหม่ที่มียอดติดลบและเชื่อมกับใบสั่งคืนสินค้าเดิม หรือจากการเรียกใช้ชุดงาน 'Create credit note'. บันทึก สร้างใบลดหนี้ โดยมักทำผ่านการลงรายการใบแจ้งหนี้ของใบสั่งคืนสินค้า. ประเภทเหตุการณ์ explicit | |||
| สร้างใบสั่งตรวจสอบคุณภาพแล้ว | สร้างใบสั่งตรวจสอบคุณภาพอย่างเป็นทางการ เพื่อระบุว่าสินค้าที่ส่งคืนต้องผ่านการตรวจสอบตามขั้นตอน มักใช้ในกรณีที่ต้องทดสอบสินค้าอย่างละเอียดหรือตรวจเทียบกับมาตรฐานคุณภาพ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นของการตรวจสอบอย่างเป็นทางการ การติดตามเวลาตั้งแต่จุดนี้ช่วยวัดประสิทธิภาพและระยะเวลาของเวิร์กโฟลว์การประกันคุณภาพ. แหล่งข้อมูล เวลาที่สร้างระเบียนใน InventQualityOrderTable ซึ่งเชื่อมกับใบสั่งคืนสินค้า. บันทึก สร้างระเบียน InventQualityOrderTable. ประเภทเหตุการณ์ explicit | |||
| สร้างใบสั่งเปลี่ยนสินค้าแล้ว | สร้างใบสั่งขายใหม่เพื่อส่งสินค้าทดแทนให้ลูกค้า กิจกรรมนี้เกิดขึ้นเมื่อกำหนดการจัดการสินค้าเป็น 'Replace and Credit' หรือ 'Replace and Scrap'. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เริ่มกระบวนการเปลี่ยนสินค้า การติดตามเส้นทางนี้แยกจากเส้นทางคืนเงินเป็นสิ่งสำคัญ เพื่อให้เข้าใจความซับซ้อนและต้นทุนของการเปลี่ยนสินค้า. แหล่งข้อมูล สร้างระเบียน SalesTable ใหม่สำหรับสินค้าทดแทน ซึ่งมักสร้างโดยอัตโนมัติและเชื่อมกับใบสั่งคืนสินค้าเดิม. บันทึก สร้างใบสั่งขายใหม่ที่เชื่อมกับใบสั่งคืนสินค้าผ่านการดำเนินการตามรหัสการจัดการสินค้า. ประเภทเหตุการณ์ explicit | |||
| สร้างสมุดรายวันรับสินค้าเข้าแล้ว | กิจกรรมนี้แสดงว่าคลังสินค้าคาดว่าจะได้รับสินค้าที่ส่งคืน โดยเป็นการสร้างสมุดรายวันรับสินค้าเข้าเพื่อเตรียมระบบสำหรับรับสินค้าจริง. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้แยกการเตรียมงานด้านโลจิสติกส์ออกจากการรับสินค้าจริง ช่วยวิเคราะห์ความพร้อมของคลังสินค้าและวางแผนรับสินค้าคืน. แหล่งข้อมูล สร้างระเบียนใน WMSJournalTable ที่มี JournalType เป็น 'Arrival' โดยเชื่อมสมุดรายวันกับรายการในใบสั่งคืนสินค้า. บันทึก เวลาที่สร้างระเบียน WMSJournalTable สำหรับการคืนสินค้า. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
ขั้นตอน
- ข้อกำหนดเบื้องต้น: ลงทะเบียนแอปพลิเคชันใน Azure Active Directory. ก่อนเชื่อมต่อกับ Dynamics 365 API คุณต้องลงทะเบียนแอปพลิเคชันใน Azure AD tenant ของคุณ และให้สิทธิ์แบบ delegated เพื่อเข้าถึง Dynamics 365 Finance & Operations เช่น
Financials.ReadWrite.Allหรือสิทธิ์ที่กำหนดเอง - กำหนดค่า Application ID ใน Dynamics 365. ใน Dynamics 365 ไปที่ System administration > Setup > Azure Active Directory applications เพิ่ม Application (client) ID จากการลงทะเบียนแอปใน Azure AD แล้วเชื่อมโยงกับบัญชีผู้ใช้ที่มี security roles ที่จำเป็นสำหรับอ่าน data entities ที่ต้องการ
- รับ OAuth 2.0 Access Token. เขียนสคริปต์ เช่น ด้วย PowerShell หรือ Python เพื่อยืนยันตัวตนกับ endpoint ของ Microsoft identity platform ใช้ข้อมูลรับรองของแอปพลิเคชัน (client ID และ secret) เพื่อขอ access token สำหรับ URL ทรัพยากรของ Dynamics 365
- ค้นหา URL สภาพแวดล้อม Dynamics 365. หา base URL ของสภาพแวดล้อม Dynamics 365 โดยทั่วไป Web API endpoint จะมีรูปแบบดังนี้:
https://[YourD365FinanceAndOpsURL].dynamics.com/data - สร้างและเรียกใช้คำขอ OData API. สร้าง URL คำขอ OData GET สำหรับกิจกรรมที่ต้องการทั้ง 12 รายการ ใช้
$selectเพื่อดึงเฉพาะคอลัมน์ที่ต้องใช้ และใช้$filterเพื่อกำหนดช่วงวันที่และเงื่อนไขสถานะแต่ละรายการต้องใส่ token ที่ได้รับในขั้นตอนที่ 3 เป็น Bearer token ใน authorization header - สร้างสคริปต์ดึงข้อมูล. เขียนสคริปต์ให้วนเรียกคำขอ OData ทั้งหมด โดยสคริปต์จะจัดการการยืนยันตัวตน เรียกคำขอ GET และจัดเก็บข้อมูล JSON ที่ได้ โปรดคำนึงถึงข้อจำกัดของ API และเพิ่มช่วงพักตามความจำเป็น
- จัดการการแบ่งหน้า API. Dynamics 365 แบ่งผลลัพธ์ขนาดใหญ่เป็นหลายหน้า สคริปต์ต้องตรวจสอบว่ามีพร็อพเพอร์ตี
@odata.nextLinkในคำตอบหรือไม่ หากมี ให้เรียก URL ดังกล่าวเพื่อดึงข้อมูลหน้าถัดไป ทำซ้ำจนกว่าจะไม่มีnextLink - แปลงและรวมข้อมูล. ประมวลผลคำตอบ JSON จาก API ทั้ง 12 ครั้ง สำหรับแต่ละกิจกรรม ให้สร้างระเบียนมาตรฐานที่มี
ReturnCaseId,ActivityName,EventTimeและแอตทริบิวต์อื่นๆ ตัวอย่างเช่น ในเหตุการณ์ 'Return Order Created' ให้จับคู่ReturnOrderNumberกับReturnCaseIdกำหนดActivityNameเป็น 'Return Order Created' และจับคู่createdDateTimeกับEventTimeจากนั้นรวมระเบียนที่แปลงแล้วจากทุกคำขอไว้ในรายการหรือตารางเดียว - จัดรูปแบบและปรับมาตรฐานการประทับเวลา. ตรวจสอบให้แน่ใจว่าค่า
EventTimeทั้งหมดใช้รูปแบบเดียวกัน โดยแนะนำให้ใช้ UTC ในรูปแบบYYYY-MM-DDTHH:MM:SSZจัดการระเบียนที่ไม่มีการประทับเวลาหรือมีค่าที่ไม่ถูกต้องตามความจำเป็น - ส่งออกบันทึกเหตุการณ์ฉบับสมบูรณ์. เมื่อรวบรวมและแปลงข้อมูลทั้งหมดเป็นชุดข้อมูลเดียวแล้ว ให้ส่งออกเป็นไฟล์ CSV ตรวจสอบว่าชื่อหัวคอลัมน์ตรงตามข้อกำหนดของ ProcessMind เช่น
ReturnCaseId,ActivityName,EventTime,ResponsibleUser,DispositionCodeเป็นต้น จากนั้นไฟล์ก็พร้อมอัปโหลดแล้ว.
การกำหนดค่า
- URL ของ API Endpoint: URL พื้นฐานของ Dynamics 365 Finance & Operations ของคุณ มีรูปแบบดังนี้
https://[YourEnvironmentName].dynamics.com/data - แอปพลิเคชัน Azure AD: ต้องลงทะเบียนแอปพลิเคชันใน Azure AD พร้อม client ID และ secret รวมถึงสิทธิ์ API สำหรับเข้าถึงเอนทิตีข้อมูล Dynamics 365
- การกรองช่วงวันที่: ต้องกรองช่วงวันที่ในทุกการเรียก API โดยใช้พารามิเตอร์ OData
$filterกับฟิลด์วันที่ที่เกี่ยวข้อง เช่นcreatedDateTimeหรือmodifiedDateTimeโดยทั่วไปควรเริ่มจากข้อมูลย้อนหลัง 3 ถึง 6 เดือน เพื่อให้จัดการการดึงข้อมูลได้สะดวก - ตัวกรองบริษัท: หากต้องการดึงข้อมูลจากนิติบุคคลแห่งใดแห่งหนึ่ง ให้ใส่พารามิเตอร์คำขอ
cross-company=trueแล้วใช้$filterกับฟิลด์dataAreaIdตัวอย่างเช่น?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]' - การตั้งค่าการแบ่งหน้า: ใช้ส่วนหัว
Prefer: odata.maxpagesize=[value]ในคำขอเพื่อกำหนดจำนวนระเบียนต่อหน้า โดยทั่วไปใช้ค่า1000ถึง5000วิธีนี้ช่วยลดโอกาสที่ API จะหมดเวลาตอบสนองเมื่อเรียกเอนทิตีขนาดใหญ่ - การจำกัดอัตราการเรียก API: โปรดคำนึงถึงขีดจำกัดการป้องกันบริการ API ของ Dynamics 365 สคริปต์ดึงข้อมูลควรจัดการการตอบกลับ
429 (Too Many Requests)โดยใช้การหน่วงเวลาแบบเพิ่มขึ้นเป็นลำดับ หรือหยุดรอสักครู่แล้วลองใหม่.
ตัวอย่างคำค้น graphql
/*
This is a conceptual guide representing multiple, distinct OData API calls.
You will need a script (e.g., Python, PowerShell) to execute these calls sequentially,
authenticate with a bearer token, handle pagination, and union the results into a single file.
Replace [YourD365URL], [StartDate], [EndDate], and [YourCompanyCode] with your specific values.
*/
// Base URL for all requests
const string BaseUrl = "https://[YourD365URL].dynamics.com/data";
const string CompanyFilter = "?cross-company=true&$filter=dataAreaId eq '[YourCompanyCode]' and ";
const string DateFilterCreated = "createdDateTime ge [StartDate]T00:00:00Z and createdDateTime le [EndDate]T23:59:59Z";
const string DateFilterModified = "modifiedDateTime ge [StartDate]T00:00:00Z and modifiedDateTime le [EndDate]T23:59:59Z";
// 1. Return Order Created
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}{DateFilterCreated}&$select=ReturnOrderNumber,createdDateTime,createdby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser, ReturnReasonCodeId -> ReturnReasonCode
// 2. Return Order Confirmed
// This often updates the header status. We look for a modification time on confirmed orders.
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Confirmed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnReasonCodeId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Confirmed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 3. Arrival Journal Created
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}{DateFilterCreated}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,createdDateTime,createdby
// Note: This requires post-processing to link JournalNumber to a ReturnCaseId via InventTransactionId.
// Mapping: Link via InventTrans -> ReturnCaseId, 'Arrival Journal Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 4. Item Received (Arrival Journal Posted)
GET {BaseUrl}/WarehouseArrivalJournalHeaders{CompanyFilter}JournalPosted eq 'Yes' and {DateFilterModified}&$expand=WarehouseArrivalJournalLines($select=InventTransactionId)&$select=JournalNumber,modifiedDateTime,modifiedby
// Mapping: Link via InventTrans -> ReturnCaseId, 'Item Received' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 5. Quality Order Generated
GET {BaseUrl}/InventQualityOrders{CompanyFilter}{DateFilterCreated}&$select=QualityOrderId,InventTransId,createdDateTime,CreatedByUserId,ItemId
// Mapping: Link via InventTransId -> ReturnCaseId, 'Quality Order Generated' -> ActivityName, createdDateTime -> EventTime, CreatedByUserId -> ResponsibleUser, ItemId -> ProductId
// 6. Disposition Code Applied
// This is a status change on the return line.
GET {BaseUrl}/ReturnOrderLines{CompanyFilter}ReturnDispositionCodeId ne '' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby,ReturnDispositionCodeId,ItemId
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Disposition Code Applied' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser, ReturnDispositionCodeId -> DispositionCode, ItemId -> ProductId
// 7. Credit Note Created
// Look for sales orders with type 'Returned Order' that are not yet invoiced.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderProcessingStatus eq 'Open' and SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 8. Credit Note Posted
// Look for posted invoice journals linked to a return order.
GET {BaseUrl}/SalesInvoiceJournalHeaders{CompanyFilter}SalesOrderType eq 'ReturnedOrder' and {DateFilterCreated}&$select=SalesOrderNumber,InvoiceDate,createdby
// Mapping: SalesOrderNumber -> ReturnCaseId, 'Credit Note Posted' -> ActivityName, InvoiceDate -> EventTime, createdby -> ResponsibleUser
// 9. Replacement Order Created
// Disposition code on the return line triggers a replacement order.
GET {BaseUrl}/SalesOrderHeadersV2{CompanyFilter}SalesOrderOriginType eq 'ReturnOrder' and {DateFilterCreated}&$select=SalesOrderNumber,createdDateTime,createdby,ReturnOrderNumber
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Replacement Order Created' -> ActivityName, createdDateTime -> EventTime, createdby -> ResponsibleUser
// 10. Replacement Item Shipped
// Check for posted packing slips related to the replacement sales order.
GET {BaseUrl}/SalesPackingSlipJournals{CompanyFilter}{DateFilterCreated}&$select=SalesOrderNumber,DeliveryDate,createdby
// Note: This requires linking SalesOrderNumber back to the original ReturnOrderNumber for the ReturnCaseId.
// Mapping: Link SalesOrderNumber -> ReturnCaseId, 'Replacement Item Shipped' -> ActivityName, DeliveryDate -> EventTime, createdby -> ResponsibleUser
// 11. Return Order Closed
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Closed' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Closed' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser
// 12. Return Order Cancelled
GET {BaseUrl}/ReturnOrderHeaders{CompanyFilter}ReturnOrderStatus eq 'Canceled' and {DateFilterModified}&$select=ReturnOrderNumber,modifiedDateTime,modifiedby
// Mapping: ReturnOrderNumber -> ReturnCaseId, 'Return Order Cancelled' -> ActivityName, modifiedDateTime -> EventTime, modifiedby -> ResponsibleUser ขั้นตอน
- เปิดใช้ TDS Endpoint: ตรวจสอบว่าเปิดใช้ Tabular Data Stream (TDS) endpoint สำหรับสภาพแวดล้อม Dynamics 365 Dataverse แล้ว ผู้ดูแลระบบสามารถเปิดใช้ได้ในศูนย์ผู้ดูแล Power Platform โดยไปที่ Environment > Settings > Features
- ค้นหา URL ของสภาพแวดล้อม: ค้นหา URL ของสภาพแวดล้อม ซึ่งมักมีรูปแบบ
yourorg.crm.dynamics.comชื่อเซิร์ฟเวอร์ TDS endpoint คือ URL นี้ตามด้วยพอร์ต 5558 เช่นyourorg.crm.dynamics.com,5558 - เชื่อมต่อด้วย SQL Client: ใช้ SQL client ที่รองรับ TDS เช่น SQL Server Management Studio (SSMS) หรือ Azure Data Studio
- ยืนยันตัวตน: เชื่อมต่อเซิร์ฟเวอร์ด้วยบัญชี Azure Active Directory ที่มีสิทธิ์เหมาะสมในสภาพแวดล้อม Dataverse โดยทั่วไปคือ System Administrator หรือ System Customizer
- เตรียม Query: คัดลอก SQL Query ทั้งหมดจากส่วน
queryในเอกสารนี้ไปวางในหน้าต่าง Query ใหม่ของ SQL client - กำหนดพารามิเตอร์: ค้นหาตัวแทนค่าใน Query แล้วแทนที่
'{StartDate}'และ'{EndDate}'ด้วยช่วงวันที่ที่ต้องการดึงข้อมูล เช่น'2023-01-01'และ'2023-12-31'นอกจากนี้ให้อัปเดตค่าตัวแทนรหัสสถานะหรือรหัสผลการพิจารณาให้ตรงกับการตั้งค่า Dynamics 365 ของคุณ - เรียกใช้ Query: เรียกใช้ Query ที่แก้ไขแล้วกับฐานข้อมูล Dataverse ระยะเวลาทำงานขึ้นอยู่กับปริมาณข้อมูลและช่วงวันที่ที่เลือก
- ตรวจสอบผลลัพธ์: เมื่อ Query ทำงานเสร็จ ให้ตรวจสอบชุดข้อมูลที่ได้ว่ามีคอลัมน์ตามที่คาดไว้ ได้แก่
ReturnCaseId,ActivityName,EventTimeและแอตทริบิวต์ที่แนะนำ - ส่งออกบันทึกเหตุการณ์: ส่งออกผลลัพธ์ Query เป็นไฟล์ CSV SQL client ส่วนใหญ่มีฟังก์ชันบันทึกผลลัพธ์ลงไฟล์โดยตรง ตรวจสอบว่าบันทึกไฟล์ด้วยการเข้ารหัส UTF-8
- อัปโหลดไปยัง ProcessMind: ไฟล์ CSV ที่ส่งออกพร้อมอัปโหลดไปยัง ProcessMind เป็นบันทึกเหตุการณ์ใหม่สำหรับการวิเคราะห์ process mining แล้ว.
การกำหนดค่า
- ข้อกำหนดเบื้องต้น: คุณต้องมีบัญชีผู้ใช้ที่มีสิทธิ์อ่านตาราง Dataverse ที่เกี่ยวข้องเป็นอย่างน้อย เช่น SalesTable, SalesLine, CustInvoiceJour โดยทั่วไปจะจัดการสิทธิ์ผ่านบทบาทความปลอดภัย เช่น System Administrator หรือบทบาทที่กำหนดเองซึ่งมีสิทธิ์เข้าถึงตารางเพียงพอ
- TDS Endpoint: ต้องเปิดใช้ TDS endpoint ของ Dataverse ในสภาพแวดล้อม ฟีเจอร์นี้ช่วยให้เรียกใช้ SQL Query กับฐานข้อมูล Dataverse ได้โดยตรงในโหมดอ่านอย่างเดียว
- ช่วงวันที่: Query มีตัวแทนค่า
'{StartDate}'และ'{EndDate}'สำหรับการวิเคราะห์ครั้งแรก แนะนำให้ใช้ช่วงวันที่ 3 ถึง 6 เดือน เพื่อให้ได้ชุดข้อมูลที่เป็นตัวแทนโดยไม่ทำให้เกิดปัญหาด้านประสิทธิภาพ - ตัวกรองบริษัท: Query ตามที่เขียนไว้จะทำงานกับนิติบุคคลทั้งหมดที่ผู้ใช้เข้าถึงได้ หากต้องการวิเคราะห์บริษัทเดียว ให้ยกเลิกการใส่หมายเหตุและเพิ่มส่วน
WHEREเพื่อกรองฟิลด์DATAAREAIDในแต่ละส่วนของคำสั่งUNION ALLเช่นAND st.DATAAREAID = '[YourCompanyID]' - ตัวแทนตรรกะที่กำหนดเอง: Query มีตัวแทนค่า เช่น
[YourReplaceCode1]สำหรับรหัสผลการพิจารณา และหมายเหตุเกี่ยวกับการเชื่อมโยงคำสั่งซื้อทดแทน คุณต้องกำหนดค่าเหล่านี้ให้ตรงกับกระบวนการทางธุรกิจและการตั้งค่า Dynamics 365 ของคุณ - ประสิทธิภาพ: การเรียก Query โดยตรงผ่าน TDS endpoint กับชุดข้อมูลขนาดใหญ่อาจใช้เวลานาน การเชื่อมต่อได้รับการปรับให้เหมาะกับ Query เพื่อการวิเคราะห์ แต่การ join ที่ซับซ้อนกับข้อมูลหลายล้านแถวอาจหมดเวลาตอบสนอง แนะนำให้ใช้ตัวกรองวันที่ที่จำกัดช่วงอย่างชัดเจน.
ตัวอย่างคำค้น sql
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Created' AS ActivityName,
st.CREATEDDATETIME AS EventTime,
st.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Confirmed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.DOCUMENTSTATUS = 1 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Arrival Journal Created' AS ActivityName,
wjt.CREATEDDATETIME AS EventTime,
wjt.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Item Received' AS ActivityName,
wjt.POSTEDDATETIME AS EventTime,
wjt.POSTEDUSERID AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN WMSJOURNALTABLE wjt ON st.SALESID = wjt.ORDERID AND st.DATAAREAID = wjt.DATAAREAID
WHERE st.SALESTYPE = 3 AND wjt.JOURNALTYPE = 4 AND wjt.POSTEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Quality Order Generated' AS ActivityName,
iqot.CREATEDDATETIME AS EventTime,
iqot.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Disposition Code Applied' AS ActivityName,
iqot.VALIDATEDDATETIME AS EventTime,
iqot.VALIDATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
iqot.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN INVENTQUALITYORDERTABLE iqot ON sl.INVENTTRANSID = iqot.INVENTTRANSID AND sl.DATAAREAID = iqot.DATAAREAID
WHERE st.SALESTYPE = 3 AND iqot.VALIDATEDDATETIME IS NOT NULL AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Created' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Credit Note Posted' AS ActivityName,
cij.CREATEDDATETIME AS EventTime,
cij.CREATEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
JOIN CUSTINVOICEJOUR cij ON st.SALESID = cij.SALESID AND st.DATAAREAID = cij.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Order Created' AS ActivityName,
replacement_so.CREATEDDATETIME AS EventTime,
replacement_so.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
replacement_sl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN SALESLINE replacement_sl ON replacement_so.SALESID = replacement_sl.SALESID AND replacement_so.DATAAREAID = replacement_sl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ro.RETURNITEMNUM AS ReturnCaseId,
'Replacement Item Shipped' AS ActivityName,
cpsj.CREATEDDATETIME AS EventTime,
cpsj.CREATEDBY AS ResponsibleUser,
NULL AS DispositionCode,
NULL AS ReturnReasonCode,
replacement_so.SALESORIGINID AS ReturnChannel,
cpsl.ITEMID AS ProductId
FROM SALESTABLE ro
JOIN SALESLINE rol ON ro.SALESID = rol.SALESID AND ro.DATAAREAID = rol.DATAAREAID
JOIN SALESTABLE replacement_so ON ro.CUSTACCOUNT = replacement_so.CUSTACCOUNT AND ro.DATAAREAID = replacement_so.DATAAREAID
JOIN CUSTPACKINGSLIPJOUR cpsj ON replacement_so.SALESID = cpsj.SALESID AND replacement_so.DATAAREAID = cpsj.DATAAREAID
JOIN CUSTPACKINGSLIPTRANS cpsl ON cpsj.PACKINGSLIPID = cpsl.PACKINGSLIPID AND cpsj.SALESID = cpsl.SALESID AND cpsj.DATAAREAID = cpsl.DATAAREAID
WHERE ro.SALESTYPE = 3
AND rol.RETURNDISPOSITIONCODEID IN ('[YourReplaceCode1]', '[YourReplaceCode2]')
AND replacement_so.SALESTYPE = 1
AND replacement_so.CREATEDDATETIME > ro.CREATEDDATETIME
-- The join above is a basic example and must be replaced with your system's specific logic for linking returns to replacements.
AND ro.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Closed' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 3 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
st.RETURNITEMNUM AS ReturnCaseId,
'Return Order Cancelled' AS ActivityName,
st.MODIFIEDDATETIME AS EventTime,
st.MODIFIEDBY AS ResponsibleUser,
sl.RETURNDISPOSITIONCODEID AS DispositionCode,
sl.RETURNREASONCODEID AS ReturnReasonCode,
st.SALESORIGINID AS ReturnChannel,
sl.ITEMID AS ProductId
FROM SALESTABLE st
JOIN SALESLINE sl ON st.SALESID = sl.SALESID AND st.DATAAREAID = sl.DATAAREAID
WHERE st.SALESTYPE = 3 AND st.SALESSTATUS = 4 AND st.CREATEDDATETIME BETWEEN '{StartDate}' AND '{EndDate}'; พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เพื่อรวบรวมข้อมูลได้สะดวกขึ้น แล้วเริ่มค้นหาข้อมูลเชิงลึกเพื่อปรับปรุงกระบวนการคืนสินค้าและคืนเงิน เริ่มปรับกระบวนการให้รวดเร็วขึ้นและเพิ่มความพึงพอใจของลูกค้าได้ตั้งแต่วันนี้.
ลดความล่าช้าในการคืนสินค้าและคืนเงิน เริ่มปรับปรุงกระบวนการวันนี้
ลดระยะเวลาของกระบวนการลง 30% และเพิ่มความพึงพอใจของลูกค้า.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จในไม่กี่นาที.