TAX-RPT-1 Deep-Dive (จาก FD) · SAP FI-Tax Knowledge Lab

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

สรุปแบบ เข้าใจง่าย จาก FD ตัวจริง — รายงานนี้เอา PND54 (WHT จ่ายไปต่างประเทศ) มากระทบยอดกับ VAT36 / PP36 (reverse-charge VAT) ที่มักเกิดจากธุรกรรมเดียวกัน (จ่ายค่าบริการต่างประเทศ) · FD เขียนว่าใช้ standard report S_P00_07000134 แล้วเพิ่ม field ในจอเลือก — ในระบบจริงคือ ZTAXA_R01 = enhanced copy ของ RFIDYYWT เรียกด้วย T-code ZTAXB_R01 และ design หลายข้อถูกตกลงใหม่หลัง FD v0.1 (ดู §2.5)

Key Takeaways

FD: standard S_P00_07000134 + 2 field ใน Further Selections (Profit Center & Recovery Indicator) · ระบบ: ZTAXB_R01 → ZTAXA_R01 (Z-copy ของ RFIDYYWT) · output group R03
Step 28 ของ FD v0.1 ถูกแทน ด้วย design 3-Sep (TCURR type M · VAT36 FC → USD → THB) และ multi-PC = split lines (TKT-01) — ดู §2.5
แปลงค่าเงินตาม Section 9 — 3 กฎ: จ่าย FC→ใช้สกุลจ่าย · invoice THB→ไม่แปลง · invoice FC จ่าย THB→ใช้สกุล invoice
ฝั่ง VAT36 (invoice) ใช้ rate T-1 (posting date ของวันทำการก่อนหน้า) จาก TCURR-UKURS
ลำดับก่อนรัน: AP posting → ZTAXA_R03 (WHT adj) → month-end ZTAXA_R02 (VAT36) → รัน recon
Join แกนหลัก: เอกสารจ่าย → BSAK (clearing) → invoice → BKPF/BSET/ACDOCA/WITH_ITEM

🧪 ความรู้จากการทำ FUT จริง (31.07–02.08.2026): ID ที่ยืนยันแล้ว — T-code ZTAXB_R01 · main program SAPLZTAXA_R01 · engine RFIDYYWT · output group ทางการ R03 (FD ไม่ระบุ) · CoCd TH01 · รายงาน read-only run ได้เสมอ · defect 3 ตัว + ระบบ unit test 9 TC + ทักษะ post/อ่าน document ทั้งหมดอยู่ที่ TAX-RPT-1 FUT Field Notes →

Object Overview

WRICEF ID	`TAX-RPT-1`
Title	Reconciliation Report for PND.54 (including profit center)
T-code / Main program	`ZTAXB_R01` / `SAPLZTAXA_R01` (ยืนยันจาก FUT)
Standard base / engine	`S_P00_07000134` · `RFIDYYWT` (Generic WHT Reporting)
Output group	`R03` — Attachment P.N.D. 3/53/54 (ทางการ · FD ไม่ระบุ)
Company code	`TH01` · TH
Module	SAP Finance — Tax Accounting
Description	สร้างรายงานกระทบยอด PND.54 และ VAT PP36
Type	Report
Nature	Retrofit from ECC (Change)
Business Process	`01.01.07.03` Withholding Tax
Complexity / Priority	Medium · P1
Business Owner	Client Tax team
Geography	Thailand เท่านั้น

Related docs: BPE = [S/4 Program]_D2.1_Blueprint_01.01.07 Tax Accounting · Previous FS = 65_undefined PND54 Attachment

วัตถุประสงค์ + กฎแปลงค่าเงิน (Section 9)

รายงานเอา WHT (ฝั่ง PND54) มาเทียบกับ VAT36 (ฝั่ง invoice) — ต้องแปลง FC เป็น THB ตามมาตรา 9 ของประมวลรัษฎากร

เข้าใจง่าย ๆ: เวลาจ่ายค่าบริการให้ต่างชาติ มักเกิด 2 ภาระพร้อมกัน — หัก WHT (ยื่น PND54) และตั้ง VAT แทน (VAT36 → PP36) รายงานนี้ดึงทั้งสองฝั่งมาวางคู่กัน + แนบ Profit Center / Recovery Indicator เพื่อตรวจว่ายอดตรงกัน

3 กฎแปลงค่าเป็น THB

Rule 1

Invoice FC + Payment FC

invoice + จ่าย เป็นสกุลต่างประเทศ (USD/EUR/GBP) → ใช้ สกุลที่จ่าย (payment currency) แปลงเป็น THB

Rule 2

Invoice THB + Payment USD

invoice เป็น THB, จ่ายเป็น USD → ใช้ สกุล invoice (THB) → ไม่ต้องแปลง

Rule 3

Invoice FC + Payment THB

invoice เป็นสกุลต่างประเทศ, จ่ายเป็น THB → ใช้ สกุล invoice แปลงเป็น THB

สรุปกฎ: ถ้าจ่ายเป็นเงินตราต่างประเทศ ให้ยึด สกุลที่จ่าย · ถ้าจ่ายเป็น THB ให้ยึด สกุล invoice · ถ้า invoice เป็น THB อยู่แล้ว = ไม่แปลง

2.5

Design ที่ตกลงหลัง FD v0.1 + สถาปัตยกรรมจริง

FD v0.1 (23/10/2025) ไม่ใช่คำตอบสุดท้าย — ส่วนนี้คือสิ่งที่ ตกลงแล้ว (AGREED) และสิ่งที่ เห็นในระบบ (SYS) · ช่องว่างระหว่าง FD กับ design นี้ต้องปิดด้วย FD v0.2 / CR ก่อน UAT sign-off (G3)

สอง FX columns — ห้ามปน

Column	FD step	Source	Date	Serves
Fx on TaxPmt	22	`BKPF-KURSF` ของ payment ที่ post แล้ว	T	WHT / ภ.ง.ด.54
Fx on Posting date	28	รายงาน lookup `TCURR` เอง	T-1 (≤ fallback)	VAT / ภ.พ.36

InteractiveTCURR date simulator — วันจ่ายวันไหน แต่ละคอลัมน์ใช้ rate ของวันไหน

Payment posting date (T)

Invoice currency

คลิกวันในแถบด้านล่างเพื่อทำเป็น “วันหยุด” (ไม่มี rate ใน TCURR) · เสาร์–อาทิตย์ไม่มี rate อยู่แล้ว

Fx on TaxPmt · step 22

BKPF-KURSF ของ payment ที่ post แล้ว (rate M ล่าสุด ≤ T) → ภ.ง.ด.54

Fx on posting date · step 28

ถ้า code ใช้ exact match

KT ข้อ 3: GDATU = BUDAT − 1 แบบตรงตัว ไม่มี ≤ fallback

Step 28 final (3-Sep-2026)

เลิก ratio approach → TCURR rate type M เท่านั้น · FCURR = สกุล invoice (BSAK-WAERS) → THB · GDATU = วัน posting ของ payment − 1 แบบ ≤ fallback · guard UKURS/FFACT = 0 · 5 ทศนิยม
VAT36 FC → THB สองขั้น (invoice ccy → USD → THB) เขียนเป็นการคูณ rate สองตัว — ใช้กับคอลัมน์ VAT36 เท่านั้น
แถว 5A ใช้ KURSF ของเอกสารตัวเอง (5A ที่ยังไม่จ่าย = provisional) · 5G ใช้ TCURR entry ที่สองก่อนวันจ่าย (T-2 วันทำการ) และการรวมใน R03 ยังรอคำตัดสิน
ผล: VAT36 base ≠ WT base บนแถวที่จ่าย FC — by design · sign: abs(FC) × sign(RC)
Steps 11/12 อ่าน WITH_ITEM ของ payment · steps 20/21 อ่าน WITH_ITEM ของ invoice ตาม FD — accepted 16-Sep (เปลี่ยน = CR)

Multi-PC / multi-invoice

Split lines (TKT-01): 1 แถวต่อ ACDOCA WIT line (HSL ≠ 0) · WHT = HSL ของบรรทัด · base prorate ตาม WIT ratio บรรทัดสุดท้ายรับเศษ · payment หลาย vendor ไม่ split · VAT36 บนแถว split + partial payment ยังเปิด (D2)
Multi-invoice payment (14-Sep, defect เปิด): รายงาน resolve AP voucher ตัวเดียวแล้ว stamp ทุกแถว · การอ่าน FD ที่ตกลง: หนึ่งแถวต่อ invoice ที่ถูก clear ซึ่ง WITH_ITEM ของตัวเอง match vendor + WHT type + code ของแถว payment (loop ไม่ใช่ first hit) · แบ่ง WHT ตาม invoice (WT_QBSHB) หรือ prorate ตาม base — รอ team lead (D3)

สถาปัตยกรรมและจุดที่แถวหายได้ SYS

ชั้น	รายละเอียด
Output group	`R03` ผ่าน `T059ID01` WT_OG_REP_DOC · โค้ดจริงไม่ใช้ `sy-tcode` (เงื่อนไข sy-tcode ถูก comment ทิ้ง) — ส่ง output group ผ่าน memory ID `ZTAXA_R01_OUTPUTGROUP` ก่อนเรียก `ZTAXA_R01_DISPATCHER` (TAX-ENH-7, 03-Aug-2026) · ดู ZTAXA_R01 X-ray
Standard data source	FM มาตรฐานของ RFIDYYWT
TH BAdI	`DELETE_EWHT_DOCUMENTS`
`ZTAXA_R01_I02`	FORM `check_witht` อ่าน whitelist `ZCAX_P01` param `WHT_TYPE_PND54` · DELETE ไม่มี key GJAHR/BUKRS + เสี่ยง sort ของ BINARY SEARCH — ผู้ต้องสงสัยหลักของ doc `8084322612` (5G/B8) ที่หาย
`ZTAXA_R01_I01`	PC/RI filter ลบที่ ระดับ document ใน `i01_select_wt_data`
Output	`ZTAXA_R01_DISPATCHER` / `ZTAX_PRINT_ALV` (ALV)

FD gaps ที่รู้แล้ว: steps 17/18 (PC/RI จากเอกสาร WHT) บอก KTOSL = WIT แต่ไม่บอกวิธีเลือกบรรทัด · step 34 (RI ของ invoice) บอก KTOSL = XST · เคยสรุปว่า step 33 “ไม่มี KTOSL” — ถอนแล้ว (เงื่อนไขอยู่หน้าถัดไปของ FD) · FD ไม่ระบุ output group (R03 ได้รับการยืนยันด้วยวาจา)

ทั้งหมดนี้เป็น locked decisions — รายการเต็มและคำถามที่รอคำตัดสินอยู่ที่ Decisions & Open Points · หลักฐาน FUT อยู่ที่ RPT-1 testing

Processing Flow

ต้องรันตามลำดับ — รายงานจะครบก็ต่อเมื่อ 2 โปรแกรมก่อนหน้ารันแล้ว

1 · Posting

AP Invoice Posting

post VAT36 (บางเคสมีแต่ PND54) · จ่ายด้วย PND54 WHT code

2 · WHT Adj

ZTAXA_R03

ปรับ WHT (FX adjustment)

3 · VAT36 (month-end)

ZTAXA_R02

รันทุก payment doc → สร้าง VAT liability line items (WRICEF TAX-ENH-3)

4 · Recon

S_P00_07000134

รายงานกระทบ PND54 ↔ VAT36 (+ PC)

posting program report

Ref	ขั้นตอน	รายละเอียด
01	AP Invoice Posting	ลง AP invoice พร้อม VAT36 · บางเคส invoice ไม่มี VAT36 แต่มี PND54 · การจ่ายใช้ PND54 WHT code
02	Run WHT Adjustment	รัน `ZTAXA_R03` เพื่อปรับ WHT
03	Generate VAT36	หลังปิดงวด รันทุก payment doc ด้วย `ZTAXA_R02 – VAT36` → สร้าง VAT liability line items สำหรับยื่น
04	Reconciliation Report	รันรายงานกระทบยอด PND54 ↔ VAT36 เพื่อตรวจความถูกต้อง/ครบถ้วน

ชื่อโปรแกรมในเอกสารไม่นิ่ง: flow เขียน ZTAXA_R03 แต่ TC-006 เขียน ZTAXA_E02 · field 29 เขียน ZTAXA_R02 (WRICEF TAX-ENH-3) ส่วน flow เขียน ZTAXA_R02 TODO: verify ชื่อโปรแกรมที่ถูกต้องกับทีม

Program & Selection Screen

FD: ใช้ standard แล้วเพิ่ม 2 field ใต้ปุ่ม “Further Selections” · ระบบ: ZTAXA_R01 Z-copy (ดู §2.5)

Report ใช้ S_P00_07000134 (Generic Withholding Tax Reporting) แสดงผลแบบ ALV · Data source = withholding transactions ใน SAP · Module = FI-TAX, FI-AP

Field ที่เพิ่ม	คุณสมบัติ	Validation
Profit Center	Alphanumeric · Optional · From/To/Multiple	Validate กับ `CEPC` (field `PRCTR`)
Recovery Indicator	Alphanumeric · Optional · Multiple	ดึงจาก `T8JJ` (field `RECID`) · validate ด้วยคู่ company code (`BUKRS`) + `RECID` ใน `T8JJ`

Logic การ Join ข้อมูล (แกนหลัก)

เข้าใจอันนี้อันเดียว แล้วตาราง 34 fields จะอ่านง่ายขึ้นมาก

ไอเดีย: เริ่มจาก เอกสารการจ่าย (PND54) → ใช้เลขเอกสารไปหา invoice ผ่านตาราง BSAK (เอกสาร clearing) → แล้วดึงข้อมูลฝั่ง VAT36 จากตารางต่าง ๆ ของ invoice นั้น

เริ่ม · Payment

เอกสารจ่าย (PND54)

Doc No · Company Code · Fiscal Year

เชื่อม · Clearing

BSAK

AUGBL = เลขเอกสารจ่าย → คืน BELNR (invoice) ที่ BELNR ≠ AUGBL

ดึง · Invoice (VAT36)

BKPF

FX rate (KURSF) · currency (WAERS) · posting date (BUDAT)

BSET

VAT36 base (FWBAS) · amount (FWSTE)

ACDOCA (0L)

Profit Center · Recovery Ind · VAT code (KTOSL = VST/XST)

WITH_ITEM

WT base (WT_QSSHB) · WT amt (WT_QBSHB)

เกร็ด KTOSL (Transaction key ใน ACDOCA): WIT = withholding · VST = input VAT · XST = (ใช้ดึง PC/Recovery ฝั่ง invoice) · rate/ชื่อ WHT มาจาก T059Z · rate แปลงค่ามาจาก TCURR

Report Columns ทั้ง 34 (แยก 2 ฝั่ง)

ส่วนใหญ่ “Same as ECC” — ที่น่าสนใจคือ field ที่มี logic ดึงข้ามตาราง (ไฮไลต์ด้านล่าง)

ฝั่งจ่าย — Payment Document (PND.54) · fields 1–22

#	Field	ความหมาย / ที่มา
1	Cert. No	เลขที่หนังสือรับรอง — same as ECC
2	Business Place	สาขาภาษี — same as ECC
3	Document No.	เลขเอกสารการจ่าย (แกนอ้างอิง) — same as ECC
4	Doc WHT FX ADJ	เอกสารปรับ FX ของ WHT: `BSEG` (KTOSL=`WIT`, ตรง BELNR/GJAHR/BUKRS ของขั้น 3) → คืน `AUGBL` (clearing doc)
5–14	WHT Code / Type / Posting date / Recipient Type / Address / Payment Curr. / WT base-amt / WT amt in RC / Bus Area / Payment Date	same as ECC
15	WHT rate	`T059Z` (LAND1=`TH`, WITHT=type, WT_WITHCD=code) → `QSATZ`
16	WHT Descp	`T059Z` เงื่อนไขเดียวกัน → `TEXT40` (ชื่อ)
17	Profit Center	`ACDOCA` (RLDNR=`0L`, KTOSL=`WIT`, ตรงเอกสารขั้น 3) → `PRCTR`
18	Recovery Indicator	`ACDOCA` (0L, KTOSL=`WIT`) → `RECID`
19	AP Voucher No.	ตัวเชื่อมไป invoice: `BSAK` (AUGBL=เลขจ่ายขั้น 3) → `BELNR` ที่ BELNR ≠ AUGBL (+ BUKRS, GJAHR)
20	WT base/amt FC	`WITH_ITEM` (ตรง BUKRS/GJAHR/BELNR ของขั้น 19) → `WT_QSSHB`
21	WT amt in FC	`WITH_ITEM` → `WT_QBSHB`
22	Fx. On TaxPmt	`BKPF` (เอกสารจ่ายขั้น 3) → `KURSF` (exchange rate)

ฝั่ง invoice — Invoice Document (VAT 36) · fields 23–34

#	Field	ความหมาย / ที่มา
23	AP Voucher No.	= ขั้น 19 (`BSAK-BELNR`)
24	Posting Date	`BKPF` (BELNR=invoice ขั้น 19) → `BUDAT`
25	VAT36 base/amt FC	`BSET` (invoice ขั้น 19) → `FWBAS` (tax base)
26	VAT36 amt FC	`BSET` → `FWSTE` (amount)
27	Invoice doc curr	`BKPF` → `WAERS` (สกุลเงิน invoice)
28	Fx on Posting date	LC1 ใช้ rate วันทำการก่อนหน้า (T-1) → `TCURR-UKURS` ที่ `GDATU` = `BUDAT` − 1 · เลือกสกุลตาม 3 กฎ Section 9
29	VAT36 Doc No.	ดึงจากโปรแกรม `ZTAXA_R02` (WRICEF `TAX-ENH-3`) ด้วย AP voucher no + company code + fiscal year
30	VAT36 base (THB)	= `BSET-FWBAS` (ขั้น 25) × `TCURR-UKURS` (ขั้น 28)
31	VAT36 PmtAmt (THB)	= `BSET-FWSTE` (ขั้น 26) × `TCURR-UKURS` (ขั้น 28)
32	VAT code	`ACDOCA` (0L, KTOSL=`VST`) → `MWSKZ`
33	Profit center	`ACDOCA` (0L, KTOSL=`XST`) → `PRCTR`
34	Recovery Indicator (Invoice)	`ACDOCA` (0L, KTOSL=`XST`) → `RECID`

RC = Reporting Currency · FC = Foreign Currency · fields 5–14 เป็น “same as ECC” จึงย่อรวมไว้

Test Scenarios (Given / When / Then)

9 เคสจาก FD จริง + validation อีก 2 · จัดกลุ่ม: สกุลเงิน (FX) · selection · dependency · edge/negative

Badge: FD = จากเอกสารจริง · PROPOSED = ผม derive ต้อง verify

ก่อนทดสอบ (precondition): ต้องมี WHT ของ recipient type “54” posted แล้ว · invoice ต้อง post ด้วย VAT PP36 tax code (บางเคสอาจมีแต่ PND54)

TC-001FX · จ่าย FCFD

GivenVendor invoice + VAT36 + PND54 code เป็น FC (invoice EUR/GBP) และจ่ายเป็น USD Whenรันรายงาน reconciliation Thenใช้ payment currency แปลงเป็น THB · base amounts reconcile

TC-002FX · THB ล้วนFD

Giveninvoice + จ่าย เป็น THB ทั้งคู่ Whenรันรายงาน Thenใช้สกุล invoice (THB) · ไม่ต้องแปลง

TC-003FX · invoice THBFD

Giveninvoice THB, จ่าย USD Whenรันรายงาน Thenใช้ document currency (THB) · base amounts reconcile

TC-004FX · จ่าย THBFD

Giveninvoice USD, จ่าย THB Whenรันรายงาน Thenใช้ document currency (USD) แปลงเป็น THB · base amounts reconcile

TC-005SelectionFD

Givenธุรกรรมหลาย Profit Center / Recovery Indicator Whenใส่ Profit Center + Recovery Indicator ในจอเลือก Thenรายงานเลือกรายการตาม PC & RI ที่ระบุ

TC-006DependencyFD

Givenมีการสร้าง WHT tax adjustment ด้วย ZTAXA_E02 (= ZTAXA_R03) Whenรัน adjustment ก่อน recon Thencolumn Doc WHT FX Adj มีค่าในรายงาน

TC-007DependencyFD

Givenมีการรัน ZTAXA_R02 (VAT36) Whenรัน ก่อน recon Thencolumn VAT36 Doc No. มีค่าในรายงาน

TC-008Edge · PND54 onlyFD

Giveninvoice มีแต่ PND54 ไม่มี VAT36 (invoice USD, จ่าย THB) Whenรันรายงาน Thencolumn ฝั่ง VAT36 ต้องว่าง

TC-009NegativeFD

Givenมีแต่ VAT36 ไม่มี PND54 Whenรันรายงาน Thenรายการ ต้องไม่ ปรากฏในรายงาน

TC-010Selection · validateProposed

Givenใส่ Profit Center ที่ไม่มีใน CEPC ของ company code นั้น Whenยืนยันในจอเลือก Thenvalidation ไม่ผ่าน (ตรวจกับ CEPC-PRCTR)

TC-011Selection · validateProposed

Givenใส่ Recovery Indicator ที่ไม่ valid สำหรับ company code (ตาม T8JJ) Whenยืนยันใน Further Selections Thenvalidation ไม่ผ่าน (ตรวจคู่ BUKRS + RECID ใน T8JJ)

Usage & Roles

Frequency	Monthly · Ad Hoc
Trigger	Manual execution (T-code → list output)
Volume	~800–1,000 records
Output	ALV · Online + File Download (Summary + Detail)
Roles (display)	Accountant · Tax Accountant · AP Accountant · Business Analyst
Error handling	ไม่มี exception ใหม่ (No new exception)

8.5

พี่น้องบนโปรแกรมเดียวกัน — TAX-FRM-1 & TAX-ENH-1 (ของซีทั้งคู่)

3 objects ของซีนั่งอยู่บน selection screen เดียวกัน (+ FRM-3 ของเพื่อนร่วมทีม)

ทำไมส่วนนี้สำคัญ: ซีเป็นเจ้าของ ทั้ง RPT-1, FRM-1 และ ENH-1 ซึ่งใช้ wrapper / filter เดียวกัน — เวลาแก้ selection screen หรือ logic การกรอง ต้อง regression ทั้งสามตัว (และ FRM-3) และเวลารายงาน defect ต้องระบุให้ชัดว่าพังที่ ALV / ฟอร์ม / ไฟล์

ตัวเรียกร่วม	`ZTAXB_R01` → `ZTAXA_R01` (Z-copy ของ RFIDYYWT / Generic Withholding Tax Reporting)
Field ที่เพิ่มร่วมกัน	Profit Center (validate `CEPC-PRCTR`) · Recovery Indicator (validate `T8JJ-RECID` คู่กับ `BUKRS`) — ทั้ง 3 objects ใช้กติกาเดียวกันเป๊ะ
Output group	`R03` คือประตูที่เรียก ฟอร์มใบแนบของ TAX-FRM-1 — ตรงกับที่คุณเห็นตอน FUT

Object	Output	WHT Type ที่ครอบคลุม	เจ้าของ
`TAX-RPT-1`	ALV — recon ภ.ง.ด.54 ↔ ภ.พ.36	ฝั่ง 54 (`5A` / `5D`)	★ คุณ
`TAX-FRM-1`	Adobe Form — ใบแนบ PDF	`3A–3F` (ภ.ง.ด.3) · `4A–4F` (53) · `5A`,`5D` (54)	★ ซี
`TAX-ENH-1`	DMEEX — text file e-Filing	`1A–1E` · `2A` · `3A–3F` · `4A–4F`	★ ซี

ข้อสังเกตที่ทำให้เห็นภาพทั้งกระบวนการยื่นภาษี:

ภ.ง.ด. 54 มี ใบแนบ (FRM-1) และ รายงานกระทบยอด (RPT-1) แต่ ไม่มี text file
ภ.ง.ด. 1 / 1ก / 2 / 2ก มี text file (ENH-1) แต่ ไม่มีใบแนบใน FRM-1
ภ.ง.ด. 3 / 53 มีครบทั้ง ใบแนบ + text file

Dependency ที่ FD ของ FRM-1 เขียนไว้ตรง ๆ: “Dependency on WRICEF TAX-RPT-1 to execute the report” → ถ้า RPT-1 ยังมี defect ค้าง FRM-1 ก็เทสต่อไม่ได้ — ทั้งสองเป็นของซี จึงต้องวางลำดับ FUT เอง (RPT-1 ก่อน) · กฎการแบ่งยอดต่อ PC ของ FRM-1 ต้องใช้คำตัดสินเดียวกับ TKT-01

→ เปิด TAX-FRM-1 deep-dive · เปิด TAX-ENH-1 deep-dive · SE16N — วิธีพิสูจน์ข้อมูลด้วยตัวเอง

Self-check

ตอบในใจก่อนกดเฉลย — โฟกัสจุดที่ออกสอบ/ทดสอบบ่อย

1. TAX-RPT-1 ใช้โปรแกรมอะไร และเพิ่ม field อะไรในจอเลือก?

ดูเฉลย

T-code ZTAXB_R01 → ZTAXA_R01 (Z-copy ของ RFIDYYWT / S_P00_07000134 ตามที่ FD อ้าง) · เพิ่ม Profit Center (validate กับ CEPC) และ Recovery Indicator (จาก T8JJ) ใต้ Further Selections

2. Invoice เป็น USD จ่ายเป็น THB — ใช้สกุลไหนแปลงเป็น THB?

ดูเฉลย

ใช้ สกุล invoice (USD) แปลงเป็น THB (Rule 3 / TC-004)

3. ฝั่ง VAT36 (invoice) ใช้ rate ของวันไหน และจากตารางใด?

ดูเฉลย

Posting date T-1 (วันทำการก่อนหน้า) · จาก TCURR-UKURS ที่ GDATU = BUDAT − 1

4. ต้องรันโปรแกรมใดก่อน recon จึงจะได้ column WHT FX Adj และ VAT36 Doc No.?

ดูเฉลย

ZTAXA_R03 (WHT adj → Doc WHT FX Adj) และ ZTAXA_R02 (VAT36 → VAT36 Doc No.)

5. เชื่อมเอกสารจ่ายไป invoice ผ่านตารางอะไร?

ดูเฉลย

BSAK — AUGBL (clearing) = เลขเอกสารจ่าย แล้วคืน BELNR (invoice) ที่ BELNR ≠ AUGBL