[16.0][FIX] l10n_th_bank_payment_export: กันไฟล์ที่ธนาคารจะตีกลับ ไม่ให้ออกจากระบบ - #1252
Open
coreichamp wants to merge 1 commit into
Open
[16.0][FIX] l10n_th_bank_payment_export: กันไฟล์ที่ธนาคารจะตีกลับ ไม่ให้ออกจากระบบ#1252coreichamp wants to merge 1 commit into
coreichamp wants to merge 1 commit into
Conversation
KTB rejected another file. Set beside the one it accepted, the layout is
not at fault: given the same data our layout reproduces the accepted file
byte for byte, all three records. Three fields differed, and all three
were master data on the instance rather than anything in the file's
shape.
field accepted rejected
H Sending A/C 0286015838 0883000059 <- an SCB account
H Company Name KING MONG... kmitl <- the placeholder
D Receiving Bank 006 ' ' <- no clearing code
Two of the three can be caught before the file leaves, so they are now.
The money has to leave from an account at the bank the file goes to. The
header names that account and the receiving bank reads it as one of its
own, so a file addressed to KTB drawn on an SCB account asks KTB to debit
an account it has never heard of -- and the refusal says nothing about
which account, because as far as the bank is concerned it is not there.
The bank is derived from the paying account when a file is built from a
payment selection, but either side can be changed afterwards and the two
then disagree in silence. Checked in the shared module: it is true of all
four banks.
A payee's bank has to carry its clearing code. SCB's 003 record and KTB's
D record write it, and without it the field goes out as three spaces.
Checked only in those two modules -- KBANK and BAY credit their own
accounts and carry no such field, so requiring one there would block a
good file. The codes are seeded but under noupdate, so a database that
had the res.bank records before the codes were added still has them
empty; that is how this one got out.
The third, a sender name left at kmitl, has no value we could validate
against, so it stays a thing to notice: 25 characters of placeholder in
the field the bank prints on the advice.
Also confirmed by two files KMITL got accepted: BAY's twenty characters
after the originating account must be blank, which is what this branch
already writes, and the header and detail value periods now agree in
BAY's output -- the September-header, May-detail file that could not be
explained is not what the current build produces.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ต่อจาก #1235 ซึ่ง merge ไปแล้ว
ที่มา
KTB ตีกลับไฟล์อีกใบ (
PE2600065.txt) เอามาวางข้างไฟล์ที่ธนาคารรับ (PE2600004_KTB_A) แล้วไล่ทีละ field — layout ไม่ผิด: ป้อนข้อมูลเดียวกันเข้าไป layout ของเราสร้างไฟล์ที่ธนาคารรับได้ ตรงทุก byte ทั้ง 3 record (ยืนยันด้วย emulator)ต่างกัน 3 field และเป็น master data บน instance ทั้งหมด ไม่ใช่รูปแบบไฟล์
02860158380883000059KING MONGKUT LADGRABANGkmitl006res.bank.bank_codeยังไม่มีค่า2 ใน 3 ข้อดักได้ก่อนไฟล์ออกจากระบบ PR นี้จึงดักให้
1. เงินต้องออกจากบัญชีที่อยู่ธนาคารเดียวกับไฟล์ (
_format)header เขียนเลขบัญชีต้นทางลงไป และธนาคารผู้รับอ่านมันเป็นบัญชีของตัวเอง → ไฟล์ที่ส่งให้ KTB แต่หักบัญชี SCB คือการสั่งให้ KTB หักบัญชีที่มันไม่เคยรู้จัก และคำปฏิเสธจะไม่บอกว่าเป็นบัญชีไหน เพราะสำหรับธนาคารคือ "ไม่มีบัญชีนี้"
bankถูก derive จากหัวจ่ายตอนสร้างไฟล์จาก payment selection แต่แก้ทีหลังได้ทั้งสองฝั่ง แล้วสองค่านั้นขัดกันแบบเงียบ ๆ — ฟอร์มบอก KTB, header บอกบัญชี SCB, และสัญญาณแรกที่รู้คือธนาคารตีกลับอยู่ใน
_check_constraint_line()ของโมดูลกลาง เพราะเป็นจริงกับทั้ง 4 ธนาคาร (บรรทัดที่ไม่มีบัญชีต้นทางเลยก็ผิดแบบเดียวกัน — header จะออกเป็นเลขศูนย์)2. ธนาคารของผู้รับต้องมีรหัส clearing (
_scb,_ktb)record 003 ของ SCB และ record D ของ KTB เขียนรหัสนี้ ถ้าไม่มีก็ออกเป็นช่องว่าง 3 ตัว
เช็คเฉพาะ 2 โมดูลนี้ — KBANK กับ BAY โอนเข้าบัญชีตัวเองและไม่มี field นี้เลย ถ้าไปบังคับด้วยจะบล็อกไฟล์ที่ถูกต้อง (SCB บังคับเฉพาะ product ที่ไม่ใช่ DCP เพราะ DCP layout เขียน
014เองอยู่แล้ว)3. ข้อที่ 3 ดักไม่ได้
ktb_sender_nameที่ยังเป็นkmitlไม่มีค่าที่ถูกต้องให้เทียบ จึงเป็นเรื่องที่ต้องไปแก้เอง — 25 ตัวอักษรของ placeholder ในช่องที่ธนาคารเอาไปพิมพ์บน advice (bank_payment_template.xmlก็เป็นnoupdateเหมือนกัน แก้ที่ Settings ▸ Bank Payment Templates)ยืนยันจากไฟล์ที่ธนาคารรับอีก 2 ใบ
PE2600008_BAY_G): 20 ตัวหลังเลขบัญชีต้นทางว่าง ✓ ตรงกับที่ [16.0][FIX] l10n_th_bank_payment_export: ทำให้ไฟล์ e-payment ตรงกับตัวอย่างจริงของ 4 ธนาคาร #1235 แก้ไป — และ header กับ detail บอกเดือนตรงกันแล้ว (0926ทั้งคู่) ไฟล์ที่เคยมี header ก.ย. / detail พ.ค. ซึ่งอธิบายไม่ได้ ไม่ใช่สิ่งที่ build ปัจจุบันสร้าง → ปิดประเด็นนี้ได้PE2600004_KTB_A): layout เราสร้างได้ตรงทุก byteTest
เพิ่ม 2 test ใน KTB suite: ไฟล์ KTB ที่หักบัญชีธนาคารอื่นต้อง raise · ผู้รับที่ธนาคารไม่มีรหัส clearing ต้อง raise
ยังไม่ได้รัน
oca_run_testsในเครื่องนี้ (ไม่มี instance ที่ mount workspace นี้) — verify layout ด้วย emulator เทียบไฟล์ที่ธนาคารรับทั้ง KTB และ BAY: ตรงทุก byte