เบื้องหลัง VertexHR: หลักฐานเวลาและการแก้ไขต้องตามย้อนหลังได้

เก็บเหตุการณ์ต้นฉบับแยกจากเวลาที่ระบบคำนวณ

Clock event ควรมี event ID, employee, timestamp, event type, source/channel และข้อมูลประกอบที่ได้รับอนุญาต เช่น site หรือ device context แล้วค่อยให้ระบบคำนวณ work session, break และยอดเวลาจาก event เหล่านี้

ถ้ามีการแก้เวลา อย่า overwrite raw event จนดูเหมือนพนักงานกดเวลานั้นตั้งแต่แรก ให้สร้าง correction/decision layer ที่อธิบายว่าค่าแสดงผลหรือ payroll-ready value ถูกปรับจาก evidence ใด

คำขอแก้ไขต้องเป็นงานที่มีเหตุผลและหลักฐาน

ตัวอย่างสมมติ: พนักงานลืม Clock Out แล้วแจ้งเวลา 18:00 ในวันถัดมา ระบบควรเก็บ requester, requested value, reason, attachment/remark และเวลาที่ส่งคำขอ แยกจาก approved value เพราะหัวหน้างานอาจอนุมัติเวลาอื่นตามหลักฐาน

สถานะอาจเป็น Draft → Submitted → Approved/Rejected → Applied โดยแต่ละ transition มี actor และ timestamp ถ้ามีการขอแก้อีกครั้งหลัง Applied ให้สร้าง revision ใหม่ ไม่ลบ decision เดิม

ผู้อนุมัติควรเห็นสิ่งที่เปลี่ยนและผลกระทบก่อนกดอนุมัติ

หน้าตรวจควรแสดง original events, ค่าที่ขอแก้, เหตุผล, schedule/site context และผลต่างชั่วโมงที่คาดว่าจะเกิด ไม่ควรให้หัวหน้างานอนุมัติจากข้อความ “ขอแก้เวลา” โดยไม่เห็น before/after

สิทธิ์แก้ raw data, อนุมัติ correction และรัน payroll/attendance calculation ควรแยกตามบทบาทเท่าที่โครงสร้างองค์กรทำได้ หากทีมเล็กต้องใช้คนเดียวกัน ควรมี review log หรือรายงานการแก้ไขเป็น control ชดเชย

หลังอนุมัติ ต้องรู้ว่ารายงานใดถูกคำนวณใหม่จาก version ไหน

เมื่อ correction เปลี่ยนเวลาทำงาน ให้ระบบบันทึกว่า attendance summary, overtime candidate, leave overlap หรือ downstream export ใดถูก recalculated และใช้ correction revision ไหน เพื่อไม่ให้รายงานหนึ่งเห็นค่าใหม่แต่อีกระบบยังถือค่าเก่าโดยไม่มี warning

หาก period ถูก lock หรือส่ง payroll ไปแล้ว correction อาจต้องเข้าสู่ adjustment flow แทนการแก้ย้อนหลังตรง ๆ หลักการคือรักษาสถานะที่เคยใช้ตัดสินใจแล้ว และสร้างการปรับปรุงที่มี reference ต่อกัน

ใช้บทความนี้เป็น UAT checklist ของ VertexHR มากกว่าคำสัญญาฟังก์ชัน

Linda แนะนำ VertexHR สำหรับ employee records, attendance, leave และ payroll workflows และหน้า Applications ระบุให้ยืนยัน module, permissions, data handoffs และ service scope ก่อน onboarding ดังนั้นลูกค้าควรทดสอบ correction flow ด้วยข้อมูลจำลองก่อนเปิดใช้จริง

กรณี UAT ควรมีลืม Clock Out, request ถูก reject, approved value ต่างจาก requested value, correction หลัง period lock และ export ซ้ำหลังแก้ไข แล้วตรวจว่า audit trail บอก original/request/decision/applied revision ได้ครบ

แหล่งอ้างอิง: [1]

นำไปใช้กับธุรกิจของคุณ

ความน่าเชื่อถือของระบบเวลาไม่ได้มาจากการห้ามแก้ข้อมูล แต่มาจากการแก้ได้อย่างมีร่องรอยและอธิบายได้ว่า original fact, human decision และผลคำนวณแต่ละ version เชื่อมกันอย่างไร