برنامج إدارة محطة الحاويات وخطوط الشحن: دخول وخروج البوابة والساحة والتعريفات والفواتير

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

المرجع هنا هو ShipYard Pro، لوحة تحكم متعددة المستأجرين (multi-tenant) لساحات الحاويات وخطوط الشحن بالعربية والإنجليزية. استغرق بناؤها خمسة أسابيع وحلّت محل واجهة قديمة بأسلوب ASP.NET. سأشرح الوحدات وقرارات نمذجة البيانات وكيف تختار بين النظام المخصص والأنظمة المؤسسية.

ماذا يفعل برنامج إدارة محطات الحاويات وخطوط الشحن؟

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

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

• البيانات الأساسية: الوكلاء والعملاء والسفن والموانئ وأنواع الحاويات والسلع والمقاولون والمعدات.
• العمليات: الحجوزات والتخصيصات وحركات البوابة ونقل الحاويات وحجبها وفك الحجب.
• الفلوس: تعريفات التخزين وتعريفات الخدمات والفواتير والإشعارات الدائنة.
• الرقابة: الأدوار والصلاحيات وسجل التدقيق وتتبع رسائل EDI.

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

كيف تعمل عمليات دخول وخروج البوابة للوكلاء والعملاء؟

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

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

الشاشة الجيدة تفعل ثلاثة أشياء: تمنع تكرار رقم الحاوية داخل الساحة، وتسجّل الحجم والنوع عند الدخول (20 أو 40 قدم، عادي، مبرّد...)، وتختم الوقت في الاتجاهين حتى لا تُخمَّن أيام التخزين لاحقًا. في شاشات البوابة داخل ShipYard Pro يظهر حجم كل حركة ونوعها بوضوح لأنهما يحددان موضع الحاوية والسعر.

كيف تُنمذج الحجوزات والتخصيصات وبلوكات الساحة؟

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

أفصل هذه المفاهيم في جداول مستقلة بدل سجل حاوية واحد ضخم:

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

كيف تتحول تعريفات التخزين والأيام المجانية والخدمات إلى فواتير؟

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

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

أمور تستحق التصميم المبكر:

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

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

ما الأدوار والصلاحيات التي يحتاجها نظام الساحة؟

الإجابة المختصرة: صلاحيات لكل وحدة ولكل إجراء: عرض وإضافة وتعديل وحذف، تُمنح لمجموعات مستخدمين وتُفرض في الصفحات ومسارات الـ API معًا.

موظف البوابة يسجل الحركات لكن لا يعدّل التعريفات. والمحاسب يعتمد الفواتير لكن لا يحذف سجلات البوابة. النظام القديم الذي استبدلته كان له قاعدة مختلفة تقريبًا في كل شاشة، فكان من الصعب فهمه. في ShipYard Pro استخدمت مجموعات مستخدمين بأربعة أعلام (عرض، إضافة، تعديل، حذف) لكل وحدة ونموذج، تُدار من شاشة الأدوار وتُفحص في الواجهة والـ API معًا. إخفاء زر ليس أمانًا؛ مسار الـ API يجب أن يرفض الطلب. وسجل التدقيق يوثق من غيّر ماذا.

وإذا كان عدة مشغّلين يشتركون في نشر واحد، يُضاف عزل المستأجر: كل شيء مرتبط بمؤسسة وفرع، فلا ترى شركة (أ) حاويات شركة (ب). هذا هو معنى multi-tenant عمليًا، ويجب أن يكون في نموذج البيانات من اليوم الأول لا إضافة لاحقة.

كيف بنيت ShipYard Pro؟

الإجابة المختصرة: Next.js 16 للوحة التحكم، وPostgreSQL مع Prisma لنطاق من 45 نموذجًا، ومسارات API يتحقق منها Zod، وNextAuth لتسجيل الدخول وnext-intl للعربية والإنجليزية.

التحدي الرئيسي كان إبقاء أكثر من 40 نموذجًا مترابطًا منظمًا مع واجهة سريعة وبسيطة. أهم القرارات:

• مخطط Prisma كعقد واضح. المؤسسات والفروع والحاويات والحجوزات والتخصيصات وحركات البوابة والنقل والتعريفات والفواتير والإشعارات الدائنة ورسائل EDI في مخطط واحد مُنمَّط.
• قسم لكل وحدة في App Router، مع مسارات API يتحقق منها Zod حتى لا تصل بيانات سيئة لقاعدة البيانات.
• جدول بيانات واحد قابل لإعادة الاستخدام (TanStack Table) بفلاتر وإظهار/إخفاء أعمدة وتصدير، مستخدم في أكثر من 50 صفحة. هذا وفّر وقتًا كبيرًا وضمن اتساق الشكل.
• ثنائية اللغة من البداية. عربي وإنجليزي مع اتجاه RTL عبر next-intl. عكس الجداول والنماذج والرسوم أسهل حين يكون RTL أساسًا لا إضافة متأخرة.
• لوحة التحكم وعرض الساحة. نشاط البوابة والفواتير وإشغال الساحة برسوم Recharts، وعرض لكل بلوك.

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

نظام مخصص أم TOS مؤسسي: أيهما يناسب ساحة صغيرة أو متوسطة؟

الإجابة المختصرة: اختر TOS المؤسسي للعمليات الكبيرة متعددة المحطات التي تحتاج ربطًا بالرافعات وبوابات آلية وتخطيطًا معقدًا. واختر نظامًا مخصصًا خفيفًا حين تكون حاجتك الأساسية سجلات البوابة ورؤية الساحة والتعريفات والفواتير، وتريد سير عمل يطابق طريقة فريقك الحالية.

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

كم تكلفة البناء وكم يستغرق؟

الإجابة المختصرة: النسخة الأولى المركّزة (البوابة والساحة ونوع تعريفة واحد والفواتير والأدوار) تناسب نطاق الـ MVP الذي أبيعه بـ 2,499 دولارًا خلال 21 يومًا؛ أما نظام أوسع مثل ShipYard Pro بأكثر من 50 صفحة و45 نموذج بيانات فاستغرق خمسة أسابيع ويُسعَّر بعد تحديد النطاق.

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

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

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