เวิร์กโฟลว์¶

หน้านี้ครอบคลุมวงจรชีวิตเต็มรูปแบบของรายงาน PM ประจำปีสำหรับ HA, กระบวนการ ลงนามแบบแง่มุมคู่ขนาน และเส้นทางการปฏิเสธ / ย้อนกลับ

วงจรชีวิต 3 สถานะ¶

stateDiagram-v2
    [*] --> draft
    draft --> in_progress: action_start() / wizard generate
    in_progress --> submitted: action_submit() (freezes snapshot)
    submitted --> archived: action_archive_report()
    submitted --> draft: action_reset_to_draft() (manager only)
    in_progress --> draft: action_reset_to_draft() (manager only)
    archived --> [*]

สามสถานะ ไม่ใช่สี่ — ไม่มีสถานะ signed แยกต่างหาก การลงนามถูกบันทึก ด้วยฟิลด์ roots_signed_pdf + ป้าย 🟢 ลงนามครบ ไม่ใช่ด้วยการเปลี่ยน สถานะ (ตรงกับการตัดสินใจแง่มุมคู่ขนานของลายเซ็นอิเล็กทรอนิกส์ Q4)

ความหมายของสถานะ¶

สร้าง → ตรวจสอบ → Submit¶

เส้นทางที่ราบรื่น:

1. วิซาร์ดสร้าง — เลือกหน่วยงาน + ปีงบประมาณ, สร้างรายงานที่ In Progress บรรทัดจะถูกเติมล่วงหน้าด้วยจำนวนตามแผน/ทำจริง; result='pass' ถูกตั้งล่วงหน้าบนบรรทัดที่ปฏิบัติตามแผน 100%
2. ตรวจสอบ — วิศวกรสแกนแท็บ Equipment Lines, เติม result + exception_reason สำหรับบรรทัดที่ต่ำกว่าแผน
3. Submit — คลิก ส่งรายงาน (Submit) ระบบ:
4. สร้างสแน็ปช็อต JSON ที่ไม่เปลี่ยนแปลงซึ่งบรรจุข้อมูลของทุกบรรทัด, ตารางชั้นความเสี่ยงเครื่องมือ (device class) ของ MoPH ฉบับเต็ม ณ ขณะนี้ และลายนิ้วมือ paperformat SHA-256
5. ตั้ง state = submitted, submitted_date = now()
6. โพสต์ข้อความแชตเตอร์ (chatter): 📋 Report submitted by [User] — snapshot #N frozen with M lines.

การ์ดของ Submit¶

การ submit จะปฏิเสธเมื่อ:

• สถานะไม่ใช่ In Progress
• รายงานมีศูนย์บรรทัด (บังคับให้ใช้วิซาร์ดหรือสร้างบรรทัดด้วยมือ)
• บรรทัดใดที่ถูกทำเครื่องหมาย fail / not_done ขาดเหตุผลข้อยกเว้น (ยกโดย @api.constrains บนโมเดลบรรทัด)

ส่งไปลงนาม¶

หลัง submit ส่วนหัวจะได้ปุ่ม 📝 Send for Signature (ปรากฏเฉพาะเมื่อ sign_request_count == 0)

การตรวจสอบก่อนเริ่ม¶

ระบบเรียก _check_ha_signers_resolvable() ก่อน โดยจะปฏิเสธเมื่อช่องผู้ลงนาม ใดในสามช่องว่างเปล่าหรือไม่มีพาร์ตเนอร์เชื่อมโยง พร้อมข้อผิดพลาดที่ ดำเนินการได้ เช่น:

Cannot send for signature: • Engineering Head — not set • Hospital Director (Dr. Smith) — no linked partner; cannot resolve a sign_oca signer

คำขอลงนาม¶

เมื่อการตรวจสอบก่อนเริ่มผ่าน ระบบ:

1. เรนเดอร์ PDF QWeb สด (รับรู้สแน็ปช็อต — อ่านจากสแน็ปช็อตที่ตรึงไว้ เนื่องจาก state == submitted)
2. สร้าง sign.oca.request พร้อมผู้ลงนามสามคน:
3. BME Head — role_bme_head, พาร์ตเนอร์จาก bme_head_id
4. Engineering Head — role_engineering_head, พาร์ตเนอร์จาก engineering_head_id
5. Hospital Director — role_hospital_signer ที่มีอยู่ของ Q4, พาร์ตเนอร์จาก director_id
6. เปิดฟอร์มคำขอเพื่อให้วิศวกรตรวจสอบและคลิก "Send"

UX การลงนาม¶

• ผู้ลงนามภายใน — เห็นไอคอนดินสอใน systray ของตนที่แจ้งเตือนเกี่ยวกับ ลายเซ็นที่รอดำเนินการ คลิก → การลงนามในระบบ
• ผู้ลงนามผ่านพอร์ทัล (โดยทั่วไปสำหรับผู้อำนวยการโรงพยาบาลนอกสถานที่) — ได้รับอีเมลพร้อมลิงก์ลงนามที่เปิดพอร์ทัล ลงนามที่นั่น

เสร็จสมบูรณ์ → PDF ที่ลงนามแล้ว¶

เมื่อผู้ลงนามคนที่สามเสร็จสมบูรณ์ sign_oca จะเปลี่ยนคำขอเป็นสถานะ 2_signed การขยาย super _check_signed ของ Q5.9 จะทำงาน:

1. super()._check_signed() รันเชนของ Q4 (จัดการกรณีการตรวจสอบ + สัญญา)
2. การขยายนี้จับ record_ref._name == 'hemms.ha.report'
3. เรียกตัวช่วย _roots_attach_signed_pdf_to_parent(request, record) ของ Q4 (สืบทอดผ่านเชนการสืบทอด sign.oca.request) — เขียน data (PDF ที่ลงนามแล้วที่รวมเข้าด้วยกัน) ไปยัง roots_signed_pdf + โพสต์ PDF ไปยัง แชตเตอร์ (chatter) เป็นไฟล์แนบ

บนส่วนหัวของรายงาน:

• ป้าย 🟡 รอลงนาม เปลี่ยนเป็น 🟢 ลงนามครบ
• PDF ที่ลงนามแล้วปรากฏในแชตเตอร์ (chatter)
• สถานะยังคงเป็น Submitted — ความหมายแบบแง่มุมคู่ขนาน

การปฏิเสธ + การลงนามใหม่¶

sign_oca 18.0 ไม่มีการปฏิเสธในกระบวนการ (อยู่ในโรดแมปต้นน้ำ) จนกว่าจะถึง ตอนนั้น การปฏิเสธที่ขับเคลื่อนโดยผู้ปฏิบัติงาน คือเส้นทาง:

1. ผู้จัดการเปิดรายงาน
2. ล้าง PDF ที่ลงนามแล้ว — ไม่ว่าจะผ่าน smart button บน sign.oca.request เอง (active = False) หรือโดยตรง:

report.sudo().write({
    "roots_signed_pdf": False,
    "roots_signed_pdf_filename": False,
})
old_request.active = False

ไม่มีขีดจำกัดรอบ — รายงานสามารถถูกปฏิเสธและส่งใหม่ได้ไม่จำกัด (ตรงกับ รูปแบบ Q3 + Q4) คำขอก่อนหน้าทั้งหมดยังคงอยู่ในประวัติ (active=False) สำหรับการตรวจสอบ

Reset to Draft (เฉพาะผู้จัดการ)¶

เมื่อต้องการการเปลี่ยนแปลงที่เป็นพื้นฐานกว่า (พิมพ์ผิดในบรรทัด, เหตุผล ข้อยกเว้นผิด, เหตุการณ์ PM ที่มาถึงล่าช้า) เฉพาะ Reset to Draft เท่านั้น ที่ปลดล็อกรายงาน:

1. ผู้จัดการคลิก คืนสู่ Draft (Reset) ในส่วนหัว (ปรากฏเฉพาะกับ maintenance.group_equipment_manager)
2. ระบบ:
3. ลบเรกคอร์ดสแน็ปช็อตที่เชื่อมโยง
4. ตั้ง state = draft, submitted_date = False, snapshot_id = False
5. โพสต์ข้อความแชตเตอร์ (chatter): ♻️ Reset to draft by [User] — snapshot cleared.
6. บรรทัดกลับมาแก้ไขได้อีกครั้ง
7. ในการ Submit ครั้งถัดไป สแน็ปช็อตใหม่จะถูกสร้างจากข้อมูลปัจจุบัน

ผลกระทบต่อการลงนาม หากมีการเก็บลายเซ็นแล้ว การ reset เป็น draft จะ "ไม่" ปฏิเสธคำขอลงนามที่มีอยู่โดยอัตโนมัติ — คุณควร archive (active = False) sign.oca.request ด้วยตนเองก่อน reset มิฉะนั้นแชตเตอร์ (chatter) อาจลงเอยด้วย PDF ที่ลงนามแล้วสองฉบับจากสแน็ปช็อตที่ต่างกัน

Archive¶

เมื่อปีงบประมาณถัดไปมาถึง ให้ archive รายงานของปีก่อนหน้า:

1. คลิก จัดเก็บ (Archive) บนรายงานที่ submit แล้ว
2. สถานะเปลี่ยน Submitted → Archived
3. ส่วนหัวจะได้ web_ribbon "Archived" เป็นสัญญาณภาพ
4. รายงานยังคงอ่านและพิมพ์ได้เต็มที่ — เพียงแค่ล็อกถาวร

Archive เป็น เชิงการจัดระเบียบล้วน ๆ — ไม่ลบหรือเปลี่ยนแปลงข้อมูล การ พิมพ์ซ้ำของผู้ตรวจประเมินทำงานได้ดีกับรายงานที่ archive แล้วเช่นเดียวกับ รายงานที่ submit แล้ว (ทั้งสองเรนเดอร์จากสแน็ปช็อต)

ขั้นตอนถัดไป¶

• การออกรายงาน — กายวิภาคของ PDF + การรับประกันการพิมพ์ซ้ำ
• การกำหนดค่า — การตั้งค่าระดับความเสี่ยง