E-MYTH

أنظمة الأعمال

ربط المبيعات بالمخزون: من تسعير الطلب إلى التسليم

شرح عملي لربط المبيعات بالمخزون عبر قوائم الأسعار وحجز الطلب والتسليم الجزئي، مع شاشات من WholesaleOS وأسئلة اختبار لصاحب شركة الجملة.

عرض تجريبي من WholesaleOS — ربط المبيعات بالمخزون: من تسعير الطلب إلى التسليم

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

سنتتبّع التسعير والطلب المحجوز وقرار التسليم عبر نسخة WholesaleOS المحلية. الصور لواجهات فعلية وبيانات تجريبية؛ وليست تسلسلاً لعملية عميل أو ادعاءً بأننا نفذنا كل زر ظاهر فيها.

الخطوة الأولى: حدّد السعر الذي يستحقه العميل

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

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

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

الخطوة الثانية: اقرأ الطلب دون الخلط بين الحجز والتسليم

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

02 — عشر وحدات مطلوبة ولم تُسلّم
WholesaleOS — واجهة تجريبية: عشر وحدات مطلوبة ولم تُسلّمافتح الصورة بالحجم الكامل ↗
طلب تجريبي محجوز فعلياً. اقرأ عمودي المطلوب والمسلّم مع حالة التسليم. زر «تسليم» متاح، ولم يُنفّذ لغرض التقاط هذه الصورة.

السؤال التشغيلي لهذا الطلب: من يجهّز الوحدات العشر ويسلّمها، ومن يسجّل التسليم؟ تعديل رصيد الصنف يدوياً ليس بديلاً جيداً؛ لأنه يفصل حركة البضاعة عن الطلب الذي سبّبها.

ماذا لو خرج جزء من الطلب فقط؟

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

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

البيع عند الكاشير يحتاج مساراً مستقلاً

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

الإلغاء ليس مرتجعاً

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

كذلك يجب أن يرتبط التسليم بـرصيد العميل والتحصيل. خروج البضاعة من المستودع لا يثبت أن العميل دفع ثمنها.

تجربة قبول قابلة للتكرار

  1. اختر تسعير العميل الصحيح وافحص صنفاً معروفاً.
  2. أكّد طلباً وقارن الموجود والمحجوز والمتاح.
  3. نفّذ تسليماً جزئياً في بيئة الاختبار وافحص المتبقي.
  4. جرّب إلغاءً غير مسموح وتأكد من وضوح السبب.
  5. أكمل التسليم وافتح السجل المالي للعميل.

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

تابع بحسب المرحلة التي تحتاجها

مصدر هذا الشرح

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

المزيد من الأفكار