ویرایش گروهی قیمت محصولات ووکامرس؛ از فایل اکسل تا اجرای قابل برگشت
برای تغییر یکسان قیمت چند محصول، ابزارهای موجود ووکامرس را بررسی کنید؛ برای قیمت‌های متفاوت، فایل CSV یا ویرایشگر گروهی می‌تواند مناسب باشد. وقتی تأیید مدیر، قواعد تأمین‌کننده یا گزارش برگشت لازم است، مسئله فقط انتخاب ابزار نیست: باید بدانید هر ردیف چه محصولی را تغییر می‌دهد، قیمت نهایی چیست و در صورت اشتباه کدام تغییرها قابل بازگردانی‌اند.
اگر تغییر قیمت با کمپین تخفیف همراه است، قواعد کد تخفیف و آزمون سبد ترکیبی را هم مشخص کنید.
ویرایش داخلی، CSV یا افزونه اختصاصی؟
- تغییر یکسان در یک گروه مشخص: امکانات ویرایش گروهی فروشگاه را با همان نوع محصول و عملیات موردنیاز امتحان کنید؛ پیش از اجرای گسترده، نتیجهٔ چند نمونه را ببینید.
- فهرست قیمت متفاوت برای هر کالا: ابزار CSV ووکامرس یا ویرایشگر آماده را در محیط آزمایشی بررسی کنید؛ معیار انتخاب، شناسایی دقیق محصول و پوشش قیمت عادی، تخفیف و تنوع‌هاست.
- فرایند تأیید و قواعد ویژه: اگر اپراتور فایل می‌دهد و مدیر باید تغییر را تأیید کند، یا قیمت از فرمول تأمین‌کننده می‌آید، ابتدا پوشش راهکار آماده را بسنجید. توسعهٔ تکمیلی یا اختصاصی وقتی توجیه دارد که نیاز مشخص با ابزار موجود پوشش داده نشود.
این مسیر با تصمیم بین افزونه آماده و اختصاصی مرتبط است. صرف زیادبودن تعداد محصولات، به‌تنهایی دلیل ساخت افزونه جدید نیست.
برای تغییر قیمت با اکسل، فایل را چگونه آماده کنیم؟
ابزار داخلی ووکامرس فایل CSV می‌گیرد؛ اگر قیمت‌ها را در Excel آماده می‌کنید، خروجی UTF-8 CSV بسازید. از خروجی همان فروشگاه برای شناخت ستون‌ها شروع کنید. در مسیر Products → Import، گزینهٔ Update existing products و نگاشت ستون‌ها را بررسی کنید؛ تطبیق محصولات موجود بر اساس ID یا SKU انجام می‌شود. ستون‌های خارج از دامنهٔ قیمت را برای واردنشدن تنظیم کنید. جزئیات در راهنمای رسمی درون‌ریزی محصولات آمده است.
قرارداد فایل را پیش از دریافت فهرست تأمین‌کننده بنویسید: واحد مبلغ، جداکنندهٔ اعشار، قیمت عادی یا تخفیف، معنای مقدار خالی و شناسهٔ هر ردیف. مقدار خالی را بدون توافق، «صفر» یا «حذف تخفیف» فرض نکنید. شناسه‌هایی با صفر ابتدایی باید به‌عنوان متن حفظ شوند؛ نگاشت مبهم، ردیف تکراری یا محصول ناشناخته وارد مرحلهٔ اجرا نشود.
گزینهٔ به‌روزرسانی را معادل تضمین «هیچ محصول جدیدی ساخته نمی‌شود» نگیرید: مستندات روز برای ایجاد بعضی تنوع‌ها در مسیر update از نسخهٔ 11.1 شرایطی ذکر می‌کنند. برای کاری که فقط تغییر قیمت است، شناسه‌ها و تعداد تنوع‌ها را پیش و پس از آزمون کنترل کنید. این رفتار باید با نسخهٔ نصب‌شدهٔ فروشگاه تطبیق یابد.
قیمت محصول متغیر را در کدام ردیف تغییر دهیم؟
برای قیمت‌گذاری تنوع‌ها، هر ردیف باید به همان variation برسد. API رسمی تنوع محصولات، قیمت عادی و تخفیف را در مسیر تنوع ارائه می‌کند. برای نمونهٔ فرضیِ پیراهن با دو سایز، اگر تأمین‌کننده فقط قیمت سایز بزرگ را عوض کرده است، اعمال آن به همهٔ تنوع‌ها یک تصمیم اضافی است و باید جدا تأیید شود.
شناسهٔ محصول مادر، شناسهٔ تنوع و SKU را در پیش‌نمایش کنار نام و ویژگی‌ها نشان دهید. محصول بدون نگاشت روشن را متوقف کنید؛ تشابه نام کالا کافی نیست. راهنمای نگاشت شناسه و SKU جزئیات این مسئله را جدا پوشش می‌دهد.
پیش‌نمایش باید اختلاف واقعی را نشان دهد
پیش از اجرا، فهرستی قابل تأیید از قیمت فعلی، قیمت پیشنهادی، تفاوت مبلغ و درصد، نوع قیمت و علت کنارگذاشتن ردیف‌ها تهیه کنید. محدودیت مجاز تغییر را خود کسب‌وکار تعیین کند؛ یک آستانهٔ عمومی برای همهٔ فروشگاه‌ها وجود ندارد. فایل، قواعد محاسبه و فهرست هدف پس از تأیید ثابت بمانند؛ تغییر هرکدام تأیید تازه می‌خواهد.
مثال فرضی: افزایش دوباره را از پیش حذف کنید
فرض کنید قیمت عادی یک کالا ۵۰۰٬۰۰۰ تومان است و تصمیم، افزایش ۱۰ درصدی به ۵۵۰٬۰۰۰ تومان است. پیشنهاد اجرا باید مقدار نهایی ۵۵۰٬۰۰۰ را ثبت کند. اجرای دوبارهٔ همان کار نباید دوباره ۱۰ درصد به قیمت جدید اضافه کند و آن را به ۶۰۵٬۰۰۰ برساند. برای مقدارگذاری نهایی هم باید تغییر هم‌زمان مدیر دیگری را تشخیص داد؛ تکرار امن فقط حل مسئلهٔ درصد نیست.
اگر همان کالا تخفیف فعال دارد، روشن کنید قیمت تخفیف حفظ، حذف یا طبق قاعدهٔ جدا محاسبه می‌شود. قیمت عادی جدید به‌تنهایی تضمین نمی‌کند مشتری همان مبلغ را در خرید ببیند؛ نمونه را در صفحهٔ محصول و سبد، با قواعد قیمت‌گذاری فروشگاه بررسی کنید.
اجرای چندمرحله‌ای را یک عملیات یکپارچه فرض نکنید
Products API مسیر batch دارد و محدودیت پیش‌فرض آن ۱۰۰ شیء است. این عدد را با ظرفیت واقعی هاست یکی نگیرید. برای اتصال اختصاصی، اندازهٔ هر بخش را با آزمون تعیین کنید، نتیجهٔ هر ردیف را نگه دارید و وضعیت‌هایی مثل آماده، موفق، ناموفق و نیازمند بررسی را قابل مشاهده کنید.
اگر بخشی از فایل اجرا شد و ارتباط قطع شد، ابتدا قیمت‌های فعلی و نتایج ثبت‌شده را بخوانید. «پاسخ نرسید» به معنای «هیچ تغییری انجام نشد» نیست. کارهای موفق را بی‌دلیل از اول اجرا نکنید؛ تکرار باید همان پیشنهاد تأییدشده را دنبال کند و تغییرهای خارج از این کار را بازنویسی نکند.
همچنین مرجع قیمت را روشن کنید: اگر اتصال حسابداری چند دقیقه بعد قیمت را از سیستم دیگری می‌فرستد، ویرایش محلی ممکن است بازنویسی شود. زمان اجرای تغییر و مسئول هماهنگی با اتصال‌ها را مشخص کنید؛ راهنمای تعریف مرجع داده در اتصال فروشگاه نقطهٔ شروع مناسبی است.
برگشت تغییرات باید محدود و قابل پیگیری باشد
پیشنهاد طراحی این است که برای هر ردیف، شناسهٔ عملیات، اجراکننده، مقدار قبل و بعد و زمان ثبت نگه داشته شود. هنگام برگشت، اگر قیمت فعلی هنوز همان مقدار ثبت‌شدهٔ این عملیات است، می‌توان بازگردانی مقدار قبلی را بررسی کرد؛ اگر مدیر دیگری آن را تغییر داده است، ردیف به‌عنوان تعارض برای بررسی باقی بماند. صرف داشتن قیمت قدیمی، مجوز بازنویسی تغییر جدید نیست.
بازیابی کل پایگاه داده برای اصلاح چند قیمت ممکن است سفارش‌های ثبت‌شده پس از پشتیبان را هم عقب ببرد. برای این سناریو، روش اصلاح محدود به اقلام و فیلدهای همین عملیات را از قبل تعریف کنید. اگر تاریخ‌های تخفیف هم در دامنهٔ تغییرند، آن‌ها نیز در سابقه و برنامهٔ برگشت ثبت شوند.
پنج آزمون پذیرش پیش از تحویل
- فایل دارای خطا: SKU تکراری، ردیف ناشناخته و مبلغ نامعتبر بسازید؛ خطاها پیش از اجرا مشخص شوند و کالای دیگری تغییر نکند.
- دو تنوع مستقل: فقط یک variation را در فایل قرار دهید؛ قیمت و ویژگی تنوع دیگر تغییر نکند.
- اجرای دوباره: یک کار تأییدشده را دوباره درخواست کنید؛ همان مقدار نهایی و یک سابقهٔ قابل توضیح باقی بماند.
- قطع میان اجرا: پس از چند ردیف ارتباط را قطع کنید؛ موفق‌ها و موارد نامشخص تفکیک و پیش از ادامه تطبیق شوند.
- تغییر هم‌زمان و برگشت: یک قیمت را پس از تأیید یا اجرا دستی عوض کنید؛ اجرا یا بازگردانی، تغییر جدید را بی‌خبر بازنویسی نکند.
این‌ها سناریوهای پیشنهادی‌اند و نتیجهٔ یک پروژهٔ واقعی را ادعا نمی‌کنند. نسخه‌های نرم‌افزار، ورودی و نتیجهٔ واقعی را در مدارک تحویل افزونه ثبت کنید. مجوز آماده‌سازی، تأیید و اجرای فایل را هم برای کارکنان جدا تعریف کنید؛ راهنمای دسترسی کارکنان ووکامرس به این تصمیم کمک می‌کند.
برای بررسی افزونه اختصاصی چه اطلاعاتی بفرستید؟
یک فایل نمونه بدون اطلاعات مشتری، نوع محصولات، واحد مبلغ، قواعد تخفیف و گردکردن، تعداد تقریبی ردیف‌ها، دفعات تغییر، مرجع قیمت و افراد تأییدکننده را آماده کنید. سپس مشخص کنید نسخهٔ اول چه پیش‌نمایش، گزارش خطا و مسیر برگشتی باید تحویل دهد. این ورودی‌ها را در شرح نیاز افزونه بنویسید تا دامنهٔ کار قابل برآورد شود.
منابع فنی
مستندات رسمی در ۲۰۲۶/۱۰/۰۶ بازبینی شدند؛ رفتار ابزار و افزونه‌های قیمت‌گذاری را با نسخه‌های نصب‌شده آزمون کنید.
ارسال نمونه فایل و قواعد قیمت‌گذاری خدمت ساخت افزونه اختصاصی ←