วิธีเตรียมไฟล์โอนเงินให้ธนาคารรับได้ทั้งไฟล์

บริษัทที่จ่ายเงินให้ผู้ขายหลายสิบรายต่อวัน มักไม่โอนทีละรายการในแอปธนาคาร แต่ใช้บริการโอนเงินแบบเป็นชุดที่ธนาคารเปิดให้ลูกค้าธุรกิจ ระบบบัญชีหรือ ERP ออกไฟล์รายการโอนหนึ่งไฟล์ อัปโหลดผ่านเว็บของธนาคารหรือส่งผ่าน SFTP แล้วมีคนอนุมัติในระบบของธนาคารอีกที

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

ไฟล์โอนเงินเป็นไฟล์ข้อความบรรทัดละหนึ่งรายการ#

ไฟล์มักเปิดด้วยบรรทัดหัวไฟล์ที่บอกว่าบริษัทไหนเป็นผู้จ่าย จากบัญชีไหน ตามด้วยบรรทัดละหนึ่งรายการโอน บางรูปแบบมีบรรทัดภาษีหัก ณ ที่จ่ายต่อท้ายรายการ แล้วปิดด้วยบรรทัดท้ายไฟล์ที่บอกจำนวนรายการและยอดรวม ธนาคารใช้บรรทัดท้ายนี้เช็กว่าไฟล์มาครบ

ตัวอย่างไฟล์ที่แต่งขึ้น แต่ละช่องคั่นด้วยตัวคั่น และบรรทัดท้ายไฟล์บอกจำนวนรายการกับยอดรวม

แต่ละช่องคั่นด้วยตัวคั่นที่ธนาคารกำหนด หรือกำหนดความกว้างของแต่ละช่องตายตัว ทั้งสองแบบมีจุดอ่อนเดียวกัน คือข้อมูลที่หลุดรูปแบบไปแม้แต่ตัวเดียว ทำให้ช่องหลังจากนั้นผิดหมด

ตัวอักษรบางตัวทำให้ข้อมูลทั้งรายการเลื่อนช่อง#

ข้อมูลที่ใส่ในไฟล์มาจากระบบบัญชี ซึ่งมีคนพิมพ์ ที่อยู่ผู้รับเงินอาจมี ; # หรือ & ติดมา ธนาคารปฏิเสธบางตัวโดยบอกว่าใช้ตัวอักษรต้องห้าม รายการนั้นก็ไม่ผ่าน

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

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

ความยาวของภาษาไทยนับได้สองแบบ#

ทุกช่องในไฟล์มีความยาวสูงสุด คำถามคือนับยังไง ไฟล์ส่วนใหญ่ทุกวันนี้เป็น UTF-8 ซึ่งตัวอักษรไทยหนึ่งตัวใช้ 3 byte ช่องที่รับ 30 ตัวอักษรจึงรับภาษาไทยได้แค่ 10 ตัวถ้าธนาคารนับเป็น byte

ธนาคารเดียวกันนับไม่เหมือนกันทุกช่อง ช่องที่อยู่ที่กำหนดไว้ 50 ตัวอักษร เคยรับที่อยู่ยาว 138 byte ได้ แปลว่านับเป็นตัวอักษร แต่ตอนที่ช่องเลขบัญชีมีชื่อคนหลงเข้าไป ธนาคารตอบว่ายาวเกิน 30 โดยนับชื่อไทย 19 ตัวเป็น 55 ซึ่งคือนับเป็น byte

ระบบจึงควรตัดความยาวเป็นตัวอักษร (ตัดเป็น byte อาจตัดกลางตัวอักษรไทยจนอ่านไม่ออก) แล้วถามธนาคารให้ชัดว่าช่องไหนนับแบบไหน ถ้าธนาคารตอบไม่ได้ ก็ลองส่งไฟล์ทดสอบที่ใส่ภาษาไทยยาว ๆ ในแต่ละช่องดู เรื่องนับตัวอักษรไทยแบบเดียวกันนี้เจอใน SMS ด้วย อ่านเพิ่มได้ที่ SMS ภาษาไทยส่งได้กี่ตัวอักษร

ไฟล์ที่ธนาคารส่งกลับอาจเป็น TIS-620#

หลังส่งไฟล์ ธนาคารส่งไฟล์กลับมาสองรอบ รอบแรกบอกว่าไฟล์ผ่านการตรวจหรือไม่ รอบหลังบอกผลการโอนของแต่ละรายการ ไฟล์ที่เราส่งเป็น UTF-8 แต่ไฟล์ที่ธนาคารส่งกลับเป็น TIS-620 ซึ่งเป็นรหัสภาษาไทยแบบเก่าที่ระบบธนาคารหลายแห่งยังใช้

ถ้าอ่านไฟล์ TIS-620 เหมือนเป็น UTF-8 ภาษาไทยในเหตุผลที่ปฏิเสธจะเป็นตัวอักษรมั่ว ๆ ฝ่ายการเงินอ่านไม่ออกว่ารายการไหนผิดเพราะอะไร ระบบต้องแปลงไฟล์ขาเข้าเป็น UTF-8 ก่อนอ่านทุกครั้ง และควรเก็บไฟล์ต้นฉบับที่ได้จากธนาคารไว้ด้วย เผื่อต้องย้อนดู

รายการเดียวผิด ธนาคารปฏิเสธทั้งไฟล์#

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

ระบบจึงควรแยกรายการที่ไม่ผ่านแน่ ๆ ไว้ไฟล์ของตัวเองก่อนส่ง เช่นเลขบัญชีที่ไม่ใช่ตัวเลข หรือยาวไม่ตรงกับที่บริการนั้นกำหนด รายการที่เหลือจะไปในไฟล์ที่ไม่มีอะไรเสี่ยง ส่วนไฟล์ที่แยกไว้ยังส่งต่อไป ให้ธนาคารปฏิเสธแล้วเหตุผลไปขึ้นที่รายการนั้น ซึ่งเป็นที่ที่ฝ่ายการเงินเฝ้าดูอยู่แล้ว

เกณฑ์ที่ใช้แยกต้องไม่จับรายการที่ถูกผิดไปด้วย ก่อนเปิดใช้ เราลองเกณฑ์กับรายการจ่ายย้อนหลังหนึ่งปี ได้ 3 รายการจากราว 2,200 รายการ และทั้งสามรายการคือรายการที่ธนาคารเคยปฏิเสธจริง ไม่มีรายการที่ถูกโดนจับผิด

รายการที่ไม่ผ่านแน่ ๆ แยกไปไฟล์ของตัวเอง รายการที่เหลือจึงไม่โดนปฏิเสธไปด้วย

ไฟล์ต้องเข้ารหัสก่อนส่ง#

ไฟล์โอนเงินมีเลขบัญชีและยอดเงินของทุกรายการ ธนาคารที่รับไฟล์ผ่าน SFTP มักให้เข้ารหัสไฟล์ด้วย GPG ก่อนส่ง ระบบเข้ารหัสด้วยกุญแจสาธารณะของธนาคาร ซึ่งมีแต่ธนาคารที่เปิดได้ ไฟล์ที่ธนาคารส่งกลับก็เข้ารหัสด้วยกุญแจสาธารณะของบริษัท และเปิดได้ด้วยกุญแจส่วนตัวที่เก็บไว้บนเซิร์ฟเวอร์ของบริษัทเท่านั้น

นอกจากกุญแจ ธนาคารมักเปิดให้เชื่อม SFTP ได้จาก IP ที่ลงทะเบียนไว้เท่านั้น เครื่องของนักพัฒนาจึงต่อไม่ได้ ควรขอบัญชีทดสอบกับธนาคารตั้งแต่ต้น พร้อมชุดกุญแจของบัญชีทดสอบแยกจากของจริง

กรณีที่อาจเจอในงานจริง#

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

เรื่องที่ควรถามธนาคารและทีมพัฒนา#

1. ธนาคารมีรายการตัวอักษรต้องห้าม และกติกาความยาวของแต่ละช่องเป็นตัวอักษรหรือ byte ไหม
2. ไฟล์ที่ธนาคารส่งกลับใช้รหัสภาษาไทยแบบไหน
3. ถ้ารายการเดียวผิด ธนาคารปฏิเสธรายการเดียวหรือทั้งไฟล์
4. ระบบตรวจอะไรก่อนส่ง และรายการที่ไม่ผ่านแน่ ๆ ไปอยู่ที่ไหน
5. กุญแจเข้ารหัสเก็บที่ไหน และมีชุดแยกสำหรับบัญชีทดสอบไหม