0.4 · วันหนึ่งของ HR
บทนี้เล่าว่า HR ของสภากาชาดใช้ระบบ VTRC อย่างไรในแต่ละวัน
คนที่ใช้ backoffice หนักที่สุดคือเจ้าหน้าที่ HR — พวกเขาเป็นคนที่รู้ดีที่สุดว่า feature ไหน "ใช้จริง" หรือ "ทิ้งไว้" และเป็น source of truth เวลาเจอพฤติกรรมที่ดูผิดปกติ ในระบบ
08:30 — เปิด Backoffice
HR เปิด https://vtrcbackoffice.redcross.or.th/ และ login ผ่าน mutation loginBackoffice (ต่างจากฝั่ง end-user ที่ใช้ login)
ความแตกต่างหลักคือ routing — loginBackoffice บังคับว่า role ต้องเป็นหนึ่งใน SUPER_ADMIN, ADMIN, STAFF ไม่งั้น reject ตั้งแต่ต้นทาง ไม่ต้องรอเช็ค menu-level
token ที่ได้ carry role JSON blob มาด้วย — downstream @auth(accessMenu: [...]) directive ใช้ตรวจต่อว่าเข้าเมนูไหนได้บ้าง
09:00 — อนุมัติคำขอลา
HR เปิดเมนู "Leave" เห็นรายการคำขอลาที่รอการอนุมัติของตนเอง (filter ตาม orgCode และ role)
สำหรับแต่ละคำขอ HR ทำได้ 4 อย่าง
- Approve — ส่งไป level ถัดไป (ถ้ามี) หรือตั้ง status เป็น
APPROVEถ้าเป็น level สุดท้าย - Reject — ตั้ง status
REJECTและจบ flow - More Info — ตั้ง status
MOREINFOเพื่อให้พนักงานแก้ไขแล้วส่งใหม่ - Edit — แก้คำขอแทนพนักงาน (ทำได้เฉพาะ HR HQ
orgCode 0734*)
chain ของผู้อนุมัติแต่ละ level ไม่ได้เก็บใน VTRC — ดึงจาก HRMI ผ่าน hrmiGetApproverCD ทุกครั้ง แปลว่าถ้า HRMI ล่ม การอนุมัติก็ล่มด้วย
รายละเอียดตรรกะใน vtrc-api/api/src/lib/controllers/hrmi/hrmi.js:60-180
10:00 — อนุมัติคำขอเบิกสวัสดิการ (WDHospital)
flow คล้ายการลา แต่ state machine ซับซ้อนกว่า — มี 13 states
| State ปัจจุบัน | HR ทำอะไรได้ | ผลลัพธ์ |
|---|---|---|
PENDING | approve / reject / moreinfo / edit | ไป state ถัดไป |
MOREINFO | (รอพนักงานแก้) | พนักงาน resubmit → กลับ PENDING |
APPROVE | export KBANK / จ่ายเงินสด | PAID / PAIDCASH / FAILED |
FAILED | retry / cancel | SUCCESS / CANCELDOC |
รายชื่อ state ทั้งหมดจาก models/core/withdraw/hospital.js:95
DRAFT, PENDING, MOREINFO, APPROVE, REJECT, PAID, FAILED, SUCCESS, CANCEL, CASH, EDIT, CANCELDOC, PAIDCASH
บาง state มี typo (DRAF แทน DRAFT ในบางที่, PEDDING_CANCLE) — ต้องระวังตอนเขียนโค้ดใหม่
11:00 — Export ข้อมูลธนาคาร (KBANK)
เมื่อมีคำขอ WDHospital หลายคำขอที่ status APPROVE HR จะ export เป็น batch เพื่อส่งให้ธนาคารกสิกรไทย (KBANK K-Cash)
ขั้นตอนจริง
- HR เลือกคำขอที่จะ export ในหน้า backoffice
- backoffice ส่ง GraphQL
wdExportไปvtrc-api vtrc-apiรวบรวม WDHospital ที่ statusAPPROVEและ bankKBANKสร้าง row ในWDExportแล้วส่งไฟล์กลับ (CSV/Excel)- HR ดาวน์โหลดไฟล์ นำไป upload ที่ระบบ K-Cash ของธนาคารกสิกรไทยเอง (manual step — ไม่ integrate อัตโนมัติ)
- หลังจาก K-Cash ประมวลผล HR นำเข้าผลลัพธ์กลับเอง ผ่าน mutation
importUpdateStatus(อัปโหลดไฟล์) — ไม่มี job ดึงผล K-Cash ในvtrc-api/api/src/crons.js
K-Cash ส่ง code กลับมา — ทีม map ไว้ใน config.js:488-518 (statusKcash)
| K-Cash code | VTRC status (statusKcash[].status) |
|---|---|
9 | SUCCESS |
6, 7, 8, 10 | FAILED |
ถ้า HR บอกว่า "KBANK ไม่อัปเดต" ให้เช็คว่าได้นำเข้าไฟล์ผลผ่าน importUpdateStatus แล้วหรือยัง แล้วค่อยเทียบ code กับ statusKcash
13:00 — จัดการ Master Data
HR ใช้หลายเมนู master data ในแต่ละวัน เช่น
| เมนู | ตาราง | หน้าที่ |
|---|---|---|
| HospitalName | Hospital | ชื่อโรงพยาบาล |
| SicknessName | Sickness | รายการโรค |
| BankBranches | BankBranch | สาขาธนาคาร |
| BankExportCode | (config) | รหัส export |
| MasterApprovers | MasterApprover | ผู้อนุมัติตาม orgCode |
| MasterData | MasterData | generic key-value config |
| LeaveName | (config + table) | ชื่อประเภทการลา |
ถ้ามีโรงพยาบาลใหม่ หรือโรคใหม่ HR ต้องเพิ่มเองที่นี่ ไม่มี sync อัตโนมัติจากระบบภายนอก
14:00 — ดูรายงาน
backoffice มีเมนูรายงานหลายตัว
ReportWelfare— รายงานสวัสดิการTuitionFeesReport— รายงานค่าเล่าเรียนApproveWelfareReport— รายงานการอนุมัติHospitalFailed— รายงานคำขอล้มเหลว
รายงานส่วนใหญ่ export เป็น Excel ผ่าน GET /download/excel/:table ที่ vtrc-api/api/src/routes.js — ใช้ exceljs สร้างไฟล์ส่งกลับ
15:00 — จัดการผู้ใช้และสิทธิ์
HR เปิดเมนู "ManageUser" จัดการผู้ใช้และสิทธิ์ โดยกำหนด
- Role —
SUPER_ADMIN,ADMIN,STAFF(backoffice) หรือUSER(end-user) - Menu Access — 32+ menu ที่กำหนดไว้ใน
config.js:159-370(MENUS_BACK_OFFICE)
ข้อควรระวัง — RBAC ในระบบนี้เก็บเป็น JSON blob ในคอลัมน์ Users.role ไม่ใช่ relation table แปลว่าการ audit สิทธิ์ด้วย SQL ปกติทำไม่ได้ ต้อง parse JSON
นอกจากนี้มี bug เงียบ — getCurrentRoleUser (session.js:130) อ่าน Role.roleName แต่ checkMenuAuth (session.js:55) อ่าน userResult[0].role.accessRole ซึ่งไม่มีใน JSON blob — รายละเอียดใน Volume 10 · Security
16:00 — ดูแล Subsystems
backoffice ไม่ใช่แค่ HR หลัก ยังมี subsystems หลายตัวที่มี axios instance แยก
| Subsystem | ไฟล์ axios config | บทบาท |
|---|---|---|
| PMS | axios-pms.js | Performance Management |
| Recruitment | axios-recruitment.js, axios-recruitment-upload.js | รับสมัครงาน |
| Meeting | axios-meeting.js | จัดการประชุม |
| WorkForce | axios-workforce.js, axios-workforce-upload.js, apollo-workforce.js | บริหารบุคคล |
| Benefit | axios-benefit.js, axios-benefit-i3.js | สวัสดิการเพิ่มเติม |
| Payments | axios-payments.js | การชำระเงิน |
| AI | axios-ai.js | (TBD) |
ถ้า HR แจ้งปัญหาเรื่อง subsystem ใด subsystem หนึ่ง ให้เริ่ม debug ที่ axios config ของ subsystem นั้นก่อน — มันเป็นจุดเชื่อมระหว่าง frontend กับ API ของ subsystem
17:00 — ล็อกเอาต์
เหมือนฝั่งพนักงาน — เรียก Mutation.logout ทำลาย Session row แล้ว redirect หน้า login
สรุปแบบกระชับ
| เวลา | สิ่งที่ทำ | ระบบที่เกี่ยวข้อง |
|---|---|---|
| 08:30 | Login backoffice | vtrc-rc-backoffice → vtrc-api |
| 09:00 | อนุมัติลา | vtrc-rc-backoffice → vtrc-api (+ อ่าน HRMI ผ่าน bridge) |
| 10:00 | อนุมัติเบิกสวัสดิการ | vtrc-rc-backoffice → vtrc-api |
| 11:00 | Export KBANK | vtrc-rc-backoffice → vtrc-api |
| 13:00 | จัดการ master data | vtrc-rc-backoffice → vtrc-api |
| 14:00 | ดูรายงาน | vtrc-rc-backoffice → vtrc-api |
| 15:00 | จัดการผู้ใช้และสิทธิ์ | vtrc-rc-backoffice → vtrc-api |
| 16:00 | ดูแล subsystems | vtrc-rc-backoffice → APIs หลายตัว |