قواعد إعادة الطلب: متى يقترح التطبيق الشراء ومتى يسمح له بالتنفيذ؟
التنبيه إلى انخفاض المخزون ليس عملية شراء معتمدة. قبل إضافة التزويد التلقائي، حددوا النتيجة المطلوبة، والتوقع الذي تعتمد عليه، ومن يملك صلاحية إلزام المؤسسة بطلب شراء. ابدؤوا باقتراحات قابلة للمراجعة ما لم تكن لديكم قواعد واضحة للشراء دون تدخل بشري.
هذه توصية لتخطيط المشروع، وليست حكماً بأن الأتمتة لا تناسب المؤسسات الصغيرة. السؤال المهم هو ما يسمح للتطبيق بفعله حين يتوقع نقصاً في البضاعة.
وضحوا التوقع بدلاً من الاكتفاء بكمية الرف
قد تبقى السلعة في المستودع لكنها مخصصة بالفعل لطلبات عملاء. وقد تغطي شحنة واردة النقص المتوقع، بشرط وصولها في الوقت المناسب. اطلبوا عرض الكميات والمواعيد التي يقوم عليها كل اقتراح شراء، بما في ذلك طريقة التعامل مع الوارد المتأخر.
يصف دليل Odoo الرسمي لقواعد إعادة الطلب قواعد للمنتج والموقع، بحد أدنى وحد أعلى، مع الاعتماد على المخزون المتوقع في تشغيل التزويد. هذا نهج خاص بمنتج محدد. يجب أن يوضح موجز مشروعكم أيضاً المدى الزمني للتوقع والطلب المحتسب والوارد الذي يجوز الاعتماد عليه.
تجنبوا احتساب كل مسودة استفسار للمورد ضمن البضاعة المتاحة. اتفقوا على مرحلة الشراء التي تدخل في الحساب، وعلى أثر تغير موعد الوصول. لا ينبغي أن يخفي التوقع مشكلة تأخر التوريد بجمع الكميات من دون مراعاة مواعيدها.
افصلوا بين حد التشغيل والهدف ومضاعف الشراء
الحد الأدنى يطلق مراجعة الحاجة. والهدف يحدد المستوى المراد استعادته. أما مضاعف الشراء فيحدد الكميات التي يقبل المورد بيعها. هذه إعدادات تؤدي وظائف مختلفة.
يوثق Odoo حقل Multiple الذي يرفع كمية التزويد إلى مضاعف مناسب، وينبه إلى أن ذلك قد يتجاوز الحد الأعلى. لذلك، إذا كانت مؤسستكم تعتبر الحد الأعلى قيداً صارماً للتخزين أو الإنفاق، فاذكروا ذلك صراحة. اطلبوا استثناء يحتاج إلى مراجعة أو كمية بديلة مسموحة عندما تتعارض العبوة مع هذا القيد. لا تصفوا قيمة بأنها سقف ملزم ثم تسمحوا بتجاوزها بصمت.
بينوا كذلك وحدة كل قيمة. يحتاج حد مخزون بالقطع وطلب شراء بالصناديق إلى تحويل متفق عليه. موضوع هذا الدليل هو قرار إعادة التزويد، لا تصميم تحويل الوحدات نفسه.
اختاروا لحظة الالتزام بالشراء
يميز Odoo بين التشغيل التلقائي ولوحة تزويد يدوية يراجع فيها المستخدم الاحتياجات قبل الضغط على الطلب. ويصف مسار Buy إنشاء طلب عرض سعر. طلب العرض لا يثبت أن المورد قبل أمر شراء أو التزم بموعد تسليم.
حددوا كل خطوة مسموحة في التطبيق المخصص: اقتراح الكمية، وإعداد استفسار المورد، واعتماد الشراء، وإرساله، وتسجيل تأكيد المورد. يمكن أتمتة بعضها وإبقاء بعضها يدوياً. وضحوا ما يحدث عند غياب المورد أو السعر أو المسؤول عن الاعتماد.
اطلبوا ربطاً دائماً بين الحاجة التي تعالج وعملية التوريد الناتجة عنها. يجب ألا تشتري عمليات الجدولة المتكررة أو نتائج الإرسال المجهولة الكمية نفسها مرتين دون علم الفريق. احفظوا المحاولات غير المحسومة وطابقوا نتيجتها الخارجية قبل إرسال طلب آخر عشوائياً. هذه ضوابط موثوقية مقترحة، وليست وصفاً لتفاصيل تنفيذ المنتج المذكور.
اختبروا نقصاً تتغير أسبابه
استخدموا مخزوناً وموردين وهميين في اختبار القبول:
- يتغير الطلب بينما ينتظر الاقتراح المراجعة.
- تتأخر شحنة واردة إلى ما بعد موعد الحاجة.
- تؤدي عبوة المورد إلى تجاوز الحد المتفق عليه.
- تواجه جولتان من الجدولة النقص نفسه.
- تبقى نتيجة إرسال طلب الشراء مجهولة مؤقتاً.
- يغيب المورد أو السعر عن السجل.
- يستطيع المستخدم تتبع الاقتراح إلى التوقع وحالة الشراء التي تفسره.
ناقشوا أصغر نطاق مفيد للأتمتة عند تخطيط تطبيق للمخزون والمشتريات. قد يكون اقتراح موثوق مع خطوة تالية واضحة أنفع من زر شراء يعمل على أرقام غير مفهومة.
حدود المصدر
يدعم دليل Odoo 19 قواعد الحد الأدنى والأعلى المرتبطة بالتوقع، ومضاعفات الشراء، والتشغيل اليدوي والتلقائي. أما سياسة التوقع، واستثناءات السقف الملزم، وتصميم الاعتماد، ومطابقة العمليات غير المحسومة فهي متطلبات تحتاج إلى تحديد. ليست ضمانات من المورد ولا وعوداً باختفاء نفاد المخزون.