14.1 · HR workflows overview
บทนี้ไล่ 5 กระบวนการ HR หลักของ VTRC แบบ end-to-end — ระบุว่าแต่ละขั้นตอนอยู่ใน repo ไหน ใครเป็นเจ้าของข้อมูล และจุดที่ repo อื่นเข้ามาแทรก
14.1.1 · Leave request (การลา)
| ขั้นตอน | Repo | หลักฐาน |
|---|---|---|
| พนักงานยื่นใบลา | vtrc-web/vtrc-mobile (GraphQL mutation) → vtrc-api cluster C (hrmi/hrmi.js — createLeaveDocument) | vtrc-api/06-controllers §Cluster C |
| ตรวจสิทธิ์วันลา (max/min ต่อประเภท) | vtrc-api — business rule anchor ใน hrmi.js พร้อม admin bypass ตาม orgUnitCode | vtrc-api/06-controllers §Cluster C |
| ข้อมูลวันลาสะสม/approver chain จริง | cu-central-api (ข้อมูล HRMI ต้นทาง ผ่าน GraphQL bridge) | vtrc-api/04-centralize-bridge |
| อนุมัติใบลา | vtrc-api — getApprover/getLeaveApprover ใน hrmi.js | vtrc-api/06-controllers §Cluster C |
| แจ้งเตือนผลอนุมัติ | vtrc-api cluster F (notification/notification.js) → Firebase Cloud Messaging (legacy HTTP v1) | vtrc-api/04-centralize-bridge |
เจ้าของข้อมูลจริง — ใบลาที่สร้างแล้วเก็บใน database vtrc (schema ของ vtrc-api เอง) แต่วันลาคงเหลือ/HR master คำนวณจาก HRMI ผ่าน cu-central-api — ทุกครั้งที่ยื่นใบลาจึงมี network round-trip ไป cu-central-api เสมอ (ไม่มี cache — ดู vtrc-api/04-centralize-bridge §Caching) ถ้า cu-central-api ช้า/ล่ม การยื่นใบลาก็ทำไม่ได้ทั้งระบบ
14.1.2 · Welfare/benefit withdrawal (การเบิกสวัสดิการ)
มี 2 ระบบคู่ขนาน ที่ทำหน้าที่คล้ายกันแต่แยก repo กันคนละตัวตามยุคที่พัฒนา:
| ประเภทเบิก | Repo ที่ implement | หมายเหตุ |
|---|---|---|
| ค่ารักษาพยาบาล (WdHospitals) — ระบบเดิม | vtrc-api cluster D (withdraw/hospital.js, 5,162 LOC, 13-state machine) | schema vtrc.WDHospitals |
| เงินช่วยเหลือภัยพิบัติ, ค่ารักษาพยาบาลเวอร์ชันใหม่, เงินฌาปนกิจ, มรดกตกทอด, ค่าธรรมเนียมการศึกษา | benefit-api (NestJS, ระบบใหม่) | schema benefit เป็นหลัก แต่เขียนกลับเข้า vtrc.WDHospitals/vtrc.WDHistories ด้วย raw SQL เมื่อ cancel (ดู 14.2) |
| Slip เงินเดือน/หนังสือรับรองเงินเดือน | vtrc-api cluster D (slip/slip.js) | อ่านจาก HRMI ผ่าน bridge |
| เก็บไฟล์แนบประกอบการเบิก | vtrc-common (POST /file/save) — ถูกเรียกจาก benefit-api | vtrc-common/02-core-pipeline |
| ตรวจสิทธิ์เบิกจาก HRMI | benefit-api เรียก centralizeServer/vtrc-api (identity ปลายทางไม่ยืนยัน 100% — ดู 13.2.1) | benefit-api/04-auth-integrations |
| ส่งออกไปบัญชี/จ่ายเงินจริง | benefit-api → SFTP ภายนอก (FMIS) | benefit-api/04-auth-integrations |
ความซับซ้อนที่ไม่เหมือน process อื่น — WdHospitals มีทั้งเวอร์ชันเก่าใน vtrc-api (schema vtrc.WDHospitals) และเวอร์ชันใหม่ใน benefit-api (schema benefit.wdHospitals) พร้อมกัน สองตารางคนละ schema ที่ชื่อคล้ายกันมาก และมีการเขียนข้าม schema เมื่อ cancel — ดูรายละเอียด debt ที่ CORR-BIZ-01 ใน 14.3 Scorecard
14.1.3 · Recruitment pipeline (การสรรหาบุคลากร)
| ขั้นตอน | Repo | หลักฐาน |
|---|---|---|
| หน่วยงานขอเปิดรับ (Job Request) + อนุมัติ | recruitment-api (JobRequestService) | recruitment-api/02-core-pipeline |
| สร้างเนื้อหา + ภาพประกาศรับสมัครด้วย AI | ai-recruitment-api (OpenAI GPT-4o content + DALL-E/gpt-image-1 ภาพ + remove.bg + qrserver.com) | ai-recruitment-api/02-core-pipeline |
| ประกาศรับสมัคร (public) | recruitment-api (jobList module, @Public()) | recruitment-api/02-core-pipeline |
| ผู้สมัครกรอกใบสมัคร (Application Profile) | recruitment-web (React, OTP login + AES-encrypt PII ฝั่ง client) → recruitment-api (CandidateService) | recruitment-web/02-core-pipeline |
| Verify ผู้สมัครที่เป็นพนักงานภายในกับ VTRC | recruitment-api (AppProfileService.verifyUserAndDifferentData()) | recruitment-api/02-core-pipeline |
| ประกาศผลสอบ/สัมภาษณ์ (PDF + email) | recruitment-api (AnnouncementService, puppeteer + nodemailer) | recruitment-api/02-core-pipeline |
| ออกสัญญาจ้าง + map รหัส HRMI | recruitment-api (ContractService เรียก workforce-api ที่ identity ไม่ยืนยัน) | recruitment-api/02-core-pipeline |
| แจ้ง HRMI ให้บันทึกพนักงานใหม่ | recruitment-api → ส่ง email (ไม่ใช่ API call อัตโนมัติ) | recruitment-api/02-core-pipeline |
เจ้าของข้อมูล AI content — ai-recruitment-api และ recruitment-api share database recruitment_ai เดียวกัน (ยืนยัน 100% จาก connection string ทั้งสองฝั่ง — ดู 13.3.4) เป็น process เดียวในทั้ง 5 ที่มี AI generation เป็นส่วนหนึ่งของ pipeline หลัก ไม่ใช่ feature เสริม
14.1.4 · Performance evaluation cycle (การประเมินผลงาน)
pms-api เป็น repo เดียวที่ implement วงจรนี้ทั้งหมด แต่ sync ข้อมูลองค์กร/พนักงานจาก dbWorkforce แบบ cron ทุก 1 นาที (ไม่ใช่ real-time API call):
| ขั้นตอน | Module ใน pms-api | หลักฐาน |
|---|---|---|
| ตั้งรอบประเมิน (period) + ตัวชี้วัดกลาง | PeriodModule, IndicatorType/Indicator/RatingScale/Grading | pms-api/02-core-pipeline |
| Sync ข้อมูลองค์กร/พนักงานจาก workforce กลาง | UsagePermissionService.handleCron (@Cron('*/1 * * * *')) | pms-api/02-core-pipeline |
| สร้างแบบประเมิน + กรอกผล | CreateFormModule, EvaluateFormModule (module ใหญ่สุด 2,996 LOC) | pms-api/02-core-pipeline |
| สายอนุมัติ + delegate | ApproverModule | pms-api/02-core-pipeline |
| ยืนยันผลระดับหน่วยงาน | ConfirmEvaluationModule | pms-api/02-core-pipeline |
| จัดสรรงบ + คำนวณ % ปรับเงินเดือน | BudgetModule → SalaryRange/SalaryPercentage/SalaryAdjust/SalaryAdjustment | pms-api/02-core-pipeline |
| แนะนำหลักสูตรพัฒนาตามผลประเมิน | pms-api → pms-ai-api (โดเมนภายนอก vtrcsupport.com, vector embedding) | pms-api/04-auth-integrations |
| Export ผลปรับเงินเดือนเข้า HRMI | SalaryAdjustToHRMIModule — export เป็นไฟล์ Excel ให้ทีม HR นำเข้าด้วยมือ (ต่างจาก recruitment ที่ export ผ่าน email) | pms-api/02-core-pipeline |
คำอธิบายความเชื่อมั่น — flow นี้อนุมานจากชื่อ module/endpoint เป็นหลัก (ไม่ได้ trace โค้ดทีละบรรทัดเท่ากับ benefit-api/recruitment-api) เพราะขนาด service ใหญ่กว่ามาก ถือเป็น skeleton ระดับ module ไม่ใช่ trace เต็มรูปแบบ — ดู pms-api/02-core-pipeline §หมายเหตุความเชื่อมั่น
14.1.5 · Meeting & attendance (การประชุมและเช็คชื่อ)
| ขั้นตอน | Repo | หลักฐาน |
|---|---|---|
| ตั้งค่ากลุ่มผู้ใช้/ผู้อนุมัติ | meeting-backoffice/meeting-backoffice-new (frontend) → meeting-vtrc-api | meeting-backoffice/03-persistence-integrations |
| สร้างการประชุม + เชิญผู้เข้าร่วม | meeting-vtrc-api (addNewMeeting) | meeting-vtrc-api/02-core-pipeline |
| ยืนยันตัวตนผู้ใช้ (bridge) | meeting-vtrc-api → vtrc-api (fetchEmployeeProfileForOtherService) | meeting-vtrc-api/02-core-pipeline |
| แปลง empCode เป็นชื่อผู้เข้าร่วม | meeting-vtrc-api → cu-central-api (fetchListEmployeeForTwoWay) | meeting-vtrc-api/02-core-pipeline |
| อนุมัติการประชุม | meeting-vtrc-api (approvemeeting) — ไม่มี server-side check ว่าผู้อนุมัติจริง | meeting-vtrc-api/02-core-pipeline |
| ส่งหนังสือเชิญ (PDF+email) | meeting-vtrc-api cron ทุก 15 นาที (ไม่ synchronous) | meeting-vtrc-api/02-core-pipeline |
| ตอบรับ/ปฏิเสธ/มอบหมายตัวแทน | meeting-vtrc-api (acceptancemeeting) | meeting-vtrc-api/02-core-pipeline |
| Push notification สุดท้าย | ฝากส่งผ่าน vtrc-api (sendNotificationFrom3Party) — meeting-vtrc-api ไม่ยิง FCM เอง | meeting-vtrc-api/02-core-pipeline |
| การเช็คชื่อ/attendance จริง (ไม่ใช่การประชุม) | vtrc-api cluster B (timeAttendance/, 9 LOC — stub, ไม่มี business logic จริงที่ตรวจสอบได้ในรอบนี้) | vtrc-api/06-controllers §Cluster B |
ข้อสังเกตสำคัญ — "attendance" ในความหมายเช็คชื่อเข้า-ออกงาน (time attendance) ไม่มี business logic ที่ยืนยันได้ ใน vtrc-api — controller timeAttendance/ มีแค่ 9 บรรทัดเป็น pass-through พร้อม dead import (bcryptjs, jsonwebtoken) ไม่พบระบบเช็คชื่อจริงใน repo อื่นที่สำรวจ — เป็นไปได้ว่าระบบ time attendance จริงอยู่ที่ HRMI ฝั่ง cu-central-api/database ภายนอกที่ไม่อยู่ใน workspace นี้ ทำเครื่องหมาย UNVERIFIED
14.1.6 · Repo ที่มีบทบาทซ้ำในหลาย process
| Repo | Process ที่เกี่ยวข้อง |
|---|---|
vtrc-api | Leave, Welfare (เวอร์ชันเดิม), Meeting (bridge + notification) |
cu-central-api | Leave (HR master), Welfare (สิทธิ์เบิกจาก HRMI ผ่าน vtrc-api bridge), Meeting (employee directory) |
vtrc-common | Welfare (file storage) — ไม่เกี่ยวกับ process อื่น |
ไม่มี repo ใดที่เกี่ยวข้องกับทั้ง 5 process พร้อมกัน — vtrc-api/cu-central-api (legacy core) เป็น hub ร่วมของ 3 จาก 5 process เพราะเป็นเจ้าของ HR master data ต้นทาง