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

หน้านี้เดินผ่าน ห้าสถานการณ์ที่เป็นรูปธรรม ซึ่งครอบคลุมประมาณ 95% ของวิธีที่ แผนก BME ของไทยใช้ขั้นตอนการซ่อมในแต่ละวัน

สถานการณ์ที่ 1 — การซ่อมเชิงแก้ไข (ขั้นตอนตามแบบฉบับ)¶

พยาบาลหอผู้ป่วยแจ้งว่าเครื่องให้สารน้ำเสีย ตั๋วเริ่มที่ Submitted และเดิน ตามเส้นทางห้าขั้นมาตรฐาน:

sequenceDiagram
    participant W as Ward staff
    participant M as BME Manager
    participant T as BME Technician
    participant S as BME Mgr (sign-off)

    W->>+M: Submit ticket [Submitted, SLA 4h]
    M->>M: Triage, assign tech [Pending Review, SLA 8h]
    M->>+T: Assign
    T->>T: Diagnose + repair [In Repair, SLA 24h]
    T->>-S: Repair done
    S->>S: Verify + sign off [Awaiting Pickup, SLA 8h]
    S-->>W: Notify ready for pickup
    W->>W: Collect equipment [Received - DONE]

ระยะเวลาทั่วไป (ทีม BME ที่บริหารดี):

คำขอที่เกินกำหนดในขั้นใดก็ตามจะพลิกแบนเนอร์สีแดงบนฟอร์ม การตกแต่งแถวสีแดงบน รายการ และป้าย SLA สีแดงบนการ์ดคัมบัง ป้ายจะหายไปทันทีที่ขั้นเลื่อนไป เพราะตัวจับเวลารีเซ็ตในทุกการเปลี่ยนผ่าน

สถานการณ์ที่ 2 — คำขอที่สร้างจาก PM¶

cron ของ OCA maintenance_plan ทำงานทุกวันเวลา 04:00 และสร้าง maintenance.request สำหรับเครื่องมือแพทย์ทุกชิ้นที่แผนถึงวันครบกำหนดถัดไป ด้วย roots_hemms_pm คำขอเหล่านั้นจะมาอยู่ใน PM Scheduled แทนที่จะเป็น Submitted:

stateDiagram-v2
    direction LR
    [*] --> PM_Scheduled: maintenance_plan cron
    PM_Scheduled --> Pending_Review: Tech acknowledges
    Pending_Review --> In_Repair: Tech starts PM work
    In_Repair --> Awaiting_Pickup: PM complete
    Awaiting_Pickup --> Received: Equipment back in service
    Received --> [*]

    PM_Scheduled: PM Scheduled\n(SLA 72h — 3 days)

ขั้นตอนเหมือนกันตั้งแต่ Pending Review เป็นต้นไป — ความแตกต่างเดียวคือ จุดเข้า SLA 72 ชั่วโมงบน PM Scheduled ให้เวลาทีม BME 3 วันทำงานในการยอมรับ งาน PM ก่อนที่จะปรากฏบนแดชบอร์ดการเกินกำหนด

ดู การบำรุงรักษาเชิงป้องกัน → ขั้นตอนการทำงาน สำหรับวงจรชีวิต PM ฉบับเต็มรวมถึงการเลือกประเภทและการตั้งค่าแผน

สถานการณ์ที่ 3 — ค้างที่ Pending Review¶

ตั๋วค้างอยู่ใน รอตรวจสอบ (Pending Review) มาสองวัน ป้าย SLA เป็นสีแดงมา 40 ชั่วโมงแล้ว

วิธีหามัน¶

ตัวกรองสองตัวแสดงสิ่งนี้ทันที:

• Maintenance → Maintenance → แถบค้นหา → Filters → SLA Breached → สลับรายการ/คัมบังให้แสดงเฉพาะการ์ดที่เกินกำหนด
• Group By → Stage แล้วนับการ์ดใน Pending Review

การตกแต่งแถวสีแดงในมุมมองรายการเป็นการกวาดสายตาที่เร็วที่สุด

สิ่งที่ต้องทำ¶

ขั้นตอนการทำงานเองไม่ได้ยกระดับโดยอัตโนมัติ — มันแสดงการเกินกำหนดและรอคน โปรโตคอลของคนที่แนะนำ:

1. ผู้จัดการ BME เปิดตั๋ว อ่าน chatter เพื่อหาบริบท
2. มอบหมายช่าง (เขียน Responsible = ช่าง) แล้วเลื่อนไปยัง In Repair — การเลื่อนเองคือสัญญาณ "ฉันจัดการแล้ว"; หรือ
3. หากคำขอถูกจำแนกผิด แก้ไข Kind / คำอธิบาย แล้วเด้งกลับไป Submitted พร้อมโน้ต chatter (การเลื่อนถอยหลังถูกบันทึก) หรือไปข้างหน้าสู่ In Repair
4. บันทึกการตรวจสอบจับการเลื่อนไม่ว่ากรณีใด

สถานการณ์ที่ 4 — คำขอที่ยกเลิก / ละทิ้ง¶

โมดูลขั้นตอนการทำงาน ไม่ได้ ให้ขั้น Cancelled มา โมเดล maintenance.request เริ่มต้นของ Odoo มีการกระทำ archive (ผ่าน active=False) ที่ซ่อนคำขอจากคัมบัง และนั่นเป็นสิ่งที่เราแนะนำให้ใช้

รูปแบบที่แนะนำ¶

1. ผู้จัดการเปิดคำขอ
2. เมนู Action → Archive — คำขอหายไปจากมุมมองที่ใช้งานแต่คงอยู่ใน บันทึกการตรวจสอบ
3. ขั้นปัจจุบัน (ไม่ว่าจะเป็นขั้นใด) ถูกเก็บรักษาไว้

บันทึกการตรวจสอบเก็บทุกการเปลี่ยนผ่านจนถึงช่วงเวลาที่เก็บถาวร ดังนั้นผู้ตรวจ ประเมินที่ถามว่า "ทำไมตั๋วนี้ถูกยกเลิก?" สามารถอ่าน chatter เพื่อหาคำอธิบาย และอ่านบันทึกเพื่อหาเวลา

หากคุณจำเป็นต้องมีขั้น Cancelled จริง ๆ¶

โรงพยาบาลที่ต้องการคอลัมน์ Cancelled ที่มองเห็นได้สามารถเพิ่มขั้นแบบกำหนดเอง (ดู การตั้งค่า):

• ชื่อ: ยกเลิก (Cancelled)
• ลำดับ: 90 (หลัง Received)
• Fold: True
• Done: True (เพื่อให้คำขอถือว่าปิดแล้ว)
• Is Done Stage: True
• SLA Hours: 0

จากนั้นเลื่อนตั๋วที่ยกเลิกไปที่นั่นด้วยตนเอง บันทึกการตรวจสอบจะแสดงการเลื่อน และผู้ตรวจประเมินจะเห็นการยกเลิกอย่างชัดเจน

สถานการณ์ที่ 5 — คำขอที่จัดการโดยผู้ขาย (ภายใต้การรับประกัน / MA)¶

เมื่อคำขอเปิดบนเครื่องมือแพทย์ที่อยู่ภายใต้สัญญาบริการที่ใช้งานอยู่ แบนเนอร์ความคุ้มครอง เหนือหัวข้อ (เพิ่มโดย roots_hemms_service_contracts) จะระบุชัดว่าใครเป็นผู้จ่าย ขั้นตอนการทำงานเอง ไม่เปลี่ยน — ทีม BME ยังคงเดินผ่านห้าขั้นเดิม — แต่ขั้น In Repair ดำเนินการโดย วิศวกรภาคสนามของผู้ขายแทนที่จะเป็นในองค์กร

sequenceDiagram
    participant W as Ward staff
    participant M as BME Manager
    participant V as Vendor (e.g., GE)
    participant S as BME Mgr (sign-off)

    W->>M: Submit ticket
    M->>M: Triage [Pending Review]
    Note over M: Coverage banner:<br/>✓ Covered by SC/2026/00003<br/>vendor pays
    M->>+V: Open ticket with vendor (out-of-band)
    V->>V: Field service [In Repair]
    V->>-S: Equipment fixed
    S->>S: Sign off [Awaiting Pickup]
    S->>W: Ready for pickup [Received]

จุดประสานงานสองจุด:

• In Repair เป็นขั้นที่จับคู่กับเวลาบริการภาคสนามของผู้ขาย — การมอบหมาย ช่างอาจเป็นผู้ใช้เทียม "Vendor" หรือปล่อยฟิลด์ว่างไว้และใช้ chatter สำหรับ โน้ตการติดต่อผู้ขาย
• Awaiting Pickup คือเมื่อผู้จัดการ BME ได้ลงนามรับรองรายงานการซ่อมของ ผู้ขาย (ลายเซ็นของผู้ขายเป็นสิ่งที่ควบคุม — ขั้นในขั้นตอนการทำงานเป็นเงา ในระบบของมัน)

ดู สัญญาบริการ → ขั้นตอนการทำงาน สำหรับเมทริกซ์ความคุ้มครองและวิธีที่ roots_is_billable_to_hospital ถูกตั้งค่า บนคำขอ

สถานการณ์ที่ 6 — การเปลี่ยนผ่านแบบกลุ่ม¶

โมดูลขั้นตอนการทำงานไม่ได้ให้การกระทำแบบกลุ่มที่กำหนดเองมา แต่สองรูปแบบ ใช้งานได้ในปัจจุบัน

การเลือกลากในคัมบัง¶

ในคัมบังงานซ่อมบำรุง เลือกการ์ดหลายใบ (คลิกและ Ctrl/Cmd + คลิก) ลากกลุ่มที่ เลือกไปยังคอลัมน์อื่น การเขียนเป็นชุดมาตรฐานของ Odoo มีผล — การ override _write ของ workflow รันหนึ่งครั้งต่อระเบียนในธุรกรรมเดียวกัน ดังนั้นทุกการ เลื่อนจึงถูกบันทึก

การกระทำเซิร์ฟเวอร์ในมุมมองรายการ¶

สำหรับชุดที่ใหญ่กว่า (50+ ระเบียน):

1. สลับไปยังมุมมองรายการ
2. ติ๊กแถวที่คุณต้องการเลื่อน
3. Action → "Update Stage" (การแก้ไขแบบกลุ่มในตัวของ Odoo บน stage_id)
4. เลือกขั้นปลายทาง; คลิก Apply

สิ่งนี้กระตุ้นการเรียก ORM write() ครั้งเดียวด้วย vals = {"stage_id": X} บนทั้ง recordset การ override ของ workflow วนซ้ำ recordset เพื่อคำนวณ time_in_previous_stage_hours ต่อระเบียน จากนั้นสร้างแถวบันทึกการตรวจสอบ แบบกลุ่มในการเรียก create() ครั้งเดียว ประสิทธิภาพขยายเชิงเส้นตามขนาดชุด เราทดสอบถึง 500 ระเบียนในการเลื่อนครั้งเดียวโดยไม่มีปัญหา

รูปแบบที่ไม่พึงประสงค์: การข้ามบันทึกการตรวจสอบผ่าน sudo()¶

หากคุณเขียนการกระทำเซิร์ฟเวอร์แบบกำหนดเองที่ทำ:

request.sudo().write({"stage_id": some_id})

แถวบันทึกการตรวจสอบยังคงถูกสร้าง — การ override write() รันไม่ว่าจะ sudo หรือไม่ อย่า พยายามข้ามมัน ข้อความ chatter ก็ถูกบันทึกด้วย (พร้อม subtype mail.mt_note) หากคุณต้องการการเลื่อนที่เงียบสนิทจริง ๆ (อย่าทำ) คุณต้อง disable_logging อย่างชัดเจน — ซึ่งเราไม่ได้นำมาใช้และจะไม่ทำ

หน้าที่เกี่ยวข้อง¶

• การตั้งค่า — การปรับ SLA ขั้นแบบกำหนดเอง
• การรายงาน — หลักฐานต่อผู้ตรวจประเมิน + KPI
• การบำรุงรักษาเชิงป้องกัน → ขั้นตอนการทำงาน — รายละเอียดวงจรชีวิต PM
• สัญญาบริการ → ขั้นตอนการทำงาน — เมทริกซ์ความคุ้มครอง