โมเดลข้อมูลใบกำกับภาษี GST: ฟิลด์ขั้นต่ำสำหรับ HSN และคำสั่งซื้อ

ปัญหาที่มักเกิดขึ้นกับใบกำกับภาษี GST

ปัญหาใบกำกับภาษี GST ส่วนใหญ่ไม่ใช่ปัญหา "ภาษีซับซ้อน" แต่เป็นปัญหาข้อมูลที่ขาดหรือไม่สอดคล้องกัน การตรวจสอบจะไม่ผ่านเมื่อใบกำกับภาษีไม่สามารถเชื่อมโยงได้ชัดเจนกับสิ่งที่ขาย ใครเป็นผู้ซื้อ ที่จัดส่งที่ไหน และคำนวณภาษีอย่างไร

สาเหตุทั่วไปคือ HSN หาย เก่า หรือเก็บไว้ผิดระดับ ทีมอาจเก็บ HSN ไว้ที่สินค้าต้นทาง แต่บรรทัดในใบกำกับเกิดจากชื่อ SKU หรือเวอร์แรนท์คนละตัว ทำให้ HSN ไม่ได้อยู่บนเอกสารสุดท้าย ปัญหาหนึ่งที่พบบ่อยคือการแยกภาษีผิด: เก็บ IGST แทนที่จะเป็น CGST+SGST (หรือกลับกัน) เพราะ "place of supply" ถูกเดาจากที่อยู่จัดส่งโดยไม่บันทึกรหัสรัฐที่ใช้ตัดสินใจ

ทีมการเงินจะรู้สึกได้ทันที การกระทบยอดจะกลายเป็นงานล้างข้อมูลประจำวัน: ยอดใบกำกับไม่ตรงกับคำสั่งซื้อ คำสั่งซื้อไม่ตรงกับการตัดจ่ายจากเกตเวย์ การคืนเงินกลายเป็นการจดบันทึกด้วยมือ แม้ความต่างเล็กน้อยจากการปัดเศษที่เกิดบนแต่ละบรรทัดก็สามารถสร้างความไม่ตรงกันระหว่าง PDF ใบกำกับ รายงาน GST และเล่มบัญชีได้

รูปแบบที่ก่อให้เกิดปัญหาส่วนใหญ่มีดังนี้:

• สินค้าและบรรทัดในใบกำกับไม่มี HSN, อัตราภาษี, หรือค่าสอบภาษีที่ตรงกัน
• ภาษีถูกคำนวณหลายที่ (ตะกร้า vs ใบกำกับ) ผลลัพธ์ต่างกัน
• ยอดรวมถูกเก็บเป็น "ยอดรวมทั้งหมด" เพียงค่าเดียวโดยไม่มีการแยกค่าฐานภาษีและแต่ละรายการภาษี
• หมายเลขใบกำกับแก้ไขได้หรือซ้ำกันข้ามซีรีส์
• การคืนเงินบันทึกเป็นคำสั่งซื้อเชิงลบแทนที่จะเป็นบันทึกเครดิตที่ถูกต้อง

เป้าหมายของโมเดลข้อมูลใบกำกับภาษี GST ง่าย: เก็บฟิลด์ขั้นต่ำของคำสั่งซื้อ สินค้า ฝ่าย (party) ภาษี ใบกำกับ และบันทึกเครดิตเพื่อให้ตัวเลขทุกค่าสามารถสร้างซ้ำและอธิบายได้ในภายหลัง รักษาให้เล็ก แต่อย่าตัดฟิลด์ที่สำคัญตามกฎหมายซึ่งกำหนดประเภทภาษี อัตรา และการรายงาน

ชุดเรคอร์ดขั้นต่ำที่ต้องมี

ถ้าต้องการให้การออกใบกำกับ GST ง่ายและกระทบยอดได้ง่าย ให้เริ่มจากชุดอ็อบเจ็กต์ขนาดเล็กและให้แต่ละอ็อบเจ็กต์ทำงานเดียว โมเดลข้อมูลใบกำกับ GST ที่สะอาดไม่ใช่เรื่องการมีหลายตาราง แต่เป็นการเก็บข้อเท็จจริงให้คงที่เมื่อเวลาผ่านไป

เรคอร์ดหลักที่ทีมส่วนใหญ่ต้องการตั้งแต่วันแรกมีดังนี้:

• Customer: ผู้ซื้อ (ชื่อ เบอร์โทร/อีเมล GSTIN ถ้าเป็น B2B)
• Address: ที่อยู่จัดส่งและเรียกเก็บเงิน รวมทั้งรัฐและสัญญาณสถานที่จัดหา (place of supply)
• Product (or Service): สิ่งที่ขาย หน่วย ราคาพื้นฐาน และ HSN/SAC เริ่มต้น
• Order: เหตุการณ์การค้า (ตะกร้า ส่วนลด ค่าจัดส่ง สถานะ)
• Payment: การเคลื่อนไหวเงิน (อ้างอิงเกตเวย์ วิธี จำนวนที่จับ/บันทึก วันที่)

Invoice ควรแยกจาก Order ออกไป คำสั่งซื้อสามารถเปลี่ยนได้ (แก้ที่อยู่ ลบสินค้า บางรายการยังไม่ส่ง) แต่ใบกำกับไม่ควรเปลี่ยน เลขที่ วัน และยอดรวมต้องคงที่ไม่ให้ "เบี้ยว" เพราะมีคนแก้คำสั่งซื้อหลังจากนั้น

จุดตั้งต้นความถูกต้องของภาษีคือ รายการบรรทัด (Line Items) แต่ละบรรทัดในคำสั่งซื้อ (และต่อมาบรรทัดในใบกำกับ) ควรเก็บจำนวนจริง ราคาต่อหน่วย ส่วนลด และการแยกภาษีของสินค้านั้นๆ นี่แหละที่ HSN/SAC และอัตรา GST ถูกนำไปใช้

รายละเอียดหนึ่งที่ช่วยทีมการเงินมาก: เก็บ สแนปช็อต เมื่อคุณสร้างใบกำกับ ให้คัดลอกรายละเอียดสินค้า คำอธิบาย HSN/SAC อัตราภาษี และราคาลงในบรรทัดใบกำกับ อย่าอิงกับข้อมูลสินค้าในปัจจุบันเพียงอย่างเดียว เพราะอัตราและชื่อตัวสินค้าอาจเปลี่ยนได้

เรคอร์ดเสริมที่มักคุ้มค่าจะเพิ่มตั้งแต่ต้นคือ การคืนสินค้า, การคืนเงิน, และ บันทึกเครดิต เป็นเรคอร์ดแยก ตัวอย่าง: ถ้าลูกค้าคืนหนึ่งชิ้นจากคำสั่งซื้อสองชิ้น คุณต้องการบันทึกเครดิตโน้ตที่อ้างอิงบรรทัดในใบกำกับเดิม ในขณะที่บันทึกการคืนเงินอ้างอิงธุรกรรมเกตเวย์ การเก็บเป็นอ็อบเจ็กต์ชัดเจนช่วยป้องกันการแก้ไขด้วยมือในรีจิสเตอร์ GST ปลายเดือน

หากสร้างใน Koder.ai ให้มองแต่ละอ็อบเจ็กต์เป็นหน้าจอเรียบง่ายก่อน (สร้าง ดู แก้ไข) แล้วเพิ่มการสร้างใบกำกับเมื่อสแนปช็อตและฟิลด์ระดับบรรทัดพร้อมแล้ว

HSN และ SAC: อยู่ตรงไหนในโมเดล

HSN (สำหรับสินค้า) และ SAC (สำหรับบริการ) ไม่ใช่รายละเอียดที่อยู่เฉพาะบนใบกำกับเท่านั้น มันเริ่มต้นที่การกำหนดสินค้า/บริการ จากนั้นคัดลอกไปยังแต่ละบรรทัดของใบกำกับเมื่อออกใบ วิธีนี้ทำให้ตะกร้าผสมหลายประเภทถูกต้องและการตรวจสอบง่ายเพราะแต่ละบรรทัดมีข้อมูลของตัวเอง

โมเดลข้อมูลขั้นต่ำที่ใช้งานได้คือ:

• Product: id, name, SKU, unit (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (ไม่จำเป็นสำหรับบรรทัดที่กรอกด้วยมือ), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

การเก็บ HSN/SAC บน Product ช่วยให้ทีมแอดมินดูแลจากที่เดียว การคัดลอกลง InvoiceLine คือสิ่งที่ทำให้ใบกำกับย้อนหลังคงที่ แม้สินค้าจะเปลี่ยนแปลงในภายหลัง ใบกำกับก็ยังแสดงความจริงในเวลาขาย นี่คือหัวใจของโมเดลที่ไม่พังตอนกระทบยอด

สำหรับการเก็บ HSN ให้เรียบง่าย: รหัส จำเป็น, คำอธิบาย เป็นทางเลือก, และ effective_from date เป็นทางเลือกถ้าต้องการเก็บประวัติการเปลี่ยนแปลง ส่วนใหญ่ไม่จำเป็นต้องมีคำอธิบายในทุกบรรทัด แต่มีประโยชน์เมื่อการเงินตรวจสอบข้อยกเว้น

ตะกร้าผสมเป็นเรื่องปกติ: ใบหนึ่งอาจมีหลายบรรทัดและหลายรหัส HSN/SAC อย่าไปบังคับให้มีรหัสเดียวต่อใบ ยอดรวมรวมที่ระดับใบ ในขณะที่การจัดหมวดหมู่เก็บที่ระดับบรรทัด

การจัดการการเปลี่ยนแปลงคือจุดที่คนมักพลาด ใช้กฎเล็กๆ ดังนี้:

• ห้ามเขียนทับ HSN/SAC ในบรรทัดใบกำกับที่ออกแล้ว
• ถ้า HSN/SAC ของสินค้าเปลี่ยน ให้ปรับที่ Product สำหรับคำสั่งซื้อในอนาคตเท่านั้น
• ถ้าติดตามประวัติ ให้เพิ่มระเบียน effective_from ใหม่ แทนการแก้ไขระเบียนเก่า

ในหน้าจอแอดมิน คุณต้องการที่เดียวในการแก้ไขฟิลด์ภาษีของ Product และมุมมองแบบอ่านอย่างเดียวบนบรรทัดใบกำกับเพื่อยืนยันสิ่งที่จับได้เมื่อออกใบ ถ้าสร้างหน้าจอเหล่านี้อย่างรวดเร็ว เครื่องมืออย่าง Koder.ai สามารถสร้างหน้า CRUD และตารางข้อมูลพื้นฐานจากโมเดลนี้ได้อย่างง่ายดาย

รายละเอียดฝ่าย: GSTIN, ที่อยู่, และสถานที่จัดส่ง (place of supply)

โมเดลข้อมูลใบกำกับภาษี GST มักล้มเหลวเพราะรายละเอียดฝ่ายไม่ครบถ้วน ถ้าตัวตนของผู้ซื้อหรือผู้ขายคลาดเคลื่อนเล็กน้อย ใบกำกับอาจถูกตามรูปแบบแต่ยุ่งยากในการยื่นรายงานและกระทบยอด

เริ่มจากการถือว่า "ผู้ขาย" "ผู้ซื้อ" และ "ผู้รับของ" เป็นฝ่ายแยกกัน ถึงแม้จะเป็นคนเดียวกันก็ตาม วิธีนี้ป้องกันการแฮ็กในภายหลังเมื่อผู้ซื้อเพิ่มที่อยู่จัดส่งคนละที่หรือเมื่อขายจากการจดทะเบียน GST หลายแห่ง

ฟิลด์ขั้นต่ำที่ต้องเก็บ (ผู้ซื้อและผู้ขาย)

เก็บฟิลด์เรียบง่ายและชัดเจน ฟิลด์ที่จำเป็นบนใบกำกับและในรายงานมีดังนี้:

• ชื่อทางกฎหมาย (ตามที่จะปรากฏบนใบกำกับ)
• ชื่อทางการค้า (ไม่จำเป็นแต่มีประโยชน์)
• GSTIN (ผู้ขายต้องมี; ผู้ซื้อเป็นค่าว่างได้)
• เบอร์โทร/อีเมล (ไม่บังคับเสมอไป แต่ช่วยฝ่ายสนับสนุน)
• บรรทัดที่อยู่ เมือง รัฐ ประเทศ รหัสไปรษณีย์

เก็บรัฐทั้งชื่อที่อ่านได้และรหัสรัฐด้วย เพราะการรายงานและกฎ place-of-supply มักอิงรหัส

ที่อยู่เรียกเก็บ vs ที่อยู่จัดส่ง และ place of supply

จับทั้งที่อยู่เรียกเก็บและที่อยู่จัดส่งบนคำสั่งซื้อ ไม่ใช่แค่ในโปรไฟล์ลูกค้า โปรไฟล์เปลี่ยนได้ ใบกำกับไม่ควรเปลี่ยน

place of supply ควรถูกเก็บเป็นรหัสรัฐเฉพาะบนใบกำกับ (คัดลอกจากคำสั่งซื้อเมื่อออกใบ) อย่าไปคำนวณซ้ำภายหลัง ถ้ากฎของคุณคือ "รัฐที่จัดส่ง" ให้เก็บผลลัพธ์นั้นพร้อมกับรหัสรัฐที่ใช้ตัดสิน นี่ช่วยให้การตรวจสอบและข้อพิพาทง่ายขึ้น

B2B vs B2C: เมื่อไร GSTIN จำเป็น

สำหรับ B2B ปกติแล้ว GSTIN ของผู้ซื้อจำเป็นและควรตรวจสอบความยาวและรูปแบบเมื่อกรอก สำหรับ B2C GSTIN สามารถเว้นว่างได้ แต่ยังต้องมีที่อยู่และรัชนีย์เต็มเพื่อกำหนดว่าจะใช้ CGST/SGST หรือ IGST

กฎง่ายๆ ที่ใช้ได้ในระบบส่วนใหญ่: ถ้ามี GSTIN ของผู้ซื้อ ให้ถือเป็น B2B; ถ้าไม่มี ให้ถือเป็น B2C ถ้าต้องมีข้อยกเว้น ให้เก็บฟิลด์ customer_type แบบชัดเจน

ผู้ขายหลายหน่วย (มี GSTIN หลายรายการ)

ถ้าคุณมีสาขาหรือหน่วยธุรกิจที่มีการจดทะเบียน GST ต่างกัน ให้สร้างระเบียน "Seller Entity" แยกต่างหากที่มี GSTIN และที่อยู่ของตัวเอง คำสั่งซื้อแต่ละชุดควรอ้างถึง seller entity เดียว และใบกำกับควรคัดลอกรายละเอียดเหล่านั้นเพื่อให้ใบกำกับเก่าคงถูกต้องแม้ที่อยู่ผู้ขายจะเปลี่ยนในภายหลัง

เครื่องมืออย่าง Koder.ai สามารถสร้างฟอร์มแอดมินสำหรับระเบียนเหล่านี้ได้เร็ว แต่โครงสร้างสำคัญคือ: แยก seller entity, สแนปช็อตเมื่อสั่งซื้อ, และรหัสสถานะสถานที่จัดส่งที่ชัดเจน

ฟิลด์การคำนวณภาษีที่ต้องเก็บ

การแยกที่พบบ่อยคือ: ถ้าสถานที่จัดส่งอยู่ในรัฐเดียวกับผู้ส่งสินค้า จะใช้ CGST + SGST ถ้าเป็นคนละรัฐจะใช้ IGST ระบบของคุณไม่ควร "คำนวณใหม่จากยอดรวม" ภายหลัง เพราะความต่างเล็กน้อย (ปัดเศษ ส่วนลด ค่าส่ง) คือสิ่งที่ทำให้เกิดความไม่ตรงกัน

อย่างน้อยที่สุด ให้เก็บตัวเลขภาษีที่ระดับบรรทัดของใบกำกับ ไม่ใช่แค่หัวใบกำกับ เพื่อที่คุณจะอธิบายทุกรูปีบนใบกำกับและจับคู่กลับไปยังสินค้า HSN และรายได้ได้

ฟิลด์ขั้นต่ำต่อบรรทัดที่ใช้ได้จริงมีดังนี้:

• taxable_value (หลังจัดสรรส่วนลดที่ระดับบรรทัด)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (เก็บการแยกที่ใช้)
• cgst_amount, sgst_amount, igst_amount (เก็บจำนวนที่คำนวณแล้ว)
• line_total (taxable_value + จำนวนภาษี)

ส่วนลดคือจุดที่ระบบมักวุ่นวาย ตัดสินใจหนึ่งกฎและเก็บมันให้ชัด หากส่วนลดลดราคาก่อนภาษี (ปกติสำหรับส่วนลดสินค้าและคูปอง) ให้เก็บจำนวนรวมเดิม จำนวนส่วนลด และค่าฐานภาษีที่เกิดขึ้น หากมีคูปองระดับคำสั่งซื้อ ให้จัดสรรเป็นสัดส่วนไปยังแต่ละบรรทัด (โดยปกติอิงตามค่าฐานก่อนส่วนลดของแต่ละบรรทัด) และเก็บการจัดสรรส่วนลดของแต่ละบรรทัดเพื่อให้คณิตศาสตร์ภาษีอธิบายได้

การปัดเศษควรสอดคล้องและบันทึกไว้ เลือกว่าจะปัดในระดับบรรทัดหรือเฉพาะระดับใบกำกับแล้วเก็บผลลัพธ์ที่ปัดไว้จริง หลายทีมคำนวณภาษีต่อบรรทัด ปัดเป็นทศนิยมสองตำแหน่ง รวมผล แล้วมีฟิลด์ invoice_rounding_adjustment เพื่อให้ถึงจำนวนที่ต้องชำระจริง

ค่าจัดส่งและค่าดำเนินการไม่ควรเป็นค่าซ่อน ให้ถือเป็นบรรทัดใบกำกับแยกต่างหากพร้อม HSN/รหัสบริการและกฎอัตราภาษี เช่น คำสั่งซื้อมีสินค้าสองชิ้นและค่าจัดส่ง จะกลายเป็นสามบรรทัด แต่ละบรรทัดเก็บค่าฐานภาษีและคอมโพเนนต์ภาษี ทำให้การกระทบยอดง่ายขึ้นมาก

ข้อมูลเอกสารใบกำกับ: การจัดหมายเลข วันที่ ยอดรวม สถานะ

เมื่อคำนวณภาษีแล้ว ใบกำกับยังต้องมีฟิลด์เอกสารที่ทำให้เป็นหลักฐาน ถูกตรวจสอบได้ และง่ายต่อการกระทบยอดในภายหลัง ในโมเดลข้อมูลใบกำกับ GST ให้ปฏิบัติต่อหัวใบกำกับเหมือนระเบียนตามกฎหมาย: ต้องคงที่แม้ข้อมูลสินค้า/ลูกค้าจะเปลี่ยน

เริ่มจากหัวข้อพื้นฐาน: หมายเลขใบกำกับ วันที่ออก ใบกำกับประเภท (tax invoice, export, B2B, B2C ฯลฯ) และสกุลเงิน แม้จะออกเป็น INR ส่วนมาก การเก็บสกุลเงินช่วยกรณีส่งออกหรือมาร์เก็ตเพลสหลายสกุล

การจัดหมายเลขเป็นสิ่งที่ทีมมักพลาด เก็บซีรีส์หรือพรีฟิกซ์ (เช่น "FY25-INV-"), เก็บปีการเงิน, และบังคับความไม่ซ้ำที่ระดับฐานข้อมูลด้วย เก็บการควบคุม "หมายเลขถัดไป" ต่อซีรีส์ในหน้าแอดมินเพื่อป้องกันสองแอดมินออกหมายเลขเดียวกันพร้อมกัน

ยอดรวมควรถูกเก็บอย่างชัดเจน ไม่ใช่แค่อนุมาน เก็บยอดย่อย (ค่าฐานภาษี), ยอดภาษีรวม, ยอดรวมทั้งสิ้น, และยอดปัดเศษแยกต่างหาก หากคุณคำนวณซ้ำภายหลังจากบรรทัดเล็กๆ กฎเล็กน้อยอาจทำให้ใบกำกับเก่ากับรายงานภาษีไม่ตรงกัน

สถานะควรสะท้อนวงจรชีวิตจริงและล็อกระเบียนเมื่อจำเป็น:

• Draft (แก้ไขได้)
• Issued (กำหนดหมายเลขแล้ว สร้าง PDF แล้ว)
• Cancelled (เก็บไว้เพื่อตรวจสอบ ไม่ลบทิ้ง)
• Refunded (คืนเงิน อาจต้องมีบันทึกเครดิต)
• Credit noted (ออกบันทึกเครดิตโดยเชื่อมกับใบกำกับเดิม)

สุดท้าย เก็บเมทาดาต้าของเอกสารที่สร้าง: เวอร์ชันเทมเพลต PDF, เวลาที่สร้าง, และตัวระบุไฟล์ แฮชเป็นทางเลือกแต่มีประโยชน์หากต้องพิสูจน์ว่า PDF ไม่ถูกแก้ไข

ตัวอย่าง: ถา้เจ้าหน้าที่ซัพพอร์ตสร้าง PDF ใหม่หลังเทมเพลตอัปเดต ยอดและหมายเลขใบกำกับต้องไม่เปลี่ยน แต่การเก็บเวอร์ชันเทมเพลตจะอธิบายว่าทำไมเลย์เอาต์ของ PDF ถึงต่างกัน

หน้าจอแอดมินสำหรับสินค้า ภาษี และรายละเอียดลูกค้า

ถ้าต้องการใบกำกับ GST ที่สะอาด อย่าเริ่มจากหน้าจอใบกำกับ เริ่มจากหน้าจอแอดมินที่ป้อนข้อมูลเข้า โมเดลข้อมูลที่ดีจะคงขนาดเล็กเมื่ออินพุตควบคุมและสอดคล้อง

Product master (SKU ถึง HSN/SAC)

Product master คือจุดเริ่มที่เกิดความผิดพลาดในอนาคตมากที่สุด ดังนั้นทำให้เข้มงวด SKU แต่ละตัวควรมีค่าเริ่มต้น HSN (หรือ SAC) หนึ่งค่า และมีอัตรา GST เริ่มต้นและข้อยกเว้นเฉพาะวันที่ถ้าจำเป็น

หน้าจอสินค้าที่ใช้งานได้ควรมี:

• SKU และชื่อสินค้า (ตามที่อยากพิมพ์)
• รหัส HSN/SAC, อัตรา GST, และหมวดภาษี (ถ้าใช้)
• วันที่เริ่ม/สิ้นสุดใช้งาน (เพื่อการเปลี่ยนแปลงไม่เขียนทับใบกำกับเก่า)
• การโอเวอร์ไรด์ราคา (สำหรับ MRP พิเศษหรือราคาตามช่องทาง)
• สถานะ (active/inactive) พร้อมเหตุผลการปิดใช้งาน

การตั้งค่าภาษี (อัตราและการตัดสิน intra vs inter-state)

หลีกเลี่ยง UI แบบ "เครื่องคิดเลข" ให้เก็บอินพุตที่ระบบนำไปใช้ได้อย่างสม่ำเสมอ: ตารางอัตรา, กฎ place of supply ที่ปฏิบัติตาม, และวิธีตัดสิน intra-state vs inter-state (ปกติเทียบรัฐผู้ขายกับรัฐผู้รับ)

เก็บหน้าจอภาษีให้มุ่งไปที่: อัตราภาษีตามหมวด/กลุ่ม HSN, วันที่มีผล, และจะทำอย่างไรเมื่อผู้ซื้อให้ GSTIN ถูกต้องหรือไม่

โปรไฟล์ลูกค้าและบริษัท (ผู้ที่ปรากฏบนใบกำกับ)

หน้าจอลูกค้าควรจับ GSTIN และสถานะการตรวจสอบของมัน พร้อมที่อยู่เรียกเก็บและที่อยู่จัดส่งเริ่มต้น อย่าให้ผู้ใช้พิมพ์ชื่อรัฐแบบอิสระ ใช้รายการควบคุมเพื่อป้องกันค่าที่ต่างกันเช่น "KA" กับ "Karnataka"

หน้าจอโปรไฟล์บริษัทสำคัญไม่แพ้กัน: ชื่อทางกฎหมาย GSTIN ที่อยู่จดทะเบียน และการตั้งค่าซีรีส์หมายเลขใบกำกับ (พรีฟิกซ์ หมายเลขถัดไป และขอบเขตปีการเงิน) ล็อกฟิลด์เหล่านี้ด้วยสิทธิ์เพราะการเปลี่ยนแปลงมีผลต่อเอกสารทุกฉบับในอนาคต

พื้นฐานบันทึกตรวจสอบ (Audit log)

คุณไม่ต้องการระบบซับซ้อน แต่ต้องการร่องรอย บันทึกว่าใครเปลี่ยน HSN/SAC อัตราภาษี การตั้งค่าซีรีส์หมายเลข หรือ GSTIN ของบริษัท พร้อมค่าก่อนหน้า ค่าใหม่ เวลาที่เปลี่ยน และเหตุผล

ถ้าสร้างหน้าจอเหล่านี้ในเครื่องมืออย่าง Koder.ai ให้ถือว่าการบันทึกตรวจสอบและวันที่มีผลเป็นฟิลด์สำคัญตั้งแต่วันแรก พวกมันใช้เวลาเพิ่มน้อยแต่ประหยัดชั่วโมงในรีวิวการเงินภายหลัง

ขั้นตอนทีละก้าว: จากคำสั่งซื้อสู่ใบกำกับที่เป็นไปตามกฎหมาย

ใบกำกับที่ถูกต้องตามกฎหมายไม่ใช่เรื่องฟอร์แมตหรู แต่เป็นการตรึงข้อเท็จจริงที่ถูกต้องในเวลาที่เหมาะสม ถ้าคุณออกแบบโมเดลข้อมูลรอบๆ ฟลอว์นี้ งานการเงินจะกลายเป็นการจับคู่ ไม่ใช่การสืบสวนประจำสัปดาห์

1) แช่แข็งสิ่งที่ลูกค้าซื้อจริง

ก่อนคำนวณภาษี ให้ล็อกสแนปช็อตคำสั่งซื้อ: สินค้า จำนวน ราคาต่อหน่วย ส่วนลด ค่าจัดส่ง/ค่าดำเนินการ GSTIN ของลูกค้า (ถ้ามี) ที่อยู่เรียกเก็บและจัดส่ง และสัญญาณสถานที่จัดส่ง สแนปช็อตต้องไม่เปลี่ยน แม้ราคาสินค้าหรือแมป HSN จะเปลี่ยน

2) เปลี่ยนสแนปช็อตเป็นบรรทัดใบกำกับ (คัดลอกแอตทริบิวต์ภาษี)

คำนวณภาษีและสร้างบรรทัดใบกำกับจากสแนปช็อต บรรทัดแต่ละรายการต้องคัดลอก HSN/SAC อัตราภาษี ค่าฐานภาษี และจำนวนภาษีที่ใช้ในขณะนั้น แทนการไปดึงแบบสดในภายหลัง

3) ออกใบกำกับและทำให้ไม่สามารถแก้ไขได้

กำหนดหมายเลขใบกำกับและวันที่ออก แล้วเปลี่ยนสถานะเป็น Issued จากจุดนี้บล็อกการแก้ไขราคาภาษี HSN และที่อยู่บนระเบียนใบกำกับ ถ้าจำเป็นต้องอนุญาตให้ทำอะไรได้ ให้จำกัดเฉพาะหมายเหตุภายในหรือแท็กที่ไม่กระทบยอดทางการเงิน

4) สร้างเอกสารสุดท้ายและเก็บยอดรวม

สร้าง PDF/มุมมองพิมพ์จากใบกำกับที่ออก แล้วเก็บยอดสุดท้ายที่จะรายงาน: ยอดค่าฐานภาษี ยอด CGST/SGST/IGST ยอดปัดเศษ และยอดรวมทั้งหมด หากต้องการความปลอดภัยเพิ่ม เก็บเวอร์ชันเอกสารหรือเช็คซัมเพื่อพิสูจน์ว่าไฟล์พิมพ์ตรงกับตัวเลขที่เก็บไว้

5) จัดการการเปลี่ยนแปลงตามกฎหมาย

หลังออกแล้ว การเปลี่ยนแปลงควรเป็นไปตามกฎ ไม่ใช่การแก้ไข:

• ต้องการแก้ราคาลูกค้า: ออกบันทึกเครดิต (หรือเดบิต) ที่อ้างอิงใบกำกับเดิม
• คำสั่งซื้อถูกยกเลิกหลังออก: ยกเลิกใบกำกับถ้ากฎหมายอนุญาต มิฉะนั้นออกบันทึกเครดิต
• ลูกค้าแก้ที่อยู่หลังออก: อย่าเขียนทับใบกำกับ แก้ด้วยเอกสารที่ถูกต้องและเก็บบันทึกตรวจสอบ
• คืนเงินบางส่วน: บันทึกเครดิตเฉพาะบรรทัด/จำนวนที่คืน
• ส่งของทดแทน: สร้างคำสั่งซื้อ/ใบกำกับใหม่ ไม่ใช่แก้ไขเงียบ

ถ้าสร้างฟลอว์นี้ในหน้าจอแอดมิน (การวางแผนแบบ Koder.ai ช่วยแม็ปขั้นตอนก่อนสร้าง) ทีมของคุณจะออกใบกำกับได้เร็วโดยไม่ทำให้การกระทบยอดพัง

ทำให้การกระทบยอดเป็นเรื่องง่าย: การชำระเงิน คืนเงิน และรีจิสเตอร์

การกระทบยอดยุ่งเมื่อการชำระเงินถูกมองเป็นเพียงธง "ชำระเงิน/ไม่ได้ชำระ" บนคำสั่งซื้อ เก็บการชำระเงินและการคืนเงินเป็นเรคอร์ดแยกที่เชื่อมกับคำสั่งซื้อและใบกำกับ เพื่อให้การเงินจับคู่การตัดจ่ายธนาคารโดยไม่ต้องเขียนประวัติใหม่

แยกระเบียนการชำระเงินและคืนเงิน (อย่าแก้ไขใบกำกับ)

ใบกำกับที่ถูกต้องควรคงที่หลังการออก หากลูกค้าจ่ายเป็นงวดหรือคุณคืนเงินภายหลัง ให้บันทึกการเคลื่อนไหวเป็นรายการชำระเงินหรือคืนเงิน ไม่ใช่การเปลี่ยนยอดในใบกำกับ

ฟิลด์ขั้นต่ำที่ช่วยให้กระทบยอดง่าย:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (ไม่บังคับแต่มีประโยชน์): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (ถ้ามี), gateway_refund_id, amount, reason, refunded_at, status
• คีย์การกระทบยอด ที่ไม่ควรนำกลับมาใช้ใหม่: order_id, invoice_id, payment_id, refund_id, credit_note_id

ถ้าลูกค้าคืนหนึ่งชิ้น อย่าไป "ลดใบกำกับ" ให้ส่งบันทึกเครดิตและเชื่อมกับใบกำกับเดิม รีจิสเตอร์ใบกำกับจะยังสะอาด และการคืนเงินจะเชื่อมกับบันทึกเครดิต

มุมมองการเงินและการส่งออกที่ประหยัดเวลา

ให้หน้าจอเดียวที่ตอบคำถาม: อะไรออกแล้ว อะไรชำระแล้ว อะไรยังค้าง และอะไรถูกยกเลิก ให้รวมอายุหนี้ (0-7, 8-30, 31-60, 60+ วัน) และสามารถเจาะลงไปดูรายการชำระเงินและคืนเงินที่เกี่ยวข้องได้

รายงานที่ทีมส่วนใหญ่ต้องการทุกเดือน:

• รีจิสเตอร์ใบกำกับ (ออก ยกเลิก บันทึกเครดิต)
• สรุปภาษีตามอัตราและ HSN/SAC (รองรับโมเดลข้อมูลใบกำกับ GST)
• การกระทบยอดการชำระเงินกับใบกำกับ (invoice_id, ยอดชำระ, ยอดคงเหลือ)
• รีจิสเตอร์คืนเงินและบันทึกเครดิต
• รายงานการตัดจ่ายเกตเวย์ (พาเอาต์ไอดีถึงการแมป invoice/payment)

ตัวอย่าง: คำสั่งซื้อ 10,000 รูปี ชำระ 6,000 วันนี้ และ 4,000 สัปดาห์หน้า ใบกำกับยังเป็น 10,000 มุมมองการเงินจะแสดงยอดคงเหลือ 4,000 จนกว่าการตัดจ่ายครั้งที่สองจะมาถึง แล้วจึงมาร์กว่าเรียบร้อยโดยไม่แก้ไขเอกสารที่ออก

กับดักทั่วไปที่ทำให้ไม่ปฏิบัติตามหรือเกิดความไม่ตรงกัน

ปัญหาใบกำกับ GST ส่วนใหญ่ไม่ใช่ "ตรรกะภาษี" แต่เป็นการเก็บบันทึก: ตัวเลขใน PDF ไม่ตรงกับสิ่งที่การเงินส่งออก หรือใบกำกับไม่สามารถอธิบายได้ในภายหลัง

กับดักแรกคือการคำนวณ GST ทุกครั้งเมื่อตามดูใบกำกับ หากคำนวณ CGST/SGST/IGST ทุกครั้งเมื่อมีการเปิดดู คุณจะได้ผลต่างเมื่อมีการเปลี่ยนอัตรา กฎการปัดเศษ หรือแก้บั๊ก เก็บการแยกภาษีที่คำนวณไว้ตอนออกใบ แม้ว่าจะเก็บอินพุตด้วยก็ตาม

กับดักที่สองคืออนุญาตให้แก้ไขใบกำกับที่ออกแล้ว เมื่อใบกำกับเป็นสุดท้ายแล้ว การเปลี่ยนแปลงควรผ่านบันทึกเครดิตหรือฟลอว์ทดแทนที่มีบันทึก มิฉะนั้นคุณจะเห็นข้อโต้แย้งว่า "ทำไม PDF ของลูกค้าไม่ตรงกับบัญชี"

รูปแบบความไม่ตรงกันที่พบบ่อย:

• ขาดสถานที่จัดส่งหรือรหัสรัฐผิด ทำให้ใช้ IGST แทน CGST+SGST (หรือกลับกัน)
• อัพเดต HSN/SAC หรืออัตราภาษี แล้วคำสั่งซื้อเก่าไปถูกคำนวณด้วยค่าที่ใหม่
• เก็บภาษีไว้แล้ว แต่กฎการปัดเศษต่างกันระหว่าง UI, การสร้าง PDF, และการส่งออก CSV
• ส่วนลดถูกนำมาหักหลังภาษีที่จุดหนึ่ง และก่อนภาษีที่อีกจุด
• คืนเงินบันทึกเป็นรายการเชิงลบโดยไม่มีการเชื่อมโยงชัดเจนกับใบกำกับเดิม

ตัวอย่างรวดเร็ว: คุณขายให้ลูกค้าในรัฐ Karnataka แต่ที่อยู่จัดส่งเป็น Maharashtra ถ้าระบบใช้ที่อยู่เรียกเก็บผิดสำหรับ place of supply คุณอาจคิด CGST+SGST แทนที่จะเป็น IGST ถ้าคุณคำนวณภาษีแบบสด ข้อผิดพลาดนั้นอาจถูก"แก้"โดยไม่รู้ตัวในภายหลัง ทำให้การเงินได้ตัวเลขที่ไม่ตรงกับเอกสารที่ออก

เมื่อคุณสร้างหน้าจอแอดมิน ให้ใส่เกราะเล็กๆ: ล็อกใบกำกับที่ออกแล้ว แสดงอินพุต place-of-supply ข้างๆ ประเภทภาษีที่คำนวณได้ และเก็บสแนปช็อตไม่เปลี่ยนของ HSN อัตรา และการปัดเศษที่ใช้ตอนออก

เช็คลิสต์ด่วนและขั้นตอนถัดไป

ก่อนส่งใบกำกับให้ลูกค้าหรือมาร์กเป็น "Issued" ให้รันเช็คลิสต์ด่วน นี่คือที่ที่ข้อผิดพลาดเล็กๆ กลายเป็นปัญหาการกระทบยอดขนาดใหญ่ ถ้าคุณสร้างโมเดลข้อมูลใบกำกับ GST ควรฝังการตรวจสอบเหล่านี้ทั้งในกฎการตรวจสอบและ UI แอดมิน

ตรวจสอบต่อใบ (ก่อนออก)

• มี HSN/SAC ในทุกบรรทัดและตรงกับสินค้าหรือบริการที่ขายจริง
• กฎ GSTIN ถูกใช้ถูกต้อง (B2B vs B2C) และที่อยู่เรียกเก็บกับจัดส่งไม่ขัดแย้ง
• สถานที่จัดส่งถูกเก็บและการแยกภาษีสมเหตุผล (CGST/SGST vs IGST)
• ยอดรวมบวกกันถูกต้อง: ค่าฐานภาษี แต่ละคอมโพเนนต์ภาษี ปัดเศษ และยอดรวมทั้งหมด
• เมื่่อออกแล้ว ใบกำกับต้องถูกล็อก (ไม่มีการแก้ไขเงียบ) แก้ไขต้องผ่านบันทึกเครดิตหรือฟลอว์ยกเลิก ไม่ใช่การเขียนทับประวัติ

ตัวอย่างง่าย: ลูกค้าอัปเดตที่อยู่จัดส่งหลังชำระเงินแล้วและรัฐเปลี่ยน ถ้าคุณออกใบใหม่ในหมายเลขเดิมพร้อมภาษีใหม่ รีจิสเตอร์และการชำระเงินจะไม่ตรง วิธีที่ปลอดภัยคือเก็บใบกำกับเดิมเป็น immutable และสร้างเอกสารปรับปรุง

การตรวจสอบข้อมูล + เวิร์กโฟลว์ (เพื่อให้การเงินสะอาด)

• การจัดหมายเลขใบกำกับไม่ซ้ำ ต่อเนื่องตามนโยบาย และสร้างเมื่อถึงเวลา "issue" เท่านั้น
• เก็บจำนวนภาษีที่คำนวณจริง ไม่ใช่แค่อัตรา เพื่อให้รายงานคงที่แม้อัตราจะเปลี่ยน
• มีขั้นตอนสถานะชัดเจน: draft -> issued -> cancelled (และเอกสารบันทึกเครดิตแยกต่างหาก)
• รายงานกระทบยอดตามช่วงเวลา: ยอดในรีจิสเตอร์ใบกำกับต้องผูกกับการชำระเงินที่จับได้ คืนเงินที่ดำเนินการ และลูกหนี้คงค้าง
• ฟิลด์ตรวจสอบเสมอมี: สร้างโดย ใคร เมื่อไหร่ และเหตุผลสำหรับการยกเลิกหรือออกบันทึกเครดิต

ขั้นตอนถัดไป: นำหน้าจอและการตรวจสอบไปใช้งานก่อน แล้ววนปรับปรุง ใน Koder.ai เริ่มจากโหมดวางแผนเพื่อร่างระเบียนและหน้าจอ (สินค้าพร้อมแมป HSN/SAC รายละเอียดลูกค้า/GSTIN กฎภาษี และใบกำกับ) สร้างแอป ทดสอบออร์เดอร์จริงสักไม่กี่เคสจากต้นทางถึงปลายทาง แล้วใช้สแนปช็อตและการย้อนกลับ (rollback) เพื่อปรับปรุงฟลอว์อย่างปลอดภัย เมื่อต้องการปรับแต่งลึกขึ้นหรือรีวิว ให้ส่งออกรหัสต้นทางและพัฒนาต่อด้วยกระบวนการปกติของคุณ