فتح أقل عدد ممكن من الطرود

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

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

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

تُستشار ثلاثة مستويات بهذا الترتيب، ويفوز أولها جواباً:

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

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

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