أتمتة طلبات WooCommerce لا تعني تحويل كل طلب مدفوع إلى Completed. الأتمتة الصحيحة تبدأ من فهم دورة الطلب ثم بناء قاعدة واضحة من Trigger → Conditions → Actions مع مراقبة الأخطاء وإمكانية إعادة المحاولة بدون تنفيذ العملية مرتين.
في المتاجر التي تبيع منتجات مادية، الدفع الناجح لا يعني أن الطلب تم شحنه أوتسليمه؛ لذلك يبقى الطلب غالبًا في Processing إلى أن يكتمل Fulfillment. أما الطلب الذي يحتوي فقط على منتجات Virtual وDownloadable فيمكن أن يصل إلى Completed بصورة تلقائية وفق سلوك WooCommerce الحالي.
المصدر الرسمي: راجع WooCommerce Order Statuses ووثائق Order Status Control قبل بناء أي Rule تغير حالات الطلبات تلقائيًا.
أول قاعدة: افصل الدفع عن تنفيذ الطلب
| السيناريو | الحالة المنطقية بعد الدفع | هل نكمل تلقائيًا؟ |
|---|---|---|
| منتج مادي مدفوع | Processing غالبًا | لا؛ ينتظر تجهيز/شحن/تسليم |
| Virtual + Downloadable فقط | Completed وفق إعداد وسلوك المتجر | يمكن |
| Bank Transfer / BACS | On hold إلى أن يتم تأكيد الدفع | لا |
| Cash on Delivery | حسب Workflow المتجر | لا تعتبره مدفوعًا تلقائيًا |
| فشل الدفع | Failed / Pending حسب السيناريو | لا |
| Refund | Refunded جزئيًا أوكليًا | تحتاج Flow منفصل |
المشكلة في كثير من إضافات “Autocomplete Orders” هي أن خيار All Orders قد يبدو مريحًا لكنه يتجاوز عمليات المخزن والشحن وخدمة العملاء. استخدمه فقط إذا كان نموذج العمل لا يحتاج Fulfillment بعد الدفع.
ما الحالات الأساسية في WooCommerce؟
- Pending payment: تم إنشاء الطلب ولم يُدفع بعد.
- On hold: الطلب ينتظر إجراءً مثل تأكيد دفع غير فوري.
- Processing: الدفع تم، لكن الطلب يحتاج تنفيذًا/تجهيزًا.
- Completed: تم تنفيذ الطلب وانتهت المعالجة.
- Cancelled: أُلغي الطلب.
- Refunded: تم رد قيمة الطلب كليًا أوجزئيًا.
- Failed: فشل الدفع أوالطلب.
في Checkout Blocks قد تظهر حالات داخلية مرتبطة بالمسودة أثناء إنشاء الطلب؛ لذلك لا تبنِ تكاملًا على افتراض أن كل Checkout يبدأ فورًا كـPending.
ابنِ الأتمتة كـWorkflow وليس كسطر واحد
أي Automation موثوقة يجب أن تحتوي ثلاثة أجزاء:
1. Trigger
حدث واضح مثل Order Created أوOrder Paid أوOrder Status Changed أوOrder Completed أوOrder Refunded.
2. Conditions
شروط تمنع تنفيذ Action على طلب غير مناسب، مثل Payment method وProduct type وOrder total وShipping method والحالة الحالية وهل نُفذت العملية سابقًا.
3. Action
الإجراء النهائي مثل تغيير الحالة أوإضافة Note أوإرسال Email أواستدعاء Webhook/API أوإنشاء مهمة Follow-up.
AutomateWoo وOrder Workflows: متى تستخدمهما؟
WooCommerce توفر أدوات رسمية للأتمتة مثل AutomateWoo، وتدعم Triggers وActions مرتبطة بالطلبات والعملاء. ليست هذه الأدوات إلزامية، لكنها مثال أفضل على منهج Rules/Triggers بدل الاعتماد على Plugin صغير يحول الحالة فقط.
المصادر الرسمية: AutomateWoo Triggers وAutomateWoo Actions.
مثال: إكمال طلب رقمي تلقائيًا
- Trigger: Payment completed.
- Condition: كل المنتجات داخل الطلب Virtual + Downloadable.
- Condition: لا يوجد Fulfillment خارجي مطلوب.
- Action: Completed.
- Action: إرسال Email/Download access عند الحاجة.
WooCommerce Core تتعامل أصلًا مع كثير من هذا السيناريو؛ لا تضف Automation مكررة إذا النظام ينفذ المطلوب بالفعل.
مثال: طلب مادي مدفوع
- Trigger: Payment completed.
- Action: يظل Processing.
- Action: إرسال الطلب للمخزن/شركة الشحن.
- Action: إضافة Tracking عند وصوله.
- Trigger لاحق: Fulfillment delivered أوتأكيد موظف.
- Action لاحق: Completed.
هذا يمنع إرسال Completed email للعميل قبل خروج المنتج من المخزن.
Bank Transfer وCOD
لا تستخدم Event مثل “Order Created” لتعتبر الطلب مدفوعًا. افصل إنشاء الطلب عن Payment confirmation، ولا ترسل Fulfillment قبل استيفاء شرطك التجاري، وضع Review للحالات التي تبقى On hold فترة طويلة.
HPOS: شرط أساسي لأي أتمتة حديثة
High-Performance Order Storage (HPOS) هي بنية تخزين الطلبات الحديثة في WooCommerce، وأصبحت افتراضية للتركيبات الجديدة منذ WooCommerce 8.2. بدل افتراض أن الطلب موجود دائمًا في wp_posts وwp_postmeta، تستخدم WooCommerce جداول مخصصة مثل _wc_orders ومجموعة جداول مرتبطة.
المصدر الرسمي: WooCommerce HPOS.
أي Plugin أوCustom code للأتمتة يجب أن يعلن Compatibility مع HPOS، ويستخدم WooCommerce CRUD مثل wc_get_order() بدل SQL مباشر على Posts، ويتم اختباره مع HPOS enabled.
لا تعدّل الطلبات بـSQL مباشر
<?php
$order = wc_get_order( $order_id );
if ( $order ) {
$order->update_status( 'processing', 'Workflow updated the order.' );
}
تغيير post_status أوMeta يدويًا من قاعدة البيانات يتجاوز Hooks وCaches وSync والـbusiness logic.
Webhooks وAPIs: اجعل التنفيذ Idempotent
Payment gateways وShipping services قد تعيد إرسال Webhook إذا حدث Timeout. لذلك لا تفترض أن الحدث سيصل مرة واحدة فقط.
- خزن External event ID أوعلامة أن Action نُفذت.
- قبل التنفيذ تحقق من الحالة الحالية.
- استخدم Idempotency key إذا API الخارجية تدعمه.
- اجعل Retry آمنًا.
- سجل Result/HTTP code.
مزامنة المخزون: لا تضاعف منطق WooCommerce
WooCommerce لديها منطق خاص لتقليل/إعادة المخزون مع دورة الطلب. لا تضف Workflow ثانية تقلل الكمية عند كل Status change إلا إذا لديك نظام Inventory خارجي وله Source of Truth واضح.
في تكامل ERP/WMS حدد من هو Source of Truth، ومتى يتم Reservation وDeduction، وماذا يحدث عند Refund/Cancel، وكيف تمنع Race conditions.
لروتين المخزون والطلبات اليومي راجع دليل إدارة متجر WooCommerce 2026.
الخصومات المجدولة ليست Order Automation
جدولة Sale Price أوDiscount Rules عملية تسعير منفصلة عن معالجة الطلب. إذا استخدمت Rules للأسعار، اختبر Timezone وCoupons stacking والضرائب والكاش ووقت بداية ونهاية العرض.
رسائل WooCommerce: اربط الرسالة بالحالة الصحيحة
إذا أجبرت الطلب المادي على Completed مبكرًا، قد ترسل للعميل Email يوحي أن الطلب انتهى بينما لم يبدأ الشحن. راجع Processing/Completed/Refunded/Failed emails، وأي رسائل Plugin أوShipping إضافية.
ولو البريد نفسه لا يصل، استخدم دليل حل مشاكل البريد في WordPress.
Background jobs وAction Scheduler
عمليات مثل إرسال Batch emails أوSync مع ERP لا يجب أن تعمل دائمًا داخل Page request واحد. نفذ العمليات الثقيلة Async، راقب Failed actions، ضع Retry policy محددة، ولا تجعل Job تعيد نفسها بلا حد.
Logs والمراقبة
لكل Workflow حرجة سجّل Order ID وTrigger وConditions result وAction وExternal request ID وHTTP/API result ووقت التنفيذ وRetry count. لا تسجل Card data أوSecrets.
اختبارات قبل Production
| السيناريو | ما يجب اختباره |
|---|---|
| Card success | Paid مرة واحدة + Processing/Completed الصحيح |
| Card failure | لا Fulfillment ولاEmail نجاح |
| Duplicate webhook | Action لا تتكرر |
| COD | لا تعتبر Paid مبكرًا |
| BACS | On hold حتى التأكيد |
| Virtual/downloadable | إكمال وتسليم Access صحيح |
| Physical | Processing حتى Fulfillment |
| Refund | المخزون والرسائل حسب القاعدة |
| HPOS | Plugin/custom code متوافق |
متى لا تؤتمت؟
- إلغاء Orders بسبب Flag واحد غير موثوق.
- Refund تلقائي بلا سقف أوReview.
- شحن Order قبل التحقق من Fraud/manual review عند الحاجة.
- تغيير Stock من أكثر من System بدون Source of Truth.
ابدأ بالمهام القابلة للعكس والمراقبة: Notes، Tags، Notifications، Queueing، ثم وسّع Automation بعد قياس النتائج.
Checklist نهائية
- كل Workflow لها Trigger محدد.
- Conditions تمنع الطلبات غير المناسبة.
- الدفع منفصل عن Fulfillment.
- لا Auto-complete للمنتجات المادية بلا سبب تشغيلي.
- HPOS compatibility مؤكدة.
- CRUD بدل SQL المباشر.
- Webhooks idempotent.
- Retries محدودة ومراقبة.
- Emails مرتبطة بالحالة الصحيحة.
- Logs بدون Secrets.
- Staging test شامل.
- خطة Rollback/Disable سريعة.
وإذا كنت ما زلت في مرحلة إعداد المتجر الأساسية، راجع إعداد WooCommerce بعد التثبيت قبل Workflows متقدمة.
الخلاصة
أتمتة WooCommerce في 2026 يجب أن تحافظ على دورة الطلب بدل اختصارها. Order Paid لا يساوي Order Fulfilled. استخدم الحالات الصحيحة، Conditions واضحة، HPOS-compatible APIs، Webhooks idempotent، Logs وRetries مراقبة، واختبر السيناريوهات الفاشلة بقدر نجاح الدفع.
1 تعليق