เทมเพลตข้อมูล Order-to-Cash ด้านการเรียกเก็บเงินและออกใบแจ้งหนี้
เทมเพลตข้อมูล Order-to-Cash ด้านการเรียกเก็บเงินและออกใบแจ้งหนี้
- แอตทริบิวต์ที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางดึงข้อมูลจาก SAP S/4HANA
แอตทริบิวต์ Order-to-Cash ด้านการเรียกเก็บเงินและออกใบแจ้งหนี้
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| หมายเลขใบแจ้งหนี้ InvoiceNumber | รหัสเฉพาะของเอกสารวางบิล ซึ่งใช้เป็นรหัสกรณีหลักของกระบวนการออกใบแจ้งหนี้. | ||
| คำอธิบาย หมายเลขใบแจ้งหนี้ หรือที่ SAP เรียกว่าหมายเลขเอกสารวางบิล ใช้ระบุธุรกรรมการวางบิลแต่ละรายการโดยไม่ซ้ำกัน และเป็นรหัสหลักที่เชื่อมโยงกิจกรรมที่เกี่ยวข้องทั้งหมด ตั้งแต่การสร้างและลงบัญชีใบแจ้งหนี้ ไปจนถึงการรับชำระเงินและกระทบยอด ใน process mining แอตทริบิวต์นี้จำเป็นต่อการเชื่อมโยงกรณี เหตุการณ์ทั้งหมดที่มีหมายเลขใบแจ้งหนี้เดียวกันจะถูกรวมเป็นกระบวนการเดียว ทำให้วิเคราะห์วงจรการวางบิลของใบแจ้งหนี้แต่ละรายการได้ตั้งแต่ต้นจนจบ คุณจึงติดตามรอบเวลา ค้นหาความคลาดเคลื่อน และวิเคราะห์เส้นทางของใบแจ้งหนี้แต่ละฉบับได้. เหตุผลที่สำคัญ เป็นรหัสหลักที่เชื่อมกิจกรรมการวางบิลที่เกี่ยวข้องทั้งหมดไว้ในกรณีเดียว ทำให้วิเคราะห์กระบวนการตั้งแต่ต้นจนจบได้. แหล่งข้อมูล ตาราง SAP: VBRK, ฟิลด์: VBELN ตัวอย่าง 900012349000567890009012 | |||
| ชื่อกิจกรรม ActivityName | ชื่อกิจกรรมทางธุรกิจหรือเหตุการณ์ที่เกิดขึ้นในกระบวนการวางบิล เช่น 'ออกใบแจ้งหนี้แล้ว' หรือ 'ได้รับชำระเงินแล้ว'. | ||
| คำอธิบาย ชื่อกิจกรรมระบุขั้นตอนหรือจุดสำคัญในวงจรการวางบิล กิจกรรมเหล่านี้ได้มาจากข้อมูลหลายประเภทใน SAP เช่น รหัสธุรกรรม การเปลี่ยนสถานะเอกสาร หรือรายการบันทึกเฉพาะ เพื่อนำมาสร้างลำดับกระบวนการ การวิเคราะห์ลำดับและความถี่ของกิจกรรมเป็นหัวใจของ process mining ช่วยให้เห็นแผนผังกระบวนการ ค้นพบรูปแบบกระบวนการที่พบบ่อยและพบไม่บ่อย ระบุคอขวดระหว่างขั้นตอน และวัดความถี่ของกิจกรรมที่ไม่เพิ่มคุณค่า เช่น การแก้ไขงานหรือการยกเลิก. เหตุผลที่สำคัญ แอตทริบิวต์นี้กำหนดขั้นตอนในกระบวนการ ทำให้แสดงแผนผังกระบวนการและวิเคราะห์ลำดับ ความแตกต่าง และคอขวดได้. แหล่งข้อมูล ได้มาจากหลายแหล่ง เช่น รหัสธุรกรรม (SY-TCODE) สถานะเอกสารการเปลี่ยนแปลง (ตาราง CDHDR/CDPOS) หรือบันทึกเวิร์กโฟลว์ทางธุรกิจ (เช่น SWW_WI2OBJ). ตัวอย่าง ออกใบแจ้งหนี้แล้วลงบัญชีใบแจ้งหนี้ในระบบบัญชีแล้วได้รับชำระเงินจากลูกค้าแล้วยกเลิกใบแจ้งหนี้แล้ว | |||
| เวลาเกิดเหตุการณ์ EventTime | เวลาที่ระบุอย่างแม่นยำว่ากิจกรรมหรือเหตุการณ์เกิดขึ้นเมื่อใด. | ||
| คำอธิบาย เวลาเกิดเหตุการณ์ระบุวันที่และเวลาของแต่ละกิจกรรม ซึ่งเป็นข้อมูลหลักสำหรับเรียงลำดับกระบวนการตามเวลา เวลานี้จำเป็นต่อการคำนวณระยะเวลา รอบเวลา และเวลารอระหว่างขั้นตอนต่างๆ ในกระบวนการวางบิล ในการวิเคราะห์ ระบบใช้เวลาเกิดเหตุการณ์เพื่อเรียงกิจกรรมตามลำดับ คำนวณตัวชี้วัดประสิทธิภาพสำคัญ เช่น จำนวนวันลูกหนี้การค้า (DSO) และรอบเวลาการออกใบแจ้งหนี้ รวมถึงค้นหาคอขวดที่เกี่ยวข้องกับเวลา ข้อมูลนี้ช่วยให้เห็นการเปลี่ยนแปลงของประสิทธิภาพตามช่วงเวลาและระยะเวลาที่ใช้ในแต่ละขั้นตอนของวงจรการวางบิล. เหตุผลที่สำคัญ ใช้เรียงเหตุการณ์ตามลำดับเวลา ซึ่งจำเป็นต่อการคำนวณตัวชี้วัดด้านเวลา เช่น รอบเวลาและระยะเวลาต่างๆ. แหล่งข้อมูล ดึงข้อมูลจากฟิลด์วันที่และเวลาต่างๆ ตามประเภทกิจกรรม เช่น วันที่และเวลาสร้าง (VBRK-ERDAT, VBRK-ERZET) เวลาที่บันทึกการเปลี่ยนแปลง (CDHDR-UDATE, CDHDR-UTIME) หรือวันที่ลงบัญชี (BKPF-BUDAT). ตัวอย่าง 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| ชื่อผู้ใช้ UserName | รหัสผู้ใช้ของพนักงานที่ดำเนินกิจกรรม. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกรหัสผู้ใช้ SAP ที่รับผิดชอบเหตุการณ์ เช่น การสร้างใบแจ้งหนี้ การลงบัญชีเอกสาร หรือการตัดยอดการชำระเงิน ทำให้เชื่อมโยงขั้นตอนในกระบวนการกับบุคคลหรือทีมที่ดำเนินการได้ การวิเคราะห์ตามชื่อผู้ใช้ช่วยค้นหาผู้ที่ทำงานได้ดี ความต้องการฝึกอบรม หรือความไม่สมดุลของภาระงาน นอกจากนี้ยังสำคัญต่อการวิเคราะห์การปฏิบัติตามข้อกำหนด เพราะช่วยระบุผู้ที่ดำเนินกิจกรรมสำคัญ และทำความเข้าใจว่าผู้ใช้แต่ละรายทำขั้นตอนเดียวกันแตกต่างกันอย่างไร. เหตุผลที่สำคัญ เชื่อมกิจกรรมในกระบวนการกับผู้ใช้แต่ละราย ทำให้วิเคราะห์ภาระงาน ประสิทธิภาพ และการปฏิบัติตามข้อกำหนดในระดับบุคคลหรือทีมได้. แหล่งข้อมูล สำหรับเหตุการณ์สร้างข้อมูล จะอยู่ใน VBRK-ERNAM ส่วนการเปลี่ยนแปลงภายหลังจะอยู่ในตารางประวัติการเปลี่ยนแปลง เช่น CDHDR-USERNAME หรือในบันทึกเวิร์กโฟลว์. ตัวอย่าง CBURNSHSIMPSONLLEONARD | |||
| ชื่อลูกค้า CustomerName | ชื่อลูกค้าที่ออกใบแจ้งหนี้ให้. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุชื่อตามกฎหมายของลูกค้าที่ถูกเรียกเก็บเงิน โดยดึงข้อมูลจากข้อมูลหลักลูกค้าส่วนกลางใน SAP การวิเคราะห์กระบวนการแยกตามลูกค้าช่วยค้นหารูปแบบเฉพาะของแต่ละบัญชี เช่น ลูกค้ารายใดชำระเงินล่าช้าเป็นประจำ รายใดยื่นข้อโต้แย้งบ่อยที่สุด หรือบัญชีใดมีกระบวนการวางบิลที่ไม่มีประสิทธิภาพมากที่สุด ข้อมูลนี้ช่วยให้บริหารความสัมพันธ์กับลูกค้าและกำหนดแนวทางติดตามหนี้ได้ตรงจุด. เหตุผลที่สำคัญ ช่วยวิเคราะห์โดยแยกตามลูกค้า เพื่อค้นหาพฤติกรรมการชำระเงิน ความถี่ของข้อโต้แย้ง และความไม่มีประสิทธิภาพของกระบวนการในแต่ละบัญชี. แหล่งข้อมูล ดึงจากตารางข้อมูลหลักลูกค้า KNA1 (ฟิลด์: NAME1) โดยเชื่อมผ่านรหัสผู้ชำระเงินในส่วนหัวใบแจ้งหนี้ (VBRK-KUNRG). ตัวอย่าง Springfield Power PlantKwik-E-MartCyberdyne Systems | |||
| ภูมิภาค Region | ภูมิภาคทางภูมิศาสตร์ของลูกค้า. | ||
| คำอธิบาย แอตทริบิวต์ภูมิภาคระบุพื้นที่ทางภูมิศาสตร์ เช่น รัฐหรือจังหวัด ที่อยู่ของลูกค้า โดยทั่วไปข้อมูลนี้เป็นส่วนหนึ่งของระเบียนข้อมูลหลักลูกค้า แอตทริบิวต์นี้เป็นข้อมูลสำคัญสำหรับแดชบอร์ดประสิทธิภาพการวางบิลรายภูมิภาค ใช้เปรียบเทียบตัวชี้วัดสำคัญ เช่น รอบเวลา อัตราข้อผิดพลาด และ DSO ระหว่างพื้นที่ต่างๆ การเปรียบเทียบนี้ช่วยให้เห็นความแตกต่างด้านการดำเนินกระบวนการ การปฏิบัติตามข้อกำหนด หรือประสิทธิภาพในแต่ละภูมิภาค เพื่อนำไปปรับปรุงและกำหนดมาตรฐานแนวปฏิบัติที่ดีได้ตรงจุด. เหตุผลที่สำคัญ ช่วยเปรียบเทียบประสิทธิภาพการวางบิลในแต่ละพื้นที่ เพื่อค้นหาความแตกต่างระหว่างภูมิภาคและกำหนดมาตรฐานกระบวนการ. แหล่งข้อมูล ดึงจากตารางข้อมูลหลักลูกค้า KNA1 (ฟิลด์: REGIO) โดยเชื่อมผ่านรหัสผู้ชำระเงินในส่วนหัวใบแจ้งหนี้ (VBRK-KUNRG). ตัวอย่าง CANYTXBA | |||
| ยอดเงินในใบแจ้งหนี้ InvoiceAmount | มูลค่าสุทธิรวมของใบแจ้งหนี้. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงมูลค่ารวมของสินค้าหรือบริการที่เรียกเก็บเงิน โดยไม่รวมภาษี เป็นข้อมูลทางการเงินพื้นฐานของใบแจ้งหนี้แต่ละกรณี ยอดเงินในใบแจ้งหนี้ใช้วิเคราะห์ได้หลายรูปแบบ เช่น แบ่งกระบวนการตามมูลค่าเพื่อดูว่าใบแจ้งหนี้มูลค่าสูงมีขั้นตอนต่างออกไปหรือล่าช้ากว่าหรือไม่ นอกจากนี้ยังใช้จัดทำรายงานทางการเงินและคำนวณมูลค่ารวมของลูกหนี้ค้างชำระได้ด้วย. เหตุผลที่สำคัญ ระบุมูลค่าทางการเงินของใบแจ้งหนี้แต่ละฉบับ ช่วยให้วิเคราะห์ตามมูลค่า จัดลำดับความสำคัญในการติดตามหนี้ และประเมินผลกระทบทางการเงินได้. แหล่งข้อมูล ตาราง SAP: VBRK, ฟิลด์: NETWR ตัวอย่าง 1500.0025000.50125.75 | |||
| วันครบกำหนดชำระ PaymentDueDate | วันที่คาดว่าลูกค้าจะชำระใบแจ้งหนี้. | ||
| คำอธิบาย วันครบกำหนดชำระคำนวณจากวันที่ใบแจ้งหนี้และเงื่อนไขการชำระเงินที่ตกลงกันไว้ เป็นวันสุดท้ายที่ต้องได้รับชำระก่อนที่ใบแจ้งหนี้จะเลยกำหนด แอตทริบิวต์นี้จำเป็นต่อการติดตามประสิทธิผลของการติดตามหนี้และการคาดการณ์กระแสเงินสด ใช้คำนวณ KPI อัตราการชำระเงินตรงเวลาและจัดกลุ่มใบแจ้งหนี้ในรายงานอายุหนี้ การวิเคราะห์ความแตกต่างระหว่างวันครบกำหนดกับวันที่ได้รับเงินจริงช่วยประเมินประสิทธิผลของเงื่อนไขการชำระเงินแต่ละแบบได้. เหตุผลที่สำคัญ กำหนดวันสุดท้ายที่ลูกค้าต้องชำระ จึงสำคัญต่อการคำนวณอัตราการชำระเงินตรงเวลาและการบริหารลูกหนี้การค้า. แหล่งข้อมูล ระบบไม่ได้จัดเก็บวันที่นี้ไว้โดยตรง แต่คำนวณจากวันที่ใบแจ้งหนี้ (VBRK-FKDAT) และรหัสเงื่อนไขการชำระเงิน (VBRK-ZTERM) โดยใช้ฟังก์ชันกำหนดวันที่มาตรฐานของ SAP. ตัวอย่าง 2023-04-192023-05-012023-06-17 | |||
| วันที่ใบแจ้งหนี้ InvoiceDate | วันที่อย่างเป็นทางการที่ออกใบแจ้งหนี้ให้ลูกค้า. | ||
| คำอธิบาย วันที่ใบแจ้งหนี้ หรือวันที่วางบิลใน SAP เป็นจุดเริ่มต้นของการคำนวณทางการเงินหลายรายการ ใช้กำหนดเงื่อนไขการชำระเงิน วันครบกำหนด และอายุของลูกหนี้ วันที่นี้เป็นแอตทริบิวต์สำคัญระดับกรณีสำหรับการวิเคราะห์ทางการเงิน ใช้เป็นฐานคำนวณ KPI จำนวนวันลูกหนี้การค้า (DSO) และจัดทำรายงานอายุใบแจ้งหนี้ค้างชำระ ซึ่งเป็นเครื่องมือสำคัญในการบริหารกระแสเงินสดและติดตามหนี้. เหตุผลที่สำคัญ เป็นวันที่หลักสำหรับการคำนวณทางการเงิน ใช้เป็นจุดเริ่มต้นในการคำนวณ DSO วันครบกำหนดชำระ และอายุใบแจ้งหนี้. แหล่งข้อมูล ตาราง SAP: VBRK, ฟิลด์: FKDAT ตัวอย่าง 2023-03-202023-04-012023-05-18 | |||
| เวลาสิ้นสุด EndTime | เวลาที่ระบุอย่างแม่นยำว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด. | ||
| คำอธิบาย เวลาสิ้นสุดระบุว่ากิจกรรมเสร็จสิ้นเมื่อใด ใน process mining มักอนุมานจากเวลาเริ่มต้นของกิจกรรมถัดไปในเคส หรือดึงจากระบบโดยตรงหากระบบบันทึกทั้งเหตุการณ์เริ่มต้นและสิ้นสุด แอตทริบิวต์นี้จำเป็นสำหรับคำนวณเวลาที่ใช้ดำเนินกิจกรรมแต่ละรายการ โดยนำเวลาเริ่มต้นมาลบออกจากเวลาสิ้นสุด ก็จะทราบระยะเวลาของแต่ละขั้นตอน ซึ่งสำคัญต่อการวิเคราะห์คอขวด เช่น การระบุความล่าช้าในขั้นตอนอนุมัติใบแจ้งหนี้. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยคำนวณระยะเวลาที่ใช้ดำเนินกิจกรรมแต่ละรายการได้อย่างแม่นยำ ซึ่งเป็นพื้นฐานสำคัญของการวิเคราะห์คอขวด. แหล่งข้อมูล แอตทริบิวต์นี้คำนวณขึ้นสำหรับ process mining โดยทั่วไปใช้เวลา StartTime ของเหตุการณ์ถัดไปในลำดับของเคส ในบางกรณีอาจมีตารางเฉพาะที่บันทึกเวลาสิ้นสุดไว้. ตัวอย่าง 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| เงื่อนไขการชำระเงิน PaymentTerms | รหัสที่กำหนดเงื่อนไขการชำระเงิน เช่น ระยะเวลาที่ให้ชำระเงิน. | ||
| คำอธิบาย เงื่อนไขการชำระเงินเป็นข้อตกลงที่กำหนดไว้ล่วงหน้าระหว่างบริษัทกับลูกค้า เพื่อระบุวันครบกำหนดชำระใบแจ้งหนี้ ตัวอย่างเช่น 'Net 30' หมายถึงต้องชำระภายใน 30 วัน ส่วน '2/10 Net 30' หมายถึงได้รับส่วนลด 2% หากชำระภายใน 10 วัน มิฉะนั้นต้องชำระภายใน 30 วัน การวิเคราะห์ตามเงื่อนไขการชำระเงินช่วยประเมินได้ว่าเงื่อนไขแต่ละแบบมีประสิทธิภาพเพียงใด เมื่อนำเงื่อนไขที่ใช้มาเปรียบเทียบกับระยะเวลาที่ได้รับเงินจริง บริษัทจะเห็นว่าเงื่อนไขใดช่วยให้ลูกค้าชำระเงินได้เร็ว และปรับเงื่อนไขเพื่อเพิ่มกระแสเงินสดได้. เหตุผลที่สำคัญ ข้อมูลนี้ระบุกำหนดการชำระเงินที่ตกลงกันไว้ และช่วยวิเคราะห์ได้ว่าเงื่อนไขใดมีประสิทธิภาพที่สุดในการทำให้ลูกค้าชำระเงินตรงเวลา. แหล่งข้อมูล ตาราง SAP: VBRK, ฟิลด์: ZTERM ตัวอย่าง Z030Z060ZB60 | |||
| ชำระตรงเวลา IsPaidOnTime | ค่าบูลีนที่ระบุว่าใบแจ้งหนี้ได้รับชำระภายในหรือก่อนวันครบกำหนดหรือไม่. | ||
| คำอธิบาย แอตทริบิวต์นี้คำนวณโดยเปรียบเทียบวันที่ได้รับชำระเงินจริงกับวันครบกำหนดชำระที่กำหนดไว้ ผลลัพธ์เป็น 'true' หากชำระตรงเวลา และ 'false' หากชำระล่าช้า ค่านี้ช่วยให้คำนวณและแสดง KPI อัตราการชำระตรงเวลาได้ง่ายขึ้น อีกทั้งยังกรองและแบ่งกลุ่มข้อมูลเพื่อเปรียบเทียบใบแจ้งหนี้ที่ชำระล่าช้ากับใบแจ้งหนี้ที่ชำระตรงเวลาได้ ช่วยค้นหารูปแบบที่เกี่ยวข้องกับลูกค้า ภูมิภาค หรือเงื่อนไขการชำระเงิน ซึ่งอาจเป็นสาเหตุของการชำระล่าช้า. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยวัดผลได้ง่ายขึ้น โดยระบุชัดเจนว่าใบแจ้งหนี้แต่ละรายการชำระตรงเวลาหรือล่าช้า และรองรับ KPI อัตราการชำระตรงเวลาโดยตรง. แหล่งข้อมูล ฟิลด์นี้คำนวณจากการเปรียบเทียบเวลาของกิจกรรม 'ได้รับชำระเงินจากลูกค้า' กับค่าในแอตทริบิวต์ 'PaymentDueDate'. ตัวอย่าง truefalse | |||
| ประเภทเอกสารเรียกเก็บเงิน BillingDocumentType | รหัสที่ใช้จัดประเภทเอกสารเรียกเก็บเงิน เช่น ใบแจ้งหนี้ ใบลดหนี้ หรือเอกสารยกเลิก. | ||
| คำอธิบาย ประเภทเอกสารเรียกเก็บเงินเป็นฟิลด์สำคัญที่ใช้จัดหมวดหมู่รายการในกระบวนการเรียกเก็บเงิน และกำหนดวิธีประมวลผลเอกสาร รวมถึงช่วงหมายเลขเอกสารและกฎการบันทึกบัญชี แอตทริบิวต์นี้ช่วยกรองกระบวนการเพื่อวิเคราะห์รายการแต่ละประเภทโดยเฉพาะ ตัวอย่างเช่น สร้างมุมมองกระบวนการสำหรับใบลดหนี้โดยเฉพาะ เพื่อทำความเข้าใจเหตุผลและลำดับการแก้ไขรายการทางการเงิน หรือแยกวิเคราะห์ใบแจ้งหนี้ปกติออกจากรายการยกเลิก เพื่อให้เห็นภาพกระบวนการเรียกเก็บเงินหลักชัดเจนขึ้น. เหตุผลที่สำคัญ ข้อมูลนี้ใช้จัดประเภทของรายการ ทำให้วิเคราะห์ลำดับเอกสารแต่ละประเภทได้โดยเฉพาะ เช่น ใบแจ้งหนี้ปกติ ใบลดหนี้ หรือรายการยกเลิก. แหล่งข้อมูล ตาราง SAP: VBRK, ฟิลด์: FKART ตัวอย่าง F2G2S1L2 | |||
| รหัสบริษัท CompanyCode | หน่วยงานที่ใช้บันทึกรายการทางการเงิน. | ||
| คำอธิบาย รหัสบริษัทเป็นหน่วยงานพื้นฐานใน SAP Financials ซึ่งแทนบริษัทที่มีสถานะทางกฎหมายเป็นอิสระและจัดทำงบการเงินแยกกัน เอกสารเรียกเก็บเงินแต่ละฉบับจะกำหนดรหัสบริษัทไว้ การวิเคราะห์ตามรหัสบริษัทจำเป็นสำหรับองค์กรที่มีหลายบริษัท เพื่อเปรียบเทียบผลการดำเนินงานของกระบวนการ ตัวชี้วัดทางการเงิน เช่น DSO และการปฏิบัติตามข้อกำหนดของแต่ละนิติบุคคล นอกจากนี้ยังใช้เป็นตัวกรองระดับองค์กรในแดชบอร์ดกระบวนการได้. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยแบ่งการวิเคราะห์กระบวนการตามนิติบุคคล เพื่อเปรียบเทียบผลการดำเนินงานและรวมข้อมูลทางการเงินทั่วทั้งองค์กร. แหล่งข้อมูล ตาราง SAP: VBRK, ฟิลด์: BUKRS ตัวอย่าง 10002000US01 | |||
| ระบบต้นทาง SourceSystem | ระบุระบบต้นทางที่ใช้ดึงข้อมูล. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูล ซึ่งมีประโยชน์อย่างยิ่งเมื่อมี SAP หลายระบบหรือระบบอื่นที่เชื่อมต่ออยู่ โดยทั่วไปจะประกอบด้วยรหัสระบบและหมายเลขไคลเอนต์ ในการวิเคราะห์ แอตทริบิวต์นี้ช่วยแยกกระบวนการและเปรียบเทียบประสิทธิภาพระหว่างระบบหรือหน่วยงานต่างๆ อีกทั้งยังช่วยตรวจสอบที่มาของข้อมูลและให้บริบท โดยเฉพาะเมื่อรวมข้อมูลจากหลายแหล่งเพื่อดูภาพรวมกระบวนการ. เหตุผลที่สำคัญ ช่วยให้ทราบที่มาของข้อมูลอย่างชัดเจน ซึ่งสำคัญเมื่อใช้หลายระบบและช่วยสนับสนุนการกำกับดูแลข้อมูล. แหล่งข้อมูล โดยทั่วไปเป็นค่าคงที่ที่กำหนดระหว่างการดึงข้อมูล มักรวมรหัสระบบ (SY-SYSID) และไคลเอนต์ (SY-MANDT) เข้าด้วยกัน. ตัวอย่าง S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| สกุลเงิน Currency | รหัสสกุลเงินของยอดเงินในใบแจ้งหนี้. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุสกุลเงินของยอดเงินในใบแจ้งหนี้ เช่น USD, EUR หรือ JPY เพื่อให้มีบริบทที่จำเป็นสำหรับมูลค่าเงินทั้งหมด สำหรับองค์กรที่ดำเนินงานในหลายประเทศ สกุลเงินมีความสำคัญต่อการวิเคราะห์และรายงานทางการเงินให้ถูกต้อง โดยสามารถแปลงยอดเงินทั้งหมดเป็นสกุลเงินกลางสำหรับรายงาน และเปรียบเทียบประสิทธิภาพการวางบิลระหว่างภูมิภาคที่ใช้สกุลเงินท้องถิ่นต่างกันได้. เหตุผลที่สำคัญ ให้บริบทที่จำเป็นสำหรับมูลค่าเงินทั้งหมด ช่วยให้วิเคราะห์และรายงานทางการเงินได้ถูกต้อง โดยเฉพาะในการปฏิบัติงานหลายประเทศ. แหล่งข้อมูล ตาราง SAP: VBRK, ฟิลด์: WAERK ตัวอย่าง USDEURGBP | |||
| สถานะการชำระเงิน PaymentStatus | สถานะปัจจุบันของการชำระใบแจ้งหนี้ เช่น ค้างชำระ ชำระแล้ว หรือเกินกำหนด. | ||
| คำอธิบาย สถานะการชำระเงินแสดงให้เห็นว่าใบแจ้งหนี้อยู่ในขั้นตอนใดของกระบวนการติดตามหนี้ โดยไม่ได้เก็บไว้ในฟิลด์เดียวของ SAP แต่คำนวณจากสถานะการเคลียร์รายการของเอกสารบัญชีที่เกี่ยวข้อง แอตทริบิวต์นี้จำเป็นสำหรับแดชบอร์ดอายุใบแจ้งหนี้ค้างชำระ ช่วยแบ่งกลุ่มใบแจ้งหนี้ที่ยังค้างชำระตามสถานะและอายุหนี้ เพื่อให้ทีมติดตามหนี้จัดลำดับงานได้อย่างเหมาะสม นอกจากนี้ การติดตามการเปลี่ยนสถานะยังช่วยให้เห็นการดำเนินงานของกระบวนการติดตามหนี้ด้วย. เหตุผลที่สำคัญ ข้อมูลนี้แสดงสถานะการติดตามหนี้ของใบแจ้งหนี้ได้อย่างชัดเจน ช่วยบริหารลูกหนี้และจัดลำดับความสำคัญของการติดตามชำระเงิน. แหล่งข้อมูล ได้จากการตรวจสอบสถานะการเคลียร์รายการของเอกสารบัญชี (VBRK-BELNR) ในตารางการเงิน เช่น BSID (รายการคงค้าง) และ BSAD (รายการที่เคลียร์แล้ว). ตัวอย่าง ค้างชำระชำระแล้วเกินกำหนดชำระบางส่วน | |||
| หมายเลขใบสั่งขาย SalesOrderNumber | รหัสของใบสั่งขายต้นทางที่นำไปสู่การออกใบแจ้งหนี้. | ||
| คำอธิบาย หมายเลขใบสั่งขายเชื่อมโยงเอกสารเรียกเก็บเงินกลับไปยังกิจกรรมการขายก่อนหน้า ใบสั่งขายหนึ่งรายการอาจมีใบแจ้งหนี้ตั้งแต่หนึ่งฉบับขึ้นไป ลิงก์นี้จึงแสดงลำดับเอกสารได้ครบถ้วน แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์ Order-to-Cash ตั้งแต่ต้นจนจบ เพราะช่วยขยายมุมมองกระบวนการไปยังกิจกรรมก่อนการเรียกเก็บเงิน และเชื่อมโยงปัญหาการเรียกเก็บเงินกับสาเหตุที่อาจเกิดขึ้นในขั้นตอนสร้างใบสั่งขายหรือดำเนินการตามคำสั่งซื้อ ตัวอย่างเช่น ใช้คำนวณระยะเวลาตั้งแต่ดำเนินการตามคำสั่งซื้อเสร็จจนออกใบแจ้งหนี้. เหตุผลที่สำคัญ ข้อมูลนี้เชื่อมใบแจ้งหนี้กับใบสั่งขายต้นทาง ทำให้เห็นกระบวนการ Order-to-Cash ตั้งแต่ต้นจนจบ ไม่จำกัดเฉพาะขั้นตอนการเรียกเก็บเงิน. แหล่งข้อมูล ตาราง SAP: VBRP (ข้อมูลรายการเอกสารเรียกเก็บเงิน), ฟิลด์: AUBEL ตัวอย่าง 100001231000045610000789 | |||
| เหตุผลที่โต้แย้งใบแจ้งหนี้ CustomerDisputeReason | เหตุผลที่ลูกค้าแจ้งเมื่อโต้แย้งใบแจ้งหนี้. | ||
| คำอธิบาย เมื่อลูกค้าโต้แย้งใบแจ้งหนี้ มักมีการบันทึกเหตุผลไว้ เช่น ราคาไม่ถูกต้อง จำนวนสินค้าไม่ตรง หรือสินค้าเสียหาย ข้อมูลนี้อาจจัดเก็บในโมดูล SAP Dispute Management หรือบันทึกเป็นข้อความ การวิเคราะห์เหตุผลที่โต้แย้งเป็นพื้นฐานสำคัญของ KPI อัตราข้อผิดพลาดในการเรียกเก็บเงินและการวิเคราะห์ข้อผิดพลาด ช่วยระบุต้นตอของการเรียกเก็บเงินที่ไม่ถูกต้อง เพื่อให้บริษัทแก้ไขปัญหาที่เกิดซ้ำในกระบวนการก่อนหน้า ปรับปรุงคุณภาพใบแจ้งหนี้ และเพิ่มความพึงพอใจของลูกค้า. เหตุผลที่สำคัญ ข้อมูลนี้อธิบายสาเหตุที่ลูกค้าโต้แย้งใบแจ้งหนี้ ช่วยให้เห็นต้นตอของข้อผิดพลาดในการเรียกเก็บเงินและความไม่พอใจของลูกค้าโดยตรง. แหล่งข้อมูล หากใช้ SAP Dispute Management จะค้นหาข้อมูลนี้ได้จากตาราง เช่น UDM_DISPUTE หากไม่ได้ใช้ อาจดึงข้อมูลจากรหัสเหตุผลในเอกสารที่เกี่ยวข้องหรือจากฟิลด์ข้อความ. ตัวอย่าง ราคาไม่ถูกต้องจำนวนไม่ตรงได้รับสินค้าเสียหาย | |||
| เหตุผลในการออกใบลดหนี้ CreditMemoReason | รหัสเหตุผลที่ระบุว่าเหตุใดจึงออกใบลดหนี้. | ||
| คำอธิบาย เมื่อใบแจ้งหนี้มีข้อผิดพลาดและต้องออกใบลดหนี้ โดยทั่วไปจะกำหนดเหตุผลไว้ในเอกสารใบลดหนี้ เพื่อจัดหมวดหมู่สาเหตุของข้อผิดพลาดในการเรียกเก็บเงินอย่างเป็นระบบ แอตทริบิวต์นี้ช่วยติดตาม KPI อัตราข้อผิดพลาดในการเรียกเก็บเงิน เมื่อนำเหตุผลในการออกใบลดหนี้มารวบรวมและวิเคราะห์ บริษัทจะระบุข้อผิดพลาดที่พบบ่อยได้ เช่น การตั้งราคาผิดหรือการคืนสินค้า จากนั้นนำผลวิเคราะห์ไปปรับปรุงกระบวนการ เพื่อลดการแก้ไขรายการทางการเงินและการทำงานซ้ำ. เหตุผลที่สำคัญ ข้อมูลนี้จัดหมวดหมู่เหตุผลในการออกใบลดหนี้ ช่วยระบุสาเหตุของข้อผิดพลาดในการเรียกเก็บเงินที่พบบ่อยและนำไปปรับปรุงคุณภาพได้. แหล่งข้อมูล ตาราง SAP: VBRK, ฟิลด์: AUGRU (เหตุผลของคำสั่งซื้อ) ฟิลด์นี้ใช้กับคำขอใบลดหนี้หรือใบเพิ่มหนี้ ซึ่งจะนำไปออกเอกสารเรียกเก็บเงินต่อไป. ตัวอย่าง 001 - ส่วนต่างราคา002 - คุณภาพไม่ดี005 - ลูกค้าคืนสินค้า | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ระบุว่าดึงหรือรีเฟรชข้อมูลของเหตุการณ์นี้ครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงข้อมูลจากระบบต้นทางครั้งล่าสุด เป็นฟิลด์ข้อมูลเมตาที่สำคัญต่อการตรวจสอบว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด ข้อมูลนี้ใช้ตรวจสอบความใหม่ของผลการวิเคราะห์และจัดการกำหนดการรีเฟรชข้อมูล เพื่อให้ผู้เกี่ยวข้องทราบว่าข้อมูลเป็นปัจจุบันเพียงใดเมื่อตัดสินใจจากแดชบอร์ดและข้อมูลเชิงลึกจาก process mining. เหตุผลที่สำคัญ แสดงว่าข้อมูลเป็นปัจจุบันเพียงใด ซึ่งสำคัญต่อความน่าเชื่อถือของผลวิเคราะห์และการประเมินว่าข้อมูลยังสะท้อนสถานะการปฏิบัติงานในปัจจุบันหรือไม่. แหล่งข้อมูล ระบบสร้างและประทับเวลานี้ลงในแต่ละระเบียนระหว่างกระบวนการดึงและโหลดข้อมูล (ETL). ตัวอย่าง 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
กิจกรรม Order-to-Cash ด้านการเรียกเก็บเงินและออกใบแจ้งหนี้
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| ได้รับชำระเงินจากลูกค้าแล้ว | กิจกรรมนี้หมายถึงการบันทึกเงินที่ลูกค้าชำระเข้ามาในระบบการเงิน ณ ขั้นตอนนี้อาจยังไม่ได้นำเงินไปตัดกับใบแจ้งหนี้รายการใดโดยเฉพาะ แต่ระบบบันทึกรับเงินแล้ว. | ||
| เหตุผลที่สำคัญ เป็นจุดสำคัญในการคำนวณจำนวนวันลูกหนี้การค้า (DSO) แสดงว่าได้รับเงินแล้ว แม้ยังอยู่ระหว่างกระทบยอด. แหล่งข้อมูล บันทึกจากวันที่ลงบัญชี (BKPF-BUDAT) ของเอกสารรับชำระเงินจากลูกค้า ซึ่งโดยทั่วไปเป็นเอกสารประเภท 'DZ' ในตาราง BKPF. บันทึก อ้างอิงเหตุการณ์จากการสร้างเอกสารรับชำระเงินใน BKPF/BSEG. ประเภทเหตุการณ์ explicit | |||
| นำเงินรับชำระไปตัดยอดและกระทบยอดแล้ว | หมายถึงเวลาที่จับคู่เงินรับชำระจากลูกค้ากับรายการใบแจ้งหนี้ค้างชำระ และตัดรายการนั้นออกจากบัญชีย่อยลูกหนี้ กิจกรรมนี้ทำให้ธุรกรรมเสร็จสมบูรณ์ในมุมมองทางการเงิน. | ||
| เหตุผลที่สำคัญ ใช้วัดประสิทธิภาพของกระบวนการนำเงินรับชำระไปตัดยอด หากล่าช้า ข้อมูลสถานะบัญชีลูกค้าอาจคลาดเคลื่อนและทำให้ทีมติดตามหนี้ต้องทำงานเพิ่มโดยไม่จำเป็น. แหล่งข้อมูล บันทึกเหตุการณ์จากวันที่ตัดยอด (BSEG-AUGDT) ในรายการเอกสารบัญชีของใบแจ้งหนี้ต้นฉบับ โดยระบบจะระบุวันที่นี้เมื่อเอกสารตัดยอดปิดรายการดังกล่าว. บันทึก บันทึกจากฟิลด์วันที่ตัดยอด (AUGDT) ในตาราง BSEG/ACDOCA สำหรับรายการใบแจ้งหนี้. ประเภทเหตุการณ์ explicit | |||
| ปิดใบแจ้งหนี้แล้ว | กิจกรรมนี้หมายถึงสถานะสุดท้ายของใบแจ้งหนี้ที่ชำระครบแล้ว ในทางปฏิบัติมีความหมายเดียวกับ 'นำเงินรับชำระไปตัดยอดและกระทบยอดแล้ว' และแสดงว่ากระบวนการของใบแจ้งหนี้นี้เสร็จสมบูรณ์. | ||
| เหตุผลที่สำคัญ เป็นเหตุการณ์สิ้นสุดหลักของเส้นทางปกติ การวัดเวลาตั้งแต่ต้นจนถึงจุดนี้ช่วยให้เห็นภาพครบถ้วนของวงจรการวางบิลและออกใบแจ้งหนี้. แหล่งข้อมูล อนุมานจากสถานะของรายการลูกค้าในเอกสารบัญชี รายการจะถือว่าปิดหรือ 'ตัดยอดแล้ว' เมื่อมีการระบุวันที่ตัดยอด (BSEG-AUGDT) และเอกสารตัดยอด (BSEG-AUGBL). บันทึก อนุมานจากการมีวันที่ตัดยอด (AUGDT) ในตาราง BSEG/ACDOCA สำหรับรายการใบแจ้งหนี้. ประเภทเหตุการณ์ inferred | |||
| ลงบัญชีใบแจ้งหนี้ในระบบบัญชีแล้ว | หมายถึงการลงบัญชีเอกสารวางบิลในโมดูลบัญชีการเงินสำเร็จ นี่คือจุดสำคัญที่ใบแจ้งหนี้กลายเป็นรายการลูกหนี้อย่างเป็นทางการ และสร้างรายการในบัญชีแยกประเภททั่วไป. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ยืนยันว่าใบแจ้งหนี้เป็นเอกสารทางการเงินที่มีผลตามกฎหมาย เวลาตั้งแต่สร้างจนถึงลงบัญชีเป็นตัวชี้วัดประสิทธิภาพที่สำคัญ ซึ่งสะท้อนความคล่องตัวในการดำเนินงานภายใน. แหล่งข้อมูล บันทึกเหตุการณ์เมื่อสร้างเอกสารบัญชีที่เกี่ยวข้อง โดยเชื่อมเอกสารวางบิล (VBRK-VBELN) กับเอกสารบัญชี (BKPF-BELNR) ผ่าน VBRK-BELNR และใช้วันที่ลงบัญชี BKPF-BUDAT. บันทึก บันทึกจากวันที่ลงบัญชี (BUDAT) ของเอกสารบัญชีในตาราง BKPF ที่เชื่อมกับเอกสารวางบิล. ประเภทเหตุการณ์ explicit | |||
| ออกใบแจ้งหนี้แล้ว | กิจกรรมนี้หมายถึงการสร้างเอกสารวางบิลในระบบ ระบบบันทึกเหตุการณ์นี้เมื่อผู้ใช้ทำธุรกรรม เช่น VF01 หรือเมื่อมีงานเบื้องหลังสร้างใบแจ้งหนี้ ทำให้เกิดรายการใหม่ในตารางส่วนหัวเอกสารวางบิล. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการวางบิล การวิเคราะห์เวลาตั้งแต่ส่งมอบคำสั่งซื้อจนถึงกิจกรรมนี้มีความสำคัญต่อการวัดรอบเวลาการออกใบแจ้งหนี้และค้นหาความล่าช้าในช่วงต้นของกระบวนการ. แหล่งข้อมูล ระบบบันทึกข้อมูลเมื่อสร้างเอกสารในตาราง VBRK ของ SAP S/4HANA (ข้อมูลส่วนหัวเอกสารวางบิล) โดยใช้วันที่สร้าง (VBRK-ERDAT) และเวลาสร้าง (VBRK-ERZET) เป็นเวลาเหตุการณ์. บันทึก บันทึกเหตุการณ์จากเวลาที่สร้างระเบียนเอกสารวางบิลในตาราง VBRK. ประเภทเหตุการณ์ explicit | |||
| ถึงวันครบกำหนดชำระ | เหตุการณ์ที่คำนวณขึ้นเพื่อระบุวันที่ครบกำหนดชำระใบแจ้งหนี้ตามเงื่อนไขการชำระเงินที่ตกลงกันไว้ ไม่ใช่เหตุการณ์จากธุรกรรมโดยตรง แต่คำนวณจากข้อมูลใบแจ้งหนี้. | ||
| เหตุผลที่สำคัญ ใช้เป็นเกณฑ์สำคัญในการวัดการชำระเงินตรงเวลาและวิเคราะห์พฤติกรรมการชำระเงินของลูกค้า ช่วยแยกการชำระเงินตรงเวลาออกจากการชำระล่าช้า. แหล่งข้อมูล คำนวณจากวันที่อ้างอิงสำหรับการชำระเงิน (BSEG-ZFBDT) และเงื่อนไขการชำระเงินที่จัดเก็บไว้ในรายการลูกค้าในเอกสารบัญชี. บันทึก คำนวณโดยบวกจำนวนวันตามเงื่อนไขการชำระเงินเข้ากับวันที่อ้างอิงการชำระเงินในรายการเอกสารบัญชี (BSEG). ประเภทเหตุการณ์ calculated | |||
| เปิดกรณีข้อโต้แย้งของลูกค้า | กิจกรรมนี้เกิดขึ้นเมื่อลูกค้าโต้แย้งใบแจ้งหนี้และมีการบันทึกเรื่องไว้ในระบบอย่างเป็นทางการ โดยต้องใช้โมดูล SAP Dispute Management. | ||
| เหตุผลที่สำคัญ ช่วยให้เห็นปัญหาด้านความถูกต้องของการวางบิล คุณภาพสินค้า หรือการส่งมอบบริการที่ทำให้การชำระเงินล่าช้า การวิเคราะห์เหตุผลของข้อโต้แย้งช่วยแก้ปัญหาที่ต้นเหตุและเพิ่มความพึงพอใจของลูกค้า. แหล่งข้อมูล บันทึกเมื่อสร้างกรณีข้อโต้แย้งในตาราง Dispute Management (เช่น UDM_CASE) ซึ่งเชื่อมกับรายการในเอกสารบัญชี. บันทึก บันทึกจากเวลาที่สร้างระเบียนกรณีข้อโต้แย้งซึ่งเชื่อมกับใบแจ้งหนี้. ประเภทเหตุการณ์ explicit | |||
| พบงานแก้ไขการวางบิล | เหตุการณ์ที่คำนวณขึ้นเพื่อระบุวงจรการแก้ไข โดยใบแจ้งหนี้ถูกยกเลิกแล้วสร้างใบใหม่สำหรับคำสั่งซื้อขายเดียวกัน ไม่ใช่ธุรกรรมรายการเดียว แต่เป็นรูปแบบที่เกิดจากเหตุการณ์หลายรายการ. | ||
| เหตุผลที่สำคัญ ใช้วัด KPI อัตราการแก้ไขงานวางบิลโดยนับจำนวนครั้งที่ต้องแก้ไข ทำให้ค้นหาความไม่มีประสิทธิภาพและประเมินต้นทุนจากคุณภาพงานที่ไม่ดีในกระบวนการวางบิลได้. แหล่งข้อมูล คำนวณรูปแบบนี้โดยค้นหาเหตุการณ์ 'ยกเลิกใบแจ้งหนี้แล้ว' ที่ตามด้วยเหตุการณ์ 'ออกใบแจ้งหนี้แล้ว' รายการใหม่ ซึ่งทั้งสองเหตุการณ์อ้างอิงเอกสารต้นทางเดียวกัน เช่น หมายเลขคำสั่งซื้อขาย. บันทึก อนุมานจากลำดับเหตุการณ์ 'ยกเลิกใบแจ้งหนี้แล้ว' และ 'ออกใบแจ้งหนี้แล้ว' ที่อ้างอิงคำสั่งซื้อขายเดียวกัน. ประเภทเหตุการณ์ calculated | |||
| ยกเลิกใบแจ้งหนี้แล้ว | เกิดขึ้นเมื่อยกเลิกใบแจ้งหนี้ที่สร้างไว้ก่อนหน้า ซึ่งโดยทั่วไปต้องสร้างเอกสารยกเลิกที่เกี่ยวข้องด้วย การดำเนินการนี้จะกลับรายการใบแจ้งหนี้ต้นฉบับและผลกระทบทางบัญชี. | ||
| เหตุผลที่สำคัญ บ่งชี้ว่ามีงานแก้ไข การปรับปรุง หรือข้อผิดพลาดในการวางบิล หากยกเลิกบ่อยครั้ง มักสะท้อนปัญหาสำคัญที่ต้นทาง เช่น การบันทึกคำสั่งซื้อขายหรือการตั้งค่าการวางบิล. แหล่งข้อมูล บันทึกเมื่อสร้างเอกสารวางบิลสำหรับการยกเลิก เช่น เอกสารประเภท 'S1' เอกสารใหม่นี้ใน VBRK จะอ้างอิงหมายเลขใบแจ้งหนี้ต้นฉบับในฟิลด์ VBRK-SFAKN. บันทึก บันทึกเหตุการณ์จากวันที่สร้างเอกสารยกเลิกใน VBRK ซึ่งอ้างอิงถึงใบแจ้งหนี้ต้นฉบับ. ประเภทเหตุการณ์ explicit | |||
| ระงับการลงบัญชีใบแจ้งหนี้ | เหตุการณ์นี้เกิดขึ้นเมื่อสร้างใบแจ้งหนี้แล้ว แต่ระบบระงับการลงบัญชีในบัญชีการเงินโดยอัตโนมัติด้วยเหตุผลต่างๆ เช่น การตรวจสอบวงเงินเครดิตหรือข้อมูลไม่สอดคล้องกัน ระบบอนุมานสถานะนี้จากฟิลด์สถานะการลงบัญชีในเอกสารวางบิล. | ||
| เหตุผลที่สำคัญ ช่วยระบุคอขวดที่เกิดเมื่อสร้างใบแจ้งหนี้แล้ว แต่ยังไม่ส่งต่อให้ฝ่ายการเงิน ทำให้วงจรการเรียกเก็บเงินล่าช้าทั้งหมด สถานะนี้ยังเป็นตัวบ่งชี้สำคัญของปัญหาคุณภาพข้อมูลหรือการจัดการเครดิต. แหล่งข้อมูล อนุมานจากฟิลด์สถานะการลงบัญชีในตารางส่วนหัวเอกสารวางบิล (VBRK-RFBSK) สถานะอย่าง 'A' (เอกสารวางบิลถูกระงับไม่ให้ส่งต่อไปยัง FI) หมายถึงมีการระงับรายการ. บันทึก ตรวจสอบค่าฟิลด์สถานะการลงบัญชี (VBRK-RFBSK) ทันทีหลังสร้างใบแจ้งหนี้เพื่ออนุมานเหตุการณ์นี้. ประเภทเหตุการณ์ inferred | |||
| ส่งใบแจ้งหนี้ให้ลูกค้าแล้ว | กิจกรรมนี้ระบุเวลาที่ส่งใบแจ้งหนี้ให้ลูกค้า เช่น ทางไปรษณีย์ อีเมล หรือ EDI วิธีบันทึกเหตุการณ์ขึ้นอยู่กับการตั้งค่าการจัดการผลลัพธ์ใน SAP. | ||
| เหตุผลที่สำคัญ เป็นจุดเริ่มต้นอย่างเป็นทางการของระยะเวลาชำระเงินในมุมมองของลูกค้า หากส่งใบแจ้งหนี้ล่าช้า จะส่งผลโดยตรงต่อจำนวนวันลูกหนี้การค้า (DSO) และกระแสเงินสด. แหล่งข้อมูล ระบบอาจบันทึกเหตุการณ์นี้ไว้อย่างชัดเจนในตารางควบคุมผลลัพธ์ เช่น NAST สำหรับวิธีการแบบเก่า หรือระบบเทียบเท่าใน S/4HANA หากไม่มีบันทึกโดยตรง มักอนุมานว่าเกิดขึ้นพร้อมกับเหตุการณ์ 'ลงบัญชีใบแจ้งหนี้ในระบบบัญชีแล้ว'. บันทึก ตรวจสอบบันทึกการประมวลผลในตารางการจัดการผลลัพธ์ เพื่อหาเวลาที่เชื่อมโยงกับประเภทผลลัพธ์ของใบแจ้งหนี้. ประเภทเหตุการณ์ explicit | |||
| ส่งหนังสือแจ้งเตือนการชำระเงินแล้ว | หมายถึงการส่งหนังสือแจ้งเตือนหรือทวงถามการชำระเงินให้ลูกค้าสำหรับใบแจ้งหนี้ที่เลยกำหนด เป็นเหตุการณ์ที่เกิดขึ้นโดยตรงจากกระบวนการทวงถามอัตโนมัติ. | ||
| เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิผลของกระบวนการทวงถาม และตรวจสอบว่าการแจ้งเตือนช่วยเร่งการชำระเงินหรือไม่ รวมถึงระดับการทวงถามใดได้ผลมากที่สุด. แหล่งข้อมูล บันทึกในตารางประวัติการทวงถาม (MAHNV, MHND) เมื่อเรียกใช้กระบวนการทวงถาม (ธุรกรรม F150) สำหรับรายการค้างชำระของใบแจ้งหนี้. บันทึก บันทึกจากวันที่ดำเนินการทวงถามที่ระบุไว้ในตารางประวัติการทวงถาม. ประเภทเหตุการณ์ explicit | |||
| สร้างใบลดหนี้แล้ว | กิจกรรมนี้หมายถึงการสร้างใบลดหนี้เพื่อแก้ไขการเรียกเก็บเงินเกินหรือคืนยอดเครดิตสำหรับสินค้าที่ส่งคืน โดยมักเชื่อมโยงกับใบแจ้งหนี้ต้นฉบับ. | ||
| เหตุผลที่สำคัญ ช่วยให้เห็นปัญหาที่ทำให้ต้องปรับปรุงรายการทางการเงินหลังวางบิล การวิเคราะห์ใบลดหนี้อาจเผยให้เห็นข้อผิดพลาดด้านราคา ปัญหาสินค้า หรือสาเหตุอื่นที่ทำให้รายได้รั่วไหล. แหล่งข้อมูล สร้างเป็นเอกสารวางบิลใหม่ใน VBRK โดยระบุประเภทการวางบิลสำหรับใบลดหนี้โดยเฉพาะ เช่น 'G2' และมักอ้างอิงคำสั่งซื้อขายหรือใบแจ้งหนี้ต้นฉบับ. บันทึก บันทึกจากการสร้างเอกสารวางบิลประเภทใบลดหนี้ใน VBRK. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
ขั้นตอน
- ข้อกำหนดเบื้องต้น: ตรวจสอบว่าคุณมีบัญชีผู้ใช้ SAP S/4HANA พร้อมสิทธิ์ที่จำเป็นในการเรียกดู Core Data Services (CDS) view โดยต้องมีสิทธิ์อ่าน view เช่น I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase และ I_DunningHistory.
- เข้าใช้เครื่องมือดึงข้อมูล: เข้าสู่ระบบ SAP S/4HANA ของคุณ คุณสามารถใช้เครื่องมือต่างๆ เพื่อเรียกใช้ SQL query กับ CDS view ได้ เช่น SAP HANA Studio, DBeaver ที่เชื่อมต่อผ่าน SAP HANA client หรือปลั๊กอิน SAP Analysis for Microsoft Excel ในคู่มือนี้จะใช้ SQL client ทั่วไป.
- ระบุพารามิเตอร์ของระบบ: ก่อนเรียกใช้ query ให้ระบุ Company Code และช่วงวันที่ที่ต้องการวิเคราะห์ แนะนำให้เริ่มจากขอบเขตข้อมูลที่จำกัด เช่น ข้อมูลย้อนหลัง 3 ถึง 6 เดือน เพื่อให้ query ทำงานได้ภายในเวลาที่เหมาะสม.
- เตรียม SQL Query: คัดลอก SQL query ฉบับเต็มจากส่วน 'query' ในเอกสารนี้ไปยัง SQL client ที่เลือกใช้.
- ปรับค่า Placeholder: แก้ไขค่า placeholder ใน query โดยแทนที่
'YYYY-MM-DD'ด้วยวันที่เริ่มต้นและสิ้นสุดที่ต้องการ และแทนที่'XXXX'ด้วย Company Code เป้าหมาย คุณอาจต้องปรับ placeholder สำหรับประเภทเอกสารใบลดหนี้ เช่น'G2'ให้ตรงกับการตั้งค่าระบบของคุณด้วย. - เรียกใช้ Query: เรียกใช้ SQL query ที่แก้ไขแล้วกับฐานข้อมูล SAP S/4HANA ระยะเวลาประมวลผลขึ้นอยู่กับปริมาณข้อมูลในช่วงวันที่เลือก.
- ตรวจสอบผลลัพธ์: เมื่อ query ทำงานเสร็จ ให้ตรวจสอบผลลัพธ์ ตารางผลลัพธ์ควรเป็นตารางแบน โดยแต่ละแถวแทนกิจกรรมหนึ่งรายการในกระบวนการวางบิล นี่คือบันทึกเหตุการณ์ของคุณ.
- แปลงข้อมูล (หากจำเป็น): query ออกแบบมาให้สร้างข้อมูลในรูปแบบบันทึกเหตุการณ์ที่พร้อมใช้งาน อย่างไรก็ตาม ให้ตรวจสอบรูปแบบ timestamp ว่าเข้ากันได้กับเครื่องมือ process mining ของคุณหรือไม่ query ใช้
ABAP_SYSTEM_UTCL_TO_TIMESTAMPเพื่อแปลงเป็น timestamp มาตรฐาน UTC ซึ่งโดยทั่วไปใช้งานร่วมกับเครื่องมืออื่นได้. - ส่งออกบันทึกเหตุการณ์: ส่งออกผลลัพธ์ทั้งหมดจาก SQL client เป็นไฟล์ CSV และตรวจสอบว่าไฟล์เข้ารหัสแบบ UTF-8 เพื่อป้องกันปัญหาเกี่ยวกับอักขระ.
- อัปโหลดไปยัง ProcessMind: อัปโหลดไฟล์ CSV ที่สร้างขึ้นไปยังแพลตฟอร์ม ProcessMind แล้วจับคู่คอลัมน์ในไฟล์ เช่น InvoiceNumber, ActivityName และ EventTime กับฟิลด์ที่เกี่ยวข้องในเครื่องมือ.
การกำหนดค่า
- ช่วงวันที่: กำหนดวันที่เริ่มต้นและสิ้นสุดในส่วน
WHEREของ Common Table Expression (CTE) แรก แนะนำให้ใช้ข้อมูลย้อนหลัง 3 ถึง 6 เดือนสำหรับการวิเคราะห์ครั้งแรก เพื่อให้สมดุลระหว่างปริมาณข้อมูลกับประสิทธิภาพ ตัวกรองนี้ใช้กับBillingDocumentDate. - Company Code: กรองด้วยค่า
CompanyCodeอย่างน้อยหนึ่งค่า เพื่อจำกัดการดึงข้อมูลให้เหลือเฉพาะนิติบุคคลที่เกี่ยวข้อง การกรองนี้สำคัญต่อการควบคุมขอบเขตข้อมูล. - ประเภทเอกสาร: query มีตรรกะสำหรับระบุใบลดหนี้ตาม
BillingDocumentTypeคุณต้องกำหนด placeholder เช่น('G2', 'CR')ให้ตรงกับประเภทเอกสารใบลดหนี้ที่องค์กรใช้. - ข้อกำหนดเบื้องต้น: ต้องมีสิทธิ์เข้าถึง CDS view ที่เกี่ยวข้อง โดยทีมรักษาความปลอดภัย SAP ต้องกำหนด role และสิทธิ์เฉพาะให้ นอกจากนี้ หากต้องการดึงกิจกรรมอย่าง 'Customer Dispute Opened' หรือ 'Payment Reminder Issued' ระบบต้องใช้งานโมดูล SAP Dispute Management และ SAP Financials Dunning อยู่ด้วย.
- ประสิทธิภาพ: query ใช้การ join และ union หลายรายการ หากชุดข้อมูลมีขนาดใหญ่มาก เช่น ข้อมูลย้อนหลังหลายปี ให้พิจารณาเรียกใช้ในช่วงที่มีการใช้งานน้อย หรือเพิ่มตัวกรองเพื่อจำกัดการดึงข้อมูลในครั้งแรก.
ตัวอย่างคำค้น sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; ขั้นตอน
- ตรวจสอบว่ามีสิทธิ์อ่านโดยตรงใน SAP HANA schema ที่มีตารางวางบิลและตารางการเงินที่เกี่ยวข้อง ขอชื่อ schema รายละเอียดการเชื่อมต่อ ช่วงวันที่ที่ได้รับอนุญาต ขอบเขต Company Code ประเภทเอกสารวางบิล และตัวกรองลูกค้าหรือภูมิภาคจากเจ้าของระบบ แก้ไขเฉพาะ placeholder สำหรับการเชื่อมต่อและตัวกรองใน query.
- ตรวจสอบแหล่งข้อมูล SAP S/4HANA ที่เกี่ยวข้องและการจับคู่ฟิลด์ในระบบเป้าหมาย query ใช้ VBRK และ VBRP สำหรับข้อมูลวางบิล และต้องกำหนดแหล่งข้อมูลสำหรับบัญชี การจัดการผลลัพธ์ การจัดการข้อพิพาท การติดตามหนี้ การรับชำระเงิน การตัดบัญชี และความสัมพันธ์ของเอกสาร แก้ไข placeholder ของแหล่งข้อมูลและฟิลด์ที่อยู่ในวงเล็บเหลี่ยมหลังจากตรวจสอบกับพจนานุกรมข้อมูลของระบบแล้วเท่านั้น.
- กำหนดช่วงเวลาดึงข้อมูลโดยใช้ timestamp เริ่มต้นแบบรวมวันเริ่มต้นและ timestamp สิ้นสุดแบบไม่รวมวันสิ้นสุด แนะนำให้เริ่มด้วยช่วง 3 ถึง 6 เดือน จำกัดข้อมูลตาม Company Code และประเภทการวางบิลเมื่อเหมาะสม เพื่อควบคุมปริมาณข้อมูลและไม่ให้ปะปนกับกระบวนการวางบิลอื่น.
- เรียกใช้ query ด้วยผู้ใช้ฐานข้อมูล HANA ที่มีสิทธิ์อ่านเท่านั้น query จะสร้างแถวเหตุการณ์สำหรับแต่ละกิจกรรมที่ดึงข้อมูลไว้อย่างชัดเจน โดยไม่อาศัย ProcessMind ในการอนุมานเหตุการณ์ กิจกรรมที่คำนวณขึ้น เช่น Payment Due Date Reached และ Billing Rework Identified จะสร้างจากตรรกะ SQL และส่งกลับมาเป็นแถวข้อมูล.
- ตรวจสอบ schema ที่ได้ บันทึกเหตุการณ์ต้องมี InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region และ EndTime ตรวจสอบว่าแต่ละแถวมีค่า InvoiceNumber, ActivityName และ EventTime.
- ตรวจสอบความหมายของเหตุการณ์และความสัมพันธ์ เปรียบเทียบแถว Invoice Generated กับข้อมูลการสร้างส่วนหัวเอกสารวางบิล แถว Invoice Posted To Accounting กับสถานะการบันทึกบัญชี แถว Invoice Sent To Customer กับระเบียนผลลัพธ์ แถวการชำระเงินกับเอกสารบัญชี และแถวการตัดบัญชีกับรายการใบแจ้งหนี้ที่ตัดบัญชีแล้ว ตรวจสอบทุกส่วนที่ขึ้นอยู่กับ placeholder ก่อนนำไปใช้จริง.
- ปรับผลลัพธ์ให้พร้อมใช้กับ ProcessMind ให้มีหนึ่งแถวต่อหนึ่งเหตุการณ์ ใช้ชนิดข้อมูล timestamp และเขตเวลาให้สอดคล้องกัน เก็บ InvoiceNumber เป็นข้อความเพื่อรักษาเลขศูนย์นำหน้า และตรวจสอบว่าค่า ActivityName ตรงกับชื่อกิจกรรมที่กำหนดทุกประการ เรียงตาม InvoiceNumber และ EventTime พร้อมกำหนดลำดับรองที่แน่นอนหากมีหลายเหตุการณ์ที่ใช้ timestamp เดียวกัน.
- ส่งออกผลลัพธ์เป็นไฟล์ CSV ที่เข้ารหัส UTF-8 หรือรูปแบบตารางอื่นที่ ProcessMind รองรับ กำหนด InvoiceNumber เป็นตัวระบุเคส ActivityName เป็นคอลัมน์กิจกรรม และ EventTime เป็น timestamp ของเหตุการณ์ เพิ่มแอตทริบิวต์แนะนำเมื่อมีข้อมูล จากนั้นอัปโหลดไฟล์ผ่านขั้นตอนนำเข้าของ ProcessMind ที่ตั้งค่าไว้ และตรวจสอบจำนวนแถวกับจำนวนกิจกรรมเป็นขั้นตอนสุดท้าย.
การกำหนดค่า
- ช่วงวันที่: เริ่มจากข้อมูลย้อนหลัง 3 ถึง 6 เดือน ใช้ timestamp เริ่มต้นแบบรวมวันเริ่มต้นและ timestamp สิ้นสุดแบบไม่รวมวันสิ้นสุด เพื่อป้องกันเหตุการณ์ซ้ำระหว่างการดึงข้อมูลแต่ละครั้ง.
- ตัวระบุเคส: ใช้ InvoiceNumber จากส่วนหัวเอกสารวางบิล เก็บเป็นข้อความเพราะหมายเลขเอกสาร SAP อาจมีเลขศูนย์นำหน้า.
- กิจกรรมที่ต้องมี: การดึงข้อมูลต้องส่งคืนแถวที่ระบุกิจกรรมเหล่านี้อย่างชัดเจน ได้แก่ Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created และ Billing Rework Identified.
- ตัวกรอง: ใช้ตัวกรอง Company Code, ประเภทเอกสารวางบิล, sales organization, ลูกค้า ภูมิภาค และวันที่ หลังจากยืนยันฟิลด์ที่เกี่ยวข้องและขอบเขตทางธุรกิจในระบบเป้าหมายแล้วเท่านั้น อย่าสันนิษฐานว่าเอกสารวางบิลทุกประเภทใช้กระบวนการบัญชีหรือการจัดการผลลัพธ์แบบเดียวกัน.
- การกำหนดค่าแหล่งข้อมูล: VBRK และ VBRP เป็นแหล่งข้อมูลหลักสำหรับการวางบิล ส่วนแหล่งข้อมูลด้านบัญชี ผลลัพธ์ ข้อพิพาท การติดตามหนี้ การชำระเงิน การตัดบัญชี และลำดับเอกสาร ต้องกำหนดตาม SAP S/4HANA รุ่นที่ติดตั้งและโมดูลที่เปิดใช้งาน แทนที่การอ้างอิงแหล่งข้อมูลในวงเล็บเหลี่ยมด้วย object และฟิลด์ที่ตรวจสอบแล้ว.
- เหตุการณ์ที่คำนวณขึ้น: Payment Due Date Reached คำนวณจากเงื่อนไขการชำระเงินและข้อมูลวันครบกำหนด ส่วน Billing Rework Identified คำนวณจากรูปแบบการยกเลิกและการสร้างใบแจ้งหนี้ใหม่ เหตุการณ์เหล่านี้เป็นแถวที่สร้างด้วย SQL ไม่ใช่ระเบียนธุรกรรมดั้งเดิม.
- ประสิทธิภาพ: ใส่ตัวกรองวันที่ Company Code ประเภทการวางบิล และหมายเลขเอกสารไว้ใน query ของแต่ละแหล่งข้อมูล เลือกเฉพาะคอลัมน์ที่จำเป็น หลีกเลี่ยงการ join ตารางบัญชีขนาดใหญ่โดยไม่มีตัวกรอง แบ่งประมวลผลเป็นรายเดือนหรือรายสัปดาห์ และใช้แผนการประมวลผลของฐานข้อมูลเพื่อค้นหา join ที่ใช้ทรัพยากรมาก.
- การดึงข้อมูลแบบเพิ่มเฉพาะส่วน: ใช้ watermark ที่คงที่โดยอิง timestamp การสร้างหรือการบันทึกจากแหล่งข้อมูล ดึงข้อมูลซ้ำในช่วงเวลาสั้นๆ ที่ทับซ้อนกันเพื่อให้ได้ระเบียนผลลัพธ์ การชำระเงิน ข้อพิพาท และการตัดบัญชีที่มาถึงล่าช้า จากนั้นลบรายการซ้ำโดยใช้ InvoiceNumber, ActivityName และ EventTime ร่วมกับคีย์เอกสารต้นทางที่เกี่ยวข้อง.
- สิทธิ์การเข้าถึง: ผู้ใช้ที่ใช้ดึงข้อมูลต้องมีสิทธิ์อ่าน object และฟิลด์ใน HANA schema ที่เลือก ตรวจสอบว่านโยบายความปลอดภัยขององค์กรอนุญาตให้เข้าถึงฐานข้อมูลโดยตรง และการจัดการข้อมูลส่วนบุคคลหรือข้อมูลลูกค้าเป็นไปตามข้อกำหนด.
- ข้อกำหนดด้านการทำงาน: ข้อมูลการจัดการผลลัพธ์ การเชื่อมต่อบัญชี การจัดการข้อพิพาท การติดตามหนี้ การรับชำระเงิน และการตัดบัญชี จะมีให้ใช้ต่อเมื่อกำหนดค่าและใช้งานในระบบ หากไม่มีโมดูลหรือระเบียนต้นทาง กิจกรรมจะไม่ปรากฏ และระบบจะไม่อนุมานเหตุการณ์ขึ้นเอง.
- เขตเวลา: ปรับ timestamp ให้เป็นเขตเวลาที่ ProcessMind ต้องการ พร้อมบันทึกว่า timestamp ต้นทางจัดเก็บเป็น UTC เวลาท้องถิ่นของระบบ หรือเขตเวลาอื่นที่กำหนดไว้.
ตัวอย่างคำค้น sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เพื่อเตรียมข้อมูลได้รวดเร็วขึ้น แล้วเริ่มปรับปรุงกระบวนการ Order to Cash - Billing & Invoicing ของคุณ เปลี่ยนข้อมูลจาก SAP S/4H4ANA ให้เป็นข้อมูลเชิงลึกที่นำไปใช้ได้จริงตั้งแต่วันนี้.
ปรับปรุงการวางบิลในกระบวนการ Order to Cash เพื่อให้กระแสเงินสดเร็วขึ้น 30%
ลดขั้นตอนที่ไม่มีประสิทธิภาพและลดระยะเวลาการวางบิลลง 30% ได้ตั้งแต่วันนี้.
ไม่ต้องใช้บัตรเครดิต เริ่มต้นได้ภายในไม่กี่นาที.