หากพบรายการตกหล่นหลังจ่าย ไม่ควรแก้ยอดในงวดเดิมให้ดูเหมือนถูกตั้งแต่แรก ควรสร้างรายการปรับที่อ้างอิงเหตุผล งวดที่เกี่ยวข้อง และผู้อนุมัติ เพื่อให้พนักงานและฝ่ายตรวจสอบเข้าใจความเปลี่ยนแปลง
รักษางวดที่ปิดแล้วเป็นหลักฐาน
หากพบรายการตกหล่นหลังจ่าย ไม่ควรแก้ยอดในงวดเดิมให้ดูเหมือนถูกตั้งแต่แรก ควรสร้างรายการปรับที่อ้างอิงเหตุผล งวดที่เกี่ยวข้อง และผู้อนุมัติ เพื่อให้พนักงานและฝ่ายตรวจสอบเข้าใจความเปลี่ยนแปลง
แยกระหว่างการแก้ข้อมูลต้นทางกับการตกลงว่าจะนำผลต่างไปจ่ายในงวดใด บางบริษัทมีรอบจ่ายเพิ่ม บางกรณีเข้ารอบถัดไป ทั้งหมดต้องตรวจข้อกำหนดที่เกี่ยวข้องกับผู้รับผิดชอบ
คิดผลต่างจากฐานเดิมที่ตรวจได้
ตัวอย่างสมมติ มีรายการเพิ่มที่อนุมัติไว้ 1,000 บาท แต่งวดเดิมนำไปคำนวณเพียง 600 บาท ผลต่างก่อนผลของรายการอื่นคือ 400 บาท ระบบต้องแสดงทั้งจำนวนเดิม จำนวนที่ควรเป็น และเหตุผล
ถ้ารายการนั้นมีผลต่อการคำนวณอื่น ห้ามบวกส่วนต่างตรง ๆ โดยไม่ประเมินผลรวม ให้ผู้รับผิดชอบตรวจสูตรและเอกสารที่ต้องแก้ประกอบ
สิ่งที่รายงานปรับย้อนหลังควรตอบ
| สถานการณ์ | สิ่งที่ระบบควรทำ | วิธีตรวจ |
|---|---|---|
| รายการเดิม | อ่านค่าและสูตรงวดเดิมได้ | ไม่ถูกแก้ทับ |
| รายการปรับ | มีเหตุผลและเอกสารอ้างอิง | รู้ว่าแก้ครั้งที่เท่าใด |
| รายการจ่าย | ผูกกับงวดหรือรอบพิเศษ | ไม่จ่ายซ้ำ |
| คำขอถูกปฏิเสธ | เก็บเหตุผลและผู้ตรวจ | ผู้ขอทราบสถานะ |
ป้องกันการแก้ซ้ำจากการประสานงานหลายฝ่าย
กำหนดรหัสคำขอเดียวตั้งแต่รับเรื่องจนส่งจ่าย และตรวจว่ารายการเดียวกันเคยเข้ารอบก่อนหรือไม่ เมื่อแจ้งผลพนักงาน ควรอธิบายช่วงที่ปรับและรายการในสลิปอย่างชัดเจน
ทดสอบการปรับหลายครั้งในงวดเดียว การยกเลิกก่อนจ่าย และกรณีธนาคารไม่รับรายการ เพื่อให้สถานะอนุมัติกับจ่ายจริงไม่ปะปน
เช็กลิสต์ก่อนเริ่มทำระบบ
- ขั้นตอนรับคำร้องและหลักฐานของแต่ละประเภท
- สิทธิ์เปิดงวดหรือสร้างรายการปรับแยก
- รูปแบบสลิปและข้อความแจ้งผล
- การตรวจสูตรและผลกระทบโดยฝ่ายเงินเดือน/บัญชี
คำถามที่พบบ่อย
ลบงวดแล้วคำนวณใหม่ง่ายกว่าไหม?
หลังมีการอนุมัติหรือจ่ายจริง การลบอาจทำให้หลักฐานหาย ควรใช้กระบวนการปรับที่ตรวจย้อนกลับได้ตามนโยบายและข้อกำหนด
พนักงานออกแล้วแก้รายการได้ไหม?
ต้องรองรับสถานะการจ้างเดิมและช่องทางดำเนินการที่ผู้รับผิดชอบอนุมัติ โดยไม่เปิดสิทธิ์ระบบของพนักงานกลับโดยไม่จำเป็น
อ่านต่อจากแหล่งข้อมูลโดยตรง
ลิงก์ต่อไปนี้ประกอบประเด็นมาตรฐานและการเชื่อมต่อ ส่วนตัวอย่างขั้นตอนและตัวเลขในบทความใช้เพื่ออธิบายการออกแบบระบบ
ตรวจแหล่งข้อมูล: 11 ตุลาคม 2569 · สิทธิ์ API และข้อกำหนดอาจเปลี่ยนได้ ควรยืนยันก่อนเริ่มโครงการ