การตั้งค่าหลายบริษัท / หลายโรงพยาบาล¶

HEMMS สืบทอดคุณสมบัติหลายบริษัทของ Odoo มา ดังนั้นคุณจึงมีสองวิธีที่ชัดเจน ในการให้บริการกลุ่มโรงพยาบาล:

1. หนึ่งบริษัทต่อโรงพยาบาล หนึ่งฐานข้อมูลที่ใช้ร่วมกัน — โหมดหลายบริษัทของ Odoo โดยใช้ record rule แบ่งเครื่องมือแพทย์ตาม company_id
2. หนึ่งฐานข้อมูลต่อโรงพยาบาล — การติดตั้งที่เป็นอิสระ หนึ่ง Compose stack ต่อโรงพยาบาล

ตัวเลือกที่เหมาะสมขึ้นอยู่กับว่าโรงพยาบาลเหล่านั้นใช้บุคลากร ข้อมูลหลัก และขอบเขตการรายงานร่วมกัน หรือดำเนินงานอย่างเป็นอิสระ หน้านี้จะวางรายละเอียด ข้อแลกเปลี่ยนและขั้นตอนการตั้งค่าเชิงปฏิบัติสำหรับตัวเลือกที่ 1

รูปแบบใดเหมาะกับลูกค้าแบบใด¶

รูปแบบที่ 1 — หนึ่งบริษัทต่อโรงพยาบาล หนึ่งฐานข้อมูล¶

นี่คือรูปแบบหลายบริษัทมาตรฐานของ Odoo

ตั้งค่าบริษัท¶

1. เข้าสู่ระบบในฐานะ admin
2. เปิดใช้งานโหมดนักพัฒนา (Settings → Developer Tools → Activate the developer mode)
3. ไปที่ Settings → Users & Companies → Companies
4. แก้ไขบริษัทเริ่มต้น (เปลี่ยนชื่อเป็น กลุ่มบริษัทแม่ ของคุณ เช่น "ABC Hospital Group")
5. สร้าง บริษัทลูกหนึ่งบริษัทต่อโรงพยาบาล กำหนด:
   • Name — เช่น "ABC Hospital — Bangkok Branch"
   • Parent Company — บริษัทกลุ่มที่คุณเพิ่งเปลี่ยนชื่อ
   • Currency, Timezone, Address, VAT — รายสาขา
   • Logo — โลโก้สาขา หากมี

กำหนดผู้ใช้ให้กับบริษัท¶

สำหรับผู้ใช้แต่ละราย (Settings → Users & Companies → Users):

1. เปิดเรกคอร์ดของผู้ใช้
2. ตั้ง Allowed Companies เป็นสาขาที่อนุญาตให้เข้าถึง
3. ตั้ง Default Company เป็นสาขาที่ผู้ใช้ควรเข้าไปอยู่หลังจากเข้าสู่ระบบ
4. ผู้ใช้สามารถสลับสาขาได้ตลอดเวลาผ่านตัวเลือกบริษัทที่ มุมขวาบนของ UI

การกำหนดขอบเขตเรกคอร์ดทำงานอย่างไรจริง ๆ ใน HEMMS¶

นี่คือ การตรวจสอบตามจริง ว่าเรกคอร์ดใดของ HEMMS ถูกกำหนดขอบเขตตามบริษัทในปัจจุบัน และเรกคอร์ดใดที่ไม่ได้ ตรวจสอบเทียบกับ source ใน addons/roots/

ข้อมูลหลัก: อะไรที่ถูกใช้ร่วมกัน¶

ในโหมดหลายบริษัทแบบฐานข้อมูลเดียว สิ่งต่อไปนี้ถูก ใช้ร่วมกันทุก โรงพยาบาล ตามการออกแบบ:

• ชนิด PM (maintenance.kind) — หมวดหมู่การสอบเทียบ / PM / ความปลอดภัยทางไฟฟ้า เหมือนกันทุกที่
• ชนิดสัญญา (hemms.contract.type) — หมวดหมู่ FSC / PSC / TM เหมือนกัน
• การตั้งค่า criticality matrix
• เทมเพลตรายงาน HA
• บัญชีผู้ใช้ กลุ่มความปลอดภัย record rule

หากโรงพยาบาลลูกต้องการแคตตาล็อก PM ที่แตกต่างกัน นั่นเป็นสัญญาณ ให้แยกออกเป็นฐานข้อมูลของตัวเอง

รูปแบบที่ 2 — หนึ่งฐานข้อมูลต่อโรงพยาบาล¶

รัน Compose stack แยกต่อโรงพยาบาล repo มีสองโปรไฟล์มาให้แล้ว (private และ gov) ซึ่งเป็นแม่แบบสำหรับรูปแบบนี้

กลไก¶

# Hospital A on port 8069
make up-private          # → http://hospital-a:8069
make install-private

# Hospital B — copy docker-compose.private.yml to docker-compose.b.yml,
# change container names + ports + volume names + DB name, then:
docker compose -f docker-compose.b.yml up -d

Dockerfile และ addons ถูกใช้ร่วมกัน (หนึ่งอิมเมจ สองคอนเทนเนอร์) แต่ วอลุ่ม (odoo_*_data, db_*_data) ถูกกำหนดขอบเขตตาม stack ดังนั้นข้อมูลจึง ถูกแยกออกจากกันอย่างสมบูรณ์

ข้อพิจารณาเรื่องการสำรองข้อมูล¶

สคริปต์สำรองข้อมูล รับอาร์กิวเมนต์ <private|gov> คัดลอกและปรับให้เข้ากับ stack เพิ่มเติม ดูที่ การสำรองข้อมูลและการกู้คืน

การอัปเกรด¶

แต่ละ stack อัปเกรดอย่างเป็นอิสระ จัดตารางหน้าต่างการอัปเกรดแบบหมุนเวียน — อัปเกรดโรงพยาบาล A ตรวจสอบ จากนั้นโรงพยาบาล B ดูที่ คู่มือการอัปเกรด

คำแนะนำ¶

สำหรับการติดตั้งในโรงพยาบาลไทย — ที่การรายงาน HA เป็นรายโรงพยาบาลและ ภาระด้านอธิปไตยของข้อมูล / DPO เป็นรายโรงพยาบาล — หนึ่งฐานข้อมูลต่อโรงพยาบาล เป็น ค่าเริ่มต้นที่สะอาดกว่า ใช้หลายบริษัทแบบฐานข้อมูลเดียวเฉพาะเมื่อ:

• ลูกค้าเป็นนิติบุคคลเดียวที่มีสาขา
• บุคลากร BME ทำงานข้ามสาขาจริง ๆ
• การรวม KPI ระดับกลุ่มเป็นความจำเป็นทางธุรกิจจริง
• ลูกค้ายอมรับข้อจำกัดเรื่องการกำหนดขอบเขตตามบริษัทเพียงบางส่วนข้างต้น

เมื่อเงื่อนไขเหล่านั้นไม่ครบ Compose stack สองชุดบนสองพอร์ตจะง่ายกว่า ปลอดภัยกว่า และสำรองข้อมูล กู้คืน และอัปเกรดได้ง่ายกว่า

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

• ผู้ใช้และสิทธิ์การเข้าถึง — การกำหนดผู้ใช้ให้กับบริษัท
• การสำรองข้อมูลและการกู้คืน — ขั้นตอนการสำรองข้อมูลราย stack
• สถาปัตยกรรม — เหตุใดจึงใช้ข้อมูลหลักร่วมกัน