TAX-ENH-1 — Text file PND1/1A/2/2A/3/53 (e-Filing RD)

← หน้ารวม (Hub) My 5 WRICEFs →

Object นี้คือ “ตัวออกไฟล์ e-Filing” — ไม่ใช่รายงานให้คนอ่าน แต่เป็น text file ที่กรมสรรพากร (RD) อ่าน สร้างจาก DMEEX format tree 6 ต้น (ต้นละ 1 แบบยื่น) เกาะอยู่บน standard program Generic Withholding Tax Reporting เดียวกับที่ TAX-RPT-1 และ TAX-FRM-1 ใช้ delta ของ S/4HANA คือ Profit Center + Recovery Indicator ที่ทำให้ 1 การรัน แตกออกเป็นหลายไฟล์

Business process

01.01.07.03

Withholding Tax

Volume

> 1,000 / เดือน

Monthly + Ad Hoc

Trigger

Manual execution

ไม่มี batch/event

🔗 อ่านคู่กัน: TAX-RPT-1 (โปรแกรมแม่ · PND54↔VAT36) · TAX-FRM-1 (ใบแนบ PDF ของ ภ.ง.ด. 3/53/54) · Statutory Filing Guide (แบบไหนยื่นอะไร) · SE16N (วิธีพิสูจน์ข้อมูลก่อน/หลังรัน)

Key Takeaways — จำ 6 ข้อนี้พอ

ตัวชี้ขาดว่าบรรทัดไหนคือ WHT = ค่าคงที่ข้อความ WIT (Withholding tax transaction line-item identifier)
WHT Type บอกว่าเป็น “ภาษีอะไร” → Recipient Type ยืนยัน “ยื่นแบบไหน” → WHT Code ระบุ “ประเภทเงินได้ในช่อง 5”
DMEEX 6 ต้น = 6 แบบยื่น · ใช้ EXIT ร่วมกัน 2 ตัวสำหรับ ฐานภาษี และ ภาษีหัก
Delta S/4 = Profit Center (validate CEPC-PRCTR) + Recovery Indicator (validate T8JJ-RECID คู่กับ BUKRS)
ไม่ว่าจะเลือกอะไร ไฟล์ยังแยกตาม Business Place (สาขา) เสมอ — เพราะ RD ยื่นเป็นรายสาขา
เอกสารกลับรายการ (reversal) ต้องไม่ออกไฟล์ — นี่คือ TC-007 และเป็นบั๊กคลาสสิกของงานตระกูลนี้

ภาพรวม — object นี้ทำอะไร และอยู่ตรงไหนของ process

Enhancement (ไม่ใช่ Report) ที่ต่อยอด standard program เพื่อ “พ่นไฟล์” ให้ RD

ในกระบวนการยื่นภาษีหัก ณ ที่จ่ายของไทย งานมี 3 ชิ้นที่ต้องออกมาพร้อมกันทุกเดือน — (1) ตัวแบบยื่น (ภ.ง.ด.) (2) ใบแนบ (attachment) และ (3) ไฟล์ e-Filing ที่อัปโหลดเข้าระบบ RD TAX-ENH-1 รับผิดชอบชิ้นที่ 3 สำหรับ 6 แบบ คือ ภ.ง.ด. 1, 1ก, 2, 2ก, 3 และ 53 (ภ.ง.ด. 54 ไม่อยู่ใน object นี้ — 54 เป็นเรื่องของ TAX-RPT-1 / TAX-FRM-1)

FB60 / MIRO / F-53
ตั้งหนี้–จ่ายเงิน มี WHT → WITH_ITEM + ACDOCA
KTOSL = WIT → ZTAXB_R01
Generic WHT Reporting → DMEEX tree
ZWHTFILE_* → .txt ต่อสาขา
อัปโหลดเข้า RD

ทำไมต้องเป็น Enhancement ไม่ใช่ Report

โครงไฟล์อยู่ใน config ไม่ใช่โค้ด — DMEEX (Extended Data Medium Exchange Engine) ให้ maintain mapping/attribute/constant/condition ผ่าน format tree ได้ ไม่ต้องแก้ ABAP ทุกครั้งที่ RD เปลี่ยน layout
ตัวเรียก (driver) เป็น standard — Generic Withholding Tax Reporting เป็นตัวอ่าน WITH_ITEM อยู่แล้ว งานที่เหลือคือ “ต่อท่อ” ให้ไปออก DMEEX ตัวที่ถูก
ส่วนที่ DMEEX ทำไม่ได้ (เช่น รวมยอดต่อ partner ของ ภ.ง.ด.1ก และการ sort) ถึงจะไปอยู่ใน ABAP enhancement ZTAXA_E01

มุมมอง consultant: เวลามีคนถามว่า “ทำไม ENH-1 เป็น Medium ไม่ใช่ Complex ทั้งที่มีตั้ง 6 แบบ?” คำตอบคือ ความซับซ้อนกระจายอยู่ใน configuration ไม่ใช่ logic — 6 ต้น DMEEX คือ 6 ชุด mapping, logic จริง ๆ ที่เขียนใหม่มีแค่ 2 เรื่อง (แตกไฟล์ตาม PC / RECID) + 1 enhancement เดิมที่ retrofit มา

กติกาแยกแบบยื่น — WHT Type / Recipient Type / WHT Code

นี่คือหัวใจของ object · จำ 3 ชั้นนี้ได้ = ตอบได้ทุกคำถามว่าธุรกรรมหนึ่งจะไปโผล่แบบไหน

ชั้นที่ 0 — ตัวชี้ว่าเป็นบรรทัด WHT

Field	ค่า	ความหมาย
Text (transaction key)	`WIT`	Withholding tax transaction line-item identifier — ใช้คัดว่าบรรทัดใน `ACDOCA` คือรายการ WHT (field `KTOSL`)

ชั้นที่ 1 — WHT Type (Extended Withholding Tax Type · `WITH_ITEM-WITHT`)

WHT Type	ไปแบบยื่น	ตีความ
`1A` `1B` `1D` `1E`	ภ.ง.ด. 1 และ ภ.ง.ด. 1ก	เงินได้จากการจ้างแรงงาน — บุคคลธรรมดา (เงินเดือน/ค่าจ้าง)
`2A`	ภ.ง.ด. 2 และ ภ.ง.ด. 2ก	เงินได้ประเภทดอกเบี้ย/เงินปันผล ฯลฯ ของบุคคลธรรมดา
`3A`–`3F`	ภ.ง.ด. 3	จ่ายให้ บุคคลธรรมดา (ค่าบริการ/ค่าจ้างทำของ/ค่าเช่า ฯลฯ)
`4A`–`4F`	ภ.ง.ด. 53	จ่ายให้ นิติบุคคล ในประเทศ

ชั้นที่ 2 — Recipient Type (`WITH_ITEM-QSREC`) · ตัวยืนยันซ้ำ

Recipient Type	แบบยื่น
`01`	ภ.ง.ด. 1 / 1ก
`02`	ภ.ง.ด. 2 / 2ก
`03`	ภ.ง.ด. 3
`53`	ภ.ง.ด. 53

ทำไมต้องมีทั้ง 2 ชั้น? WHT Type ผูกกับ config การคำนวณ (ฐาน/อัตรา/จังหวะหัก) ส่วน Recipient Type ผูกกับ ผู้รับเงินและแบบยื่น — ในทางปฏิบัติ master data ที่ผิดจะทำให้ 2 ชั้นนี้ “ไม่ตรงกัน” แล้วรายการจะหายไปจากไฟล์เงียบ ๆ นี่คือจุดที่ต้องไล่ด้วย SE16N บน WITH_ITEM ก่อนโทษโปรแกรม

ชั้นที่ 3 — Withholding Tax Code (`WITH_ITEM-WT_WITHCD`) · ประเภทเงินได้

ใช้กับ	WHT Codes	หมายเหตุ
ภ.ง.ด. 1 / 1ก	`01` `02` `03` `GA` `G1`	รหัสตระกูล G* = กรณีพิเศษ/gross-up
ภ.ง.ด. 2 / 2ก	`04` `05` `06` `07` `08`	—
ภ.ง.ด. 3 และ 53 (ช่อง 5 ของแบบ)	`09` `11` `12` `13` `14` `15` `23` `24` `25` `27` `28` `29` `31` `33` `34` `GB` `GC` `GD` `GE` `G2` `G3` `G4` `G5`	ชุดเดียวกันทั้ง 3 และ 53 — แยกกันด้วย WHT Type/Recipient Type ไม่ใช่ด้วย code

⚠ กับดักที่เจอบ่อย: ถ้า user บอกว่า “ยอดในไฟล์ไม่ครบ” ให้ไล่ย้อน 3 ชั้นนี้ตามลำดับ — (1) บรรทัดนั้นมี KTOSL = WIT ไหม → (2) WITHT อยู่ในลิสต์ของแบบนั้นไหม → (3) QSREC ตรงกับแบบไหม → (4) WT_WITHCD ว่างหรือเปล่า ส่วนใหญ่ 80% หลุดที่ข้อ 3 หรือ 4 ซึ่งเป็น master data ของ vendor ไม่ใช่โค้ด

Selection screen — Generic Withholding Tax Reporting

หน้าจอเดิมของ standard + 2 field ใหม่ใน block “Further Selections”

โครงหน้าจอ (block ต่อ block)

Block	Field	ใช้ทำอะไร
Output Groups	Process Type · Output Groups	เลือกว่าจะให้ออก output อะไร (ไฟล์/ฟอร์ม/list)
Mandatory Selections	Country Key · Reporting Period	`TH` + ช่วงงวดยื่น
General Selections	Company Code · Fiscal Year · Extended WH Tax Type · Extended WH Tax Code · Classic WH Tax Code · Suppliers · Customers	ตัวกรองหลัก — ทุกตัวเป็นช่วง/หลายค่าและ exclude ได้
General Control	(standard)	คุมพฤติกรรมการรัน
Further Selections	Profit Center · Recovery Indicator	← 2 ตัวนี้คือ delta ของ S/4HANA

Validation ของ 2 field ใหม่ (ต้องจำ)

Field	Type	Attribute	Parameter	Default	Validation
Profit Center	`CHAR(10)`	Optional	From, To + multiple selection	None	เช็คกับ `CEPC-PRCTR`
Recovery Indicator	`CHAR(2)`	Optional	Multiple selection	None	เช็คกับ `T8JJ-RECID` โดย ส่งคู่กับ Company Code (`BUKRS`)

ทำไม Recovery Indicator ต้อง validate เป็นคู่กับ BUKRS? เพราะ T8JJ เป็นตาราง JVA (Joint Venture Accounting) — recovery indicator ตัวเดียวกัน อาจมีความหมาย/ใช้ได้ต่างกันในแต่ละ company code การ validate ลอย ๆ จะปล่อยค่าที่ไม่ควรใช้ผ่านเข้ามา แล้วได้ไฟล์เปล่า (ไม่ error แต่ไม่มีข้อมูล) ซึ่งแย่กว่า error

Logic delta — 1 การรัน แตกเป็นกี่ไฟล์

ส่วนเดียวที่เป็น “ตรรกะใหม่” จริง ๆ ในเอกสารฉบับนี้

ถ้าเลือก Profit Center — ให้ generate text file แยกตาม profit center ที่เลือก
ถ้าเลือก Recovery Indicator — ให้ generate text file แยกตาม recovery indicator
ทุกกรณี ไฟล์ยังคงถูกแยกตาม Business Place (สาขา) — ข้อนี้เป็นพฤติกรรมพื้นฐาน ไม่ใช่ทางเลือก

สูตรจำนวนไฟล์ (mental model)

จำนวนไฟล์ ≈ (แบบยื่นที่มีข้อมูล) × (Business Place) × (Profit Center ที่เลือก | Recovery Indicator ที่เลือก)

→ ถ้าไม่เลือกทั้ง PC และ RECID ก็เหลือแค่ (แบบยื่น × สาขา) เหมือน ECC เดิม → นี่คือเหตุผลที่ volume ระบุไว้ว่า >1,000 records/เดือน แต่จำนวน “ไฟล์” อาจสูงกว่าที่คนคาดมาก

⚠ TC-004 คือ test ที่คนมักคิดไม่ถึง: เลือก Profit Center และ Recovery Indicator พร้อมกัน FD ระบุว่าต้องออกไฟล์ได้ตามทั้งสองเงื่อนไขพร้อมกัน — ไม่ใช่ “อันใดอันหนึ่ง” ตอนเทสต์ให้เตรียมข้อมูลที่ profit center หนึ่งมีหลาย recovery indicator เพื่อดูว่าโปรแกรมแตกไฟล์ถูกจริง

DMEEX format tree + EXIT + ABAP enhancement

object ทางเทคนิคทั้งหมดที่ต้องส่งมอบ

Format tree — 1 แบบยื่น = 1 ต้น

แบบยื่น	DMEEX Format Tree	จำนวน field ใน layout
ภ.ง.ด. 1	`ZWHTFILE_PND1`	13
ภ.ง.ด. 1ก	`ZWHTFILE_P01A`	15
ภ.ง.ด. 2	`ZWHTFILE_P02`	13
ภ.ง.ด. 2ก	`ZWHTFILE_P02A`	18
ภ.ง.ด. 3	`ZWHTFILE_P03`	16
ภ.ง.ด. 53	`ZWHTFILE_P53`	14

สังเกต naming: prefix ZWHTFILE_ คงที่ ส่วนท้ายคือรหัสแบบ — ต้นที่ยาวสุด (P02A, 18 field) คือ ภ.ง.ด.2ก เพราะเป็นแบบ “สรุปทั้งปี + ที่อยู่เต็ม + อัตราภาษี”

Use exits — ใช้ร่วมกันทุกต้น

EXIT Function Module	คำนวณอะไร
`ZDMEE_EXIT_WHT_BASE`	WHT Base — ฐานภาษีที่ใช้คำนวณหัก ณ ที่จ่าย
`ZDMEE_EXIT_WHT_AMT`	WHT Amount — ยอดภาษีที่หักและนำส่ง

ทำไม 2 ตัวนี้ต้องเป็น EXIT ไม่ใช่ mapping ตรง ๆ? เพราะยอดในไฟล์ไม่ใช่ค่าดิบจาก WITH_ITEM เสมอไป — มีเรื่อง สกุลเงิน / การปัดเศษ / รูปแบบตัวเลขที่ RD บังคับ และกรณี gross-up (รหัส G*) ที่ฐานต้องถูกคำนวณย้อน DMEEX ทำ arithmetic ซับซ้อนได้จำกัด จึงโยนออกมาเป็น FM

ABAP Enhancement — `ZTAXA_E01` (retrofit จาก ECC)

Sum partner สำหรับ ภ.ง.ด. 1ก — 1ก เป็นแบบสรุป “ทั้งปี ต่อคน” จึงต้องยุบหลายบรรทัดของ partner เดียวกันเป็นบรรทัดเดียว
Sort ตาม Company Code → Partner → WHT Code — ลำดับในไฟล์มีผลกับการตรวจของ RD และกับการกระทบยอดของทีมภาษี

Enhancement hook

ตอนรัน ZTAXB_R01

Enhancement type

Program

Business context

Text file for PND forms

Layout ทั้ง 6 แบบ — field ต่อ field

อ่านเป็น “ผัง” ไม่ต้องท่อง — แต่ต้องรู้ว่าแบบไหนมีอะไรที่แบบอื่นไม่มี

อ่านตารางข้างล่างให้เร็ว — จับ 4 ความต่างนี้

มี “Company Tax ID + Business Place + Page No” = แบบรายเดือน (1, 2, 2ก, 3, 53) · 1ก ไม่มี เพราะเป็นใบสรุปแนบท้าย
มี “Tax Rate” = 2, 2ก, 3, 53 · 1 และ 1ก ไม่มี (เงินเดือนใช้วิธีคำนวณตามขั้นบันได ไม่ใช่อัตราคงที่)
มีที่อยู่เต็ม (House/Street/Tumbon/District/City/Post) = 1ก และ 2ก (แบบสรุปรายปี) · 3/53 มีแค่ City + Postal code
มี “Remarks” = 3 และ 53 เท่านั้น

ภ.ง.ด. 1 — 13 fields

#	Field	คำอธิบาย
1	Company Tax ID	เลขประจำตัวผู้เสียภาษีของบริษัท
2	Business Place	สาขา
3	Income Type	ประเภทเงินได้
4	Page No	แผ่นที่
5	Seq. No	ลำดับที่
6	Tax ID	เลขประจำตัวผู้เสียภาษีของผู้มีเงินได้
7	Title	คำนำหน้า
8	Name	ชื่อผู้มีเงินได้
9	Sur-Name	นามสกุล
10	Payment Date	วัน/เดือน/ปี ที่จ่าย
11	Payment Amount	จำนวนเงินที่จ่าย
12	Withholding tax amount	ภาษีที่หักและนำส่ง
13	Condition	เงื่อนไข: 1 หักภาษี ณ ที่จ่าย · 2 ออกให้ตลอดไป · 3 ออกให้ครั้งเดียว

ภ.ง.ด. 1ก — 15 fields (สรุปรายปี · ไม่มี Company Tax ID/Business Place/Page No · มีที่อยู่เต็ม)

#	Field	คำอธิบาย
1	Seq. No	ลำดับที่
2	Income Type	ประเภทเงินได้
3	Tax ID	เลขประจำตัวผู้เสียภาษี
4	Title	คำนำหน้า
5	Name	ชื่อ
6	Sur-Name	นามสกุล
7	House Number	บ้านเลขที่
8	Street	ถนน
9	Tumbon	ตำบล/แขวง
10	District	อำเภอ/เขต
11	City	จังหวัด
12	Post Code	รหัสไปรษณีย์
13	Payment Amount	ยอดรวมที่จ่ายทั้งปี
14	Withholding tax amount	ภาษีที่หักและนำส่ง
15	Condition	เงื่อนไข 1/2/3

โยงกลับหา ZTAXA_E01: field ที่ 13 (ยอดรวมทั้งปีต่อคน) คือเหตุผลที่ต้องมี “sum partner” ใน enhancement — ถ้าไม่รวม จะได้ 1ก ที่มีคนเดิมซ้ำหลายบรรทัด ซึ่ง RD ไม่รับ

ภ.ง.ด. 2 — 13 fields (มี Tax Rate · ชื่อ-นามสกุลรวมช่องเดียว)

#	Field
1	Company Tax ID
2	Business Place
3	Income Type
4	Page No
5	Seq. No
6	Tax ID
7	Title
8	Name and Sur-Name (ช่องเดียว)
9	Payment Date
10	Tax Rate
11	Payment Amount
12	Withholding tax amount
13	Condition

ภ.ง.ด. 2ก — 18 fields (ยาวที่สุด · สรุปรายปี + ที่อยู่ + อัตรา)

#	Field
1–5	Company Tax ID · Business Place · Income Type · Page No. · Seq. No
6–9	Tax ID · Title · Name · Sur-Name
10–14	House Number · Tumbon · District · City · Post Code (สังเกต: 2ก ไม่มี Street ต่างจาก 1ก)
15	Payment Amount — ยอดรวมทั้งปี
16	Tax rate
17	Withholding tax amount
18	Condition

ภ.ง.ด. 3 — 16 fields (บุคคลธรรมดา · มี Remarks)

#	Field
1–5	Company Tax ID · Business Place · Income Type Text · Page No. · Seq. No
6–8	Tax ID · Title · Name and Sur-Name
9–10	City · Postal code (ที่อยู่แบบย่อ)
11–14	Payment date · Tax rate · Payment Amount · Withholding tax amount
15	Condition
16	Remarks

ภ.ง.ด. 53 — 14 fields (นิติบุคคล · ไม่มี Page No · ไม่มี Title)

#	Field
1–4	Company Tax ID · Business Place · Income Type Text · Seq. No (ข้าม Page No)
5–6	Tax ID · Name (นิติบุคคลไม่มีคำนำหน้า/นามสกุล)
7–8	City · Postal code
9–12	Payment date · Tax rate · Payment Amount · Withholding tax amount
13	Condition
14	Remarks

เทคนิคจำ: “1 ไม่มีอัตรา · ก ไม่มีวันจ่าย · 53 ไม่มีชื่อคน” — แบบ 1/1ก ไม่มี Tax Rate เพราะเงินเดือนคำนวณตามขั้น · แบบ “ก” (1ก/2ก) เป็นสรุปทั้งปี จึงไม่มี Payment Date รายรายการ · แบบ 53 จ่ายให้นิติบุคคล จึงไม่มี Title/Sur-Name

ECC → S/4HANA — ของเดิมอยู่ตรงไหน

Retrofit หมายถึง “ยกของเดิมมา แล้วเพิ่ม delta” — ต้องรู้ว่าของเดิมคืออะไร

เมนู/T-code เดิมใน ECC (แยกกัน 6 ตัว)

T-code เดิม	ชื่อเมนู	แบบยื่น
`E01`	AP Attach P.N.D. 1 & E-Filing	ภ.ง.ด. 1
`E1K`	AP Attach P.N.D. 1A & E-Filing	ภ.ง.ด. 1ก
`E02`	AP Attach P.N.D. 2 & E-Filing	ภ.ง.ด. 2
`E2K`	AP Attach P.N.D. 2A & E-Filing	ภ.ง.ด. 2ก
`E03`	AP Attach P.N.D. 3 & E-Filing	ภ.ง.ด. 3
`E04`	AP Attach P.N.D. 53 & E-Filing	ภ.ง.ด. 53

Delta สรุปเป็น 3 บรรทัด

รวมทางเข้า — จาก 6 T-code ใน ECC เหลือ ZTAXB_R01 ตัวเดียว ใน S/4 (ตัวเดียวกับที่ TAX-RPT-1 ใช้)
เพิ่ม 2 มิติการแตกไฟล์ — Profit Center และ Recovery Indicator
โครงไฟล์และ EXIT ไม่เปลี่ยน — DMEEX tree + EXIT FM ยกมาตรง ๆ (retrofit)

เอกสารอ้างอิง FS เดิมของ ECC ระบุเป็น 6 ไฟล์ ตามหมายเลข object เดิม — 1722_ZWHTFILE_P01 (PND1) · 1726_..._P01KOR (PND1A) · 1723_..._P02 · 1727_..._P02K (PND2A) · 1724_..._P03 · 1725_..._P53 สังเกตว่า naming เดิมใช้ “KOR” แทน “ก” ส่วน S/4 เปลี่ยนมาใช้ “A”

Key Test Conditions (FAT) — TC-001 ถึง TC-007

ชุดนี้จะถูก upload เข้า TestRail แล้วขยายเป็น test script พร้อม expected result

Test ID	Condition	Expected result
TC-001	ดึงข้อมูลตามที่ระบุใน sec 2.2.3 และสร้าง text file	ได้ text file ครบตามข้อมูลที่กำหนด
TC-002	เลือก Profit Center บน selection screen	ไฟล์ถูกแตกตาม profit center ที่เลือก
TC-003	เลือก Recovery Indicator	ไฟล์ถูกแตกตาม recovery indicator
TC-004	เลือก ทั้ง PC และ RECID พร้อมกัน	ไฟล์ถูกแตกตามทั้งสองเงื่อนไขพร้อมกัน
TC-005	รันตาม Company Code + Business Place	ผลลัพธ์ออกตาม company code และสาขา
TC-006	Negative: exclude WHT code / WHT type บน selection screen	ไฟล์ของ code/type ที่ถูก exclude ต้องไม่ถูกสร้าง
TC-007	เอกสารกลับรายการ (reversal document)	ต้องไม่มีไฟล์ออกมา สำหรับเอกสาร reversal

⚠ TC-007 อธิบายให้ลึก: การกลับรายการ WHT ทำให้เกิดคู่เอกสาร (ตัวจริง + ตัวกลับ) ถ้าโปรแกรมนับทั้งคู่ ยอดในไฟล์จะเป็น 0 แต่ จำนวนบรรทัดจะเกิน — RD จะเห็นรายการที่ไม่ควรมี ตอนเทสต์ให้เตรียม 3 เคส: (ก) กลับรายการในงวดเดียวกัน (ข) กลับรายการข้ามงวด (ค) กลับแล้วตั้งใหม่ เคส (ข) คือตัวที่ทำให้โปรแกรมพลาดบ่อยที่สุด

8.5

FUT status & gaps (mid-Oct-2026)

ของซี — สอนในคอร์ส TAX-405 (slides 28 และ 33 upper)

G11 — Tambon (ตำบล): ใน BP เก็บกระจายอยู่ใน street fields ของ ADRC ไม่ได้อยู่ใน field คงที่ → กระทบ logic ที่อยู่ใน text file · ทำ ADRC trace ใน SE16N ก่อนเขียน mapping rules (owner: BP/MDG team + ENH-6 owner) · ownership ทับกันระหว่าง ENH-1 กับ ENH-6

Output groups ↔ แบบ

แบบ	Output group	WHT type / QSREC
PND1	`E01`	1A, 1B, 1D, 1E / 01
PND1A (1ก)	`E1K`	1A, 1B, 1D, 1E / 01
PND2	`E02`	2A / 02
PND2A (2ก)	`E2K`	2A / 02
PND3	`E03`	3A–3F / 03
PND53	`E04`	4A–4F / 53

E01/E02 = ใบแนบ + e-filing PND1/2 · E03/E04 = PND3/53 · E1K/E2K = PND1A/2A · PND54 ไม่อยู่ใน ENH-1 (เป็นของ RPT-1 / FRM-1) · WHT codes กำลัง redesign (G5) → ต้องอัปเดต constants

ต้องมีก่อนเทสระดับ field

DMEEX mapping workbook — field positions, lengths, padding, constants, วันที่แบบปี พ.ศ., รูปแบบทศนิยม (FD ไม่ได้ฝังไว้)
ยืนยันชื่อ format tree / exits ใน S/4 (อาจต่างจาก ECC)

Gaps

กลไก PC/RI และ key ไม่ได้ระบุ — คาดว่า inherit จาก ACDOCA 0L KTOSL WIT TBC
Business place + PC/RI รวมกันแล้วได้กี่ไฟล์ — ไม่ได้กำหนด
วิธีตัดเอกสาร reversed ไม่ได้ระบุ — เช็ก BKPF-STBLG / XREVERSAL
หมายเหตุ config ของ PND53 และช่อง Business Place ของ TC-005 ไม่ครบ

Test approach

Baseline ทุก process type → control totals เทียบ WITH_ITEM ต่อ WITHT / QSREC
PND3 / PND53 amounts เทียบ WT_QSSHH / WT_QBSHH แล้วบันทึกผลกระทบ GL-ENH-1
ไม่กรอง / PC / RI / ทั้งคู่ → นับบรรทัดเทียบ ACDOCA WIT rows · regression บังคับหลัง TKT-01 (split lines เปลี่ยนจำนวนบรรทัดได้)
คู่ original / reversal ต้องไม่ออกในไฟล์ · ตรวจ 1 record ต่อ file type เทียบ workbook · PND1A partner summation
Multi-invoice payment TC-010..016

Sister objects (ไม่ใช่ของซี)

TAX-ENH-6 SWC PND3/53 — exception path · tree type WTRE · header H + detail D · gross-up exits
TAX-ENH-5 SWC PND1 / 1A / 2 / 2A

Expert notes — สิ่งที่ FD ไม่ได้เขียน แต่ต้องรู้

มุมที่ทำให้ตอบ review/KT ได้เหนือกว่าการอ่านเอกสาร

1) object นี้อยู่บนโปรแกรมเดียวกับอีก 2 objects ของซี — ต้องระวัง regression

ZTAXB_R01 ถูกใช้โดย TAX-RPT-1 (recon PND54↔VAT36), TAX-FRM-1 (ใบแนบ PDF) และ TAX-ENH-1 (text file) พร้อมกัน แปลว่า การแก้ selection screen ของตัวหนึ่ง กระทบทั้งสามตัว เวลารายงาน defect ต้องระบุ output group ให้ชัดว่าพังที่ไฟล์ ที่ฟอร์ม หรือที่รายงาน

ZTAXB_R01
selection screen ร่วม → TAX-RPT-1
ALV recon TAX-FRM-1
Adobe PDF TAX-ENH-1
DMEEX .txt

2) Profit Center ใน object ตระกูล tax = “มิติที่ ECC ไม่เคยมี”

ทั้ง ENH-1 / FRM-1 / RPT-1 ต่างเพิ่ม Profit Center พร้อมกัน — นี่ไม่ใช่ความบังเอิญ แต่เป็น Key Design Decision ระดับ blueprint ที่ตัดสินว่างานภาษีของ Client ใน S/4 ต้องมองเห็นได้ระดับ profit center (สอดคล้องกับที่ TAX-RPT-3 เลิกใช้กติกา “Exclude profit center O*” ของ ECC) → ผลคือ ทุก object ในกลุ่มนี้ validate Profit Center จาก CEPC เหมือนกันหมด

3) ทำไมไฟล์ต้องแยกตาม Business Place เสมอ

เพราะภาษีหัก ณ ที่จ่ายของไทยยื่น รายสาขา (สำนักงานใหญ่/สาขา มีเลขสาขาต่างกัน) ใน SAP เลขสาขาผูกกับ Business Place และปรากฏเป็น field ที่ 2 ของแทบทุก layout ถ้าไฟล์รวมสาขา จะยื่นไม่ได้เลย — นี่คือข้อบังคับทางกฎหมาย ไม่ใช่ทางเลือกของ design

4) Error handling ที่ FD กำหนด

Ref	Notification level	สิ่งที่ควรใช้กับอะไร (ตีความ)
1	Error	เงื่อนไขที่ทำให้ไฟล์ผิดกฎหมาย — เช่น profit center / recovery indicator ที่ไม่มีในตาราง
2	Warning	เงื่อนไขที่ยังรันต่อได้แต่ต้องรู้ — เช่น ไม่พบข้อมูลของบางสาขา
3	Info	สรุปผล — จำนวนไฟล์/บรรทัดที่สร้าง

TODO: verify ข้อความ exception จริง ๆ ยังเป็น N/A ใน FD v0.1 — ต้องตามจาก technical design หรือระบบจริง

5) Checklist ก่อนขึ้น FUT (ทำเองได้)

ก่อนรัน — เตรียมข้อมูลด้วย SE16N 4 ตาราง

WITH_ITEM (มี WITHT/QSREC/WT_WITHCD ที่ต้องการไหม) → ACDOCA (บรรทัดนั้น KTOSL = WIT และมี PRCTR/RECID ที่จะใช้ทดสอบไหม) → CEPC (profit center ที่จะใส่มีจริงไหม) → T8JJ (recovery indicator ใช้กับ company code นั้นได้ไหม)

หลังรัน — ตรวจไฟล์ 4 จุด

จำนวนไฟล์ตรงกับ (แบบยื่น × สาขา × PC/RECID) ไหม → field ที่ 1–2 (Tax ID บริษัท + สาขา) ถูกไหม → ยอดรวม WHT ในไฟล์ = ยอดใน ALV ของ RPT-1 ไหม → เอกสาร reversal หลุดเข้ามาไหม

Self-check

ทวนความเข้าใจ

ตอบในใจก่อนกดดูเฉลย

1. ธุรกรรมหนึ่งมี WHT Type = 4C แต่ Recipient Type = 03 จะออกในไฟล์ไหน?

ไม่ควรออกที่ไหนเลย และนี่คือ master data ผิด — 4C อยู่ในกลุ่ม ภ.ง.ด.53 (นิติบุคคล) แต่ 03 คือ recipient type ของ ภ.ง.ด.3 (บุคคลธรรมดา) เงื่อนไขทั้งสองต้องสอดคล้องกัน รายการนี้จะหลุดจากทั้งสองไฟล์แบบเงียบ ๆ → ต้องแก้ที่ vendor master / WHT type ของเอกสาร ไม่ใช่แก้โปรแกรม

2. Recovery Indicator validate จากตารางอะไร และทำไมต้องส่ง company code ไปด้วย?

จาก T8JJ-RECID (ตาราง JVA) และต้องส่งคู่กับ BUKRS เพราะ recovery indicator เป็นค่าที่นิยามภายใต้บริบทของ joint venture ในแต่ละ company code — validate ลอย ๆ จะยอมรับค่าที่ใช้ไม่ได้จริง แล้วได้ไฟล์เปล่าโดยไม่มี error

3. ทำไม ภ.ง.ด. 1ก ต้องพึ่ง enhancement ZTAXA_E01 ในขณะที่แบบอื่นไม่ต้อง?

เพราะ 1ก เป็น ใบสรุปทั้งปีต่อผู้มีเงินได้ 1 คน = 1 บรรทัด (field 13 = “Total amount paid per year”) ในขณะที่ WITH_ITEM เก็บเป็นรายเอกสาร → ต้อง sum ตาม partner ก่อน DMEEX จะ map นอกจากนี้ enhancement ยัง sort ตาม company code → partner → WHT code ให้ด้วย

4. ถ้าเลือก Profit Center แล้ว ไฟล์จะยังแยกตามสาขาอยู่ไหม?

ยังแยก — FD ระบุชัดว่า “files separated by business place” เป็นพฤติกรรมพื้นฐาน ส่วน PC / RECID เป็น มิติเพิ่ม ไม่ใช่มิติแทนที่ ดังนั้นเลือก PC = ยิ่งได้ไฟล์เยอะขึ้น ไม่ใช่น้อยลง

5. EXIT 2 ตัวชื่ออะไร และทำหน้าที่ต่างกันอย่างไร?

ZDMEE_EXIT_WHT_BASE = คำนวณ ฐานภาษี (WHT base) · ZDMEE_EXIT_WHT_AMT = คำนวณ ยอดภาษีที่หัก (WHT amount) ทั้งคู่ถูกเรียกจาก DMEEX tree ทุกต้น (ทั้ง PND3 และ PND53 ระบุไว้ตรง ๆ ใน FD)

6. Object นี้ครอบคลุม ภ.ง.ด. 54 หรือไม่?

ไม่ — ENH-1 มีแค่ 1, 1ก, 2, 2ก, 3, 53 · ภ.ง.ด. 54 (จ่ายไปต่างประเทศ) อยู่ใน TAX-FRM-1 (ใบแนบ) และ TAX-RPT-1 (กระทบยอดกับ ภ.พ.36)

ภาพรวม — object นี้ทำอะไร และอยู่ตรงไหนของ process

ทำไมต้องเป็น Enhancement ไม่ใช่ Report

กติกาแยกแบบยื่น — WHT Type / Recipient Type / WHT Code

ชั้นที่ 0 — ตัวชี้ว่าเป็นบรรทัด WHT

ชั้นที่ 1 — WHT Type (Extended Withholding Tax Type · WITH_ITEM-WITHT)

ชั้นที่ 2 — Recipient Type (WITH_ITEM-QSREC) · ตัวยืนยันซ้ำ

ชั้นที่ 3 — Withholding Tax Code (WITH_ITEM-WT_WITHCD) · ประเภทเงินได้

Selection screen — Generic Withholding Tax Reporting

โครงหน้าจอ (block ต่อ block)

Validation ของ 2 field ใหม่ (ต้องจำ)

Logic delta — 1 การรัน แตกเป็นกี่ไฟล์

DMEEX format tree + EXIT + ABAP enhancement

Format tree — 1 แบบยื่น = 1 ต้น

Use exits — ใช้ร่วมกันทุกต้น

ABAP Enhancement — ZTAXA_E01 (retrofit จาก ECC)

Layout ทั้ง 6 แบบ — field ต่อ field

ภ.ง.ด. 1 — 13 fields

ภ.ง.ด. 1ก — 15 fields (สรุปรายปี · ไม่มี Company Tax ID/Business Place/Page No · มีที่อยู่เต็ม)

ภ.ง.ด. 2 — 13 fields (มี Tax Rate · ชื่อ-นามสกุลรวมช่องเดียว)

ภ.ง.ด. 2ก — 18 fields (ยาวที่สุด · สรุปรายปี + ที่อยู่ + อัตรา)

ภ.ง.ด. 3 — 16 fields (บุคคลธรรมดา · มี Remarks)

ภ.ง.ด. 53 — 14 fields (นิติบุคคล · ไม่มี Page No · ไม่มี Title)

ECC → S/4HANA — ของเดิมอยู่ตรงไหน

เมนู/T-code เดิมใน ECC (แยกกัน 6 ตัว)

Key Test Conditions (FAT) — TC-001 ถึง TC-007

FUT status & gaps (mid-Oct-2026)

Output groups ↔ แบบ

ต้องมีก่อนเทสระดับ field

Gaps

Test approach

Sister objects (ไม่ใช่ของซี)

Expert notes — สิ่งที่ FD ไม่ได้เขียน แต่ต้องรู้

1) object นี้อยู่บนโปรแกรมเดียวกับอีก 2 objects ของซี — ต้องระวัง regression

2) Profit Center ใน object ตระกูล tax = “มิติที่ ECC ไม่เคยมี”

3) ทำไมไฟล์ต้องแยกตาม Business Place เสมอ

4) Error handling ที่ FD กำหนด

5) Checklist ก่อนขึ้น FUT (ทำเองได้)

ทวนความเข้าใจ

ชั้นที่ 1 — WHT Type (Extended Withholding Tax Type · `WITH_ITEM-WITHT`)

ชั้นที่ 2 — Recipient Type (`WITH_ITEM-QSREC`) · ตัวยืนยันซ้ำ

ชั้นที่ 3 — Withholding Tax Code (`WITH_ITEM-WT_WITHCD`) · ประเภทเงินได้

ABAP Enhancement — `ZTAXA_E01` (retrofit จาก ECC)