تطوير Laravel في جدة للتجزئة والتوزيع

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

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

الدفع بعد التسليم في جدة دورة حياة لا علامة

في النظام المدفوع مقدمًا يكون حدث الدفع وحدث الطلب متقاربين إلى حد يجعل القيمة المنطقية كافية تقريبًا.

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

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

مخزون Laravel يجب أن يُحرَّر لا أن يُحجَز فقط

النتيجة الثانية تتبع مباشرة وتسبب ضررًا أكبر.

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

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

عروض جدة تمشي على تقويم قمري

هذه التفصيلة المحلية التي تنتج أجوبة خاطئة بهدوء، ولا تحلها مكتبة بمفردها.

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

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

مطابقة ما حصّله مندوب التوصيل في جدة مع ما كان مستحقًا

الدفع عند التسليم يعني أن طرفًا ثالثًا يحتفظ بالمال أيامًا، ومطابقة ذلك عملٌ محاسبي حقيقي لا سكربت استيراد.

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

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

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

مخزون Laravel في عدة مواقع في جدة

ما إن يصبح للمخزون أكثر من مكان، يتوقف التوفر عن أن يكون رقمًا ويصبح سؤالًا عن أي مكان.

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

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

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

تجاريًا

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

الفاتورة من Codefacture Yazılım A.Ş. في تركيا، بالدولار الأمريكي، عبر حوالة بنكية، دون ضريبة قيمة مضافة تركية لأن الخدمات المصدَّرة معفاة.