TAX-RPT-1 · FUT Field Notes (Knowledge Report)

← หน้ารวม (Hub) RPT-1 design → My 5 WRICEFs →

หน้านี้ ต่างจาก deep-dive (ที่มาจาก FD) — เป็นความรู้ที่ พิสูจน์เองกับมือ ตอนทำ FUT: สถาปัตยกรรมที่ยืนยันแล้ว, defect 3 ตัวพร้อมหลักฐาน controlled experiment, ระบบ unit test 9 TC, ทักษะ post/อ่าน document และ correction ของความเข้าใจเดิม · ทุกจุดติดป้ายชัดว่า confirmed / inference / open · ชื่อเพื่อนร่วมทีมในต้นฉบับถูกแทนด้วย role

Confirmed พิสูจน์แล้ว (code/FD/screenshot/doc) Inference อนุมาน ยังต้อง verify Open คำถามที่ยังเปิด Correction แก้ความเข้าใจเดิม

10 บรรทัดที่ต้องแม่นจาก FUT

ตัวตน: T-code ZTAXB_R01 · main program SAPLZTAXA_R01 · enhancement ของ standard S_P00_07000134 (RFIDYYWT Generic WHT) · CoCd TH01 TH
Output group ทางการ = R03 (P.N.D. 3/53/54 Attachment) — FD ไม่ได้ระบุ (gap) · AP2 ไม่ใช่ตัวใช้งาน
2 FX columns ขนานกัน ห้ามปน: Fx on TaxPmt = KURSF@T (WHT/ภงด.54) · Fx on posting date = TCURR@T-1 (VAT36/ภพ.36)
M@T (บัญชี) vs BOT@T-1 (สรรพากร) = เหตุมีอยู่ของ TAX-ENH-2 และของสอง column นี้
รายงาน read-only, run ได้เสมอ — chain กระทบแค่ 2 column (Doc WHT FX Adj / VAT36 Doc No.)
เกาะเส้น WHT (KTOSL='WIT') เป็นสมอ · VAT36 เป็นผู้โดยสาร · 1 แถว = เย็บสูงสุด 4 ใบด้วย clearing (AUGBL)
ช่อง Document Number บน selection = เลข Invoice (AP Voucher) ไม่ใช่เลข payment
OB08/TCURR = valid-from + กติกา ล่าสุดที่ ≤ วัน posting (จ่ายอาทิตย์ → ใช้ rate ศุกร์)
Rate types = เลนในตารางเดียว: M(post FI) · B(selling≈BOT) · G(buying) · ZTH/ZOM(custom)
ห้ามพูด “T-1” กับ GL team — ใช้ประโยคเดียว: “bank line must use the payment document’s date”

สถาปัตยกรรม (ยืนยันจากการเทสต์)

1.1 ตัวตนของรายงาน Confirmed

ZTAXB_R01 (main program SAPLZTAXA_R01) = Reconciliation Report ภงด.54 ↔ ภพ.36 · เป็น enhancement ของ standard S_P00_07000134 (RFIDYYWT — Generic Withholding Tax Reporting) สำหรับ CoCd TH01 TH · เพิ่ม Profit Center (validate CEPC) + Recovery Indicator (validate T8JJ) ใน Further Selections + column ฝั่ง VAT36

คำว่า “Generic”: RFIDYYWT เป็น เครื่องยนต์กลางตัวเดียว serve WHT reporting หลายประเทศ — ความต่างทั้งหมดย้ายไปเป็น config Process Type + Output Group · โปรแกรมเป็นแค่คนทำตามสูตร

1.2 Output Group — config ระดับเครื่องยนต์ Confirmed บางแถว

Output group เป็น config ระดับ engine ไม่ใช่ระดับรายงาน — ทุก group ของ TH โผล่ใน F4 ของทุกโปรแกรมบน RFIDYYWT · “กดได้” ≠ “ใช่ของเรา” · 1 group = 1 สูตร (อ่านจากไหน + ผลิต List/Forms/Files + render แบบไหน)

Group	Description (F4)	สถานะ
`R03`	Attachment P.N.D. 3, 53 and 54 — Vendors, Original Documents	Official ของ RPT-1 — team lead ยืนยัน (วาจา) 02.08
`AP2`	WHT Certificate for Thailand & Form No. 54	ไม่ใช่ตัวใช้งาน — สาย certificate (เคยเข้าใจผิดจากคำว่า “Form 54”)
`E08`	Attachment P.N.D. 1 Kor & E-Filing	คนละกระบวนการ (ภงด.1ก) · render เป็น classic list
`CER`	เหมือน AP2 เป๊ะ	Open — group ซ้ำ/legacy? ถาม config owner ก่อน UAT
`E01–E10, E1K, E2K`	Attachment + E-Filing แยกตามแบบ ภงด.	สูตรของ objects ตระกูล text file (TAX-ENH-1/077/079)

FD gap: FD ของ RPT-1 ไม่ระบุ output group (Variants & Constants = N/A) — ต้องขอ confirm เป็นลายลักษณ์อักษรใน Teams หนึ่งครั้งเพื่อตอกหมุด

1.3 สอง FX columns ขนานกัน — ห้าม conflate Confirmed

Column	FD step	Source	วันที่	Serve
Fx on TaxPmt	22	`BKPF-KURSF` จาก payment doc ที่ post แล้ว	T (วันจ่าย)	WHT / ภงด.54
Fx on Posting date	28	รายงานเปิด `TCURR` เอง `GDATU=BUDAT−1`	T-1	VAT36 / ภพ.36

ที่มาของสองโลก: post เข้า GL ใช้ rate M @ T (หลักบัญชี ค่ากลาง ณ วันเกิดรายการ) · แต่เกณฑ์สรรพากรไทยใช้ rate BOT วันทำการก่อนหน้า (T-1 ≈ เลน B) — ช่องว่าง M@T ↔ B@T-1 คือเหตุผลการมีอยู่ของ TAX-ENH-2 (post ส่วนต่างปรับ WHT) และการที่ RPT-1 ต้องโชว์ 2 FX column เทียบกัน

ชื่อ misleading: “Fx on posting date” จริง ๆ คือ rate ของ วันก่อนหน้า posting date (BUDAT−1) ไม่ใช่วัน posting เอง

กติกาสื่อสารเด็ดขาด: ห้ามพูด “T-1” กับ GL team — fix target ของเขาคือฝั่ง TaxPmt เท่านั้น · ประโยคเดียวที่ใช้: “bank line must use the payment document’s date” · เผลอพูด T-1 ปน = เสี่ยง GL แก้ขา bank ไปใช้ T-1 → ผิดบัญชี + defect ใหม่ซ้อน

1.4 กลไกเลือก + เย็บเอกสาร Confirmed

รายงาน เกาะเส้น WHT ที่จุดจ่าย (ACDOCA KTOSL='WIT') เป็นสมอ · VAT36 เป็นผู้โดยสาร:

มี WHT + มี VAT36 → โผล่ครบทุก column
มี WHT ไม่มี VAT36 → ยังโผล่ · ฝั่ง VAT36 ว่างโดย design (= สาระ TC-008)
มี VAT36 ไม่มี WHT → ไม่โผล่เลย (= สาระ TC-009 + ใบ control)

1 แถว = เย็บสูงสุด 4 ใบ: (1) Invoice จาก FB60 → base, VAT36 lines, invoice currency, PC/RI · (2) Payment จาก F-53 → WHT line, KURSF, วัน T · (3) VAT36 doc 9xxxxxxxxx ที่ ZTAXA_R02 สร้าง · (4) WHT FX adj doc (type SW) ที่ ZTAXA_R03 สร้าง · ตัวเย็บ = clearing (BSAK/BSEG-AUGBL) ที่เกิดตอน activate open item ใน F-53

Precision ที่มักสลับ: ช่อง Document Number บน selection รับเลข “Invoice” (AP Voucher) ไม่ใช่เลข payment · selection กรองที่จุดตั้งต้นฝั่ง invoice แล้วโปรแกรมไต่ clearing ไปหา payment เอง (FD 19/27) · “พร้อมกัน” = “ถูกเย็บถึงกันแล้ว ณ วัน run” · invoice ที่ยังไม่จ่าย = ไม่โผล่ (ภาระเกิด ณ จุดเงินออก)

1.5 Execution chain = read-only Confirmed

ลำดับ business: (01) AP posting → (02) ZTAXA_R03/TAX-ENH-2 → (03) ZTAXA_R02/TAX-ENH-3 → (04) RPT-1 · ประโยค KT sheet (“report generated after E032 & E040”) = ลำดับงาน user สิ้นเดือน ไม่ใช่เงื่อนไขทางเทคนิค

ข้อเท็จจริงสำคัญ: RPT-1 read-only · run ได้เสมอ ไม่ error ไม่ block — chain กระทบแค่ 2 column: “Doc WHT FX Adj” ว่างจนกว่า E032 run · “VAT36 Doc No.” ว่างจนกว่า E040 run · ที่เหลือ (WHT amounts, 2 FX columns, VAT36 base/amt FC, PC, RI) มาจาก doc + logic เอง
→ กฎออกแบบ TC ข้อเดียว: run chain เฉพาะเมื่อ column ที่ TC ตรวจต้องพึ่งมัน

Open VAT36 base/amt (FC) น่าจะขึ้นจากฝั่ง invoice โดยไม่รอ R030 — แต่ยังไม่ verify ด้วยตาบน doc ที่ R030 ยังไม่แตะ · TC-007 step 3 (baseline) คือการทดลองที่จะตอบ

1.6 ระบบ rate: เลน · valid-from · ความเสี่ยงวันจันทร์ Confirmed ครึ่ง

OB08/TCURR เก็บแบบ valid-from (แต่ละบรรทัดมีผล “ตั้งแต่วันนั้นจนกว่าจะมีบรรทัดใหม่”) · standard หา rate ด้วย ล่าสุดที่ ≤ วัน posting · เสาร์อาทิตย์/วันหยุดไม่มี rate ใหม่ → ใช้บรรทัดวันทำการล่าสุด (พิสูจน์แล้ว: จ่ายอาทิตย์ 02.08 ระบบดึง 32.57230 ของศุกร์ 31.07)

Rate type = เลนขนานในตารางเดียว: M=middle (post FI ถูกล็อคเลนนี้) · B=selling (≈BOT ฝั่งขาย) · G=buying · custom ZTH (TAX-ENH-2 ฝั่ง LC3) / ZOM (RPT-2 Oman)

Open — KT ข้อ 3 ความเสี่ยงวันจันทร์: FD step 28 เขียน lookup GDATU=BUDAT−1 · ถ้า Z-code เขียน exact match แทน ≤ fallback → payment วันจันทร์/หลังวันหยุดจะได้ Fx on posting date = blank (BUDAT−1=อาทิตย์ ไม่มี GDATU) · อาการเหมือน TC-003 แต่คนละเหตุ · พิสูจน์ฟรีด้วย “การทดลองวันจันทร์” · ฝั่ง GL posting พิสูจน์แล้วว่าใช้ ≤ · เหลือฝั่ง report

Defect ทั้งหมด — หลักฐาน · กลไก · สถานะ

1 defect 1 ticket — คนละชั้น อย่ายำรวม (report logic vs GL posting vs rendering)

TKT-02Exchange rate at payment (ขา bank ใน GL)

Scope ยืนยัน: เกิดเฉพาะ currency case 1 (invoice สกุลที่สาม GBP/EUR → payment USD) และเฉพาะ payment ที่ มี WHT line · case 2 (USD→THB) / case 3 (THB invoice) ไม่โดน · root cause อยู่ ฝั่ง posting ไม่ใช่รายงาน — RPT-1 เป็นกระจก read-only

Owner: fix = GL team · config = Config owner · comms routing = Comms lead · Acceptance criterion: bank outgoing line converts at the payment document’s date

Controlled experiment (02.08) — คู่แฝดต่างตัวแปรเดียว

เงื่อนไข: rate M USD→THB วัน invoice (24.07 = 32.34140) ต้องต่างจากวันจ่าย (02.08 = 32.57230), delta = 0.23090 · ถ้า rate 2 วันเท่ากัน bug ล่องหน (บทเรียนเดียวกับ F6 ของ RPT-2 ที่ flat rate ใน DEV บังไว้)

คู่หลัก (มี WHT): invoice 2004326539 GBP 1,000, V2, backdate 24.07, vendor line 44,060.10 THB · payment 8084322489 USD 1,140.19 (=85% ของ 1,341.40 หลังหัก WHT 15%), จ่าย 02.08

บรรทัด (doc 502)	USD	THB (LC)	Rate แฝง	ตัดสิน
Bank (A102X003)	1,140.19	43,679.45	38.31 — ไม่มีจริงใน TCURR ทุก type	❌ พัง
Vendor (clear)	1,341.40	44,060.10	มูลค่าวัน invoice ยกทั้งก้อน	✅ ปกติ
WHT Pay PND54	201.21	6,553.86	32.5723 = rate วันจ่าย	✅ ถูก
RealizedFX (2 บรรทัด)	0.00	6,173.21 + (15.24-)	ตัวโปะที่ระบบ post เอง	อาการตาม

ที่ถูกต้อง: bank = 1,140.19 × 32.5723 ≈ 37,138.6 → GL เพี้ยน ≈ 6,540.9 THB

ความหมายคู่แฝด: ตัวแปรเดียวที่ต่าง = WHT line · ใบไม่มี WHT ถูก / ใบมี WHT พัง = คำตอบ KT ข้อ 1 (“ทำไมเกิดเฉพาะ payment ที่มี WHT”) ด้วยหลักฐานสร้างเอง

กลไก (ใบ 502): ขา bank ไม่ได้คูณ rate ผิดวัน — มันไม่ได้คูณอะไรเลย · ยอดบาทถูก derive จากมูลค่าวัน invoice (43,679.45 ≈ 44,060.10 ปรับผล WHT) · เลข 38.31 เป็นผลหาร ไม่ใช่ rate · เหมือนเป็นหนี้ตอนทองบาทละ 30,000 จ่ายวันทอง 33,000 แต่สมุดจดว่าเงินที่ออกวันนี้มีค่าเท่าราคาทองวันก่อ

สมมติฐานที่ตัดออก: (1) rate type ผิด → USD ทุก type ตระกูล 32.x, 38.31 ไม่ match · (2) rate ไม่มีในตาราง → OB08 ครบทุกวันทำการ · (3) ขั้นตอน post ผิด → control ขั้นตอนเดียวกันออกถูก · ทิศทางหลักฐาน: program logic ของ clearing/WHT path (ฝั่ง b) > config (ฝั่ง a) เพราะ config ผิดจะกระทบทุกใบ ไม่เลือกเฉพาะใบมี WHT

ใบ 8084322444 (ของทีม, จ่าย 14.07) + correction

Correction ระหว่างวิเคราะห์สด เคยสรุปว่า “ใบ 457 ขา bank/WHT ใช้ rate ผิดวัน (32.588 แทน 32.637)” — อ่านผิด เพราะอ่านตาราง OB08 คลาดบรรทัด: rate M USD→THB มีผล 14.07 คือ 32.58770 ไม่ใช่ 32.637 · ดังนั้นขา bank (37,530.28÷1,151.67=32.588) และ WHT (6,622.95÷203.23=32.589) ของใบ 457 แปลง USD→THB ที่ rate วันจ่ายถูกต้อง

ความผิดปกติของ 457 อยู่คนละจุด: การแปลง GBP→USD (vendor 1,354.90 / bank net 1,151.67) ใช้ cross rate ของ 07.07 ทั้งที่จ่าย 14.07 · สอดคล้องกลไกกับ 502: ทั้งคู่ยอดถูก derive จากมูลค่า ณ วันเก่า แทนแปลงจริง ณ วันจ่าย — แค่คนละมิติ (457 เพี้ยนเลน USD, 502 เพี้ยนเลน THB) · การ map กลไกต่อใบเป็นงาน triage ของ GL team · หน้าที่เรา = ส่งเลข observed ครบ

บทเรียนการอ่าน FI doc ที่ได้จากคู่นี้ (3 ข้อ)

rate แต่ละบรรทัดของ doc ที่ถูกต้อง ไม่จำเป็นต้องเท่ากัน — vendor ตรึงมูลค่าวัน invoice (อดีต), bank/WHT ใช้วันจ่าย (ปัจจุบัน), ส่วนต่างลง Realized FX · ผิดคือเมื่อขาปัจจุบันไปใช้ค่าอดีต
จำนวนบรรทัดไม่ fix — RealizedFX แตก 2 บรรทัดใน 502 (THB 6,173.21 / group 15.24-) เพราะแต่ละเลนสกุลเพี้ยนไม่เท่ากัน · เทียบ doc ให้เทียบ โครงหน้าที่ ไม่ใช่นับแถว
ขยะจาก bug (FX lines) ลง PC C_PC11 / RI CP — ไหลเข้า profit center เดียวกับที่ RPT-1 และ TC-005 answer key อ่าน = เหตุผลต้องแก้ที่ posting ไม่ใช่ปัดที่รายงาน

สถานะ: ticket เปิด (Fix versions S/4 Program/04 Test), triage ทีมเอียงทาง config · evidence เรา (WHT-line trigger + rate ผี) เป็นข้อมูลสวน ส่งผ่าน Comms lead พร้อม workbook DEFECT_REPRO · Blocked จนกว่า fix transport · ห้ามใช้คู่ repro เป็น TC-001 (ค่าผิดติด GL ถาวร ต้อง post ใหม่หลัง fix)

TC-003FX on Posting Date blank เมื่อ invoice = THB (ฝั่งรายงาน)

อาการ: invoice THB + payment FC → “FX on posting date” blank และ VAT36 base/amt (THB) = 0.00 ทั้งคู่ (หลักฐานแรก: doc 2004322073 / VAT36 9004322999, 31.07)

กลไก: FD step 28 case 2 บอก “ไม่ต้อง convert” แต่ dev implement เป็น SELECT TCURR ทุกกรณีโดยไม่มี same-currency guard — ไม่มีใครเมนเทน rate THB→THB → SELECT ไม่เจอ → rate ค้าง initial → domino: THB columns = FC×0 = 0.00 (สองอาการ สาเหตุเดียว)

Expected หลัง fix (confirm โดย SI functional 31.07): FX on posting date = 1.00000, VAT36 THB = ยอด DC ตรง ๆ · Proposed fix: ถ้า BKPF-WAERS = THB → hard-set rate = 1.00000 แล้วข้าม TCURR fetch

Scope discipline: แยก ticket จาก 163211 เด็ดขาด (report logic vs GL posting) · อย่าพ่วง GDATU exact-match/Monday (ยัง open ไม่ใช่ observed defect) · owner = TAX ABAP dev (ยังต้องได้ contact — KT ข้อ 5) · column นี้อยู่ฝั่ง ภพ.36 ไม่ใช่ ภงด.54 — เล่าให้ระบุชั้นตรง

GETWA_NOT_ASSIGNEDShort dump — output control (ฝั่ง rendering)

อาการ: untick “Company Codes” ใน List Sections → short dump ใน SAPLZTAXA_R01 · Reproduce ยืนยันบนทั้ง R03 (official path!) และ AP2 · E08 (classic list) ไม่เป็น

กลไก: โปรแกรมถูกแปลงจาก classic list (WRITE — 4 sections ต่อกันในม้วนเดียว ตัดอิสระ) เป็น ALV (1 grid:1 จอ ต้องมีโครงสร้างของแต่ละ section) แบบครึ่ง ๆ กลาง ๆ · code path ALV assume ว่า section ครบ · untick → โครงสร้างไม่ถูกสร้าง แต่ code ยังอ้างถึง → field symbol ไม่ assign → dump · พังทั้ง R03+AP2 = จุดพังอยู่ โค้ดส่วนกลางของ render ไม่ใช่ logic เฉพาะ group

สำคัญหลังรู้ว่า R03 = official: จาก “อาจเป็นแค่ constraint” → defect บน production path ที่ user เจอได้ทุกเดือน — สมควรเปิด JIRA แยกและดันแก้ · Workaround: ติ๊ก List Sections ครบ 4 ทุก run (เขียนเป็น prerequisite แล้ว) · แยก list/ALV ด้วยตา: มี toolbar sort/filter/Σ/export = ALV, ตัวหนังสือเปล่า = classic

2.4 Defect/ปัญหาอื่นที่จดทะเบียน

ID_WT 027 — WHT reference number missing สำหรับ CoCd TH01 (config gap, ไม่ block list output)
CX_DMEE dump — DMEE engine, scope ทีมอื่น
AP2 vs CER descriptions ซ้ำ — legacy trap · เคลียร์ก่อน UAT (user run ผิด group แล้วพฤติกรรมต่าง = defect ผีตอน SIT)

Unit Testing — ระบบ · ทักษะ · สถานะ

3.1 โครง 9 Test Cases + Document Sets A–H

ทุก TC self-contained: post เอกสารใหม่เอง บน master data ที่ proven · ยอดมาตรฐาน base 1,000 / WHT 15%=150 / VAT36 7%=70 · ใช้ posting date เดียวกันทุกใบเป็น isolation key (E032 เลือกด้วย period → วันเดียวร่วมทำให้ write ครอบเฉพาะจักรวาลเรา ใน shared client)

Set	TC	Invoice	Payment	WHT/VAT36	บทบาท
A	TC-002	THB	THB	✓/✓	No-conversion; E032 pass-through (zero adj)
B	TC-003	THB	USD	✓/✓	Reproduce defect FX blank
C	TC-004	USD	THB	✓/✓	Invoice-currency conv @T-1; side-evidence 163211
D	TC-001	EUR/GBP (post หลัง fix)	USD	✓/✓	Case 1 full chain
E	TC-008	THB	THB	✓/✗	PND54-ไม่มี-VAT36 (ว่างโดย design)
F	TC-006	THB	USD	✓/✓	E032 transition (ต้องจ่าย FC ไม่งั้นไม่มี FX diff)
G	TC-007	THB	USD	✓/✓	E040 transition (VAT36 Doc No. ก่อน/หลัง)
H	TC-009	THB	THB	✗/✓	Negative — ต้องไม่โผล่

Stage บังคับ 5 ขั้น: (1) Post ทั้งหมดยกเว้น D → (2) Baselines + read-only ทั้งหมด ก่อน update run ใด ๆ → (3) Chain writes: E032 test→update (=TC-006), R030 test→update ราย doc (=TC-007 + เติม TC-002/004) → (4) Post-chain verifications → (5) Gated: TC-001 หลัง GL fix / TC-003 retest หลัง report fix

Chain → TC mapping: TC-001/002 = เดินครบ chain end-to-end · TC-006 = test ของ E032 โดด ๆ · TC-007 = ของ E040 โดด ๆ · TC-003/004 ตรวจ FX ไม่พึ่ง chain (R030 ใส่เพื่อความครบของ row) · TC-005 filter ไม่พึ่ง chain · TC-008 = E040 ไม่มีอะไรให้ gen นั่นคือ case · TC-009 = run R030 แล้วต้องยังไม่โผล่

3.2 Discipline ทุก run

Capture selection screen ก่อน Execute เสมอ · เปลี่ยนตัวแปรเดียวต่อ run เทียบ baseline
Test run ก่อน Update run เสมอ · ดู proposal ให้เห็นว่ามีแค่ doc เราก่อนกด update · baseline ก่อน write เสมอ
ห้ามกรอก manual rate (ทำลาย expected) · ห้ามใช้ Distribute/Charge Off Difference (โยนส่วนต่างลงบัญชีอื่น)
expected values เทียบ สูตร ไม่ใช่ตัวเลขดิบ (rate เปลี่ยนได้ สูตรไม่เปลี่ยน) · doc DEFECT-REPRO ติดป้ายใน Evidence Log ห้ามปนกับ TC จริง

3.3 ทักษะ SAP จากการลงมือจริง

FB60 (Invoice) — 6 จุดที่ต้องรู้

Branch Code = สาขาสรรพากรของ ผู้ขาย (คนละช่องกับ Bus.Place=สาขาเรา) · บังคับเฉพาะ vendor ไทย · validate กับ branch data ใน BP master (F4 ว่าง = master ไม่มี พิมพ์เองไม่ผ่าน) · foreign vendor ไม่โดน — พอดี scenario ภงด.54/ภพ.36 (จ่ายต่างประเทศ)
rate เกาะ Posting Date ไม่ใช่ Invoice date — backdate ต้องเปลี่ยนทั้งคู่
tab Withholding tax ต้องแวะดูก่อน Post เสมอ (ถ้าว่างระบบไม่เตือน post ผ่านเงียบ ๆ → doc ใช้กับ RPT-1 ไม่ได้)
cost object บน expense line = ตัวกำหนด PC/RI ในรายงาน (chain: Cost Center → Profit Center → Segment) · warning “segment invalid” = ยังไม่ใส่ cost assignment
หลักเลือก master data: “doc ใหม่ บน master data ที่ proven” — ลอก vendor/tax code/G-L/cost center จาก doc ที่ผ่าน chain มาแล้ว (FB03) แทนสุ่ม
tax code: V1/V2 = 7% ClaimPP36 (ยึด label ในระบบ)

F-53 (Payment) — Assigned loop + จุดพลาด

ขา bank เกิดจาก header เท่านั้น — Bank data ว่าง = doc ไม่มีขาเงินออก (overview โชว์ 0 line / INTERNAL)
ช่อง Currency default THB ต้องเปลี่ยนก่อนทำอย่างอื่น · ยอดจ่าย = net หลังหัก WHT ไม่ใช่ยอดเต็ม
เทคนิค Assigned loop: ใส่ยอดประมาณ → Process Open Items → อ่านค่า Assigned (=ยอดเป๊ะที่ระบบต้องการ) → back → แก้ Amount → Not Assigned = 0.00
activate เฉพาะใบเป้าหมาย (vendor test มี open items ปนหลายใบ) · CashDiscount ปล่อยว่างเสมอ
อ่านจอ: Assigned ÷ Gross = 0.85 → WHT 15% ทำงาน โดยไม่ต้องเปิด tab · tab WH Tax = จุด capture evidence ว่า payment มี WHT line

FB03 (Display) — posting keys + implied rate

posting keys: 31 เครดิตเจ้าหนี้ / 25 เดบิตล้างเจ้าหนี้ / 40-50 เดบิต-เครดิต G/L · vendor line โชว์ reconciliation account ไม่ใช่ expense
LC Amount (THB) = เลนที่รายงานภาษีไทยอ่าน · Group Curr (USD) = LC2 เพื่อ consolidation อ่านข้ามได้
เทคนิค implied rate: LC ÷ Amount ของแต่ละบรรทัด บอกทันทีว่าแปลงด้วย rate อะไร (เครื่องมือหลักที่ใช้จับ 163211)
Data Entry View = สิ่งที่คนกรอก · General Ledger View = สิ่งที่รายงาน/ACDOCA อ่าน (KTOSL='WIT' อยู่มุมนี้)
VAT36 reverse charge = ขาคู่ Def Inp VAT (สิทธิ์) + Inp VAT Pay (หน้าที่) หักล้างศูนย์ รอ R030 ประมวลสิ้นเดือน

Tax codes (client จริง): V1/V2 = 7% ClaimPP36 (สเปรดชีต config เก่าที่ว่า V2=10% outdated — ยึด label ในระบบเสมอ) · V0 ห้ามใช้แทน “ไม่มี VAT36” (ยังเป็น code กลุ่ม VAT36 อัตรา 0% → แยกไม่ออกว่า 0.00 เพราะอัตราหรือ defect) · V3–V6 unclaimable = นอก scope TC หลัก (edge case SIT + ถาม config)

3.4 สถานะ ณ 02.08.2026

รายการ	สถานะ
Doc set A (`2004326537` THB 12,345 + payment)	✅ post ครบคู่ — TC-002 พร้อม run บน R03
Repro pair (`2004326539` + `8084322489`)	✅ post — ป้าย DEFECT-REPRO ห้ามเป็น TC-001; รอ run R03 เป็น observation
Control pair (GBP no-WHT + USD payment)	⚠️ ยืนยัน post จบ + เก็บเลข doc + capture ขา bank (×32.5723) · ใช้เป็น mini TC-009 FC
TC-005 baseline (116 records, 30.07)	⚠️ re-verify บน R03 + re-export answer key หลัง Stage 1 (population เปลี่ยน)
Doc sets B, C, E, F, G, H	⏳ ยังไม่ post — pattern พร้อม (B/F/G=THB→USD, C=USD→THB)
Doc set D (TC-001)	🔒 Gate: ห้าม post จนกว่า 163211 fix transport

ไฟล์ที่สร้าง: TAXR074_FUT_Execution_Workbook_TC001-TC009_v2.xlsx · Client_FUT_..._TAX-RPT-1_...xlsx (template ทางการ 9 TC, 50 steps) · DEFECT_REPRO_TKT-02_Summary_20260802.xlsx — ทั้งสามไฟล์ยังเขียน AP2 ต้องอัปเดตเป็น R03 (งานค้างอันดับต้น)

KT Open Questions — สถานะล่าสุด

#	คำถาม	สถานะ
1	ทำไม wrong-date เกิดเฉพาะ payment ที่มี WHT line	ตอบแล้ว ด้วยคู่ control/repro
2	Fx on TaxPmt (T) vs E032 (T-1) — ค่าไหนยื่นจริง / E032 ต้อง run ก่อน RPT-1?	ครึ่งแรก เปิด · ครึ่งหลัง ตอบ (business order ไม่ใช่เทคนิค)
3	Step 28 อ่าน TCURR exact GDATU=BUDAT−1 หรือ ≤ fallback	GL พิสูจน์ ≤ แล้ว · report รอ “ทดลองวันจันทร์” เปิด
4	OB08 maintenance timing + เจ้าของหลัง go-live	เปิด · TCURR = client-wide ห้ามเมนเทนเองโดยไม่ประกาศ
5	Handover artifacts + ABAP dev contact ของ RPT-1	เปิด · สำคัญขึ้นเพราะ TC-003 fix ต้องมี dev contact
ใหม่	Official output group	R03 (วาจา) — ตอกหมุดเป็นลายลักษณ์อักษร
ใหม่	AP2 vs CER description ซ้ำ	เปิด — ถาม config owner ก่อน UAT

หลักการทำงานที่ตกผลึก

Scope discipline: 1 defect 1 ticket — TC-003 blank / 163211 / GETWA dump / Monday-fallback = 4 เรื่องแยกแม้อาการคล้าย · ยำรวม = partial fix ปิด ticket แล้วเรื่องจริงหลุด

Evidence-first: ทุก claim trace กลับ source ได้ (code/FD/screenshot/เลขใน doc) · “เห็นกับตา” ชนะ “มีคนบอก” · evidence ขัดความเชื่อเดิม (R03 vs AP2, ใบ 457) → แก้ความเชื่อ ไม่ใช่เก็บ evidence เข้าลิ้นชัก · จด correction ตรง ๆ

Ownership boundaries: GL posting → GL team · report logic → TAX ABAP dev · config → Config owner · comms → Comms lead · อย่าให้ภาษาทำให้คนแก้ผิดที่ (“แก้ Fx on TaxPmt” ฟังเหมือนแก้รายงาน ทั้งที่ fix อยู่ posting — ยึดภาษา acceptance criterion)

Inference vs Confirmed: ระวังอนุมานจากชื่อ (AP2 มี “Form 54” ≠ group ใช้งาน · “E” ใน E08 เดา e-filing บังเอิญถูก) · inference ตั้งสมมติฐานได้ แต่ปิดด้วย config/คนยืนยัน/การทดลองเสมอ

สื่อสารในทีม: ตอบ senior ให้ระบุ “ขาไหน” ชัด (บทเรียนจากตอบ “Vendor” ทั้งที่ตัวพังคือขา bank) · ประโยคปลอดภัยของ 163211: “bank outgoing line converts at the wrong value when the payment carries a WHT line” — ระบุตัวพัง (bank) + ตัวกระตุ้น (WHT) แยกในประโยคเดียว · route ผ่าน senior ก่อน commit ใน public channel

สถานะล่าสุด (mid-Oct-2026) — หลังจาก field notes ชุดนี้

ส่วน 1–5 คือสิ่งที่พิสูจน์ช่วง 31.07–02.08 · ส่วนนี้คือสิ่งที่เกิดหลังจากนั้น: RPT-1 ผ่าน review 11-Sep · R03 ถูกใช้เป็น output group ทางการ · split lines (TKT-01) กลับมาทำต่อ 2-Oct

Open issues

#	Issue	หลักฐาน / ตัวอย่าง	Next
1	Multi-invoice payment (14-Sep): รายงาน resolve AP voucher ตัวเดียวแล้ว stamp ทุกแถว	`8084322636` (THB, 3 vendors) · `8084322637` (USD, vendor เดียว, 6 invoices รวมเป็น 2 WHT sets)	Dev fix ต่อแถว: `BSAK-LIFNR = WT_ACCO` + match WITH_ITEM ของ invoice (vendor + type + code) · กฎแบ่งยอด = D3
2	คอลัมน์ WHT Rate โชว์ 15% สำหรับ code 44 ที่ post 10%	—	เช็ก `T059Z`
3	FD gap: steps 17/18 บอก KTOSL = WIT แต่ไม่มีการเลือกบรรทัด · step 34 ใช้ KTOSL = XST	claim เดิมว่า step 33 ไม่มี KTOSL — ถอนแล้ว	FD v0.2 / CR (G3)
4	TKT-01 split lines: WHT@payment หยิบ ACDOCA WIT record แรกแม้เป็น 0.00	`2004328305` (5A/39, 3 WIT lines 90/45/15) · `2004327460` (USD, WIT 10/5) · `2004328295` / `8084322641`	ส่ง expected-result workbook แล้ว (หนึ่งแถวต่อ WIT line ที่ HSL ≠ 0) · เทียบไอเดีย “high-precision portion” ของ senior กับ WIT-ratio · partial payment รอยืนยัน
5	TKT-02 (GL): invoice สกุลที่สาม (GBP/EUR) → จ่าย USD มี WHT — bank line ใช้ rate วัน invoice	คู่ control / repro ส่วน 2	Acceptance = bank line ใช้วันที่ของ payment doc · บล็อก TC-001
6	GL-ENH-1: WITH_ITEM ไม่ถูก update ด้วยบรรทัด WHT ของ GL ตอน post	`8084322568` aux 38,000.70 / 5,700.11 vs GL 38,108.97 / 5,716.35 (adj `8084322578`) · `8084322545` same-day gap 4.57	ประสานกับ ENH-2 owner (dual-write)
7	5G doc `8084322612` (5G/B8) อยู่ใน WITH_ITEM แต่ไม่ออก R03	—	SE16N `ZCAX_P01` WHT_TYPE_PND54 → BAdI → form-name condition → standard DS FM

Test cases (current set)

TC-001 FC invoice → USD payment — blocked by 163211 · one-shot retest หลัง deploy
TC-002 / 003 / 004 runnable (004 พิสูจน์ว่า USD→THB ไม่โดน)
TC-005 PC/RI 4-run method: baseline → positive → negative (คาดว่าว่าง / ไม่ dump) → RI · rerun หลัง split change
TC-006 / 007 write data (ENH-2 ก่อน / ENH-3 ก่อน) บนเอกสาร dedicated
TC-008 / 009 VAT36-without-PND54 (รวมแบบจ่าย FC)
TC-010..016 draft สำหรับ multi-invoice payment — ต้องรันบน FRM-1 / ENH-1 ด้วย

Specimen registry

Doc(s)	ใช้พิสูจน์อะไร
`581 / 5184`	EUR→USD ผ่าน ENH-2 · step-28 = 38.03240
`558 / 4943`	same-day gap
`552 / 4882`	USD→THB · กับดัก Sunday fallback (ดูถูกเพราะบังเอิญ)
`568 / 5069`	ratio-vs-table discriminator · step-28 = 32.72500
`580`	LC3 fail (“Balance in Hard currency USDTH”)
`611`	GBP→USD · step-28 = 44.14480
`5473`	multi-PC
`4941` + `5690`	5A docs
`8084322636 / 650`	multi-invoice payment
`2004328305 / 2004328295`	split lines

Statutory conflict (ไม่ใช่ defect): PND54 = สกุลจ่ายจริง @ T-1 vs VAT36 = ยอด invoice × table rate @ T-1 → doc 581 ต่าง 76.57 THB · รอคำตัดสิน (D1) — ดู Decisions · backlog ทั้งทีมอยู่ที่ FUT backlog