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

نظرة عامة

لم يكن لدى الشركة نظام يؤدي هذه المهمة. فبنينا لها المنصة التي تحتاجها.

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

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

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

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

التحديات

سبع مشكلات، وأصعبها لم يدوّنها أحد من قبل.

توقيع العقد مرهون بنظام لم يكن موجودًا بعد

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

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

قواعد امتثال لم يدوّنها أحد

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

رمز الحالة الخاطئ له تبعات تجارية تتجاوز خطأ الكتابة

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

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

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

رحلة واحدة، وآلاف الطرود، وتحديث لكل طرد

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

مستندات جمركية موزّعة على خوادم عبر الإنترنت

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

حسابات بعملتين وفي اتجاهين

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

قد لا يُذكر فرق التقريب في طرد واحد. لكن تكراره على شحنات شهر كامل يترك عجزًا في الحسابات.

نظام خارجي يخفي إخفاقاته

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

من اليوم 1 إلى اليوم 7 · عقد الشراكة

الأسبوع الذي أتاح توقيع العقد

كان نمو أعمال العميل يتوقف على توقيع واحد، وكان التوقيع يتوقف على نظام لم يكن موجودًا بعد.

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

يستغرق بناء واجهة API موثّقة لبيئة الإنتاج شهرًا في الظروف المعتادة. ولم يكن لدى العميل شهر ينتظره.

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

الأمان أولًا، ثم ثماني عشرة نقطة نهاية في بيئة الإنتاج.

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

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

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

وأصبح ذلك نهجنا في بقية المشروع.

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

ما بنيناه

ثمانية أشهر من التطوير، حسب أولويات العمل.

الفصل الأول · 2025 · أسبوع واحد للوصول إلى بيئة الإنتاج

التكامل قبل أي شيء آخر

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

الفصل الثاني · أواخر 2025 · نموذج البيانات

تمثيل العمليات داخل النظام

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

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

الفصل الثالث · نهاية 2025 · ثلاث وحدات في ستة أسابيع

الحسابات المالية

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

الفصل الرابع · مطلع 2026 · جوهر المنصة

تحويل دليل القواعد إلى نظام

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

الفصل الخامس · أوائل 2026 · تعديلات تُطلق في اليوم نفسه

القواعد تتغيّر، والمنصة تواكبها

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

أطلقنا كل تعديل من هذه التعديلات في يوم الاتفاق عليه، ولم يتطلب أيّ منها تعديل المحرك.

طوال المشروع

ثوابت لم تتغيّر

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

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

شرح تقني معمّق · محرك الحالات

داخل دليل القواعد: محرك الحالات

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

لم تكن المشكلة مجرد إدخال بيانات

قائمة منسدلة تنطوي على مخاطر تجارية.

بدأنا بتدوين القواعد التي يعرفها الموظفون، وكان ذلك أصعب جزء.

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

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

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

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

ما كشفه توثيق القواعد

• 40 رمز حالة — جميع الحالات، برموز الشريك نفسه.
• 17 خطوة مرتّبة — عبر دورتَي حياة مختلفتين: مسار أول، ومسار مختلف يتكرر مع كل جولة لإعادة التوصيل.
• 120+ قاعدة مستقلة — أعداد أحصيناها ولم نقدّرها: 62 موضعًا مسموحًا للحالات، و60 قاعدة سلوكية، كلها في ملف إعدادات واحد.

لا يمر الطرد بهذه الخطوات في مسار خطّي ثابت.

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

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

كيف تظهر هذه القواعد لموظف العمليات؟

وتكون النتيجة واجهة شديدة البساطة.

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

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

يعيد المحرك تتبّع سجل الحالات كاملًا في كل مرة.

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

كيف يصمد المحرك عندما يتبيّن أن قواعده خاطئة؟

اعتمد العميل دليل القواعد قبل أن نكتب المحرك، واستمر في مراجعته بعد بدء العمل به. وقد صمّمنا المحرك ليستوعب ذلك.

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

طريقة عملنا

ثماني قواعد، وموضع واحد تمهّلنا فيه.

حدّد ما يعطّل العمل وابدأ به

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

واكب حاجة العميل الملحّة طوال المشروع، لا في الأسبوع الأول وحده

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

اكتب المواصفات بلغة العميل، لا بلغتنا

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

غيّر الإعدادات دون إصدار جديد

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

حافظ على سلامة الشحنات التي بدأت رحلتها

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

افترض أن النظام الذي تعتمد عليه سيعطيك نتيجة مضلّلة

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

نفّذ في الخلفية كل عملية بطيئة أو خارجية أو مقيّدة بمعدل طلبات

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

تمهّل في موضع واحد: ما يؤدي خطؤه إلى إفساد كل ما بعده

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

التقنيات المستخدمة

تسع طبقات، ووظيفة كل منها.

التطبيق

تقنيات ناضجة تحظى بدعم طويل الأمد، ويتوفر عدد كبير جدًا من المطوّرين للعمل بها. فلا يضطر العميل إلى إعادة كتابة التطبيق بعد 3 سنوات.

• PHP 8.2
• Laravel 12

الواجهة

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

• Vue 3
• Inertia 2
• Tailwind
• Vite
• Pinia

محرك الامتثال

نغيّر قواعد العمل بتعديل ملف إعدادات، دون إعادة كتابة الكود. أطلقنا 4 تعديلات طلبها الشريك خلال 2026، كلًا منها في يوم الاتفاق عليه، دون تعديل كود المحرك.

• آلة حالات تعتمد على الإعدادات
• أكثر من 120 قاعدة في ملف إعدادات واحد

البيانات

دورة حياة الطرد كاملة: الرحلات، والأكياس، والطرود، والأصناف، والمرسَل إليهم، والسجلات الزمنية، والرسوم، والتسعير، وسجلات التدقيق.

• MySQL
• 27 جدولًا
• 46 تغييرًا في بنية قاعدة البيانات

العمليات في الخلفية

تجري التحديثات الجماعية، ومحاولات جلب الفواتير المتكررة، وكتابة سجلات التدقيق في الخلفية، وتعرض لوحة تحكم العمليات الجارية والعمليات التي أخفقت، مع تحديث مستمر.

• Redis
• Laravel Horizon
• مهام في طابور المهام

التكامل مع الشريك

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

• Laravel Sanctum
• رموز وصول قابلة للإلغاء
• حدود معدل طلبات بمستويات مختلفة
• توثيق مولّد تلقائيًا
• أداة اختبار داخل المتصفح

المستندات والتخزين

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

• AWS S3
• تجميع الملفات بصيغة ZIP
• روابط مؤقتة موقّعة

التحكم في الوصول

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

• Jetstream
• Fortify
• المصادقة الثنائية
• التحقق من البريد الإلكتروني
• الصلاحيات حسب الدور

المراقبة

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

• Laravel Pulse
• تسجيل كامل للطلبات الواردة والصادرة

الاختبارات الآلية

تتحقق الاختبارات الآلية من كل تغيير قبل وصوله إلى بيئة الإنتاج.

كيف تعمل المنصة

سبع خطوات، من استقبال بيانات رحلة عبر واجهة API إلى طرد يستطيع العميل تتبّعه.

الخطوة 1

استقبال الشحنة

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

الخطوة 2

استكمال البيانات

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

الخطوة 3

التخليص الجمركي

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

الخطوة 4

تحديث الحالات وفق القواعد

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

الخطوة 5

تحديث الحالات جماعيًا

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

الخطوة 6

الحسابات

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

الخطوة 7

إتاحة التتبّع

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

النتائج

ما تستطيع الشركة إنجازه الآن، ولم تكن تستطيعه في سبتمبر 2025.

توقيع العقود بناءً على إصدارات جاهزة للاستخدام

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

تطبيق مسار امتثال من 120 قاعدة دون حضور متخصص

تضبط المنصة مسار الحالات عبر 40 رمز حالة و17 خطوة ودورتَي حياة، وتفرض جميع القيود الزمنية وقيود الصلاحيات، بدلًا من الاعتماد على ذاكرة الموظف.

منع إرسال بيانات خاطئة إلى الشريك ومن بعده

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

تحديث رحلة كاملة بإجراء واحد

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

تقديم مستندات مكتملة للجمارك عند الطلب

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

معرفة ما أُرسل وما ردّ به الشريك

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

تعديل قواعدها التجارية بنفسها

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

استيعاب تغيّر قرارات الجهة التنظيمية أو الشريك

نفّذنا 4 تغييرات في مسار الحالات خلال 2026، وأصبح كل منها يعمل فعليًا في يوم الاتفاق عليه، دون أن يتطلب أيّ منها تعديل كود المحرك.

تمكين العملاء من معرفة حالة طرودهم بأنفسهم

يتيح موقع عام للتتبّع للعميل البحث عن طرده دون الاتصال بأحد.

إصدار الفواتير من النظام الذي يدير العمليات

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

العمل الهندسي بالأرقام

• 120+ قاعدة امتثال مستقلة برمجناها داخل النظام
• 40 رمز حالة يخضع لقواعد المنصة
• 17 خطوة مرتّبة عبر دورتَي حياة
• 62 موضعًا مسموحًا للحالات
• 19 / 19 قيود تقصر الصلاحية على المدير / قواعد تجميد تلقائي
• 7 قيود للتاريخ والوقت وأيام العمل
• 41 من 125 عملية حفظ للتغييرات مسّت محرك الامتثال
• 18 نقطة نهاية موثّقة في واجهة API للشريك
• 11 وحدة تشغيلية
• 27 نوعًا من السجلات يحفظها النظام
• 46 تغييرًا في قاعدة البيانات طبّقناه دون انقطاع الخدمة
• 100 شاشة ومكوّن في Vue
• 3 / 14 أنواع مهام في الخلفية / أوامر صيانة
• 200 كيس تدعم المنصة معالجته ضمن دفعة واحدة لكل رحلة
• 58 يومًا من العمل الفعلي على تطوير المنصة وتسليمها خلال المشروع
• ~30,000 سطر من كود التطبيق

وضع المشروع كما نعرفه

يعود تاريخ آخر عملية حفظ للتغييرات في المستودع إلى 20 مايو 2026، لذا تصف هذه الصفحة عملنا في المشروع بصيغة الماضي.

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

أعمال ذات صلة

جميع الأعمال

الخطوة التالية

هل يتوقف عقدك القادم على نظام لم يُبنَ بعد؟

اعمل مع فريق هندسي يحدد ما يعطّل أعمالك ويبدأ ببناء الحلّ، ثم يتمهّل في موضع واحد فقط: القواعد التي يعتمد عليها كل ما عداها.

احجز مكالمة استكشافية