1.15 · ข้อจำกัดทางธุรกิจ + Edge Cases
บทสุดท้ายของ Volume 1 รวม "ความซับซ้อนที่ไม่ได้บอกไว้ในเอกสาร" — รหัสพิเศษ, typo ที่ติดมา, by-pass rules, และ edge cases ที่ต้องรู้ตอน debug
เอาไว้ใช้ตอนเจอพฤติกรรมที่ดูผิดปกติและไม่แน่ใจว่าเป็น bug หรือเป็น policy
รหัสพิเศษในระบบ
orgCode prefix
| Code | หมายถึง | ผลกระทบ |
|---|---|---|
0734* | HR HQ (สนง. บริหารทรัพยากรบุคคล) | bypass validation การลา + admin ทั่วระบบ |
88 | ผู้รับบำนาญ | tag empType = "บำนาญ" อัตโนมัติ |
UUID/Key พิเศษ (config.js:152-154)
| ชื่อ | ค่า | ใช้ทำอะไร |
|---|---|---|
KEY_CU_H | 'CU-RE-STRUCTURE-ID-02' | ระบุกลุ่มพนักงานจุฬา (CU restructure) |
KEY_PLASMA | '47837e2d-7788-4a1a-8e24-a90abf6742f4' | ระบุกลุ่ม plasma (ธนาคารเลือด) |
KEY_HR | ['305A814A-...', '5A764C0F-...'] | ระบุ HR staff (array 2 UUID) |
Profile Keys
| profileKey | sourceDB | หมายถึง |
|---|---|---|
dbHRMI_RC_B_rep | HRMI กาชาด สาขา B | พนักงานกาชาดกลุ่ม B |
dbHRMI_CU_SC_rep | HRMI จุฬา SC | พนักงานจุฬากลุ่ม SC |
emplGrupCode
| Code | หมายถึง | file:line |
|---|---|---|
04 | ผู้รับบำนาญ (บน dbHRMI_RC_B_rep) | slip.js:255-294 — เปลี่ยน label "เงินเดือน" → "แสดงเฉพาะเงินบำนาญ" |
ความสัมพันธ์เบิกสวัสดิการ
config.js:392-429 — relationHrmi code
| Code | ความสัมพันธ์ | จำกัดจำนวน |
|---|---|---|
00 | ตัวเอง | self |
10 | บิดา | 1 คน |
20 | มารดา | 1 คน |
70 | คู่สมรส | 1 คน |
81–85 | บุตรคนที่ 1–5 | สูงสุด 5 คน |
policy "สูงสุด 5 บุตร" hardcode — ต้องแก้ code ถ้า HR อยากขยาย
HRMI status code
config.js:430-458 — statusHrmi (single letter)
| Letter | หมายถึง |
|---|---|
W | PENDING (Wait) |
Y | APPROVE (Yes) |
N | REJECT (No) |
C | CANCEL |
CR | CREATE |
A | ALL |
D | DRAFT |
statusHrmiName (config.js:459-487) — version ที่มี label ไทย
K-Cash status code
config.js:488-519 — รหัสจาก KBANK
| Code | หมายถึง | VTRC status |
|---|---|---|
6 | duplicate + stoppay | FAILED |
7 | cancelled | FAILED |
8 | stoppay | FAILED |
9 | paid | SUCCESS |
10 | unsuccessful credit | FAILED |
ถ้าเจอ code อื่นที่ไม่อยู่ใน map — VTRC ไม่อัปเดต (row ค้าง)
Typo ที่ติดมาใน production
| Term | ที่ถูก | file:line | ผลกระทบ |
|---|---|---|---|
PEDDING_CANCLE | PENDING_CANCEL | models/core/leave/leave.js:59 | ทุก consumer ต้องสะกดผิดเหมือนกัน — อย่า "แก้ให้ถูก" |
CONINCLE_USERNAME | CONICLE_USERNAME | config.js:34-35 | env var ต้องตรง typo |
DRAF (ในบางที่) | DRAFT | (หลายจุด) | บางครั้งต้อง match ทั้งสองแบบ |
| "เป็ฯสมาชิก" | "เป็นสมาชิก" | providentFund.js:288 (docstring) | cosmetic — ไม่มีผลทาง logic |
กฎ — typo ที่อยู่ใน ENUM หรือใน database ต้องอยู่ต่อไป ถ้าแก้ที่จุดเดียวจะพังทุกจุดที่เหลือ
By-pass rules ที่ตั้งใจ
| Rule | file:line | เหตุผล |
|---|---|---|
HR HQ (0734) ข้าม leave validation | hrmi.js:1302 | HR HQ อนุมัติเอง ไม่จำเป็นต้อง validate ตอนยื่น |
adminCanPass === true ข้าม validation | hrmi.js:1302 | admin บังคับผ่าน (ใช้ตอนแก้ให้พนักงาน) |
SC profile ถูกบังคับ orgUnitCode = '02' | slip.js:175-177 | CU จัดการ SC กลุ่มนี้แยกใน HRMI |
Continuous leave — ลาป่วยต่อเนื่อง
hrmi.js:1164-1216 — findLeaveContinuos(args, empCode, reqAttachDay)
กฎ — ถ้าลาป่วย (type "1") ต่อเนื่อง >= reqAttachDay วัน ต้องแนบใบแพทย์
algorithm
- เริ่มจาก
leaveStartDate - เดินหลัง → หาลาป่วย
PENDING/APPROVEวันก่อนหน้า - เดินหน้า → หาลาป่วยวันถัดไป
- รวม — ถ้า >=
reqAttachDayและไม่มี attach → reject
Edge case — ถ้าลา "H1" (ครึ่งวันเช้า) แล้ววันถัดไป "H2" (ครึ่งวันบ่าย) — algorithm ถือว่าต่อเนื่อง 2 วัน (แม้รวมเป็น 1 วัน)
การยื่นคำขอแทน — HR แทนพนักงาน
clientType enum — WEB_CLIENT vs WEB_ADMIN
| clientType | ใครยื่น | validation |
|---|---|---|
WEB_CLIENT | พนักงานเอง | เคร่งครัด |
WEB_ADMIN | HR แทน (ไม่ใช่ 0734) | เคร่งครัด |
WEB_ADMIN + orgUnit 0734* | HR HQ แทน | bypass |
field นี้เก็บใน LeaveDocument.clientType (leave.js:1-164) — ใช้ audit
Multi-profile edge case
พนักงานที่มีหลาย profile (RC + CU)
| สถานการณ์ | ผล |
|---|---|
| สลับ profile ระหว่าง session | slip + tax เปลี่ยน sourceDB — cache อาจสับสน |
| ลาใน profile CU | เห็นใน profile RC ไหม? ไม่ — แยกกัน |
| เบิก WDHospital ใน profile CU | ใช้ slip ของ CU คำนวณยอดเบิก |
| Sync ข้อมูล profile | ไม่ sync — แต่ละ profile independent |
Reset password — edge cases
forgetPassword flow (user.js:16-33)
| สถานการณ์ | ผล |
|---|---|
| เบอร์โทรใน HRMI ผิด | OTP ไม่ถึง → ต้องแจ้ง HR แก้ HRMI |
| กรอก idCard ผิดใน reset | reject — ต้องรอ OTP ใหม่ |
| กรอก birthDate ผิด | reject — defense in depth |
| LoginSession ล็อก (3 attempts ผิด) | ต้องรอ 15 นาทีให้หมดอายุ |
Cron jobs — ทั้งหมด 3 ตัว (ที่ active)
vtrc-api/api/src/crons.js:14-27
| Schedule | Job | เงื่อนไข |
|---|---|---|
* 1 * * * * (ทุกนาที) | updateSuccessFundChangeRateByJob | APP_NO === 1 เท่านั้น |
30 3 * * * (03:30 ประจำวัน) | updateDelegatesExpire | (ไม่มีเงื่อนไข) |
30 0 * * * (00:30 ประจำวัน) | statLog | (ไม่มีเงื่อนไข) |
Cron ที่ disabled
crons.js:29-70 — comment ไว้ — แผนเดิมคือจะ auto-cancel leave ของหน่วยงาน 0734 ทุกวันที่ 16 ของเดือน แต่ยังไม่เปิดใช้
Cron ที่ "ไม่มี" แต่ควรมี
- KBANK K-Cash result import → operator manual (เพราะ KBANK ไม่มี API)
- Session cleanup (VTRC ไม่ได้ลบ session หมดอายุ active — แค่ mark expire)
- Profile sync จาก HRMI → live-pull ทุก request
- Notification retry → ไม่มี — ถ้า fail หาย
ข้อจำกัดของระบบการลา
- ประเภทการลาไม่ได้ hardcode — ดึงจาก HRMI live (
getLeaveType) - Approver chain ดึงจาก HRMI live (
getLeaveApprover) — ถ้า HRMI ล่ม อนุมัติไม่ได้ - ไม่สามารถ "ยื่นแทน" โดยไม่ผ่าน validation ได้ (เว้น
adminCanPassหรือ 0734) - attachment ถูกลบเมื่อ document ถูก delete — ไม่มี trash
ข้อจำกัดของ WDHospital
- ไม่มี auto-cancel — WDHospital
PENDINGที่ approver ไม่ตอบจะค้างตลอด - ไม่มี idempotency ใน
importUpdateStatus— upload ซ้ำจะ update ซ้ำ MasterApprovers.isActive = 0ทำให้ไม่เจอผู้อนุมัติ — แต่ไม่มี UI warning- ยอด
totalCurrentWithdrawแก้โดย admin ได้หลัง create — ไม่มี approval สำหรับการแก้ยอด
ข้อจำกัดของ Provident Fund
- ช่วงเปลี่ยน rate ปิดแล้ว → พนักงานยื่นไม่ได้ ต้องรอปีถัดไป
benefitsRateผลรวมต้อง 100% — ถ้าไม่ครบ HRMI ปฏิเสธforceUpdateSuccessStatusทิ้ง audit trail ไม่ครบ — ใช้ด้วยความระมัดระวัง- sync ไป HRMI เป็น batch — เหมือน TaxDraft
ข้อจำกัดที่ต้องรู้ทั่วไป
- HRMI เป็น source of truth ของ profile data — VTRC แค่ cache
- การแก้ข้อมูลพนักงานส่วนใหญ่ต้องทำที่ HRMI ไม่ใช่ VTRC
- ถ้า HRMI ล่ม → VTRC ใช้งานไม่ได้เกือบทั้งหมด
- การ sync ข้อมูล VTRC → HRMI เป็น batch ไม่ใช่ real-time
- VTRC ไม่เคยลบ User row — ปล่อยทิ้งไว้เพื่อ audit
- ไฟล์
_bk*หลายร้อยไฟล์ — อย่าแก้ (ตามกฎ workspace)
สิ่งที่ต้องถาม HR — policy ที่ไม่ได้ document
- policy "เบิกบุตรได้สูงสุด 5 คน" — จะขยายไหม
- กฎ "ลาต่อเนื่องกี่วันต้องมีใบแพทย์" —
reqAttachDayตั้งตามอะไร - กฎ "HR HQ ข้าม validation" — ยังเปิดอยู่ไหม (policy อาจเปลี่ยน)
- Study Leave — เงื่อนไขผู้ค้ำประกันคืออะไร
- policy "ต้องกลับมาทำงานกี่ปี" หลังลาศึกษา
- ช่วงเปลี่ยน contribution กองทุน — วันที่แน่นอนปีนี้
- Conicle — ใครเป็น owner ของข้อมูล training
ถ้าเจอ field ในโค้ดที่ไม่เข้าใจ — อย่าเดา ถาม HR ก่อน
ขั้นตอนถัดไป
ไป Volume 2 · Architecture & Topology → หรือกลับไป ภาพรวม Volume 1