เทมเพลตข้อมูลการประมวลผลการชำระเงินของคุณ
เทมเพลตข้อมูลการประมวลผลการชำระเงินของคุณ
- แอตทริบิวต์ที่แนะนำให้เก็บ
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางดึงข้อมูลจาก ACI Worldwide
แอตทริบิวต์การประมวลผลการชำระเงิน
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| Payment Transaction ID PaymentTransactionId | รหัสเฉพาะของคำสั่งชำระเงินแต่ละรายการในระบบ ACI. | ||
| คำอธิบาย แอตทริบิวต์นี้เป็นคีย์หลักสำหรับการวิเคราะห์ process mining โดยเชื่อมโยงเหตุการณ์ทั้งหมดที่เกี่ยวข้องกับคำขอชำระเงินรายการเดียว ในระบบ ACI Worldwide เช่น MTS หรือ UPP ค่านี้ตรงกับหมายเลขอ้างอิงเฉพาะที่กำหนดให้ธุรกรรมเมื่อบันทึกรายการ ช่วยสร้างลำดับการชำระเงินตั้งแต่ต้นจนจบ ตั้งแต่คำขอแรก การตรวจสอบ การอนุมัติ ไปจนถึงการชำระบัญชีขั้นสุดท้าย. เหตุผลที่สำคัญ นี่คือ Case ID หลักที่ใช้จัดกลุ่มเหตุการณ์แต่ละรายการให้เป็นอินสแตนซ์ของกระบวนการ. แหล่งข้อมูล ตรวจสอบตารางส่วนหัวของธุรกรรม ซึ่งมักใช้ชื่อ TRN_REF, REFERENCE_NUM หรือ UUID ในบันทึกธุรกรรมหลัก. ตัวอย่าง TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| ชื่อกิจกรรม ActivityName | ขั้นตอนหรือการเปลี่ยนสถานะที่เกิดขึ้นในวงจรการชำระเงิน. | ||
| คำอธิบาย แอตทริบิวต์นี้กำหนดโหนดเหตุการณ์ในแผนผังกระบวนการ เช่น 'สร้างคำขอชำระเงิน' หรือ 'โอนเงินแล้ว' ในระบบ ACI ค่านี้มักได้มาจากรหัสสถานะ ประเภทการดำเนินการในบันทึกการตรวจสอบ หรือการเปลี่ยนสถานะในเวิร์กโฟลว์ การจับคู่สถานะทางเทคนิคเหล่านี้กับกิจกรรมทางธุรกิจที่อ่านเข้าใจง่ายอย่างถูกต้อง เป็นสิ่งสำคัญต่อการแสดงผลที่มีความหมาย. เหตุผลที่สำคัญ ใช้กำหนดลำดับขั้นตอนของกระบวนการ และจำเป็นต่อการแสดงลำดับการปฏิบัติงาน. แหล่งข้อมูล ได้มาจากรหัสสถานะ เช่น 100=สร้างแล้ว, 200=ตรวจสอบแล้ว หรือคอลัมน์การดำเนินการในบันทึกการตรวจสอบ. ตัวอย่าง สร้างคำขอชำระเงินแล้วอนุมัติการชำระเงินในระบบแล้วชำระเงินเสร็จสิ้นแล้วการชำระเงินล้มเหลว | |||
| เวลาประทับของเหตุการณ์ EventTimestamp | วันที่และเวลาที่กิจกรรมเกิดขึ้น. | ||
| คำอธิบาย แอตทริบิวต์นี้บันทึกเวลาที่เหตุการณ์เกิดขึ้นในระบบ ACI อย่างแม่นยำ ใช้คำนวณตัวชี้วัดตามเวลา เช่น ระยะเวลาของวงจร ระยะเวลาการอนุมัติ และอัตราปริมาณงาน ควรใช้ความละเอียดสูงระดับมิลลิวินาที เพื่อจัดลำดับขั้นตอนอัตโนมัติที่เกิดขึ้นอย่างรวดเร็วได้อย่างถูกต้อง. เหตุผลที่สำคัญ จำเป็นต่อการจัดลำดับเหตุการณ์และคำนวณระยะเวลาการทำงาน. แหล่งข้อมูล ตรวจสอบคอลัมน์ 'วันที่สร้าง' หรือ 'วันที่อัปเดต' ในประวัติธุรกรรมหรือตารางบันทึกการตรวจสอบ. ตัวอย่าง 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| ช่องทางประมวลผล ProcessingChannel | ช่องทางที่ใช้เริ่มต้นการชำระเงิน. | ||
| คำอธิบาย ระบุช่องทางที่รับรายการชำระเงิน เช่น แอปมือถือ พอร์ทัลเว็บ API หรือการอัปโหลดไฟล์ ช่วยวิเคราะห์ 'รูปแบบกระบวนการชำระเงิน' เพื่อดูว่าช่องทางใดมีแนวโน้มเกิดข้อผิดพลาดหรือล่าช้ามากกว่าช่องทางอื่น. เหตุผลที่สำคัญ ช่วยเปรียบเทียบประสิทธิภาพตามวิธีรับข้อมูล. แหล่งข้อมูล ส่วนหัวของธุรกรรม ซึ่งมักมีคอลัมน์ชื่อ CHANNEL, SOURCE_TYPE หรือ INPUT_METHOD. ตัวอย่าง SWIFTธนาคารทางอินเทอร์เน็ตแอปมือถืออัปโหลดไฟล์ | |||
| ประเภทการชำระเงิน PaymentType | ประเภทของเครื่องมือที่ใช้ชำระเงิน. | ||
| คำอธิบาย จัดประเภทการชำระเงิน เช่น Wire, ACH, SEPA หรือ RTGS การชำระเงินแต่ละประเภทมักมี SLA และขั้นตอนการทำงานที่แตกต่างกันมาก แอตทริบิวต์นี้เป็นมิติหลักสำหรับกรองข้อมูลในแดชบอร์ด 'ระยะเวลาการชำระเงินตั้งแต่ต้นจนจบ'. เหตุผลที่สำคัญ สำคัญต่อการแยกกระบวนการชำระเงินความเร็วสูงออกจากกระบวนการแบบชุด. แหล่งข้อมูล ส่วนหัวของธุรกรรม โดยใช้ฟิลด์ เช่น PMT_TYPE, INSTRUMENT_TYPE หรือ SERVICE_ID. ตัวอย่าง โอนเงินภายในประเทศโอนเงินระหว่างประเทศACH Creditชำระเงินทันที | |||
| ผู้ดำเนินกิจกรรม EventUser | รหัสผู้ใช้หรือบัญชีระบบที่รับผิดชอบกิจกรรม. | ||
| คำอธิบาย บันทึกว่าใครเป็นผู้ดำเนินการ ไม่ว่าจะเป็นผู้ใช้ที่เป็นบุคคล เช่น ผู้อนุมัติ หรือบัญชีระบบ เช่น ระบบชำระบัญชีอัตโนมัติ แอตทริบิวต์นี้สำคัญต่อ 'การวิเคราะห์คอขวด' เพื่อดูว่าผู้ใช้หรือคิวใดมีงานค้างมากเกินไป. เหตุผลที่สำคัญ ช่วยวิเคราะห์ทรัพยากรและตรวจสอบการแบ่งแยกหน้าที่. แหล่งข้อมูล บันทึกการตรวจสอบหรือคอลัมน์ 'UpdatedBy' ในตารางธุรกรรม. ตัวอย่าง SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| แผนก Department | แผนกภายในที่รับผิดชอบกิจกรรมปัจจุบัน. | ||
| คำอธิบาย จับคู่ เหตุผลที่สำคัญ รวมผลการดำเนินงานตามหน้าที่ทางธุรกิจ. แหล่งข้อมูล ได้มาจากตารางผู้ใช้หรือการจับคู่ลำดับชั้นองค์กร. ตัวอย่าง ฝ่ายปฏิบัติการComplianceฝ่ายบริหารเงินฝ่ายสนับสนุน IT | |||
| มีการทำงานซ้ำหรือไม่ IsRework | ตัวบ่งชี้ว่ารายการชำระเงินมีการทำกิจกรรมซ้ำหรือไม่. | ||
| คำอธิบาย ค่าสถานะแบบบูลีนที่คำนวณระหว่างประมวลผลข้อมูล โดยกำหนดเป็น true หากกิจกรรม เช่น 'ตรวจสอบรายละเอียดการชำระเงินแล้ว' เกิดขึ้นมากกว่าหนึ่งครั้ง หรือพบวงจรข้อผิดพลาด ค่านี้ใช้คำนวณ KPI 'อัตราการทำงานซ้ำในการชำระเงิน'. เหตุผลที่สำคัญ ช่วยระบุกรณีที่ไม่มีประสิทธิภาพได้อย่างรวดเร็ว โดยไม่ต้องเขียนคำค้นกระบวนการที่ซับซ้อน. แหล่งข้อมูล คำนวณในไปป์ไลน์ข้อมูล โดยตรวจหากิจกรรมที่ซ้ำกันในแต่ละกรณี. ตัวอย่าง truefalse | |||
| ยอดชำระเงิน PaymentAmount | มูลค่าเงินของธุรกรรมการชำระเงิน. | ||
| คำอธิบาย ระบุมูลค่าเงินที่โอน ข้อมูลนี้เป็นบริบทสำคัญสำหรับการวิเคราะห์ 'ปริมาณการชำระเงิน' และจัดลำดับความสำคัญของคอขวด รายการมูลค่าสูงมักต้องผ่านขั้นตอนอนุมัติที่เข้มงวดกว่ารายการมูลค่าต่ำที่ประมวลผลอัตโนมัติ ซึ่งช่วยให้วิเคราะห์รูปแบบกระบวนการได้. เหตุผลที่สำคัญ ช่วยแบ่งกลุ่มตามมูลค่าและคำนวณปริมาณรวมที่ประมวลผลแล้ว. แหล่งข้อมูล ตารางรายละเอียดธุรกรรม โดยทั่วไปใช้ฟิลด์ AMT, TRANS_AMOUNT หรือ PRINCIPAL_AMOUNT. ตัวอย่าง 1500.00250000.5050.001000000.00 | |||
| รหัสข้อผิดพลาด ErrorCode | รหัสที่ระบบสร้างเมื่อการชำระเงินล้มเหลวหรือต้องแก้ไข. | ||
| คำอธิบาย บันทึกสาเหตุเฉพาะของเหตุการณ์ 'การชำระเงินล้มเหลว' หรือ 'ตรวจพบข้อผิดพลาดในการชำระเงิน' การจัดกลุ่มตามแอตทริบิวต์นี้ในแดชบอร์ด 'การวิเคราะห์การชำระเงินล้มเหลวและงานแก้ไข' ช่วยให้ธุรกิจระบุสาเหตุหลักที่พบบ่อยที่สุด เช่น 'เงินไม่พอ' หรือ 'บัญชีไม่ถูกต้อง'. เหตุผลที่สำคัญ จำเป็นต่อการวิเคราะห์หาสาเหตุหลักของความล้มเหลวในกระบวนการ. แหล่งข้อมูล บันทึกข้อผิดพลาดหรือคอลัมน์สาเหตุของสถานะ ซึ่งมักใช้ชื่อ REASON_CODE หรือ RETURN_CODE. ตัวอย่าง R01AM04BE05TECH_ERR_001 | |||
| วันครบกำหนดชำระเงิน PaymentDueDate | วันที่ต้องชำระเงินให้เสร็จเพื่อให้ถือว่าชำระตรงเวลา. | ||
| คำอธิบาย เก็บวันที่ดำเนินการตามสัญญาหรือวันที่ร้องขอ โดยนำไปเปรียบเทียบกับวันที่ชำระเงินจริงเพื่อคำนวณ KPI 'อัตราการชำระเงินตรงเวลา' และใช้กับแดชบอร์ด 'การปฏิบัติตามกำหนดชำระเงิน'. เหตุผลที่สำคัญ ใช้เป็นเกณฑ์วัดการปฏิบัติตาม SLA และการชำระเงินตรงเวลา. แหล่งข้อมูล คำสั่งธุรกรรม โดยทั่วไปใช้ฟิลด์ VALUE_DATE, EXECUTION_DATE หรือ DUE_DATE. ตัวอย่าง 2023-11-012023-11-05 | |||
| สกุลเงินที่ใช้ชำระ PaymentCurrency | รหัสสกุลเงิน ISO ของยอดชำระเงิน. | ||
| คำอธิบาย ระบุสกุลเงินของ เหตุผลที่สำคัญ จำเป็นต่อการแปลความหมายยอดชำระเงินให้ถูกต้อง. แหล่งข้อมูล ตารางรายละเอียดธุรกรรม โดยทั่วไปใช้ฟิลด์ CCY, CURRENCY_CODE หรือ ISO_CODE. ตัวอย่าง USDEURGBPJPY | |||
| ชำระเงินล่าช้าหรือไม่ IsPaymentLate | ตัวบ่งชี้ว่าชำระเงินหลังวันครบกำหนดหรือไม่. | ||
| คำอธิบาย ค่าสถานะแบบบูลีนที่เปรียบเทียบวันที่ชำระเงินจริงกับ เหตุผลที่สำคัญ ช่วยให้การรายงานการปฏิบัติตามข้อกำหนดทำได้ง่ายขึ้น. แหล่งข้อมูล คำนวณจาก: SettlementDate > PaymentDueDate. ตัวอย่าง truefalse | |||
| ชื่อผู้รับเงิน BeneficiaryName | ชื่อหน่วยงานที่ได้รับเงิน. | ||
| คำอธิบาย ระบุคู่สัญญาในธุรกรรม การวิเคราะห์ฟิลด์นี้ช่วยค้นหาผู้ขายหรือลูกค้าที่เกี่ยวข้องกับอัตราการทำงานซ้ำหรือความล่าช้าสูง และสนับสนุน 'การวิเคราะห์การชำระเงินล้มเหลวและงานแก้ไข'. เหตุผลที่สำคัญ ระบุผู้รับเงิน ซึ่งเป็นประโยชน์ต่อการวิเคราะห์ที่เน้นลูกค้า. แหล่งข้อมูล รายการรายละเอียดการชำระเงิน โดยใช้ฟิลด์ เช่น CREDITOR_NAME, BENE_NAME หรือ PAYEE. ตัวอย่าง Acme CorpGlobal Supplies LtdJohn Smith | |||
| ภูมิภาคต้นทาง OriginatingRegion | ภูมิภาคที่เป็นต้นทางของคำขอชำระเงิน. | ||
| คำอธิบาย ระบุตำแหน่งทางกายภาพหรือเชิงตรรกะของผู้ร้องขอ มีประโยชน์ต่อการวิเคราะห์ 'รูปแบบกระบวนการชำระเงิน' เพื่อดูว่าภูมิภาคใดใช้ขั้นตอนที่ไม่เป็นมาตรฐานหรือมีอัตราการปฏิเสธสูงกว่า. เหตุผลที่สำคัญ ให้บริบทด้านภูมิศาสตร์สำหรับผลการดำเนินงานของกระบวนการ. แหล่งข้อมูล ส่วนหัวของธุรกรรม ซึ่งมักได้มาจากรหัสสาขาหรือรหัสประเทศ. ตัวอย่าง อเมริกาเหนือยุโรป ตะวันออกกลาง และแอฟริกาเอเชียแปซิฟิก | |||
| รหัสกระทบยอด ReconciliationId | รหัสที่เชื่อมโยงรายการชำระเงินกับบัญชีแยกประเภททั่วไปหรือระเบียนการกระทบยอด. | ||
| คำอธิบาย ระบบจะระบุรหัสนี้เมื่อเกิดกิจกรรม 'กระทบยอดการชำระเงินแล้ว' เพื่อยืนยันว่ารายการชำระเงินในระบบประมวลผลตรงกับรายการในระบบบัญชี หากไม่มีรหัสนี้ในรายการที่ชำระแล้ว แสดงว่าอาจเกิดปัญหาในการกระทบยอด. เหตุผลที่สำคัญ จำเป็นต่อแดชบอร์ด 'ประสิทธิภาพการกระทบยอดการชำระเงิน'. แหล่งข้อมูล ตารางการกระทบยอดหรือฟิลด์เฉพาะ เช่น RECON_REF หรือ GL_REF. ตัวอย่าง REC-9921GL-Entry-2023-11 | |||
| ระบบต้นทาง SourceSystem | ชื่อระบบที่เป็นแหล่งที่มาของข้อมูลเหตุการณ์. | ||
| คำอธิบาย ระบุแอปพลิเคชันหรือโมดูลในระบบนิเวศ ACI Worldwide เช่น ACI MTS, ACI UPF หรือระบบภายนอกที่เกี่ยวข้องในกระบวนการ ข้อมูลนี้สำคัญเป็นพิเศษเมื่อต้องเชื่อมข้อมูลจากบัญชีแยกประเภทหลายระบบ หรือเมื่อรายการชำระเงินผ่านระบบหักบัญชีภายนอก. เหตุผลที่สำคัญ ช่วยระบุบริบทว่าดึงข้อมูลมาจากที่ใด ซึ่งเป็นประโยชน์ต่อการตรวจสอบที่มาของข้อมูลเมื่อเกิดปัญหา. แหล่งข้อมูล กำหนดค่าไว้ระหว่างการดึงข้อมูล หรือได้มาจากคอลัมน์ SystemID หากมีหลายอินสแตนซ์. ตัวอย่าง ACI MTSACI UPPSAP GLSwift Gateway | |||
| ระยะเวลาในขั้นตอนอนุมัติ ApprovalCycleTime | ระยะเวลาที่ใช้ในขั้นตอนอนุมัติ. | ||
| คำอธิบาย คำนวณเวลาตั้งแต่ 'ส่งรายการชำระเงินเพื่อขออนุมัติ' จนถึง 'อนุมัติการชำระเงิน' หรือถูกปฏิเสธ ตัวชี้วัดนี้ใช้ในแดชบอร์ด 'การวิเคราะห์ระยะเวลาของวงจรการอนุมัติการชำระเงิน' เพื่อแสดงความล่าช้าในขั้นตอนที่ต้องอาศัยการตัดสินใจของบุคลากร. เหตุผลที่สำคัญ แยกช่วงของกระบวนการที่ต้องอาศัยบุคลากรออกมาให้เห็นชัดเจน. แหล่งข้อมูล คำนวณจาก: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval). ตัวอย่าง 4 ชั่วโมง15 นาที | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาประทับที่ระบุว่ามีการดึงหรืออัปเดตระเบียนในโมเดลข้อมูลครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย ใช้ติดตามความใหม่ของข้อมูลที่นำมาวิเคราะห์ ค่านี้ไม่ใช่เวลาที่เหตุการณ์ในกระบวนการเกิดขึ้น แต่เป็นเวลาทางเทคนิคที่นำเข้าข้อมูล ช่วยให้นักวิเคราะห์ทราบว่ากำลังดูข้อมูลปัจจุบันหรือข้อมูลย้อนหลัง. เหตุผลที่สำคัญ ช่วยให้ข้อมูลเป็นปัจจุบันและตรวจพบข้อมูลเก่าในแดชบอร์ด. แหล่งข้อมูล เวลาของระบบขณะที่สคริปต์ ETL ทำงาน. ตัวอย่าง 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
กิจกรรมในการประมวลผลการชำระเงิน
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| ชำระเงินเสร็จสิ้นแล้ว | การยืนยันขั้นสุดท้ายว่ากระบวนการชำระเงินเสร็จสมบูรณ์และเงินเข้าบัญชีผู้รับแล้ว ถือเป็นการสิ้นสุดธุรกรรมและเป็นเหตุการณ์สำคัญที่แสดงว่าการชำระเงินตลอดทั้งวงจรสำเร็จ. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์สิ้นสุดหลักที่แสดงว่ากระบวนการสำเร็จ ใช้คำนวณเวลาตั้งแต่ต้นจนจบและปริมาณงานที่ประมวลผลได้ อีกทั้งเป็นข้อมูลสำคัญสำหรับแดชบอร์ดวัดผลการดำเนินงานตั้งแต่ต้นจนจบเกือบทั้งหมด. แหล่งข้อมูล โดยทั่วไปจะบันทึกเป็นเหตุการณ์อย่างชัดเจนเมื่อได้รับข้อความยืนยันการชำระบัญชีขั้นสุดท้ายจากเครือข่าย หรือเมื่ออัปเดตบัญชีแยกประเภทภายในเพื่อระบุว่าธุรกรรมเสร็จสมบูรณ์. บันทึก บันทึกเมื่อได้รับไฟล์หรือข้อความยืนยันการชำระเงินขั้นสุดท้าย และอัปเดตสถานะเป็น 'ชำระเงินแล้ว'. ประเภทเหตุการณ์ explicit | |||
| ตรวจพบข้อผิดพลาดในการชำระเงิน | ระบุว่าระบบตรวจพบปัญหาเกี่ยวกับการชำระเงินในขั้นตอนใดขั้นตอนหนึ่ง เช่น ข้อมูลไม่ถูกต้องหรือมีการแจ้งเตือนด้านการปฏิบัติตามข้อกำหนด โดยทั่วไปเหตุการณ์นี้จะบันทึกไว้อย่างชัดเจนพร้อมรหัสข้อผิดพลาด. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นสำหรับการวิเคราะห์งานที่ต้องทำซ้ำและการจัดการกรณียกเว้น จำเป็นต่อแดชบอร์ด 'การวิเคราะห์การชำระเงินล้มเหลวและงานแก้ไข' และ 'ระยะเวลาแก้ไขข้อผิดพลาด'. แหล่งข้อมูล ค้นหารายการที่ระบุชัดเจนในตารางบันทึกข้อผิดพลาด หรือการเปลี่ยนสถานะเป็น 'ข้อผิดพลาด' หรือ 'ต้องแก้ไข' ในตารางธุรกรรม โดยควรเชื่อมโยงเหตุการณ์เหล่านี้กับ Payment Transaction ID. บันทึก ระบบจะบันทึกเหตุการณ์ไว้อย่างชัดเจนเมื่อกลไกตรวจสอบหรือประมวลผลแจ้งว่าพบข้อผิดพลาด. ประเภทเหตุการณ์ explicit | |||
| สร้างคำขอชำระเงินแล้ว | กิจกรรมนี้ระบุจุดเริ่มต้นของธุรกรรมการชำระเงินใหม่ในระบบ ACI Worldwide โดยทั่วไปจะบันทึกเป็นเหตุการณ์อย่างชัดเจนเมื่อผู้ใช้หรือระบบต้นทางส่งคำขอชำระเงิน ทำให้เกิดระเบียนธุรกรรมใหม่ที่มี ID ไม่ซ้ำกัน. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการชำระเงิน การวิเคราะห์เวลาตั้งแต่กิจกรรมนี้จนถึงเสร็จสิ้นจะช่วยคำนวณเวลาตั้งแต่ต้นจนจบ ซึ่งจำเป็นต่อการวัดประสิทธิภาพโดยรวมของกระบวนการ. แหล่งข้อมูล โดยทั่วไปจะเป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนในตารางธุรกรรมหลักหรือบันทึกเหตุการณ์เฉพาะใน ACI ให้ค้นหาเวลาประทับการสร้างที่เชื่อมโยงกับ Payment Transaction ID. บันทึก ระบุได้จากระเบียนการสร้างหรือเหตุการณ์ 'Create' ที่บันทึกไว้อย่างชัดเจนในบันทึกธุรกรรม. ประเภทเหตุการณ์ explicit | |||
| อนุมัติการชำระเงินในระบบแล้ว | หมายถึงการอนุมัติการชำระเงินในระดับระบบหลังจากได้รับอนุมัติจากบุคลากร โดยตรวจสอบเงินทุนหรือกฎป้องกันการฉ้อโกง อาจบันทึกเป็นรายการในบันทึกอย่างชัดเจน หรืออนุมานได้จากการเปลี่ยนสถานะที่ระบุว่าพร้อมดำเนินการ. | ||
| เหตุผลที่สำคัญ นี่คือจุดควบคุมสำคัญก่อนส่งคำสั่งให้เคลื่อนย้ายเงิน ความล่าช้าในขั้นตอนนี้อาจบ่งชี้ถึงปัญหาประสิทธิภาพของระบบ หรือปัญหาในระบบย่อยด้านการปฏิบัติตามข้อกำหนดและการตรวจสอบการฉ้อโกง. แหล่งข้อมูล ตรวจสอบว่ามีบันทึกอย่างชัดเจนในบันทึกการประมวลผลของระบบหรือบันทึกความปลอดภัยหรือไม่ หรืออนุมานได้จากการเปลี่ยนสถานะจาก 'Approved' เป็น 'Authorized for Payment'. บันทึก ระบบบันทึกกิจกรรมนี้ผ่านกลไกประมวลผลการชำระเงิน หลังผ่านการตรวจสอบภายในขั้นสุดท้าย. ประเภทเหตุการณ์ explicit | |||
| อนุมัติการชำระเงินแล้ว | ขั้นตอนสำคัญที่ผู้ใช้ซึ่งมีอำนาจอนุมัติการชำระเงิน เพื่อให้ดำเนินการต่อได้ โดยปกติจะบันทึกเป็นเหตุการณ์อย่างชัดเจนเมื่อผู้อนุมัติดำเนินการผ่านหน้าจอของระบบ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดตรวจสอบสำคัญและมักเป็นคอขวด การวิเคราะห์เวลารอก่อนถึงขั้นตอนนี้และระยะเวลาของรอบการอนุมัติช่วยให้พบโอกาสเร่งการชำระเงิน. แหล่งข้อมูล ค้นหาเหตุการณ์ที่บันทึกไว้อย่างชัดเจนในตารางบันทึกการอนุมัติ หรือการเปลี่ยนสถานะเป็น 'Approved' ในตารางธุรกรรมหลัก ซึ่งเชื่อมโยงกับการดำเนินการและเวลาประทับของผู้ใช้รายใดรายหนึ่ง. บันทึก บันทึกเมื่อผู้ใช้ที่มีอำนาจดำเนินการอนุมัติในระบบเสร็จสิ้น. ประเภทเหตุการณ์ explicit | |||
| โอนเงินแล้ว | ระบุว่าได้รับการยืนยันจากเครือข่ายการชำระเงินแล้วว่าได้หักเงินจากบัญชีผู้ชำระสำเร็จ โดยทั่วไปจะบันทึกจากข้อความสถานะขาเข้าของเครือข่าย. | ||
| เหตุผลที่สำคัญ ยืนยันว่าเครือข่ายภายนอกดำเนินการชำระเงินสำเร็จแล้ว เป็นจุดเริ่มต้นของช่วงเวลาการชำระบัญชี และเป็นข้อมูลสำคัญสำหรับ KPI 'Average Payment Settlement Time'. แหล่งข้อมูล เป็นเหตุการณ์ที่เกิดขึ้นอย่างชัดเจนเมื่อได้รับข้อความอัปเดตสถานะขาเข้า เช่น MT103 จาก SWIFT หรือการยืนยันจาก ACH ซึ่งจะอัปเดตระเบียนการชำระเงิน. บันทึก บันทึกเมื่อได้รับข้อความยืนยันจากเครือข่ายหักบัญชีภายนอก. ประเภทเหตุการณ์ explicit | |||
| กระทบยอดการชำระเงินแล้ว | หมายถึงขั้นตอนสุดท้ายทางบัญชีที่จับคู่ธุรกรรมการชำระเงินใน ACI กับรายการเดินบัญชีธนาคารหรือรายการบัญชีแยกประเภท อาจบันทึกเป็นเหตุการณ์โดยตรงจากโมดูลกระทบยอด หรืออนุมานจากการเปลี่ยนสถานะ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ใช้วัดประสิทธิภาพของกระบวนการกระทบยอดในส่วนงานหลังบ้าน ความล่าช้าในขั้นตอนนี้อาจกระทบความถูกต้องของรายงานทางการเงิน และทำให้ปัญหาการชำระเงินที่ยังไม่เสร็จสิ้นถูกมองข้าม. แหล่งข้อมูล ข้อมูลนี้อาจมาจากโมดูลกระทบยอดเฉพาะใน ACI หรือระบบ ERP ภายนอก โดยบันทึกจากการอัปเดตสถานะรายการชำระเงินเป็น 'กระทบยอดแล้ว'. บันทึก อนุมานจากการอัปเดตสถานะสุดท้ายเป็น 'กระทบยอดแล้ว' หรือจากข้อมูลการกระทบยอดที่เชื่อมด้วย Payment ID. ประเภทเหตุการณ์ inferred | |||
| การชำระเงินล้มเหลว | สถานะสิ้นสุดที่ระบุว่าไม่สามารถดำเนินการชำระเงินให้เสร็จได้ เนื่องจากเกิดปัญหาที่แก้ไขไม่ได้ ต่างจากข้อผิดพลาดที่ยังแก้ไขได้ และหมายถึงการสิ้นสุดด้วยความล้มเหลวอย่างชัดเจน. | ||
| เหตุผลที่สำคัญ การติดตามเหตุการณ์สิ้นสุดนี้สำคัญต่อการคำนวณอัตราการชำระเงินล้มเหลวโดยรวม การวิเคราะห์สาเหตุของความล้มเหลวช่วยปรับปรุงคุณภาพข้อมูลและกฎของกระบวนการได้. แหล่งข้อมูล อนุมานจากสถานะสิ้นสุด เช่น 'ล้มเหลว', 'ยกเลิก' หรือ 'ธนาคารปฏิเสธ' ในข้อมูลธุรกรรม ซึ่งไม่มีการเปลี่ยนแปลงหลังจากนั้น. บันทึก อนุมานจากสถานะความล้มเหลวขั้นสุดท้ายในรายการชำระเงิน. ประเภทเหตุการณ์ inferred | |||
| แก้ไขข้อผิดพลาดในการชำระเงินแล้ว | ระบุจุดที่ผู้ใช้แก้ไขข้อผิดพลาดที่ตรวจพบก่อนหน้านี้แล้ว และส่งรายการชำระเงินกลับไปประมวลผลอีกครั้ง โดยมักอนุมานจากการเปลี่ยนสถานะการชำระเงินจากสถานะข้อผิดพลาดกลับไปเป็นสถานะประมวลผลปกติ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ปิดวงจรการจัดการกรณียกเว้น ระยะเวลาตั้งแต่ 'ตรวจพบข้อผิดพลาดในการชำระเงิน' จนถึงเหตุการณ์นี้คือระยะเวลาแก้ไขข้อผิดพลาด ซึ่งเป็นตัวชี้วัดสำคัญของประสิทธิภาพการปฏิบัติการ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะออกจากสถานะ 'ข้อผิดพลาด' ไปเป็นสถานะประมวลผล เช่น 'รออนุมัติ' หรือ 'ตรวจสอบแล้ว' นอกจากนี้อาจบันทึกเป็นรายการการดำเนินการของผู้ใช้โดยตรง. บันทึก อนุมานจากการเปลี่ยนสถานะออกจากสถานะข้อผิดพลาด ซึ่งแสดงว่ามีการแก้ไขแล้ว. ประเภทเหตุการณ์ inferred | |||
| ตรวจสอบรายละเอียดการชำระเงินแล้ว | หมายถึงการตรวจสอบด้วยระบบอัตโนมัติหรือด้วยมือเสร็จสิ้น เพื่อยืนยันว่ารายละเอียดการชำระเงิน เช่น ข้อมูลผู้รับเงินและรหัสธนาคาร ถูกต้อง กิจกรรมนี้มักอนุมานได้จากการเปลี่ยนสถานะธุรกรรมจาก 'New' เป็น 'Validated' หรือ 'Pending Approval'. | ||
| เหตุผลที่สำคัญ ใช้ติดตามประสิทธิภาพของขั้นตอนตรวจสอบข้อมูลเบื้องต้น หากล่าช้าอาจทำให้เกิดคอขวดในขั้นตอนก่อนหน้าและเพิ่มโอกาสเกิดข้อผิดพลาดในการชำระเงินภายหลัง. แหล่งข้อมูล อนุมานได้จากฟิลด์การเปลี่ยนสถานะในตารางธุรกรรมการชำระเงินหลัก โดยเปรียบเทียบเวลาประทับระหว่างสถานะ 'Created' กับสถานะถัดมา เช่น 'Validated'. บันทึก อนุมานได้จากการเปลี่ยนแปลงฟิลด์สถานะการชำระเงิน เช่น จาก 'Entered' เป็น 'Validated'. ประเภทเหตุการณ์ inferred | |||
| ปฏิเสธการชำระเงินแล้ว | เกิดขึ้นเมื่อผู้อนุมัติปฏิเสธคำขอชำระเงิน ซึ่งมักต้องแก้ไขและส่งใหม่ เหตุการณ์นี้จะบันทึกไว้อย่างชัดเจน หยุดความคืบหน้าของการชำระเงิน และเริ่มวงจรการแก้ไขงาน. | ||
| เหตุผลที่สำคัญ ใช้ระบุการแก้ไขงานและความไม่มีประสิทธิภาพของกระบวนการ การติดตามความถี่ของการปฏิเสธช่วยวิเคราะห์ปัญหาคุณภาพข้อมูลเบื้องต้นหรือนโยบายการส่งคำขอ และสนับสนุนการวิเคราะห์งานแก้ไข. แหล่งข้อมูล บันทึกเป็นเหตุการณ์อย่างชัดเจนในบันทึกการอนุมัติ หรือเป็นการเปลี่ยนสถานะเป็น 'Rejected' ในตารางธุรกรรม เหตุการณ์อาจมีรหัสระบุเหตุผลที่ปฏิเสธด้วย. บันทึก บันทึกเมื่อผู้อนุมัติดำเนินการปฏิเสธในระบบเสร็จสิ้น. ประเภทเหตุการณ์ explicit | |||
| ยืนยันการชำระเงินแล้ว | หมายถึงการยืนยันภายในว่าได้ประมวลผลการชำระเงินสำเร็จและได้รับการยืนยันแล้ว โดยมักใช้เป็นจุดเริ่มต้นในการแจ้งผู้รับเงินหรือระบบภายในอื่นๆ. | ||
| เหตุผลที่สำคัญ ขั้นตอนสำคัญนี้จำเป็นต่อการวัดการชำระเงินให้ทันกำหนดและอัตราการชำระเงินตรงเวลา พร้อมระบุเวลาที่องค์กรถือว่าการชำระเงินดำเนินการสำเร็จอย่างชัดเจน. แหล่งข้อมูล โดยทั่วไปอนุมานได้จากการเปลี่ยนสถานะในตารางธุรกรรมการชำระเงินเป็น 'Confirmed' หรือ 'Completed' หลังได้รับการยืนยันจากเครือข่ายภายนอก. บันทึก อนุมานได้จากการเปลี่ยนสถานะเป็น 'Confirmed' หรือ 'Processed'. ประเภทเหตุการณ์ inferred | |||
| ส่งการชำระเงินเพื่อขออนุมัติแล้ว | ระบุว่าการชำระเงินผ่านการตรวจสอบเบื้องต้นแล้ว และถูกส่งต่อเพื่อขออนุมัติจากผู้จัดการหรือฝ่ายการเงินตามที่จำเป็น โดยทั่วไปจะบันทึกเป็นการเปลี่ยนสถานะในเวิร์กโฟลว์การชำระเงิน. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นของกระบวนการย่อยการอนุมัติ การวัดเวลาตั้งแต่จุดนี้จนถึง 'Payment Approved' สำคัญต่อแดชบอร์ด 'Payment Approval Cycle Time Analysis'. แหล่งข้อมูล อนุมานได้จากการเปลี่ยนฟิลด์สถานะการชำระเงินในข้อมูลธุรกรรม เช่น การเปลี่ยนเป็น 'Pending Approval'. บันทึก อนุมานได้จากการเปลี่ยนสถานะเป็น 'Pending Approval' หรือสถานะใกล้เคียง พร้อมเวลาประทับที่เกี่ยวข้อง. ประเภทเหตุการณ์ inferred | |||
| ส่งคำสั่งชำระเงินแล้ว | ระบุจุดที่รวบรวมคำสั่งชำระเงินและส่งไปยังเครือข่ายการชำระเงินภายนอก เช่น SWIFT, ACH หรือ SEPA โดยระบบ ACI จะบันทึกการส่งต่อข้อมูลนี้ไว้อย่างชัดเจนเพื่อการตรวจสอบและติดตาม. | ||
| เหตุผลที่สำคัญ สำหรับการชำระเงินหลายประเภท นี่คือจุดที่ย้อนกลับไม่ได้ การติดตามขั้นตอนนี้ช่วยวัดเวลาประมวลผลภายในก่อนที่หน่วยงานภายนอกจะเข้ามาดำเนินการต่อ. แหล่งข้อมูล เกือบทุกกรณีจะเป็นเหตุการณ์ที่บันทึกไว้อย่างชัดเจนในบันทึกธุรกรรมหรือบันทึกข้อความของ ACI และมักมีหมายเลขอ้างอิงเฉพาะเครือข่าย. บันทึก ระบบสร้างรายการบันทึกอย่างชัดเจนเมื่อส่งข้อความการชำระเงินไปยังเครือข่ายภายนอก. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
ขั้นตอน
เข้าถึงสภาพแวดล้อมฐานข้อมูล: เข้าสู่ระบบ SQL Server ที่โฮสต์ฐานข้อมูล ACI Postilion Realtime โดยใช้ SQL Server Management Studio (SSMS) หรือไคลเอนต์ที่รองรับ
ค้นหาตารางหลัก: ค้นหาตาราง
post_tran(บันทึกรายการธุรกรรม) และpost_tran_cust(ส่วนขยายข้อมูลที่กำหนดเอง) ตรวจสอบว่าคุณมีสิทธิ์SELECTในตารางเหล่านี้กำหนดตัวระบุเคส: การดึงข้อมูลนี้ใช้
retrieval_reference_nrเป็นPaymentTransactionIdหากระบบของคุณใช้คีย์เฉพาะอื่น เช่นsystem_trace_audit_nrร่วมกับtransmission_date_timeให้ปรับการเลือกข้อมูลในคิวรีตามนั้นกำหนดพารามิเตอร์ตัวกรอง: เปิดคิวรีด้านล่าง แล้วค้นหาตัวแปร
@StartDateและ@EndDateที่ส่วนต้นของสคริปต์ กำหนดช่วงเวลาที่ต้องการดึงข้อมูล เช่น 30 ถึง 90 วันล่าสุด เพื่อให้ทำงานได้มีประสิทธิภาพตรวจสอบตรรกะกิจกรรม: คิวรีจับคู่ประเภทข้อความ ISO 8583 เช่น 0200 และ 0210 รวมถึงรหัสการตอบกลับ กับกิจกรรม process mining ทั้ง 14 รายการ ตรวจสอบคำสั่ง
CASEให้ตรงกับการตั้งค่าอินเทอร์เฟซ ACI ของคุณเรียกใช้คิวรี: เรียกใช้สคริปต์ทั้งหมด คิวรีใช้
UNION ALLปรับสถานะธุรกรรมประเภทต่างๆ ให้อยู่ในรูปแบบบันทึกเหตุการณ์เดียวกันตรวจสอบข้อมูลผลลัพธ์: ตรวจสอบว่ามีคอลัมน์ที่จำเป็น ได้แก่
PaymentTransactionId,ActivityNameและEventTimestampและไม่มีฟิลด์สำคัญใดมีค่าNULLโดยไม่คาดหมายส่งออกข้อมูล: คลิกขวาที่ตารางผลลัพธ์ใน SSMS แล้วบันทึกเป็นไฟล์ CSV เช่น
ACI_Payments_EventLog.csvจัดรูปแบบสำหรับ ProcessMind: เปิดไฟล์ CSV และตรวจสอบว่า
EventTimestampใช้รูปแบบมาตรฐาน (YYYY-MM-DD HH:MM:SS) และPaymentAmountมีเฉพาะค่าตัวเลขอัปโหลด: นำเข้าไฟล์ CSV ที่ตรวจสอบแล้วไปยัง ProcessMind โดยจับคู่คอลัมน์กับรหัสเคส กิจกรรม และการประทับเวลาตามลำดับ
การกำหนดค่า
- Date Range: ตาราง ACI
post_tranมีขนาดเพิ่มขึ้นอย่างรวดเร็ว แนะนำอย่างยิ่งให้จำกัดการดึงข้อมูลไว้ที่ช่วงย้อนหลัง 3 เดือน หรือใช้ partition switching หากระบบรองรับ. - Response Codes: คำสั่งค้นหากำหนดให้
rsp_code = '00'หมายถึงสำเร็จ หากสถาบันของคุณใช้รหัสอนุมัติหรือสำเร็จอื่น เช่น '08' หรือ '10' ให้ปรับตัวกรอง. - Message Types (ISO 8583): สคริปต์ใช้ประเภทข้อความมาตรฐาน (0100/0200 สำหรับคำขอ และ 0210 สำหรับการตอบกลับ) หากมีการกำหนดประเภทข้อความเองใน
source_node_nameอาจต้องปรับสคริปต์. - System Performance: คำสั่งค้นหานี้ใช้คำใบ้
NOLOCKเพื่อป้องกันการบล็อกการประมวลผลธุรกรรมที่กำลังทำงาน อย่านำคำใบ้เหล่านี้ออกจากระบบใช้งานจริง. - Currencies: ดึงจำนวนเงินออกมาเป็นค่าดิบ หากต้องปรับมาตรฐานหลายสกุลเงินระหว่างการวิเคราะห์ ให้ใช้
tran_currency_code.
ตัวอย่างคำค้น sql
DECLARE @StartDate DATETIME = '2023-01-01 00:00:00';
DECLARE @EndDate DATETIME = '2023-01-31 23:59:59';
/* 1. Payment Request Created: Initial transaction request received */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Request Created' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Origination' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200') -- Authorization/Financial Request
UNION ALL
/* 2. Payment Details Validated: Inferred after request but before routing */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Details Validated' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.rsp_code = '00' -- Implies validation passed
UNION ALL
/* 3. Payment Sent For Approval: Routing to internal authorization */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Sent For Approval' AS ActivityName,
DATEADD(second, 2, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.tran_amount_req > 1000 -- Example threshold for approval logic
UNION ALL
/* 4. Payment Approved: Successful response code logic */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Approved' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Approver' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type IN ('0110', '0210')
UNION ALL
/* 5. Payment Rejected: Specific rejection codes */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Rejected' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('51', '05', '61') -- Insufficient funds, Do not honor, etc.
UNION ALL
/* 6. Payment Authorized: Successful authorization completion */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Authorized' AS ActivityName,
DATEADD(millisecond, 500, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0110' -- Authorization Response
UNION ALL
/* 7. Payment Instruction Sent: Handoff to Sink Node */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Instruction Sent' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Network Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.sink_node_name IS NOT NULL
AND t.message_type IN ('0200', '0100')
UNION ALL
/* 8. Funds Transferred: External network confirmation */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Funds Transferred' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Treasury' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210' -- Financial Response
UNION ALL
/* 9. Payment Confirmed: Final acknowledgment */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Confirmed' AS ActivityName,
DATEADD(second, 5, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Customer Service' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
UNION ALL
/* 10. Payment Settled: Settlement/Reconciliation message */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Settled' AS ActivityName,
ISNULL(t.settle_date, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Settlement Engine' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Accounting' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type = '0500' -- Reconciliation
AND t.rsp_code = '00'
UNION ALL
/* 11. Payment Failed: System Errors */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Failed' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'IT Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('91', '96', '06') -- Issuer down, System malfunction
UNION ALL
/* 12. Payment Error Identified: General Error */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Identified' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code NOT IN ('00')
AND t.message_type IN ('0210', '0110')
UNION ALL
/* 13. Payment Error Resolved: Reversal or Correction followed by Success */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Resolved' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0400', '0420') -- Reversal/Advice
UNION ALL
/* 14. Payment Reconciled: Batch processing flag from Custom Table */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Reconciled' AS ActivityName,
ISNULL(c.recon_date, DATEADD(hour, 24, t.datetime_req)) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Recon Module' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Finance' AS Department
FROM post_tran t WITH (NOLOCK)
JOIN post_tran_cust c WITH (NOLOCK) ON t.post_tran_cust_id = c.post_tran_cust_id
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
AND c.recon_date IS NOT NULL; พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เป็นแนวทางเริ่มดึงข้อมูลการประมวลผลการชำระเงิน ค้นพบข้อมูลเชิงลึกที่มีประโยชน์และเพิ่มประสิทธิภาพเวิร์กโฟลว์ทางการเงินของคุณได้ตั้งแต่วันนี้.
ปรับปรุงการประมวลผลการชำระเงิน เริ่มทดลองใช้ฟรีวันนี้
ลดข้อยกเว้นในการชำระเงินและทำให้ประมวลผลแบบอัตโนมัติตั้งแต่ต้นจนจบได้ 98%.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จในไม่กี่นาที