چه زمانی فروشگاه واقعاً چندانباره است؟
وقتی یک کالا در چند محل نگهداری میشود و سایت باید بداند سفارش را از کجا تأمین کند، مسئله فراتر از داشتن چند نشانی است. شعبه، انبار مرکزی و محل نگهداری کالای معیوب لزوماً نقش یکسانی ندارند. مشخص کن کدام محل اجازه تأمین سفارش آنلاین دارد و کدام فقط برای انتقال داخلی یا فروش حضوری استفاده میشود.
اگر تمام سفارشهای اینترنتی فعلاً از یک انبار میروند، شاید نمایش موجودی همان محل کافی باشد. چندانبارهکردن بدون نیاز مشخص، تصمیمها و آزمونهای بیشتری وارد پروژه میکند. این مقاله درباره تخصیص کالا و ارسال بین محلهاست؛ اتصال حسابداری و گردش کلی سفارش، موضوع راهنماهای جداگانهاند.
موجودی داخل انبار با موجودی قابل فروش فرق دارد
برای هر کد کالا و هر محل، عدد قابل فروش را جدا تعریف کن. کالای کنارگذاشتهشده برای سفارش، کالای آسیبدیده و محمولهای که هنوز نرسیده نباید بیقاعده به عدد قابل خرید اضافه شوند. راهنمای وضعیت موجودی Shopify هم موجودی قابل فروش، تعهدشده، غیرقابل فروش و در راه را از هم جدا میکند؛ این منبع برای توضیح مفهوم است و به معنی استفاده گره از آن سرویس نیست.
یک مثال فرضی: انبار الف ۸ عدد از یک مدل کفش دارد؛ ۲ عدد برای سفارش کنار گذاشته شده و ۱ عدد نیازمند بررسی است. با فرض نبود محدودیت دیگر، ۵ عدد قابل فروش میماند. اگر انبار ب ۳ عدد قابل فروش دارد، نمایش جمع ۸ عدد فقط وقتی درست است که سیاست تأمین و ارسال اجازه استفاده از هر دو محل را بدهد.
زمان رزرو و آزادشدن کالا را توافق کن
بنویس موجودی چه زمانی کنار گذاشته میشود: هنگام شروع پرداخت، تأیید سفارش یا مرحله دیگری؟ مدت رزرو و رفتار سفارش پرداختنشده هم روشن باشد. انتخاب درست به روند فروش و زیرساخت بستگی دارد؛ یک زمان ثابت برای همه کسبوکارها پیشنهاد نمیشود. قیمت کالا و تعداد قابل خرید را نیز در نقطه نهایی ثبت سفارش دوباره بررسی کن.
برای مثال، اگر از یک مدل تنها یک عدد مانده و دو نفر همزمان اقدام کنند، نتیجه هر دو درخواست باید قابل توضیح باشد. پرداخت نامعلوم را با پرداخت ناموفق یکی نگیر؛ آزادسازی عجولانه میتواند همان کالا را در اختیار سفارش دیگری بگذارد. در سفارش توسعه، قاعده رسیدگی به تأیید دیرهنگام پرداخت و تلاش تکراری را صریح بخواه.
انبار سفارش را با چه اولویتی انتخاب میکنی؟
سه خواسته ممکن است با هم تعارض داشته باشند: ارسال از محل نزدیکتر، کمکردن تعداد بستهها و رعایت اولویت عملیاتی انبار. برای نمونه، اگر یک انبار تمام سبد را دارد اما انبار نزدیکتر فقط یک قلم را، کدام انتخاب میشود؟ فاصله کمتر لزوماً به معنی هزینه یا زمان کمتر نیست؛ ظرفیت بستهبندی، روش ارسال و محدودیت کالا هم مؤثرند.
مستندات رسمی Shopify تخصیص سفارش را وابسته به موجودی و قواعد مسیریابی توضیح میدهد و نزدیکترین محل را یک انتخاب قابل تنظیم میداند. در پروژه خودت، ترتیب قواعد و راه رسیدگی به نبود گزینه مناسب را بنویس. تغییر دستی محل تأمین هم باید مسئول مشخص، دلیل و کنترل موجودی داشته باشد؛ دکمه جابهجایی بهتنهایی کافی نیست.
ارسال از دو انبار را قبل از پرداخت روشن کن
فرض کن مشتری دو مدل کفش میخرد و هیچ انباری هر دو را ندارد. آیا سفارش به دو بسته تقسیم میشود، ابتدا انتقال داخلی انجام میدهی یا خرید را تا هماهنگی متوقف میکنی؟ این تصمیم روی مبلغ ارسال، زمان تحویل و کار تیم اثر دارد. عبارت کلی «ارسال سراسری» پاسخ این سؤال نیست.
اگر دو بسته میفرستی، مشتری باید پیش از تأیید خرید هزینه و حدود زمانبندی را بفهمد. بعد از خرید هم وضعیت هر بسته و راه پیگیری مشخص باشد. لغو یک قلم نباید وضعیت بسته تحویلشده را بیدلیل عوض کند. هزینه واقعی ارسال، محدودیت شرکت حمل و امکان ادغام مرسوله را بررسی کن؛ دو انبار همیشه به معنی دو هزینه ثابت یا یک زمان تحویل مشترک نیست.
مرجوعی را مستقیم به موجودی قابل فروش برنگردان
در مثال کفش، برگشت بسته به انبار ب به معنی آمادهبودن آن برای فروش بعدی نیست. ابتدا مدل، اندازه، تعداد و وضعیت کالا بررسی شود. ممکن است نیاز به بستهبندی دوباره، اصلاح ثبت یا کنارگذاشتن کالا باشد. عکس میانی این مقاله همین نقطه بازرسی را بهصورت نمایشی نشان میدهد.
مشخص کن کالای برگشتی به کدام محل میرسد و چه کسی اجازه قابل فروشکردن آن را دارد. وضعیت کالا را از وضعیت بازپرداخت جدا نگه دار؛ بررسی مالی و بررسی فیزیکی دو کار متفاوتاند. قواعد پذیرش مرجوعی باید مطابق سیاست واقعی فروشگاه تدوین شوند. این راهنما درباره ثبت موجودی است و شرایط حقوقی یا تجاری بازگشت را بهجای کسبوکار تعیین نمیکند.

انتقال بین انبارها را دو بار نشمار
اگر کالایی از الف به ب در راه است، باید روشن باشد در چه مرحلهای از موجودی قابل فروش مبدأ خارج و به مقصد اضافه میشود. ثبت خروج، دریافت واقعی و اختلاف تعداد سه رخداد جدا هستند. صرف ثبت درخواست انتقال، رسیدن کالا را ثابت نمیکند. برای بسته آسیبدیده یا دریافت ناقص هم مسیر رسیدگی بنویس.
یک نمونه آزمون بساز: انتقال ۴ عدد ثبت شود ولی مقصد فقط ۳ عدد دریافت کند. مسئول باید بتواند کسری را ثبت و پیگیری کند، بدون اینکه عدد خیالی به فروش آنلاین اضافه شود. در گزارش مدیریتی، موجودی فیزیکی هر محل و کالای در راه را جدا ببین. انتقال داخلی با سفارش مشتری یا ورود خرید تازه یکی نیست.
کد کالا و مرجع داده را یکسان کن
برای هر رنگ، اندازه و واحد فروش، کد مشترک لازم است؛ نام «کتانی طوسی» برای تشخیص چند مدل کافی نیست. انبار الف نباید یک جفت را با کدی ثبت کند که انبار ب برای کارتن چندجفتی استفاده میکند. پیش از ورود گروهی داده، چند نمونه ساده، اندازهدار و بستهای را با تیم انبار بررسی کن.
مشخص کن عدد معتبر از کجا میآید: نرمافزار انبار، حسابداری یا پنل سایت؟ زمان آخرین بهروزرسانی و رفتار قطع ارتباط را روشن بخواه. وجود نام یک نرمافزار در پیشنهاد، سازگاری اتصال را ثابت نمیکند؛ نسخه، دسترسی مجاز، مستندات و آزمون واقعی لازماند. برای جزئیات تبادل مالی، راهنمای اتصال فروشگاه به حسابداری را جدا بخوان.
پنل هر انبار چه چیزی باید نشان بدهد؟
مسئول انبار به صف کار خودش نیاز دارد: سفارش تخصیصیافته، کالا و تعداد، مهلت آمادهسازی و استثناهای نیازمند تصمیم. اطلاعات شخصی و مالی فقط به اندازه نیاز کاری نمایش داده شوند. مدیر میتواند تصویر کلی داشته باشد، اما اصلاح دستی موجودی باید مجوز، دلیل و سابقه قابل پیگیری داشته باشد.
اختلاف شمارش را با یک عدد تازه بیتوضیح حل نکن. مسئول بتواند بداند چه تغییری، چه زمانی و به چه دلیلی ثبت شده است. در گزارش، سفارش در انتظار تأمین را از سفارش آماده ارسال جدا کن. نمودار زیبا بدون تعریف وضعیتها برای تصمیم روزانه کافی نیست؛ ابتدا مشخص کن هر عدد کدام کار تیم را تغییر میدهد.
قیمت طراحی فروشگاه چندانباره به چه چیزهایی بستگی دارد؟
برآورد را به قواعد تخصیص، رزرو و آزادسازی، ارسال چندبستهای، انتقال داخلی، مرجوعی، دسترسی کارکنان و اتصالها تقسیم کن. افزودن یک محل با همان قواعد قبلی، با اضافهکردن انباری دارای فرایند و روش حمل متفاوت یکسان نیست. تعداد انبار، تنها یکی از ورودیهای برآورد است.
خروجی طراحی، توسعه، پاکسازی داده، انتقال اولیه، آزمون و نگهداری را جدا بخواه. هزینه سرویسهای بیرونی و مسئول اصلاح تغییرهای اتصال هم مشخص شوند. تعرفه عمومی فروشگاه را قیمت قطعی چندانباره برداشت نکن. در گره محدوده طراحی و اجرای فروشگاه بر اساس نیاز پروژه بررسی میشود؛ این مقاله وعده افزونه یا اتصال آماده برای هر نرمافزار انبار نیست.
پیش از تحویل، این سناریوها را امتحان کن
یک سفارش کامل از یک محل، سفارش نیازمند دو محل، خرید همزمان آخرین موجودی و لغو سفارش رزروشده را با داده آزمایشی بررسی کن. سپس قطع اتصال منبع موجودی، تغییر دستی محل تأمین و دریافت ناقص انتقال را امتحان کن. برای هر مورد، عدد پیش و پس و مسئول اقدام بعدی از قبل مشخص باشد.
مرجوعی را تا پایان بازرسی دنبال کن و مطمئن شو صرف ثبت برگشت، کالا را قابل فروش نمیکند. مشتری نیز مبلغ، تعداد بستهها و وضعیت هر ارسال را درست ببیند. هیچ آزمونی نباید بیهماهنگی سفارش، پرداخت یا مرسوله واقعی بسازد. نتیجه نامعلوم شبکه را پیش از تکرار بررسی کن تا موجودی یا سفارش دوباره ثبت نشود.
برای درخواست برآورد چه سندی آماده کنی؟
فهرست محلها و نقش هرکدام، چند کد کالا با واحد فروش، منبع موجودی و قواعد دلخواه تأمین را در یک برگه بنویس. دو سبد نمونه بده: یکی که یک محل تأمین میکند و یکی که به چند محل نیاز دارد. روش ارسال، انتقال و مرجوعی را هم کنار آنها مشخص کن؛ داده واقعی مشتری و کلید اتصال را در فرم عمومی نفرست.
اگر بعضی قواعد هنوز تصمیمگیری نشدهاند، آنها را سؤال باز بنویس تا در بررسی پروژه روشن شوند. میتوان دامنه شروع را به انبارهای ضروری محدود کرد، به شرط اینکه مسیر سفارش آنها کامل و قابل آزمون باشد. درخواست بررسی را با همین سناریوها بفرست؛ مقایسه پیشنهادهایی که درباره یک محدوده مشترکاند، از مقایسه دو عدد بدون توضیح مفیدتر است.
پرسشهای مرتبط
آیا جمع موجودی چند انبار را میتوان در سایت نشان داد؟
فقط اگر آن موجودی واقعاً برای سفارش آنلاین قابل استفاده باشد و قواعد تأمین و ارسال اجازه بدهند. کالای رزروشده، نیازمند بررسی یا در راه نباید بدون قاعده به عدد قابل خرید اضافه شود.
همیشه باید نزدیکترین انبار انتخاب شود؟
خیر. موجودی کامل سبد، تعداد بستهها، ظرفیت آمادهسازی و روش ارسال میتوانند مهمتر باشند. اولویت قواعد و حالت بدون گزینه مناسب باید در پروژه مشخص شوند.
قیمت سایت چندانباره فقط به تعداد انبارها بستگی دارد؟
خیر. قواعد رزرو، تخصیص سفارش، ارسال چندبستهای، انتقال، مرجوعی، نقشها و اتصالها روی محدوده و هزینه اثر دارند. بدون تعریف این موارد، عدد ثابت قابل اتکا نیست.
کالای برگشتی چه زمانی دوباره قابل فروش میشود؟
پس از بررسی و تأیید مسئول مجاز طبق فرایند واقعی فروشگاه. ثبت برگشت یا انجام بازپرداخت بهتنهایی سلامت و آمادهبودن کالا را ثابت نمیکند.
اتصال فروشگاه به هر نرمافزار انبار آماده است؟
نباید چنین فرضی کرد. نسخه نرمافزار، دسترسی مجاز، مستندات، قواعد داده و آزمون تبادل باید برای همان پروژه بررسی شوند؛ هزینه نگهداری اتصال هم جدا مشخص شود.
منابع برای مطالعه بیشتر
تحریریه گره · این راهنما برای انتخاب آگاهانه نوشته شده است. محدوده و شرایط هر همکاری در پیشنهاد همان پروژه مشخص میشود.
بررسی خدمت مرتبط در گره
دیجیپی
اسنپپی