فهرست و برد سفارش‌ها و مدیریت صف
جست‌وجو، فیلتر، ستون‌ها، اقدام‌های مجاز و صف‌های روزانه
فهرست سفارش‌ها، برد مراحل، جست‌وجو، فیلترها و مدیریت صف روزانه
این صفحه نقطه شروع مسئول سفارش است؛ هدف آن تنها یافتن شماره خرید نیست، بلکه تشخیص کار بعدی است. در آناما فهرست سفارش از API /order-workspace/ بارگیری می‌شود و نتیجه، شمار سفارش‌ها، شمارش هر وضعیت، صفحه جاری و فهرست اقدام‌های مجاز را برمی‌گرداند. بنابراین آنچه دیده می‌شود هم به فیلترها و هم به مجوز نقش بستگی دارد.
بخش‌های قابل مشاهده
- همه سفارش‌ها و وضعیت‌ها در نوار کناری: عدد کنار هر وضعیت، شمار سفارش‌های همان وضعیت در دامنه جست‌وجوی فعلی است. با انتخاب یک وضعیت، فهرست محدود می‌شود. شمارها لزوماً شمار پرداخت‌های موفق یا اقلام انبار نیستند.
- جست‌وجو: شماره سفارش، موبایل، نام و نام خانوادگی مشتری. در صورت نتیجه صفر، ابتدا فاصله اضافی، فیلتر وضعیت و جست‌وجوی موبایل را بررسی کنید؛ فیلد SKU برای جست‌وجوی این نمای خاص در بک‌اند دیده نمی‌شود.
- تازه‌سازی: برای دریافت آخرین داده بعد از اقدام همکار یا تغییر وضعیت لازم است. صفحه خودکار از رخدادهای داخلی هم تازه می‌شود، اما قبل از تصمیم مالی بهتر است داده تازه بخوانید.
- جدول/برد: دو شیوه نمایش یک منبع داده‌اند؛ جابه‌جایی برد خودش وضعیت سفارش را تغییر نمی‌دهد. حرکت روی برد در عمل پنجره تأیید اقدام سفارش را باز می‌کند.
- افزودن سفارش: با مجوز ایجاد سفارش نمایش داده می‌شود. ثبت سفارش جدید جایگزین اصلاح سفارش موجود نیست.
ستون‌های جدول را چگونه تفسیر کنیم؟
سفارش: شماره یکتا و نشان «دستی» یا «خرید مشتری»؛ شماره سفارش در زمان ساخت ایجاد می‌شود و برای پیگیری ضروری است. مشتری: نام و موبایل مرتبط؛ نام مشابه دو شخص را بر اساس موبایل و پرونده تفکیک کنید. مبلغ: مبلغ قابل پرداخت ذخیره‌شده؛ اگر تخفیف، حمل و کیف پول دارید، لزوماً برابر جمع قیمت روز محصولات نیست. پرداخت: از payment_status می‌آید؛ با status عملیات ارسال یکی نیست. وضعیت: مرحله تجاری سفارش. تاریخ: زمان ساخت؛ تاریخ پرداخت، بسته‌بندی یا تحویل نیست. عملیات: فقط اقدام‌های مجاز موجود در آن وضعیت.
چه صف‌هایی را اول رسیدگی کنیم؟
۱. فیش یا دریافت در انتظار بررسی: زیرا تأیید اشتباه ممکن است هم پرداخت و هم رزرو موجودی را قطعی کند.
۲. سفارش‌های پرداخت‌شده و آماده پردازش: اقلام، کمبود موجودی و اولویت تحویل را بررسی کنید. ظرفیت آماده‌سازی واقعی را لحاظ کنید.
۳. بسته‌بندی‌شده‌های منتظر ارسال: اطلاعات تحویل و حامل را کنترل کنید؛ پرشدن این صف می‌تواند نشان تأخیر عملیات باشد.
۴. مرسوله‌های بدون رهگیری یا مشکل‌دار: در بخش ارسال دنبال پرونده واقعی شرکت حمل بگردید. عدد «ارسال شده» بدون تحویل واقعی پایان کار نیست.
۵. مرجوعی، تعویض، اختلاف پرداخت و گارانتی: این پرونده‌ها صف مستقل دارند و نباید صرفاً با تغییر وضعیت سفارش بسته شوند.
تفاوت «برد مراحل» و مرکز کنترل سفارش
برد موجود در فهرست، سفارش‌ها را به ستون وضعیت تجاری تقسیم می‌کند. مرکز کنترل سفارش (OrderControlTower) در بخش ERP چند صف عملیاتی دارد: پرداخت، آماده‌سازی، ارسال، مرجوعی و گارانتی. ممکن است تعدادها یکسان نباشند، زیرا شرایط عضویت در صف‌ها متفاوت است و مجوزهای نقش نیز اثر دارد. از شمار کارت «نیازمند اقدام» به‌عنوان کل سفارش‌ها یا مبلغ کل فروش استفاده نکنید.
سناریو: سفارش پیدا نمی‌شود
ابتدا فیلتر وضعیت را به «همه سفارش‌ها» برگردانید و جست‌وجو را با شماره سفارش کامل انجام دهید. اگر نتیجه‌ای نبود، موبایل مشتری را امتحان کنید. سپس دامنه دسترسی و Tenant جاری را بررسی کنید. ممکن است سفارش در فضای کاری دیگری ساخته شده باشد، ولی انتقال رکورد بین Tenantها صرفاً برای حل جست‌وجو مجاز نیست. اگر مشتری ادعای پرداخت دارد، قبل از ایجاد سفارش جایگزین، رسید/تراکنش را با بخش پرداخت تطبیق دهید.
سناریو: دو نفر روی یک سفارش کار می‌کنند
دو مسئول فروش، همان سفارش را باز کرده‌اند. نفر اول بسته‌بندی را ثبت می‌کند و نفر دوم با داده قدیمی اقدام بعدی را می‌بیند. نفر دوم باید سفارش را دوباره بارگیری کند؛ اقدام‌های سمت سرور براساس وضعیت و مجوز تازه بررسی می‌شوند. برای سفارش دستی ویرایش‌پذیر، کنترل زمان expected_updated_at جلوی بازنویسی بی‌خبر داده جدید را می‌گیرد. ثبت موازی چندباره یک سفارش برای جبران خطای نمایش، روش صحیح نیست.
پیشنهاد اجرایی برای تیم
تعریف مسئول صف پرداخت، آماده‌سازی، تحویل و رسیدگی پس از فروش به‌مراتب مفیدتر از این است که همه به تمام دکمه‌ها دسترسی داشته باشند. در انتهای روز، سفارش‌هایی را که بیشتر از بازه خدمت در یک مرحله مانده‌اند استخراج و با دلیل توقف دسته‌بندی کنید: «انتظار مشتری»، «کمبود کالا»، «عدم تأیید وجه»، «خطای حامل» یا «ارجاع پشتیبانی». این دسته‌بندی عملیاتی پیشنهاد است و لزوماً فیلد آماده روی همه سفارش‌ها ندارد.
ادامه: وضعیت‌ها، جزئیات سفارش، چک‌لیست شیفت.