WooCommerce يحفظ البيع على شكل طلب. Stripe يسوّي المبالغ على شكل دفعة. هذا هو سبب اختفاء الطلب #1842 فور فتح سجل التحويلات: مرجع الطلب يقيم في جانب المتجر، بينما تتنظم سطور التحويل حول الرسوم والمستردات والعمولات ومعرّفات التحويل.

المطابقة تصبح موثوقة حين تتوقف عن البحث عن عمود مشترك وتبني جدول الربط في التسلسل الصحيح: مرجع الطلب في WooCommerce ← معرّف الدفع في Stripe ← سطر التحويل في Stripe. بمجرد وجود هذا الجدول، تتوقف التباينات عن أن تبدو عشوائية.

لماذا لا يظهر مرجع الطلب في المكان المتوقع

الخطأ الأول هو افتراض أن رقم الطلب في WooCommerce يجب أن يظهر مباشرةً داخل ملخص التحويل. في أغلب الحالات لا يظهر. سجل التحويلات ليس دفتر طلبات. إنه دفتر تسوية.

هذا الجدول يفسّر أغلب عمليات التسوية الفاشلة.

مرجع الطلب في WooCommerce يخبرك بأي بيعة تتعامل. سجل التحويلات في Stripe يخبرك بكيفية تحرك المال عبر Stripe وصولاً إلى التحويل. الاثنان مترابطان، لكنهما لا يُخزَّنان على المستوى نفسه.

لا تطابق الطلب مباشرةً بمعرّف التحويل

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

تحويل واحد قد يضم:

• عشرات الطلبات من WooCommerce
• استرداداً واحداً أو أكثر من أيام سابقة
• سطور عمولات Stripe
• سطور نزاعات أو تعديلات
• معاملات سُوّيت معاً رغم أن طلباتها أُنشئت في تواريخ مختلفة

إذن معرّف التحويل يجيب على سؤال بنكي: أي مجموعة نشاط Stripe أصبحت إيداعاً واحداً؟ ولا يجيب على سؤال الطلب: أي طلب WooCommerce أنشأ هذه الرسوم؟

لمطابقة مراجع WooCommerce بشكل موثوق، افصل تصدير Stripe حسب نوع السطر قبل محاولة أي ربط:

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

ابنِ جدول الربط قبل البدء في التسوية

إن حاولت حل هذا في تبويب واحد من جدول البيانات، تشوّشت المنطق سريعاً. جدول الربط أنظف.

استخرج أولاً هذه الحقول من WooCommerce:

ثم استخرج هذه الحقول من تفاصيل معاملات Stripe أو التحويل:

جدول الربط الذي تعمل به ينبغي أن يبدو هكذا:

هذا الجدول يؤدي شيئين مهمين. يُثبت أي كائن Stripe ينتمي إلى أي طلب WooCommerce. ويوضّح أيضاً أي سطور Stripe لا يُفترض أن تشير إلى مرجع طلب WooCommerce.

كيف تجد معرّف Stripe حين لا يصدّره WooCommerce بشكل مباشر

هذا هو الجزء الذي يحدد عادةً إن كان العمل يستغرق عشرين دقيقة أو ساعتين.

إن كان تصدير WooCommerce يتضمن بالفعل معرّف معاملة Stripe، فاستخدمه. هذا هو المسار الأنظف. لكن كثيراً من التصديرات لا تُظهره في عمود مريح، وعليك حينها الاعتماد على أدلة بديلة.

استخدم هذه المصادر بهذا الترتيب:

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

بعد استعادة معرّف الجانب الخاص بـ Stripe، يصبح باقي المطابقة أكثر استقراراً. ابحث عن قيمة ch_ أو pi_ في تصدير Stripe، تحقق من المبلغ والتاريخ، ثم سجّل Payout ID المرتبط بذلك السطر.

الإجراء الذي يصمد حين يحتوي التحويل على بيانات مختلطة

هذا هو التسلسل الذي يتجنب أغلب التباينات الوهمية.

1. طابق دفعة التحويل مع البنك أولاً. سجل التحويلات ينتمي إلى سير عمل تسوية نقدية، فتحقق من أي تحويل وصل فعلاً قبل البدء في تتبع الطلبات الفردية. إن لم يكن هذا المستوى واضحاً بعد، ابدأ بـكيفية مطابقة ملف CSV لتحويلات Stripe مع كشف حسابك البنكي.
2. افتح سطور Stripe داخل ذلك التحويل بعينه. افصل سطور charge وrefund وstripe_fee وأي سطور تعديل قبل محاولة ربطها بـ WooCommerce.
3. طابق سطور charge مع WooCommerce باستخدام معرّف معاملة Stripe أو PaymentIntent. هذا هو الجسر الحقيقي بين الطلب وـ Stripe.
4. طابق سطور refund مع الطلب الأصلي في WooCommerce باعتباره استرداداً لاحقاً. لا تعامل سطور التحويل السالبة على أنها مبيعات مفقودة.
5. أبقِ سطور العمولات خارج مطابقة الطلبات. إنها تنتمي إلى تفسير التحويل لا إلى جدول ربط الطلب.
6. اكتب النتيجة كتصنيف، لا كقائمة كبيرة غير مُسوَّاة.

هذه النقطة الأخيرة مهمة. التسوية التي تعمل لا يجب أن تنتهي بأربعين خلية حمراء وتخمين. يجب أن تنتهي بفئات تفسّر ما يعنيه كل فارق.

الأخطاء التي تجعل المطابقات الصحيحة تبدو خاطئة

حتى مع مفتاح الربط الصحيح، بعض الأنماط لا تزال تولّد ضوضاء.

المبلغ نفسه يظهر أكثر من مرة.

طلبان في WooCommerce قد يكون كلاهما 89.00. إن طابقت بالمبلغ وحده، قد تربط رسوم Stripe الخاطئة بالطلب الخاطئ. استخدم المبلغ دليلاً داعماً فقط، وليس مفتاحاً رئيسياً أبداً.

تاريخ الطلب وتاريخ التحويل ينتميان إلى فترتين مختلفتين.

الطلبات المتأخرة في الليل وعطل نهاية الأسبوع وجداول التحويل تدفع التسوية إلى اليوم التالي أو حتى الشهر التالي. هذا طبيعي. تاريخ البيع والتاريخ البنكي يجيبان على سؤالين مختلفين.

استرداد يصل في تحويل مختلف عن الطلب الأصلي.

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

سطور العمولات تُجبر على الدخول في مطابقة الطلبات.

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

تصدير يُظهر معرّف الرسوم والآخر يُظهر PaymentIntent.

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

هذا هو التباطؤ الهيكلي نفسه المُوصوف في لماذا تسوية طلبات Shopify مع تحويلات Stripe بطيئة. المتجر يتغير. نمط التباين يبقى كما هو: بيانات على مستوى الطلب من جهة، وبيانات على مستوى التسوية من جهة أخرى.

ما يجب أن تُظهره التسوية المكتملة

النتيجة القابلة للاستخدام تُثبت المسار من مرجع الطلب إلى الدفع في Stripe ثم إلى دفعة التحويل. لا تتوقف عند «متطابق» أو «غير متطابق».

حين تُقدّم النتيجة بهذه الطريقة، الشخص التالي لا يحتاج إلى إعادة فتح WooCommerce وـ Stripe من الصفر. يمكنه اتباع السلسلة:

• أي مرجع طلب WooCommerce تم فحصه
• أي كائن Stripe أكّد الدفعة
• أي تحويل استوعب تلك الدفعة
• أي سطور خفّضت المبلغ قبل وصوله إلى البنك
• أي استثناءات لا تزال تحتاج إجراءً

هذا هو المعيار المطلوب. ليس مصنف يوازن هذا الشهر بالصدفة. بل مسار مطابقة يمكنك الدفاع عنه الشهر القادم.

متى يصبح إعادة بناء جدول الربط كل شهر غير مجدية

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

• إيجاد معرّفات Stripe المفقودة في تصديرات الطلبات
• البحث عن قيم ch_ أو pi_ في السجلات
• تقسيم سطور التحويل إلى رسوم ومستردات وعمولات
• إعادة بناء جدول الربط نفسه
• إعادة كتابة نفس التفسيرات لفوارق التوقيت والتسوية الصافية

عند هذه النقطة، العمل الحقيقي لم يعد حكماً محاسبياً. إنه ترجمة ملفات.

الحل الحقيقي ليس إيجاد VLOOKUP أذكى. إنه قبول أن مراجع طلبات WooCommerce وسجلات تحويلات Stripe تصف مستويات مختلفة من تدفق المال نفسه، ثم ربط تلك المستويات بالترتيب الصحيح.