كيف تُؤتمت متجرك الإلكتروني بربط ووكومرس بـn8n؟

هذا المقال مكتوب لصاحب متجر يعمل فعلًا: لديك طلبات يومية، وموظّف أو اثنان ينسخان البيانات يدويًا بين لوحة ووكومرس وبرنامج الفواتير وشركة الشحن وملف إكسل. ما ستقرأه هنا ليس عرضًا نظريًا لقدرات الأداة، بل ستّة سيناريوهات كاملة قابلة للتنفيذ اليوم، مبنية على ما يدعمه n8n وووكومرس فعليًا — لا على وعود. وإن كنت جديدًا على الأداة نفسها ومفاهيمها (العُقد، المُشغّلات، الاعتمادات) فابدأ من الدليل الشامل لأتمتة الأعمال بـn8n ثم ارجع إلى هنا للتطبيق على المتجر.

لماذا تستحقّ العمليات الداخلية للمتجر أن تُؤتمت؟

المتجر الإلكتروني ليس صفحة منتجات وزرّ شراء. خلف كل طلب سلسلة من الخطوات الإدارية المتكرّرة: قراءة الطلب، التحقّق من توفّر الصنف، تحديث المخزون، إصدار فاتورة، إبلاغ المستودع، إنشاء بوليصة شحن، إرسال رقم التتبّع للعميل، تسجيل العميل في قائمة التسويق، ثم في آخر الشهر تجميع كل ذلك في تقرير. كل خطوة منها بسيطة بمفردها، ومجموعها هو ما يستهلك يوم العمل ويولّد الأخطاء.

الفارق بين المتجر الصغير والمتجر المتوسط ليس عدد الطلبات بقدر ما هو قدرة العمليات الداخلية على الاحتمال. متجر يستقبل خمسة طلبات يوميًا يمكن إدارته بذاكرة صاحبه وملف إكسل واحد. المتجر نفسه عند خمسين طلبًا يوميًا يبدأ في فقد الطلبات بين التبويبات: صنف بيع وهو غير متوفّر، فاتورة صدرت مرتين، عميل لم يصله رقم التتبّع فتحوّل إلى تذكرة دعم. الأتمتة هنا ليست ترفًا تقنيًا بل هي الطريقة الوحيدة لتنمو دون أن تتضاعف تكلفة التشغيل بنفس نسبة نموّ المبيعات.

الميزة الثانية أهمّ من توفير الوقت: الاتّساق. الموظّف المتعب ينسى خطوة، والموظّف الجديد ينفّذها بترتيب مختلف، وأنت في إجازة تنفّذها بطريقة ثالثة. سير العمل المؤتمت ينفّذ الخطوات نفسها بالترتيب نفسه في كل مرّة، وإن أخطأ أخطأ بشكل قابل للاكتشاف والإصلاح مرّة واحدة لكل الحالات المستقبلية. هذا وحده يبرّر الاستثمار في بنائه.

لنضع أرقامًا تقريبية على الكلام. الجدول التالي يقدّر الوقت المستهلك شهريًا في متجر يعالج نحو 300 طلب في الشهر (عشرة طلبات يوميًا)، وهو حجم واقعي لمتجر عربي صغير-متوسّط:

سبع وثلاثون ساعة شهريًا هي أسبوع عمل كامل تقريبًا. وهذا التقدير متحفّظ لأنه لا يحسب تكلفة الأخطاء: الطلب الذي شُحن إلى العنوان الخطأ، أو الصنف الذي بيع بعد نفاده فاضطررت لإلغاء الطلب واعتذار العميل. لكن الأمانة تقتضي ملاحظة مقابلة: بناء هذه الأتمتة يستهلك وقتًا أوّليًا يتراوح بين عدّة ساعات ويومين حسب عدد السيناريوهات، ويحتاج مراجعة دورية. الأتمتة ليست مجّانية، لكنها تُدفَع مرّة وتُستهلك شهورًا.

ما الذي يجعل ووكومرس قابلًا للأتمتة من الأساس؟

ووكومرس ليس نظامًا مغلقًا. هو إضافة ووردبريس مفتوحة المصدر تكشف بياناتها عبر واجهة برمجية معيارية، وتُطلق أحداثًا عند تغيّر تلك البيانات. هاتان القدرتان — القراءة/الكتابة عبر REST API، والإشعار الفوري عبر Webhooks — هما كل ما تحتاجه أي أداة أتمتة خارجية.

الأولى: REST API. تجد إعداداتها في لوحة ووردبريس: ووكومرس ← الإعدادات ← تبويب "متقدّم" ← REST API. من هناك تُنشئ مفتاحًا جديدًا، تختار المستخدم الذي سيُنسب إليه، وتكتب وصفًا يوضّح الغرض، ثم تختار الصلاحية. عند الحفظ يعرض لك ووكومرس Consumer Key وConsumer Secret مرّة واحدة فقط — انسخهما فورًا وخزّنهما في مدير كلمات مرور، فلن تستطيع رؤية السرّ مرّة أخرى وستضطر لإنشاء مفتاح بديل.

الثانية: Webhooks. في التبويب نفسه (متقدّم) تجد قسم Webhooks. الـwebhook في ووكومرس يتكوّن من: اسم، حالة (فعّال/معطّل)، موضوع (Topic) يحدّد الحدث الذي يُطلقه، عنوان تسليم (Delivery URL) هو العنوان الذي سيستقبل الحمولة، وسرّ (Secret) يُستخدم لتوقيع الطلب. المفهوم نفسه مشروح في صفحة الويكي عن الـWebhook، لكن ما يهمّنا هنا تطبيقه: العنوان سيكون عنوان عقدة Webhook في n8n، والسرّ سيكون وسيلتك للتحقّق من أن الطلب الوارد صادر فعلًا من متجرك.

لماذا يهمّ السرّ؟ لأن عنوان الـwebhook في n8n عنوان عام على الإنترنت. أي شخص يعرفه يستطيع إرسال حمولة مزيّفة تُشبه طلبًا حقيقيًا، فيصدر نظامك فاتورة لطلب لا وجود له، أو يخصم من المخزون بلا سبب. ووكومرس يوقّع كل حمولة يرسلها بترويسة توقيع محسوبة من السرّ ومحتوى الطلب. الممارسة الصحيحة أن تُضيف في n8n عقدة تتحقّق من هذا التوقيع قبل أي معالجة، أو — كحدّ أدنى عملي — أن تجعل أوّل خطوة في السير هي جلب الطلب من REST API برقمه للتأكّد من وجوده فعلًا بالبيانات نفسها. الحمولة الواردة تُعامل كإشارة، والمصدر الموثوق للحقيقة هو المتجر نفسه.

صلاحيات مفاتيح REST API — امنح الأقلّ

الخطأ الأكثر شيوعًا عند الربط هو إنشاء مفتاح واحد بصلاحية قراءة/كتابة واستخدامه في كل شيء. هذا يعني أن أي تسريب لهذا المفتاح يمنح المهاجم قدرة تعديل الطلبات والمنتجات والعملاء. القاعدة أن تُنشئ مفتاحًا منفصلًا لكل سير عمل بأدنى صلاحية يحتاجها:

وثمّة تفصيلات إجرائية تستحقّ الالتزام بها:

هذا كلّه جزء من صورة أوسع لأمن المتجر — المفاتيح والتوقيع طبقة واحدة فقط، وبقيتها (تحديثات، صلاحيات، جدار حماية، مراقبة) مشروحة في دليل تأمين المتجر الإلكتروني.

حالات الطلب في ووكومرس: أيّها يصلح مُشغّلًا لأي أتمتة؟

هذه هي النقطة التي يُخطئ فيها معظم من يبني أوّل أتمتة له. الطلب في ووكومرس ليس كائنًا ثابتًا بل يمرّ بحالات، وكل حالة تعني شيئًا مختلفًا تشغيليًا. تشغيل أتمتة الفوترة على الحالة الخطأ يعني فواتير لطلبات لم يُدفع ثمنها أصلًا.

القاعدة العملية: processing هي بوّابة التنفيذ. عندها تكون قد استلمت المال (أو أكّدت الدفع عند الاستلام حسب إعدادك) وصار الطلب واقعيًا. الحالات قبلها للمتابعة والتذكير، والحالات بعدها للتسوية والمتابعة اللاحقة. وانتبه لتفصيل مهمّ: بعض بوّابات الدفع تنقل الطلب مباشرة إلى completed للمنتجات الرقمية دون المرور بـprocessing، فإن كنت تبيع منتجات رقمية اجعل سيرك يتعامل مع الحالتين. سلوك كل بوّابة وتأثيرها في حالة الطلب مشروح في دليل بوّابات الدفع في ووكومرس.

هذه حمولة مختصرة لطلب في حالة processing كما تصل من ووكومرس (اختصرنا الحقول غير الجوهرية):

{
  "id": 4821,
  "number": "4821",
  "status": "processing",
  "currency": "SAR",
  "date_created": "2026-08-03T11:24:07",
  "total": "349.00",
  "payment_method_title": "بطاقة مدى",
  "billing": {
    "first_name": "سارة",
    "last_name": "العتيبي",
    "email": "sara@example.com",
    "phone": "05xxxxxxxx",
    "city": "الرياض"
  },
  "shipping": {
    "address_1": "حي النرجس، شارع الأمير",
    "city": "الرياض",
    "country": "SA"
  },
  "line_items": [
    {
      "id": 1,
      "name": "عباية كلاسيك — أسود / M",
      "product_id": 918,
      "variation_id": 926,
      "sku": "ABY-CL-BLK-M",
      "quantity": 1,
      "total": "279.00"
    },
    {
      "id": 2,
      "name": "حزام جلد",
      "product_id": 640,
      "sku": "BLT-LTH-01",
      "quantity": 1,
      "total": "70.00"
    }
  ]
}

لاحظ حقلين ستستعملهما كثيرًا: id (رقم الطلب، مفتاح منع التكرار)، وvariation_id الذي يظهر عند المنتجات المتغيّرة ويحدّد المتغيّر المحدَّد (اللون/المقاس). أتمتة المخزون التي تتجاهل variation_id وتخصم من المنتج الأب ستُفسد مخزونك، وهذه أحد أهمّ فروق التعامل مع المنتجات المتغيّرة في ووكومرس.

ما الذي يوفّره n8n لووكومرس تحديدًا؟

يقدّم n8n لووكومرس عنصرين جاهزين: عقدة WooCommerce للإجراءات، وWooCommerce Trigger للاستماع للأحداث. عقدة WooCommerce تعمل على ثلاثة موارد — المنتجات والطلبات والعملاء — بعمليات الإنشاء والجلب والتحديث والحذف. أما WooCommerce Trigger فيسجّل webhook في متجرك تلقائيًا ويستمع لأحداث مثل إنشاء طلب أو تحديثه، وإنشاء منتج أو تحديثه أو حذفه، وأحداث العملاء والكوبونات.

انتبه إلى ما لا توفّره العقدة: هي لا تغطّي كل ما في واجهة ووكومرس البرمجية. الكوبونات مثلًا متاحة كحدث في المُشغّل لكن العمليات المباشرة عليها ليست ضمن موارد العقدة، وكذلك التقارير وطرق الشحن والاسترجاعات كسجلّات مستقلّة. الحلّ في هذه الحالات ليس معقّدًا: استخدم عقدة HTTP Request مع اعتماد Basic Auth يحمل الـConsumer Key والـSecret، وخاطب نقطة النهاية التي تريدها مباشرة. هذا المزيج — عقدة جاهزة لما هو مدعوم، وHTTP لما ليس مدعومًا — هو النمط الذي ستبني به معظم سيناريوهاتك.

اختيار المُشغّل قرار معماري لا تفصيلة. الأحداث الفورية تحتاج webhook، والمراجعات الدورية تحتاج جدولة، والمزج بينهما في السير الواحد وصفة للتعقيد. أمثلة أوسع لأنماط المُشغّلات وبناء الـworkflows تجدها في أمثلة عملية لأتمتة المهام بـn8n.

قبل أي سيناريو: كيف تمنع معالجة الطلب نفسه مرّتين؟

هذه أهمّ فقرة في المقال، وأكثر ما يُتجاهَل. الـwebhook ليس ضمانًا بالتسليم مرّة واحدة. قد يصل مرتين لأسباب طبيعية تمامًا: n8n تأخّر في الردّ فأعاد ووكومرس المحاولة، أو حدث تحديث ثانٍ على الطلب فأطلق الحدث مجدّدًا، أو أعدت تفعيل سير عمل فأُعيد إرسال أحداث معلّقة، أو ضغط موظّف زرّ تحديث الحالة مرّتين.

النتيجة عند غياب الحماية: فاتورتان بالرقم نفسه لعميل واحد، خصم المخزون مرتين لطلب واحد، رسالتان متطابقتان للعميل، صفّان في تقرير المبيعات. الأولى محرجة، والثانية تُفسد المخزون، والرابعة تُفسد أرقامك.

الحلّ مبدأ اسمه idempotency: أن يعطي تنفيذ العملية مرّة أو عشر مرّات النتيجة نفسها. تطبيقه عمليًا يقوم على مفتاح فريد لكل طلب — وأوضح مفتاح متاح هو رقم الطلب id — وسجلّ يخبرك هل عُولج هذا الرقم من قبل.

كيف تُنفّذها في n8n:

1. أوّل عقدة بعد المُشغّل تستخرج id من الحمولة وتضعه في حقل مسمّى بوضوح مثل orderKey.
2. عقدة تقرأ من "سجلّ المعالجة": صفحة في Google Sheets، أو جدول في قاعدة بيانات، أو مفتاح في مخزن قيم. تبحث عن orderKey.
3. عقدة IF: إن وُجد ⇒ المسار ينتهي بـNoOp (لا شيء). إن لم يوجد ⇒ يكمل السير.
4. بعد نجاح آخر إجراء فعلي (لا قبله)، عقدة تكتب orderKey في السجلّ مع الطابع الزمني ونتيجة التنفيذ.

ترتيب الخطوتين 3 و4 مقصود. لو سجّلت المفتاح قبل تنفيذ الإجراء ثم فشل الإجراء، سيظنّ السير في المحاولة التالية أن الطلب عولج بينما لم يحدث شيء — وهذا أسوأ من التكرار لأنه فقدان صامت. سجّل بعد النجاح، وتقبّل احتمال تكرار نادر في حالة انقطاع بين الإجراء والتسجيل. إن كان الإجراء بالغ الحساسية (إصدار فاتورة ضريبية مثلًا) فأضف حقل حالة في السجلّ: started قبل التنفيذ وdone بعده، وعالج القيم العالقة على started بمراجعة يدوية.

نقطة إضافية للطلبات التي تُحدَّث لا تُنشأ: مفتاح orderKey وحده لا يكفي لأن الطلب نفسه سيُحدَّث مرارًا بحكم دورة حياته. اجعل المفتاح مركّبًا من رقم الطلب والغرض: 4821:invoice و4821:stock و4821:tracking. هكذا يمنع التكرار داخل كل سيناريو دون أن يمنع سيناريو آخر من العمل على الطلب نفسه.

السيناريو الأول: معالجة الطلب الجديد آليًا

الهدف: فور تحوّل الطلب إلى processing، تُجهَّز بطاقة عمل للمستودع وتصل تنبيهات الفريق دون أن يفتح أحد لوحة التحكّم.

المُشغّل: WooCommerce Trigger على حدث تحديث الطلب (أو webhook أصلي بموضوع تحديث الطلب).

العُقد بالترتيب: Trigger ← Set (استخراج id والحالة) ← IF (الحالة = processing؟) ← بحث في سجلّ المعالجة ← IF (غير معالَج؟) ← WooCommerce: Get Order (تحقّق من المصدر) ← Set (تهيئة بطاقة العمل) ← Google Sheets: إضافة صفّ في ورقة "طلبات للتجهيز" ← تنبيه الفريق ← تسجيل 4821:processed.

لماذا نجلب الطلب مجدّدًا بعقدة Get Order؟ لأن الحمولة الواردة يمكن تزويرها، ولأنها قد تكون قديمة إن وصلت متأخّرة. الجلب من المصدر يضمن أنك تعمل على الحالة الحالية الحقيقية. هذه خطوة إضافية بمقابل واحد فقط: استدعاء API بسيط لكل طلب.

مثال ملموس: متجر عبايات في الرياض. يصل الطلب 4821 بحالة processing. يتحقّق السير من أنه لم يُعالج، يجلبه من المتجر، يبني صفًّا يحوي رقم الطلب واسم العميل والمدينة والأصناف مع الـSKU والكميات وطريقة الدفع، يضيفه إلى ورقة المستودع، ثم يرسل سطرًا واحدًا في قناة الفريق: «طلب 4821 — الرياض — صنفان — جاهز للتجهيز». الموظّف في المستودع يفتح الورقة ويجهّز، بلا وصول إلى لوحة ووكومرس أصلًا — وهذه ميزة أمنية إضافية.

السيناريو الثاني: تحديث المخزون والتنبيه قبل النفاد

الهدف: متابعة الكميات آليًا، وتنبيه المشتريات قبل نفاد الصنف لا بعده.

ووكومرس يدير المخزون على مستويين: المنتج البسيط، والمتغيّر المستقلّ داخل المنتج المتغيّر. وهو يخصم الكمية تلقائيًا عند الطلب إن فعّلت إدارة المخزون. لذلك السيناريو الافتراضي هنا ليس الخصم بل المراقبة والتنبيه — لا تُعِد بناء ما يفعله المتجر أصلًا، وإلا خصمت الكمية مرّتين.

المُشغّل: Schedule كل ساعة أو ساعتين (لا webhook).

العُقد بالترتيب: Schedule ← WooCommerce: Get Many Products ← Code/Filter (اختيار ما كميته ≤ حدّ التنبيه) ← IF (هل توجد نتائج؟) ← Set (تنسيق قائمة موجزة) ← تنبيه المشتريات + صفّ في ورقة المتابعة.

متى تحتاج الكتابة فعلًا؟ عندما يكون مصدر الحقيقة للمخزون خارج المتجر: نظام ERP، أو ملف يرفعه المورّد، أو مستودع مادّي يُجرَد يدويًا. حينها يقرأ السير الكمية من المصدر الخارجي ويكتبها إلى ووكومرس عبر عقدة WooCommerce أو HTTP.

مثال ملموس: متجر إلكترونيات يبيع شواحن بثلاثة أنواع. حدّ التنبيه 5 قطع. في تمام كل ساعة يفحص السير المنتجات، فيجد أن CHG-USBC-65W وصل إلى 4، فيرسل: «تنبيه مخزون — شاحن 65W — المتبقّي 4 — SKU: CHG-USBC-65W». المشتريات تطلب من المورّد قبل انقطاع البيع.

سحابة الأتمتة n8n من wpressly

شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.

ابدأ مع سحابة الأتمتة

السيناريو الثالث: إنشاء الفاتورة وتسجيلها

الهدف: إصدار مستند فاتورة عند تأكيد الدفع، وإرساله للعميل، وأرشفته في سجلّ منظّم.

المُشغّل: حدث تحديث الطلب، بفلتر processing (أو completed للمنتجات الرقمية).

العُقد بالترتيب: Trigger ← Set (orderKey = 4821:invoice) ← بحث في السجلّ ← IF ← WooCommerce: Get Order ← Set (تجهيز حقول الفاتورة: الرقم، التاريخ، بيانات العميل، البنود، الإجمالي، الضريبة) ← HTTP Request إلى خدمة الفوترة ← بريد للعميل بالمرفق ← تسجيل 4821:invoice مع رقم الفاتورة الناتج.

مفتاح النجاح هنا هو ترقيم الفواتير. لا تولّد الرقم داخل n8n بعدّاد محلّي، لأن أي إعادة تنفيذ ستُنتج أرقامًا مكرّرة أو فجوات. اجعل نظام الفوترة نفسه هو من يمنح الرقم التسلسلي، وخزّن الرقم الذي أعاده في سجلّك مقابل رقم الطلب. هكذا تعرف دائمًا أي فاتورة تخصّ أي طلب، وتكتشف أي ازدواج فورًا.

مثال ملموس: متجر ملابس يبيع لأفراد وشركات. يضيف السير عقدة IF بعد جلب الطلب: هل حقل «الرقم الضريبي» في بيانات الفوترة ممتلئ؟ إن نعم، يوجّه المسار إلى قالب فاتورة الشركات ويرسل نسخة إلى بريد المحاسبة أيضًا. إن لا، يستخدم قالب الأفراد المبسّط. سير واحد، فرعان، وقاعدة لا تُنسى أبدًا.

السيناريو الرابع: تحديث بيانات الشحن ورقم التتبّع

الهدف: عندما يصدر المستودع بوليصة الشحن، يُحفظ رقم التتبّع في الطلب وتُحدَّث حالته ويُبلَّغ العميل — بلا خطوة يدوية واحدة.

هذا السيناريو يسير في الاتّجاه المعاكس للسيناريوهات السابقة: البيانات تدخل إلى ووكومرس بدل أن تخرج منه.

المُشغّل: Webhook في n8n يستقبل من نظام المستودع/شركة الشحن، أو Schedule يقرأ ورقة أدخل فيها المستودع أرقام التتبّع.

العُقد بالترتيب: المُشغّل ← Set (orderKey = 4821:tracking) ← بحث + IF ← WooCommerce: Get Order (التأكّد من وجوده وحالته) ← WooCommerce: Update Order (إضافة رقم التتبّع في بيانات الطلب وتغيير الحالة إلى completed) ← إشعار العميل ← تسجيل المفتاح.

تنبيه مهمّ: تغيير حالة الطلب سيُطلق حدث تحديث الطلب مرّة أخرى، وقد يُشغّل سيرًا آخر يستمع للحدث نفسه. لهذا نبّهنا على الفلترة الصارمة بالحالة ومفاتيح المنع المركّبة؛ بدونها تدخل في حلقة: سير يغيّر الحالة، فيُشغّل سيرًا يغيّر الحالة، فيُشغّل الأوّل. راجع دائمًا سلسلة الأحداث التي يُنتجها كل تعديل تكتبه.

مثال ملموس: متجر يشحن داخل السعودية عبر شركة محلّية. المستودع يمسح باركود الطلب فيكتب النظام سطرًا في ورقة: رقم الطلب، رقم البوليصة، اسم الناقل. كل خمس عشرة دقيقة يقرأ السير الأسطر الجديدة، يحدّث كل طلب، يغيّر حالته، ويرسل للعميل رسالة تحوي رقم التتبّع. أما إشعار واتساب فيمكن إضافته كخطوة أخيرة في المسار نفسه (له مقال مستقلّ لأن إعداده يستحقّ تفصيلًا خاصًّا).

السيناريو الخامس: مزامنة العملاء مع CRM أو جدول بيانات

الهدف: بناء قاعدة عملاء موحّدة خارج المتجر، تصلح للتسويق والدعم والتحليل، وتتحدّث تلقائيًا.

المُشغّل: حدث إنشاء/تحديث العميل، أو حدث الطلب (لالتقاط من يشتري كضيف بلا حساب).

العُقد بالترتيب: Trigger ← Set (تطبيع البيانات: بريد بحروف صغيرة، هاتف بصيغة موحّدة) ← بحث في CRM بالبريد ← IF (موجود؟) ← تحديث السجلّ أو إنشاؤه ← Set (تحديث الإحصاءات: عدد الطلبات، إجمالي الإنفاق، تاريخ آخر طلب).

مفتاح المطابقة هو أهمّ قرار هنا. البريد الإلكتروني هو الأنسب عادةً، لكن انتبه لثلاث حالات: العميل الذي يشتري كضيف بلا حساب في المتجر، والعميل الذي يستخدم بريدين، والعميل الذي يُدخل بريده بأحرف كبيرة وصغيرة مختلطة. عقدة Set التي توحّد الصيغة قبل البحث تحلّ الحالة الثالثة نهائيًا، والأولى تُعالَج بالاعتماد على حدث الطلب لا حدث العميل، والثانية تُعالَج بمطابقة ثانوية على رقم الجوّال.

احترم الخصوصية. بيانات العملاء ليست ملفًّا تنقله كيفما شئت. انقل الحدّ الأدنى الذي تحتاجه فعلًا، ولا تنقل تفاصيل الدفع، وتأكّد أن الوجهة التي تُصدّر إليها تستحقّ الثقة نفسها التي تعطيها لمتجرك. وإن كنت ستستخدم البيانات للتسويق، فذلك يخضع لموافقة العميل لا لقدرتك التقنية على تصديرها.

السيناريو السادس: تقرير مبيعات دوري ومتابعة الطلبات الفاشلة

هذان سيناريوهان صغيران يشتركان في المُشغّل نفسه (Schedule) ويكمّلان بعضهما: الأوّل يخبرك بما نجح، والثاني بما يكاد يضيع.

التقرير الدوري. المُشغّل: Schedule يوميًا الساعة 8 صباحًا (وأسبوعيًا الأحد). العُقد: Schedule ← Set (حساب نطاق التاريخ: أمس من 00:00 إلى 23:59) ← WooCommerce/HTTP: جلب الطلبات ضمن النطاق ← Code (تجميع: العدد، الإجمالي، متوسّط قيمة الطلب، أكثر خمسة أصناف مبيعًا، توزيع طرق الدفع، عدد الفاشلة) ← Set (صياغة نصّ موجز) ← إرسال بالبريد + صفّ في ورقة الأرشيف.

المفتاح في التقرير هو الاختصار. تقرير من ثلاثين سطرًا لن يُقرأ. اجعله خمسة أسطر: كم طلبًا، بكم، متوسّط الطلب، أعلى صنف، وكم طلبًا فشل. التفاصيل تبقى في ورقة الأرشيف لمن يريد الغوص. ومفتاح صحّة التقرير أن يستخدم مفتاح قراءة فقط — لا سبب على الإطلاق لمنح سير تقارير صلاحية الكتابة.

متابعة الفاشلة والمرتجعة. الطلبات failed مال كاد يدخل ثم لم يدخل، وأكثر أسبابها تقنيّ لا نيّة عزوف: بطاقة رُفضت، انقطاع لحظي مع البوّابة، عميل أغلق الصفحة أثناء التحقّق. سير بسيط يلتقط الحالة failed، ينتظر ساعة، يتأكّد أن الطلب لم يتحوّل إلى processing في هذه الأثناء، ثم يرسل رسالة واحدة مهذّبة برابط إكمال الدفع — يسترجع نسبة معتبرة من هذه الطلبات. أما refunded فمساره محاسبي: صفّ في ورقة المرتجعات مع السبب، وتنبيه للمحاسبة، ومراجعة شهرية لأكثر الأصناف ارتجاعًا (رقم يكشف مشكلة في وصف المنتج أو مقاسه أكثر ممّا يكشف عن العملاء).

الترتيب الذي ننصح به للتنفيذ: ابدأ بتنبيه المخزون لأنه أقلّ جهدًا وأعلى عائدًا ولا يكتب شيئًا في متجرك (مخاطرة صفر). ثم متابعة الطلبات الفاشلة. ثم معالجة الطلب الجديد. ثم البقية. بناء سيناريو واحد يعمل بثبات لأسبوع أفضل من ستّة سيناريوهات نصف مكتملة تفقد الثقة فيها جميعًا بعد أوّل عطل.

أين تشغّل الأتمتة؟ ولماذا لا تكون على خادم المتجر؟

سؤال يُهمَل حتى تظهر آثاره في أبطأ لحظة ممكنة. n8n يحتاج تشغيلًا مستمرًّا وعنوانًا عامًّا ليستقبل الـwebhooks، وهو ما يوفّره خادم VPS. السؤال الحقيقي: هل يكون نفس الخادم الذي يستضيف متجرك؟

الجواب في الغالب: لا. الأتمتة تستهلك ذاكرة ومعالجًا بشكل متقطّع وحادّ — تنفيذ يجلب مئة طلب ويحوّلها ويرسلها إلى ثلاث خدمات يستهلك موارد لحظية معتبرة. إن حدث ذلك أثناء ذروة البيع، فأنت تنافس زبائنك على موارد الخادم نفسه، وسينخفض أداء صفحات المتجر في اللحظة التي لا تحتمل فيها بطئًا. والعكس صحيح كذلك: ضغط زيارات مفاجئ قد يُبطئ الأتمتة فتتأخّر الطلبات عن التجهيز.

وثلاث احتياطات تشغيلية تستحقّ الالتزام: أجّل الأعمال الثقيلة (التقارير، عمليات الجلب الواسعة) إلى ساعات الهدوء بدل ذروة الظهيرة والمساء؛ وحدّد عدد التنفيذات المتوازية بحيث لا تُغرق متجرك بعشرات الاستدعاءات في الثانية؛ ونظّف سجلّات التنفيذ دوريًا لأنها تتضخّم بسرعة مذهلة في متجر نشط. أثر الأتمتة على سرعة المتجر وطرق قياسه مشروحان في تحسين أداء متجر ووكومرس، وقبل أي تجربة على متجر حيّ خذ نسخة احتياطية كاملة كما في دليل النسخ الاحتياطي للمتاجر.

سحابة الأتمتة n8n من wpressly

شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.

ابدأ مع سحابة الأتمتة

حلّ الأعطال: ماذا تفعل عندما تتوقّف الأتمتة؟

كل أتمتة ستتعطّل يومًا. الفارق بين متجر يكتشف العطل خلال دقائق ومتجر يكتشفه بعد أسبوع من شكاوى العملاء هو وجود عقدة Error Trigger في سير منفصل ترسل لك تنبيهًا عند فشل أي workflow. اجعلها أوّل ما تُنشئه بعد أوّل سير حقيقي.

الـwebhook لا يصل إلى n8n

الأعراض: تُنشئ طلبًا تجريبيًا ولا يحدث شيء، وسجلّ التنفيذات في n8n فارغ تمامًا. التشخيص بالترتيب: (1) هل السير مفعّل (Active)؟ عنوان الاختبار يعمل فقط أثناء الاستماع اليدوي، والإنتاج يحتاج التفعيل والعنوان الإنتاجي. (2) هل العنوان في ووكومرس يطابق العنوان الإنتاجي حرفًا بحرف؟ (3) افتح سجلّ تسليم الـwebhook في ووكومرس نفسه — فهو يعرض رمز الاستجابة لكل محاولة، وهو أسرع طريق للتمييز بين «لم يُرسَل» و«أُرسل ورُفض». (4) هل يمنع جدار حماية أو إعداد أمني الطلبات الواردة إلى خادم n8n؟ (5) هل شهادة SSL على نطاق n8n صالحة؟ شهادة منتهية أو ذاتية التوقيع كفيلة بأن يرفض ووكومرس الاتّصال بصمت.

المصادقة تُرجع 401

الأعراض: 401 Unauthorized أو woocommerce_rest_authentication_error عند أي استدعاء من عقدة WooCommerce أو HTTP. الأسباب الشائعة بالترتيب: مفتاح أو سرّ منسوخ ناقصًا (مسافة زائدة في نهايته سبب متكرّر بشكل مضحك)؛ أو المفتاح بصلاحية قراءة والعملية كتابة؛ أو الاتّصال عبر HTTP لا HTTPS فترفض بعض الإعدادات تمرير بيانات الاعتماد؛ أو إعادة توجيه من www إلى غير www تُسقط ترويسة المصادقة أثناء التحويل؛ أو إضافة أمان في ووردبريس تحجب الوصول إلى الواجهة البرمجية. جرّب الاستدعاء نفسه من أداة خارجية لتفصل بين مشكلة في n8n ومشكلة في المتجر.

الطلب يُعالَج مرّتين

الأعراض: فاتورتان بالرقم نفسه، أو صفّان متطابقان في الشيت، أو رسالتان للعميل. السبب واحد دائمًا: لا يوجد فحص idempotency، أو الفحص موجود لكن مفتاحه غير مركّب فيتضارب بين السيناريوهات، أو التسجيل في السجلّ يحدث قبل تنفيذ الإجراء بدل بعده. عُد إلى قسم منع التكرار ونفّذه كما هو. ولو حدثت الحادثة فعلًا، لا تصلحها بحذف الصفوف يدويًا فقط — أصلح السير أوّلًا وإلا تكرّرت مساءً.

تعارض حالات الطلب

الأعراض: طلب يتنقّل بين حالتين ذهابًا وإيابًا، أو حالة تعود إلى ما قبلها بلا سبب، أو سلسلة تنفيذات لا تنتهي. السبب: سيران أو أكثر يكتبان الحالة، أو سير يكتب حالة تُطلق الحدث الذي يُشغّله هو نفسه. الحلّ: اجعل سيرًا واحدًا فقط مسؤولًا عن كتابة حالة الطلب، وأضف في بداية كل سير آخر فلترًا يتجاهل الطلب إن كانت حالته الحالية مساوية للحالة التي كان سيكتبها. القاعدة العامة في تصميم أتمتة المتاجر: كاتب واحد لكل حقل، وقارئون كثر.

ما الذي لا يجب أن تُؤتمته؟

الحماس للأتمتة يقود أحيانًا إلى أتمتة ما لا ينبغي. ثلاث فئات تستحقّ أن تبقى بيد إنسان:

القرارات المالية غير الاسترجاعية. الاسترداد التلقائي بناءً على قاعدة، أو إلغاء الطلبات آليًا بعد مدّة، أو تعديل الأسعار استجابةً لمنافس — كلّها قرارات ذات كلفة مباشرة عند الخطأ. اجعل الأتمتة تُهيّئ القرار وتعرضه (بطاقة تحوي كل المعطيات + زرّ)، ويبقى التنفيذ بضغطة إنسان.

التواصل الحسّاس مع العميل. الردّ على شكوى، أو التعامل مع طلب متأخّر، أو الاعتذار عن خطأ. رسالة آلية في هذه المواضع تُضاعف الغضب بدل أن تحتويه. أتمت الإشعارات المعلوماتية (تأكيد، شحن، تتبّع) لا الحوار.

كل ما يتعلّق ببيانات الدفع. لا تمرّ بيانات البطاقات عبر أي سير أتمتة، ولا تُخزَّن في شيت، ولا تُنسخ إلى CRM. هذه مسؤولية بوّابة الدفع وحدها، والاقتراب منها مخاطرة قانونية وأمنية لا مبرّر لها.

القاعدة الجامعة: أتمت الخطوات القابلة للتنبّؤ ذات القواعد الثابتة، واترك للإنسان ما يحتاج حكمًا أو تعاطفًا أو مسؤولية قانونية. المعيار العملي هنا هو نفسه معيار اختيار أي مهمّة للأتمتة: تكرار عالٍ وقواعد ثابتة ونتيجة قابلة للتحقّق.

خطّة تنفيذ في أسبوعين

المرحلة الأخيرة ليست تحصيل حاصل. شغّل الأتمتة أوّل ثلاثة أيام مع مراجعة يدوية موازية: راجع كل طلب مساءً وتأكّد أن ما فعلته الأتمتة صحيح. هذه الأيام الثلاثة تكشف الحالات الحافّة التي لم تخطر ببالك — طلب بعنوان ناقص، صنف بلا SKU، عميل بحرف غريب في اسمه — وتصحيحها الآن أرخص بكثير من اكتشافها بعد شهر في تقرير خاطئ.

سحابة الأتمتة n8n من wpressly

شغّل n8n على سحابة wpressly بموارد مخصّصة وحماية ودعم عربي — اربط أدواتك وأتمت مهامك بلا إدارة سيرفر معقّدة.

ابدأ مع سحابة الأتمتة

الأسئلة الشائعة

هل أحتاج خبرة برمجية لربط ووكومرس بـn8n؟

لا في الأغلب. عقد WooCommerce والـTrigger تُضبط بالنماذج بلا كتابة كود، وأغلب السيناريوهات في هذا المقال تُبنى بعُقد جاهزة (Trigger، IF، Set، HTTP، Sheets). قد تحتاج عقدة Code في تجميعات التقارير أو تحويلات معقّدة، لكنها ليست شرطًا للبدء. الأهمّ ليس البرمجة بل فهم منطق العمليات: أي حالة تُشغّل ماذا، وأي إجراء يجب ألّا يتكرّر.

هل يمكن تشغيل n8n على استضافة مشتركة بدل VPS؟

لا. n8n تطبيق Node.js يعمل كخدمة مستمرّة، والاستضافة المشتركة مصمّمة لتشغيل PHP لا لخدمات دائمة. تحتاج خادمًا يمنحك تحكّمًا كاملًا، وأصغر خطة VPS تكفي للبداية بمتجر صغير، وتفاصيل التثبيت والمتطلّبات مشروحة في دليل تثبيت n8n المخصّص لذلك.

ماذا يحدث إن كان خادم n8n متوقّفًا عند وصول طلب جديد؟

الـwebhook لن يجد من يستقبله، وسيسجّل ووكومرس فشل التسليم مع إعادة محاولة محدودة. الطلب نفسه لن يتأثّر إطلاقًا — هو في المتجر سليم — لكن الأتمتة المرتبطة به لن تُنفَّذ. لهذا يُنصح بسير احتياطي مجدوَل يفحص الطلبات الأخيرة ويعالج ما لم يُعالَج، معتمدًا على سجلّ منع التكرار نفسه لتمييزها. هذا السير الاحتياطي هو ما يجعل النظام محتملًا للأعطال لا هشًّا.

كيف أتحقّق أن الطلب الوارد صادر فعلًا من متجري؟

بطريقتين متكاملتين: التحقّق من توقيع الحمولة باستخدام السرّ الذي ضبطته في إعدادات الـwebhook، ثم جلب الطلب برقمه من REST API ومقارنة بياناته. الطريقة الثانية أبسط تنفيذًا وتحمي من معظم الحالات لأن الطلب المزيّف ببساطة لن يوجد في متجرك. لا تعتمد على الحمولة الواردة وحدها كمصدر حقيقة في أي إجراء له أثر مالي أو مخزوني.

هل تُغني الأتمتة عن برنامج المحاسبة والالتزام الضريبي؟

لا إطلاقًا. الأتمتة تنقل البيانات وتُنشئ المستندات وتنظّم الأرشفة، لكن الالتزام المحاسبي والضريبي — شكل الفاتورة، بياناتها الإلزامية، مدّة الحفظ، الإقرارات، أي ربط مطلوب مع الجهة المختصّة — مسؤولية قانونية عليك. اعتبر الأتمتة أداة تنظيم تُقلّل الخطأ البشري، وراجع محاسبك قبل اعتماد أي مسار مؤتمت في مستنداتك الرسمية.

هل تؤثّر الأتمتة على سرعة متجري؟

نعم إن أسأت التصميم. كل استدعاء API يستهلك موارد من خادم المتجر، وسير يجلب مئات الطلبات دفعةً واحدة وقت الذروة سيُبطئ الصفحات فعلًا. علاجه بسيط: شغّل n8n على خادم منفصل، أجّل العمليات الثقيلة إلى ساعات الهدوء، وحدّد التنفيذات المتوازية. تفاصيل القياس والضبط في قسم الأداء أعلاه وفي دليل تحسين أداء المتجر.

كيف أتعامل مع المنتجات المتغيّرة في أتمتة المخزون؟

بالاعتماد على variation_id لا product_id. المنتج المتغيّر يحمل مخزونًا مستقلًّا لكل متغيّر (لون/مقاس)، وأي سير يخصم أو يراقب على مستوى المنتج الأب سيُنتج أرقامًا خاطئة تمامًا. تأكّد أن كل متغيّر لديه SKU فريد، فهو ما سيربط بيانات المتجر بجداولك الخارجية بلا لبس. راجع دليل المنتجات المتغيّرة المشار إليه سابقًا لضبط المخزون على مستوى المتغيّر.

من أين أبدأ إن كان لديّ وقت محدود جدًّا؟

من سير واحد: تنبيه المخزون المجدوَل. لا يكتب شيئًا في متجرك (مخاطرة صفر)، ويُبنى في أقلّ من ساعة، ويمنع أكثر الأخطاء كلفةً — بيع صنف غير متوفّر. شغّله أسبوعًا، وحين تثق به انتقل إلى معالجة الطلب الجديد. الأتمتة التدريجية التي تعمل أفضل من خطّة شاملة لا تُنجَز.

المصادر

• توثيق n8n الرسمي