🔗 خطة: كود جهاز واحد ← أكثر من تحليل (Multi-Mapping)

مثال: السكر — الصايم (FBS) والفاطر (PPBS) لهم نفس كود الجهاز، بس تحليلين مختلفين في النظام

Moon ERP · LIS · machine-test-mappings + orders + result-ingest · تحليل قبل التنفيذ

📅 13 يونيو 2026 ⛔ خطة فقط — للقرار

★ المطلوب (بكلامك)

«الكود يتربط بأكتر من investigation — مثلاً السكر الصايم والفاطر نفس كود التحليل على الجهاز، بس هما اتنين تحليل مختلف. فلازم الاتنين على نفس الكود، ولما يطلب اللي فيهم في العينة هو اللي يرجع.»

الجوهر: الجهاز بيقيس «جلوكوز» بكود واحد (مثلاً GLU). لكن في النظام ده ممكن يكون FBS (صايم) أو PPBS (فاطر) أو RBS (عشوائي) — تحاليل منفصلة بأسعار/رنجات مختلفة. لازم:

الكود GLU يتربط بالتلاتة (نفس الكود، تحاليل مختلفة).
الاستعلام: العينة اللي عليها FBS → ترجّع GLU.
النتيجة: الجهاز يبعت GLU → تروح للتحليل الصح اللي على العينة دي (FBS)، مش عشوائي.

١ ليه ده مش شغّال دلوقتي — عائقين

العائق	المكان	الأثر
قيد تفرّد الكود `machine_test_code_unique` على (machine_id, machine_test_code)	migration	مينفعش كود `GLU` يتكرر مرتين على نفس الجهاز → مينفعش نربطه لـFBS و PPBS.
الإدخال بياخد أول mapping عشوائي	LabMachineResultController::store — `where(machine,code)->first()`	لو الكود متكرر، النتيجة تروح لتحليل عشوائي (FBS أو PPBS) بغضّ النظر عن العينة → نتيجة في التحليل الغلط.

ملاحظة: قيد machine_investigation_unique (machine, investigation) يفضل زي ما هو — كل investigation يتربط مرة واحدة، بس ممكن أكتر من investigation يشتركوا في نفس الكود.

٢ الخبر الكويس — نموذج «لكل عينة» بيحلّ نص المشكلة

إحنا أصلاً صلّحنا orders() تبقى per-sample (ترجّع تحاليل العينة/الباركود نفسه، مش الطلب كله). والسكر الصايم والفاطر بيتسحبوا في عينتين/باركودين مختلفين (سحبة صايم وسحبة بعد الأكل).

باركود FBS → العينة عليها FBS → الاستعلام يرجّع GLU → الجهاز يبعت GLU → يروح لـ FBS ✅ باركود PPBS → العينة عليها PPBS → الاستعلام يرجّع GLU → الجهاز يبعت GLU → يروح لـ PPBS ✅

يعني: العينة نفسها هي اللي بتحدّد التحليل الصح. كل اللي محتاجينه: (أ) نسمح بنفس الكود لتحاليل مختلفة، (ب) الإدخال يختار التحليل اللي على عينة النتيجة بدل العشوائي.

٣ الحل المقترح

أ) قاعدة البيانات

أشيل قيد machine_test_code_unique (migration). أسيب machine_investigation_unique.

ب) الإدخال (النتيجة) — request-aware

في store(): بدل ->first()، لما الكود يطابق أكتر من mapping:

mappings = كل الـ(machine, code) النشطة لو واحد بس → استخدمه (زي دلوقتي) لو أكتر من واحد → اختار اللي investigation بتاعه موجود على طلب/عينة النتيجة (lab_sample_investigations) لو لسه أكتر من واحد على نفس العينة → اختار اللي لسه مالوش نتيجة (أو علّمه للمراجعة) لو مفيش تطابق → unmatched/pending

ج) الاستعلام (orders)

زي ما هي — بترجّع كود كل investigation على العينة، وunique() (مضافة) بتمنع تكرار نفس الكود لو اتفق إن تحليلين على نفس العينة بنفس الكود.

د) حفظ الـmapping + التحقّق

الحفظ يطابق الموجود بـ(machine, investigation) فقط (مش الكود) — فنفس الكود يتقبل لتحاليل مختلفة.
قاعدة التحقّق Rule::unique(code) تتشال/تتعدّل (دلوقتي بتمنع تكرار الكود).

هـ) الواجهة (machine-setup) — ده اللي إنت طالبه بالظبط

كل كود جهاز يبقى قصاده اختيار متعدد (multi-select) للتحاليل بدل اختيار واحد:

كود الجهاز التحاليل المربوطة (multi-select) ───────── ────────────────────────────── GLU → [ FBS ✓ ] [ PPBS ✓ ] [ RBS ✓ ] ← تختار أكتر من تحليل TSH II → [ TSH ✓ ] ALT → [ ALT ✓ ]

تختار التحاليل اللي الكود ده بيخدمها (واحد أو أكتر) → الحفظ بيعمل mapping لكل تحليل مختار، كلهم بنفس الكود.
إزالة تحليل من الاختيار → يمسح الـmapping بتاعه بس (الباقي يفضل).
الجدول الموحّد الحالي (كود → تحليل واحد) يتطوّر لـ(كود → قائمة تحاليل). الأكواد القديمة (تحليل واحد) تفضل شغّالة عادي.

النتيجة العملية: في machine-setup تكتب الكود مرة واحدة وتعلّم على كل التحاليل اللي بتطلع منه (FBS/PPBS/RBS) — والباقي (إن النتيجة تروح للتحليل الصح حسب العينة) بيتظبط تلقائياً بالـrequest-aware ingest.

٤ الحالات الحرجة — محتاجة قرارك

الحالة	السؤال	المقترح
FBS و PPBS على نفس العينة/الباركود	لو الاتنين اتطلبوا على نفس السحبة (غير شائع)، الجهاز يبعت GLU واحد → يروح لمين؟	غالباً مش بيحصل (سحبتين مختلفتين). لو حصل: نطبّق على اللي لسه فاضي، أو نطبّق على الاتنين بنفس القيمة، أو نعلّمه «غامض» للمراجعة. قرار
تحاليل مكرّرة فعلاً (زي Vitamin D 151/2567)	نفس الحل بيخدمها؟	أيوة — نفس الآلية بتغطّي التحاليل المكرّرة بأسماء مختلفة كمان.
دمج مع «الفاضي فقط»	التوافق مع خطة «الاستعلام يرجّع الفاضي بس»	متوافقين — الاتنين بيشتغلوا على مستوى العينة. ننفّذهم مع بعض أو ورا بعض.

⚠ المخاطر + ترتيب التنفيذ

الأهم: لازم نعمل الإدخال request-aware قبل أو مع إزالة قيد تفرّد الكود. لو شِلنا القيد والإدخال لسه ->first() → النتيجة هتروح لتحليل عشوائي (FBS أو PPBS) = نتيجة في التحليل الغلط (خطر إكلينيكي).

ترتيب التنفيذ المقترح

1) أعدّل الإدخال يبقى request-aware (يختار التحليل اللي على عينة النتيجة).
2) أعدّل حفظ الـmapping + قاعدة التحقّق (يطابق بالـinvestigation، الكود مش فريد).
3) migration: أشيل machine_test_code_unique.
4) الواجهة: عرض/سماح بالكود المتكرر.
5) اختبار: عينة FBS + عينة PPBS، الاتنين كود GLU → كل واحدة نتيجتها تروح لتحليلها الصح.

❓ قرارات محتاجها منك

1) لو FBS و PPBS اتطلبوا على نفس العينة/الباركود (نادر): النتيجة الواحدة تروح للاتنين بنفس القيمة؟ ولا للأول الفاضي؟ ولا نعلّمها للمراجعة؟
2) ننفّذ ده مع خطة «الاستعلام يرجّع الفاضي فقط» في دفعة واحدة، ولا واحدة ورا التانية؟
3) تأكيد: الكلاود (BE) هو اللي هيتعدّل (orders + store + mapping + migration) — مفيش تغيير في الميدل وير. ✅