مرجوعی و بازپرداخت جزئی در ووکامرس؛ پول و موجودی چه زمانی برگردند؟
درخواست مرجوعی، رسیدن بسته به انبار و برگشت پول سه اتفاق جدا هستند. اگر همه را با یک تغییر وضعیت سفارش انجام دهید، ممکن است کالای بررسی‌نشده دوباره قابل فروش شود یا بازپرداختی که فقط ثبت شده، پرداخت‌شده به نظر برسد. پیش از انتخاب افزونه، مسیر هر اتفاق و مسئول تأیید آن را مشخص کنید.
بازپرداخت در ووکامرس چگونه ثبت می‌شود؟
در مدیریت سفارش، گزینهٔ Refund برای ثبت بازپرداخت وجود دارد. بازپرداخت خودکار به پشتیبانی درگاه وابسته است؛ بازپرداخت دستی فقط سابقه را در فروشگاه ثبت می‌کند و انتقال پول باید جدا انجام شود. تغییر مستقیم وضعیت به Refunded یا Cancelled نیز دستور انتقال وجه نیست. بازپرداخت جزئی لزوماً وضعیت کل سفارش را به Refunded تغییر نمی‌دهد. مستند رسمی بازپرداخت ووکامرس این تفاوت‌ها را توضیح می‌دهد.
بنابراین ابتدا مشخص کنید مشکل شما ثبت سادهٔ بازپرداخت است یا مدیریت درخواست مشتری، بررسی کالا و تأیید چندمرحله‌ای. برای نیاز ساده، امکانات داخلی را روی سفارش آزمایشی بررسی کنید؛ افزودن افزونه بدون روشن‌کردن کمبود فعلی، تصمیم را دشوارتر می‌کند.
یک مسیر پیشنهادی برای درخواست مرجوعی
مسیر زیر پیشنهاد طراحی است و باید با عملیات فروشگاه تطبیق داده شود؛ این مراحل، وضعیت‌های پیش‌فرض سفارش ووکامرس نیستند.
- ثبت درخواست: مشتری قلم سفارش، تعداد، دلیل و روش تماس را انتخاب کند. نمایش «درخواست دریافت شد» نباید وعدهٔ تأیید یا برگشت قطعی پول باشد.
- بررسی اولیه: اپراتور مجاز درخواست را تأیید، رد یا نیازمند اطلاعات اعلام کند و دلیل قابل پیگیری بنویسد.
- دریافت بسته: انبار تعداد واقعی و هویت کالا یا تنوع را با درخواست تطبیق دهد؛ دریافت بسته به‌تنهایی تأیید سلامت کالا نیست.
- بررسی کالا: نتیجهٔ قابل فروش، نیازمند بررسی یا غیرقابل فروش ثبت شود. مسئول و زمان بررسی مشخص باشند.
- تصمیم مالی: مبلغ قابل برگشت، هزینه‌های مرتبط و روش پرداخت با تأیید فرد مجاز نهایی شود.
- بستن درخواست: نتیجهٔ مالی و حرکت انبار هرکدام سابقهٔ خود را داشته باشند؛ پروندهٔ ناقص با عنوان «تمام شد» پنهان نشود.
در شرح نیاز، قواعد فروشگاه برای پذیرش و محاسبه را بنویسید. این راهنما سیاست حقوقی مرجوعی تعیین نمی‌کند؛ هدفش تبدیل قواعد مشخص فروشگاه به فرایند نرم‌افزاری قابل آزمون است.
مثال: از سه قلم سفارش، فقط یک قلم برمی‌گردد
در مثال فرضی، مشتری دو پیراهن با تنوع‌های متفاوت و یک کیف خریده و فقط یکی از پیراهن‌ها را برمی‌گرداند. درخواست باید به همان قلم سفارش وصل شود؛ نام کلی «پیراهن» برای تشخیص کافی نیست. پیراهن دوم و کیف همچنان فروخته‌شده‌اند و نباید موجودی یا مبلغ آن‌ها اصلاح شود.
پس از دریافت، پیراهن مرجوعی ممکن است قابل فروش نباشد. در این حالت تأیید بازپرداخت الزاماً به افزایش موجودی قابل فروش منجر نمی‌شود. برعکس، ثبت دریافت کالا در انبار هم مدرک برگشت پول نیست. برای اتصال بیرونی، شناسهٔ درخواست، قلم سفارش و نتیجهٔ هر عملیات را جدا نگه دارید.
اگر مشکل شما انتخاب شناسهٔ کالا و تنوع است، راهنمای نگاشت کالا و SKU را بخوانید. این مقاله روی تصمیم و اجرای مرجوعی تمرکز دارد.
مبلغ را از سابقهٔ سفارش بررسی کنید
پیشنهاد می‌شود پیش‌نمایش مالی شامل قلم و تعداد، مبنای مبلغ، سهم تخفیف، مالیات، هزینهٔ حمل و بازپرداخت‌های قبلی باشد. قیمت امروز محصول جای سابقهٔ خرید مشتری را نگیرد. اینکه حمل یا هزینه‌ای برگردد، باید از قواعد مصوب فروشگاه بیاید؛ اپراتور نباید با یک انتخاب مبهم مبلغ را حدس بزند.
API رسمی برای بازپرداخت، اطلاعات مبلغ، اقلام و مالیات را ارائه می‌کند. قابلیت محاسبهٔ سمت سرور با compute_totals و مسیر پیش‌نمایش بازپرداخت در مستند فعلی از ووکامرس 11.1 معرفی شده‌اند؛ آن‌ها را برای همهٔ نسخه‌ها فرض نکنید. پشتیبانی واقعی باید پیش از استفاده بررسی شود، زیرا نسخهٔ قدیمی ممکن است پارامتر ناشناخته را نادیده بگیرد. مرجع Order refunds API مبنای بررسی نسخه و قرارداد درخواست است.
پیش‌نمایش در فرایند اختصاصی، پیشنهاد تصمیم است؛ میان پیش‌نمایش و تأیید ممکن است اپراتور دیگری بازپرداختی ثبت کند. پیش از اجرا، سابقه و مبلغ باقی‌مانده دوباره خوانده شوند و اگر مبنا تغییر کرده، تأیید تازه گرفته شود.
چه زمانی موجودی را افزایش دهیم؟
ووکامرس هنگام بازپرداخت، گزینهٔ «Restock refunded items» برای برگشت اقلام به موجودی دارد. این گزینه جای بررسی فیزیکی کالا را نمی‌گیرد. پیش از انتخاب آن، تعداد و نتیجهٔ بررسی انبار را روشن کنید. راهنمای رسمی برگشت اقلام به موجودی محل این انتخاب را نشان می‌دهد.
برای فروشگاهی که انبار بیرونی مرجع موجودی است، پیشنهاد می‌شود فقط یک مسیر مسئول افزایش موجودی باشد. افزایش در ووکامرس و ثبت دوبارهٔ همان حرکت در اتصال انبار می‌تواند اختلاف بسازد. کالای آسیب‌دیده را از موجودی قابل فروش جدا کنید و روش ثبت قرنطینه یا ضایعات را در سامانهٔ واقعی انبار تعریف کنید.
راهنمای اتصال ووکامرس به انبار انتخاب مرجع داده را توضیح می‌دهد. اگر سند مالی هم لازم دارید، مسیر آن در راهنمای اتصال حسابداری جدا بررسی شده است.
اگر پاسخ درگاه نامشخص بود، دوباره پول برنگردانید
در طراحی اختصاصی، برای هر اقدام مالی شناسه و سابقهٔ درخواست نگه دارید. قطع ارتباط پس از ارسال ممکن است نتیجه را نامشخص کند؛ آن را با رد قطعی درخواست یکی نکنید. پیش از اجرای دوباره، نتیجه را با امکانات استعلام یا گزارش سرویس انتخاب‌شده بررسی کنید. اگر سرویس چنین امکانی ندارد، مسیر بررسی دستی و مسئول تصمیم لازم است.
این یک قاعدهٔ پیشنهادی طراحی است؛ تضمین جلوگیری از تکرار به قابلیت درگاه و کنترل اجرای هم‌زمان وابسته است. درگاه، افزونهٔ پرداخت و ووکامرس باید در همان ترکیب واقعی آزموده شوند. برای پرداخت دستی هم مرجع انتقال و تأیید مالی ثبت شود؛ صرف ثبت یادداشت، نتیجهٔ بانکی را اثبات نمی‌کند.
افزونه آماده یا اختصاصی؟
اگر فقط فرم درخواست و رسیدگی ساده می‌خواهید، ابتدا افزونهٔ آماده را با سناریوی واقعی آزمایش کنید. وجود عنوان «مرجوعی» در فهرست امکانات کافی نیست؛ مرجوعی یک قلم، دسترسی کارکنان، روش بازپرداخت و اثر موجودی را بررسی کنید.
دریافت مرحله‌ای کالا، تأیید جداگانهٔ انبار و مالی، اتصال به چند سامانه یا کنترل درخواست‌های هم‌زمان می‌تواند نیاز به توسعهٔ تکمیلی ایجاد کند. کمبود راهکار موجود را دقیق بنویسید و با راهنمای انتخاب افزونه آماده یا اختصاصی تصمیم بگیرید.
پنج آزمون پذیرش پیش از انتشار
این آزمون‌ها پیشنهادی‌اند و گزارش اجرای پروژهٔ مشتری نیستند. آن‌ها را در محیط آزمایشی، با روش تست مورد تأیید سرویس پرداخت اجرا کنید.
- یک قلم از چند قلم: تنها مبلغ و تعداد انتخاب‌شده تغییر کنند و سایر اقلام سفارش دست‌نخورده بمانند.
- کالای غیرقابل فروش: تأیید مالی باعث افزایش خودکار موجودی قابل فروش نشود؛ نتیجهٔ بررسی انبار محفوظ بماند.
- دو اپراتور: تأیید هم‌زمان یک درخواست، یک اقدام منطقی بسازد و تغییر سابقه، پیش‌نمایش قدیمی را نامعتبر کند.
- پاسخ نامشخص: قطع ارتباط نتیجهٔ نامشخص ثبت کند و اجرای مجدد به استعلام یا بررسی مجاز وابسته باشد.
- مجوز و سابقه: کاربر انبار بدون مجوز مالی نتواند بازپرداخت انجام دهد؛ زمان، مسئول و نتیجهٔ هر اقدام قابل پیگیری باشند.
نسخه‌ها، دادهٔ ورودی، نتیجهٔ مورد انتظار و نتیجهٔ مشاهده‌شده را در مدارک تحویل افزونه ثبت کنید. مرز عملیات نقش‌ها هم در راهنمای دسترسی کارکنان توضیح داده شده است.
برای سفارش توسعه چه اطلاعاتی آماده کنیم؟
- قواعد تأیید درخواست، تعویض یا بازپرداخت و نمونهٔ بدون اطلاعات مشتری
- درگاه و مستندات بازپرداخت، استعلام و محیط آزمایش آن
- مراحل دریافت و بررسی کالا، مرجع موجودی و مسئول هر مرحله
- قاعدهٔ تخفیف، حمل، مالیات و بازپرداخت‌های قبلی در پیش‌نمایش
- دسترسی اپراتورها، گزارش اختلاف و معیار بستن درخواست
این موارد را در شرح نیاز افزونه ثبت کنید تا برآورد بر اساس فرایند مشخص انجام شود.
منابع و محدودهٔ راهنما
مستندات رسمی در ۸ اکتبر ۲۰۲۶ بررسی شدند. رفتار داخلی بازپرداخت بر اساس راهنمای WooCommerce Refunds و قابلیت‌های اتصال بر اساس Order refunds API نوشته شده‌اند. مسیر رسیدگی، کنترل هم‌زمانی و آزمون‌ها پیشنهاد طراحی‌اند و باید با نسخه‌ها و عملیات فروشگاه تطبیق داده شوند.