Hilton Kitchen

تطبيق عميل / دراسة حالة هندسية

من أول بيعة.لآخر تسليم.

نقطة بيع، تصنيع، مخزون وتحصيل. نظام واحد متصمم على الشغل اللي فريق هيلتون كيتشن بيعمله فعلًا.

جوه الحكاية21 دقيقة

شاشة المدير الفعلية بالعربي ببيانات عرض تجريبية — شاشات تجريبية · تصوّر للأجهزة

نقطة البيع الفعلية بالعربي، كتالوج وسلة فارغة وحالة مراجعة الطلبات المحلية — شاشات تجريبية · تصوّر للأجهزة

العلاقة: تطبيق عميل
دورنا: تصميم وهندسة المنتج
المنصات: Web + Windows
لغة التشغيل: عربي أولًا / دعم إنجليزي

فريق سوفتوركس للهندسة / مراجعة المحتوى 18 أكتوبر 2026

دراسة حالة من فريق مهندسي Softworks عن بناء نظام تشغيل مخصص، عربي من البداية، ومرتبط بتفاصيل الشغل اليومية.

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

في Hilton Kitchen، بنينا النظام حوالين الترابط ده. جمعنا البيع المباشر، وطلبات التوصيل والجملة، وبيع الأجهزة بالرقم المسلسل، وحركات المخزون، والتحصيل، والمستندات، في تجربة تشغيل واحدة. ووسّعنا التجربة بتطبيق موظفين على ويندوز يقدر يحتفظ بالشغل المؤقت ويرجّعه للخادم لما الاتصال يرجع.

الحكاية هنا عن قرارات هندسية ليها أثر واضح على الشغل: إمتى نخصم المخزون؟ إيه اللي يحصل لو الرد ضاع؟ وإزاي فاتورة طويلة تفضل مقروءة؟ السيناريوهات الجاية أمثلة افتراضية مستوحاة من التنفيذ والاختبارات؛ مش وقائع منسوبة لعميل أو موظف.

01 / فهم الشغل

النظام بيتبع حركة الشغل.

البيع، التسليم، والتحصيل. كل واحد له معنى.

المشروع في نظرة واحدة

اشتغلنا على Hilton Kitchen MMS كنظام مخصص لإدارة دورة الطلب وحركة البضاعة والتحصيل. مساحة العمل بتتغير حسب المهمة: الكاشير بيختار المنتجات ويقفل البيع، والمبيعات بتجهز الطلبات وتتابع التحصيل، والمصنع والتجهيز بيتعاملوا مع خطوات تنفيذ واضحة، والمخزن بيشوف الأرصدة والتسليمات.

الجانب	اللي اتبنى
فريق التنفيذ	فريق هندسة البرمجيات في Softworks
اللغة الأساسية	عربي باتجاه من اليمين لليسار، مع دعم الإنجليزي
أنواع الطلبات	بيع مباشر، أجهزة، توصيل، وجملة
مساحات التشغيل	كاشير، مبيعات، مصنع، تجهيز، مخزن، مدير، وإدارة
واجهات الاستخدام	موقع وتطبيق موظفين على ويندوز
المستندات	إيصالات حرارية، فواتير A4، ملصقات، وبيانات تجهيز

الدراسة بتوصف المصدر اللي راجعناه يوم 18 أكتوبر 2026. تواريخ الإصدارات والصور والاختبارات مذكورة لوحدها، لأن وجود تحسين في الكود مش معناه تلقائيًا إنه وصل لكل جهاز شغال. والتخصيص هنا ظاهر في دورة العمل نفسها، مش بس في اسم المنتج أو ألوانه.

فهمنا المشكلة من حركة الشغل

المرجع التشغيلي الأصلي وصف شغل بيتوزع بين مصنعين، والتجهيز، والمخزن، والكاشير، والمكتب الرئيسي. متابعة الطلب وسط الأماكن دي محتاجة سجل مركزي مفهوم: مين استلم الخطوة، وإيه اللي خلص، وإيه اللي لسه منتظر، وإمتى البضاعة دخلت المخزون أو خرجت منه.

بدأنا بتحديد معنى كل فعل. «تأكيد البيع» له نتيجة مختلفة عن «إنهاء التصنيع». و«جاهز» معناها إن التجهيز اكتمل، بينما «تم التسليم» معناها إن البضاعة خرجت لمستلم معروف. التفرقة دي بقت أساس نموذج البيانات، وتسميات الأزرار، وترتيب الشاشات، والمستند اللي بيطلع بعد كل خطوة.

وبنينا على التعديلات المعتمدة أثناء التطوير: البيع المباشر من المخزون، ومنطقة مستقلة للأجهزة، والتحصيل على دفعات، والمرتجعات، والعمل المؤقت من غير اتصال في تطبيق ويندوز. كل إضافة كان لازم تدخل في نفس منطق التشغيل، وتوضح أثرها على الطلب والمخزون والمبالغ، بدل ما تتحول لشاشة منعزلة محتاجة حد يربطها بباقي النظام يدويًا.

02 / مسارين للطلبات

نفس الكاونتر. ومسارات مختلفة.

اختار مسار الطلب

01
بيع مباشر
منتجات جاهزة أو جهاز محدد برقم مسلسل.
02
معاملة واحدة
فحص الرصيد وتسجيل البيع وخصم المخزون وتجهيز المستند.
03
مكتمل من المخزون
من غير دخول طابور التصنيع.

التحصيل مسار مستقل

المبيعات تقدر تسجل دفعة مقدمة أو أقساط. الكاشير يشترط السداد الكامل.

خصصنا مسارين للطلبات

المسار الأول للمنتج الجاهز. طلب الكاشير بيبيع من المخزون المتاح، وطلب الأجهزة بيبيع وحدات محددة من منطقة الأجهزة. عند تأكيد العملية، الخادم بيراجع الرصيد، ويسجل البيع وحركة الخروج، ويكمّل الطلب، ويجهز المستند المناسب في معاملة واحدة. الطلبات دي مابتدخلش طابور التصنيع.

المسار التاني للتوصيل والجملة. الطلب بيبدأ في التصنيع، ويظهر في الطابور المشترك للمصنعين، وبعدها ينتقل للتجهيز. لما التجهيز يكتمل بالكميات الصحيحة، النظام بيسجل دخول الإنتاج الجاهز للمخزون. التسليم لعميل أو سائق باسمه بيسجل الخروج وينهي الطلب.

ده خلّى عندنا أربع حالات تشغيل واضحة: تصنيع، وتجهيز، وجاهز، ومكتمل. وكل حالة مرتبطة بفعل محدد وشروط واضحة. الموظف مش مطلوب منه يختار أي حالة من قائمة عامة؛ هو بينفذ الخطوة المتاحة في سياق شغله. والمدير يقدر يفهم مكان الطلب في الرحلة من غير ما يفسر معاني مختلفة لكلمة «مكتمل» على شاشات متعددة.

لقطة مراجعة محلية لمساحة المبيعات بسلة فارغة. بتوضح تنظيم العمل، ومش دليل على تنفيذ عملية بيع بعينها.

03 / عملية مترابطة

البيعة لازم تتسجّل كاملة.

خدمات Fastify بتفحص الإجراءات باستخدام Zod. الطلب والمخزون والدفعات والمستندات يتسجلوا سوا حسب العملية.

إجراء محدد ← معاملة قاعدة بيانات ← إشعار بعد الحفظ ← تحديث الشاشات

اخترنا بنية تخدم قواعد العمل

بنينا الواجهة بـ Next.js وReact، والخادم بـ Fastify، وقاعدة البيانات بـ PostgreSQL مع Prisma. استخدمنا TypeScript علشان شكل البيانات بين الواجهة والخادم يفضل صريح، وZod لفحص حدود الإدخال والنتائج. قواعد البيع والمخزون والتحصيل موجودة في خدمات المجال على الخادم؛ المكونات المرئية بتعرض الحالة وتطلب الفعل المناسب.

الطبقة	النسخة الموجودة في المصدر وقت المراجعة	دورها
الواجهة	Next.js 16.3.1 وReact 19.2.8	صفحات الويب وواجهة تطبيق الموظفين
لغة التطوير	TypeScript 6.0.3	عقود واضحة للبيانات
مكونات العرض	Tailwind CSS 4.3.3 وRadix UI 1.6.7	تفاعلات متسقة وعرض مخصص
الخادم	Fastify 5.12.0 وZod 4.3.3	عمليات واضحة وفحص البيانات
البيانات	PostgreSQL وPrisma 7.9.1	علاقات ومعاملات وترحيلات
الحسابات	decimal.js 10.6.0	دقة المبالغ والكميات
التحديثات	Socket.IO 4.8.3	إخطار الشاشات بالتغييرات
تطبيق ويندوز	Electron 44.2.0 وSQLite	تشغيل الواجهة وحفظ العمل المحلي

بيئة التطوير بتستخدم PostgreSQL 16.14، وNode 24، وpnpm 11.21.0. الأرقام دي توثيق للمصدر المراجع، مش توصية باختيار أحدث إصدار متاح. الأهم في الاختيار كان إن حدود المسؤولية تفضل مفهومة، وإن كل جزء يقدر يتبني ويتراجع باختباراته.

سيناريو افتراضي: آخر قطعة قدام كاشيرين

تخيّل إن جهازين عرضوا إن باقي قطعة واحدة. كل كاشير أضافها للسلة قبل ما التاني يخلص. الرصيد اللي ظهر وقت اختيار المنتج بقى معلومة قديمة لحظة التأكيد؛ عشان كده الاعتماد على فحص الشاشة وحده مش كفاية.

خلّينا مراجعة الرصيد والخصم جزءًا من نفس معاملة البيع في قاعدة البيانات. العملية بتقفل الأصناف المعنية بترتيب ثابت، وتقرا الرصيد الحالي، وتتأكد إن الكمية متاحة، وبعدها تحفظ الطلب والحركات والمستند. لو صنف واحد ناقص، البيع كله بيرجع من غير تسجيل جزئي.

التصميم ده بيربط معنى النجاح بنتيجة كاملة. مافيش طلب مكتمل وحركة مخزون ناقصة، ومفيش خصم حصل من غير الطلب اللي سببه. الاختبارات بتغطي نقص الرصيد، والتراجع عن العملية، ومحاولات الإعادة. المثال ده بيوضح ليه المعاملة عندنا وحدة إتمام للعمل التجاري، وليه الحساب المعروض في السلة يفضل تقديرًا لحد ما الخادم يؤكد العملية بالمعلومات الحالية.

لقطة محفوظة ببيانات تجريبية وسلة فارغة. ظاهر تنبيه فحص الوردية؛ الصورة بتشرح توزيع الواجهة، ومش إثبات بيع مكتمل.

سيناريو افتراضي: البيع اتحفظ والرد ضاع

ممكن الخادم يسجل العملية بنجاح، وبعدها الاتصال ينقطع قبل ما الرد يوصل. الموظف وقتها شايف انتظار، وعايز يضغط تأكيد مرة تانية. السؤال الهندسي هنا: الإعادة معناها نفس النية، ولا بيع جديد؟

كل تعديل عندنا له معرّف ثابت اسمه clientActionId. النتيجة بتتحفظ مع العملية، ولو نفس الطلب اتبعت تاني، النظام بيرجع النتيجة الأصلية. الواجهة بتحتفظ بالمعرّف نفسه في حالات الرد المجهول، وبتمنع الضغط المتكرر أثناء الإرسال. ده اسمه تنفيذ قابل للإعادة من غير تكرار الأثر.

اختبرنا فقدان الاتصال، وإعادة فتح المكوّن، والرد الناقص، وحالة إن الخادم يكون حفظ فعلًا لكن الواجهة ماقدرتش تفهم الرد. الفرق مهم: رسالة فشل مؤكدة ممكن تسمح بتصحيح الإدخال، لكن نتيجة غير معروفة محتاجة استرجاع نفس العملية. بالشكل ده، طريق التعافي بقى جزءًا من التصميم، والموظف عنده حالة واضحة بدل ما يخمّن إذا كان المفروض يبدأ من الأول.

سيناريو افتراضي: نفس الموديل، جهازين مختلفين

عند بيع معدات مطابخ، اسم الموديل لوحده مش كفاية. جهازين ممكن يبقوا نفس المنتج ونفس السعر، لكن كل واحد له رقم مسلسل وتاريخ حركة مختلف. ولو واحد رجع بعد البيع، لازم نعرف أنهي وحدة رجعت بالضبط.

فصلنا المنتج في الكتالوج عن الوحدة الفعلية. المنتج بيحمل التعريف التجاري، والوحدة بتحمل المسلسل والباركود والحالة والارتباط بعملية البيع. اختيار جهازين للبيع بيستلزم اختيار وحدتين مختلفتين؛ الكمية هنا ناتجة عن الوحدات المختارة، ومش رقم مستقل يكتبه الموظف ويختلف عنها.

الخادم بيراجع إتاحة الوحدات مع الرصيد، وبيغيّر حالتها مع إتمام البيع داخل نفس المعاملة. واختبارات المجال بتغطي الأرقام المسلسلة المكررة، والكميات الصحيحة، وتطابق العدد مع الاختيار. ده خلّى مستند البيع والمرتجع يفضلوا مربوطين بالبضاعة الفعلية، وخلّى تصحيح عدد الأجهزة مباشرة خارج مسارها الطبيعي غير متاح؛ لأن الرصيد لازم يفضل له وحدات موجودة تفسره.

سيناريو افتراضي: الجهاز اتسلّم وباقي عليه أقساط

عميل اشترى جهاز، ودفع مقدم، واستلم الوحدة، ولسه هيسدد الباقي بعدين. لو ربطنا حالة الطلب بالمبلغ، هنلاقي جهاز خرج فعلًا لكن الطلب لسه ظاهر كأنه محتاج تصنيع أو تجهيز.

فصلنا تقدم التنفيذ عن تقدم التحصيل. طلب الجهاز اللي أنشأته المبيعات ممكن يكتمل تشغيليًا، مع بقاء رصيد مستحق. الدفعات اللاحقة بتتضاف لسجل مالي متتابع، وبتحدّث المدفوع والمتبقي من غير ما تخصم المخزون مرة تانية. أما البيع المباشر من الكاشير، فبيحتاج السداد الكامل عند الإقفال.

خطة الأقساط بتحدد مواعيد ومبالغ لازم مجموعها يساوي الرصيد المستحق. والتعديل المالي بيستخدم نسخة للحالة علشان عملية قديمة ماتكتبش فوق نتيجة أحدث. النظام كمان بيسجل طرق الدفع والمراجع والأدلة، ومنها النقدي وInstaPay وVodafone Cash؛ ده تسجيل ومراجعة للتحصيل، ومش ادعاء إن عندنا بوابة بتنقل الأموال. التفرقة خلت شاشة الطلب تجاوب بوضوح: البضاعة وصلت لفين، والفلوس وصلت لفين.

سيناريو افتراضي: مرتجع من غير افتراضات

رجوع المنتج مش معناه تلقائيًا إنه جاهز للبيع، ولا معناه إن العميل لازم ياخد نفس مبلغ الفاتورة نقدًا. ممكن الوحدة تحتاج عزل، وممكن البيع الأصلي كان عليه مبلغ لسه ماتدفعش.

بنينا المرتجع كعملية جديدة بتختار الكمية أو المسلسل المعني، وبتسجل قرار المخزون وقرار التسوية المالية. رجوع للمخزون، أو عزل، أو عدم رجوع مادي للمخزون: كل اختيار له أثر محدد. والسجل الأصلي للبيع بيفضل موجود، بدل ما نغيّر الماضي ونفقد تفسير الرصيد الحالي.

الاختبارات بتراجع إن كمية المرتجع ماتزيدش عن المتبقي القابل للإرجاع، وإن الصرف مايزيدش عن المبلغ المقبوض. وفي اختبار مخصص لمرتجع جهاز غير مدفوع، علشان النتيجة ما تتحولش لصرف نقدي غير مبرر. كمان وثقنا مستند المرتجع بالقيم الناتجة بعد العملية. بالشكل ده، موظف التحصيل والمخزن يقدروا يفهموا نفس القرار، حتى لو الأثر المالي مختلف عن الأثر على البضاعة.

سيناريو افتراضي: الشاشة فوتت تحديثًا

المصنع محتاج يشوف الطلب الجديد بسرعة، والمدير محتاج يشوف تقدم الشغل. لكن الاتصال اللحظي ممكن ينقطع، أو الرسالة تتفوت وقت إعادة الاتصال. الاعتماد على آخر إشعار وصل يسيب شاشة بتعرض صورة ناقصة.

استخدمنا Socket.IO لإخطار الشاشات بالتغييرات بعد حفظ المعاملة. الإشعار بيخلّي الشاشة تحدّث البيانات المعنية من الخادم، بدل ما كل واجهة تحسب لنفسها نسخة مستقلة من قواعد العمل. وعند الرجوع للاتصال، فيه إعادة تحميل للمعلومات علشان تعوض الرسائل اللي فاتت.

أضفنا كمان مراجعة دورية للحالة حتى مع وجود اتصال، ومسار تحديث بديل لو النقل اللحظي غير متاح. الاختبارات بتغطي وصول طلب للمصنع، وتغيير الكتالوج بعد الحفظ، وإعادة الاتصال، والتحديث البديل. الفكرة إن سرعة الإشعار تحسن الاستخدام، ومراجعة الحالة تحافظ على قابلية التعافي. مانقدرش نستنتج من ده زمن استجابة أو نسبة توافر تجارية؛ اللي نقدر نوثقه هو السلوك الموجود واختباراته.

sale-transaction.illustration.ts

// Illustrative transaction model, not production source.
async function completeSale(command: SaleCommand) {
  const result = await database.transaction(async (tx) => {
    const previous = await tx.actions.claimOrRead(command.actionId);
    if (previous.completed) return previous.result;

    const stock = await tx.inventory.lockAndRead(command.items);
    assertAvailable(stock, command.items);

    const order = await tx.orders.createCompleted(command);
    await tx.inventory.recordOut(order);
    await tx.documents.enqueue(order);
    await tx.actions.complete(command.actionId, order);
    return order;
  });

  // Other workspaces refresh only after the commit succeeds.
  notifyCommittedChange(result.id);
  return result;
}

مثال تعليمي مبسّط، مش كود الإنتاج. claimOrRead بتمثل حجزًا ذريًا لهوية الإجراء، مش مجرد فحص ثم كتابة.

04 / المخزون بسياقه

كل كمية وراها حكاية.

**اختيار الصنف ورصيده**اختيار الصنف ورصيده الحالي، ومعاه الرصيد المتوقع بعد إضافة المخزون. لقطة من مراجعة محلية للتصميم.

سيناريو افتراضي: التجهيز أكد كمية مختلفة

لو الطلب فيه 15 وحدة، والتجهيز سجل 14.999 أو 15.001، الفرق صغير في الكتابة لكنه تغيير في البضاعة اللي هنقول إنها جاهزة. ولو حد عدّل الطلب بعد التجهيز، لازم أثر التعديل يوصل لحالة العبوة كمان.

عاملنا التجهيز كنقطة مطابقة. الكمية المؤكدة لازم تساوي الكمية المتبقية المطلوبة بحساب عشري دقيق. وكل بند لازم يكون له تجهيز صالح قبل انتقال الطلب إلى «جاهز». التعديلات اللي بتبطل المطابقة بتحتاج إعادة تجهيز، بدل الاحتفاظ بإشارة اكتمال قديمة.

بعد الإتمام، حركة دخول الإنتاج بتوضح إن البضاعة بقت جاهزة ومتاحة. والتسليم النهائي له حركة خروج منفصلة ومستلم مسجل. الاختبارات بتجرب الزيادة والنقص، وكمان تزامن تعديل الكمية مع محاولة إكمال التجهيز أو التسليم. كده قدرنا نخلي تاريخ المخزون يحكي اللي حصل للبضاعة: اتجهزت إمتى، وبأي كمية، وخرجت إمتى؛ وكل سؤال منهم له حدث واضح يجاوبه.

لقطة محفوظة للحالة الفارغة في شاشة المصنع. مش طابور إنتاج مليان، ووجودها هنا بيوضح إن رسالة عدم وجود شغل جزء من التجربة.

لقطة للحالة الفارغة في التجهيز، مع مدخل للسجل السابق. مش صورة لبيان تجهيز مطبوع أو لطلب تحت التنفيذ.

سيناريو افتراضي: «١٢٫٥» كمية صحيحة

التعريب الحقيقي بيظهر وقت الكتابة. موظف المخزن ممكن يكتب ١٢٫٥ أو يستخدم أرقامًا فارسية، والمتصفح يرفض الحروف دي داخل حقل أرقام عادي قبل ما كود التطبيق يشوفها أصلًا. وتبديل النص في كل ضغطة ممكن ينقل مؤشر الكتابة لمكان غير متوقع.

عملنا حقلًا نصيًا بلوحة إدخال عشرية، بيفهم الأرقام العربية والفارسية والفواصل المدعومة. أثناء التركيز، بيحافظ على طريقة كتابة الموظف، وبعد اكتمال القيمة بيطلع تمثيلًا موحدًا زي 12.5. وعند الخروج من الحقل، العرض بيتنظم من غير تعطيل التحرير أثناءه.

الحقل كمان بيتعامل مع تكوين النص، والقيمة غير المكتملة، والدقة القصوى. لو النص الظاهر غير صالح، مايسيبش قيمة قديمة صالحة تتبعت بالغلط. وخلّينا نفس المنطق يخدم البحث بالباركود والأرقام المحلية. الاختبارات فيها كتابة عربية وفارسية، وفواصل، وأصفار في البداية، ومدخلات ناقصة. دي تفاصيل صغيرة في شكلها، لكنها بتحدد إذا كانت الواجهة العربية مريحة فعلًا للي بيستخدمها يوميًا.

سيناريو افتراضي: الرصيد اتغير قبل التصحيح

موظف فتح الصنف وشاف رصيد عشرة، وبدأ يراجع تصحيح العدد. قبل الحفظ، عملية تانية زوّدت الرصيد. لو حفظنا الرقم الجديد مباشرة، هنخفي أثر الحركة اللي حصلت في النص.

فصلنا التصحيح النهائي عن الإضافة والصرف العاديين. التصحيح بيبعت الرصيد اللي الموظف كان شايفه، والخادم بيقارنه بالرصيد الحالي بعد قفل الصنف. لو اختلف، النظام بيطلب مراجعة الحالة الحالية. ولو اتفق، بيسجل الفرق كحركة تصحيح؛ ولو مافيش فرق، مابيضيفش حركة فارغة المعنى.

في تحسينات المخزن الأحدث، رد الإضافة والصرف بقى يرجّع الرصيد المؤكد بعد الحفظ. الواجهة تقدر تعرضه فورًا بينما تحديث القوائم بيكمل. ده بيفرق بين الرصيد المتوقع قبل التنفيذ والرصيد اللي الخادم أكد إنه اتسجل. الاختبارات بتغطي الإعادة والرصيد القديم، والتحسينات دي موثقة محليًا؛ نشر أحدث تصميم للمخزن مش مثبت بمجرد وجود تقرير إصدار أقدم.

05 / لما النت يفصل

نحفظ الشغل. ونحسم اللي لسه معلّق.

Windows / طابور عمل دائم

تسجيل عميلمحفوظ محليًا
إنشاء الطلبمنتظر العميل
دفعة لاحقةمنتظر الطلب

الأوامر محفوظة في SQLite. الطباعة هنا مؤقتة، وإغلاق الشاشة مش بيمسح الشغل.

رسم توضيحي للتنفيذ. أوامر الأوفلاين الدائمة تخص تطبيق Windows؛ المتصفح بيخزن هيكل الواجهة والملفات الثابتة.

سيناريو افتراضي: شغل مترابط والنت مقطوع

في تطبيق ويندوز، الموظف ممكن يسجل عميلًا جديدًا، وبعده طلبًا للعميل، وبعده دفعة أو خطوة تشغيل. لو الاتصال رجع وبعتنا العمليات بأي ترتيب، الطلب ممكن يسبق العميل اللي بيعتمد عليه.

استخدمنا SQLite لحفظ أوامر العمل محليًا، ومع كل أمر الاعتماديات اللي لازم تخلص قبله. منسق المزامنة في العملية الرئيسية للتطبيق بيتابع الطابور، ويستبدل المراجع المحلية بمعرّفات الخادم بعد التأكيد، ويحفظ النتائج حتى لو الموظف غيّر الشاشة أو التطبيق اتفتح من جديد.

لما عملية تخص طلبًا معينًا تتعطل، العمليات التابعة لها بتنتظر، لكن الشغل المستقل يقدر يكمل. والموظف اللي نفذ الفعل الأصلي بيفضل معروفًا، حتى لو موظف تاني هو اللي رجّع الاتصال وساعد في المزامنة. الاختبارات بتغطي اعتماديات العميل والدليل المالي والعهدة والطلب بعد إعادة التشغيل. العمل المحلي هنا مؤقت لحد قبول الخادم، والمستند المؤقت لازم يفضل واضحًا بوصفه كده، عشان الحفظ على الجهاز مايتفهمش على إنه تأكيد نهائي من النظام المركزي.

سيناريو افتراضي: جهازين منفصلين شايفين نفس الوحدة

لو جهازين من غير اتصال عندهم نسخة قديمة بتقول إن ماكينة معينة متاحة، مافيش طريقة محلية تخلي كل واحد يعرف فورًا اختيار التاني. دي حدود طبيعية للعمل المنفصل، ولازم المنتج يعرضها بوضوح.

كل جهاز بيحسب أثر شغله المعلق على نسخته المحلية. وعند المزامنة، الخادم بيراجع الرصيد والوحدات الفعلية من جديد. لو الاختيار بقى غير متاح، العملية بتدخل مسار تعارض واضح ومراجعة، بدل ما تظهر كمبيعات مكتملة لمجرد إنها اتكتبت على الجهاز.

وفي تفصيلة مرتبطة برصيد بيع الكاشير: لو البيع اتقبل لكن نسخة المخزون المحلية لسه قديمة، ماينفعش نوقف خصمه محليًا فورًا، وإلا الرصيد المباع هيظهر متاحًا تاني. استخدمنا مراجعة مرقمة للمخزون علشان نعرف إمتى النسخة الجديدة شملت الحركة المقبولة. الربط هنا بمراجعة بيانات واضحة، مش بتخمين ترتيب ساعات الأجهزة. النتيجة المقصودة هي حفظ العمل وعرض حالته بصدق، مع بقاء القرار النهائي للمخزون عند المزامنة المركزية.

سيناريو افتراضي: تحديث التطبيق قابل شغلًا قديمًا

تحديث برنامج على جهاز شغال لازم يراعي البيانات اللي اتسجلت قبل التحديث. ده ظهر في مراجعة المصدر: أوامر مخزن قديمة كانت بتستخدم حقل direction، بينما منفذ الأوامر كان متوقع movementType. الواجهة الأحدث لوحدها ماكانتش كفاية لإصلاح الأوامر المنتظرة.

أضفنا توافقًا مع الشكل القديم والشكل الحالي، مع رفض القيم المتناقضة، وإرسال الحقول اللي نقطة النهاية بتفهمها. وراجعنا كمان شكل دفعات المبيعات المؤجلة، علشان الأوامر المخزنة قبل التعديل تقدر تعدّي من نفس عقد البيانات الصحيح.

الإصلاحات دي موثقة في تقرير بناء ويندوز 0.1.5 واختبارات منفذ الأوامر. وهي تغييرات محلية لاحقة لآخر التزام مسجل، مش جزءًا ننسبه بالخطأ لتاريخ أقدم. درس مهم هنا: التوافق مش بس إن النسخة الجديدة تفتح؛ لازم تفهم الشغل الموجود بالفعل، وتعرف إمتى تكمّله وإمتى تعرض تعارضًا يحتاج قرارًا. وتأكيد تشغيل الحزمة الفعلية بيظل خطوة مستقلة عن نجاح اختبارات المصدر.

06 / الشاشات والورق والناس

التجربة مش بتنتهي عند الشاشة.

كل صفحة ليها قاعدة

عدد البنود

HILTON KITCHEN15بند

HILTON KITCHEN1بند

31 بند = 15 + 15 + 1. الحد الأقصى 15 بند في الصفحة، وعنوان الفاتورة بيتكرر.

نموذج توضيحي، مش فاتورة حقيقية. تفاصيل الأجهزة لها ملحق منفصل: 8 وحدات في الصفحة.

الطباعة لها هندسة مختلفة عن الشاشة

الفاتورة الطويلة بتكشف مشاكل مش بتبان في نموذج فيه ستة بنود. سطر ممكن يتقسم، أو عنوان يختفي من صفحة متابعة، أو إجمالي يتزق خارج الورق. وعشان كده تعاملنا مع المستند كواجهة لها أبعاد وقواعد قراءة.

فواتير المبيعات والأجهزة A4 بتتقسم عند 15 بندًا مختلفًا في الصفحة. مثال افتراضي فيه 31 بندًا يطلع ثلاث صفحات بنود: 15، ثم 15، ثم بند واحد. بيانات التعريف بتتكرر، وتفاصيل الوحدات المسلسلة ليها ملاحق مستقلة، كل صفحة فيها لحد ثماني وحدات. والحد الحالي للطلب الكبير 100 بند؛ أما الكاشير فحده 20 بندًا مختلفًا في الإيصال الحراري.

أضفنا فحصًا قبل الطباعة للقص، والتجاوز، وإخفاء المحتوى، وحجم الخط. وفصلنا تنسيق الشاشة عن مقاسات الورق، علشان تحسين واجهة المخزن ما يغيّرش فاتورة. الاختبارات بتقيس الحدود والصفحات الممتدة، لكن معاينة المتصفح مش دليل على نجاح طابعة فعلية. معايرة الورق والماسح والطابعة على الأجهزة المستخدمة بتفضل قبولًا عمليًا منفصلًا.

الواجهة اتصممت لليد والعين والسياق

شاشات التشغيل بتدي مساحة للفعل الأساسي، وأسماء عربية واضحة، وأزرار مناسبة للمس. شاشة الكاشير بتفصل الكتالوج عن ملخص الطلب. والمخزن بيعرض الرصيد داخل نتائج البحث، وبعد الاختيار بيحافظ على الصنف والكمية قدام الموظف أثناء الإضافة أو الصرف.

الكتالوج بيدعم ثلاث مستويات تصنيف، وبيانات قابلة للبحث، لكن شبكة المنتجات بترسم بحد أقصى 16 بطاقة في المرة. عندنا اختبار بكاتالوج تجريبي فيه 1,500 منتج بيتأكد من الحد ده. ده دليل على تنظيم العرض، مش ادعاء إن ده عدد منتجات العميل أو قياس لسرعة تجارية.

المدير عنده عرض للمس وعرض أوسع للكمبيوتر، مبنيين على نفس البيانات والعمليات. وعلى الموبايل، العناصر بتترتب تحت بعض مع الحفاظ على وضوح الأفعال. راجعنا كمان الحالات الفارغة، والاسم الطويل، والكمية الغلط، ونتيجة البحث الفارغة؛ لأن الشغل اليومي مش كله شاشة نجاح. وحمينا الكتابة المبكرة قبل اكتمال تفاعل React، باختبار بيأخر ملفات التطبيق عمدًا علشان نتأكد إن المدخلات ماتضيعش.

عرض مكتبي محفوظ ببيانات تجريبية، بيوضح توزيع معلومات التشغيل على مساحة أوسع.

لقطة كاملة لعرض اللمس؛ ارتفاع الصورة أكبر من ارتفاع الشاشة الأصلية.

لقطة محلية نهائية لمراجعة عرض بعرض 390 بكسل، ومش إثبات استخدام يومي على هاتف العميل.

تاريخ التطوير بيشرح القرارات

سجل التغييرات بيوضح إن المنتج اتطور على خطوات لها معنى تشغيلي. بدأ تدفق الكاشير، وبعده اتفصل البيع المباشر عن التصنيع، واتضاف مسار الأجهزة، ثم تتبع الوحدات والتجهيز. بعد كده اتسع العمل للتحصيل والمرتجعات والعمل المحلي على ويندوز.

التاريخ	التغيير المسجل	أثره على التصميم
26 أغسطس 2026	تدفق كاشير محسّن، `2fd5c2f`	اختيار المنتجات وإقفال الطلب
29 أغسطس 2026	بيع مباشر، `c98173e`	إتمام البيع من المخزون الجاهز
30 أغسطس 2026	أجهزة وصفحات فواتير، `d31f149`	مسار معدات ومستندات ممتدة
30 أغسطس 2026	وحدات فعلية وتجهيز، `1868850`	ربط البضاعة بالمسلسل والكمية
9 سبتمبر 2026	تشغيل محلي ودورة طلب، `918ab9a`	توسيع العمل والتحصيل والمرتجعات
26 سبتمبر 2026	واجهات واعتمادية تطبيق الموظفين، `cb42e3f`	تحسين التجربة والتعافي
29 سبتمبر 2026	تصحيح مخزون ضمن `620511a`	تعديل رصيد بحركة واضحة
29–30 سبتمبر 2026	إصلاحات محلية لاحقة	توافق المزامنة وتجربة المخزن

التواريخ دي مش جدول ساعات عمل، ولا دليل على عدد أفراد الفريق. هي خريطة للقرارات اللي نقدر نرجع لها في المصدر، مع الحفاظ على الفرق بين الالتزام المسجل والتعديل المحلي والإصدار المنشور.

07 / الأدلة والنتيجة

النتيجة باينة في التفاصيل.

قدرات موثّقة

04أنواع طلبات07أدوار تشغيلية21لقطة موثقة

دي حقائق عن نطاق المنتج، مش نسب تحسّن تجارية. نتائج اختبارات التطبيق المذكورة تحت مرتبطة بتقارير سبتمبر.

الجودة بالأدلة، وحدودها مكتوبة

وزعنا التحقق بين اختبارات المجال، وتكامل قاعدة البيانات، ومكونات الواجهة، ومسارات المتصفح. الاختبارات بتركز على نتائج العمل: نقص مخزون، وإعادة طلب، وانتقال متزامن، ومرتجع، ودفعة، وصفحة فاتورة زائدة. وفي تقارير منفصلة للبناء والترحيلات والمراجعة المرئية.

تقرير ويندوز المؤرخ في 29 سبتمبر بيسجل 153 اختبارًا للخادم، و514 للواجهة، و208 اختبارات Vitest لتطبيق الموظفين، و32 فحصًا لسياسات بناء حزمة تطبيق ويندوز. تسليم المخزن المؤرخ في 30 سبتمبر بيسجل 517 اختبارًا للواجهة و153 للخادم، مع تحقق متصفح على أحجام مختلفة. الأرقام دي لنقاط مراجعة متداخلة، ومش بنجمعها في رقم كبير كأنها تشغيل واحد.

الأدلة المنشورة بتفرق بين جاهزية المصدر وجاهزية الجهاز الفعلي. إصدار الموقع والخادم موثق يوم 29 سبتمبر، وتحسينات المخزن الأحدث متحققة محليًا. حزمة ويندوز 0.1.5 لها أدلة بناء ومحتوى وتنزيل، لكن تشغيلها الفعلي واختبار الأجهزة والطباعة لسه لهم قبول منفصل. الصور كلها لواجهة عربية فاتحة؛ مافيش وضع داكن مثبت بالصور. وكمان مافيش أرقام موثقة عن عائد استثمار أو توفير ساعات، فمش هنخترع نتائج تجارية من عدد الاختبارات.

أسئلة بتوضح نطاق النظام

هل ده برنامج ERP شامل؟

النظام مركز على الطلبات والتصنيع والتجهيز والمخزون والتحصيل وتشغيل الموظفين حسب النطاق المعتمد. الدراسة مابتدّعيش وجود محاسبة عامة أو مرتبات أو مشتريات لمجرد إن المنتج فيه أرصدة ومبالغ.

هل الموقع العادي بيشتغل من غير نت زي تطبيق ويندوز؟

تطبيق ويندوز بيحفظ أوامر تشغيل مؤقتة بشكل دائم ويرجعها للخادم. المتصفح العادي عنده حفظ لبعض موارد التطبيق والمسودات، لكن ده مش نفس صلاحية إنشاء عمليات تجارية من غير اتصال. قبول الأوامر المؤقتة بيحصل عند المزامنة.

هل طلب الجهاز يدخل المصنع لو عليه باقي؟

لا. بيع الجهاز بيكمل من المخزون الجاهز، والمبلغ المتبقي بيتابع في السجل المالي. التصنيع والتجهيز خاصين بمسار التوصيل والجملة، وفق قواعد الطلب.

هل الصور بتعرض أحدث نسخة منشورة؟

الصور أرشيف مختار من أغسطس وسبتمبر، وكل صورة لها وصف وسياق في معرض الشاشات. صور المخزن الأحدث محلية، وبعض صور الأدوار أقدم. القاهرة الظاهرة في البيانات فرع تجريبي، ومش توثيقًا لمقر العميل الفعلي.

هل ينفع نشر الدراسة بالعربي والإنجليزي؟

أيوه. الحزمة فيها نسخة إنجليزية، ونسخة مصرية مهنية، ونسخة مصرية مرحة، بصور محلية وروابط بين النسخ. اتجاه العرض والنبرة يتغيروا، لكن حقائق المنتج وحدود الأدلة تفضل واحدة.

نبدأ من الشغل اللي فريقك بيعمله

تجربتنا في Hilton Kitchen بتوضح طريقتنا في Softworks: نفهم الفعل التجاري، ونحدد أثره على البيانات، ونصمم الواجهة اللي تساعد الموظف ينفذه، ونختبر اللي يحصل لما الطريق الطبيعي يتعطل. من ضغطة التأكيد لآخر صفحة فاتورة، التفاصيل مترابطة.

لو فريقك بيحاول يربط المبيعات بالمخزن والتصنيع والتحصيل، البداية المفيدة هي خريطة الشغل نفسها: الطلب بيبدأ إزاي، ومين يستلمه، وإيه المستند اللي لازم يخرج، وإيه الاستثناء اللي بيكرر تعبكم. من هنا نقدر نصمم نظامًا مخصصًا يعبر عن التشغيل بوضوح، وتفضل قراراته قابلة للفهم والتطوير مع احتياج العمل.

فريق هندسة البرمجيات في Softworks

من جوه المنتج

الشغل الحقيقي. شاشة بشاشة.

21 لقطة محفوظة من أغسطس وسبتمبر 2026: أدوار التشغيل، المخزن، التحصيل والطباعة. كل الصور عربية وبالمظهر الفاتح؛ الأوصاف بتوضح حالة الاختبار وتاريخ التصميم.

صور المنتج الأصلية، ببيانات عرض واختبار.

21 شاشة