การทำงานเฉพาะธุรกิจ
แลกเวรแล้วใครต้องเห็นข้อมูลอะไร: มุมงานบุคคลและการอนุมัติ
รักษาเวรเดิม คำขอ คู่แลก การยอมรับ policy checks และ approval แยกกัน ก่อนให้ attendance/payroll อ้าง final assignment
ในองค์กรที่มีเวร เช่น โรงพยาบาล โรงแรม หรือบริการ 24 ชั่วโมง การแลกเวรอาจเกิดจากคน A ขอปล่อยเวรให้คน B หรือสองคนสลับเวรกัน ถ้าระบบแก้ตารางโดยตรงจนไม่เห็น request และ approval ภายหลังจะตอบยากว่าใครควรมาทำงาน ใครได้รับอนุมัติ และทำไม attendance ของวันนั้นต่างจาก roster เดิม
บทความนี้อธิบาย operational workflow และ auditability ไม่ใช่เกณฑ์ความปลอดภัยของการขึ้นเวรหรือคำแนะนำทางกฎหมายแรงงาน องค์กรต้องใช้ policy ของตนเองในการพิจารณาความเหมาะสมของชั่วโมง การพัก คุณสมบัติ และข้อจำกัดเฉพาะวิชาชีพ
เก็บเวรเดิมไว้เป็น Baseline ก่อนสร้างคำขอแลก
Shift Assignment เดิมควรระบุ employee, shift type, date/range และสถานะที่ใช้เป็น baseline เมื่อมีคำขอแลก ให้ request อ้าง assignment เดิมทั้งสองฝั่ง ไม่ควรแก้ตารางก่อน approval แล้วค่อยพยายามย้อนว่าใครเคยถูกมอบหมาย
Frappe HR แยก Shift Request ออกจาก Shift Assignment และเมื่อ request ถูก approved/submitted จึงสร้าง assignment ซึ่งเป็นตัวอย่างที่ดีว่าคำขอและตารางที่มีผลจริงควรเป็นคนละ record/state
คำขอแลกต้องบอกคู่เวรและผู้รับผิดชอบให้ครบ
สำหรับ swap ให้เก็บ requester, original assignment A, proposed assignment B, target employee, date/time, reason และ expiration ของคำขอ ถ้าเป็นการขาย/โอนเวรฝ่ายเดียว ให้ระบุว่าเป็น transfer มากกว่า swap เพื่อไม่ให้ระบบสมมติว่ามีเวรอีกฝั่งต้องสลับกลับ
ถ้าคน B ยังไม่ยอมรับ คำขอไม่ควรถูกถือว่าเป็นการเปลี่ยน roster แล้ว สถานะควรแยก Offered / Accepted / Pending Approval / Approved / Rejected / Expired ตามความซับซ้อนที่องค์กรต้องการ
ตรวจ Eligibility ก่อนส่งให้ผู้อนุมัติ
ก่อนอนุมัติ ระบบควรตรวจข้อขัดแย้งพื้นฐาน เช่น B มี assignment ซ้อนในช่วงเดียวกันหรือไม่ อยู่ในหน่วย/role ที่รับเวรนั้นได้หรือไม่ และ policy ขององค์กรกำหนดข้อจำกัดอื่นใด การตรวจนี้เป็น validation ของข้อมูลและ policy ไม่ใช่คำตัดสินว่าชั่วโมงนั้นปลอดภัยทางคลินิก
Frappe HR รองรับ multiple shift assignments ในวันเดียวได้หรือไม่ตาม HR Settings ซึ่งชี้ว่าระบบ scheduling ต้องมี policy ชัดเจน ไม่ใช่ถือว่า overlap ทุกแบบผิดหรือถูกเหมือนกัน
แหล่งอ้างอิง: [2]
แยก Accept ของพนักงานออกจาก Approve ของหัวหน้า
การที่ผู้รับเวรกดยอมรับหมายถึงยินดีรับข้อเสนอ แต่ยังไม่ควรเท่ากับ organizational approval ถ้านโยบายกำหนดให้หัวหน้า/HR ตรวจ ตารางใหม่ควรมีผลเมื่อ approval สำเร็จ แล้วแจ้งทั้งผู้ปล่อย ผู้รับ และผู้เกี่ยวข้องกับ roster
Frappe HR Shift Request มี approver ที่ระดับ Employee หรือ Department และเมื่อ approved/submitted จึงสร้าง Shift Assignment หลักคิดนี้ช่วยแยก employee intent ออกจาก authority ขององค์กร
แหล่งอ้างอิง: [1]
Attendance และ Payroll ต้องอ้าง Final Assignment ไม่ใช่ตารางที่ถูกแก้ย้อนหลังแบบไร้ร่องรอย
เมื่อ swap approved ให้สร้าง superseding assignment หรือ revision ที่มี effective date และ reference ไป request เดิม จากนั้น attendance exception ของ A/B และ downstream report ต้องรู้ว่า assignment version ใด active ณ วันนั้น
Linda ระบุ VertexHR สำหรับ attendance, leave และ payroll workflow และกำหนดให้ยืนยัน module/permission/handoff ก่อน onboarding ดังนั้น UAT ควรมี swap accepted แต่ยังไม่ approved, swap rejected, overlapping shift, cancellation หลัง approved และ attendance ที่เกิดหลัง roster เปลี่ยน เพื่อยืนยัน lineage จริงของระบบ
แหล่งอ้างอิง: [3]
เช็กลิสต์เริ่มต้น
- เก็บ original assignment เป็น baseline ก่อน request
- ระบุ requester, counterparty, เวรเดิม/ใหม่ และ request type
- ตรวจ conflict/eligibility ตาม policy ก่อน approval
- แยก employee acceptance ออกจาก manager/HR approval
- ให้ attendance/payroll อ้าง final assignment revision พร้อม audit trail
นำไปใช้กับธุรกิจของคุณ
การแลกเวรที่ตรวจสอบได้ไม่ใช่การเปลี่ยนชื่อคนบนปฏิทิน แต่เป็น transaction ของ schedule ที่มี proposal, consent, policy checks, approval และ downstream lineage ครบ
แหล่งอ้างอิง
- Frappe HR. (n.d.). Shift Request. สืบค้น 1 ตุลาคม 2026.
- Frappe HR. (n.d.). Shift Assignment. สืบค้น 1 ตุลาคม 2026.
- Linda Accounting IT. (2026). Linda Business Applications. สืบค้น 1 ตุลาคม 2026.
แหล่งอ้างอิงรองรับข้อความที่ระบุหมายเลข ส่วนตัวอย่างและแนวทางปฏิบัติเป็นข้อเสนอของ Linda ไม่ใช่ผลลัพธ์ที่รับรองจากลูกค้าจริง
บทความนี้เป็นแนวทางออกแบบงานและตัวอย่างเพื่อการเรียนรู้ ไม่ใช่คำวินิจฉัยบัญชี ภาษี กฎหมาย หรือการรับรองความพร้อมของทุกโมดูล การนำไปใช้ต้องพิจารณาธุรกิจ สิทธิ์ผู้ใช้ และขอบเขตระบบจริง