ไฟล์การชำระเงินจาก ERP ถึงธนาคารและการกระทบยอด
จาก ERP ถึงธนาคาร: ไฟล์การชำระเงินออกไป ใบแจ้งยอดกลับมา และกระทบยอดแล้ว
การชำระเงินส่งเป็น ISO 20022 pain.001 ผ่าน host-to-host SFTP หรือ API ของธนาคาร พร้อมใบแจ้งยอด camt.053 และ MT940 ที่จับคู่กลับเข้าบัญชีแยกประเภท
พิมพ์เขียว
เลื่อนแนวนอนเพื่อดูภาพทั้งภาพ
ERP ถึงธนาคาร: เงินออก รายการเดินบัญชีเข้า
การชำระเงินที่อนุมัติแล้วออกจาก ERP เป็นไฟล์ ISO 20022 ที่ลงนามผ่านช่องทาง host-to-host รายงานสถานะและรายการเดินบัญชีกลับมาทางเดียวกันและจับคู่กับรายการค้าง รายการถูกปฏิเสธและรายการที่ไม่ตรงจะส่งถึงทีมของคุณพร้อมเหตุผล
- เส้นทางหลัก
- แบบอะซิงโครนัส
- เส้นทางข้อยกเว้น
ขั้นตอนการทำงาน 10 ขั้นตอน
ขั้นตอนการทำงานทีละขั้น
- จาก ERP ไปยัง ชั้นการเชื่อมต่อ: รอบการจ่ายเงินที่อนุมัติแล้ว ผ่าน REST/JSON · IDoc (เส้นทางหลัก)
- จาก ชั้นการเชื่อมต่อ ไปยัง ช่องทางธนาคารที่ปลอดภัย: ไฟล์การชำระเงินที่ลงนามและเข้ารหัสแล้ว ผ่าน ISO 20022 pain.001 · OpenPGP (เส้นทางหลัก)
- จาก ช่องทางธนาคารที่ปลอดภัย ไปยัง ธนาคาร: ส่งถึงธนาคารแล้ว ผ่าน SFTP H2H (เส้นทางหลัก)
- จาก ธนาคาร ไปยัง ช่องทางธนาคารที่ปลอดภัย: รายงานสถานะและรายการเดินบัญชี ผ่าน pain.002 · camt.053 · MT940 (แบบอะซิงโครนัส)
- จาก ช่องทางธนาคารที่ปลอดภัย ไปยัง ชั้นการเชื่อมต่อ: เก็บรวบรวมและตรวจสอบแล้ว ผ่าน SFTP H2H (แบบอะซิงโครนัส)
- จาก ชั้นการเชื่อมต่อ ไปยัง กลไกกระทบยอด: รายการในรายการเดินบัญชี ผ่าน camt.053 (แบบอะซิงโครนัส)
- จาก กลไกกระทบยอด ไปยัง ERP: รายการที่จับคู่แล้วบันทึกเข้าบัญชี ผ่าน REST/JSON (เส้นทางหลัก)
- จาก ชั้นการเชื่อมต่อ ไปยัง ทีมบริหารเงินและการเงิน: การชำระเงินที่ถูกปฏิเสธ พร้อมรหัสเหตุผล ผ่าน pain.002 RJCT (เส้นทางข้อยกเว้น)
- จาก กลไกกระทบยอด ไปยัง ทีมบริหารเงินและการเงิน: รายการที่ไม่ตรง: รายการกระทบยอดที่ไม่ตรง (เส้นทางข้อยกเว้น)
- จาก ทีมบริหารเงินและการเงิน ไปยัง ERP: แก้ไขและส่งใหม่แล้ว (เส้นทางข้อยกเว้น)
ภาพรวม
นี่คือกระแสข้อมูลระหว่าง ERP กับธนาคาร: การชำระเงินที่อนุมัติแล้วออกไป และรายงานสถานะกับใบแจ้งยอดกลับมา เป็นการเชื่อมต่อที่ทีมการเงินส่วนใหญ่ยังทำด้วยมือผ่านพอร์ทัลธนาคารและสเปรดชีต และเป็นจุดที่ข้อผิดพลาดมีต้นทุนเป็นเงิน
การออกแบบอ้างอิงวางชั้นการเชื่อมต่อไว้ระหว่าง ERP กับธนาคารแต่ละแห่ง ชั้นนี้แปลงการชำระเงินเป็น ISO 20022 pain.001 ในรูปแบบเฉพาะของธนาคาร ลงนามและเข้ารหัส และส่งผ่าน host-to-host SFTP, EBICS หรือ API ของธนาคาร รายงานสถานะและใบแจ้งยอดกลับมาทางเดิมและจับคู่กับรายการที่ค้างอยู่ใน ERP
เส้นทางความล้มเหลวถูกออกแบบอย่างรอบคอบเท่ากับเส้นทางปกติ การชำระเงินที่ถูกปฏิเสธกลับมาพร้อมรหัสเหตุผลของธนาคาร รายการในใบแจ้งยอดที่ไม่ตรงจะกลายเป็นรายการกระทบยอดค้างให้ผู้รับผิดชอบที่ระบุชื่อเคลียร์ ไม่มีอะไรถูกทิ้งและไม่มีอะไรถูกบันทึกซ้ำ
กระบวนการ
อนุมัติรอบการจ่ายเงิน
ERP ของคุณสร้างรอบการจ่ายเงินและผู้อนุมัติปล่อยรายการตามที่ทำอยู่ทุกวัน ชั้นการเชื่อมต่อหยิบเฉพาะรอบที่อนุมัติแล้ว
แปลง ลงนาม และเข้ารหัส
ชั้นนี้แปลงการชำระเงินแต่ละรายการเป็น pain.001 ในรูปแบบของธนาคาร ตรวจสอบ และลงนามและเข้ารหัสไฟล์ตามที่ธนาคารกำหนด
ส่งถึงธนาคาร
ไฟล์เดินทางผ่านช่องทางที่ตกลง ได้แก่ host-to-host SFTP, EBICS หรือ API ของธนาคาร ก่อนเวลาตัดรอบของธนาคาร
รับสถานะและใบแจ้งยอด
ธนาคารส่งรายงานสถานะ pain.002 สำหรับแต่ละไฟล์และการชำระเงิน และใบแจ้งยอด camt.053 หรือ MT940 เมื่อสิ้นวัน
เก็บและตรวจสอบ
ชั้นนี้เก็บรายงานแต่ละฉบับ ตรวจหาช่องว่างและรายการซ้ำเทียบกับลำดับใบแจ้งยอด และแยกเป็นรายการย่อย
จับคู่และบันทึก
รายการในใบแจ้งยอดถูกจับคู่กับรายการค้างตามกฎที่คุณอนุมัติ และรายการที่จับคู่ได้ถูกบันทึกเข้า ERP
เมื่อระบบเกิดข้อขัดข้อง
การชำระเงินถูกปฏิเสธ
รายงาน pain.002 มีรหัสเหตุผลของธนาคาร การชำระเงินถูกทำเครื่องหมายว่าถูกปฏิเสธใน ERP และส่งให้ทีมบริหารเงินสดของคุณแก้ไขและส่งใหม่
รายการในใบแจ้งยอดไม่ตรง
รายการกลายเป็นรายการกระทบยอดค้าง พร้อมรายการที่ใกล้เคียงที่สุดและเหตุผลที่ล้มเหลว ทีมของคุณเคลียร์ และกฎสามารถเรียนรู้จากกรณีนั้นได้
ไฟล์หายหรือมาช้า
ตรวจสอบลำดับเลขของใบแจ้งยอดและเวลาส่งที่คาดไว้ ไฟล์ที่หายหรือมาช้าจะแจ้งเตือนก่อนมีใครพึ่งพาสถานะเงินสด
กุญแจหรือใบรับรองใกล้หมดอายุ
กุญแจลงนามและใบรับรองช่องทางถูกติดตามพร้อมวันหมดอายุ และเริ่มต่ออายุก่อนเวลาเพียงพอที่จะตกลงกุญแจใหม่กับธนาคาร
มาตรฐานและระบบ
- มาตรฐานและช่องทางธนาคาร
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- SFTP (H2H)
- EBICS
- Swift
- OpenPGP
คำถามและคำตอบ
host-to-host, EBICS หรือ API ธนาคาร: เราควรใช้อะไร
ธนาคารมักเป็นผู้กำหนด host-to-host SFTP เป็นช่องทางที่เสนอแพร่หลายที่สุดสำหรับไฟล์การชำระเงินขององค์กร EBICS ใช้กันทั่วไปกับธนาคารในเยอรมนี ฝรั่งเศส และประเทศเพื่อนบ้าน API ธนาคารเหมาะกับยอดคงเหลือแบบเรียลไทม์และการชำระเงินทันทีในกรณีที่ธนาคารมี บริษัทจำนวนมากใช้มากกว่าหนึ่งช่องทาง และชั้นการเชื่อมต่อซ่อนความแตกต่างนั้นจาก ERP
เราควรรับใบแจ้งยอด camt.053 หรือ MT940
เมื่อธนาคารมีทั้งสองแบบ camt.053 มีข้อมูลการโอนเงินที่มีโครงสร้างและละเอียดกว่า ทำให้การจับคู่อัตโนมัติเชื่อถือได้มากขึ้น MT940 ยังใช้กันแพร่หลายและใช้ได้ดีในหลายกรณี เรารับได้ทั้งสองแบบ แปลงเป็นโมเดลภายในเดียวกัน และย้ายแต่ละธนาคารจาก MT940 ไปเป็น camt.053 เมื่อเหมาะกับคุณและธนาคาร
เราเห็นสถานะเงินสดระหว่างวันได้หรือไม่
ได้ หากธนาคารของคุณมีรายงานระหว่างวัน ข้อมูลมาในข้อความ camt.052 หรือ MT942 หรือผ่าน API ยอดคงเหลือ เราเก็บตามกำหนดเวลาที่แต่ละธนาคารรองรับ และแสดงเคียงกับใบแจ้งยอดสิ้นวัน ทีมบริหารเงินสดของคุณจึงเห็นสถานะที่คาดไว้และสถานะจริงก่อนเวลาตัดรอบ
เราติดตามได้หรือไม่ว่าใครอนุมัติและส่งการชำระเงิน
ได้ การอนุมัติยังอยู่ใน ERP ของคุณพร้อมการควบคุมเดิม ชั้นการเชื่อมต่อบันทึกทุกไฟล์ที่สร้าง ลงนาม ส่ง และรับ พร้อมเวลา ตัวระบุ และบัญชีทางเทคนิคที่ใช้ บันทึกนั้นเชื่อมการชำระเงินแต่ละรายการในรายงานสถานะของธนาคารกลับไปยังเอกสาร ERP และผู้อนุมัติ
เรามีธนาคารหลายแห่ง แต่ละแห่งเป็นโครงการแยกกันหรือไม่
ไม่ใช่ ชั้นการเชื่อมต่อ โมเดลการชำระเงินภายใน และกฎการจับคู่ถูกสร้างครั้งเดียว ธนาคารใหม่แต่ละแห่งเพิ่มรูปแบบ ช่องทาง และขั้นตอนขึ้นทะเบียนของตัวเอง ซึ่งเป็นงานชิ้นเล็กกว่า เรามักเชื่อมธนาคารที่มีปริมาณมากที่สุดก่อนและเพิ่มรายอื่นตามลำดับ
ทดสอบการเชื่อมต่อก่อนใช้งานจริงอย่างไร
ธนาคารแต่ละแห่งมีสภาพแวดล้อมทดสอบหรือกระบวนการทดสอบ เราตกลงชุดกรณีทดสอบกับธนาคาร ครอบคลุมการชำระเงินแต่ละประเภท การปฏิเสธ และใบแจ้งยอด รันทดสอบและเก็บหลักฐาน เมื่อธนาคารอนุมัติ เราจึงเปิดใช้งานด้วยรอบการจ่ายเงินเล็กๆ ก่อนและเปรียบเทียบผลลัพธ์ก่อนย้ายส่วนที่เหลือ
เริ่มต้นด้วยการพูดคุย ไม่ใช่สัญญา
บอกเราว่าคุณต้องการสร้าง เชื่อมต่อ หรือรักษาความปลอดภัยอะไร สถาปนิกจะพิจารณาร่วมกับคุณ แล้วแนะนำว่าควรเริ่มที่ใด
ขั้นตอนถัดไป
การนัดหมายเวลา
ทีมของเราส่งอีเมลถึงคุณเพื่อนัดหมายเวลาสำหรับการปรึกษา
การปรึกษาก่อนเริ่มงาน
การปรึกษาก่อนเริ่มงานออนไลน์ฟรี 30 นาที: เราพูดคุยถึงเป้าหมาย ระบบ และข้อจำกัดของคุณ
การทบทวนความพร้อม
ในการทบทวนความพร้อมฟรี 48 ชั่วโมง สถาปนิกหลักจะตรวจสอบโครงการของคุณเทียบกับนิยามของความพร้อม 6 ข้อ และแนะนำแนวทางที่เหมาะที่สุด
การเลือกแนวทาง
โครงการที่ขอบเขตพร้อมจะได้รับข้อเสนอที่มีผลผูกพัน ภายใน 3 ถึง 5 วันทำการ โครงการในระยะแนวคิดจะเริ่มใน Blueprint Studio ระบบที่ใช้งานอยู่แต่มีปัญหา ไม่มีเอกสาร หรือต้องเชื่อมต่อ จะเริ่มด้วยการวินิจฉัยระยะเวลา 1 ถึง 2 สัปดาห์ Blueprint Studio และการวินิจฉัยต่างมีค่าธรรมเนียมคงที่ ซึ่งระบุไว้ในข้อเสนอ