> การปรับปรุงกระบวนการอย่างต่อเนื่อง > การประมวลผลการชำระเงิน > Fiserv > เทมเพลตข้อมูล

เทมเพลตข้อมูลการประมวลผลการชำระเงินของคุณ

Name: เทมเพลตข้อมูล process mining สำหรับกระบวนการ การประมวลผลการชำระเงิน
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

เทมเพลตข้อมูลการประมวลผลการชำระเงินของคุณ

← กลับไปยังคู่มือการปรับปรุง

แอตทริบิวต์การประมวลผลการชำระเงิน(19) กิจกรรมในการประมวลผลการชำระเงิน(13) คู่มือการดึงข้อมูล(1)

เทมเพลตข้อมูลการประมวลผลการชำระเงินของคุณ

เทมเพลตนี้เป็นกรอบข้อมูลที่ช่วยจัดรูปแบบข้อมูล Fiserv ให้พร้อมสำหรับ process mining และการวิเคราะห์ โดยระบุคุณลักษณะและกิจกรรมสำคัญที่จำเป็นต่อการมองเห็นรอบการชำระบัญชีและการกระทบยอดอย่างชัดเจน เมื่อทำตามแนวทางนี้ คุณจะสร้างบันทึกเหตุการณ์ที่ช่วยชี้ให้เห็นจุดที่ไม่มีประสิทธิภาพและความเสี่ยงด้านการปฏิบัติตามข้อกำหนดในการปฏิบัติการทางการเงินได้.

แอตทริบิวต์ที่แนะนำสำหรับการวิเคราะห์การชำระเงิน
จุดสำคัญในกระบวนการที่ควรติดตาม
คำแนะนำทางเทคนิคสำหรับการดึงข้อมูล Fiserv

เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

ดาวน์โหลดเทมเพลต

แอตทริบิวต์การประมวลผลการชำระเงิน

ฟิลด์ข้อมูลที่แนะนำเหล่านี้ให้บริบทที่จำเป็นแก่บันทึกเหตุการณ์ เพื่อช่วยวิเคราะห์วงจรการชำระเงินทั้งหมดได้อย่างครบถ้วน.

5 จำเป็น 9 แนะนำ 5 ไม่บังคับ

	ชื่อ	คำอธิบาย
	ชื่อกิจกรรม ActivityName	เหตุการณ์หรือการเปลี่ยนสถานะที่เกิดขึ้นในกระบวนการชำระเงิน.
คำอธิบาย แอตทริบิวต์นี้ระบุขั้นตอนที่ดำเนินการ เช่น 'สร้างคำขอชำระเงินแล้ว' หรือ 'ชำระเงินเสร็จแล้ว' และกำหนดโหนดในแผนผังกระบวนการ จึงสำคัญต่อการทำความเข้าใจลำดับการปฏิบัติงาน. การวิเคราะห์กิจกรรมที่แตกต่างกันช่วยให้องค์กรมองเห็นเวิร์กโฟลว์ ระบุขั้นตอนที่ถูกข้าม และตรวจพบเส้นทางที่ไม่เป็นไปตามข้อกำหนด เช่น การข้ามการตรวจสอบหรือการอนุมัติที่จำเป็น. เหตุผลที่สำคัญ กำหนดเหตุการณ์ที่ประกอบกันเป็นลำดับเวลาของกระบวนการ. แหล่งข้อมูล บันทึกประวัติธุรกรรมหรือตารางตรวจสอบการเปลี่ยนสถานะ. ตัวอย่าง สร้างคำขอชำระเงินอนุมัติให้ชำระเงินแล้วพบข้อผิดพลาดในการชำระเงินชำระเงินเสร็จสมบูรณ์ยกเลิกการชำระเงินแล้ว
	รหัสธุรกรรมการชำระเงิน PaymentTransactionId	รหัสเฉพาะของคำสั่งชำระเงินหรือกรณีธุรกรรมแต่ละรายการ.
คำอธิบาย แอตทริบิวต์นี้เป็นรหัสหลักที่ใช้เชื่อมโยงกิจกรรมทั้งหมดตลอดวงจรการชำระเงินรายการเดียว นักวิเคราะห์จึงติดตามเส้นทางตั้งแต่ได้รับคำขอ ตรวจสอบ อนุมัติ ไปจนถึงชำระบัญชีหรือยกเลิกได้. ในระบบ Fiserv รหัสนี้มักเป็นคีย์หลักในตารางประวัติธุรกรรม ซึ่งจำเป็นต่อการสร้างลำดับกระบวนการขึ้นใหม่ และเชื่อมโยงเหตุการณ์ที่เกิดห่างกัน เช่น การชำระบัญชีที่เกิดขึ้นหลายวันหลังอนุมัติ ให้เป็นธุรกรรมเดียวกันได้อย่างถูกต้อง. เหตุผลที่สำคัญ เป็น Case ID หลักที่ใช้จัดกลุ่มเหตุการณ์ให้เป็นอินสแตนซ์ของกระบวนการ. แหล่งข้อมูล ดูเอกสาร Fiserv เกี่ยวกับตาราง Transaction หรือ Payment Header. ตัวอย่าง TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	เวลาประทับของเหตุการณ์ EventTimestamp	วันที่และเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ.
คำอธิบาย แอตทริบิวต์นี้บันทึกเวลาที่เกิดเหตุการณ์อย่างแม่นยำ และเป็นข้อมูลพื้นฐานสำหรับการวิเคราะห์ด้านเวลา ทั้งระยะเวลารอบงาน ระยะเวลาตั้งแต่เริ่มจนเสร็จ และการระบุคอขวด. ข้อมูลนี้ใช้คำนวณระยะเวลาระหว่างขั้นตอนในแดชบอร์ด เช่น เวลาตั้งแต่ 'สร้างคำขอชำระเงิน' จนถึง 'อนุมัติการชำระเงิน' เวลาประทับที่มีความละเอียดสูงช่วยจัดลำดับเหตุการณ์ที่เกิดขึ้นต่อเนื่องกันอย่างรวดเร็วได้อย่างแม่นยำ. เหตุผลที่สำคัญ จำเป็นต่อการจัดลำดับเหตุการณ์และคำนวณระยะเวลาการทำงานของกระบวนการ. แหล่งข้อมูล บันทึกการตรวจสอบหรือคอลัมน์เวลาประทับการอัปเดตธุรกรรม. ตัวอย่าง 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	ระบบต้นทาง SourceSystem	ชื่อระบบที่เป็นแหล่งที่มาของข้อมูล.
คำอธิบาย ระบุโมดูล Fiserv หรือระบบภายนอกที่สร้างเหตุการณ์นั้น มีประโยชน์เป็นพิเศษในสภาพแวดล้อมที่ซับซ้อน ซึ่งการชำระเงินอาจเริ่มจากช่องทางส่วนหน้าและไปชำระบัญชีในระบบธนาคารหลักส่วนหลัง. นักวิเคราะห์สามารถกรองมุมมองกระบวนการตามระบบต้นทาง เพื่อเจาะจงวิเคราะห์สภาพแวดล้อมทางเทคนิคหรือจุดเชื่อมต่อแต่ละจุดได้. เหตุผลที่สำคัญ ให้บริบททางเทคนิคและที่มาของข้อมูล. แหล่งข้อมูล กำหนดค่าไว้ระหว่างการดึงข้อมูลหรือใช้ข้อมูลเมตาของระบบ. ตัวอย่าง Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	อัปเดตข้อมูลล่าสุด LastDataUpdate	เวลาประทับที่ดึงหรือรีเฟรชระเบียนครั้งล่าสุด.
คำอธิบาย แสดงว่าข้อมูลที่ใช้วิเคราะห์เป็นข้อมูลล่าสุดเพียงใด ซึ่งสำคัญต่อการพิจารณาว่าแดชบอร์ดแสดงการปฏิบัติการแบบเรียลไทม์หรือข้อมูลย้อนหลัง. ช่วยให้ผู้ใช้มั่นใจในตัวชี้วัดที่แสดง และไม่ตัดสินใจจากข้อมูลเก่า โดยเฉพาะเมื่อติดตามการปฏิบัติตามเวลาตัดรอบหรือคอขวดที่ยังเกิดขึ้นอยู่. เหตุผลที่สำคัญ ช่วยให้ข้อมูลเป็นปัจจุบันและเชื่อถือได้. แหล่งข้อมูล เวลาของระบบขณะเรียกใช้ ETL. ตัวอย่าง 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	จำนวนเงินที่ชำระ PaymentAmount	มูลค่าเงินของธุรกรรมการชำระเงิน.
คำอธิบาย แอตทริบิวต์นี้แสดงมูลค่าทางการเงินของการชำระเงิน และเป็นมิติหลักสำหรับแบ่งกลุ่มการวิเคราะห์ ช่วยให้ผู้ใช้แยกการชำระเงินมูลค่าสูงที่มีความสำคัญเชิงกลยุทธ์ออกจากธุรกรรมทั่วไปที่มีมูลค่าต่ำได้. ข้อมูลนี้จำเป็นต่อมุมมองการตรวจจับการชำระเงินซ้ำ โดยจำนวนเงินที่ตรงกันเมื่อพิจารณาร่วมกับรายละเอียดผู้ชำระเงินและผู้รับเงินอาจบ่งชี้ข้อผิดพลาด นอกจากนี้ยังช่วยวิเคราะห์อำนาจอนุมัติ เพราะยอดเงินที่สูงขึ้นมักทำให้ต้องใช้เวิร์กโฟลว์ที่ต่างออกไป. เหตุผลที่สำคัญ สำคัญต่อการวิเคราะห์ความเสี่ยงทางการเงินและตรวจจับรายการซ้ำ. แหล่งข้อมูล ตารางส่วนหัวธุรกรรม คอลัมน์ Amount. ตัวอย่าง 150.0025000.5010.991000000.00
	ประมวลผลตรงถึงปลายทางหรือไม่ IsStraightThroughProcessing	ระบุว่าการชำระเงินต้องมีผู้ดำเนินการด้วยตนเองหรือไม่.
คำอธิบาย แอตทริบิวต์บูลีนที่คำนวณขึ้น โดยมีค่าเป็นจริงเมื่อกรณีไม่มีขั้นตอน 'พบข้อผิดพลาดในการชำระเงิน' 'แก้ไขข้อผิดพลาดในการชำระเงินแล้ว' หรือ 'อนุมัติการชำระเงินแล้ว' ด้วยตนเอง ทั้งนี้ขึ้นอยู่กับนิยาม ใช้สนับสนุน KPI อัตราการประมวลผลแบบตรงถึงปลายทางโดยตรง. ช่วยแบ่งกระบวนการเป็นสองกลุ่ม คือขั้นตอนที่ทำงานอัตโนมัติทั้งหมดและขั้นตอนที่ต้องอาศัยบุคลากร ทำให้เห็นโอกาสในการทำงานอัตโนมัติได้ชัดเจน. เหตุผลที่สำคัญ ตัวชี้วัดหลักของประสิทธิภาพกระบวนการและความสำเร็จในการทำงานอัตโนมัติ. แหล่งข้อมูล คำนวณระหว่างการแปลงข้อมูล. ตัวอย่าง truefalse
	ผู้ดำเนินการประมวลผล ProcessingUser	รหัสผู้ใช้หรือเอเจนต์ระบบที่รับผิดชอบกิจกรรม.
คำอธิบาย ระบุผู้ดำเนินการ ไม่ว่าจะเป็นผู้อนุมัติหรือบอตระบบอัตโนมัติ ข้อมูลนี้ใช้กับแดชบอร์ดประสิทธิภาพรอบการแก้ไขข้อผิดพลาดและปริมาณงานตามอำนาจอนุมัติ. การติดตามผู้ใช้ช่วยให้นักวิเคราะห์ระบุความต้องการฝึกอบรมของผู้ที่มีอัตราข้อผิดพลาดสูง หรือพบคอขวดเมื่อผู้อนุมัติบางรายมีคำขอค้างมากเกินไป. เหตุผลที่สำคัญ ช่วยวิเคราะห์ทรัพยากรและระบุคอขวด. แหล่งข้อมูล บันทึกการตรวจสอบ คอลัมน์ User ID. ตัวอย่าง jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	รหัสข้อผิดพลาด ErrorCode	รหัสเฉพาะที่ระบบสร้างเมื่อการชำระเงินไม่ผ่านการตรวจสอบความถูกต้อง.
คำอธิบาย บันทึกรหัสข้อผิดพลาดทางเทคนิคหรือทางธุรกิจที่เกี่ยวข้องกับกิจกรรม 'พบข้อผิดพลาดในการชำระเงิน' แอตทริบิวต์นี้เป็นข้อมูลพื้นฐานของตัวติดตามข้อผิดพลาดจากการตรวจสอบและการแก้ไขงานซ้ำ. เมื่อรวบรวมความถี่ของรหัสข้อผิดพลาดแต่ละรายการ องค์กรจะระบุปัญหาคุณภาพข้อมูลที่เกิดซ้ำได้ เช่น 'หมายเลขเส้นทางธนาคารไม่ถูกต้อง' และปรับปรุงกฎการตรวจสอบหรือการฝึกอบรมผู้ใช้ให้ตรงจุด. เหตุผลที่สำคัญ ช่วยระบุต้นเหตุของการแก้ไขงานซ้ำ. แหล่งข้อมูล บันทึกข้อผิดพลาดหรือรายละเอียดสถานะธุรกรรม. ตัวอย่าง E-101INV_ACCNSF_ERRAUTH_FAIL
	รหัสสกุลเงิน CurrencyCode	รหัสสกุลเงิน ISO ของจำนวนเงินที่ชำระ.
คำอธิบาย ระบุสกุลเงินของการชำระเงิน เช่น USD หรือ EUR แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ดแนวโน้มปริมาณตามสกุลเงินและวิธีการชำระเงิน เพื่อให้องค์กรติดตามความเสี่ยงจากอัตราแลกเปลี่ยนเงินตราต่างประเทศได้. นอกจากนี้ยังใช้ปรับจำนวนเงินให้อยู่ในมาตรฐานเดียวกันสำหรับรายงานระดับโลก และช่วยป้องกันไม่ให้ระบบตรวจจับรายการซ้ำที่มีตัวเลขจำนวนเงินเท่ากันแต่เป็นคนละสกุลเงิน. เหตุผลที่สำคัญ จำเป็นต่อการวิเคราะห์การประมวลผลหลายสกุลเงิน. แหล่งข้อมูล ตารางส่วนหัวธุรกรรม คอลัมน์ Currency. ตัวอย่าง USDEURGBPCADJPY
	เลขที่บัญชีผู้ชำระเงิน PayerAccountNumber	เลขที่บัญชีที่ใช้หักเงิน.
คำอธิบาย ระบุบัญชีต้นทางของการชำระเงิน และเป็นองค์ประกอบสำคัญของมุมมองการตรวจจับการชำระเงินซ้ำ เมื่อนำไปพิจารณาร่วมกับผู้รับเงิน จำนวนเงิน และเวลา จะได้ชุดข้อมูลเฉพาะที่ใช้ตรวจจับการจ่ายซ้ำโดยไม่ตั้งใจ. นอกจากนี้ยังใช้วิเคราะห์ปริมาณการชำระเงินแยกตามบัญชีต้นทาง เพื่อระบุพอร์ตภายในที่มีการใช้งานมากที่สุด. เหตุผลที่สำคัญ จำเป็นต่อการตรวจจับรายการซ้ำและวิเคราะห์การฉ้อโกง. แหล่งข้อมูล รายละเอียดธุรกรรม คอลัมน์ Debit Account. ตัวอย่าง 123456789987654321ACC-001-992
	เลขที่บัญชีผู้รับเงิน PayeeAccountNumber	เลขที่บัญชีที่รับเงินโอน.
คำอธิบาย ระบุบัญชีปลายทาง เช่นเดียวกับบัญชีผู้ชำระเงิน ข้อมูลนี้สำคัญต่อมุมมองการตรวจจับการชำระเงินซ้ำ เพื่อให้การวิเคราะห์เจาะจงความสัมพันธ์กับผู้รับเงินแต่ละรายได้ถูกต้อง. เมื่อติดตามการปฏิบัติตามเวลาตัดรอบ การทราบผู้รับเงินช่วยจัดลำดับความสำคัญให้ผู้ขายเชิงกลยุทธ์หรือรายการชำระบัญชีสำคัญที่ต้องดำเนินการให้สำเร็จ. เหตุผลที่สำคัญ จำเป็นต่อการตรวจจับรายการซ้ำและวิเคราะห์ผู้รับเงิน. แหล่งข้อมูล รายละเอียดธุรกรรม คอลัมน์ Credit Account หรือ Beneficiary. ตัวอย่าง 555000111222333444BEN-882-11
	วันที่ครบกำหนดชำระเงิน PaymentDueDate	วันที่ต้องประมวลผลการชำระเงินให้เสร็จ.
คำอธิบาย วันที่เป้าหมายที่ต้องชำระเงินให้เสร็จ ใช้ในตัวติดตามการปฏิบัติตามเวลาตัดรอบประมวลผล เพื่อแจ้งเตือนธุรกรรมที่เสี่ยงล่าช้า. เมื่อนำเวลาประทับ 'ชำระเงินเสร็จแล้ว' มาเปรียบเทียบกับแอตทริบิวต์นี้ จะคำนวณตัวชี้วัดการชำระเงินตรงเวลาได้ และช่วยให้องค์กรรักษาความเชื่อมั่นของผู้รับเงิน. เหตุผลที่สำคัญ จุดอ้างอิงสำหรับวัดการปฏิบัติตาม SLA. แหล่งข้อมูล รายละเอียดคำสั่งชำระเงิน. ตัวอย่าง 2023-11-012023-11-15
	วิธีการชำระเงิน PaymentMethod	ช่องทางที่ใช้ดำเนินการชำระเงิน เช่น Wire หรือ ACH.
คำอธิบาย จัดประเภทธุรกรรมตามช่องทางการประมวลผล แอตทริบิวต์นี้เป็นพื้นฐานของการวิเคราะห์ระยะเวลารอบการอนุมัติ เพราะแต่ละวิธีมีขั้นตอนปฏิบัติงานมาตรฐานและข้อตกลงระดับบริการที่แตกต่างกันมาก. การวิเคราะห์รูปแบบกระบวนการตามวิธีชำระเงินช่วยระบุได้ว่าความล่าช้าเกิดเฉพาะในช่องทางใดช่องทางหนึ่ง เช่น การโอนเงินระหว่างประเทศ หรือเกิดขึ้นทั่วทั้งองค์กร. เหตุผลที่สำคัญ แบ่งกลุ่มกระบวนการตามโครงสร้างพื้นฐานที่ใช้. แหล่งข้อมูล คอลัมน์ประเภทธุรกรรมหรือรหัสเครื่องมือ. ตัวอย่าง WireACHเช็คRTPโอนเงินภายใน
	ธนาคารผู้รับเงิน BeneficiaryBank	ชื่อหรือรหัสของธนาคารผู้รับเงิน.
คำอธิบาย ระบุสถาบันการเงินที่รับเงิน ใช้วิเคราะห์ความล่าช้าในการชำระบัญชีได้ เพราะธนาคารผู้รับแต่ละแห่งอาจใช้เวลาประมวลผลต่างกันหรือมีปัญหาการเชื่อมต่อ. ช่วยเพิ่มอีกมิติให้แดชบอร์ดช่วงเวลาตั้งแต่ชำระบัญชีจนถึงกระทบยอด และแสดงให้เห็นว่าความล่าช้าเกิดจากภายนอก เช่น ธนาคารแห่งใดแห่งหนึ่ง หรือเกิดจากภายใน. เหตุผลที่สำคัญ วิเคราะห์การพึ่งพาหน่วยงานภายนอก. แหล่งข้อมูล รายละเอียดธุรกรรม คอลัมน์ Bank ID หรือ Name. ตัวอย่าง ChaseBank of AmericaWells FargoCitibank
	เป็นงานแก้ไขซ้ำหรือไม่ IsRework	ระบุว่ากิจกรรมนี้เป็นส่วนหนึ่งของวงจรการแก้ไขงานซ้ำหรือไม่.
คำอธิบาย แฟล็กบูลีนที่ระบุกิจกรรมหลังพบข้อผิดพลาดแต่ก่อนแก้ไขเสร็จ หรือกิจกรรมที่เกิดซ้ำ ใช้สนับสนุน KPI อัตราการแก้ไขงานซ้ำจากการตรวจสอบการชำระเงิน. นักวิเคราะห์กรองแผนผังกระบวนการให้แสดงเฉพาะ 'เส้นทางปกติ' หรือเลือกดูเฉพาะ 'เส้นทางแก้ไขงานซ้ำ' เพื่อทำความเข้าใจรูปแบบความผิดพลาดได้. เหตุผลที่สำคัญ แยกงานที่เพิ่มคุณค่าออกจากงานแก้ไข. แหล่งข้อมูล คำนวณจากวงจรของกระบวนการ. ตัวอย่าง truefalse
	พลาดเวลาตัดรอบหรือไม่ IsCutoffMissed	ระบุว่ามีการส่งรายการชำระเงินหลังเวลาตัดรอบธนาคารประจำวันหรือไม่.
คำอธิบาย ค่าบูลีนที่คำนวณจากการเปรียบเทียบเวลาของ 'ส่งคำสั่งชำระเงินแล้ว' กับเวลาตัดรอบประจำวันของสกุลเงินหรือวิธีชำระเงินนั้น ใช้สนับสนุน KPI อัตราการปฏิบัติตามเวลาตัดรอบ. การระบุรายการที่พลาดเวลาตัดรอบช่วยตรวจสอบต้นเหตุของความล่าช้าได้ ว่าเกิดจากการเริ่มรายการช้าหรือการประมวลผลภายในล่าช้า. เหตุผลที่สำคัญ สำคัญต่อการปฏิบัติตามข้อกำหนดด้านการปฏิบัติการและการบริหารสภาพคล่อง. แหล่งข้อมูล คำนวณโดยเปรียบเทียบ EventTimestamp กับตาราง Cutoff Reference. ตัวอย่าง truefalse
	ระดับการอนุมัติ ApprovalLevel	ระดับตามลำดับชั้นที่ต้องใช้หรือใช้ในการอนุมัติการชำระเงิน.
คำอธิบาย ระบุระดับอาวุโสหรืออำนาจที่เกี่ยวข้องกับกิจกรรม 'อนุมัติการชำระเงินแล้ว' ใช้ในแดชบอร์ดปริมาณงานตามอำนาจอนุมัติ เพื่อวิเคราะห์ว่าผู้อนุมัติระดับสูงกำลังกลายเป็นคอขวดหรือไม่. การทำความเข้าใจการกระจายรายการชำระเงินในแต่ละระดับ เช่น ระดับ 1 เทียบกับระดับ 3 ช่วยปรับนโยบายการมอบอำนาจให้เหมาะสมได้. เหตุผลที่สำคัญ แยกวิเคราะห์คอขวดในการอนุมัติตามลำดับชั้น. แหล่งข้อมูล ตารางบทบาทผู้ใช้หรือเวิร์กโฟลว์การอนุมัติ. ตัวอย่าง ระดับ 1ผู้จัดการผู้อำนวยการCFO
	หน่วยธุรกิจ BusinessUnit	แผนกหรือฝ่ายที่เริ่มรายการชำระเงิน.
คำอธิบาย จัดหมวดหมู่การชำระเงินตามหน่วยงานที่รับผิดชอบค่าใช้จ่าย ช่วยจัดสรรค่าใช้จ่ายและทำความเข้าใจว่าส่วนใดขององค์กรมีงานแก้ไขด้วยตนเองหรือข้อผิดพลาดมากที่สุด. ข้อมูลนี้สนับสนุนการตรวจสอบการปฏิบัติตามเส้นทางการชำระเงิน โดยช่วยให้มั่นใจว่าแต่ละหน่วยงานปฏิบัติตามข้อกำหนดด้านกฎระเบียบหรือการควบคุมภายในของตน. เหตุผลที่สำคัญ ให้บริบทด้านโครงสร้างองค์กรสำหรับวิเคราะห์ประสิทธิภาพ. แหล่งข้อมูล การจับคู่ศูนย์ต้นทุนหรือรหัสแผนก. ตัวอย่าง ธนาคารรายย่อยสินเชื่อธุรกิจบริหารความมั่งคั่งการปฏิบัติการ

จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในการประมวลผลการชำระเงิน

บันทึกขั้นตอนและจุดสำคัญเหล่านี้ไว้ในบันทึกเหตุการณ์ เพื่อให้ค้นพบและปรับปรุงเวิร์กโฟลว์การชำระเงินได้อย่างแม่นยำ.

5 แนะนำ 8 ไม่บังคับ

	กิจกรรม	คำอธิบาย
	กระทบยอดการชำระเงินแล้ว	การจับคู่ธุรกรรมภายในกับรายการเดินบัญชีธนาคารหรือไฟล์การชำระบัญชี เพื่อปิดขั้นตอนทางบัญชีให้ครบถ้วน.
เหตุผลที่สำคัญ จำเป็นต่อ 'ช่วงเวลาตั้งแต่ชำระบัญชีจนถึงกระทบยอด' เพื่อให้ปิดบัญชีการเงินได้อย่างถูกต้อง. แหล่งข้อมูล บันทึกจากโมดูลกระทบยอดเมื่อสถานะเปลี่ยนเป็น 'จับคู่แล้ว' หรือ 'กระทบยอดแล้ว'. บันทึก บันทึกเมื่อจับคู่รายการเพื่อกระทบยอดแล้ว ประเภทเหตุการณ์ explicit
	ชำระเงินเสร็จสมบูรณ์	การโอนเงินเสร็จสมบูรณ์และบันทึกลงบัญชีแยกประเภททั่วไป นับเป็นการสิ้นสุดธุรกรรมทางการเงินในมุมมองของธนาคาร.
เหตุผลที่สำคัญ เป็นจุดสิ้นสุดหลักสำหรับ 'อัตราการประมวลผลแบบตรงถึงปลายทาง' และแสดงว่าเงินถูกโอนแล้วจริง. แหล่งข้อมูล สถานะธุรกรรมเป็น 'ลงบัญชีแล้ว' หรือมีเวลาประทับ 'วันที่ลงบัญชี' ในบัญชีแยกประเภท. บันทึก บันทึกเมื่อมีการลงบัญชีในบัญชีแยกประเภททั่วไป ประเภทเหตุการณ์ explicit
	ส่งคำสั่งชำระเงินแล้ว	การส่งไฟล์ชำระเงิน เช่น ชุดรายการ ACH หรือข้อความ Wire ไปยังเครือข่ายภายนอกหรือสำนักหักบัญชี ซึ่งเป็นจุดส่งต่องานสำคัญ.
เหตุผลที่สำคัญ สำคัญต่อ 'ตัวติดตามการปฏิบัติตามเวลาตัดรอบประมวลผล' เพื่อให้องค์กรส่งรายการทันเวลาตัดรอบธนาคารในแต่ละวัน. แหล่งข้อมูล บันทึกการประมวลผลแบบชุดหรือเวลาที่สร้างไฟล์ มักบันทึกเป็น 'สร้างชุดรายการแล้ว' หรือ 'ส่งไฟล์แล้ว'. บันทึก บันทึกเมื่อสร้างไฟล์ชุดรายการแล้ว ประเภทเหตุการณ์ explicit
	สร้างคำขอชำระเงิน	การบันทึกคำสั่งชำระเงินครั้งแรกในระบบ Fiserv ระบบจะบันทึกเหตุการณ์นี้เมื่อผู้ใช้หรือระบบภายนอกเริ่มธุรกรรมผ่าน API หรืออินเทอร์เฟซ.
เหตุผลที่สำคัญ เป็นจุดเริ่มต้นของลำดับเวลาของกระบวนการ จำเป็นต่อการคำนวณเวลารวมของวงจรและระบุคอขวดในขั้นตอนรับรายการ. แหล่งข้อมูล เวลาที่สร้างรายการในตารางประวัติธุรกรรม ให้ค้นหารายการแรกสุดที่มี Payment Transaction ID นั้น. บันทึก บันทึกเมื่อเพิ่มรายการธุรกรรมลงในระบบ ประเภทเหตุการณ์ explicit
	อนุมัติการชำระเงินแล้ว	การตัดสินใจด้วยตนเองหรือโดยระบบให้ดำเนินการชำระเงินต่อได้ตามวงเงินอนุมัติ ระบบบันทึกเหตุการณ์นี้เมื่อผู้ใช้ที่มีอำนาจหรือกฎของระบบเปลี่ยนสถานะการอนุมัติ.
เหตุผลที่สำคัญ เป็นข้อมูลสำคัญสำหรับ 'Authorization Cycle Time Analysis' ความล่าช้าในขั้นตอนนี้บ่งชี้ถึงคอขวดในลำดับการอนุมัติของผู้ใช้. แหล่งข้อมูล บันทึกการตรวจสอบที่แสดงการดำเนินการของผู้ใช้ ซึ่งเปลี่ยนสถานะจาก 'Pending Approval' เป็น 'Approved'. บันทึก บันทึกเมื่อมีการอนุมัติ ประเภทเหตุการณ์ explicit
	กำหนดเวลาชำระเงิน	เกิดขึ้นเมื่ออนุมัติการชำระเงินแล้ว แต่พักรายการไว้จนถึงวันที่มีผลในอนาคต ระบบจะจัดคิวรายการไว้จนกว่าจะถึงช่วงเวลาประมวลผล.
เหตุผลที่สำคัญ อธิบายช่วงเวลาที่กระบวนการหยุดรอ โดยแยกความล่าช้าจากคอขวดออกจากการรอวันที่ครบกำหนดตามแผน. แหล่งข้อมูล เปรียบเทียบ 'วันที่บันทึกรายการ' กับ 'วันที่มีผล' หากวันที่มีผลอยู่ในอนาคต สถานะนี้จะทำงานอยู่. บันทึก คำนวณจากการเปรียบเทียบฟิลด์ X กับ Y ประเภทเหตุการณ์ calculated
	แก้ไขข้อผิดพลาดการชำระเงินแล้ว	หมายถึงการแก้ไขธุรกรรมที่เคยเกิดข้อผิดพลาด อนุมานได้เมื่อสถานะธุรกรรมเปลี่ยนจากข้อผิดพลาดกลับเป็นกำลังประมวลผลหรือถูกต้อง.
เหตุผลที่สำคัญ จำเป็นต่อการคำนวณ 'Mean Time to Resolve Payment Errors' และช่วยวัดประสิทธิภาพของทีมปฏิบัติการ. แหล่งข้อมูล อนุมานเมื่อสถานะธุรกรรมเปลี่ยนจากรหัสข้อผิดพลาดเป็นรหัสประมวลผลปกติ. บันทึก เปรียบเทียบฟิลด์สถานะก่อนและหลัง ประเภทเหตุการณ์ inferred
	ตรวจสอบรายละเอียดการชำระเงินแล้ว	ระบบตรวจสอบหมายเลขบัญชี หมายเลขเส้นทางธนาคาร และรูปแบบข้อมูล โดยทั่วไปอนุมานได้ว่าผ่านการตรวจสอบเมื่อธุรกรรมเปลี่ยนจากสถานะรับรายการเป็นรอดำเนินการหรืออนุมัติ โดยไม่มีข้อผิดพลาด.
เหตุผลที่สำคัญ แสดงว่าผ่านจุดตรวจสอบอัตโนมัติขั้นแรกแล้ว หากไม่ผ่าน มักเป็นปัญหาคุณภาพข้อมูล ไม่ใช่ปัญหาสภาพคล่องหรือการอนุมัติ. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะจาก 'Received' เป็น 'Pending' หรือ 'Ready' ภายในเวลาไม่นาน. บันทึก เปรียบเทียบฟิลด์สถานะก่อนและหลัง ประเภทเหตุการณ์ inferred
	พบข้อผิดพลาดในการชำระเงิน	บันทึกเวลาที่ธุรกรรมถูกระบุว่าล้มเหลวหรือมีรหัสกรณียกเว้น เหตุการณ์นี้เกิดขึ้นเมื่อไม่ผ่านกฎการตรวจสอบหรือได้รับผลตอบกลับเชิงลบจากการตรวจสอบภายนอก.
เหตุผลที่สำคัญ จำเป็นต่อแดชบอร์ด 'Validation Error and Rework Tracker' หากพบจำนวนมาก แสดงว่าอาจมีปัญหาคุณภาพข้อมูลจากขั้นตอนก่อนหน้า. แหล่งข้อมูล ฟิลด์สถานะธุรกรรมเปลี่ยนเป็นรหัสกรณียกเว้น เช่น 'Invalid', 'Hold' หรือ 'Error'. บันทึก บันทึกเมื่อสถานะเปลี่ยนเป็น Error ประเภทเหตุการณ์ explicit
	ยกเลิกการชำระเงินแล้ว	การยุติขั้นตอนการชำระเงินก่อนชำระบัญชี โดยผู้ใช้หรือกฎของระบบเป็นผู้เริ่มดำเนินการ และหยุดการประมวลผลทั้งหมดหลังจากนั้น.
เหตุผลที่สำคัญ ช่วยระบุงานที่สูญเปล่าหรือถูกละทิ้ง หากยกเลิกบ่อยหลังอนุมัติแล้ว อาจบ่งชี้ว่ากระบวนการไม่มีประสิทธิภาพ. แหล่งข้อมูล เปลี่ยนสถานะเป็น 'ยกเลิกแล้ว' 'เป็นโมฆะ' หรือ 'หยุดแล้ว'. บันทึก บันทึกเมื่อสถานะเปลี่ยนเป็นยกเลิกแล้ว ประเภทเหตุการณ์ explicit
	ยืนยันการชำระเงินแล้ว	ได้รับการตอบรับเชิงบวก (ACK) จากเครือข่ายภายนอกหรือเกตเวย์ เพื่อยืนยันว่าหน่วยงานถัดไปได้รับคำสั่งอย่างถูกต้อง.
เหตุผลที่สำคัญ ใช้ตรวจสอบว่าการ 'ส่งคำสั่ง' สำเร็จหรือไม่ หากมีช่วงเวลาขาดหาย อาจเกิดจากปัญหาการเชื่อมต่อเครือข่ายหรือรูปแบบข้อมูลภายนอก. แหล่งข้อมูล บันทึกการประมวลผลไฟล์ขาเข้าหรือรหัสตอบกลับจาก API ที่ยืนยันการรับข้อมูล. บันทึก บันทึกเมื่อได้รับ ACK ประเภทเหตุการณ์ explicit
	ส่งการแจ้งเตือนการชำระเงินแล้ว	ระบบส่งข้อความทางอีเมลหรือ SMS ไปยังผู้ชำระเงินหรือผู้รับเงินเพื่อยืนยันธุรกรรม ช่วยให้ลูกค้าติดตามสถานะได้ชัดเจนขึ้น.
เหตุผลที่สำคัญ ใช้ติดตาม 'ความเร็วและการตอบสนองในการแจ้งเตือน' หากเว้นช่วงนานหลังชำระเงินเสร็จ อาจทำให้ลูกค้าขาดความเชื่อมั่น. แหล่งข้อมูล บันทึกการสื่อสารหรือตารางประวัติการติดต่อกับลูกค้าที่เชื่อมโยงกับรหัสธุรกรรม. บันทึก บันทึกเมื่อส่งอีเมลหรือ SMS ประเภทเหตุการณ์ explicit
	อนุมัติให้ชำระเงินแล้ว	การยืนยันขั้นสุดท้ายภายในองค์กรว่าเงินพร้อมใช้และธุรกรรมผ่านการตรวจสอบเพื่อดำเนินการ ขั้นตอนนี้อาจเกิดขึ้นพร้อมกับการอนุมัติหรือเป็นการตรวจสอบแยกต่างหาก.
เหตุผลที่สำคัญ แยกการอนุมัติของผู้จัดการออกจากการอนุมัติสิทธิ์ในระดับระบบ สำคัญต่อแดชบอร์ด 'ปริมาณงานตามอำนาจอนุมัติ'. แหล่งข้อมูล การเปลี่ยนสถานะเป็น 'อนุมัติแล้ว' หรือ 'พร้อมลงบัญชี'. บันทึก เปรียบเทียบฟิลด์สถานะก่อนและหลัง ประเภทเหตุการณ์ inferred

แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

วิธีดึงข้อมูลจาก Fiserv

ขั้นตอน

1. ตั้งค่าสิ่งที่ต้องมีก่อน

ตรวจสอบว่าคุณเข้าใช้งานพอร์ทัลนักพัฒนาของ Fiserv Commerce Hub ได้ คุณต้องสร้าง API Key และ API Secret (บางครั้งเรียกว่า Client ID และ Client Secret) โดยกำหนดสิทธิ์ให้เข้าถึง Transaction Inquiry หรือ Search API หากเปิดใช้การจำกัด IP ให้ตรวจสอบว่าได้เพิ่มที่อยู่ IP ของคุณไว้ในรายการอนุญาตของสภาพแวดล้อม Fiserv แล้ว

2. ตั้งค่าสภาพแวดล้อม

ติดตั้ง Python 3.8 ขึ้นไปบนเซิร์ฟเวอร์ที่ใช้ดึงข้อมูลหรือเครื่องของคุณ และติดตั้งไลบรารี requests กับ pandas ด้วยคำสั่ง pip: pip install requests pandas จากนั้นสร้างโฟลเดอร์ทำงานสำหรับสคริปต์และไฟล์ผลลัพธ์

3. ตั้งค่าสคริปต์

ดาวน์โหลดสคริปต์ Python ที่ให้มาไว้ในโฟลเดอร์ทำงาน เปิดสคริปต์แล้วแก้ไขส่วนตั้งค่าด้านบน โดยระบุ API_KEY, API_SECRET และ BASE_URL ของคุณ (ใช้ URL ของ sandbox เพื่อทดสอบ และ URL ของระบบจริงเมื่อเรียกใช้งานจริง) ปรับ START_DATE และ END_DATE ให้ตรงกับช่วงเวลาที่ต้องการใช้ทำ process mining

4. ตั้งค่าการยืนยันตัวตน

สคริปต์มีคลาสช่วยจัดการข้อกำหนดการยืนยันตัวตนของ Fiserv ซึ่งโดยทั่วไปจะสร้างลายเซ็น HMAC จาก API Secret, การประทับเวลา และข้อมูลคำขอ อย่าแก้ไขส่วนสร้างลายเซ็น เว้นแต่การติดตั้ง Fiserv ของคุณจะใช้มาตรฐานอื่น เช่น OAuth2 bearer token

5. ทำความเข้าใจการแยกวิเคราะห์ข้อมูล

สคริปต์เรียก API เพื่อดึงธุรกรรม โดยทั่วไป API จะส่งภาพข้อมูลธุรกรรม ณ เวลาหนึ่ง ซึ่งมีการประทับเวลาหลายรายการ เช่น เวลาส่งคำขอ เวลายืนยันรายการ และเวลาชำระเงิน สคริปต์จะแยกวิเคราะห์ออบเจ็กต์ JSON นี้ แล้วแปลงข้อมูลจากหลายฟิลด์ให้เป็นหลายแถว (เหตุการณ์) ในบันทึกเหตุการณ์ ตัวอย่างเช่น ระเบียน JSON หนึ่งรายการที่มีเวลาส่งคำขอและเวลาชำระเงิน จะสร้างแถวใน CSV อย่างน้อย 2 แถว

6. จัดการการแบ่งหน้า

สคริปต์จะวนเรียกข้อมูลเพื่อจัดการการแบ่งหน้า โดย API ของ Fiserv จำกัดจำนวนระเบียนต่อการตอบกลับ ซึ่งมักอยู่ที่ 50 หรือ 100 รายการ สคริปต์จะเรียกหน้าถัดไปโดยอัตโนมัติจนกว่าจะดึงธุรกรรมทั้งหมดในช่วงวันที่กำหนดได้ ตรวจสอบให้แน่ใจว่าการเชื่อมต่ออินเทอร์เน็ตเสถียร เพราะการดึงชุดข้อมูลขนาดใหญ่อาจใช้เวลา

7. เรียกใช้สคริปต์

เรียกใช้สคริปต์ผ่านบรรทัดคำสั่ง: python fiserv_extraction.py คอนโซลจะแสดงความคืบหน้า จำนวนหน้าที่ประมวลผล และจำนวนธุรกรรมที่ดึงได้ ให้สังเกตข้อผิดพลาด HTTP 401 (ไม่ได้รับอนุญาต) หรือ 429 (เกินขีดจำกัดการเรียกใช้)

8. ตรวจสอบผลลัพธ์

เมื่อสคริปต์ทำงานเสร็จ ให้ตรวจสอบว่ามีไฟล์ fiserv_event_log.csv ในโฟลเดอร์ เปิดไฟล์และตรวจสอบว่าคอลัมน์ ActivityName มีชื่อกิจกรรมที่กำหนดไว้ 13 รายการ และฟิลด์ EventTimestamp อยู่ในรูปแบบที่ถูกต้อง

9. ประมวลผลข้อมูลเพิ่มเติม (ไม่บังคับ)

หากต้องปรับเขตเวลา เช่น แปลง UTC เป็นเวลาท้องถิ่น คุณสามารถแก้ไขส่วนแปลงข้อมูลของ pandas ในสคริปต์ หรือจัดการขั้นตอนนี้ใน ProcessMind หลังอัปโหลดได้

10. อัปโหลดไปยัง ProcessMind

นำเข้าไฟล์ CSV ไปยัง ProcessMind แล้วจับคู่ PaymentTransactionId กับรหัสเคส, ActivityName กับกิจกรรม และ EventTimestamp กับการประทับเวลา ตรวจสอบว่าคอลัมน์ตัวเลข เช่น PaymentAmount ถูกกำหนดเป็นแอตทริบิวต์

การกำหนดค่า

ข้อมูลรับรอง API: ต้องใช้ API Key และ Secret/Shared Secret ตรวจสอบว่ามีสิทธิ์อ่านข้อมูลจากปลายทาง Transaction Reporting
URL หลัก: ตั้งค่าเป็น https://api.commerce.fiserv.com สำหรับ production หรือใช้ URL cert/sandbox เฉพาะที่ได้รับระหว่างการเริ่มใช้งาน
ช่วงวันที่: เนื่องจาก API จำกัดขนาดข้อมูลที่ส่งกลับ แนะนำให้ดึงข้อมูลย้อนหลัง 30 ถึง 90 วัน หากต้องโหลดข้อมูลย้อนหลัง ให้เรียกใช้สคริปต์แยกเป็นรายเดือน
จำนวนรายการต่อหน้า: ตั้งไว้ที่ 100 รายการต่อการเรียกหนึ่งครั้ง เพื่อให้สมดุลระหว่างการใช้หน่วยความจำกับปริมาณการรับส่งข้อมูล
เขตเวลา: API ส่งเวลาเป็น UTC สคริปต์คงรูปแบบนี้ไว้เพื่อให้ข้อมูลสอดคล้องกันในทุกภูมิภาค
การลองใหม่: มีระบบลองใหม่พื้นฐานเมื่อเกิดการหมดเวลาของเครือข่ายเป็นครั้งคราว (HTTP 500/502/503).

ตัวอย่างคำค้น python

import requests
import json
import time
import hmac
import hashlib
import base64
import uuid
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
API_KEY = class="hl-string">"YOUR_API_KEY"
API_SECRET = class="hl-string">"YOUR_API_SECRET"
BASE_URL = class="hl-string">"https://cert.api.fiservapps.com"  class=class="hl-string">"hl-comment"># Update to Production URL as needed
ENDPOINT = class="hl-string">"/ch/payments/v1/transaction-inquiry"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
PAGE_SIZE = 50
OUTPUT_FILE = class="hl-string">"fiserv_event_log.csv"

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># AUTHENTICATION HELPER
class=class="hl-string">"hl-comment"># ==========================================
def generate_headers(payload):
    class=class="hl-string">"hl-comment"># Fiserv Commerce Hub typically requires HMAC auth
    class=class="hl-string">"hl-comment"># This is a standard implementation pattern
    client_request_id = str(uuid.uuid4())
    timestamp = str(int(time.time() * 1000))
    
    class=class="hl-string">"hl-comment"># specific signature construction depends on Fiserv documentation version
    class=class="hl-string">"hl-comment"># standard pattern: apiKey + reqId + timestamp + payload
    raw_signature = API_KEY + client_request_id + timestamp + payload
    
    hmac_obj = hmac.new(
        API_SECRET.encode(class="hl-string">'utf-8'),
        raw_signature.encode(class="hl-string">'utf-8'),
        hashlib.sha256
    )
    message_signature = base64.b64encode(hmac_obj.digest()).decode(class="hl-string">'utf-8')
    
    return {
        class="hl-string">"Content-Type": class="hl-string">"application/json",
        class="hl-string">"Client-Request-Id": client_request_id,
        class="hl-string">"Api-Key": API_KEY,
        class="hl-string">"Timestamp": timestamp,
        class="hl-string">"Message-Signature": message_signature
    }

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># PARSING LOGIC (UNPIVOTING EVENTS)
class=class="hl-string">"hl-comment"># ==========================================
def extract_events_from_transaction(tx):
    events = []
    
    class=class="hl-string">"hl-comment"># Base Attributes
    case_id = tx.get(class="hl-string">"transactionId", class="hl-string">"")
    amount = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"total", 0.0)
    currency = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"currency", class="hl-string">"USD")
    method = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"type", class="hl-string">"Unknown")
    payer_acc = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"maskedAccountNumber", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Identifying common attributes
    base_data = {
        class="hl-string">"PaymentTransactionId": case_id,
        class="hl-string">"SourceSystem": class="hl-string">"Fiserv Commerce Hub",
        class="hl-string">"LastDataUpdate": datetime.utcnow().isoformat(),
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentMethod": method,
        class="hl-string">"PayerAccountNumber": payer_acc,
        class="hl-string">"PayeeAccountNumber": class="hl-string">"MerchantAccount", class=class="hl-string">"hl-comment"># Placeholder
        class="hl-string">"ErrorCode": tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseCode", class="hl-string">""),
        class="hl-string">"IsStraightThroughProcessing": class="hl-string">"True" class=class="hl-string">"hl-comment"># Default assumption unless error found
    }

    class=class="hl-string">"hl-comment"># Helper to append event
    def add_event(activity, timestamp_str, specific_attrs={}):
        if timestamp_str:
            row = base_data.copy()
            row.update({
                class="hl-string">"ActivityName": activity,
                class="hl-string">"EventTimestamp": timestamp_str
            })
            row.update(specific_attrs)
            events.append(row)

    class=class="hl-string">"hl-comment"># 1. Payment Request Created (Submission Time)
    submission_time = tx.get(class="hl-string">"submissionTime")
    add_event(class="hl-string">"Payment Request Created", submission_time)

    class=class="hl-string">"hl-comment"># 2. Payment Details Validated (Inferred: slightly after submission if no immediate 400 error)
    class=class="hl-string">"hl-comment"># We infer this exists if the transaction exists and has a submission time
    if submission_time:
        class=class="hl-string">"hl-comment"># Infer validation happened 1 second after submission
        val_time = (datetime.fromisoformat(submission_time.replace(class="hl-string">'Z', class="hl-string">'+00:00')) + timedelta(seconds=1)).isoformat()
        add_event(class="hl-string">"Payment Details Validated", val_time)

    class=class="hl-string">"hl-comment"># 3. Payment Error Identified / 4. Resolved
    status = tx.get(class="hl-string">"transactionStatus", class="hl-string">"")
    if status == class="hl-string">"FAILED":
        fail_time = tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseTimestamp", submission_time)
        add_event(class="hl-string">"Payment Error Identified", fail_time, {class="hl-string">"IsStraightThroughProcessing": class="hl-string">"False"})
    elif status == class="hl-string">"APPROVED" and tx.get(class="hl-string">"retryCount", 0) > 0:
        class=class="hl-string">"hl-comment"># Logic: If approved but had retries, an error was resolved
        add_event(class="hl-string">"Payment Error Resolved", submission_time) class=class="hl-string">"hl-comment"># Simplified assumption

    class=class="hl-string">"hl-comment"># 5. Payment Approved
    approval_time = tx.get(class="hl-string">"approvalTime")
    if approval_time:
        add_event(class="hl-string">"Payment Approved", approval_time)

    class=class="hl-string">"hl-comment"># 6. Payment Authorized
    auth_time = tx.get(class="hl-string">"authorizationTime")
    class=class="hl-string">"hl-comment"># If separate auth time not provided, use approval time
    if not auth_time and approval_time:
        auth_time = approval_time
    add_event(class="hl-string">"Payment Authorized", auth_time)

    class=class="hl-string">"hl-comment"># 7. Payment Scheduled (if future dated)
    req_exec_date = tx.get(class="hl-string">"requestedExecutionDate")
    if req_exec_date and req_exec_date > submission_time:
         add_event(class="hl-string">"Payment Scheduled", submission_time)

    class=class="hl-string">"hl-comment"># 8. Payment Instruction Sent
    gateway_time = tx.get(class="hl-string">"gatewayTransmitTime")
    add_event(class="hl-string">"Payment Instruction Sent", gateway_time)

    class=class="hl-string">"hl-comment"># 9. Payment Confirmed (Gateway ACK)
    gateway_ack = tx.get(class="hl-string">"gatewayAckTime")
    add_event(class="hl-string">"Payment Confirmed", gateway_ack)

    class=class="hl-string">"hl-comment"># 10. Payment Settled
    settle_time = tx.get(class="hl-string">"settlementTime") or tx.get(class="hl-string">"fundingDate")
    add_event(class="hl-string">"Payment Settled", settle_time)

    class=class="hl-string">"hl-comment"># 11. Payment Notification Sent (Inferred or specific field)
    notify_time = tx.get(class="hl-string">"customerNotificationEmailTime")
    add_event(class="hl-string">"Payment Notification Sent", notify_time)

    class=class="hl-string">"hl-comment"># 12. Payment Reconciled
    recon_time = tx.get(class="hl-string">"reconciliationDate")
    add_event(class="hl-string">"Payment Reconciled", recon_time)

    class=class="hl-string">"hl-comment"># 13. Payment Cancelled
    if status == class="hl-string">"VOIDED" or status == class="hl-string">"CANCELLED":
        void_time = tx.get(class="hl-string">"voidTime") or tx.get(class="hl-string">"lastUpdateTime")
        add_event(class="hl-string">"Payment Cancelled", void_time)

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXTRACTION LOOP
class=class="hl-string">"hl-comment"># ==========================================
def main():
    all_events = []
    page_number = 1
    has_more = True
    
    print(fclass="hl-string">"Starting extraction from {START_DATE} to {END_DATE}...")

    while has_more:
        class=class="hl-string">"hl-comment"># Construct Search Payload
        payload_dict = {
            class="hl-string">"startDate": START_DATE,
            class="hl-string">"endDate": END_DATE,
            class="hl-string">"page": page_number,
            class="hl-string">"limit": PAGE_SIZE
        }
        payload_json = json.dumps(payload_dict)
        
        headers = generate_headers(payload_json)
        full_url = BASE_URL + ENDPOINT
        
        try:
            response = requests.post(full_url, headers=headers, data=payload_json)
            
            if response.status_code == 200:
                data = response.json()
                transactions = data.get(class="hl-string">"reports", []) class=class="hl-string">"hl-comment"># Key depends on specific endpoint schema
                
                if not transactions:
                    print(fclass="hl-string">"No transactions found on page {page_number}. Finishing.")
                    has_more = False
                    break
                
                print(fclass="hl-string">"Processing page {page_number}, found {len(transactions)} transactions.")
                
                for tx in transactions:
                    events = extract_events_from_transaction(tx)
                    all_events.extend(events)
                
                class=class="hl-string">"hl-comment"># Pagination Check
                total_pages = data.get(class="hl-string">"totalPages", page_number)
                if page_number >= total_pages:
                    has_more = False
                else:
                    page_number += 1
            else:
                print(fclass="hl-string">"Error fetching data: {response.status_code} - {response.text}")
                has_more = False
                
        except Exception as e:
            print(fclass="hl-string">"Exception occurred: {str(e)}")
            has_more = False

    class=class="hl-string">"hl-comment"># ==========================================
    class=class="hl-string">"hl-comment"># EXPORT TO CSV
    class=class="hl-string">"hl-comment"># ==========================================
    if all_events:
        df = pd.DataFrame(all_events)
        class=class="hl-string">"hl-comment"># Column ordering
        cols = [
            class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", 
            class="hl-string">"SourceSystem", class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentMethod",
            class="hl-string">"PayerAccountNumber", class="hl-string">"ErrorCode", class="hl-string">"IsStraightThroughProcessing"
        ]
        class=class="hl-string">"hl-comment"># Ensure columns exist even if empty
        for c in cols:
            if c not in df.columns:
                df[c] = None
                
        df = df[cols]
        df.to_csv(OUTPUT_FILE, index=False)
        print(fclass="hl-string">"Extraction complete. {len(df)} rows written to {OUTPUT_FILE}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    main()

พร้อมเริ่มต้นหรือยัง?

เริ่มปรับปรุงเวิร์กโฟลว์ทางการเงินโดยใช้เทมเพลตนี้กับระบบ Fiserv ของคุณ แนวทางทีละขั้นตอนช่วยให้คุณเตรียมข้อมูลที่เหมาะสมเพื่อปรับปรุงกระแสเงินสดและการปฏิบัติตามข้อกำหนดในการปฏิบัติการ.

กลับไปยังคู่มือการปรับปรุง

ดาวน์โหลดเทมเพลต

เพิ่มประสิทธิภาพการประมวลผลการชำระเงินและทำ STP ให้ได้ 98% วันนี้

ลดความล่าช้าในการกระทบยอดและจัดการเวิร์กโฟลว์ Fiserv ของคุณได้ดียิ่งขึ้น.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จในไม่กี่นาที.

เทมเพลตข้อมูลการประมวลผลการชำระเงินของคุณ

เทมเพลตข้อมูลการประมวลผลการชำระเงินของคุณ

แอตทริบิวต์การประมวลผลการชำระเงิน

กิจกรรมในการประมวลผลการชำระเงิน

คู่มือการดึงข้อมูล

สคริปต์ Python สำหรับ Fiserv Commerce Hub API

ขั้นตอน

1. ตั้งค่าสิ่งที่ต้องมีก่อน

2. ตั้งค่าสภาพแวดล้อม

3. ตั้งค่าสคริปต์

4. ตั้งค่าการยืนยันตัวตน

5. ทำความเข้าใจการแยกวิเคราะห์ข้อมูล

6. จัดการการแบ่งหน้า

7. เรียกใช้สคริปต์

8. ตรวจสอบผลลัพธ์

9. ประมวลผลข้อมูลเพิ่มเติม (ไม่บังคับ)

10. อัปโหลดไปยัง ProcessMind

การกำหนดค่า

ตัวอย่างคำค้น python

พร้อมเริ่มต้นหรือยัง?

เพิ่มประสิทธิภาพการประมวลผลการชำระเงินและทำ STP ให้ได้ 98% วันนี้