تخطَّ إلى المحتوى
أعمال ودراسات حالة
لوحة تحكم

Altahdi System

نظام ERP عربي أولًا فوق Laravel وMySQL، نقل الفواتير والقيود والرواتب والتقارير من الورق وExcel إلى تشغيل يومي داخل منصة واحدة.

20 أسبوعًا · 2025
Altahdi System — غلاف المشروع
الدور
قيادة تقنية · معمارية النظام · تسليم مع فريق DevSparks
الخدمات
معمارية نظام ERP/POS · تصميم UI/UX عربي RTL · API بـ Laravel وMySQL · تطوير React 19 + Redux · تقارير ورسوم مالية وتصدير Excel/CSV · وحدة رواتب وحضور · صلاحيات ومصادقة وإشعارات FCM
التقنيات
React 19 · Laravel · MySQL · TypeScript · Redux Toolkit · MUI · Recharts · Firebase FCM
العميل
شركة التحدي
المجال
خدمات رجال الأعمال
المدة الزمنية
20 أسبوعًا · 2025

01 / سياق العمل

المشكلة المطلوب حلّها

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

Altahdi System نظام ERP بُني لشركة التحدي لخدمات رجال الأعمال، بعد اعتماد عملياتها على الورق وExcel. يجمع النظام دورة العمل المالية من الفاتورة عند الاستقبال إلى القيود اليومية وتقارير الضرائب والرواتب، داخل واجهة صُممت بالعربية أولًا، وفوق Laravel API وقاعدة MySQL تحفظان السجل المالي للشركة. وتخدم المنصة ثلاثة مستويات من المستخدمين: المدير، وموظف الاستقبال، والموظف، بصلاحيات محددة لكل مستوى.

02 / من النطاق إلى الإطلاق

كيف تحرّك العمل؟

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

05 خطوات

  1. خطوة 01

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

  2. خطوة 02

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

  3. خطوة 03

    صممنا الواجهة المالية باتجاه RTL منذ الشاشة الأولى، بمصطلحات محاسبية عربية واضحة، وجداول بيانات معكوسة، ونظام تصميم قائم على MUI أُعيد استخدامه عبر وحدات التشغيل.

  4. خطوة 04

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

  5. خطوة 05

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

03 / القرارات التي شكّلت المنتج

قرارات المنتج الأساسية

القرار 01

واجهة عربية أولًا، لا ترجمة لاحقة

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

نظام ERP واحد بدل أدوات متفرقة

سياق العمل
كان من الممكن فصل الفوترة والقيود المحاسبية والرواتب والتقارير في أدوات مختلفة، لكن المشكلة الأساسية كانت تشتت البيانات المالية بين الفواتير المكتوبة يدويًا والسجلات وملفات Excel.
القرار
بنينا منصة واحدة تتشارك فيها فواتير POS والقيود اليومية والرواتب والتقارير مخطط MySQL واحدًا وLaravel API واحدًا ونموذج صلاحيات موحّدًا.
لماذا
ربط الوحدات في نموذج علائقي واحد يعني أن فاتورة الاستقبال تغذي القيود والتقارير والرسوم مباشرة، وتقلّل الحاجة إلى إعادة إدخال البيانات بين الأدوات.
القرار 03

القواعد المالية في الخادم، لا في الواجهة

سياق العمل
كان يمكن احتساب الإجماليات والرسوم الحكومية لكل بند والخصومات والضرائب والرواتب داخل واجهة React، وهو أسرع في التنفيذ لكنه يضع المنطق المحاسبي للشركة في المتصفح.
القرار
أبقينا كل عملية حسابية مالية وكل تغيير في الحالة داخل Laravel API، مع كتابة الفاتورة وقيدها المحاسبي ضمن معاملات قاعدة بيانات واحدة، على أن تعرض الواجهة النتائج لا أن تشتقها.
لماذا
المحاسبة يجب أن تكون قابلة لإعادة الإنتاج ومتسقة: وجود تنفيذ مرجعي واحد يمنع اختلاف التقرير عن فاتورة الـ PDF عن الرقم الظاهر على الشاشة، ويمنع بقاء الدفاتر غير متوازنة عند توقف عملية في منتصفها.
القرار 04

ثلاث مستويات صلاحيات بمسارات محمية

سياق العمل
يتعامل المدير والاستقبال والموظفون مع أجزاء من البيانات المالية نفسها، لكنهم لا يحتاجون إلى الرؤية أو الصلاحيات ذاتها. وكان تسجيل الدخول المشترك سيكشف معلومات الرواتب والماليات لغير أصحابها.
القرار
نفذنا ثلاث مستويات صلاحيات — مدير وموظف استقبال وموظف — مطبّقة داخل Laravel API ومعكوسة كمسارات محمية في الواجهة، مع إشعارات Firebase Cloud Messaging لحظية.
لماذا
يتيح ذلك لموظف الاستقبال إصدار الفواتير، مع حصر الرواتب والتحليلات المالية في الأدوار المناسبة، بما يعكس توزيع المسؤوليات داخل الشركة — وتطبيق الصلاحية على مستوى الـ API يعني أن إخفاء الشاشة ليس هو الحاجز الوحيد أمام بيانات الرواتب.

04 / المنتج أثناء الاستخدام

واجهات حقيقية عبر تجربة العميل والتشغيل.

لقطة شاشة من نظام الـ ERP الخاص بـ Altahdi System
Altahdi Systemلقطة من المنتج 1
لقطة شاشة لواجهة Altahdi System المصممة عربي-أولاً
Altahdi Systemلقطة من المنتج 2
لقطة شاشة أخرى من نظام الـ ERP الخاص بـ Altahdi System
Altahdi Systemلقطة من المنتج 3

05 / كيف تم بناؤه؟

قرارات هندسية

  • Laravel API فوق مخطط MySQL يغطي العملاء وكتالوج الخدمات والفواتير وبنودها والقيود اليومية والحضور ودورات الرواتب، كسجل مالي واحد خلف كل وحدة في النظام.

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

  • واجهة React 19 مكتوبة بـ TypeScript، مع إدارة حالة مقسمة إلى وحدات Redux Toolkit ومسارات تشغيل واضحة حسب المجال.

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

  • تقارير قابلة للفلترة للإيرادات والمصروفات والخدمات والضرائب والرواتب والمديونيات، معروضة من خلال جداول بيانات قابلة لإعادة الاستخدام وتقسيم الصفحات، مع تصدير أي عرض مفلتر إلى Excel أو CSV مباشرة من الشاشة.

  • غرفة تحليل مالي تتضمن عروض Recharts للسيولة والمصروفات وهامش الربح وأعمار المديونيات والضرائب واتجاهات مؤشرات الأداء.

  • أدوار مدير وموظف استقبال وموظف مطبّقة داخل Laravel API ومعكوسة كمسارات محمية في الواجهة، مع إشعارات Firebase Cloud Messaging لحظية.

06 / ما الذي تغيّر؟

النتيجة التي تم تسليمها

  • يغطي النظام المُسلَّم 61 شاشة تشمل الفوترة والقيود اليومية والرواتب والتقارير وإدارة الصلاحيات.

  • أصبح فريق التحدي يستخدم النظام لإصدار فواتير PDF وإدارة القيود اليومية ضمن مسار رقمي موحّد.

  • كل فاتورة ومصروف وقيد ودورة رواتب محفوظة في قاعدة بيانات علائقية واحدة بدل توزّعها بين الورق وملفات Excel منفصلة.

  • يجمع مسار الرواتب بيانات الحضور والمكافآت والخصومات بدل إعادة تجميعها يدويًا في كل دورة.

  • تمنح لوحات التحليل الإدارة قراءة مباشرة للمؤشرات المالية الأساسية بدل انتظار تجميع تقارير نهاية الشهر.

  • الخروج من ملفات Excel لم يعنِ فقدانها: أي تقرير يُصدَّر إلى Excel أو CSV للمحاسب الخارجي أو لطلب مراجعة أو لإقرار ضريبي، بلا إعادة إدخال للأرقام.

  • نُقل الجزء الأساسي من دورة العمل من الورق والجداول إلى نظام واحد، مع تسليم الوحدات ومراجعة التدفقات تدريجيًا مع الفريق.

كل فاتورة ومصروف ومرتب في الشركة بقى في نظام واحد — أخيراً بنشوف أرقامنا لحظة بلحظة.

فريق التحدي

خدمات رجال الأعمال

هل تواجه تحديًا مشابهًا في منتجك؟

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