تخطَّ إلى المحتوى
→ حسين الحسن

Autro

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

محلل أعمال ومطوّر Full Stack · TRICYCLE PRODUCTOS SL · 2023 – 2026

autro-tricycle.tech
عملية تجارية
64عملية تجارية
نوعاً من المستندات يُولَّد آلياً
13نوعاً من المستندات يُولَّد آلياً
دول
8دول
شهراً في الإنتاج
12+شهراً في الإنتاج

المشكلة

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

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

أين كانت الصعوبة

لم تكن المشكلة في الأوراق نفسها، بل في أن الشحنة ليست كياناً واحداً.

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

يستطيع Excel حفظ كل ذلك، لكنه لا يفرض قواعد العمل.

القرارات

نمذجة العملية لا المستند

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

تحديد دورة الحياة (Lifecycle) بوضوح

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

حفظ العملة مع السجل

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

إعادة البناء بدل الترقيع

بنى حسين النسخة الأولى على Flutter وLaravel مع فريق من خمسة، وربطها بواجهة WhatsApp Business API، وكانت تعمل. لكن قواعد النظام اتضحت أثناء البناء لا قبله. كتب حسين المتطلبات كاملة — بما فيها نموذج المجال (Domain Model)، وآلات الحالة (State Machines)، وقواعد العمل — ثم أعاد بناء النظام من الصفر على React وTypeScript وtRPC وDrizzle وMariaDB.

ما تغيّر

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

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

ما تعلّمه منه

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

وبناء ما وصفه حسين بنفسه غيّر طريقته في التوصيف. والقاعدة التي يصعب تنفيذها تكون غالباً قاعدة لم تُوصف بدقة.