S5 — ระบบบริหารจัดการและเบิกจ่ายค่าตอบแทนทนายความ (มาตรา 134/1)¶

สถานะการพัฒนาล่าสุด (% ความคืบหน้า / เฟสที่ทำไปแล้ว / ของที่ค้าง): ดู แผนงาน เฟส และความคืบหน้า

Lawyer Compensation System (Section 134/1)¶

ตารางสรุปข้อมูลเบื้องต้น¶

หัวข้อ	รายละเอียด
อ้างอิง TOR	ข้อ 7.15
หน่วยงานรับผิดชอบ	กองพิทักษ์สิทธิและเสรีภาพ (กพส.)
ลักษณะการพัฒนา	ระบบปรับปรุงและเพิ่มประสิทธิภาพ (Improvement & Maintenance)
สถานะโครงการ	ปรับปรุงระบบเดิม (Existing System) — ระบบมีอยู่ก่อน Phase 1 และไม่ได้อยู่ในขอบเขต TOR Phase 1 เป็นระบบเดิมที่นำมาปรับปรุงใหม่ใน Phase 2
ระดับความซับซ้อน	ระดับมาตรฐาน (🟡 Standard)
ฟังก์ชันหลัก	ลงทะเบียนทนายความ, มอบหมายคดี, และประมวลผลการเบิกจ่ายค่าตอบแทน
สถานะการดำเนินงาน	ขั้นตอนการวางแผนและการปรับปรุง (Planning & Improvement Phase)

เครื่องแม่ข่าย (Server / Host)¶

รายการ	รายละเอียด
Front (Proxy)	10.136.27.248 — nginx (`rlpd-webserver`, Ubuntu 18.04) · โดเมน `ia.rlpd.go.th`
Backend (App)	10.136.27.38:8080 — Windows · Apache/2.4.33 (Win32) · PHP CodeIgniter
การเข้าถึง	proxy `.248`: SSH `sysadmin1` · backend `.38`: RDP (คาดว่าใช้ `.\Admin-it`) — cred ใน Obsidian Vault `RLPD/credentials/`
DB	⚠️ ยังต้องยืนยัน — KB เดิมระบุ `10.136.27.43` (SQL 2017) · `conn.php` ใน repo ระบุ `10.148.0.10 / 134_dba` (ทั้ง `.248` และ `.38` ไม่เปิด 1433 — DB อยู่เครื่องอื่น)

ยืนยันด้วย probe จริง (read-only, 2026-07-11) — สถาปัตยกรรม S5:
ผู้ใช้ → ia.rlpd.go.th → [nginx .248 :443] → proxy_pass http://10.136.27.38:8080
                                               → Apache/2.4.33 (Win32) + PHP CodeIgniter (คุกกี้ CI_Sessions)
- แก้ stack ที่ขัดแย้งแล้ว: SYSTEM_OVERVIEW.md เขียน .NET Framework — ผิด. หลักฐาน (คุกกี้ CI_Sessions + login /th/application/login) ยืนยันว่าเป็น PHP CodeIgniter ตรงกับ source ใน repo → ยึด repo - .248 เป็น reverse proxy กลางของ RLPD (front ~35 โดเมน ไม่ใช่แค่ S5) — เดิม KB เข้าใจผิดว่าเป็น Windows/IIS เฉพาะ S5. ดู server_inventory.md - .\Admin-it (RDP/Windows) ที่ได้ตอนแรก น่าจะเป็น cred ของ backend .38 (Windows/Apache) — สอดคล้องกับที่เป็น Windows-style account (รอทดสอบ RDP ยืนยัน)

สถานะปัจจุบัน (Current State)¶

ระบบ S5 มีวัตถุประสงค์หลักในการบริหารจัดการรายชื่อทนายความอาสา (Pro bono lawyers) การมอบหมายทนายความให้แก่ผู้ต้องหาในคดีอาญาตามมาตรา 134/1 และกระบวนการเบิกจ่ายค่าตอบแทนให้แก่ทนายความ

สภาพปัญหาในปัจจุบัน: - ระบบขาดการปรับปรุงและบำรุงรักษาอย่างต่อเนื่อง (Legacy System) - พบปัญหาความผิดพลาดในกระบวนการเบิกจ่ายและการตรวจสอบสถานะ - กระบวนการตรวจสอบคุณสมบัติทนายความยังเป็นแบบกึ่งอัตโนมัติ (Manual/Batch Process)

ขอบเขตความต้องการตาม TOR¶

ตามรายละเอียดในข้อกำหนด TOR ข้อ 7.15 การปรับปรุงระบบเบิกจ่ายค่าตอบแทนทนายความต้องครอบคลุมดังนี้: - พัฒนาและปรับปรุงระบบให้สอดคล้องกับระเบียบกฎหมายมาตรา 134/1 - เพิ่มประสิทธิภาพระบบลงทะเบียนทนายความและการจัดกลุ่ม (Lawyer Pool) - ปรับปรุงขั้นตอนการมอบหมายทนายความ (Lawyer Assignment) ให้มีความโปร่งใสและตรวจสอบได้ - แก้ไขปัญหาและพัฒนาระบบเบิกจ่ายค่าตอบแทน (Compensation Processing) ให้มีความถูกต้องแม่นยำ - รองรับการเชื่อมต่อข้อมูลกับระบบที่เกี่ยวข้องในกลุ่มงานเดียวกัน (เช่น S1)

ปัญหาสำคัญที่ตรวจพบ (Identified Issues)¶

การบันทึกการเบิกจ่ายซ้ำซ้อน (Duplicate Payment Records):
พบรายการเบิกจ่ายซ้ำในระบบ ส่งผลให้เกิดความคลาดเคลื่อนทางการเงินและบัญชี
สาเหตุอาจเกิดจากขาดการตรวจสอบความซ้ำซ้อน (Uniqueness Constraints) ในระดับฐานข้อมูลหรือแอปพลิเคชัน
การตรวจสอบใบอนุญาตทนายความ (License Verification):
ปัจจุบันใช้วิธีนำเข้าข้อมูลจากไฟล์ Excel (Batch Import) เป็นรอบๆ ทำให้ข้อมูลไม่เป็นปัจจุบัน (Not Real-time)
กระบวนการ Import ด้วยมือมีความเสี่ยงต่อความผิดพลาดของข้อมูล
หนี้ทางเทคนิคสะสม (Technical Debt):
ระบบขาดการอัปเดตซอฟต์แวร์และโครงสร้างโค้ดมาเป็นเวลานาน
ขาดเอกสารประกอบระบบ (System Documentation) ที่เป็นปัจจุบัน ทำให้ยากต่อการบำรุงรักษา
ระบบการตรวจสอบ (Audit Trail):
การบันทึกประวัติการทำรายการ (Transaction Logs) ยังไม่ละเอียดเพียงพอสำหรับการตรวจสอบย้อนหลังในกรณีที่เกิดปัญหาทางการเงิน

ขั้นตอนการทำงาน (Workflow)¶

1. การลงทะเบียนและตรวจสอบคุณสมบัติ¶

graph TD
    A[ทนายความยื่นขอลงทะเบียน] --> B[นำเข้าข้อมูลใบอนุญาตจากหน่วยงานภายนอก]
    B --> C[ตรวจสอบและอนุมัติคุณสมบัติ]
    C --> D[เพิ่มรายชื่อเข้าสู่ระบบ Lawyer Pool]

2. การมอบหมายคดีและการเบิกจ่าย¶

graph TD
    A[รับคำขอทนายความจากระบบ S1 / ภายนอก] --> B[ระบบจับคู่ทนายความตามความเหมาะสม]
    B --> C[ยืนยันการมอบหมายคดี]
    C --> D[ทนายความบันทึกผลงานและขอเบิกจ่าย]
    D --> E[ตรวจสอบความถูกต้องและอนุมัติจ่ายเงิน]
    E --> F[บันทึกรายการบัญชีและออกรายงาน]

แผนภาพระบบ (Interactive Diagrams)¶

แผนภาพเชิงโต้ตอบของระบบ S5 Lawyer Compensation 134/1: รองรับการซูม/เลื่อน สลับโหมดมืด–สว่าง ค้นหา component และ export เป็นรูปภาพได้จากในหน้าแผนภาพ (แนะนำให้เปิดแบบเต็มจอ)

สถาปัตยกรรมระบบ (System Architecture)¶

เปิดแบบเต็มจอ — Architecture

ลำดับการทำงานหลัก (Main Sequence)¶

เปิดแบบเต็มจอ — Sequence

จุดเชื่อมต่อระบบ (System Integration)¶

แหล่งข้อมูล / ระบบที่เกี่ยวข้อง	ชื่อระบบ	ทิศทาง	ประเภทข้อมูล	หมายเหตุ
ระบบให้คำปรึกษาฯ	S1 Legal Consultation	สองทาง (Bidirectional)	ข้อมูลการมอบหมายงาน	รับคำขอจาก S1 เพื่อจัดหาทนายความและส่งคืนข้อมูลการเบิกจ่าย
หน่วยงานทนายความ	External Agencies	ขาเข้า (Inbound)	ข้อมูลใบอนุญาต	รับไฟล์ Excel รายชื่อทนายความ (มีแผนปรับเป็น API ในอนาคต)
ระบบบัญชีและการเงิน	Internal Finance System	ขาออก (Outbound)	รายการเบิกจ่าย	ส่งข้อมูลการอนุมัติจ่ายเงินเพื่อดำเนินการโอนเงิน

ประเด็นที่ต้องการคำชี้แจง (Open Issues)¶

[ประเด็นเปิด] แหล่งข้อมูลใบอนุญาตทนายความ (Lawyer License) มาจากหน่วยงานใด และสามารถเปลี่ยนจากการส่งไฟล์ Excel เป็นการเชื่อมต่อผ่าน API ได้หรือไม่?

[ประเด็นเปิด] สาเหตุเชิงลึกของปัญหาการจ่ายเงินซ้ำซ้อน (Duplicate Payment) เกิดจากจุดใด? (เช่น การกดยืนยันซ้ำที่หน้าจอ, ระบบ Validation หลังบ้านขัดข้อง, หรือข้อมูลในฐานข้อมูลไม่มี Unique Key)

[ประเด็นเปิด] ปริมาณทนายความในระบบปัจจุบันมีจำนวนเท่าใด และมีปริมาณธุรกรรมการเบิกจ่ายต่อเดือนมากน้อยเพียงใด?

[ประเด็นเปิด] กระบวนการตรวจสอบยอดเงิน (Reconciliation) ระหว่างระบบ S5 กับฝ่ายการเงินในปัจจุบันทำอย่างไร?

[ประเด็นเปิด] มีข้อกำหนด SLA ในการอนุมัติการเบิกจ่ายค่าตอบแทนทนายความหรือไม่?

หมายเหตุทางเทคนิค (Technical Notes)¶

แนวทางการปรับปรุงในระยะที่ 2 (Phase 2 Improvements)¶

การแก้ไขปัญหาเบิกจ่ายซ้ำซ้อน:
ตรวจสอบและเพิ่มข้อกำหนดความไม่ซ้ำกัน (Uniqueness Constraints) ในระดับฐานข้อมูล เช่น lawyer_id + case_id + period
พัฒนากลไกป้องกันการส่งข้อมูลซ้ำ (Idempotency Key) ในระดับแอปพลิเคชัน
จัดทำรายงานตรวจสอบความซ้ำซ้อน (Deduplication Report) เพื่อทำความสะอาดข้อมูลเดิม
การเพิ่มประสิทธิภาพการตรวจสอบใบอนุญาต:
พัฒนาโมดูลนำเข้าข้อมูลอัตโนมัติ (Automated Import) พร้อมระบบตรวจสอบความถูกต้อง (Validation Rules)
เพิ่มระบบแจ้งเตือนเมื่อใบอนุญาตทนายความใกล้หมดอายุ
การเสริมความปลอดภัยและการตรวจสอบ (Audit & Security):
เพิ่มระบบ Audit Trail แบบละเอียด (ใคร, ทำอะไร, เมื่อไหร่, ข้อมูลก่อน-หลังเปลี่ยน) สำหรับทุกรายการเบิกจ่าย
กำหนดสิทธิ์การเข้าถึง (Role-based Access Control) แยกตามหน้าที่อย่างชัดเจน เช่น ผู้บันทึก, ผู้อนุมัติ, ผู้จ่ายเงิน
การบำรุงรักษาและปรับปรุงโครงสร้าง (System Maintenance):
ทำการ Refactor โค้ดในส่วนที่มีหนี้ทางเทคนิคสูง
ปรับปรุงโครงสร้างฐานข้อมูล (Database Schema) ให้มีความเป็นระเบียบ (Normalized)
จัดทำคู่มือการทำงาน (Technical Documentation) และ API Specification