TAX-FRM-1 — ใบแนบ ภ.ง.ด. 3 / 53 / 54 (PDF · Profit Center)

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

“ใบแนบ” คือเอกสารรายละเอียดที่แนบท้ายแบบยื่น — รายชื่อผู้ถูกหักภาษี ยอดจ่าย ยอดภาษี ทีละบรรทัด FRM-1 พิมพ์ใบแนบของ ภ.ง.ด. 3 (บุคคลธรรมดา) · 53 (นิติบุคคลในประเทศ) · 54 (จ่ายไปต่างประเทศ) สิ่งที่ “เปลี่ยน” จริง ๆ มีแค่ 2 อย่าง — เพิ่มมิติ Profit Center / Recovery Indicator บนหน้าจอ และเปลี่ยนวิธีดึง เลขประจำตัวผู้เสียภาษีของผู้ขาย ให้มาจาก DFKKBPTAXNUM

Trigger

Manual

ผ่าน S_P00_07000134

Output channel

Print (A4)

ภาษาไทย · ไม่มี Output Mgmt

Volume

≤ 500 / เดือน

Monthly + Ad Hoc · on demand

⚠ Dependency ที่ต้องรู้ก่อนเทสต์: FD ระบุตรง ๆ ว่า ต้องพึ่ง WRICEF TAX-RPT-1 ในการรันรายงาน — ถ้า RPT-1 ยังไม่พร้อม/มี defect FRM-1 จะเทสต์ไม่ได้เลย เพราะทั้งคู่เกาะ selection screen เดียวกัน → เปิด TAX-RPT-1 คู่กัน

🔗 อ่านคู่กัน: TAX-ENH-1 (text file e-Filing ของ 1/1ก/2/2ก/3/53) · TAX-FRM-2 (WHT Certificate เมียนมา — form อีกตัวที่คุณดูแล) · Statutory Filing Guide · SE16N (ไล่ join chain ด้วยตัวเอง)

Key Takeaways — 6 ข้อ

“Retrofit with change” = ฟอร์มหน้าตาเดิม (No change ทั้ง header/item/summary/footer) แต่ วิธีได้ข้อมูลเปลี่ยน
ทิศทางการ join กลับด้าน ระหว่าง “เลือก PC” กับ “ไม่เลือก PC” — จำ 2 ทิศนี้ให้ได้คือเข้าใจทั้ง object
ไม่เลือก Profit Center = โปรแกรมต้อง ไปหา PRCTR เอง จาก ACDOCA แล้ว แตกใบแนบทีละ profit center
ACDOCA ที่ใช้ต้องเป็น RLDNR = '0L' และ KTOSL = 'WIT' เสมอ
ใน 18 fields มีแค่ field [7] Tax Identification of Vendor ที่เปลี่ยน — ที่เหลือ “No change”
Tax ID ผู้ขาย: TAXTYPE = 'TH1' ถ้าเป็นบุคคล, 'TH3' ถ้าไม่ใช่ · แล้วหยิบ TAXNUM หรือ TAXNUMXL ตัวที่ ไม่ว่าง

ภาพรวม — ใบแนบคืออะไร และ object นี้เปลี่ยนอะไร

Form บน standard transaction เดิม · ผลิตเอกสารกระดาษที่ยื่นจริงต่อกรมสรรพากร

แบบยื่น ภ.ง.ด. 3 / 53 / 54 มี “หน้าปก” ที่สรุปยอดรวม กับ “ใบแนบ” ที่ลิสต์รายละเอียดผู้ถูกหักภาษีทีละราย TAX-FRM-1 คือตัวพิมพ์ ใบแนบ — ไม่ใช่หน้าปก และไม่ใช่หนังสือรับรองการหักภาษี (50 ทวิ)

แบบยื่น	ใช้กับใคร	WHT Type	Recipient Type
ภ.ง.ด. 3	จ่ายให้ บุคคลธรรมดา ในประเทศ	`3A` `3B` `3C` `3D` `3E` `3F`	`03`
ภ.ง.ด. 53	จ่ายให้ นิติบุคคล ในประเทศ	`4A` `4B` `4C` `4D` `4E` `4F`	`53`
ภ.ง.ด. 54	จ่าย ออกไปต่างประเทศ (มาตรา 70)	`5A` `5D`	`54`

เอกสารต้นทางที่ retrofit มา

ของเดิม (ECC)	ครอบคลุม
`65_ZTAXA_F03 PND3-53 Attachment`	ใบแนบ ภ.ง.ด. 3 และ 53
`65_undefined PND54 Attachment`	ใบแนบ ภ.ง.ด. 54
Legacy form output `R03`	“Attachment P.N.D. 3, 53 and 54”

R03 คือคำที่คุณเคยเจอมาแล้ว: ใน FUT ของ TAX-RPT-1 คุณเห็น output group R03 บนหน้าจอ Generic Withholding Tax Reporting — นั่นคือตัวเดียวกันกับ legacy form number ของ FRM-1 พูดอีกแบบ: R03 = ประตูที่ทำให้ standard program รู้ว่าต้องเรียกฟอร์มใบแนบตัวนี้

Trigger — เอกสารแบบไหนที่ทำให้เกิดใบแนบ

FD ระบุ trigger ว่า “Invoice posting subject to WHT (FB60 / MIRO / FB01) with the WHT code of WHT type (PND3, 53) or (PND54)” → หมายความว่า ใบแนบเกิดจากเอกสารตั้งหนี้/จ่ายเงินที่มี WHT ไม่ได้เกิดจาก event ใด ๆ ในระบบเอง ตัวฟอร์มถูกพิมพ์ทีหลังแบบ manual/on demand

Selection screen ของ S_P00_07000134 (TO-BE)

หน้าจอเดียวกับ TAX-RPT-1 / TAX-ENH-1 — แต่ block “Forms” เป็นของ FRM-1 โดยเฉพาะ

Block	Field	บทบาทกับ FRM-1
Output Groups	Process Type · Output Groups	ต้องเลือกกลุ่มที่ผูกกับ `R03` ฟอร์มจึงจะออก
Mandatory Selections	Country Key · Reporting Period	`TH` + งวดที่ยื่น
General Selections	Company Code · Fiscal Year · Ext. WH Tax Type · Ext. WH Tax Code · Classic WH Tax Code · Suppliers · Customers	ตัวกรองหลัก
General Control	(standard)	—
Further Selections	Profit Center (from–to + multiple) · Recovery Indicator (multiple)	← delta ของ S/4 (ทั้งคู่ optional)
Output Control And Lists	(standard)	—
Forms	Sender Variant · Form 1: Attachment (Print form 1 / Print Immediately / Number of copies / Output Device) · Form 2: Attachment (ชุดเดียวกัน)	คุมการพิมพ์ใบแนบ 2 ชุด

Validation ของ 2 field ใหม่

Screen field	Type	Attribute	Parameter	Validation
Profit Center	Alphanumeric	Optional	From, To + multiple selection	ตรวจกับตาราง `CEPC` field `PRCTR`
Recovery Indicator	Alphanumeric	Optional	Multiple selection	ตรวจ คู่ ของ `BUKRS` + `RECID` ในตาราง `T8JJ`

สังเกตความสอดคล้องข้าม object: validation ชุดนี้ เหมือนกันเป๊ะ กับ TAX-ENH-1 และ TAX-RPT-4 / TAX-RPT-5 ก็ใช้กติกาเดียวกัน (CEPC สำหรับ PC, T8JJ+BUKRS สำหรับ RECID) → เวลาอธิบายให้ทีม technical ฟัง ให้พูดครั้งเดียวว่า “มาตรฐานของ tax workstream” ไม่ต้องอธิบายซ้ำ object ต่อ object

Logic — 6 เส้นทางการดึงข้อมูล (3 เงื่อนไข × 2 กลุ่มแบบ)

หัวใจของ FD ฉบับนี้ · ให้ดูที่ “ทิศทางลูกศร” ไม่ใช่ที่ชื่อ field

สรุปทิศทางก่อนอ่านรายละเอียด

เลือก PC / เลือก RECID → เริ่มที่ ACDOCA (เพราะ PC และ RECID อยู่ใน ACDOCA) แล้ววิ่งไป WITH_ITEM
ไม่เลือก PC → เริ่มที่ WITH_ITEM (เพราะมีแค่ BUKRS/GJAHR) แล้ววิ่ง ย้อนกลับ ไป ACDOCA เพื่อ “ขอ PRCTR”
ปลายทางเหมือนกันเสมอ: พิมพ์ตาม field 18 ตัวใน section 5

เส้นทาง A — เลือก Profit Center

A1 · ภ.ง.ด. 3 และ 53 (เลือก PC)

ส่ง PRCTR + GJAHR เข้า ACDOCA · เงื่อนไข KTOSL = 'WIT'
ดึง เลขที่เอกสาร BELNR ออกมา
ส่ง BELNR + GJAHR เข้า WITH_ITEM · WT_WITHCD ต้อง ไม่ว่าง
กรอง WITHT ∈ {3A…3F} และ QSREC = '03' → ภ.ง.ด. 3
กรอง WITHT ∈ {4A…4F} และ QSREC = '53' → ภ.ง.ด. 53
พิมพ์ฟอร์มตาม field ใน section 2.3.3.6 (18 fields)

A2 · ภ.ง.ด. 54 (เลือก PC)

ขั้น 1–3 เหมือน A1 ทุกประการ
กรอง WITHT ∈ {5A, 5D} และ QSREC = '54'
พิมพ์ฟอร์ม

เส้นทาง B — ไม่เลือก Profit Center (ต้องหา PRCTR เอง)

B1 · ภ.ง.ด. 3 และ 53 (ไม่เลือก PC)

ส่ง BUKRS + GJAHR จาก selection screen เข้า WITH_ITEM · WT_WITHCD ไม่ว่าง
กรอง WITHT / QSREC ตามแบบ (3A–3F/'03' หรือ 4A–4F/'53')
ดึง BELNR ออกมา
ส่ง BUKRS + GJAHR + BELNR เข้า ACDOCA · RLDNR = '0L' และ KTOSL = 'WIT'
ดึง PRCTR ออกมา
ถ้าข้อมูลที่ได้มีหลาย profit center → สร้างใบแนบ “แยกใบต่อ profit center”

B2 · ภ.ง.ด. 54 (ไม่เลือก PC)

เหมือน B1 แต่กรอง WITHT ∈ {5A, 5D} และ QSREC = '54'
ปิดท้ายด้วยกติกาเดียวกัน — หลาย PRCTR = หลายใบแนบ

เส้นทาง C — เลือก Recovery Indicator

C1 / C2 · ภ.ง.ด. 3 & 53 และ ภ.ง.ด. 54 (เลือก RECID)

ส่ง RECID + GJAHR เข้า ACDOCA · match KTOSL = 'WIT' · ดึง BELNR
ส่ง BELNR + GJAHR เข้า WITH_ITEM · WT_WITHCD ไม่ว่าง
กรอง WITHT/QSREC ตามแบบ (3/53 หรือ 54)
พิมพ์ฟอร์ม

เลือก PC หรือ RECID → ACDOCA
KTOSL=WIT → BELNR → WITH_ITEM
WITHT + QSREC → พิมพ์ใบแนบ

ไม่เลือก PC → WITH_ITEM
BUKRS+GJAHR → BELNR → ACDOCA
RLDNR=0L, KTOSL=WIT → PRCTR → 1 ใบแนบ / 1 profit center

⚠ จุดที่ต่างกันเงียบ ๆ: เส้นทาง A และ C ไม่ได้ระบุ RLDNR = '0L' ใน FD แต่เส้นทาง B ระบุไว้ชัดเจน — เพราะ B ต้องอ่าน ACDOCA เพื่อ “หา PRCTR” จึงต้องล็อก ledger กันข้อมูลซ้ำจาก ledger อื่น (เช่น T1) ส่วน A/C ค้นด้วย PRCTR/RECID ที่ระบุมาแล้ว จึงเสี่ยงซ้ำน้อยกว่า ในทางปฏิบัติควรล็อก RLDNR ทุกเส้นทาง — ถ้าเจอยอดซ้ำตอนเทสต์ ให้สงสัยจุดนี้ก่อน TODO: verify

Condition 1 — ที่มาของ “เลขประจำตัวผู้เสียภาษีของผู้ขาย”

field เดียวที่เปลี่ยนใน 18 fields · แต่เป็นตัวที่ทำให้ยื่นผ่าน/ไม่ผ่าน

จาก WITH_ITEM กรอง WITHT/QSREC ตามแบบ และ WT_WITHCD ต้องไม่ว่าง
ดึง เลขผู้ขาย WT_ACCO (Vendor Number)
ส่ง WT_ACCO เข้าตาราง DFKKBPTAXNUM ที่ field PARTNER
อ่าน TAXTYPE (Identification Type) — ถ้าผู้ขายเป็นบุคคล ใช้ TH1 · ถ้าไม่ใช่ ใช้ TH3
หยิบ TAXNUM (Tax Number) หรือ TAXNUMXL (Tax Number Long) — ตัวไหนที่ไม่ว่าง

WITH_ITEM
WT_ACCO → DFKKBPTAXNUM
PARTNER → TAXTYPE
TH1 (บุคคล) / TH3 → TAXNUM หรือ TAXNUMXL
field [7] ของฟอร์ม

ทำไมต้อง DFKKBPTAXNUM ไม่ใช่ LFA1-STCD1?

S/4HANA ใช้ Business Partner (BP) เป็นแกน — ผู้ขาย/ลูกค้ารวมเป็น BP เดียว เลขประจำตัวผู้เสียภาษีจึงย้ายไปเก็บที่ตาราง tax number ของ BP
1 BP มีได้หลาย tax number หลาย type — จึงต้องระบุ TAXTYPE ให้ถูก ไม่งั้นอาจได้เลขของประเทศอื่น/ประเภทอื่น
TAXNUM vs TAXNUMXL — field มาตรฐานยาวจำกัด ส่วน XL ไว้รองรับเลขที่ยาวกว่า → กติกา “ตัวไหนไม่ว่างใช้ตัวนั้น” จึงจำเป็น

⚠ กับดักในการเทสต์: ถ้า field [7] ว่างในใบแนบ อย่าเพิ่งโทษฟอร์ม — ให้ไล่ 3 จุดด้วย SE16N: (1) WITH_ITEM-WT_ACCO มีค่าไหม (2) DFKKBPTAXNUM มี record ของ partner นั้นไหม (3) record นั้น TAXTYPE เป็น TH1/TH3 ตรงกับประเภทผู้ขายไหม → ตาม TC-02 ระบบต้องปล่อยช่องว่างไว้ พร้อมขึ้นข้อความ “The field xxx is not available in the table xxx”

Required Data for Form — 18 fields

“No change” ทุกช่อง ยกเว้น [7] — เท่ากับ delta ของ object นี้ทั้งหมดอยู่ที่ 1 บรรทัด

#	Form field	SAP field	SAP table	สถานะ
[1]	Tax identification number (Company Tax ID)	No change	No change	เดิม
[2]	Branch (สาขา)	No change	No change	เดิม
[3]	T-sheets in the number (แผ่นที่)	No change	No change	เดิม
[4]	Rank (ลำดับ)	No change	No change	เดิม
[5]	Company Name	No change	No change	เดิม
[6]	Company Address	No change	No change	เดิม
[7]	Tax Identification of Vendor	TAXNUM หรือ TAXNUMXL	DFKKBPTAXNUM	← เปลี่ยน (Condition 1)
[7]	Name — Vendor Name1 & Name2 & Name3	No change	No change	เดิม
[8]	Payee Address	No change	No change	เดิม
[9]	Date of payment	No change	No change	เดิม
[10]	Currency Exchange Document No.	No change	No change	เดิม
[11]	Income type (Income text)	No change	No change	เดิม
[12]	WHT Rate (Tax rate)	No change	No change	เดิม
[13]	Amount of payment (WHT base amount)	No change	No change	เดิม
[14]	Taxes deducted and remitted (WHT tax amount)	No change	No change	เดิม
[15]	Paid Condition	No change	No change	เดิม
[16]	Total Earnings (Total WHT Base)	No change	No change	เดิม
[17]	Withholding tax Amount (รวม)	No change	No change	เดิม
[18]	FI Document No.	No change	No change	เดิม

อ่านตารางนี้ให้เป็น: คำว่า “No change” ในคอลัมน์ SAP field/table ไม่ได้แปลว่าไม่สำคัญ — แปลว่า technical team ต้องไปเปิด FS เดิม (65_ZTAXA_F03/undefined) เอาเอง เวลาทำ FUT/FIT คุณจึงต้อง ตรวจครบทั้ง 18 ช่อง ไม่ใช่ตรวจแค่ช่องที่ระบุว่าเปลี่ยน (นี่คือ TC-01)

Layout ที่ไม่เปลี่ยน

ส่วน	สถานะ
Header Section · Item Table · Summary · Footer · QR Code/Barcode	No change
Logos	No change
Page Breaks	No page break
Sorting	N/A

Processing · Printer · Roles

รายละเอียดการรันจริง — ข้อมูลชุดนี้มักถูกถามใน cutover/hypercare

Attribute	ค่า
Form Type	Adobe Form (ไม่ใช่ SAPScript / Smart Form)
Trigger	Manual
Trigger Event / Batch Program	`S_P00_07000134`
Output Channel	Print
Output Determination	N/A — ไม่มี Output Management (ไม่ใช่ BRF+)
Document Type	Vendor Invoice / AP payment posting
Language	Thai
Execution Frequency	Monthly + Ad hoc
Processing method	On demand
Expected Volume	Up to 500 / เดือน
Printer requirement	เครื่องพิมพ์ทั่วไป · กระดาษ A4

User roles & authorisation

Role	Access
Accountant	สร้าง/พิมพ์ฟอร์มได้
Tax Accountant	สร้าง/พิมพ์ฟอร์มได้
Business Analyst	ดูได้อย่างเดียว (display)

Error / Exception handling

FD ระบุทั้ง 3 ระดับว่า “No new exceptions to be added” — คือ ใช้ข้อความ error เดิมของ standard ยกเว้นข้อความที่ปรากฏใน test conditions (profit center ไม่พบ / recovery indicator ไม่พบ / field ไม่มีในตาราง) ซึ่งเป็น expected behaviour ที่ต้องมีจริงตอนเทสต์

Key Test Conditions — TC-01 ถึง TC-08

สังเกตว่าครึ่งหนึ่งเป็น negative test — ฟอร์มที่ดีต้อง “พังอย่างมีมารยาท”

Test ID	Condition	Expected result
TC-01	ดึงข้อมูลครบทุก field ตาม “2.3.3.6 Required data for form”	ข้อมูลถูกต้องครบทั้ง 18 ช่อง
TC-02	Negative: ข้อมูลไม่มีในตารางที่อ้างถึง	ช่องนั้น เว้นว่าง + ขึ้นข้อความ “The field xxx is not available in the table xxx” ระหว่างรัน
TC-03	พิมพ์ A4 · ภาษาไทย · ข้อมูลเกิน 1 หน้า	พิมพ์ครบทุกหน้า ข้อมูลไม่ตกหล่นเมื่อข้ามหน้า
TC-04	เลือก Profit Center	ฟอร์มออกตาม profit center ที่เลือก
TC-05	Negative: profit center ที่เลือกไม่มีอยู่	error “profit center xxxxx is not found”
TC-06	เลือก Recovery Indicator	ฟอร์มออกตาม recovery indicator
TC-07	Negative: recovery indicator ที่เลือกไม่มีอยู่	error “recovery indicator xx is not found”
TC-08	พิมพ์เกิน 1 หน้าต่อฟอร์ม	พิมพ์ได้หลายหน้าถูกต้อง

Test ที่ FD ไม่ได้เขียนแต่ควรทำ: “ไม่เลือก profit center เลย แล้วข้อมูลมีหลาย PC” — ตามเส้นทาง B ต้องได้ ใบแนบหลายใบ ใบละ 1 profit center ไม่ใช่ใบเดียวที่ปนกัน · เคสนี้คือ logic ที่ซับซ้อนที่สุดของ object แต่ไม่มี TC ตรง ๆ ครอบ → เพิ่มเป็น unit test ของตัวเองตอน FUT

7.5

FUT status & defects (mid-Oct-2026)

สิ่งที่ FD ไม่ได้บอก แต่เจอจริงตอนเทส — ทุกข้อเป็นของซีในฐานะเจ้าของ object

Defects ที่ต้อง raise พร้อม specimens

#	อาการ	หลักฐาน
1	17-Sep · Multiple Profit Center ใส่ 2 PCs → vendor ของบรรทัดถูก คัดลอกจากบรรทัดก่อนหน้า (root cause ยังไม่ trace)	run ด้วย PC 2 ตัว
2	21-Sep · Alternative payee: FRM-1 พิมพ์ชื่อ / ที่อยู่ / Tax ID จาก BP master (`DFKKBPTAXNUM`, BP category TH1) แทนข้อมูล payee บนเอกสาร (`BSEC`) · certificate `ZTAXA_F02` ถูกแก้ไปแล้ว (8-Jul) ให้ใช้ `BSEC-STCD3` → `STCD1` → blank	test vendor `VTEST0001` (“payee in document” = X) · docs `2004325075` / `3641` / `3642` / `3643`
3	Header พิมพ์ “แผ่นที่ 1 ในจำนวน 0 แผ่น”	—
4	เลขลำดับไม่ตรงกัน: attachment `070002` vs certificate `070000`	doc `2004325629`

Gaps จาก FD (ต้องได้คำตอบก่อนปิด FUT)

Multi-PC amount rule ไม่ได้กำหนด — 2004327460 อาจนับซ้ำ · ใช้กฎ split ของ TKT-01 หลังได้ sign-off
5G ไม่อยู่ใน scope 5A/5D ปัจจุบัน → 8084322612 หาย · ใช้คำตัดสินเดียวกับ RPT-1 TBC
ทุก branch ที่อ่าน ACDOCA ต้องมี BUKRS และ RLDNR = '0L'
ไม่เลือก PC แล้วมี attachment รวมหรือไม่ — FD ไม่ได้อธิบาย TBC · ชื่อฟอร์มใน S/4 (retrofit จาก ZTAXA_F03/004) และเทคโนโลยี Smart Form vs Adobe อ่านจาก FD ไม่ออก TBC

Test approach

TC-01 (18 fields) blocked by GL-ENH-1 — ยอดมาจาก WITH_ITEM ที่ไม่ถูก update ด้วยยอด GL (8084322568)
2004327460 ทั้ง 2 PCs + population แบบไม่กรอง · 8084322612 เพื่อบันทึกพฤติกรรม 5G ปัจจุบัน
Baseline → positive PC → negative PC → RI filter (วิธีเดียวกับ RPT-1 TC-005)
A4 / ภาษาไทย / หลายหน้า / ยอดรวมต่อหน้า · multi-invoice payment TC-010..016
หลังแก้ filter / split ของ RPT-1: รัน variant เดียวกันผ่าน Form แล้วเทียบ WHT total ต่อ PC กับ WT total ของ RPT-1

Expert notes — อ่านให้ลึกกว่าเอกสาร

1) ทำไม “ไม่เลือก PC” ถึงยากกว่า “เลือก PC”

เพราะ Profit Center ไม่ใช่ field ของโลก WHT — WITH_ITEM ไม่มี PRCTR PRCTR อยู่ในโลกบัญชี (ACDOCA) เท่านั้น เมื่อ user ไม่ระบุ PC โปรแกรมจึงต้อง “ยิงกลับ” ไปถาม ACDOCA ว่าเอกสารแต่ละใบตกที่ profit center ไหน แล้วค่อยจัดกลุ่มพิมพ์ — ต้นทุน performance และความเสี่ยงข้อมูลซ้ำอยู่ตรงนี้

2) ทำไมต้อง `RLDNR = '0L'`

S/4HANA ของ Client มีหลาย ledger (leading 0L + ledger ภาษี เช่น T1) เอกสารเดียวกันจะมีบรรทัดใน ACDOCA หลาย ledger ถ้าไม่ล็อก ledger การหา PRCTR จะได้ record ซ้ำ → ใบแนบซ้ำ/ยอดเบิ้ล 0L = ledger หลักตามมาตรฐานบัญชี ซึ่งเป็นตัวที่สะท้อน profit center ที่แท้จริงของรายการ

3) ความสัมพันธ์กับอีก 2 objects บน T-code เดียวกัน

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

→ สังเกต: ภ.ง.ด. 54 มีใบแนบ (FRM-1) และมีรายงานกระทบยอด (RPT-1) แต่ไม่มี text file (ENH-1) เพราะ 54 ยื่นด้วยวิธีต่างจากแบบอื่น · ส่วน ภ.ง.ด. 1/1ก/2/2ก มี text file แต่ไม่มีใบแนบใน FRM-1

4) เชื่อมกับสิ่งที่คุณเจอใน FUT ของ RPT-1

คุณเคยเห็น output group R03 บนหน้าจอ — ตอนนี้รู้แล้วว่ามันคือ “ประตูเรียกใบแนบ FRM-1”
คุณเคยเจอ 2 FX columns ใน RPT-1 — field [10] “Currency Exchange Document No.” ของ FRM-1 คือญาติของเรื่องเดียวกัน
ตอนไล่ defect ให้ระบุเสมอว่า พังที่ ALV (RPT-1) หรือพังที่ฟอร์ม (FRM-1) เพราะ dev คนละคนกัน

5) Checklist ก่อนเซ็นใบแนบส่งทีมภาษี

4 จุดที่ต้องกระทบยอดทุกครั้ง

(1) ยอดรวม [16]/[17] ในใบแนบ = ยอดใน ALV ของ RPT-1 · (2) จำนวนใบแนบ = จำนวน profit center ที่มีข้อมูลจริง · (3) field [7] ไม่มีช่องว่างที่ไม่ควรว่าง · (4) field [2] สาขา ตรงกับสาขาที่จะยื่นจริง

Self-check

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

1. ถ้า user ไม่ใส่ Profit Center เลย โปรแกรมเริ่มอ่านตารางไหนก่อน?

เริ่มที่ WITH_ITEM ด้วย BUKRS+GJAHR จาก selection screen แล้วดึง BELNR ไปถาม ACDOCA (RLDNR='0L', KTOSL='WIT') เพื่อขอ PRCTR จากนั้นถ้ามีหลาย PRCTR → แตกใบแนบทีละ profit center

2. WHT Type ของ ภ.ง.ด. 54 มีกี่ตัว อะไรบ้าง?

2 ตัว: 5A และ 5D คู่กับ recipient type '54' — ต่างจาก 3 และ 53 ที่มี 6 ตัว (3A–3F / 4A–4F)

3. TAXTYPE = TH1 กับ TH3 ต่างกันยังไง?

TH1 = ผู้ขายเป็นบุคคล (Person) · TH3 = กรณีอื่น (นิติบุคคล) — ต้องเลือกให้ตรงกับประเภทผู้ขาย เพราะ 1 BP อาจมี tax number หลาย type แล้วค่อยหยิบ TAXNUM หรือ TAXNUMXL ตัวที่ไม่ว่าง

4. FRM-1 เป็น Smart Form หรือ Adobe Form? แล้วต่างจาก TAX-FRM-2 อย่างไร?

FRM-1 = Adobe Form · ส่วน TAX-FRM-2 (WHT cert เมียนมา) = Smart Form → คนละ technology คนละวิธีแก้ layout · เวลาคุยกับ dev ต้องบอกให้ถูก

5. Object นี้มี Output Determination (BRF+) ไหม?

ไม่มี — FD ระบุ “N/A as there is no output management” ฟอร์มถูกเรียกจาก selection screen ของ S_P00_07000134 โดยตรงผ่าน block “Forms” (ต่างจากฟอร์ม SD/บิลที่ใช้ BRF+ Output Management)

ภาพรวม — ใบแนบคืออะไร และ object นี้เปลี่ยนอะไร

เอกสารต้นทางที่ retrofit มา

Trigger — เอกสารแบบไหนที่ทำให้เกิดใบแนบ

Selection screen ของ S_P00_07000134 (TO-BE)

Validation ของ 2 field ใหม่

Logic — 6 เส้นทางการดึงข้อมูล (3 เงื่อนไข × 2 กลุ่มแบบ)

เส้นทาง A — เลือก Profit Center

เส้นทาง B — ไม่เลือก Profit Center (ต้องหา PRCTR เอง)

เส้นทาง C — เลือก Recovery Indicator

Condition 1 — ที่มาของ “เลขประจำตัวผู้เสียภาษีของผู้ขาย”

ทำไมต้อง DFKKBPTAXNUM ไม่ใช่ LFA1-STCD1?

Required Data for Form — 18 fields

Layout ที่ไม่เปลี่ยน

Processing · Printer · Roles

User roles & authorisation

Error / Exception handling

Key Test Conditions — TC-01 ถึง TC-08

FUT status & defects (mid-Oct-2026)

Defects ที่ต้อง raise พร้อม specimens

Gaps จาก FD (ต้องได้คำตอบก่อนปิด FUT)

Test approach

Expert notes — อ่านให้ลึกกว่าเอกสาร

1) ทำไม “ไม่เลือก PC” ถึงยากกว่า “เลือก PC”

2) ทำไมต้อง RLDNR = '0L'

3) ความสัมพันธ์กับอีก 2 objects บน T-code เดียวกัน

4) เชื่อมกับสิ่งที่คุณเจอใน FUT ของ RPT-1

5) Checklist ก่อนเซ็นใบแนบส่งทีมภาษี

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

2) ทำไมต้อง `RLDNR = '0L'`