การกำหนดค่า¶
บทบาท¶
บทบาทที่ตั้งค่าไว้ล่วงหน้า 4 บทบาท (ดู เริ่มต้นใช้งาน §2) มาพร้อมค่าเริ่มต้นที่สมเหตุสมผล สองในจำนวนนั้นใช้การจับคู่พาร์ตเนอร์ แบบ นิพจน์ (ประธาน, ผู้ขาย) — โดยจะเติมผู้ลงนามจากเรกคอร์ดแม่ โดยอัตโนมัติ ส่วนอีกสองบทบาท (role_committee_member, role_hospital_signer) ใช้นโยบาย ว่างเปล่า และบริดจ์จะเติม พาร์ตเนอร์อย่างชัดเจนในขั้นตอน "Send for Signature"
การแก้ไขบทบาท¶
Sign → Settings → Roles → เปิดบทบาท → แก้ไข ไฟล์ข้อมูล XML ใช้ noupdate=1 ดังนั้นการแก้ไขของคุณจะคงอยู่ตลอดการอัปเกรดโมดูล
การปรับแต่งทั่วไป:
- เปลี่ยนชื่อป้ายกำกับสองภาษา (เช่น สลับลำดับ EN/TH)
- เพิ่ม
default_partner_idสำหรับrole_vendor_signerเพื่อกำหนดให้ ผู้รับเหมาเฉพาะรายเป็นผู้ลงนามเมื่อใช้เทมเพลตเดโมแบบ bulk
การเพิ่มบทบาทใหม่¶
หากคุณต้องการบทบาทที่ห้า (เช่น "พยาน") ให้เพิ่มผ่าน UI โค้ดของบริดจ์ อ้างอิงเฉพาะบทบาทที่ตั้งค่าไว้ล่วงหน้า 4 บทบาทตาม XML ID เท่านั้น ดังนั้นบทบาทใหม่จะส่งผลเฉพาะกับเวิร์กโฟลว์ bulk "Sign from Template" — ไม่ใช่กระบวนการต่อเรกคอร์ดของการตรวจสอบหรือสัญญา
ผู้มีอำนาจลงนามฝั่งโรงพยาบาล¶
บนฟอร์มสัญญา ฟิลด์ Hospital Authorized Signer (roots_hospital_signer_id) เป็น Many2one ของ res.users ตั้งค่านี้ให้กับ บุคคลที่โรงพยาบาลของคุณซึ่งมีอำนาจลงนาม — มักเป็นหัวหน้าแผนก BME หรือผู้อำนวยการโรงพยาบาล
ฟิลด์นี้ จำเป็นในขณะลงนาม (ไม่ใช่ตอนสร้างสัญญา) คุณสามารถสร้างสัญญา โดยไม่ตั้งค่านี้ได้ แต่ action_send_for_signature จะไม่ทำงานจนกว่าจะ มีการเติมข้อมูล
ความแตกต่างจาก user_id (ผู้รับผิดชอบ):
| ฟิลด์ | วัตถุประสงค์ |
|---|---|
user_id | เจ้าของสัญญาฝั่งโรงพยาบาล — รับการแจ้งเตือนต่ออายุ (Q3.7), เป็นผู้ได้รับมอบหมายเริ่มต้นสำหรับกิจกรรมที่เกี่ยวกับสัญญา |
roots_hospital_signer_id | บุคคลที่มีอำนาจลงนามอิเล็กทรอนิกส์บนสัญญาในนามของโรงพยาบาล |
ผู้ใช้คนเดียวกันสามารถทำหน้าที่ทั้งสองได้ แต่เป็นฟิลด์แยกกันเพื่อให้ เจ้าของสามารถมอบหมายการลงนามให้ผู้ลงนามอาวุโสได้โดยไม่สูญเสียบริบท การจัดการสัญญา
เทมเพลตเดโม¶
เรกคอร์ด sign.oca.template สำเร็จรูป 2 รายการมาพร้อมกับโมดูล (ติดตั้งเมื่อเลือกช่อง Demo data ขณะติดตั้ง):
| เทมเพลต | เชื่อมโยงกับ | ช่องที่วางไว้ล่วงหน้า |
|---|---|---|
sign_oca_template_inspection_demo | hemms.asset.inspection | ลายเซ็นประธาน 1 ช่อง (ลากลายเซ็นกรรมการ 2 ช่องลงบน PDF ด้วยตนเอง) |
sign_oca_template_contract_demo | hemms.service.contract | ลายเซ็น 2 ช่อง (ผู้ขาย + โรงพยาบาล) — เลย์เอาต์เต็มรูปแบบ |
เทมเพลตเหล่านี้ขับเคลื่อนกระบวนการ bulk-action Sign → Templates → Sign from Template เทมเพลตเหล่านี้ "ไม่" ถูกใช้โดยปุ่ม "Send for Signature" แบบต่อเรกคอร์ด บนฟอร์ม (ซึ่งเรนเดอร์ PDF qweb สดทุกครั้ง)
การแทนที่ PDF เดโม¶
PDF เดโมเป็นหน้าว่างทั่วไปที่คัดลอกมาจาก sign_oca/tests/empty.pdf หากต้องการแทนที่ด้วยฟอร์มสไตล์โรงพยาบาล:
- Sign → Templates → เปิดเทมเพลตเดโม
- คลิก Upload PDF → เลือก PDF จริงของคุณ
- คลิก Configure Document → ลาก/วางช่องลายเซ็น, ข้อความ และช่อง เครื่องหมายถูกลงบนหน้าใหม่
- บันทึก
ลิงก์ model_id ของเทมเพลตไปยังโมเดลที่บริดจ์จะคงอยู่ ดังนั้น bulk action "Sign from Template" จะยังคงปรากฏบนเรกคอร์ดการตรวจสอบหรือสัญญาต่อไป
การลงนามแบบต่อเรกคอร์ด vs แบบอิงเทมเพลต¶
ข้อเตือนความจำว่ากระบวนการใดใช้อะไร:
| กระบวนการ | แหล่งของ PDF | เมื่อใดควรใช้ |
|---|---|---|
| Send for Signature (ปุ่มบนฟอร์ม) | การเรนเดอร์ qweb สดของเรกคอร์ดแม่ (รายงานการตรวจสอบ / สรุปสัญญา) | งานประจำวันปกติ — สิ่งที่ผู้ใช้โรงพยาบาลจะทำ 95% ของเวลา |
| Sign from Template (bulk action) | PDF ที่อัปโหลดของเทมเพลต | เมื่อคุณมี PDF ที่เตรียมไว้ภายนอก (เช่น ร่างสัญญาของผู้ขาย) ที่ไม่ตรงกับเวอร์ชันที่เรนเดอร์ด้วย qweb |
ทั้งสองกระบวนการจะลงเอยด้วย sign.oca.request ที่เชื่อมโยงกับเรกคอร์ดแม่ ผ่าน record_ref + hemms_asset_inspection_id / hemms_service_contract_id ดังนั้น hook ของ Q4.5 จึงทำงานสำหรับทั้งสอง และ PDF ที่ลงนามแล้วจะไปอยู่ใน แชตเตอร์ (chatter) ของเรกคอร์ดแม่ในลักษณะเดียวกัน