เทมเพลตข้อมูลการประมวลผลการชำระเงินของคุณ
เทมเพลตข้อมูลการประมวลผลการชำระเงินของคุณ
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ การประมวลผลการชำระเงิน หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- คำอธิบายฟิลด์โดยละเอียดสำหรับติดตามธุรกรรม
- การจับคู่กิจกรรมมาตรฐานตลอดวงจรการชำระเงิน
- โครงสร้างข้อมูลที่ขยายได้และใช้ได้กับระบบการเงินทุกประเภท
ข้อมูลประกอบการประมวลผลการชำระเงิน
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| การอัปเดตข้อมูลครั้งล่าสุด LastDataUpdate | เวลาประทับที่ระบุว่าดึงหรือรีเฟรชระเบียนครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย แอตทริบิวต์นี้ใช้ติดตามความใหม่ของข้อมูลที่นำมาวิเคราะห์ โดยระบุเวลาที่โหลดข้อมูลเข้าสู่เครื่องมือ process mining หรือเวลาที่แก้ไขระเบียนในฐานข้อมูลต้นทางครั้งล่าสุด ข้อมูลนี้สำคัญต่อการกำกับดูแลข้อมูลและสร้างความเชื่อมั่น นักวิเคราะห์จะทราบได้ว่ากำลังดูข้อมูลแบบเรียลไทม์หรือข้อมูล ณ วันก่อนหน้า ซึ่งสำคัญเป็นพิเศษเมื่อติดตามรายการชำระเงินที่ยังดำเนินการอยู่และอาจค้างในสถานะรอดำเนินการ แม้จะไม่ได้นำไปคำนวณการไหลของกระบวนการโดยตรง แต่ฟิลด์ข้อมูลเมตานี้ช่วยให้แน่ใจว่าแดชบอร์ดแสดงสถานะการปฏิบัติการด้านการชำระเงินล่าสุด. เหตุผลที่สำคัญ ช่วยยืนยันว่าข้อมูลเป็นปัจจุบัน และช่วยแก้ไขปัญหาความล่าช้าในไปป์ไลน์ข้อมูล. แหล่งข้อมูล สร้างขึ้นระหว่างการดึงข้อมูลหรือกระบวนการ ETL. ตัวอย่าง 2023-10-27T12:00:00Z2023-10-27 23:59:592023-10-28 06:00:0010/27/20232023-11-01 01:00:00.000 | |||
| ชื่อกิจกรรม ActivityName | ขั้นตอน การเปลี่ยนสถานะ หรือเหตุการณ์ที่เกิดขึ้นในวงจรการชำระเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุการดำเนินการหรือการเปลี่ยนสถานะของรายการชำระเงิน ณ ช่วงเวลาหนึ่ง เช่น การสร้างคำขอ การตรวจสอบความถูกต้อง การอนุมัติ หรือการชำระเงินขั้นสุดท้าย process mining ใช้แอตทริบิวต์นี้กำหนดโหนดในแผนผังกระบวนการ เมื่อนักวิเคราะห์ตรวจสอบลำดับกิจกรรม จะเห็นรูปแบบกระบวนการที่พบบ่อย การวนกลับไปทำรายการซ้ำ และคอขวดที่ทำให้รายการชำระเงินค้างเป็นเวลานาน การปรับชื่อกิจกรรมจากระบบต้นทางต่างๆ ให้เป็นมาตรฐานเดียวกันมักจำเป็นต่อการสร้างภาพกระบวนการที่สอดคล้องกัน เช่น ระบบหนึ่งอาจเรียกขั้นตอนว่า 'Auth' แต่อีกระบบใช้คำว่า 'Authorization' จึงควรปรับชื่อให้ตรงกันระหว่างการแปลงข้อมูล. เหตุผลที่สำคัญ ใช้กำหนดโหนดในแผนผังกระบวนการ และช่วยวิเคราะห์ลำดับการทำงานกับรูปแบบต่างๆ ของกระบวนการ. แหล่งข้อมูล พบในบันทึกการตรวจสอบ ตารางประวัติสถานะ หรือตารางติดตามเหตุการณ์. ตัวอย่าง สร้างรายการชำระเงินอนุมัติธุรกรรมการชำระเงินแล้วการชำระเงินล้มเหลวยืนยันการชำระเงินแล้วข้อผิดพลาดในการตรวจสอบความถูกต้อง | |||
| รหัสธุรกรรมการชำระเงิน PaymentTransactionId | รหัสเฉพาะที่ใช้ระบุคำสั่งชำระเงินหรือรายการธุรกรรมแต่ละรายการ. | ||
| คำอธิบาย แอตทริบิวต์นี้เป็นรหัสหลักที่ใช้เชื่อมโยงกิจกรรมทั้งหมดตลอดวงจรการชำระเงินหนึ่งรายการ เครื่องมือ process mining ใช้รหัสนี้สร้างเส้นทางการชำระเงินตั้งแต่เริ่มต้นจนถึงการชำระเงินเสร็จสมบูรณ์หรือไม่สำเร็จ ในการวิเคราะห์ ระบบใช้รหัสนี้จัดกลุ่มเหตุการณ์ต่างๆ ให้อยู่ในเคสเดียวกัน และแสดงภาพการไหลของกระบวนการ ทั้งยังจำเป็นต่อการคำนวณ Cycle Time ของแต่ละธุรกรรม หากไม่มีรหัสเฉพาะ ก็จะแยกธุรกรรมหลายพันรายการที่ดำเนินอยู่พร้อมกันในระบบออกจากกันไม่ได้ โดยทั่วไปรหัสนี้จะคงเดิมตลอดวงจรการชำระเงิน แต่ในกรณีที่ซับซ้อนและมีหลายระบบ อาจต้องใช้คีย์ผสมหรือจับคู่กับหมายเลขอ้างอิงเฉพาะที่ใช้ติดตามรายการตั้งแต่ต้นจนจบ. เหตุผลที่สำคัญ นี่คือ Case ID หลักที่จำเป็นสำหรับสร้างโมเดลกระบวนการและติดตามรายการชำระเงินแต่ละรายการ. แหล่งข้อมูล โดยทั่วไปพบในส่วนหัวของธุรกรรม ตารางคำสั่งชำระเงิน หรือบันทึกบัญชีแยกประเภทหลัก. ตัวอย่าง TRX-8859201PAY-2023-X9910029384f47ac10b-58cc-4372-a567-0e02b2c3d479INSTR-5542 | |||
| ระบบต้นทาง SourceSystem | ชื่อแอปพลิเคชันหรือระบบที่เป็นแหล่งที่มาของข้อมูลเหตุการณ์. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุแหล่งที่มาทางเทคนิคของระเบียน ในกระบวนการชำระเงินตั้งแต่ต้นจนจบ ข้อมูลมักผ่านหลายระบบ เช่น เกตเวย์ส่วนหน้า ระบบตรวจจับการฉ้อโกง และบัญชีแยกประเภทส่วนหลัง การวิเคราะห์ข้อมูลแยกตามระบบช่วยให้ผู้ใช้แยกปัญหาทางเทคนิคได้ เช่น หากพบความล่าช้าในระบบตรวจจับการฉ้อโกงเป็นประจำ แต่ไม่พบในบัญชีแยกประเภท ก็จะระบุสาเหตุที่แท้จริงได้ตรงจุด นอกจากนี้ยังช่วยตรวจสอบความถูกต้องของข้อมูลเมื่อนำข้อมูลจากหลายแหล่งมารวมกัน หากข้อมูลต้นทางไม่มีฟิลด์นี้ โดยทั่วไปจะเพิ่มระหว่างการดึงและแปลงข้อมูล เพื่อใช้ระบุที่มาของข้อมูลสำหรับการตรวจสอบและแก้ไขปัญหา. เหตุผลที่สำคัญ สำคัญต่อการวิเคราะห์ข้อมูลจากหลายระบบ และช่วยระบุได้ว่าส่วนใดเป็นสาเหตุของความล่าช้าหรือข้อผิดพลาด. แหล่งข้อมูล มักกำหนดค่าไว้ระหว่างกระบวนการ ETL หรือพบในข้อมูลเมตาของระบบ. ตัวอย่าง PaymentGateway_01CoreBankingSystemFraudEngineSwiftInterfaceERP_SAP | |||
| เวลาประทับของเหตุการณ์ EventTimestamp | วันที่และเวลาที่กิจกรรมหรือการเปลี่ยนสถานะเกิดขึ้น. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกเวลาที่เกิดเหตุการณ์ในระบบการชำระเงินอย่างแม่นยำ และใช้เป็นจุดอ้างอิงตามลำดับเวลาของกระบวนการ เพื่อให้จัดเรียงเหตุการณ์ภายในเคสได้ถูกต้อง ในการวิเคราะห์ เวลาประทับนี้เป็นพื้นฐานของการคำนวณที่เกี่ยวกับเวลา ใช้คำนวณระยะเวลาระหว่างกิจกรรม Cycle Time ตั้งแต่ต้นจนจบ และการปฏิบัติตามข้อตกลงระดับการให้บริการ เวลาประทับที่แม่นยำช่วยระบุได้ว่าคอขวดเกิดขึ้นเมื่อใด ควรใช้เวลาที่มีความละเอียดสูง โดยเฉพาะกับระบบซื้อขายความถี่สูงหรือระบบชำระเงินอัตโนมัติที่มีความแตกต่างระดับมิลลิวินาที หากมีเพียงวันที่โดยไม่มีเวลา อาจต้องใช้หลักเกณฑ์การจัดเรียงเพิ่มเติมเพื่อแยกลำดับกิจกรรมที่เกิดขึ้นในวันเดียวกัน. เหตุผลที่สำคัญ จำเป็นต่อการจัดเรียงเหตุการณ์และคำนวณ KPI ที่อิงระยะเวลา เช่น Cycle Time. แหล่งข้อมูล พบในบันทึกธุรกรรม ตารางประวัติ หรือบันทึกการตรวจสอบของระบบ. ตัวอย่าง 2023-10-15T08:30:00Z2023-10-15 14:45:12.5502023-11-01T09:00:00+00:0010/15/2023 08:30:00 PM2023-10-16 10:15:00 | |||
| ผู้ดำเนินการ ProcessingUser | รหัสผู้ใช้หรือบัญชีระบบที่รับผิดชอบดำเนินกิจกรรม. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุว่าใครหรือระบบใดดำเนินขั้นตอนหนึ่งในกระบวนการชำระเงิน อาจเป็นผู้ใช้ที่ตรวจสอบรายการด้วยตนเอง หรือบัญชีระบบที่ทำงานอัตโนมัติ ข้อมูลนี้จำเป็นต่อการวิเคราะห์การใช้ทรัพยากรและคอขวด อีกทั้งช่วยแยกการประมวลผลอัตโนมัติ (Straight-Through Processing) ออกจากการดำเนินการด้วยตนเอง หากผู้ใช้ต้องเข้ามาดำเนินการด้วยตนเองบ่อยครั้ง ก็มักสัมพันธ์กับต้นทุนที่สูงขึ้นและ Cycle Time ที่นานขึ้น ในด้านการปฏิบัติตามข้อกำหนด ฟิลด์นี้ช่วยวิเคราะห์การแบ่งแยกหน้าที่ เพื่อให้แน่ใจว่าผู้สร้างรายการชำระเงินไม่ใช่คนเดียวกับผู้อนุมัติ. เหตุผลที่สำคัญ ช่วยวิเคราะห์อัตราการทำงานอัตโนมัติ (STP) และผลิตภาพของทรัพยากร. แหล่งข้อมูล พบในบันทึกการตรวจสอบหรือคอลัมน์ข้อมูลเมตาของตารางธุรกรรม. ตัวอย่าง SystemAgent_01jdoeAPPROVER_GROUP_AAutoReconcilerAPI_User | |||
| ยอดชำระเงิน PaymentAmount | มูลค่าเงินของธุรกรรมการชำระเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้แสดงมูลค่าเงินที่โอน และเป็นตัวชี้วัดเชิงตัวเลขหลักสำหรับประเมินผลกระทบจากความไม่มีประสิทธิภาพของกระบวนการ ตัวอย่างเช่น ความล่าช้าของการชำระเงินมูลค่าหนึ่งล้านดอลลาร์มักส่งผลกระทบมากกว่าความล่าช้าของการชำระเงินสิบดอลลาร์ ในการวิเคราะห์ ใช้ฟิลด์นี้รวมปริมาณธุรกรรม คำนวณความต้องการสภาพคล่องทั้งหมด และแบ่งกลุ่มรายการชำระเงินตามมูลค่า รายการมูลค่าสูงมักมีเวิร์กโฟลว์การอนุมัติต่างจากรายการมูลค่าต่ำ แอตทริบิวต์นี้จึงช่วยแยกเส้นทางของแต่ละกลุ่มได้ ควรใช้แอตทริบิวต์นี้คู่กับรหัสสกุลเงิน เพื่อให้เปรียบเทียบมูลค่าในหน่วยเดียวกันได้ การรวมยอดโดยไม่แปลงหรือแยกสกุลเงินอาจทำให้รายงานทางการเงินคลาดเคลื่อน. เหตุผลที่สำคัญ ช่วยวิเคราะห์ผลกระทบทางการเงินและแบ่งกลุ่มธุรกรรมมูลค่าสูงกับมูลค่าต่ำ. แหล่งข้อมูล พบในรายละเอียดธุรกรรมหรือตารางบันทึกรายการทางการเงิน. ตัวอย่าง 150.0010000.5025.995000000.01 | |||
| รหัสข้อผิดพลาด ErrorCode | รหัสหรือสาเหตุเฉพาะที่ระบบระบุเมื่อการชำระเงินไม่สำเร็จหรือถูกปฏิเสธ. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกสาเหตุทางเทคนิคหรือทางธุรกิจที่ทำให้กระบวนการไม่สำเร็จ โดยจะมีข้อมูลเมื่อรายการชำระเงินถูกปฏิเสธ ตรวจสอบความถูกต้องไม่ผ่าน หรือเกิดข้อผิดพลาดในการส่งข้อมูล การวิเคราะห์รหัสข้อผิดพลาดเป็นวิธีหลักในการลด 'อัตราการชำระเงินไม่สำเร็จ' และ 'อัตราการทำงานซ้ำ' การจัดกลุ่มรหัสข้อผิดพลาดที่พบบ่อยช่วยระบุปัญหาเชิงระบบ เช่น ข้อมูลหลักไม่ถูกต้อง หรือการเชื่อมต่อกับหน่วยงานหักบัญชีภายนอกมีปัญหา ในกรณีที่กระบวนการเป็นไปตามปกติ ฟิลด์นี้มักไม่มีค่า หากมีข้อมูล มักหมายถึงกระบวนการเบี่ยงเบนจากเส้นทางที่ควรเป็น และมีการเรียกใช้กระบวนการย่อยเพื่อจัดการข้อยกเว้น. เหตุผลที่สำคัญ แอตทริบิวต์หลักสำหรับวิเคราะห์หาสาเหตุที่แท้จริงของความล้มเหลวและการทำงานซ้ำ. แหล่งข้อมูล พบในบันทึกข้อผิดพลาด ข้อความแจ้งปฏิเสธ หรือข้อมูลตอบกลับ. ตัวอย่าง INSUFFICIENT_FUNDSINVALID_ACCOUNTFRAUD_SUSPICIONTIMEOUTDUPLICATE_REF | |||
| รหัสสกุลเงิน CurrencyCode | รหัส ISO 3 ตัวอักษรที่ระบุสกุลเงินของรายการชำระเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุหน่วยสกุลเงินของยอดชำระเงิน เช่น USD, EUR หรือ GBP ซึ่งจำเป็นต่อการจัดทำรายงานทางการเงินให้ถูกต้อง และการเรียกใช้เวิร์กโฟลว์เฉพาะสำหรับธุรกรรมข้ามพรมแดน การวิเคราะห์มักต้องกรองตามสกุลเงินเพื่อดูผลการดำเนินงานในแต่ละภูมิภาคหรือระยะเวลาประมวลผลอัตราแลกเปลี่ยน สกุลเงินแต่ละชนิดอาจมีเวลาปิดรับรายการ รอบการชำระเงิน และข้อกำหนดด้านกฎระเบียบต่างกัน ซึ่งส่งผลโดยตรงต่อการไหลของกระบวนการ หากไม่มีแอตทริบิวต์นี้ ฟิลด์ 'ยอดชำระเงิน' จะไม่ระบุชัดเจนว่าเป็นสกุลเงินใด แอตทริบิวต์นี้ช่วยแปลงยอดเงินต่างสกุลให้เป็นสกุลเงินเดียวสำหรับจัดทำแดชบอร์ดระดับโลก. เหตุผลที่สำคัญ จำเป็นต่อการปรับมูลค่าทางการเงินให้อยู่ในมาตรฐานเดียวกัน และระบุความแตกต่างของกระบวนการข้ามพรมแดน. แหล่งข้อมูล พบในตารางธุรกรรมร่วมกับยอดชำระเงิน. ตัวอย่าง USDEURGBPJPYCAD | |||
| วันครบกำหนดชำระเงิน PaymentDueDate | วันที่คาดว่าจะต้องชำระเงินให้เสร็จสิ้น หรือวันที่กำหนดให้ชำระเงินเสร็จสิ้น. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุวันครบกำหนดชำระเงิน และช่วยให้ระบบวัด 'อัตราการชำระเงินตรงเวลา' รวมถึงตรวจสอบว่าเป็นไปตามข้อตกลงระดับการให้บริการ (SLA) หรือไม่ เมื่อนำเวลาที่ชำระเงินเสร็จจริงมาเทียบกับวันครบกำหนด ก็จะได้ตัวชี้วัดประสิทธิภาพของกระบวนการที่ชัดเจน หากชำระเงินหลังวันดังกล่าว จะถือว่าล่าช้า ซึ่งอาจมีค่าปรับหรือกระทบต่อความสัมพันธ์ทางธุรกิจ ฟิลด์นี้สำคัญเป็นพิเศษสำหรับกระบวนการเจ้าหนี้การค้าหรือสัญญารับประกันการให้บริการที่กำหนดเวลาไว้เป็นข้อผูกพันตามสัญญา. เหตุผลที่สำคัญ จำเป็นต่อการคำนวณการปฏิบัติตาม SLA และอัตราการชำระเงินตรงเวลา. แหล่งข้อมูล พบในส่วนหัวของใบแจ้งหนี้หรือคำสั่งขอชำระเงิน. ตัวอย่าง 2023-10-302023-11-012023-10-152023-12-312024-01-01 | |||
| วิธีการชำระเงิน PaymentMethod | เครื่องมือหรือช่องทางเฉพาะที่ใช้ดำเนินการชำระเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้จัดประเภทการชำระเงินตามวิธีดำเนินการ เช่น การโอนเงินผ่านธนาคาร ACH บัตรเครดิต หรือการชำระเงินทันที โดยแต่ละวิธีมักมีเส้นทางกระบวนการ ระยะเวลาดำเนินการ และต้นทุนที่ต่างกัน นักวิเคราะห์สามารถใช้แอตทริบิวต์นี้แบ่งกลุ่มข้อมูลเพื่อเปรียบเทียบประสิทธิภาพของช่องทางการชำระเงินแต่ละแบบ เช่น การโอนเงินผ่านธนาคารอาจต้องผ่านขั้นตอนอนุมัติด้วยตนเองมากกว่าการประมวลผล ACH แบบกลุ่มที่ทำงานอัตโนมัติ การทำความเข้าใจสัดส่วนของวิธีชำระเงินช่วยวางแผนทรัพยากร และระบุการเปลี่ยนแปลงพฤติกรรมของลูกค้า เช่น การเปลี่ยนจากเช็คแบบเดิมมาใช้การชำระเงินดิจิทัลแบบทันที. เหตุผลที่สำคัญ จำเป็นต่อการแยกรูปแบบกระบวนการ เช่น การชำระเงินทันทีและการโอนเงินผ่านธนาคาร ซึ่งมี SLA ต่างกัน. แหล่งข้อมูล พบในรายละเอียดคำสั่งชำระเงิน. ตัวอย่าง โอนเงินผ่านธนาคารACHบัตรเครดิตโอนเงินผ่าน SEPAชำระเงินแบบเรียลไทม์ | |||
| คะแนนความเสี่ยง RiskScore | คะแนนตัวเลขที่บ่งชี้โอกาสเกิดการฉ้อโกงหรือความเสี่ยงด้านการปฏิบัติตามข้อกำหนด. | ||
| คำอธิบาย แอตทริบิวต์นี้เป็นค่าที่ระบบตรวจจับการฉ้อโกงหรือโมเดลความเสี่ยงสร้างขึ้น โดยทั่วไปคะแนนที่สูงขึ้นหมายถึงมีโอกาสมากขึ้นที่ธุรกรรมจะเป็นการฉ้อโกงหรือมีความเสี่ยงสูง ในการวิเคราะห์กระบวนการ คะแนนนี้ช่วยอธิบายได้ว่าทำไมรายการชำระเงินบางรายการจึงต้องผ่านการตรวจสอบหลายรอบ รายการที่มีคะแนนความเสี่ยงสูงมักต้องให้ผู้ใช้ดำเนินการด้วยตนเอง ทำให้ Cycle Time นานขึ้น เมื่อนำคะแนนความเสี่ยงมาเทียบกับผลลัพธ์สุดท้าย เช่น อนุมัติหรือปฏิเสธ ก็จะช่วยปรับประสิทธิภาพของกฎการประเมินความเสี่ยงได้ ระบบบางระบบไม่ได้สร้างคะแนนเป็นตัวเลข แต่อาจแสดงเพียงสถานะ อย่างไรก็ตาม เกตเวย์การชำระเงินสมัยใหม่มักใช้คะแนนนี้เป็นตัวชี้วัดมาตรฐานในการตัดสินใจ. เหตุผลที่สำคัญ ช่วยอธิบายความเบี่ยงเบนของกระบวนการ เช่น การตรวจสอบด้วยตนเองและการระงับรายการเพื่อตรวจสอบการฉ้อโกง. แหล่งข้อมูล ข้อมูลที่ได้จากระบบตรวจจับการฉ้อโกงหรือระบบประเมินความเสี่ยง. ตัวอย่าง 08512.5994 | |||
| ช่องทางการประมวลผล ProcessingChannel | ช่องทางหรือส่วนติดต่อที่ใช้เริ่มต้นการชำระเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุช่องทางที่ใช้ส่งคำสั่งชำระเงิน เช่น แอปมือถือ เว็บพอร์ทัล API หรือการอัปโหลดไฟล์ ช่วยให้เข้าใจพฤติกรรมของลูกค้าและการใช้ช่องทางต่างๆ การวิเคราะห์ประสิทธิภาพของกระบวนการแยกตามช่องทางช่วยให้เห็นความแตกต่างด้านเทคนิค เช่น รายการที่เริ่มผ่าน API อาจดำเนินการได้ทันที ส่วนรายการที่ส่งผ่านไฟล์อาจต้องรอรอบประมวลผลแบบกลุ่ม ข้อมูลนี้ช่วยให้เข้าใจประสบการณ์ของผู้ใช้ในแต่ละแพลตฟอร์ม นอกจากนี้ยังช่วยวิเคราะห์การเปลี่ยนจากช่องทางเดิม เช่น การกรอกข้อมูลด้วยตนเองหรือแฟกซ์ ไปสู่ช่องทางดิจิทัล เพื่อสนับสนุนการเปลี่ยนผ่านสู่ดิจิทัล. เหตุผลที่สำคัญ ช่วยวิเคราะห์แนวโน้มปริมาณธุรกรรมและความแตกต่างด้านประสิทธิภาพของแต่ละช่องทาง เช่น มือถือกับเว็บ. แหล่งข้อมูล พบในส่วนหัวของธุรกรรมหรือข้อมูลเมตาของเซสชัน. ตัวอย่าง แอปมือถือเว็บพอร์ทัลไฟล์ H2HAPIเครื่อง POS | |||
| ชื่อผู้รับเงิน BeneficiaryName | ชื่อองค์กรหรือบุคคลที่ได้รับเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้ระบุผู้รับเงิน ในบริบท B2B คือผู้ขาย ส่วนบริบท P2P คือบุคคลที่ได้รับเงิน จึงช่วยให้ทราบว่าใครเป็นผู้รับชำระเงิน การวิเคราะห์รายการชำระเงินตามผู้รับเงินอาจเผยให้เห็นรูปแบบต่างๆ เช่น การจ่ายเงินให้หน่วยงานความเสี่ยงสูงบ่อยครั้ง หรือการพึ่งพาผู้ขายบางรายมากเกินไป นอกจากนี้ยังช่วยวิเคราะห์การฉ้อโกง เช่น ตรวจสอบว่ามีการแบ่งยอดเงินเล็กๆ หลายรายการไปยังผู้รับเงินรายเดียวที่ไม่คาดคิดหรือไม่ ข้อมูลส่วนนี้มักมีปัญหาด้านคุณภาพ เช่น ชื่อสะกดต่างกัน ('Inc.' กับ 'Incorporated') จึงมักต้องทำความสะอาดข้อมูลก่อนนำมารวมยอดอย่างถูกต้อง. เหตุผลที่สำคัญ มีประโยชน์ต่อการวิเคราะห์ผู้ขาย การตรวจจับการฉ้อโกง และการประเมินความเสี่ยง. แหล่งข้อมูล พบในส่วนรายละเอียดผู้รับเงินของคำสั่งชำระเงิน. ตัวอย่าง Acme CorpGlobal Services LtdJohn SmithAzure Cloud Servicesหน่วยงานจัดเก็บภาษี | |||
กิจกรรมในการประมวลผลการชำระเงิน
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| การชำระเงินล้มเหลว | สถานะสิ้นสุดที่ระบุว่าไม่สามารถดำเนินการชำระเงินให้เสร็จได้ เนื่องจากปัญหาทางเทคนิคหรือการเงินที่แก้ไขไม่ได้ ถือเป็นการสิ้นสุดของกระบวนการรายการนั้นอย่างชัดเจน. | ||
| เหตุผลที่สำคัญ เป็นตัวชี้วัดสำคัญด้านความน่าเชื่อถือ การวิเคราะห์รูปแบบในขั้นตอนนี้ช่วยลดธุรกรรมที่ไม่สำเร็จ. แหล่งข้อมูล บันทึกจากรหัสสถานะความล้มเหลวขั้นสุดท้ายหรือบันทึกข้อผิดพลาดร้ายแรง. บันทึก ระบุธุรกรรมที่เข้าสู่สถานะล้มเหลวขั้นสุดท้าย. ประเภทเหตุการณ์ explicit | |||
| ชำระเงินเสร็จสมบูรณ์ | การโอนเงินเสร็จสมบูรณ์ โดยเงินเข้าบัญชีผู้รับ นี่คือสถานะสิ้นสุดที่สำเร็จหลักของธุรกรรมการชำระเงิน. | ||
| เหตุผลที่สำคัญ ใช้คำนวณระยะเวลาทั้งวงจร และเป็นเกณฑ์หลักที่บ่งชี้ว่ากระบวนการสำเร็จ. แหล่งข้อมูล โดยทั่วไปแสดงด้วยสถานะการชำระเงินเฉพาะ รายงานยืนยัน หรือรายการบันทึกบัญชีแยกประเภททั่วไป. บันทึก ดึงวันที่และเวลาที่ระบบประมวลผลการยืนยันการชำระเงิน. ประเภทเหตุการณ์ explicit | |||
| ส่งคำสั่งชำระเงินแล้ว | การส่งไฟล์หรือข้อความการชำระเงินฉบับสมบูรณ์ไปยังเครือข่ายการชำระเงินหรือสำนักหักบัญชีภายนอก เป็นจุดส่งต่องานจากระบบภายในไปยังระบบภายนอก. | ||
| เหตุผลที่สำคัญ นี่คือจุดสำคัญที่แบ่งเวลาประมวลผลภายในออกจากเวลาชำระเงินภายนอก. แหล่งข้อมูล บันทึกเมื่อสร้างไฟล์ ส่งการเรียก API ไปยังเครือข่าย หรือเปลี่ยนสถานะเป็น Transmitted. บันทึก ระบุเวลาของการเรียก API ขาออกหรือเหตุการณ์โอนไฟล์. ประเภทเหตุการณ์ explicit | |||
| สร้างรายการชำระเงิน | การสร้างระเบียนธุรกรรมการชำระเงินในระบบครั้งแรก เหตุการณ์นี้บันทึกเวลาที่ระบบรับคำขอชำระเงินเป็นครั้งแรก ไม่ว่าจะเป็นการป้อนข้อมูลด้วยตนเองโดยผู้ใช้หรือสร้างผ่านการเรียก API. | ||
| เหตุผลที่สำคัญ ใช้กำหนดเวลาเริ่มต้นของวงจรการชำระเงินตั้งแต่ต้นจนจบ และเป็นข้อมูลตั้งต้นสำหรับวิเคราะห์ปริมาณธุรกรรม. แหล่งข้อมูล โดยทั่วไปพบได้ในฟิลด์เวลาที่สร้างระเบียนของตารางธุรกรรมหลัก หรือรายการในบันทึกการตรวจสอบสำหรับระเบียนใหม่. บันทึก ดึงเวลาที่เร็วที่สุดซึ่งเชื่อมโยงกับ Payment Transaction ID. ประเภทเหตุการณ์ explicit | |||
| อนุมัติการชำระเงินแล้ว | จุดสำคัญภายในองค์กรที่ผู้ใช้ซึ่งมีอำนาจหรือกฎของระบบอนุญาตให้ดำเนินการชำระเงินต่อ ขั้นตอนนี้ต่างจากการอนุมัติทางการเงินภายนอก และเป็นการลงนามอนุมัติภายในองค์กร. | ||
| เหตุผลที่สำคัญ มักเป็นคอขวดสำคัญ เนื่องจากต้องทำงานผ่านเวิร์กโฟลว์ด้วยตนเองและรอการดำเนินการจากบุคลากร. แหล่งข้อมูล บันทึกไว้ในบันทึกการอนุมัติของเวิร์กโฟลว์ หรือเมื่อกำหนดค่าแฟล็กการอนุมัติเป็น true. บันทึก บันทึกเวลาที่การอนุมัติขั้นสุดท้ายถูกบันทึกลงฐานข้อมูล. ประเภทเหตุการณ์ explicit | |||
| อนุมัติธุรกรรมการชำระเงินแล้ว | การยืนยันทางการเงินว่าได้กันวงเงินไว้หรือมีเงินพร้อมสำหรับธุรกรรมแล้ว โดยมักเกิดจากการเชื่อมต่อกับระบบธนาคารหลัก ผู้ออกบัตร หรือวงเงินสินเชื่อ. | ||
| เหตุผลที่สำคัญ การยืนยันการอนุมัติเป็นจุดควบคุมสำคัญก่อนที่จะเคลื่อนย้ายเงินจริง. แหล่งข้อมูล พบได้ในบันทึกการตอบกลับจากเกตเวย์หรือตารางการอนุมัติของระบบธนาคารหลัก. บันทึก ดึงเวลาของรหัสตอบกลับที่ยืนยันการอนุมัติ. ประเภทเหตุการณ์ explicit | |||
| กระทบยอดการชำระเงินแล้ว | ขั้นตอนทางบัญชีที่จับคู่ระเบียนจากระบบการชำระเงินกับรายการเดินบัญชีธนาคารหรือบัญชีแยกประเภทภายนอก เพื่อให้มั่นใจว่าข้อมูลในระบบตรงกับรายการจริง. | ||
| เหตุผลที่สำคัญ แสดงว่าปิดธุรกรรมในส่วนงานธุรการแล้วและข้อมูลทางการเงินถูกต้อง. แหล่งข้อมูล พบได้ในโมดูลกระทบยอด หรืออนุมานได้เมื่อกำหนดรหัสการจับคู่ให้กับธุรกรรม. บันทึก เชื่อมธุรกรรมกับเวลาที่บันทึกในตารางกระทบยอด. ประเภทเหตุการณ์ calculated | |||
| แก้ไขข้อผิดพลาดการชำระเงินแล้ว | ระบุว่าปัญหาที่พบก่อนหน้านี้ได้รับการแก้ไขแล้ว ทำให้การชำระเงินกลับเข้าสู่ขั้นตอนประมวลผลตามปกติ โดยทั่วไปต้องให้คนเข้ามาจัดการหรือใช้กลไกลองใหม่โดยอัตโนมัติ. | ||
| เหตุผลที่สำคัญ จำเป็นต่อการวัดเวลาและแรงงานที่ใช้แก้ไขข้อยกเว้นในการชำระเงิน. แหล่งข้อมูล อนุมานได้เมื่อธุรกรรมเปลี่ยนจากสถานะข้อผิดพลาดกลับไปเป็นสถานะกำลังประมวลผลหรือพร้อมดำเนินการ. บันทึก ตรวจจับการเปลี่ยนสถานะจากรหัสข้อผิดพลาดกลับไปเป็นสถานะประมวลผลที่ถูกต้อง. ประเภทเหตุการณ์ inferred | |||
| คืนเงินแล้ว | เกิดขึ้นเมื่อมีการกลับรายการชำระเงินที่เสร็จแล้วและคืนเงินให้ผู้จ่าย โดยทั่วไปกิจกรรมนี้เกิดขึ้นหลังจากกระบวนการหลักเสร็จสิ้นตามปกติแล้ว. | ||
| เหตุผลที่สำคัญ อัตราการคืนเงินเป็นตัวชี้วัดคุณภาพสำคัญของบริการหรือผลิตภัณฑ์ทางธุรกิจ. แหล่งข้อมูล บันทึกจากธุรกรรมคืนเงินที่เชื่อมโยงกัน หรือการเปลี่ยนสถานะที่ระบุว่ามีการกลับรายการ. บันทึก ระบุเหตุการณ์คืนเงินที่เชื่อมโยงกับรหัสการชำระเงินต้นฉบับ. ประเภทเหตุการณ์ explicit | |||
| ตรวจสอบการชำระเงินแล้ว | การตรวจสอบคำสั่งชำระเงินโดยอัตโนมัติเสร็จสิ้น เช่น ตรวจรูปแบบและไวยากรณ์ ความถูกต้องของเลขที่บัญชี และการคัดกรองตามข้อกำหนด ขั้นตอนนี้ช่วยให้ข้อมูลถูกต้องก่อนส่งต่อไปอนุมัติหรือดำเนินการ. | ||
| เหตุผลที่สำคัญ หากขั้นตอนนี้ใช้เวลานาน อาจเกิดจากบริการตรวจสอบภายนอกทำงานช้าหรือกฎการปฏิบัติตามข้อกำหนดมีความซับซ้อน. แหล่งข้อมูล โดยทั่วไปบันทึกเมื่อสถานะเปลี่ยนจาก Draft เป็น Validated หรืออนุมานจากบันทึกที่ระบุว่าการตรวจสอบสำเร็จ. บันทึก ระบุการเปลี่ยนสถานะที่แสดงว่าตรวจสอบสำเร็จ หรือรายการบันทึกเฉพาะจากระบบตรวจสอบการปฏิบัติตามข้อกำหนด. ประเภทเหตุการณ์ inferred | |||
| ปฏิเสธการชำระเงิน | เหตุการณ์ที่ผู้อนุมัติภายในหรือผู้ควบคุมภายนอกปฏิเสธคำขอชำระเงินอย่างชัดเจน ทำให้ขั้นตอนปัจจุบันหยุดลงและอาจมีการแจ้งผู้เริ่มรายการ. | ||
| เหตุผลที่สำคัญ สำคัญต่อการวิเคราะห์เหตุผลที่ถูกปฏิเสธและลดรายการรบกวนในขั้นตอนการชำระเงิน. แหล่งข้อมูล บันทึกไว้อย่างชัดเจนในประวัติเวิร์กโฟลว์ หรืออนุมานจากการอัปเดตสถานะสุดท้าย เช่น Rejected หรือ Declined. บันทึก บันทึกการดำเนินการเฉพาะที่ผู้ใช้หรือระบบสร้างเหตุการณ์ปฏิเสธ. ประเภทเหตุการณ์ explicit | |||
| พบข้อผิดพลาดในการชำระเงิน | ระบุว่าระบบหรือผู้ตรวจสอบภายนอกพบปัญหาเกี่ยวกับการชำระเงิน เช่น เงินไม่พอหรือข้อมูลไม่ถูกต้อง เหตุการณ์นี้เป็นจุดเริ่มต้นของการจัดการข้อยกเว้น. | ||
| เหตุผลที่สำคัญ จำเป็นต่อการคำนวณอัตราการแก้งานและระบุปัญหาคุณภาพในขั้นตอนป้อนข้อมูลก่อนหน้า. แหล่งข้อมูล บันทึกจากบันทึกข้อผิดพลาด ตารางข้อยกเว้น หรือรหัสสถานะที่ระบุว่าธุรกรรมล้มเหลวหรือถูกระงับ. บันทึก กรองหารหัสข้อผิดพลาดหรือการเปลี่ยนสถานะที่แจ้งว่าต้องแก้ไขธุรกรรม. ประเภทเหตุการณ์ explicit | |||
| ยกเลิกการชำระเงิน | การยุติการชำระเงินโดยผู้ใช้หรือผู้ดูแลระบบก่อนชำระเงินเสร็จ ซึ่งทำให้ธุรกรรมเป็นโมฆะ. | ||
| เหตุผลที่สำคัญ การแยกการยกเลิกออกจากความล้มเหลวสำคัญต่อการทำความเข้าใจพฤติกรรมผู้ใช้และข้อผิดพลาดของระบบ. แหล่งข้อมูล บันทึกไว้อย่างชัดเจนเมื่อมีการใช้คำสั่งยกเลิกหรือสถานะเปลี่ยนเป็น Void. บันทึก บันทึกเวลาที่ใช้คำสั่งยกเลิก. ประเภทเหตุการณ์ explicit | |||
| ยืนยันการชำระเงินแล้ว | ได้รับการตอบรับทางเทคนิคจากเครือข่ายภายนอก ซึ่งระบุว่าได้รับคำสั่งแล้วและรูปแบบถูกต้อง เป็นการยืนยันว่าการชำระเงินอยู่ในขั้นตอนดำเนินการของระบบภายนอก. | ||
| เหตุผลที่สำคัญ ยืนยันว่าการส่งต่องานไปยังเครือข่ายสำเร็จ และธุรกรรมกำลังรอการชำระเงิน. แหล่งข้อมูล บันทึกจากข้อความตอบรับขาเข้า (ACK) หรือ webhook จากผู้ให้บริการ. บันทึก บันทึกเวลาที่ได้รับข้อความตอบรับจากระบบภายนอก. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
เริ่มต้นด้วยการดาวน์โหลดเทมเพลตทั่วไปนี้ หรือเลือกคู่มือการดึงข้อมูลเฉพาะระบบเพื่อดูวิธีดึงข้อมูลจากสภาพแวดล้อมของคุณ.
หยุดรายได้รั่วไหลจากการชำระเงินตั้งแต่วันนี้
มองเห็นธุรกรรมทุกรายการและลดข้อผิดพลาด
ไม่ต้องใช้บัตรเครดิต • ตั้งค่าเสร็จใน 5 นาที