جلوگیری از فروش بیش از موجودی در ووکامرس؛ رزرو کالا و سفارش‌های هم‌زمان
اگر دو مشتری آخرین واحد یک کالا را هم‌زمان سفارش بدهند، کدام سفارش حق مصرف موجودی دارد؟ پاسخ فقط در عدد نمایش‌داده‌شدهٔ محصول نیست. تنظیمات فروش، زمان رزرو، نتیجهٔ پرداخت و فروش در کانال‌های دیگر باید با هم بررسی شوند. برای شروع، مشخص کنید موجودی منفی نتیجهٔ پیش‌فروشِ مجاز است یا یک تعهد فروش ناخواسته؛ این دو مسئله راه‌حل یکسانی ندارند.
قبل از نصب افزونه، این تنظیمات را بررسی کنید
در ووکامرس ← تنظیمات ← محصولات ← موجودی، فعال‌بودن مدیریت موجودی را کنترل کنید. طبق راهنمای رسمی تنظیمات محصولات، بدون مدیریت عددی، وضعیت‌هایی مانند «موجود» و «ناموجود» جای شمارش موجودی را می‌گیرند. سپس برای کالای مسئله‌دار، مقدار موجودی و اجازهٔ پیش‌فروش یا Backorders را بررسی کنید. اگر پیش‌فروش آگاهانه مجاز است، قبول سفارش بیشتر از تعداد فعلی الزاماً نشانهٔ خرابی نیست.
برای محصول متغیر، معلوم کنید موجودی در سطح محصول مادر مشترک است یا هر تنوع موجودی مستقل دارد. مستندات محصول متغیر هر دو حالت و ترکیب آن‌ها را توضیح می‌دهد. آزمون خرید را روی همان رنگ، سایز یا تنوعی انجام دهید که اختلاف دارد؛ موجودبودن محصول مادر، موجودی همهٔ تنوع‌ها را ثابت نمی‌کند. برای اتصال به انبار نیز شناسهٔ هر کالا و تنوع باید درست نگاشت شده باشد.
نگهداری موجودی با رزرو همیشگی سبد خرید فرق دارد
گزینهٔ Hold Stock مدت نگهداری موجودی سفارش‌های پرداخت‌نشده را تعیین می‌کند. طبق راهنمای تنظیمات، لغو پس از این مهلت مربوط به سفارش‌های «در انتظار پرداخت» است و به سفارش‌های On hold تعمیم داده نمی‌شود. خالی‌گذاشتن این تنظیم هم آن را غیرفعال می‌کند؛ پس تغییر مقدار بدون شناخت جریان پرداخت، راه‌حل عمومی نیست.
صرف افزودن کالا به سبد را رزرو قطعی فرض نکنید. در راهنمای فعلی وضعیت سفارش، تسویه‌حساب بلوکی برای جریان تازه، ابتدا اطلاعات را در نشست مشتری نگه می‌دارد و هنگام اقدام به ثبت سفارش رکورد موقت می‌سازد؛ رزرو در مرحلهٔ مربوط به آن انجام می‌شود. بنابراین زمان دقیق رزرو را با نسخهٔ نصب‌شده، نوع تسویه‌حساب و درگاه خودتان آزمون کنید. رفتار یک نسخه یا افزونهٔ قدیمی را به همهٔ فروشگاه‌ها تعمیم ندهید.
موجودی فیزیکی، رزروشده و قابل فروش را جدا تعریف کنید
در طراحی یک اتصال، سه عدد ممکن است با هم متفاوت باشند: کالای واقعاً موجود در انبار، مقداری که برای سفارش باز کنار گذاشته شده و مقداری که هنوز می‌توان به مشتری تازه فروخت. یک تعریف پیشنهادی این است: «قابل فروش = موجودی مبنا منهای تعهدهای رزروشده و سهم کنارگذاشته‌شده». این تعریف برای روشن‌کردن قرارداد داده است و فرمولی برای تغییر مستقیم عدد ووکامرس نیست.
اگر عدد مبنا قبلاً پس از فروش یا رزرو کاهش یافته باشد، کسر دوبارهٔ همان تعهد، موجودی را کمتر از مقدار واقعی نشان می‌دهد. در مقابل، اگر اتصال انبار عدد قدیمی را روی فروشگاه بنویسد، ممکن است تعهد تازهٔ سایت در نمایش موجودی نادیده گرفته شود. برای هر فیلد، مشخص کنید عدد مربوط به چه لحظه‌ای است، چه چیزهایی از آن کم شده و چه سامانه‌ای اجازهٔ تغییر آن را دارد.
مثال فرضی: دو سفارش برای آخرین واحد
فرض کنید فقط یک واحد از یک تنوع باقی مانده و پیش‌فروش مجاز نیست. دو مشتری تقریباً هم‌زمان به مرحلهٔ ثبت سفارش می‌رسند. در طراحی مورد انتظار، یکی رزرو معتبر می‌گیرد و دیگری پیام نبود موجودی یا امکان تلاش بعدی را می‌بیند. این مثال، معیار پذیرش یک فرایند است و گزارش نتیجهٔ پروژه یا تضمین رفتار همهٔ نصب‌های ووکامرس نیست.
دو درخواست نباید هرکدام عدد «یک» را بخوانند و مستقل آن را کافی بدانند. کنترل ظرفیت و ثبت رزرو باید در مرجع تصمیم‌گیر به‌گونه‌ای انجام شود که دو اجرا نتوانند یک ظرفیت را مصرف کنند. ووکامرس ابزار ReserveStock برای نگهداری موقت و آزادکردن موجودی سفارش دارد؛ وجود این ابزار جای آزمون مسیرهای افزونه، درگاه و اتصال بیرونی را نمی‌گیرد.
اگر رزرو مشتری اول منقضی شد و مشتری دوم کالا را گرفت، تأیید دیرهنگام پرداخت اول نباید بی‌بررسی تعهد تازه بسازد. باید معلوم باشد آیا موجودی دوباره بررسی می‌شود، سفارش برای رسیدگی متوقف می‌ماند یا مسیر توافق‌شدهٔ دیگری اجرا می‌شود. مسئول پیگیری پرداخت و پیام مشتری نیز باید مشخص باشد.
برای هر پایان سفارش، تکلیف رزرو را بنویسید
این جدول نمونهٔ طراحی و آزمون است؛ رفتار نهایی به قواعد فروشگاه، درگاه و امکانات انبار بستگی دارد. آزادکردن رزرو باید مربوط به همان سفارش و همان مقدار باشد. تکرار اعلان لغو یا پرداخت نباید بار دوم موجودی را آزاد یا کم کند.
| سناریو | قاعدهٔ لازم | کنترل قابل مشاهده |
|---|---|---|
| پرداخت موفق در مهلت | تبدیل رزرو معتبر به تعهد فروش | کاهش یا قطعی‌شدن فقط یک بار |
| پایان مهلت پرداخت | تعیین سفارش واجد آزادسازی | مقدار آزادشده و زمان ثبت آن |
| لغو یا پرداخت ناموفق | آزادسازی مطابق اثر قبلی سفارش | عدم افزایش موجودی در پیام تکراری |
| پرداخت پس از انقضا | کنترل مجدد ظرفیت یا رسیدگی مسئول | عدم تعهد خودکار به کالای واگذارشده |
| قطع ارتباط با انبار | توقف، سهم مستقل یا مسیر از پیش توافق‌شده | نتیجهٔ نامشخص و مسئول بررسی |
اگر رزروهای موعدگذشته آزاد نمی‌شوند، زمان اجرای عملیات و خطاهای آن را بررسی کنید؛ تغییر مهلت به‌تنهایی علت را روشن نمی‌کند. راهنمای کارهای زمان‌بندی‌شدهٔ ووکامرس به تفکیک تأخیر اجرا و شکست عملیات کمک می‌کند.
فروش حضوری و چند کانال، تصمیم دیگری می‌خواهند
رزرو داخل فروشگاه فقط درخواست‌هایی را کنترل می‌کند که از همان مسیر عبور می‌کنند. اگر فروش حضوری یا سامانهٔ دیگری هم از یک کالا مصرف می‌کند، باید قرارداد مشترکی برای سهم فروش وجود داشته باشد. همگام‌سازی سریع‌تر، فاصلهٔ اختلاف را کم می‌کند؛ اما به‌تنهایی اجازهٔ هم‌زمان دو سامانه برای فروش آخرین واحد را حل نمی‌کند.
- رزرو در مرجع مشترک: کانال‌ها پیش از قبول تعهد، از مرجع موجودی ظرفیت می‌گیرند. API باید نتیجهٔ رزرو، مهلت و مسیر تعیین تکلیف پاسخ نامشخص داشته باشد.
- سهم مستقل کانال‌ها: بخشی از موجودی به سایت و بخشی به فروش حضوری اختصاص می‌یابد؛ جابه‌جایی سهم و اصلاح دستی نیز باید کنترل شود.
- حاشیهٔ احتیاط: نمایش مقدار کمتر از موجودی ممکن است ریسک اختلاف را کاهش دهد، اما جای رزرو مشترک یا سهم‌بندی معتبر را نمی‌گیرد.
انتخاب بین این مسیرها به قابلیت واقعی نرم‌افزار انبار و میزان تأخیر قابل قبول بستگی دارد. برای تعریف مرجع داده و جریان کلی، راهنمای اتصال ووکامرس به انبار را بخوانید. وقتی مقصد پاسخ نداده، «ناموفق» فرض‌کردن نتیجه و رزرو دوباره می‌تواند مشکل تازه بسازد؛ ابتدا نتیجهٔ عملیات قبلی باید روشن شود.
پنج آزمون پیش از انتشار تغییر
این آزمون‌ها را در محیط آزمایشی، با درگاه آزمایشی و کالای ساختگی اجرا کنید. شناسهٔ سفارش، تنوع، مقدار، زمان و نتیجهٔ رزرو را ثبت کنید؛ برای گزارش تشخیص نیازی به انتشار اطلاعات مشتری نیست.
- آخرین واحد: در دو نشست مستقل، خرید همان تنوع را هم‌زمان انجام دهید؛ بیش از ظرفیت موجود، تعهد معتبر ایجاد نشود.
- انقضا و تلاش دوباره: پرداخت را رها کنید و پس از تعیین تکلیف مهلت، خرید تازه را امتحان کنید؛ ظرفیت مطابق قاعده آزاد شود و رزرو بی‌صاحب نماند.
- پیام تکراری: تأیید پرداخت و لغو را جداگانه دوباره پردازش کنید؛ اثر موجودی در هر عملیات فقط یک بار اعمال شود.
- پرداخت دیرهنگام: پس از آزادسازی و واگذاری کالا، نتیجهٔ پرداخت اول را برگردانید؛ سفارش برای مسیر توافق‌شده تعیین تکلیف شود.
- کانال دوم و قطعی: هم‌زمان با خرید سایت، فروش بیرونی و قطع ارتباط را شبیه‌سازی کنید؛ محدودیت سهم یا سیاست توقف حفظ شود و نتیجهٔ نامشخص قابل پیگیری باشد.
چه زمانی افزونهٔ اختصاصی لازم می‌شود؟
اگر مشکل از تنظیم مدیریت موجودی، اجازهٔ پیش‌فروش یا نگاشت تنوع است، ابتدا همان را اصلاح و آزمون کنید. وقتی قواعد شما شامل سهم چند انبار، رزرو پیش از پرداخت در سامانهٔ بیرونی، رسیدگی به پرداخت دیرهنگام یا محدودیت متفاوت کانال‌هاست، باید بررسی شود افزونهٔ موجود این سناریوها را واقعاً پوشش می‌دهد یا توسعهٔ تکمیلی لازم است.
برای برآورد، نوع تسویه‌حساب، نسخهٔ ووکامرس و درگاه، شیوهٔ مدیریت موجودی هر تنوع، امکان رزرو API انبار، مهلت‌ها و نتیجهٔ پنج آزمون بالا را آماده کنید. این موارد را در شرح نیاز افزونه بنویسید؛ معیارهای پذیرش را هم در چک‌لیست تحویل نگه دارید. مسیر ساخت افزونه اختصاصی وردپرس و ووکامرس برای بررسی همین قواعد و محدودهٔ اجراست.
منابع فنی
منابع رسمی در ۲۰۲۶/۱۰/۰۴ بازبینی شدند. رفتار رزرو و وضعیت‌ها را با نسخه و افزونه‌های نصب‌شدهٔ فروشگاه خود تطبیق دهید.