ข้ามไปที่เนื้อหา

สัญญาบริการ

โมดูล สัญญาบริการ (roots_hemms_service_contracts) ช่วยให้ทีม BME บันทึกการรับประกัน สัญญาบำรุงรักษา (MA) และข้อตกลงกับผู้ขายทุกฉบับไว้ในที่เดียว จากนั้นเชื่อมโยงสัญญาที่ใช้งานอยู่กับคำขอซ่อมแก้ไขใหม่ทุกรายการโดยอัตโนมัติ เพื่อให้ ช่างเทคนิคทราบ — ในขณะที่เปิดใบงาน — ว่าผู้ขาย จะรับผิดชอบงานหรือโรงพยาบาลต้องชำระ

คุณสมบัติหลัก

1. หนึ่งเรกคอร์ดต่อหนึ่งข้อตกลงกับผู้ขาย

สัญญาแต่ละฉบับเป็น hemms.service.contract พร้อมเลขอ้างอิงต่อเนื่อง (SC/2026/00001) ที่ครอบคลุมเครื่องมือแพทย์หนึ่งหรือหลายรายการ ผู้ขายหนึ่งราย ประเภท สัญญาหนึ่งประเภท (Warranty / Extended Warranty / MA / Spare-only / Labor-only) วันที่เริ่ม และวันที่สิ้นสุด และระดับ SLA เสริม

2. ขอบเขตความครอบคลุมต่อประเภท

ภายในสัญญาทุกฉบับ แท็บ Coverage ให้คุณทำเครื่องหมายแต่ละ maintenance.kind ว่า Included (อยู่ในขอบเขต) และ Billable to Hospital (อะไหล่เรียกเก็บแยกแม้ในงานที่ครอบคลุม) Q3.5 อ่าน บูลีนสองตัวนี้เพื่อตั้ง roots_is_billable_to_hospital บนคำขอใหม่ทุกรายการ

3. เชื่อมโยงสัญญาที่ใช้งานอยู่กับ maintenance.request โดยอัตโนมัติ

เมื่อช่างเทคนิคเปิดคำขอซ่อมแก้ไขบนเครื่องมือแพทย์ที่อยู่ในความครอบคลุม ฟอร์มจะกรอก roots_service_contract_id โดยอัตโนมัติด้วยสัญญาที่ใช้งานอยู่ ล่าสุดของเครื่องมือแพทย์ — และแบนเนอร์ความครอบคลุมเหนือชื่อจะระบุ ผลที่ตามมาอย่างชัดเจน:

  • ✅ ครอบคลุมโดย SC/2026/00003 (GE Healthcare) — ผู้ขายชำระ
  • ✅ ครอบคลุมโดย SC/2026/00003 (GE Healthcare) — โรงพยาบาลต้องชำระ
  • ⚠ ครอบคลุมโดย SC/2026/00003 แต่ประเภทไม่อยู่ในความครอบคลุม — โรงพยาบาลชำระ
  • ⚠ อยู่นอกสัญญา — โรงพยาบาลชำระ

ช่างเทคนิคสามารถแทนที่สัญญาที่เลือกด้วยตนเองได้; การคำนวณ จะไม่เขียนทับการแทนที่นั้นในการแก้ไขครั้งต่อไป

4. การแจ้งเตือนการต่ออายุก่อนหมดอายุ

งานตามเวลา (cron) รายวันจะเลื่อนสถานะสัญญา draft → active → expired ตาม วันที่ จากนั้นสร้าง mail.activity บนผู้ใช้ Responsible สำหรับ สัญญาที่ใช้งานอยู่ใด ๆ ที่วันที่สิ้นสุดอยู่ภายใน roots_renewal_alert_days (ค่าเริ่มต้น 60) ค่าเริ่มต้นแบบเกณฑ์เดียว ตรงกับแผน D7 — แบบหลายระยะ (90/60/30/7) อยู่ในแผนงาน Q4

5. การแสดงระดับ SLA

สัญญาทุกฉบับมี roots_sla_tier (bronze / silver / gold / platinum) บวกกับ roots_sla_response_hours แบบอิสระ Q3 แสดง สิ่งเหล่านี้บนมุมมองฟอร์มและรายการ; การตรวจจับการละเมิด SLA เปรียบเทียบ request.create_date กับ first_response_date และเป็น hook สำหรับ สกอร์การ์ดผู้ขายของ Q4

6. สองภาษาทุกที่

ชื่อสัญญา ประเภทสัญญา และการค้นหาทั้งหมดรองรับ roots_name_th เพื่อให้ผู้ใช้ภาษาไทยสามารถค้นหาสัญญาด้วยป้ายชื่อ ภาษาไทยได้

7. การเจาะลึกด้วยปุ่มสถิติสามแบบ

  • ฟอร์มผู้ขาย (partner) → "X Service Contracts"
  • ฟอร์มเครื่องมือแพทย์ → "X Contracts" + ป้าย Under Warranty ในส่วนหัว
  • ฟอร์มสัญญา → ปุ่มสถิติ "Equipment" + "Requests"

สถาปัตยกรรมโมดูล

Layer 3 — roots_hemms_service_contracts (this module)
  ↓
Layer 2 — maintenance_partner (OCA)            ← vendor link on equipment
Layer 2 — roots_hemms_pm                       ← maintenance.kind vocabulary
Layer 2 — roots_hemms_asset_master             ← equipment master with brand/model
  ↓
Layer 1 — maintenance + mail (Odoo base)

การไม่พึ่งพาโดยตั้งใจ: เรา ไม่ vendor OCA maintenance_equipment_contract โมดูลนั้นมีเพียง ~25 บรรทัดบน OCA contract (การออกใบแจ้งหนี้แบบประจำ) ซึ่งพึ่งพา account — โรงพยาบาลติดตามความครอบคลุมการรับประกัน/MA และระดับ SLA ไม่ใช่ใบแจ้งหนี้ แบบประจำ โมเดล Layer 3 ที่กระชับสะท้อนรูปแบบฟิลด์ m2m equipment ↔ contract โดยไม่มีภาระเรื่องการออกใบแจ้งหนี้ ดูแผน §2 (D1) สำหรับ เหตุผลและเงื่อนไขการทบทวน

ไปที่ใดต่อ