TAX-RPT-3 — Current Tax Report ไทย (ZTAXA_R05)

← หน้ารวม (Hub)

รายงานนี้คือ “เครื่องคำนวณภาษีเงินได้นิติบุคคลรายเดือน” — เอางบการเงินตั้งต้น แล้วบวก/ลบรายการปรับปรุงทางภาษี จนได้กำไรทางภาษี × อัตรา = ภาษีที่ต้องตั้งค้างจ่าย ทุกบรรทัดในรายงานมาจาก 3 แหล่งเท่านั้น — GL node (ยอดจากระบบ) · UP node (ไฟล์อัปโหลด) · CL node (สูตรคำนวณ) FD ฉบับนี้เป็น delta document — เขียนเฉพาะสิ่งที่เปลี่ยนจาก ECC → S/4HANA

Business process

01.01.07.04

Period-End Tax Reporting

Frequency

Monthly + Ad Hoc

มี option รัน background

Users

6 users

Accountant / Tax / BA

🔗 อ่านเป็นชุด — “Current Tax Suite” 3 objects: TAX-RPT-3 (ไทย · หน้านี้) · TAX-RPT-4 (ต่างประเทศ) · TAX-RPT-5 (Loss Carried Forward) — ทั้งสามใช้ตารางชุดเดียวกัน (ZTAXA_T05–037) และส่งค่าให้กันผ่าน ZTAXB_T01

Key Takeaways — 8 ข้อที่ตอบได้ = เข้าใจ object นี้

โครงข้อมูล = GL node (จาก ACDOCA) + UP node (flat file → ZTAXA_T03) + CL node (สูตร)
Segment เปลี่ยนชื่อ: CIT_RC→CIT_TH · PITA1→PITA1_TH · PITA3→PITA3_TH · PITA4→PSC_TH · MTJDA เท่าเดิม
Layout เพิ่ม BOI (ใหม่) และเปลี่ยน IHQ → IBC-TC → รวมเป็น 8 layouts
สูตรกลาง: ANNUAL (P/L) AFTER LCF = ANNUAL (P/L) − ALLOWANCES − LCF − LCF adjustment ใช้กับ ทุก layout
เลิกใช้ “Exclude profit center O*” ของ ECC — S/4 ต้องรวม profit center O* ด้วย
Default ใหม่: Depreciation area 32 · Ledger T1 (สาขาใช้ 02 / 0L)
Manual adjustment 5 รายการถูกดึงจาก GL แทน flat file แล้ว (ลดงาน manual)
IBC = 3% กับ intercompany · 20% กับ non-intercompany — ตัดสินด้วย trading partner (VBUND)

ภาพรวม — รายงานนี้คำนวณอะไร

เครื่องมือคำนวณและประมาณการ “ภาษีเงินได้นิติบุคคลค้างจ่าย” รายเดือน

หลักการทางภาษี: กำไรทางบัญชี ≠ กำไรทางภาษี — ต้องปรับด้วย 2 ตระกูลรายการ

Permanent difference — ต่างถาวร ไม่กลับรายการ (เช่น ค่าปรับ · เงินบริจาคเกินเกณฑ์ · รายจ่ายต้องห้าม)
Temporary difference — ต่างชั่วคราว กลับรายการในอนาคต (เช่น ค่าเสื่อมบัญชี vs ค่าเสื่อมภาษี · ประมาณการหนี้สิน)

กำไรทางบัญชี
GL node ± Permanent diff ± Temporary diff − Allowances / LCF × Tax rate = ภาษีค้างจ่าย

3 ประเภท node — จำให้ขึ้นใจ

Node	ชื่อเต็ม	แหล่งข้อมูล	แก้ไขยังไง
`GL`	General Ledger node	ยอดจาก `ACDOCA` ผ่าน mapping `ZTAXA_T01`	แก้ที่ mapping table หรือแก้เอกสาร
`UP`	Upload node	flat file (โปรแกรม `ZTAXA_R06`) → เก็บใน `ZTAXA_T03`	อัปโหลดใหม่ทับ
`CL`	Calculation node	สูตรจาก node อื่น	แก้ไม่ได้โดยตรง — ต้องแก้ต้นทาง

ประโยชน์ตอน debug: เวลามีคนบอกว่า “ตัวเลขผิด” ให้ถามก่อนว่า บรรทัดนั้นเป็น node ประเภทไหน — ถ้าเป็น GL ให้ไล่ mapping + ACDOCA · ถ้าเป็น UP ให้ไปดูไฟล์ที่อัปโหลด · ถ้าเป็น CL ให้ไล่ node ต้นทางที่ป้อนเข้าสูตร ไม่ต้องเดา — ประเภท node ระบุอยู่ใน ZTAXA_T06

Assumption สำคัญของ FD

“Revaluated information will be based on LC3 — ข้อมูลที่ตีราคาใหม่สำหรับ current tax TH report จะอยู่ใน ACDOCA field ของ LC3 ไม่ว่าจะเป็น standard หรือ custom solution ฝั่ง GL” → แปลว่าถ้าทีม GL เปลี่ยนวิธีทำ revaluation รายงานนี้ไม่ต้องแก้ ตราบใดที่ค่ายังลงที่ LC3

Segment ที่เปลี่ยนชื่อ + Layout ทั้ง 8

การเปลี่ยนชื่อ segment ดูเล็ก แต่กระทบทุก config ที่อ้างชื่อเดิม

Segment code — ECC → S/4HANA

#	ECC (เดิม)	S/4HANA (ใหม่)	ความหมาย
1	`CIT_RC`	`CIT_TH`	Corporate Income Tax — ธุรกิจปกติในไทย
2	`PITA1`	`PITA1_TH`	Petroleum Income Tax Act — ระบบสัมปทาน (ชุดที่ 1)
3	`PITA3`	`PITA3_TH`	PITA ชุดที่ 3
4	`PITA4`	`PSC_TH`	เปลี่ยนความหมายชัดเจนขึ้น — Production Sharing Contract
5	`MTJDA`	`MTJDA`	Malaysia–Thailand Joint Development Area (ไม่เปลี่ยน)

ทำไม PITA4 → PSC_TH ถึงสำคัญกว่าที่คิด: ชื่อเดิมสื่อว่าเป็น “PITA ตัวที่ 4” แต่จริง ๆ เป็น ระบบภาษีคนละแบบ (แบ่งปันผลผลิต ไม่ใช่สัมปทาน) การเปลี่ยนชื่อทำให้ คนอ่านรายงานเข้าใจถูกทันที และสอดคล้องกับ segment ต่างประเทศที่ใช้ PSC_* เหมือนกัน (ดู TAX-RPT-4 — PSC_DZ, PSC_MM, PSC_VN, PSC_OM, PSC_MY)

Report layout ทั้งหมดใน S/4HANA

#	ECC	S/4HANA	Company code ตัวอย่าง
1	CIT_RC	`CIT_TH`	TH01 Client · XB01 (สาขาต่างประเทศ)
2	PITA1	`PITA1_TH`	—
3	PITA3	`PITA3_TH`	—
4	PITA4	`PSC_TH`	—
5	IBC-SVCS	`IBC-SVCS`	1013 Client SERVICES
6	IHQ	`IBC-TC` (เปลี่ยน)	1086 Client TC
7	—	`BOI` (ใหม่)	1126 FST
8	MTJDA	`MTJDA`	—

IHQ (International Headquarters) เป็นสิทธิประโยชน์ทางภาษีรุ่นเก่าที่ถูกยกเลิก และแทนที่ด้วย IBC (International Business Center) — จึงต้องเปลี่ยนทั้งชื่อ layout, ชื่อตาราง และ checkbox บนหน้าจอ

ตาราง custom 13 ตัว — อะไรเปลี่ยน อะไรไม่เปลี่ยน

ตารางชุดนี้คือ “สมอง” ของรายงาน · ถูกใช้ร่วมกับ ZTAXA_R06/038/039 และ interface ไป BI

Table	หน้าที่	Delta ใน S/4HANA	Field type
`ZTAXA_T05`	Node master	ไม่เปลี่ยนโครงสร้าง (ข้อมูล node เปลี่ยนได้)	—
`ZTAXA_T06`	Define node + description	เพิ่ม Proportion/Fixed และ Fixed Rate	CHAR 1 · CHAR 5
`ZTAXA_T01`	GL account mapping	เพิ่ม Valid From / Valid To	DATS 8
`ZTAXA_T07`	Define report layout	เพิ่ม Valid From / Valid To / Proportion-Fixed + layout BOI + layout IBCTC	DATS 8 · DATS 8 · CHAR 1
`ZTAXA_T03`	Upload data (flat file)	เพิ่ม RLDNR (Ledger) · check table = `FINSC_LD_CMP`	CHAR 2
`ZTAXA_T08`	Exclude asset class	รวม 029+030+031+032 เป็นตารางเดียว · เพิ่ม Segment (custom) + Include/Exclude	CHAR 10 · CHAR 1 · CHAR 1
`ZTAXA_T14`	(เดิม: exclude asset class PITA1/PITA3)	ยุบเข้า T029	—
`ZTAXA_T15`	(เดิม: exclude asset class MTJDA)	ยุบเข้า T029	—
`ZTAXA_T16`	(เดิม: asset class Pre-OP)	ยุบเข้า T029	—
`ZTAXA_T11`	Tax rate for tax filing	ไม่เปลี่ยน	—
`ZTAXA_T04`	Trading partner ต่อ tax rate (IBC-TC)	เพิ่ม Valid From / Valid To · เปลี่ยนชื่อ field Partner PC → Trading Partner	DATS 8
`ZTAXA_T02`	Company code สำหรับ IBC/BOI	โครงสร้างไม่เปลี่ยน · เปลี่ยนชื่อตาราง IHQ → IBC/BOI	—
`ZTAXA_T10`	IBC tax rate + trading partner จาก customers	โครงสร้างไม่เปลี่ยน · เปลี่ยนชื่อ IHQ → IBC	—

3 delta ที่ต้องเข้าใจ “ทำไม” ไม่ใช่แค่ “อะไร”

ก) Valid From / Valid To — ทำไมต้องมี

รายงานภาษีต้องรันย้อนหลังได้ (ตรวจสอบ/แก้ไขแบบยื่นเก่า) ถ้า mapping หรือ layout เปลี่ยนกลางทาง การรันปีเก่าจะได้ผลลัพธ์ตาม config ปัจจุบัน = ผิด Valid From/To ทำให้โปรแกรม เลือก config ที่ใช้อยู่ ณ ปีที่รายงาน — FD ระบุว่า “Report should display same data as per the reporting year … with historical values and layout”

ข) GL account prefix A/B/C — เคล็ดลับ `*999999999`

ผังบัญชี S/4HANA ของ Client ขึ้นต้นด้วย A, B หรือ C (เช่น A999X042, B_PC07, C_PC34) ถ้า map ทีละตัวอักษรจะได้ 3 แถวต่อ 1 บัญชี → บวม FD จึงกำหนดให้ใช้ *999999999 — ดอกจันแทนตัวอักษรนำหน้า เพื่อ “รวมยอดของทั้ง 3 ตัวในแถวเดียว”

ตัวอย่าง: ต้องการยอดรวมของ A999X042 + B_PC07 + C_PC34 maintain ใน ZTAXA_T01 เป็น *999999999 (1 แถว แทน 3 แถว)

ค) RLDNR ใน upload table — ทำไมเพิ่งมามี

ECC มี ledger เดียวในบริบทนี้ แต่ S/4HANA มี หลาย ledger (0L, T1 …) รายการปรับปรุงที่อัปโหลดจึงต้องระบุว่า “ปรับที่ ledger ไหน” check table FINSC_LD_CMP คือ ตารางกำหนด ledger ต่อ company code → กันไม่ให้ใส่ ledger ที่บริษัทนั้นไม่มี

ผลกระทบข้ามระบบที่ FD เตือนไว้: การเปลี่ยนโครงสร้างตารางชุดนี้กระทบ (ก) Annual Tax Report (P2) และ (ข) Interface ส่งข้อมูลไป BI (ZTAXA_I01) → เวลาแก้ตารางต้องแจ้ง 2 ทีมนี้เสมอ · นี่คือเหตุผลที่ FD ลงตารางว่าตารางไหนถูกใช้โดยโปรแกรมใดบ้าง

Selection screen — delta ทุกช่อง

หน้าจอ TO-BE แบ่ง 4 block: General Selection (Main) · Display Report · General Selection (Branch) · Display Currency

Field	Delta	Default	Validation / หมายเหตุ
Company code (Main)	เพิ่ม multiple selection	—	ใส่หลาย company code ได้พร้อมกัน
Reporting Year / Period	ไม่เปลี่ยน	—	—
Profit center	ไม่เปลี่ยน	—	—
Recovery Indicator	ใหม่	Blank	จาก `T8JJ-RECID` · validate คู่กับ `BUKRS`
Exclude profit center O*	ถูกลบออก	—	S/4 ต้องรวม profit center ที่ขึ้นต้นด้วย O ด้วย
Depreciation Area (Main)	เปลี่ยน default	32	แก้ไขได้ (editable)
Ledger (Main)	เปลี่ยน default	T1	แก้ไขได้
Segment (Main)	ไม่เปลี่ยน	—	—
BOI (checkbox)	ใหม่ — มาแทน IHQ	Blank	validate กับ `ZTAXA_T02` — ถ้า company code ผูก BOI อยู่ต้องติ๊ก มิฉะนั้น error “please select BOI checkbox”
IBC (checkbox)	ไม่เปลี่ยนโครง · เพิ่ม validation	—	ติ๊กแต่ไม่มีใน T035 → error “Please do not select IBC” · มีใน T035 แต่ไม่ติ๊ก → error “Please select IBC”
Company code (Branch)	ใหม่	None	optional · multiple · ไม่มี validation กับ main · ถ้า main ใส่หลายตัว → field นี้ถูก grey out
Profit Center (Branch)	ใหม่	None	multiple selection
Recovery Indicator (Branch)	ใหม่	None	validate `T8JJ` คู่กับ branch company code
Depreciation area (Branch)	ใหม่	02	default เมื่อใส่ branch company code · editable
Ledger (Branch)	ใหม่	0L	default เมื่อใส่ branch company code · editable
Segment (Branch)	ใหม่	None	ใช้เมื่อใส่ branch เท่านั้น
Display currency	ไม่เปลี่ยน	LC2	radio LC1 / LC2 / LC3 · เปลี่ยนได้

Default 4 ตัวที่ต้องท่อง (ถูกถามบ่อยใน KT)

Main → Depreciation area 32 · Ledger T1 (มุมมองภาษี)
Branch → Depreciation area 02 · Ledger 0L (มุมมองบัญชีมาตรฐาน)
สกุลเงินแสดงผล → LC2
ต้องมี option รัน background เพราะข้อมูลใหญ่

⚠ Authorization ที่ FD สั่งไว้ตรง ๆ: “Must add authorization to company code XB01 Client (overseas branch) which is a branch of registered company in Thailand.” → XB01 อยู่ที่แอลจีเรีย แต่ทางภาษีเป็นสาขาของบริษัทไทย จึงต้องรวมยอดในรายงานไทย (TC-004) นี่คือเหตุผลที่ต้องมี block “Branch” ทั้งชุด

LC1 / LC2 / LC3 — ดึงจาก field ไหนของ ACDOCA

ECC ใช้แค่ LC2 · S/4HANA เพิ่ม LC3 เข้ามา

Currency	Table	Amount field	Currency field	ความหมาย
LC1	`ACDOCA`	`HSL`	`RHCUR`	Company code currency (สกุลของบริษัท)
LC2	`ACDOCA`	`KSL`	`RKCUR`	Global currency (สกุลกลุ่ม)
LC3	`ACDOCA`	`OSL`	`ROCUR`	Freely defined currency 1 (สกุลอิสระ — ใช้เก็บค่าที่ตีราคาใหม่)

ลำดับการทำงาน

รับ parameter จากหน้าจอ: company code, reporting year, period, profit center, recovery indicator, depreciation area, ledger, segment, LC1/2/3
ส่งค่าทั้งหมดเข้า ACDOCA
หา เลขบัญชี RACCT จาก mapping table ZTAXA_T01 ผ่าน item type ใน layout
ดึงยอดตามคู่ field ของสกุลที่เลือก (HSL/RHCUR · KSL/RKCUR · OSL/ROCUR)

วิธีจำ 3 คู่นี้: HSL = Home (บริษัท) · KSL = Konzern (กลุ่ม/global) · OSL = Other (freely defined) · ส่วนสกุลเงินคือ R + ตัวอักษรเดิม + CUR → เป็นชุดเดียวกับที่ TAX-RPT-4 ใช้ ไม่ต้องจำใหม่

Manual adjustment ที่ย้ายมาดึงจากระบบ (5 รายการ)

เจตนา: “Client wants to minimize the manual data which comes from uploading flat files”

#	Item type	สูตร	ใช้กับ layout
1	LOSS CARRIED FORWARD	ดึงจากตารางของ TAX-RPT-5 (`ZTAXB_T01`) แทนอัปโหลด	ทุก layout
2	UNREALIZED GAIN/LOSS ON FINANCIAL DERIVATIVES ผ่าน OCI	`A490X036` + `A490X037` + `A490X038` · กลับเครื่องหมาย	CIT_TH · PITA1_TH · PITA3_TH · PSC_TH
3	ACCRUED INTEREST FROM FINANCIAL DERIVATIVES	`A460X032` + `A560X041` · กลับเครื่องหมาย	CIT_TH · PITA1_TH · PITA3_TH · PSC_TH
4	ADJUST WRITE-OFF FROM IDC	`A520X040` · กลับเครื่องหมาย	PITA1_TH · PITA3_TH · PSC_TH
5	RETIREMENT RESERVE — COVENTURERS / JCE	movement ของ `A254X027` = ยอดต้นงวด − ยอดปลายงวด	PITA1_TH · PITA3_TH · PSC_TH

สูตรกลางที่ใช้กับ “ทุก layout”

ANNUAL (PROFIT)/LOSS AFTER LCF = ANNUAL (PROFIT)/LOSS − ALLOWANCES − Loss carried forward (ดึงจาก custom table ZTAXB_T01) − Loss carried forward adjustment (ปรับด้วย flat file) ใช้กับ: CIT_TH · PITA1_TH · PITA3_TH · PSC_TH · MTJDA · IBCSVCS · IBC-TC · BOI

ปีก่อน
ANNUAL (P/L) AFTER LCF → ถ้าเป็น ยอดเดบิต = ขาดทุน
เก็บลง ZTAXB_T01 → ปีนี้
โผล่เป็น “Loss carried forward”

⚠ “กลับเครื่องหมาย (reverse sign)” คืออะไร และทำไมต้องทำ: ยอดใน GL ใช้ convention เดบิต/เครดิตของบัญชี ส่วนรายงานภาษีใช้ convention “บวก = เพิ่มกำไรทางภาษี” ซึ่งอาจตรงข้ามกัน ถ้าลืมกลับเครื่องหมาย → กำไรทางภาษีจะผิดทิศ และภาษีที่คำนวณได้จะผิดทั้งก้อน ให้เช็คทุกครั้งว่าบรรทัดนั้นระบุ reverse sign หรือไม่ — 3 ใน 5 รายการข้างบนระบุไว้ชัด

ข้อสังเกตเชิงวิเคราะห์: รายการที่ 4 และ 5 ใช้กับ PITA1_TH / PITA3_TH / PSC_TH แต่ ไม่ใช้กับ CIT_TH — เพราะ IDC (Intangible Drilling Cost) และ retirement reserve เป็นเรื่องของ ธุรกิจปิโตรเลียมโดยเฉพาะ ไม่มีในบริษัททั่วไป · การรู้ว่ารายการไหนใช้กับ layout ไหน ทำให้คุณตอบได้ทันทีว่า “ทำไมบรรทัดนี้ไม่โผล่ในรายงานของบริษัท A”

IBCSVCS — company code 1013 (Client SERVICES)

การเปลี่ยน 2 รายการจาก “proportion” เป็น “fixed rate”

หลักการพื้นฐานของ IBC

ระบบอ่าน ZTAXA_T02 (company code ผูก IBC) + ZTAXA_T04 (trading partner ต่ออัตรา)
ธุรกรรมกับ trading partner ที่เป็น intercompany → ตกคอลัมน์ 3%
ธุรกรรมที่ ไม่ใช่ intercompany → ตกคอลัมน์ 20%

ข้อยกเว้น 2 รายการที่ FD สั่งให้ทำ “fixed”

Item type	Node	Item type code	เปลี่ยนเป็น
EXPENSE POOL COST → “EXPENSES SPECIFIC 20%”	`HGL4`	`HG6`	Fixed 20% — ลงคอลัมน์ 20% ทั้งก้อน ไม่แบ่งสัดส่วน
ACTUAL PAYMENT FOR PENSION FUND	`TCL1`	`TG21`	Fixed 3% — ย้ายจาก 20% มา 3% ทั้งก้อน

กลไก: field “Proportion/Fixed” + “Fixed Rate”

ZTAXA_T06 / ZTAXA_T07 → field Proportion/Fixed ค่า F = Fixed rate → ต้องกรอก Fixed Rate ด้วย (เช่น 20% / 3%) ค่า P = Proportion → คำนวณตามสัดส่วน ค่า Blank = ใช้กับ layout อื่น (MTJDA / CIT / PITA) ตัวอย่างแถวจริง: Node = TCL1 · Type = TG21 · Description = ACTUAL PAYMENT FOR PENSION FUND Order = 1 · Proportion/Fixed = F · Fixed Rate = 3%

Logic การดึงยอด

อ่าน G/L accounts ที่ผูกกับ item type จาก ZTAXA_T01
ส่ง G/L account เข้า ACDOCA ดึงยอด
แสดง ยอดรวมของ item type และ ยอดแยกราย G/L account (กรณีมีหลายบัญชีผูกกับ item type เดียว)
ลงคอลัมน์ตาม fixed rate ที่กำหนด (ไม่ผ่านกติกา intercompany)

Design ที่ควรชม: แทนที่จะ hard-code “20%” ลงในโค้ด FD เลือกใส่ไว้ใน ตาราง config (Proportion/Fixed + Fixed Rate) → ถ้ากฎหมายเปลี่ยนอัตรา แค่แก้ตาราง ไม่ต้องแก้โปรแกรม และ FD ยังเผื่อไว้ว่า “ในอนาคตเมื่อสิทธิ IBC หมดอายุ ให้ปรับ validity ใน ZTAXA_T02 แล้ว output กลับไปใช้ layout CIT_TH ปกติ”

IBCTC — company code 1086 (Client TC · Treasury Centre)

ธุรกิจการเงิน — รายได้ 4 ประเภท และการปันสัดส่วน 3% / 20%

รายได้ของ Client TC

Interest Income (ดอกเบี้ยรับ)
Service income (ค่าบริการ)
Gain from trading investment (กำไรจากเงินลงทุน)
Gain from derivative instrument (กำไรจากตราสารอนุพันธ์)

Layout เปลี่ยน — คอลัมน์ที่หายและที่เพิ่ม

คอลัมน์	ECC	S/4HANA	ความหมาย
0%	มี	ลบออก	ไม่ใช้แล้ว
10%	มี	ลบออก	ไม่ใช้แล้ว
A — IBC 3%	มี	มี	ธุรกรรม intercompany · ระบุด้วย `R001` ใน `ZTAXA_T04` ผ่าน trading partner
B — Non-IBC 20%	มี	มี	ธุรกรรม ไม่ใช่ intercompany
C — Total	—	เพิ่มใหม่	C = A + B
D — ยอดต่อ Profit Center	มี	มี (ขยายได้หลายคอลัมน์)	ยอด G/L จาก `ZTAXA_T01` ราย profit center
Check difference	มี	มี	= D − C · ควรเป็น 0

คอลัมน์ “Check difference” คือ built-in control: D คือยอดจริงจาก GL · C คือยอดที่ถูกปันเข้า 3%/20% แล้ว ถ้า D − C ≠ 0 แปลว่า มีบางรายการปันไม่เข้าคอลัมน์ไหนเลย (เช่น trading partner ไม่มีใน ZTAXA_T04) → เป็นจุดแรกที่ต้องดูตอนกระทบยอด ไม่ต้องไล่ทีละบรรทัด

Logic การจัดคอลัมน์ (จาก ACDOCA line-item)

หา G/L account ที่ผูกกับ item type จาก ZTAXA_T01
ดึงยอดจาก ACDOCA ตาม selection (company code, fiscal year, ledger, period …)
อ่าน trading partner = VBUND ที่ระดับ line item
ตรวจกับ ZTAXA_T04 → intercompany ลง 3% · ไม่ใช่ ลง 20% · แยกตาม profit center ด้วย

สูตรสำคัญ (node/type formula)

HCL4 (Total Revenue) = (HG3 หรือ HG3.1) + HG3.2 + HG3.4 + HG3.5 ดอกเบี้ยรับ + ค่าบริการ + กำไรเงินลงทุน + กำไรอนุพันธ์ HUP = (HG3 หรือ HG3.1) + HG3.2 + HG3.4 + HG3.5 + PU8 HCL5 (Revenue adjustment uploaded) = HCL4 + HUP HC4 (Revenue After Adjustment) = HG3 + PU8 HCL0 / HC3 = % Portion of Interest Income คอลัมน์ 3% = ดอกเบี้ยรับในคอลัมน์ 3% ÷ ดอกเบี้ยรับทั้งหมด คอลัมน์ 20% = ดอกเบี้ยรับในคอลัมน์ 20% ÷ ดอกเบี้ยรับทั้งหมด HCL3 / HC6 = % Proportion of Revenue คอลัมน์ 3% = Total Revenue ในคอลัมน์ 3% ÷ Total Revenue ทั้งหมด คอลัมน์ 20% = Total Revenue ในคอลัมน์ 20% ÷ Total Revenue ทั้งหมด

รายการที่ปันตามสัดส่วน (proportion) แทนการดูที่ trading partner

Item type	ปันตามอะไร
Admin employee expenses · Admin selling expenses	% Proportion of Revenue
Interest Expense	% Portion of Interest Income (ไม่ใช่ revenue)
Others	% Ratio of Revenue
Expense แต่ละบรรทัด	ยอดในบรรทัด × % Proportion of revenue ของคอลัมน์นั้น

กำไร/ขาดทุนจากเงินลงทุนและอนุพันธ์ — ดึงจากด้านไหน

Item type	ดึงจากด้าน	Field
Gain from Trading investment	เครดิต	`ACDOCA-SHKZG = 'H'`
Gain from Derivative instrument	เครดิต	`SHKZG = 'H'`
Loss from Trading investment	เดบิต	`SHKZG = 'S'`

⚠ ทำไมต้องแยก H / S แทนที่จะใช้เครื่องหมายของยอด: บัญชีเดียวกันอาจมีทั้งบรรทัดกำไรและขาดทุนปนกัน — ถ้าเอายอดสุทธิ จะได้ “กำไรสุทธิ” ซึ่ง ไม่ใช่สิ่งที่กฎหมายภาษีต้องการ (กำไรกับขาดทุนอาจถูกปฏิบัติต่างกัน) จึงต้องแยกอ่านด้วย SHKZG ที่ระดับ line item → เป็นเหตุผลว่าทำไมรายงานนี้ต้องอ่าน ACDOCA ระดับบรรทัด ไม่ใช่ยอดสรุป

BOI — layout ใหม่ · company code 1126 (FST)

สิทธิประโยชน์ BOI แยกด้วย profit center · มีเพดาน 2% ที่ต้องคำนวณเอง

โครงสร้าง profit center ที่ใช้แยก BOI / Non-BOI

กลุ่ม	ตัวอย่าง Profit Center
Corporate	`B_PC01`
BOI 1	`B_PC02`
BOI 2	`B_PC04`
Non-BOI 1	`B_PC03`
Non-BOI 2	`B_PC05`

ถ้ามี BOI/Non-BOI ใหม่ เลข หลักที่ 8 และ 9 จะเดินต่อ — สังเกตว่า หลักสุดท้าย 1 = BOI · 2 = Non-BOI

โครงคอลัมน์ของรายงาน BOI

ฝั่ง	คอลัมน์
TB (Trial Balance — ตามที่ระบบบันทึกจริง)	Profit Ctr-Corp · Profit Ctr-BOI 1 · Profit Ctr-BOI 2 · Profit Ctr-Non BOI 1 · Profit Ctr-Non BOI 2 · Total
Tax closing (หลังปันส่วนตามกติกาภาษี)	BOI 1 · BOI 2 · Non BOI 1 · Non BOI 2 · Total per Tax Closing

แนวคิดหลักของ layout นี้: ฝั่งซ้าย (TB) = ความจริงทางบัญชี · ฝั่งขวา (Tax closing) = ความจริงทางภาษีหลังปันส่วน — สองฝั่งไม่จำเป็นต้องเท่ากันในระดับคอลัมน์ แต่ ยอดรวมต้องเท่ากัน · นี่คือ control ที่ผู้ใช้ต้องดูทุกเดือน

กติกา 6 ข้อ

Direct Income แยก BOI/Non-BOI ตาม profit center · % สัดส่วนคำนวณจาก Direct Income เท่านั้น — ไม่นับ other income, FX gain/loss, interest income · Total Revenue = Total Direct income (TB) + Total others income (TB)
ดอกเบี้ยรับจากเงินกู้ intercompany / เงินฝากประจำ → เข้า Non-BOI เสมอ ที่ฝั่ง Tax closing · ยอดที่อยู่ใต้ Corporate ให้ยกไปรวมที่ Non-BOI · Total (Tax closing) = Corporate + Non-BOI จาก TB
ดอกเบี้ยรับจากเงินฝากออมทรัพย์ มีเพดาน 2% ของ Direct Income ของ BOI แต่ละตัว (ดูตัวอย่างคำนวณข้างล่าง)
FX Gain/Loss: ถ้า Non-BOI ไม่มีรายได้ (Direct income = 0 ตาม TB) → ผลขาดทุน (เดบิต) ไปลง BOI · ผลกำไร (เครดิต) ไปลง Non-BOI · ถ้า Non-BOI มีรายได้ → ปันตามสัดส่วนปกติ
Operating cost/expenses ของ corporate profit center → ปันระหว่าง BOI/Non-BOI ตามสัดส่วนรายได้ในข้อ 1
Expense adjustments → มาจาก flat file ตาม tax rate ที่ระบุในไฟล์

⚠ ข้อ 4 คือกติกาที่ “ดูไม่สมมาตร” และคนมักคิดว่าเป็นบั๊ก: ขาดทุนไป BOI แต่กำไรไป Non-BOI — เพราะเป็นหลักภาษีที่อนุรักษ์นิยม (กำไรควรถูกเก็บภาษี = ไปฝั่งที่เสียภาษี · ขาดทุนไม่ควรใช้ลดภาษี = ไปฝั่งที่ยกเว้นภาษีอยู่แล้ว) ถ้าไม่รู้ที่มา จะรายงานเป็น defect ผิด ๆ

ตัวอย่างคำนวณเพดาน 2% (ตัวเลขจาก FD)

ขั้นที่ 1 — Direct Income ตาม TB

Profit center	Direct income	% ของ Total DI	เพดาน 2%
Corporate	0	—	—
BOI 1	1,000,000	27.027%	20,000
BOI 2	2,000,000	54.054%	40,000
Non-BOI 1	200,000	5.4054%	—
Non-BOI 2	500,000	13.5135%	—
Total DI	3,700,000	100%	60,000

ขั้นที่ 2 — ดอกเบี้ยรับออมทรัพย์ตาม TB และการปันของ Corporate

Profit center	ตาม TB	ได้รับปันจาก Corporate (30,000)
Corporate	30,000	→ กระจายออก
BOI 1	25,000	27.027% × 30,000 = 8,108.1
BOI 2	30,000	54.054% × 30,000 = 16,216.2
Non-BOI 1	5,000	5.4054% × 30,000 = 1,621.62
Non-BOI 2	7,000	13.5135% × 30,000 = 4,054.05
รวม	97,000	30,000

ขั้นที่ 3 — ใส่เพดาน แล้วโยนส่วนเกินไป Non-BOI

BOI 1: ควรได้ 25,000 + 8,108.1 = 33,108.1 แต่เพดาน = 20,000 → Tax closing BOI 1 = 20,000 → ส่วนเกิน = 5,000 (จาก BOI1) + 8,108.1 (จาก corporate) = 13,108.1 Non-BOI 1 = 5,000 (TB) + 1,621.62 (ปัน) + 5,000 + 8,108.1 (ส่วนเกินจาก BOI1) = 19,729.72 BOI 2: ควรได้ 30,000 + 16,216.2 = 46,216.2 แต่เพดาน = 40,000 → Tax closing BOI 2 = 40,000 → ส่วนเกิน = 6,216.2 (จาก corporate) Non-BOI 2 = 7,000 (TB) + 4,054.05 (ปัน) + 6,216.2 (ส่วนเกินจาก BOI2) = 17,270.25 ตรวจยอดรวม: 20,000 + 40,000 + 19,729.72 + 17,270.25 = 97,000 ✔ เท่ากับ TB

3 บทเรียนจากตัวอย่างนี้

สัดส่วนคำนวณจาก Direct Income แต่ เอาไปปันดอกเบี้ยรับ — คนละฐาน อย่าสับสน
เพดานคิดจาก DI ของ BOI นั้น ๆ ไม่ใช่จากยอดดอกเบี้ยที่ได้รับ (2% × 1,000,000 = 20,000)
ยอดรวมต้องไม่เปลี่ยน — ส่วนเกินไม่ได้หายไป แต่ถูกโยนไป Non-BOI คู่ของมัน (BOI1→Non-BOI1, BOI2→Non-BOI2)

Key Test Conditions — TC-001 ถึง TC-015

Precondition ของทั้งชุด: “Ensure that the necessary non-SAP data has been uploaded prior to executing this report”

Test ID	Condition	Expected result
TC-001	เลือก segment CIT_TH / PITA1_TH / PITA3_TH / PSC_TH / MTJDA	แสดง layout ตาม segment ที่เลือก
TC-002	Layout IBCSVCS ของ 1013	ค่าออกตาม calculation logic ใหม่ (fixed 20% / 3%)
TC-003	Layout IBCTC ของ 1086	แสดงคอลัมน์ 3% และ 20% เท่านั้น — 0% และ 10% ต้องหายไป
TC-004	เลือกหลาย company code — XB01 (สาขาต่างประเทศ) + TH01 Client segment CIT_TH	แสดงข้อมูลรวมของทั้งสอง
TC-005	ใส่เงื่อนไขบน selection screen	รายงานตรงกับเงื่อนไขที่ใส่
TC-006	Branch company code	มี field สำหรับ branch ให้กรอกครบ
TC-007	BOI checkbox	มี checkbox บนหน้าจอ · ดึง layout BOI ให้ company code 1126
TC-008	BOI Layout	รายงานแสดง layout BOI ถูกต้อง
TC-009	BOI report logic	ค่าฝั่ง Tax closing (BOI / Non-BOI) คำนวณถูก
TC-010	`ZTAXA_T10` logic	cost center ที่ไม่ได้ระบุในตาราง → ใช้อัตรา default (ปัจจุบัน 3%) · ที่ระบุไว้ → ใช้อัตราในตาราง
TC-011	Manual adjustment ที่ดึงจากระบบ	ค่าถูกดึงจาก GL ตามสูตร ไม่ต้องอัปโหลด
TC-012	Loss carried forward	ดึงยอดปีก่อนจาก custom table มาแสดงเป็น LCF ของปีปัจจุบัน
TC-013	Performance	ข้อมูลใหญ่ — ต้องเร็ว และมี option รัน background
TC-014	Proportion / Fixed Rate logic ของ IBC	ค่าออกตามที่ maintain ใน `ZTAXA_T06` และ `ZTAXA_T07`
TC-015	Validation ทั้งหมด	ทุก validation ทำงาน (BOI/IBC checkbox, recovery indicator ฯลฯ)

Expert notes

1) “Retrofit with change” + “delta document” = ต้องอ่าน 2 เอกสาร

FD นี้เขียนเฉพาะสิ่งที่เปลี่ยน — logic เดิมทั้งหมดอยู่ใน FS ZTAXA_R05 Current Tax V0.1.docx ของ ECC เวลาทำ FUT ห้ามเทสต์แค่ delta เพราะ regression มักเกิดที่ส่วนที่ “ไม่ได้เปลี่ยน” แต่ถูกกระทบจากการยุบตาราง T029–T032 และการเพิ่ม Valid From/To

2) ความสัมพันธ์ 3 objects ในชุด Current Tax

TAX-RPT-3
Current Tax · ไทย ↘ ZTAXB_T01
LCF store (TAX-RPT-5) ↙ TAX-RPT-4
Current Tax · ต่างประเทศ

RPT-3 และ RPT-4 ต่างมีปุ่ม “Update table for LCF” บนหน้า output → เขียนค่าลง ZTAXB_T01
RPT-5 คือ รายงานอ่านค่าจากตารางนั้น + จัดการ conversion LC1→LC2
RPT-4 ยืมตาราง ZTAXA_T05/025/027/028/029/035 ของ RPT-3 โดยเพิ่ม flag “Overseas” เพื่อแยกข้อมูล

3) การยุบตาราง T029–T032 กระทบอะไร

FD เตือนไว้ตรง ๆ ว่า “As we combine these tables, logic in the backend also need to be adjusted accordingly” กติกาใหม่คือ: asset class ที่เหมือนกันทั้ง PITA1_TH/PITA3_TH/PSC_TH ให้ maintain ครั้งเดียวใต้ PITA_TH (segment รวมที่เก็บใน constants table) ส่วน asset class ที่เป็นของ segment ใด segment หนึ่งโดยเฉพาะ ให้แยกบรรทัด

4) ทำไมต้องเลิก “Exclude profit center O*”

ใน ECC profit center ที่ขึ้นต้นด้วย O ถูกกันออกจากรายงานภาษีโดยอัตโนมัติ แต่ใน S/4HANA ผังบัญชี/ผัง profit center ถูกออกแบบใหม่ ทำให้ prefix นั้นไม่ได้แปลว่า “ไม่เกี่ยวกับภาษี” อีกต่อไป → การเก็บ validation เดิมไว้จะทำให้ ยอดหาย อย่างเงียบ ๆ นี่คือ delta ที่อันตรายที่สุดในหน้าจอ เพราะไม่มี error ให้เห็น

5) Checklist กระทบยอดรายเดือน (ใช้ได้จริง)

5 จุดที่ต้องดูก่อนส่งตัวเลขให้ทีมภาษี

(1) node CL ทุกตัวมีต้นทางครบไหม (ไม่มีศูนย์ที่ไม่ควรเป็นศูนย์) · (2) IBCTC — Check difference = 0 ทุกบรรทัด · (3) BOI — ยอดรวมฝั่ง TB = ยอดรวมฝั่ง Tax closing · (4) LCF ที่ดึงมาตรงกับที่ RPT-5 แสดง · (5) manual adjustment 5 รายการ — เครื่องหมายถูกทิศไหม

Self-check

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

1. Segment PITA4 ใน ECC กลายเป็นอะไรใน S/4HANA และทำไม?

กลายเป็น PSC_TH — เพราะจริง ๆ แล้วเป็นระบบ Production Sharing Contract ไม่ใช่ PITA ตัวที่ 4 · ชื่อใหม่สอดคล้องกับ segment ต่างประเทศ (PSC_DZ, PSC_MM, PSC_VN, PSC_OM, PSC_MY)

2. เขียนสูตร ANNUAL (PROFIT)/LOSS AFTER LCF

= ANNUAL (PROFIT)/LOSS − ALLOWANCES − Loss carried forward (จาก custom table) − Loss carried forward adjustment · ใช้กับทุก layout: CIT_TH, PITA1_TH, PITA3_TH, PSC_TH, MTJDA, IBCSVCS, IBC-TC, BOI

3. Default ของ Depreciation area และ Ledger ต่างกันอย่างไรระหว่าง Main กับ Branch?

Main: Dep. area 32 · Ledger T1 (มุมมองภาษี) · Branch: Dep. area 02 · Ledger 0L (มุมมองบัญชีมาตรฐาน) ทั้งคู่ editable · เหตุผลคือสาขาถูกบันทึกในระบบตามมาตรฐานบัญชี แล้วค่อยนำมารวมทางภาษี

4. IBCTC ตัดสินว่ารายการไหนเป็น 3% จากอะไร?

จาก trading partner — field VBUND ใน ACDOCA ที่ระดับ line item แล้ว validate กับ ZTAXA_T04 (intercompany = R001) intercompany → คอลัมน์ 3% · ไม่ใช่ → คอลัมน์ 20%

5. BOI — เพดานดอกเบี้ยออมทรัพย์คำนวณจากอะไร และส่วนเกินไปไหน?

เพดาน = 2% × Direct Income ของ BOI นั้น (ตาม TB) · ส่วนที่เกินเพดาน ไม่หายไป แต่ถูกโยนไป Non-BOI คู่ของมัน (BOI1 → Non-BOI1 · BOI2 → Non-BOI2) ยอดรวมจึงเท่าเดิมเสมอ

6. ทำไม ZTAXA_T01 ต้องมี Valid From / Valid To?

เพื่อให้รันย้อนหลังได้ถูกต้อง — เมื่อ GL mapping เปลี่ยน การรันปีเก่าต้องใช้ mapping ของปีนั้น ไม่ใช่ mapping ปัจจุบัน · FD ระบุว่า “report should display same data as per the reporting year with historical values and layout” (ZTAXA_T07 ก็มีเหตุผลเดียวกันสำหรับ layout)

7. *999999999 ใน GL mapping หมายความว่าอะไร?

ให้รวมยอดของ A999X042 + B_PC07 + C_PC34 ในแถวเดียว — ดอกจันแทนตัวอักษรนำหน้าของผังบัญชี S/4HANA เพื่อลดจำนวนแถวที่ต้อง maintain ลง 3 เท่า

8. รายงานนี้ส่งข้อมูลต่อให้ใครบ้าง?

(1) Annual Tax Report (P2 · ZTAXA_R07) · (2) BI Interface ผ่าน ZTAXA_I01 · (3) TAX-RPT-5 LCF ผ่านปุ่ม “Update table for LCF” → ZTAXB_T01 — เพราะแบบนี้การแก้โครงตารางจึงต้องแจ้งหลายทีม

ภาพรวม — รายงานนี้คำนวณอะไร

3 ประเภท node — จำให้ขึ้นใจ

Assumption สำคัญของ FD

Segment ที่เปลี่ยนชื่อ + Layout ทั้ง 8

Segment code — ECC → S/4HANA

Report layout ทั้งหมดใน S/4HANA

ตาราง custom 13 ตัว — อะไรเปลี่ยน อะไรไม่เปลี่ยน

3 delta ที่ต้องเข้าใจ “ทำไม” ไม่ใช่แค่ “อะไร”

ก) Valid From / Valid To — ทำไมต้องมี

ข) GL account prefix A/B/C — เคล็ดลับ *999999999

ค) RLDNR ใน upload table — ทำไมเพิ่งมามี

Selection screen — delta ทุกช่อง

LC1 / LC2 / LC3 — ดึงจาก field ไหนของ ACDOCA

ลำดับการทำงาน

Manual adjustment ที่ย้ายมาดึงจากระบบ (5 รายการ)

สูตรกลางที่ใช้กับ “ทุก layout”

IBCSVCS — company code 1013 (Client SERVICES)

หลักการพื้นฐานของ IBC

ข้อยกเว้น 2 รายการที่ FD สั่งให้ทำ “fixed”

กลไก: field “Proportion/Fixed” + “Fixed Rate”

Logic การดึงยอด

IBCTC — company code 1086 (Client TC · Treasury Centre)

รายได้ของ Client TC

Layout เปลี่ยน — คอลัมน์ที่หายและที่เพิ่ม

Logic การจัดคอลัมน์ (จาก ACDOCA line-item)

สูตรสำคัญ (node/type formula)

รายการที่ปันตามสัดส่วน (proportion) แทนการดูที่ trading partner

กำไร/ขาดทุนจากเงินลงทุนและอนุพันธ์ — ดึงจากด้านไหน

BOI — layout ใหม่ · company code 1126 (FST)

โครงสร้าง profit center ที่ใช้แยก BOI / Non-BOI

โครงคอลัมน์ของรายงาน BOI

กติกา 6 ข้อ

ตัวอย่างคำนวณเพดาน 2% (ตัวเลขจาก FD)

ขั้นที่ 1 — Direct Income ตาม TB

ขั้นที่ 2 — ดอกเบี้ยรับออมทรัพย์ตาม TB และการปันของ Corporate

ขั้นที่ 3 — ใส่เพดาน แล้วโยนส่วนเกินไป Non-BOI

Key Test Conditions — TC-001 ถึง TC-015

Expert notes

1) “Retrofit with change” + “delta document” = ต้องอ่าน 2 เอกสาร

2) ความสัมพันธ์ 3 objects ในชุด Current Tax

3) การยุบตาราง T029–T032 กระทบอะไร

4) ทำไมต้องเลิก “Exclude profit center O*”

5) Checklist กระทบยอดรายเดือน (ใช้ได้จริง)

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

ข) GL account prefix A/B/C — เคล็ดลับ `*999999999`