پیامک وضعیت سفارش و کد رهگیری ووکامرس؛ چه زمانی ارسال شود؟
پیامک سفارش وقتی مفید است که خبر درست را در زمان درست به مشتری برساند. پیش از نصب یا سفارش افزونه، رویداد ارسال، منبع کد رهگیری، مسئول اصلاح و روش پیگیری خطا را مشخص کنید. تغییر وضعیت سفارش به‌تنهایی همیشه به معنی پرداخت قطعی یا تحویل بسته به شرکت حمل نیست.
افزونه آماده کافی است یا توسعهٔ اختصاصی لازم داریم؟
اگر یک سرویس پیامک دارید و نیازتان اطلاع‌رسانی سادهٔ ثبت سفارش یا ورود دستی کد رهگیری است، ابتدا قابلیت‌های افزونهٔ آماده را در فروشگاه آزمایشی بررسی کنید. پوشش سرویس پیامک، الگوهای موردنیاز، سازگاری با نسخهٔ ووکامرس و تجربهٔ اپراتور مهم‌تر از تعداد امکانات تبلیغ‌شده است.
نیاز به چند بسته برای یک سفارش، دریافت کد از سامانهٔ حمل، تأیید مدیر پیش از ارسال یا گزارش قابل پیگیری می‌تواند توسعهٔ تکمیلی را توجیه کند. قبل از تصمیم، محدودیت دقیق راهکار موجود را بنویسید؛ راهنمای انتخاب افزونه آماده یا اختصاصی به همین تصمیم کمک می‌کند.
برای هر پیام، رویداد و شرط ارسال تعریف کنید
مستندات ووکامرس وضعیت‌های سفارش را از هم جدا می‌کند: Pending payment انتظار پرداخت است، Processing معمولاً سفارش پرداخت‌شده و در انتظار انجام است و Completed انجام‌شدن سفارش را نشان می‌دهد. این عنوان‌ها به‌تنهایی سند تحویل مرسوله به حمل‌کننده نیستند. برای کالاهای دیجیتال یا جریان‌های سفارشی هم رفتار را روی ترکیب واقعی فروشگاه بررسی کنید.
- ثبت درخواست خرید: متن فقط دریافت سفارش را اعلام کند؛ عبارت «پرداخت تأیید شد» به رویداد تأیید پرداخت وابسته باشد.
- تأیید پرداخت: شرط را با وضعیت و رفتار درگاه هماهنگ کنید؛ سفارش منتظر بررسی یا پرداخت دیرهنگام را جدا در نظر بگیرید.
- آماده‌سازی: تنها وقتی خبر بدهید که این مرحله در فرایند شما ثبت می‌شود؛ صرف بازکردن سفارش توسط اپراتور کافی نیست.
- ارسال مرسوله: کد معتبر، شرکت حمل و رویداد تأیید ارسال لازم باشد. اگر فقط برچسب ساخته‌اید، متن نباید تحویل بسته به حمل‌کننده را قطعی جلوه دهد.
- لغو یا اصلاح: خبر تازه باید علت قابل فهم داشته باشد؛ سیاست پیام اصلاح کد را از ارسال دوبارهٔ همان پیام جدا کنید.
این قواعد پیشنهاد طراحی فرایندند؛ ووکامرس به‌تنهایی همهٔ مراحل عملیاتی انبار یا گزارش تحویل پیامک را تعیین نمی‌کند.
کد رهگیری متعلق به مرسوله است یا سفارش؟
در مثال فرضی، یک سفارش سه قلم دارد: دو قلم امروز در یک بسته و قلم سوم فردا در بستهٔ دیگری ارسال می‌شود. اگر فقط یک فیلد کد روی سفارش داشته باشید، ثبت کد دوم ممکن است کد اول را بپوشاند. در شرح نیاز روشن کنید آیا هر سفارش دقیقاً یک بسته دارد یا ساختار چندمرسوله‌ای لازم است.
برای هر مرسوله، شناسهٔ داخلی، شرکت حمل، کد رهگیری، زمان ثبت، مرحلهٔ عملیاتی و اقلام مربوط را تعریف کنید. اگر داده از API می‌آید، مسئول اصلاح و مرجع نهایی آن هم مشخص باشد. API سفارش ووکامرس متاداده را پشتیبانی می‌کند، اما نام فیلدها و قرارداد رهگیری را باید با افزونه یا سامانهٔ حمل مورد استفاده هماهنگ کنید؛ یک کلید عمومی را برای همهٔ افزونه‌ها فرض نکنید.
ورود دوبارهٔ همان کد نباید خودکار خبر تازه‌ای بسازد. اصلاح واقعی کد، رویداد جدا و نیازمند ثبت سابقه باشد. شمارهٔ سفارش هم جای کد رهگیری شرکت حمل را نمی‌گیرد.
چطور جلوی پیامک تکراری را بگیریم؟
ابتدا بررسی کنید چند افزونه یا اتصال برای یک رویداد پیام می‌فرستند. ممکن است افزونهٔ پیامک، افزونهٔ حمل و یک اتصال اختصاصی هم‌زمان فعال باشند. یک مسئول برای هر نوع پیام تعیین کنید و تنظیمات بقیهٔ مسیرها را با آن هماهنگ کنید.
برای مسیر اختصاصی، پیشنهاد می‌شود هر اعلان یک شناسهٔ پایدار داشته باشد؛ مثلاً ترکیب سفارش، مرسوله، نوع خبر و نسخهٔ رویداد. ثبت تکراری یک رویداد باید به همان سابقه برسد. ثبت و صف‌گذاری این شناسه هم باید در برابر اجرای هم‌زمان کنترل شود؛ بررسی سادهٔ «قبلاً فرستاده‌ایم؟» بدون کنترل هم‌زمانی کافی نیست.
شناسهٔ درخواست سرویس پیامک را نگه دارید. اگر پاسخ درخواست به‌دلیل قطع ارتباط نامشخص است، ارسال کورکورانه ممکن است تکرار ایجاد کند. ابتدا امکان استعلام همان درخواست یا پشتیبانی سرویس از شناسهٔ تکرار را بررسی کنید. در نبود این قابلیت، سیاست بررسی دستی و خطر تکرار را در دامنهٔ پروژه ثبت کنید؛ وعدهٔ جلوگیری مطلق از تکرار ندهید.
پذیرش سرویس، تحویل پیام و خواندن مشتری فرق دارند
در گزارش افزونه، «در صف»، «پذیرفته‌شده توسط سرویس»، «تحویل گزارش‌شده»، «ناموفق» و «نتیجه نامشخص» را مخلوط نکنید. نام و معنای وضعیت‌ها باید از مستندات سرویس انتخاب‌شده گرفته شود. پذیرش درخواست در API به‌تنهایی اثبات نمی‌کند پیام روی گوشی رسیده یا مشتری آن را خوانده است.
گزارش پیشنهادی شامل رویداد، زمان، شناسهٔ درخواست، نتیجهٔ سرویس و اقدام بعدی است. شمارهٔ تلفن در نمایش عمومی یا لاگ مشترک کامل ثبت نشود و کلید API در دسترس اپراتورهای نامرتبط قرار نگیرد. مدت نگهداری و افراد مجاز را مشخص کنید. برای صف‌های دیرهنگام، راهنمای کارهای زمان‌بندی‌شدهٔ ووکامرس مسیر تشخیص اجرا را توضیح می‌دهد؛ نتیجهٔ سرویس پیامک همچنان باید جدا بررسی شود.
پنج آزمون پیش از انتشار
آزمون‌های زیر پیشنهادی‌اند؛ با سفارش و شمارهٔ آزمایشی و امکانات تست سرویس اجرا شوند. این فهرست گزارش نتیجهٔ پروژهٔ مشتری نیست.
- پرداخت ناموفق و سپس موفق: متن تأیید پرداخت پیش از موفقیت فرستاده نشود و تلاش مجدد خبر موفق را تکراری نسازد.
- ثبت هم‌زمان کد: ثبت دوبارهٔ یک رویداد توسط اپراتور یا اتصال بیرونی، فقط یک اعلان منطقی ایجاد کند.
- دو بسته: هر پیام کد بستهٔ درست را داشته باشد و ثبت بستهٔ دوم سابقهٔ اول را نپوشاند.
- قطع ارتباط: پاسخ نامشخص از شکست قطعی جدا ثبت شود؛ استعلام یا بررسی دستی پیش از ارسال مجدد انجام شود.
- اصلاح و دسترسی: کاربر غیرمجاز نتواند کد یا اعلان را تغییر دهد؛ اصلاح مجاز با سابقه و متن اصلاحی تعریف‌شده ثبت شود.
تست را با نسخه‌های واقعی وردپرس، ووکامرس، درگاه و افزونهٔ حمل ثبت کنید. اگر ابزار به صفحهٔ مدیریت سفارش وابسته است، سازگاری HPOS را هم بررسی کنید. جزئیات پذیرش در چک‌لیست تحویل افزونه آمده است.
برای برآورد پروژه چه اطلاعاتی آماده کنیم؟
- سرویس پیامک و مستندات API، روش ارسال و وضعیت‌های قابل استعلام
- فهرست پیام‌ها با رویداد، شرط، گیرنده و متن نمونهٔ بدون اطلاعات مشتری
- منبع کد رهگیری و نیاز به یک یا چند مرسوله برای هر سفارش
- قواعد اصلاح، ارسال مجدد، پاسخ نامشخص و دسترسی کارکنان
- نسخه‌ها، افزونه‌های فعلی، محیط تست و معیار پذیرش
این ورودی‌ها را در شرح نیاز افزونه بنویسید. امکانات الگو، محدودیت خط و گزارش تحویل را با سرویس انتخاب‌شده تأیید کنید؛ این راهنما تعرفه یا تضمین تحویل پیامک ارائه نمی‌کند.
منابع و محدودهٔ راهنما
مستندات رسمی در ۷ اکتبر ۲۰۲۶ بررسی شدند. قواعد مرسوله، تکرار و گزارش در این مقاله پیشنهاد طراحی‌اند و باید با سرویس و افزونه‌های فروشگاه تطبیق داده شوند.