← หน้ารวม (Hub)
My 5 WRICEFs →
ห้าเรื่องที่ถูกถามบ่อยที่สุดตอน FUT / SIT / KUT — แต่ละเรื่องมี โมเดลที่กดเล่นได้: ใส่สถานการณ์ → ดู เอกสาร SAP ที่เกิดขึ้นจริง (ACDOCA / BSAK / WITH_ITEM / BSEC) → ดู แถวในรายงาน → ระบบ เช็กให้ ว่ายอดผูกกันไหม · กฎ มาจาก design ที่ตกลงแล้วและหลักฐาน FUT · ตัวเลข เป็น sample แก้ได้ทุกช่อง
อ่านทุกโมเดลแบบเดียวกัน — 4 ขั้น
- ① Scenario — preset จากเคส FUT จริง หรือแก้ตัวเลขเอง (state อยู่ในหน้านี้เท่านั้น รีเฟรชแล้วรีเซ็ต)
- ② SAP document — บรรทัดที่ระบบสร้าง/อ่าน พร้อมชื่อ field จริง (
KTOSL · HSL · PRCTR · RECID · WT_QBSHB · BSEC-STCD3)
- ③ Output — แถวที่รายงาน / ฟอร์มพิมพ์ออกมา (เลข field ตาม FD เช่น 17 PC · 18 RI ของ RPT-1)
- ④ Checks — ✓ ผูกยอดได้ · ✗ ผิดกฎ / defect · ? รอคำตัดสิน (D2 / D3 / D4) — ห้ามพูดเหมือนเป็นข้อเท็จจริง
STDstandard SAP
BPBlueprint / LC concept
SYSเห็นในระบบ / FUT
AGREEDตกลงแล้ว
INFERอนุมาน — verify
TBCยังเปิด
1
Split lines — payment เดียวแตะหลาย Profit Center
AGREED
TAX-RPT-1 · TKT-01 (ตกลง 3-Sep) — เอกสาร WHT ที่ document splitting แตก WIT ออกเป็นหลายบรรทัดตาม PC ต้องออกรายงาน หนึ่งแถวต่อ WIT line ไม่ใช่แถวเดียวที่หยิบ PC แรกมา
Model 1 · Split-line engineRPT-1FRM-1ENH-1TKT-01
1Scenario
Preset
WT base ที่ยื่น (THB)
มุมมอง
Payment มี vendor
2ACDOCA · RLDNR 0L · KTOSL WIT document splitting
CoCd TH01Doc 2004330988 (sample)WHT type 5A · PND54amounts = HSL (THB)
| BUZEI | KTOSL | PRCTR | RECID | HSL | ใช้ทำแถว? | |
|---|
3RPT-1 output · ฝั่ง PND54
ZTAXB_R01output group R03 / ALV
| # | 3Doc no. | 17PC | 18RI | WT base | WT amt | WIT ratio | 30VAT36 |
|---|
4Checks
- กฎที่ตกลง AGREED: หนึ่งแถวต่อ ACDOCA WIT line ที่
HSL ≠ 0 (ไม่ต่อ comma) · WHT ของแถว = HSL ของบรรทัดนั้น (ไม่ prorate) · base prorate ตาม WIT ratio แถวสุดท้ายรับเศษ เพื่อให้ยอดรวมผูกกับยอดที่ยื่น · payment หลาย vendor ไม่เข้า PC split
- สิ่งที่เห็นตอน FUT SYS: WHT@payment หยิบ ACDOCA WIT record แรก แม้เป็น 0.00 — 2004328305 (5A/39, 3 WIT lines 90/45/15) · 2004327460 (USD, WIT 10/5) · ส่ง expected-result workbook แล้ว
- ยังเปิด TBC: คอลัมน์ VAT36 (fields 23–34) บนแถว split + partial payment → D2 (team lead) · หลังแก้ split ต้องรัน variant เดียวกันผ่าน FRM-1 และ ENH-1 แล้วเทียบ WHT ต่อ PC
2
Alternative payee — ใครคือ “ผู้ถูกหัก” บน 50 ทวิ และใบแนบ
SYS
TAX-FRM-1 defect 21-Sep — ถ้าเอกสารมี payee ของตัวเอง (BSEC) แต่ใบแนบ ภ.ง.ด.3/53 พิมพ์ข้อมูลจาก BP master ผู้รับ 50 ทวิ กับรายชื่อในแบบยื่นจะเป็น คนละคน — golden thread A พังตรงนี้
Model 2 · Payee resolverFRM-1ZTAXA_F02ENH-1
1Scenario
Preset
เอกสารมี payee ของตัวเอง (BSEC)
BP tax category (DFKKBPTAXNUM)
2Master vs document
BP mastervendor VTEST0001 · “payee in document” = X
BSECone-time / alternative payee data บนเอกสาร STD
3สิ่งที่พิมพ์ออกมา
4Checks
- Certificate ZTAXA_F02 SYS ถูกแก้แล้ว (8-Jul): เลขภาษีผู้ถูกหัก =
BSEC-STCD3 → STCD1 → blank · test vendor VTEST0001 (“payee in document” = X) · specimens 2004325075 / 3641 / 3642 / 3643
- FRM-1 ตอนนี้ SYS: พิมพ์ชื่อ / ที่อยู่ / Tax ID จาก BP master (
DFKKBPTAXNUM, category TH1) แทน payee บนเอกสาร — raise พร้อม specimens · expected = ใช้กฎเดียวกับ certificate INFER ให้ 50 ทวิ = ใบแนบ
- ENH-1 (RD text file) อ่าน payee จากไหน TBC — รัน specimens ชุดเดียวกันผ่าน ENH-1 · defect แยก: เลขลำดับ attachment 070002 vs certificate 070000 (doc 2004325629) · FRM-1 §7.5
3
Payment เดียว clear หลาย invoice — AP voucher ของใคร?
D3
TAX-RPT-1 defect 14-Sep — รายงาน resolve AP voucher ตัวเดียวแล้ว stamp ทุกแถว ฝั่ง VAT36 (fields 19–34) จึงชี้ invoice ผิดใบ · dev fix = loop หา invoice ที่ WITH_ITEM ตรง vendor + WHT type + code · วิธีแบ่ง WHT ยังรอ team lead (D3)
Model 3 · Clearing resolverRPT-1FRM-1ENH-1TC-010..016
1Scenario
Preset
มุมมอง
D3 · แบ่ง WHT ของ payment
2BSAK (AUGBL = payment) ⋈ WITH_ITEM ของแต่ละ invoice
Payment Currency amounts sample · แก้ base / rate ได้
| BELNR (AP voucher) | LIFNR | WITHT | WT_WITHCD | rate % | WT_QSSHB | WT_QBSHB |
|---|
2bWITH_ITEM ของ payment (WHT at payment) — 1 set ต่อ vendor + type + code
| Set | WT_ACCO | type / code | Σ base | Σ invoice WHT | payment WHT (posted) | Δ |
|---|
3RPT-1 output
ZTAXB_R01
| # | Set | 19AP voucher | match key | 20WT base FC | 21WT amt FC | WHT ในแถว (D3) |
|---|
4Checks
- Defect SYS: 8084322636 (THB, 3 vendors) · 8084322637 (USD, vendor เดียว, 6 invoices รวมเป็น 2 WHT sets) — ทุกแถวได้ AP voucher ใบเดียวกัน
- Dev fix ต่อแถว AGREED (การอ่าน FD ที่ตกลง):
BSAK-LIFNR = WT_ACCO + match WITH_ITEM ของ invoice ด้วย vendor + type + code — loop ไม่ใช่ first hit · steps 20/21 อ่าน WITH_ITEM ของ invoice (accepted 16-Sep)
- D3 TBC: ทางเลือก A ทำให้แต่ละแถว = WITH_ITEM ของ invoice แต่ยอดรวมอาจไม่ผูกกับ WHT ที่ยื่น · ทางเลือก B ผูกยอดรวมเสมอ แต่แถวอาจต่างจาก invoice ไม่กี่สตางค์ — โมเดลแสดงทั้งสองด้านเพื่อใช้คุยกับ team lead · TC-010..016 ต้องรันบน FRM-1 / ENH-1 ด้วย
4
Realized FX gain / loss — ข้ามสกุล LC1 · LC2 · LC3
BP
บริษัทไทยถือ 3 สกุลพร้อมกัน: LC1 THB · LC2 USD · LC3 USDTH — ตอนจ่าย invoice สกุลต่างประเทศ แต่ละชั้นคำนวณ realized FX แยกกัน และ อาจคนละทิศ · บวก 2 แหล่ง FX เฉพาะ Client: บรรทัด Realized FX (from VAT) และ WHT FX adjustment (ENH-2)
Model 4 · FX engine (invoice → payment)GL-ENH-1ENH-2RPT-1LC concept
1Scenario
Preset
Invoice currency
Payment currency
Segment (ตัดสิน LC3)
Net amount (doc currency)
WHT at payment
WHT rate %
1bTCURR (sample rates — แก้เป็นของจริงได้)
2Invoice (FB60 / MIRO) · posting date
CoCd TH01Invoice · LC1 THB · LC2 USD · LC3 USDTH
| Line | KTOSL / GL | LC1 rule | DC | LC1 THB | LC2 USD | LC3 USDTH |
|---|
3Payment (F110 / F-53) · clearing
Payment · clearing line = historical · KDF = realized
| Line | KTOSL / GL | rate | DC | LC1 THB | LC2 USD | LC3 USDTH |
|---|
4Checks
- กฎ 1 — สกุลเอกสาร BP: THB doc → LC1 = doc amount · USD doc → LC2 = LC3 = doc amount · FC อื่น → แปลงทั้งสามชั้น โดย LC2/LC3 เป็น cross rate ผ่าน THB =
DC × ZTH(FC:THB) ÷ ZTH(USD:THB)
- กฎ 2 — segment ตัดสิน LC3 BP: CIT_TH → LC3 = LC2 · PITA / PSC / MTJDA → PITB (ฝั่งซื้อ) รายเดือน · ตัวหาร PITM แม้ฝั่งซื้อ TBC · กฎ 3 — ประเภทบรรทัด: expense / AP = M @ posting date · input VAT = B @ document date −1 · WHT at payment = M @ posting date · clearing = historical
- Realized FX ตอน clear STD: บรรทัด vendor ใน payment ใช้ค่า LC เดิม (historical) ส่วน bank / WHT ใช้ rate วันจ่าย → ส่วนต่างโพสต์เป็นบรรทัด
KDF แยกต่อสกุล (DC = 0) · บัญชี AP realized FX ของ Client (OBA1) TBC · rate ของบรรทัด bank INFER
- Realized FX (from VAT) BP: LC1 เท่านั้น = DC × rate(doc date −1) − DC × rate(posting date) →
A490X035 (Option 1, non-operating) · error F5A49 ผ่าน FB60/FB70 ยังเปิดกับ SAP · ENH-2: GL post WHT ด้วย M @ T แต่สรรพากรใช้ BOT ของวันทำการก่อนหน้า (paper T-1 · e-WHT T-2) → เอกสาร SW ปรับ A212X021 · realized FX ฝั่ง direct tax A490X034 (ทิศ Dr/Cr INFER) · ดู LC rules · ENH-2
5
รายงาน Profit Center × Recovery Indicator — แบบที่ผูกยอดได้
SYS
“PC + RI filter / PC + RI on output” คือ key change ของ RPT-1, RPT-2, FRM-1 และ ENH-1 พร้อมกัน — โมเดลนี้ใช้ข้อมูล Oman VAT (CoCd OM01, OMR 3 ทศนิยม) รวม doc 3004322020 จาก FUT จริง เพื่อดูว่าการกรอง “ระดับบรรทัด vs ระดับเอกสาร” และ “Total” เปลี่ยนตัวเลขยังไง
Model 5 · PC × RI report engineRPT-2RPT-6RPT-1OBJ1
1Selection screen
Profit Center (ว่าง = ทั้งหมด)
Recovery Indicator (ว่าง = ทั้งหมด)
ระดับการกรอง
Total / Balance
2ALV output · line items
ZTAXA_R04 · RPT-2CoCd OM01OMR · 3 dp · sign SAP-style
| Doc | Ln | Tax | PRCTR | RECID | Venture | Base | Tax amt | src |
|---|
3Pivot · tax amount by PC × RI (หลังกรอง)
4Checks · control ของ OBJ1
- Bug 2 (17-Sep, เจอบน RPT-6 ก่อน) SYS: กรอง PC แล้ว line items ถูกกรองต่อ tax line แต่ Total / Balance รวมทั้งเอกสาร เมื่อมีบรรทัดใดตรง · repro doc 3004322020 (O1; C_PC29 952.379- / 47.619- + N_PC38 1,142.859- / 57.143-; ทั้งใบ 2,095.238- / 104.762-) · บน RPT-6 Total ขับ clearing posting → ต้องแก้เหมือนกัน
- Key risk OBJ1 SYS: เอกสาร mixed-RI อาจหายจาก ทุก bucket ของ RI filter = compliance risk → control คือ
Σ(buckets) = unfiltered total · ฝั่ง RPT-1 filter PC/RI ลบที่ ระดับเอกสาร ใน i01_select_wt_data — ความหมาย “any / all” ต้องอ่านโค้ดยืนยัน TBC
- RI ของ Client BP: BR, BN (operated) · NR (non-op) · NN · CR, CN (cutback) · CP (corporate) · master
T8JJ · RI ของ doc 3004322020 ใน evidence ไม่ได้ระบุ — โมเดลใส่ CP / NN ให้ INFER · PC ของเอกสาร multi-PC (tax line vs document) และ total ไม่กรองจาก BSET หรือ Σ ACDOCA → D4 (project lead)
6
Regression map — แก้ตรงไหน ต้องรันอะไรซ้ำ
ZTAXB_R01 / RFIDYYWT เป็น selection screen เดียว — output group เป็นตัวตัดสิน output · bug PC/RI ใน selection จึงโผล่ใน RPT-1, FRM-1, ENH-1 และ FRM-3 พร้อมกัน SYS
| ถ้าเปลี่ยน… | โมเดล | รันซ้ำ | เช็กอะไร |
|---|
| Split lines (TKT-01) | 1 · 5 | RPT-1 → FRM-1 → ENH-1 ด้วย variant เดียวกัน | WHT ต่อ PC เท่ากันทุก output · Σ แถว = ยอดยื่น |
| Multi-invoice fix + D3 | 3 | TC-010..016 บน RPT-1, FRM-1, ENH-1 | AP voucher ต่อแถว · Σ WHT ต่อ set = WITH_ITEM payment |
| Alternative payee บน FRM-1 | 2 | FRM-1 + ZTAXA_F02 + ENH-1 · specimens 2004325075 / 3641 / 3642 / 3643 | ชื่อ / Tax ID บนใบแนบ = 50 ทวิ |
| LC rules / ENH-2 / GL-ENH-1 | 4 | ENH-2 ก่อน แล้ว RPT-1 (TC-006/007) · SE16N layout /LC_CHECK | LC1/LC2/LC3 ต่อบรรทัด · WITH_ITEM = GL (8084322568) |
| PC / RI filter (i01) · Total logic | 5 | RPT-1, FRM-1, ENH-1, FRM-3 · RPT-2 + RPT-6 คู่กัน | Σ(buckets) = unfiltered total · Total = Σ บรรทัดที่แสดง |
✓
Self-check — อธิบายได้ใน 30 วินาทีไหม
1. เอกสาร WHT มี WIT 3 บรรทัด 5,000 / 5,000 / 5,000 base 100,000 — RPT-1 ควรออกกี่แถว base เท่าไร?
3 แถว WHT = HSL ของแต่ละบรรทัด · base 33,333.33 / 33,333.33 / 33,333.34 (แถวสุดท้ายรับเศษ) ยอดรวมผูก 100,000.00 · ถ้ามีบรรทัด HSL 0.00 ให้ข้าม
2. ทำไม FRM-1 ต้องใช้ BSEC แทน BP master เมื่อเอกสารมี payee?
คนที่ถูกหักจริงคือ payee บนเอกสาร — certificate ZTAXA_F02 ใช้ BSEC-STCD3 → STCD1 → blank แล้ว ถ้าใบแนบใช้ BP master ชื่อ / Tax ID ในแบบยื่นจะไม่ตรง 50 ทวิ
3. D3 ทางเลือก A กับ B ต่างกันตรงไหน?
A ใช้ WT_QBSHB ของแต่ละ invoice — แถวตรง invoice แต่ยอดรวมอาจห่าง WHT ที่ post ตอนจ่ายด้วยเศษปัด · B prorate WHT ของ payment ตาม base — ยอดรวมผูกเสมอ แต่บางแถวต่างจาก invoice ไม่กี่สตางค์ · ยังไม่ตัดสิน (team lead)
4. จ่าย invoice EUR จากบัญชี USD — ทำไม LC2 realized FX ไม่เหมือนจ่ายด้วย EUR?
เอกสาร USD → LC2 = LC3 = doc amount (กฎ 1) ค่า LC2 ของบรรทัด bank จึงเท่ากับยอด USD ที่จ่ายจริง ส่วนเอกสาร EUR ใช้ cross rate ZTH(EUR:THB) ÷ ZTH(USD:THB) · บรรทัด vendor ใช้ historical ทั้งสองแบบ
5. control อะไรพิสูจน์ว่า RI filter ไม่ทำเอกสารหาย?
รันทีละ RI แล้วรวมทุก bucket ต้องเท่ากับรันแบบไม่กรอง — Σ(buckets) = unfiltered total · ถ้าน้อยกว่า = เอกสาร mixed-RI หาย ถ้ามากกว่า = นับซ้ำ