แผนงาน¶

HEMMS พัฒนาผ่านไตรมาสเล็กๆ ที่มีธีม — แต่ละไตรมาสเป็นชุดโมดูลที่ครบในตัวเอง ซึ่งจัดส่งหลังด่าน CI และลงเป็นการเผยแพร่เดียว เจ็ดไตรมาสแรกอยู่ใน main แล้ว หน้านี้บันทึกสิ่งที่ทำเสร็จ สิ่งที่อยู่ในคิว และสิ่งที่เราตั้งใจ ยังไม่ ผูกมัด

จัดส่งแล้ว (Q1 → Q7)¶

ดู บันทึกการเผยแพร่ สำหรับรายการต่อ commit และ สถาปัตยกรรม สำหรับวิธีที่โมดูลต่างๆ ประกอบกัน

ขั้นถัดไป¶

เหล่านี้คือธีมที่เรากำลังกำหนดขอบเขตอย่างจริงจัง สิ่งเหล่านี้ ไม่ใช่ วันที่ที่ผูกมัด — แต่ละธีมจะมีเอกสาร Q-plan ของตนเองที่ docs/developer/ ก่อนที่จะมีโค้ดใดลง ชื่อของโมดูลจริง อาจเปลี่ยนแปลงได้

การคิดค่าเสื่อมราคาครุภัณฑ์ / IAS 16¶

เชื่อม maintenance.equipment เข้ากับ account.asset ของ Odoo โรงพยาบาล ที่ทำบัญชีครุภัณฑ์ภายใต้ IAS 16 ต้องการต้นทุนการได้มา อายุการใช้งาน มูลค่า ซาก ค่าเสื่อมราคาสะสม และตารางรายปีบนเรกคอร์ดเครื่องมือแพทย์ทุกชิ้น รหัสครุภัณฑ์ (Ref. No.) และข้อมูลหลักครุภัณฑ์ที่มีอยู่จาก Q1 เป็นจุดเชื่อม ที่เหมาะสม ดู การปฏิบัติตาม IAS 16 สำหรับภูมิหลังด้าน กฎระเบียบ

อินเทอร์เฟซพยาบาลแบบ mobile-first¶

ขั้นตอนการส่งคำขอแบบลดทอนที่เหมาะกับโทรศัพท์หรือ แท็บเล็ตที่ข้างเตียง มุมมองพยาบาลในวันนี้สืบทอด ฟอร์ม maintenance.request แบบเต็ม เราต้องการขั้นตอน "รายงานเครื่องมือเสีย" แบบ 3-แตะ ที่เติมตำแหน่ง เครื่องมือแพทย์ และผู้รายงานไว้ล่วงหน้าจาก พนักงานที่เข้าสู่ระบบ

แดชบอร์ดสำหรับผู้บริหาร¶

แดชบอร์ดสไตล์ AUM สำหรับผู้อำนวยการโรงพยาบาล: % การปฏิบัติตาม SLA จำนวนอะไหล่วิกฤตที่ขาดสต็อก ไปป์ไลน์การต่ออายุสัญญา ความสมบูรณ์ของรายงาน HA ตามแผนก ข้อมูลมีอยู่แล้ว (การค้นหา SLA-breached, cron อะไหล่สต็อกต่ำ, cron สถานะสัญญา, การรวมผลรายงาน HA) — สิ่งที่ขาดคือ ชั้นองค์ประกอบ board.board / OWL

รายงาน PM รูปแบบ JCI¶

ตัวเทียบเคียงกับรายงาน HA Thailand ของ Q5 จัดรูปแบบสำหรับผู้ตรวจประเมิน JCI แทน HA แหล่งข้อมูลเดียวกัน (hemms.ha.report.line บวกกับ MoPH device class) เทมเพลต QWeb ต่างกัน เป็นภาษาอังกฤษล้วน ไม่มีหน้า ลายเซ็นภาษาไทย นำรูปแบบ snapshot-on-submit ของ Q5 กลับมาใช้เพื่อให้การ พิมพ์ซ้ำยังคงเหมือนกันแบบ byte ต่อ byte

ใบรับรองการสอบเทียบ¶

โมดูลน้ำหนักเบาใหม่ hemms.calibration.cert ที่เชื่อมโยงกับ maintenance.equipment และ maintenance.request พร้อมการอัปโหลด PDF วันหมดอายุ หน่วยงานสอบเทียบ (เช่น NIMT, NIST) และ cron รายวัน ที่จุดกิจกรรมการต่ออายุ น่าจะเป็นสะพานเชื่อมสไตล์ Q4 ไปยัง sign_oca สำหรับใบรับรองที่ผู้ขายรับรอง

การพยากรณ์อะไหล่¶

Q2 จัดส่ง consumption-on-PM และ cron อะไหล่วิกฤตสต็อกต่ำ ขั้นตอนถัดไป คือจุดสั่งซื้อใหม่และการพยากรณ์ความต้องการตามข้อมูลการเบิกในอดีต — ส่วนขยาย stock.warehouse.orderpoint เล็กๆ ที่อิงกับระดับความวิกฤต ของเครื่องมือแพทย์ ไม่ใช่แค่อัตราการหมุนเวียนของสินค้า

เลื่อนออกไปอย่างตั้งใจ¶

สิ่งที่เราพิจารณาแล้วและตั้งใจ ไม่ จัดลำดับความสำคัญสำหรับงานวงถัดไป:

• การคิดเงินผู้ขายหลายสกุลเงิน โมเดลสัญญาสมมติว่ามี บริษัทโรงพยาบาล / สกุลเงินเดียว หลายสกุลเงินแก้ได้แต่ ไม่อยู่บนเส้นทางวิกฤตสำหรับโรงพยาบาลรัฐไทย
• ลำดับชั้นครุภัณฑ์เชิงลึกระดับ EAM ต้นไม้เครื่องมือแพทย์ที่เกิน สองระดับ (Brand → Model) — เราจะกลับมาดูเฉพาะเมื่อลูกค้า ต้องการ
• โหมดออฟไลน์บนมือถือ การซิงค์ออฟไลน์แบบ native เป็นเรื่องยาก เราจะเริ่ม ด้วยมือถือแบบออนไลน์เท่านั้นและกลับมาดูหากลูกค้าร้องขอ

การมีส่วนร่วมจากชุมชน¶

ยินดีต้อนรับ pull request เราใช้ มาตรฐานการเขียนโค้ดของ OCA (ruff + pylint_odoo + oca-checks-odoo-module — ดู CI/CD) และ มาตรฐานการเขียนโค้ดของ Odoo อย่างเป็นทางการ เป็นด่าน pre-commit สองด่านของเรา อ่านสิ่งเหล่านี้ก่อน:

• สถาปัตยกรรม — โมเดล 3 ชั้นและ หลักการตั้งชื่อฟิลด์
• การพัฒนาโมดูล — วิธี สร้างโครงและเชื่อมต่อโมดูล roots_hemms_* ใหม่
• การมีส่วนร่วม — ขั้นตอนการทำงานด้าน เอกสาร / commit / PR

แผนการออกแบบ Q2 → Q6 (docs/developer/q*-*-plan.md) เป็นตัวอย่าง การทำงานที่ดีว่าเรากำหนดขอบเขต ตัดสินใจ และจัดส่งไตรมาสอย่างไร

วิธีติดตามความคืบหน้า¶