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

نظرة عامة

نسخة النظام ليست نظامًا مشتركًا؛ إنها نظام بدأ يختلف عن النسخ الأخرى.

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

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

بنينا البديل: منصة واحدة يرتبط فيها كل سجل بمتجره، ويضبط المدير القواعد التجارية التي تهمه من الإعدادات بدل تعديل الكود، ويمرّ المستخدم بـ 6 فحوص مستقلة قبل أن يتمكن من طباعة عقد قانوني. وواصلت الأنظمة القديمة العمل طوال تلك الفترة.

التحديات

ست مشكلات يخفيها نظام لا يزال يعمل.

نسختان من نظام واحد أصبحتا نظامين مختلفين

كان نظام كل متجر يضم نحو 165 شاشة رئيسية وأكثر من 500 ملف برمجي. قارنّا جميع الملفات واحدًا واحدًا، فوجدنا 160 ملفًا مختلفًا: 135 ملفًا موجودة في النسختين لكن محتواها لم يعد متطابقًا، و25 ملفًا لا توجد إلا في إحداهما.

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

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

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

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

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

المستندات أساس العمل، لكن إعدادها كان عرضة للأخطاء

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

كانت إحدى أدوات إعداد هذه الحزمة صفحة واحدة تضم 1,758 سطرًا وتطبع 9 مستندات متتالية. أدّت الأداة عملها، واستمرت في ذلك سنوات.

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

أجهزة كمبيوتر مشتركة في صالة بيع مزدحمة

العمل هنا عند طاولة البيع في متجر، لا في مكتب. وتجتمع فيه ثلاثة ظروف:

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

لا تعالج شاشة تسجيل الدخول التقليدية أيًا من هذه المشكلات الثلاث. والمشكلة الثالثة تتعلق بالامتثال للضوابط، لا بسهولة الاستخدام.

بيانات المصدر تُنقل كما هي من إشعار التسليم

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

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

لا سجل يوضح من غيّر البيانات وما الذي غيّره

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

في معاملة بيع تخضع لضوابط تنظيمية، لا إجابة أسوأ من «لا نعرف».

ثلاثة أجيال · حزمة مستندات العقد

ملف حجمه 75,000 بايت أصبح صفر بايت

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

الجيل الأول

أداة مستقلة تضم 1,758 سطرًا.

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

الجيل الثاني

تسجيل دخول مشترك، مع بقاء نسخة مستقلة من النص.

أعدنا بناء الأداة للمتجر الثاني مع تنظيم مساراتها على نحو سليم. وكان التغيير الأهم أنها لم تعد مستقلة؛ بل اعتمدت تسجيل الدخول ومصفوفة الصلاحيات وقواعد الوصول إلى الصفحات في نظام الموظفين بدل الاحتفاظ بنسخ خاصة منها. فأصبح هناك مرجع أساسي واحد للبيانات يحدد صلاحيات كل مستخدم. لكن الأداة ظلّت تحتفظ بنسختها من نص العقد في ملف عرض حجمه 75,854 بايت.

الجيل الثالث

صفر بايت، عن قصد.

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

ثلاثة ملفات تختصر مسار التعاون كله.

1,758 سطرًا ← تسجيل دخول مشترك ← صفر بايت. أزلنا في كل جيل نسخة مكررة من أحد الأجزاء. ومع الجيل الثالث، لم تعد الشركة تحتفظ بأي نسخ مكررة من نص العقد.

وهناك وظيفة أخرى.

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

دراسة حالة ذات صلة: شبكة شفافية المورّدين

وجهة رمز الجلسة: ملف المورّد على الجهاز اللوحي.

ما بنيناه

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

الفصل الأول · الأنظمة القديمة

نظام الإدارة الداخلية الذي كان يدير المتجر

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

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

كان على النظام الجديد أن يحل محل هذا النظام. وبسبب حجمه، نفّذنا إعادة البناء على مراحل بدل محاولة إنجازها دفعة واحدة.

وكان يطبع أيضًا كل ما يستخدمه المتجر

• بطاقات الأقفاص، 4 في الصفحة
• بطاقات التعريف السريع، 16 في الصفحة
• استمارات الفحص
• استمارات الأدوية
• شهادات المصدر
• قسائم الخدمات البيطرية
• استمارات توصيات التأمين

الفصل الثاني · التوصية بخلاف الحل البديهي

قرار عدم دمج النسختين

يبدو دمج نسختين مختلفتين الحل البديهي. لكننا نصحنا بعدم دمجهما. فدمج نظامين اختلفا في 160 ملفًا ينتج نظامًا ثالثًا لا يثق به أحد، وتبقى فيه الافتراضات التي بُني عليها كل منهما.

أعدنا بناء الأساس بدلًا من ذلك. حصرنا البيانات التي تتعامل معها الشركة فعليًا، وأعدنا تنظيمها في 62 جدولًا واضح البنية في قاعدة البيانات.

البيانات التي تتعامل معها الشركة فعليًا

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

الفصل الثالث · تعدد الفروع جزء من التصميم

قرار التصميم الذي أتاح إدارة عدة متاجر

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

هذا القرار الواحد في تصميم نموذج البيانات هو ما يحوّل النظام إلى منصة. فلا يحتاج الكود إلى تحديد المتجر الذي يعمل له في كل مرة؛ إذ يحمل كل صف هذه المعلومة بالفعل.

الفصل الرابع · القواعد ضمن الإعدادات بدل الكود

نقلنا القواعد التجارية من الكود إلى الإعدادات

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

أصبح من الممكن إضافة متجر عاشر دون أي تعديل في الكود.

الفصل الخامس · التحقق من مصدر التوريد

التحقق من المصدر بالرجوع إلى السجل الوطني

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

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

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

دراسة حالة ذات صلة: منصة رصد أسعار المنافسين وتحليلها

مصدر السجل الذي يعتمد عليه هذا البحث.

شرح تقني مفصّل · نموذج الأمان

نموذج الأمان من الداخل: ستة فحوص في صالة البيع

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

الفحص الأول

اسم المستخدم يتضمن المتجر.

يسجّل الموظف دخوله بصيغة name@store. فالمتجر جزء من بيانات تسجيل الدخول، ولا يختاره الموظف من قائمة منسدلة قد يخطئ فيها.

الفحص الثاني

التحقق من ارتباط الموظف بالمتجر.

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

الفحص الثالث

التحقق من الجهاز.

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

الفحص الرابع

التحقق من كلمة المرور.

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

الفحص الخامس

عامل تحقق ثانٍ.

رمز يعتمد على الوقت من Google Authenticator، أو رمز يُستخدم مرة واحدة ويرسله النظام عبر SMS.

الفحص السادس

قفل الشاشة.

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

وللاستثناء إجراءات محددة، لا منفذ لتجاوز الأمان.

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

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

كيف نعمل

ثماني قواعد لاستبدال نظام لا تستطيع الشركة إيقافه.

اقرأ النظام كاملًا قبل استبدال أي جزء منه

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

عارض الخطة البديهية حين تكون خاطئة

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

صمّم نموذج البيانات قبل تصميم أي شاشة

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

اجعل المتجر جزءًا من السجل نفسه، لا شرطًا في الاستعلام

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

الشركة هي صاحبة القرار في قواعدها التجارية

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

الأمان أول ما نبنيه، لا آخره

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

لا توقف عمل المتجر

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

سجّل من أجرى التغيير

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

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

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

التطبيق

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

• PHP 8.0
• Laravel 9.19

الواجهة

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

• Vue 3
• Inertia
• Vite
• Pinia

البيانات

قاعدة البيانات المرجعية تضم 62 جدولًا، ويرتبط كل صف فيها بمتجره.

• MySQL

عامل التحقق الثاني

عامل تحقق ثانٍ عند تسجيل الدخول: تطبيق مصادقة يُعَدّ بمسح رمز، أو رموز تُستخدم مرة واحدة عبر SMS للموظفين الذين لا يستخدمون التطبيق.

• Google Authenticator (TOTP)
• الإعداد بمسح رمز QR
• Twilio

البريد الإلكتروني

تنبيهات النظام ورسائل الحسابات، مع تتبّع وصول الرسائل فعليًا.

• Postmark

العناوين

البحث عن العناوين والتحقق منها، لإدخال العنوان مرة واحدة بصورة صحيحة.

• Loqate

سجل التراخيص

سجلات محدّثة باستمرار للمربّين والتجار والناقلين المرخّصين من السجل الوطني.

• منصة CompertMe لمعلومات السوق

الأنظمة القديمة

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

• تطبيق PHP مخصص بنمط MVC
• FastRoute
• mPDF
• PHPSpreadsheet
• Chart.js

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

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

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

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

الخطوة 1

تسجيل الدخول

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

الخطوة 2

الابتعاد عن الجهاز

يقفل النظام الشاشة ويحميها برمز PIN من 4 أرقام. ويعود الموظف خلال ثانية أمام العميل، دون إدخال كلمة مرور.

الخطوة 3

وصول حيوان إلى المتجر

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

الخطوة 4

المدير يتحقق من السجل

يعتمد المدير السجل الذي كان قيد التحقق، ويسجّل جدول التدقيق المستخدم الذي اعتمده ووقت الاعتماد.

الخطوة 5

استكمال السجل الطبي

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

الخطوة 6

إتمام البيع

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

الخطوة 7

إقفال الأسبوع

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

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

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

وفي الخلفية، يحدد المدير المورّدين المعتمدين، وطرق الدفع المقبولة، والرسوم، والإعفاءات الضريبية، وصلاحيات الموظفين لكل متجر من الإعدادات، دون تعديل الكود.

النتائج

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

تعديل واحد يسري في كل مكان

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

افتتاح متجر دون الحاجة إلى مطوّر

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

تحديد الشروط التجارية مباشرة

نقلنا شرائح العمولات ورسوم المتاجر من الكود إلى شاشة يتحكم فيها المدير.

إثبات مصدر كل حيوان

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

معرفة من غيّر البيانات ومتى

يحفظ جدول التدقيق هوية من غيّر حالة السجل من «قيد التحقق» إلى «تم التحقق منه».

منع إنشاء العقود لمن لا يملك تصريحًا، أو من مكان أو جهاز غير معتمد

6 فحوص مستقلة، مع تنبيه عند الإخفاق في أهمها.

منح صلاحية الوصول من خارج المتجر بأمان

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

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

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

التطوير بالأرقام

• 160 ملفًا اختلفت بين نسختَي المتجرين
• 543 ملفًا برمجيًا حصرناها قبل بدء إعادة البناء
• 62 جدولًا في قاعدة البيانات ضمن النموذج الجديد
• 23 جدولًا للربط في النموذج
• 16 من جداول الربط تربط السجل بمتجره
• 56 شاشة في التطبيق الجديد
• 54 مكوّنًا مشتركًا للواجهة
• 193 شاشة في النظام القديم الذي ما زال يدير المتجر
• 11 قالبًا لمستندات قابلة للطباعة في الأنظمة القديمة
• 6 فحوص مستقلة قبل السماح بطباعة عقد
• 9 مستندات قانونية ينشئها إجراء واحد
• 1,758 سطرًا في أداة إعداد العقود الأصلية
• 0 بايت في الأداة البديلة من الجيل الثالث

توضيح لحالة النظام

الأساس يعمل فعليًا، ونواصل نقل بقية الأنظمة إليه.

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

في بيئة الإنتاج · نواصل توسيع نطاقه

لم تحل المنصة الجديدة محل النظام القديم بعد

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

ما تغطيه المنصة الجديدة

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

ما زال على النظام القديم ولم تشمله المنصة بعد

• مسار المبيعات
• سجلات العملاء
• محرّك إعداد العقود والمستندات
• تقارير نهاية اليوم
• كشوف العمولات
• الرواتب

انتهى الدعم

الإصدارات المستخدمة أصبحت قديمة

كان آخر تعديل على الكود الذي استخرجنا منه أرقام هذه الصفحة في مايو 2023. وانتهى الدعم الأمني لإصدار PHP 8.0 في نوفمبر 2023، ولإصدار Laravel 9 في فبراير 2024، أي إن التقنيات الأساسية للمنصة لم تعد تتلقى الدعم منذ أكثر من عامين. هذا وصف لنسخة من الكود في وقت محدد، وليس انتقادًا للعميل.

أعمال ذات صلة

جميع الأعمال

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

هل تدير شركتك باستخدام نسخ من النظام لم تعد متطابقة؟

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

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