ملف CSV لنزاعات Stripe لا يفتقد طلباتك. إنه يصف البيع نفسه عبر معرّفات النزاع والدفعة الخاصة بـ Stripe، بينما يعتمد جدول طلباتك عادةً على رقم طلب داخلي. إذا حاولت مطابقة صفوف dp_ مباشرةً مع معرّفات الطلبات، بدا كل سطر خاطئاً حتى وإن كانت جميع السجلات موجودة.

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

ما يخبرك به صف النزاع فعلاً

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

إذا كانت محاولتك الأولى VLOOKUP(dispute_id, orders, ...)، فجدول البيانات أدّى تماماً ما يجب. القيم مختلفة. المشكلة في مفتاح المطابقة، لا في الدالة.

احضر الملفات التي تُنشئ الجسر

ملفّان ليسا دائماً كافيَين. لهذا العمل تحتاج عادةً إلى ثلاثة.

الملف الوسيط هو ما يتجاهله معظم الناس. لهذا يفشل التقاطع.

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

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

طابق بهذا الترتيب، لا بالتخمين

المطابقة النظيفة تبدأ بالمعرّف الأقوى ولا تلجأ إلى غيره إلا إذا كان ذلك المعرّف غائباً.

1. معرّف الدفعة مع معرّف الدفعة

إذا كان ملف الطلبات يحتوي على حقل stripe_charge_id أو gateway_reference أو ما يشابههما، ابدأ من هنا. هذا أقصر مسار من النزاع إلى الطلب.

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

2. Payment intent أو مرجع الدفع

بعض جداول الطلبات تحتفظ بـ payment intent لكن ليس بمعرّف الدفعة النهائي. في هذه الحالة، استخدم تصدير المدفوعات لربط دفعة النزاع بـ payment intent، ثم ربط payment intent بالطلب.

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

3. البيانات الوصفية أو مرجع الدفع المنقول إلى الطلب

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

المبدأ هنا هو مطابقة كائن دفع واحد مع كائن طلب واحد. لا تختزل المنطق في «المبلغ نفسه إذن البيع نفسه». المبلغ إشارة داعمة. ليس جسراً.

4. المبلغ والعميل والتوقيت كملاذ أخير محكوم

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

استخدم نطاق مرشحين محدوداً:

• بريد العميل نفسه أو اسم حامل البطاقة
• مبلغ الدفعة الأصلي قريب من المبلغ المتنازع عليه
• طلب أُنجز قرب وقت إنشاء الدفعة
• صف دفع ناجح واحد فقط، لا محاولة فاشلة أو تفويض مكرر

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

=COUNTIF(Orders!$D:$D,D2)

إن تجاوزت النتيجة 1، فالمبلغ ليس فريداً. ضيّق بالعميل وتاريخ الدفعة قبل اختيار صف.

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

أنشئ جدول مراجعة نزاعات يُجيب على السؤال الحقيقي

السؤال الحقيقي ليس «هل أستطيع محاذاة الصفوف؟». بل «أي طلبات تأثرت، وماذا أفعل بعد ذلك؟».

هذا يعني أن ورقة المخرجات يجب أن تشبه جدول تدقيق أكثر من كونها مسودة معادلات.

تلك التسميات مهمة. إنها تمنعك من التعامل مع كل صف باعتباره موثوقاً بالقدر ذاته.

هيكل جيد للمرور الأول:

• تطابق مباشر بالمعرّف
• مُطابَق عبر تصدير المدفوعات
• تطابق محتمل: مراجعة يدوية
• لم يُعثر على الطلب

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

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

الحالات الاستثنائية التي تُنشئ تعارضات زائفة

هنا تتوقف المقالات السطحية. التطابق المباشر نصف العمل فقط. الحالات الصعبة هي ما يُطيل المطابقة.

المبلغ المتنازع عليه ليس إجمالي الطلب.

رد الدفع قد يكون جزئياً. حين يكون إجمالي الطلب 120.00 والمبلغ المتنازع عليه 40.00، الصف ليس خاطئاً. إنه يُخبرك أن جزءاً فقط من الدفعة الأصلية موضع نزاع. احتفظ بالمبلغَين في جدول المراجعة.

تاريخ النزاع ليس تاريخ الطلب.

الدفعة قد تمت في يناير والنزاع قد يُفتح في مارس. المطابقة بتاريخ إنشاء النزاع سترسلك إلى نافذة الطلبات الخاطئة.

عميل واحد أجرى طلبات متعددة متشابهة.

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

محاولة الدفع الأولى فشلت لكن الثانية نجحت.

أنظمة الطلبات تحتفظ في الغالب بسجل الطلب بينما تُظهر Stripe عدة أحداث دفع حوله. الدفعة الناجحة المرتبطة بالنزاع وحدها هي ما يهم. المحاولات الفاشلة والتفويضات المكررة تُنتج ضجيجاً، لا أدلة.

تصدير الطلبات يُخزّن الإجماليات الصافية أو إجماليات المنتجات بينما يخزّن Stripe المبلغ الإجمالي المحصَّل.

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

ملف النزاعات صحيح، لكن جدولك فقد المفتاح.

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

ماذا تفعل حين لا يوجد أي مرجع طلب واضح

أحياناً لا يكتب نظام الطلبات معرّف دفعة Stripe أو payment intent أو أي مرجع دفع قابل لإعادة الاستخدام في أي تصدير. هذا لا يجعل تتبع النزاع مستحيلاً، لكنه يغيّر طبيعة العمل.

في هذه الحالة:

1. ابدأ من معرّف الدفعة في تصدير النزاعات.
2. اسحب تفاصيل الدفع من جانب Stripe لتلك الدفعة.
3. أدخل معرّف العميل ومبلغ الدفع والطابع الزمني للدفع.
4. ضيّق نطاق الطلبات المرشحة بالعميل أولاً، ثم بالنافذة الزمنية، ثم بالمبلغ.
5. صنّف النتيجة كتطابق محتمل حتى يؤكده حقل عمل إضافي.

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

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

حين يكلّف أسلوب الملف تلو الملف أكثر من النزاع نفسه

نزاع واحد يمكن معالجته يدوياً. تصبح العملية مكلفة حين تُعيد بناء الجسر نفسه مراراً: تصدير النزاعات، تصدير الدفعات، تصدير الطلبات، استرداد المرجع المشترك، تعليم المبالغ الجزئية، ثم فرز الصفوف المؤكدة عن تلك التي تحتاج إلى مراجعة.

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