ملفات تسوية Klarna وسجلات مبيعات Shopify نادراً ما تتعارض بسبب مبيعات مفقودة. تتعارض لأن Klarna يسوّي الطلبات الملتقطة وفق جدول دفعاته الخاص، في حين يسجّل Shopify الطلبات في وقت إتمام الشراء بالمتجر ويمنحها مراجع مختلفة.
هذا يعني أن تصديراً نظيفاً من Shopify قد يبدو خاطئاً بجانب ملف Klarna نظيف كذلك. صف واحد قد يحمل اسم طلب Shopify، وصف آخر قد يحمل order_id من Klarna، أو short_order_id، أو أحد حقول مرجع التاجر. الاسترداد قد يقع في تسوية لاحقة. طلب شُحن جزئياً قد يولّد أكثر من التقاط واحد. الرسوم والاحتجازات والإلغاءات قد تخفض الدفعة دون وجود صف مبيعات مقابل في Shopify.
إن قارنت الملفين صفاً بصف من أول علامة تبويب صدّرتها، بدت الفروق عشوائية. ليست كذلك. أنت تقارن نشاط طلبات، ونشاط تسوية، وتسويات دفعات، كأنها شيء واحد.
الحل: افصل هذه المستويات أولاً، واختر مفتاح مطابقة واحداً، ثم قارن المبالغ بعد ذلك.
حدّد نوع الفرق قبل الدخول إلى البيانات
معظم المطابقات الفاشلة تعود إلى أنماط محدودة متكررة. حدّد النمط الذي تواجهه قبل بناء المعادلات أو تصفية الصفوف غير المطابقة.
| ما تراه على الشاشة | كيف يخزّنها Klarna | كيف يخزّنها Shopify | ماذا يحدث إن طابقت دون التحقق |
|---|---|---|---|
#10482 يظهر في Shopify لكن لا توجد قيمة مساوية في Klarna | order_id = c504a9bb-1948-46d5...، merchant_reference1 = #10482 | Name = #10482 | يبدو الطلب مفقوداً إن طابقت Name من Shopify مع order_id من Klarna |
| تاريخ الطلب متطابق لكن تاريخ الدفعة غير متطابق | sale_date = 2026-05-02T21:18:00Z، payout_date = 2026-05-04T07:45:00Z | Paid at = 2026-05-02 | يبدو الطلب متأخراً أو مفقوداً بينما هو فعلياً يُسوَّى في وقت لاحق |
| استرداد موجود في Klarna لكن ليس ضمن صف الالتقاط نفسه | type = RETURN، capture_id = ""، order_id نفسه للمبيعة الأصلية | الاسترداد مسجّل في الطلب أو ضمن سجل المعاملات تحت اسم الطلب الأصلي | يبدو الاسترداد معزولاً إن استخدمت capture_id مفتاحاً رئيسياً |
| Klarna يعرض صفوفاً سالبة غير موجودة في Shopify | type = FEE، HOLDBACK، CHARGE | لا يوجد صف طلب مقابل في سجل المبيعات | تبدو التسوية ناقصة رغم صحة المبيعات |
| إجمالي طلب Shopify الواحد ينتج صفَّي مبيعة في Klarna | صفّا SALE بقيمتَي capture_id مختلفتين تحت order_id واحد | صف طلب واحد أو اسم طلب واحد في سجل المبيعات | يبدو الطلب مكرراً أو مفقوداً جزئياً إن لم تجمّعه أولاً |
إن كانت ملفاتك تنطبق على أكثر من صف من هذا الجدول، فذلك طبيعي. Klarna وShopify يتتبعان مراحل مختلفة من الحدث التجاري ذاته. تنجح المطابقة حين تقرر أي مستوى يفترض أن يثبته كل ملف.
ضع كل ملف في مستواه الصحيح أولاً
ملف تسوية Klarna يثبت ما أدرجه Klarna في دفعة وسبب تغيّرها صعوداً أو هبوطاً. سجل مبيعات Shopify يثبت أن طلباً أُنشئ، أو دُفع، أو استُرد، أو عُدّل داخل المتجر. هذه سجلات مترابطة، لكنها ليست قابلة للتبادل.
استخدم ملف Klarna لإثبات تركيبة التسوية، ومرجع الدفع، وما إذا كانت الرسوم اُستُقطعت من الدفعة أم فُوتّرت منفصلةً. استخدم ملف Shopify لإثبات أي الطلبات دُفعت عبر Klarna، وأي مرجع طلب ينتمي إلى كل مبيعة، وهل توجد استردادات أو صفوف مكررة.
| الملف | الحقول المهمة | ما يُثبته | ما لا يُثبته |
|---|---|---|---|
| ملف تسوية Klarna | payment_reference، payout_date، type، amount، order_id، short_order_id، merchant_reference1، merchant_reference2، capture_id | تركيبة التسوية ومنطق الدفعة | أن كل صف يجب أن يقابله صف مبيعات مطابق في Shopify بنسبة واحد لواحد |
| سجل مبيعات Shopify | اسم الطلب ورقمه، بوابة الدفع أو وسيلته، تاريخ الدفع، تاريخ الاسترداد، المبلغ، الحالة | نشاط الطلبات والمعاملات من جانب المتجر | التركيبة الدقيقة لدفعة تسوية Klarna |
هنا تنحرف كثير من المطابقات. يتوقع المحاسب من ملف مبيعات Shopify أن يفسّر الرسوم والاحتياطيات. لا يستطيع ذلك. ثم يتوقع من ملف تسوية Klarna أن يتصرف كتصدير طلبات. ليس دوره.
اختر مفتاح المطابقة قبل المبالغ
المبالغ هي آخر ما تقارنه. إن كان المفتاح خاطئاً، لن تولّد المبالغ المتطابقة إلا ثقةً زائفة.
أفضل مفتاح مطابقة بين النظامين هو في الغالب أحد حقول مرجع التاجر في Klarna، لأنها القيم المُرسَلة عند إنشاء الطلب. إن كان merchant_reference1 أو merchant_reference2 يحتوي على اسم طلب Shopify أو رقمه، استخدمه أولاً. إن كانت هذه الحقول فارغة أو غير موثوقة، فالخيار الأفضل التالي هو العلاقة بين short_order_id من Klarna واسم طلب Shopify.
حقل order_id في Klarna لا يزال مفيداً، لكن لتجميع نشاط Klarna عبر دورة حياة طلب واحد: مبيعة، ورسوم، واسترداد، وإلغاء، وتصحيح. لا يُعدّ تلقائياً أفضل جسر إلى Shopify، لأن Shopify قد لا يعرض هذا UUID. لا تستخدم capture_id مفتاحاً رئيسياً أيضاً. الاستردادات والإلغاءات قد لا يكون لها قيمة في هذا الحقل، وطلب Shopify الواحد قد ينتج التقاطات متعددة إن كان الشحن مجزأً.
| المفتاح | الاستخدام الأمثل | القيد |
|---|---|---|
merchant_reference1 / merchant_reference2 | الربط المباشر باسم طلب Shopify أو رقمه | أحياناً فارغ أو مملوء بصورة غير متسقة |
short_order_id | بديل حين يعرض Klarna وShopify المرجع نفسه للعميل | ليس دائماً مطابقاً لاسم الطلب الداخلي للتاجر |
order_id | تجميع كل أحداث Klarna لطلب واحد | غالباً غائب من سجلات مبيعات Shopify |
capture_id | تشخيص الالتقاطات المجزأة والنشاط على مستوى الشحنة | الاستردادات والإلغاءات قد لا تحمل قيمة هنا |
إن كنت تربط طلبات المتجر بملفات الدفعات في موضع آخر من سير عملك، المشكلة الجوهرية هي ذاتها الموصوفة في سبب تباطؤ مطابقة طلبات Shopify مع ملفات الدفعات: البيانات لا تفشل لأن المبالغ خاطئة، بل لأن المراجع وجداول الأحداث تتباعد بين التصديرات.
أجرِ المطابقة في ثلاث مراحل
بمجرد اختيار المفتاح، اعمل في طبقات. لا تبدأ بإجمالي الدفعة.
1. عزل صفوف Shopify المنتمية إلى Klarna
صفِّ سجل مبيعات Shopify أولاً على بوابة الدفع المعنية. إن احتوى الملف على مدفوعات بالبطاقة، أو PayPal، أو بطاقات هدايا، أو طلبات يدوية إلى جانب معاملات Klarna، ستصبح كل المقارنات اللاحقة مشوشة.
ثم أرجع جانب Shopify إلى: مرجع طلب واحد، ومبلغ مدفوع واحد، وتاريخ دفع واحد، ومبلغ استرداد إن وجد، وحالة دفع واحدة. إن كرّر تصديرك من Shopify طلباً عبر صفوف منتجات متعددة، ادمجه في سجل مستوى طلب واحد قبل المطابقة مع Klarna.
2. تقسيم صفوف Klarna إلى صفوف مرتبطة بطلبات وصفوف تسوية فقط
ليس كل صف في Klarna يفترض أن يطابق صف مبيعات في Shopify. اعزل الصفوف المرتبطة بطلبات — SALE، وRETURN، وREVERSAL، وREVERSAL_MERCHANT_PROTECTION، وCORRECTION، وFEE — عن صفوف التسوية فقط: HOLDBACK، وRELEASE، وCHARGE، وCREDIT، وCOMMISSION، وFEE_REFUND. إن خلطتها معاً، تنتج المطابقة فروقاً وهمية هي في الحقيقة حركات احتياطي أو تسويات على مستوى الدفعة.
3. تحقق من الوجود أولاً، ثم المبالغ، ثم الأثر على الدفعة
الوجود هو الاختبار الأول. هل يوجد الطلب في كلا الجانبين تحت المفتاح المختار؟
ثم قارن اقتصاديات الطلب:
- إجمالي مبيعة Shopify مقابل إجمالي
SALEفي Klarna - استردادات Shopify مقابل إجماليات
RETURNوREVERSALفي Klarna - صفوف رسوم Klarna بشكل منفصل، لا ضمن مطابقة المبيعة الإجمالية
حين ينتج طلب واحد عدة صفوف SALE بسبب الالتقاطات الجزئية، اجمعها حسب order_id قبل مقارنتها بمبيعة Shopify:
=SUMIF(Klarna!$F:$F,F2,Klarna!$H:$H)هنا العمود F هو order_id وH مبلغ الصف. قارن هذا الإجمالي الجزئي، لا كل سطر التقاط.
بعد اجتياز هذه الفحوصات فقط، ارتبط بإجمالي الدفعة. هذه الخطوة الأخيرة هي موضع مرجع الدفع، وتاريخ الدفعة، والاحتجازات، والتحريرات، والتسويات الأخرى خارج الطلبات.
هذه هي رؤية التجميع المطلوبة:
| مرجع الطلب | سجل مبيعات Shopify | عرض تسوية Klarna | التفسير |
|---|---|---|---|
#10482 | مدفوع 120.00 | SALE 120.00، FEE -3.20 | الطلب مطابق؛ الرسوم تفسّر جزءاً من صافي الدفعة |
#10483 | مدفوع 80.00، ثم استُرد 80.00 | SALE 80.00، ثم RETURN -80.00 | توقيت الاسترداد يجب تتبّعه بشكل منفصل عن المبيعة الأصلية |
#10484 | مدفوع 150.00 | لا يوجد صف SALE في التسوية الحالية | على الأرجح لم يُلتقَط بعد، أو لم يُسوَّى، أو خارج نطاق التواريخ |
#10485 | صف طلب واحد بقيمة 200.00 | صفّا SALE بقيمتَي 120.00 و80.00 تحت order_id واحد | التقاط جزئي؛ جمِّع قبل اختبار المبالغ |
السؤال ليس: "هل هذان التصديران متطابقان؟" لا ينبغي أن يكونا كذلك. السؤال المفيد: "هل بإمكاني تفسير كل فرق في مستواه الصحيح؟"
افصل التسويات المؤجلة عن الفروق الحقيقية
أكثر الأخطاء كلفةً في هذا السير هو معاملة فارق التوقيت كمبيعة مفقودة.
Klarna يكشف على الأقل ثلاثة تواريخ مهمة عملياً:
sale_date: وقت إنشاء الطلبcapture_date: وقت تسجيل الحدث، ولصفوفSALEوقت شحن البضاعة وإتمام الالتقاطpayout_date: وقت مبادرة Klarna بإصدار الدفعة
سجلات مبيعات Shopify كثيراً ما تتمحور حول الطلب أو حدث الدفع. هذا يعني أن طلباً صحيحاً قد يظهر في Shopify في يوم، وفي صفوف التقاط Klarna في يوم آخر، وفي الدفعة في يوم لاحق بعد ذلك.
استخدم جدول القرار هذا حين يبدو صف مفقوداً:
| النمط | ما يعنيه عادةً | ما يجب فعله |
|---|---|---|
موجود في Shopify، غائب من صفوف SALE في Klarna، الدفع لا يزال معلقاً أو غير ملتقط | الطلب لم يُسوَّ بعد | لا تُعلّمه كمفقود؛ راجع حالة الالتقاط ونافذة التسوية القادمة |
| موجود في Shopify، غائب من Klarna، لكن بوابات دفع أخرى تظهر في التصدير نفسه | فلتر بوابة الدفع خاطئ | أعد بناء مجموعة Shopify لمعاملات Klarna فقط |
موجود في صفوف SALE من Klarna، غائب من مفتاح المطابقة في Shopify | ربط المراجع خاطئ | راجع merchant_reference1، وmerchant_reference2، وتنسيق اسم الطلب |
موجود بصيغة RETURN أو REVERSAL في Klarna ضمن تسوية لاحقة | استرداد أو طعن لاحق يخفض الدفعة الحالية | اربطه بالطلب الأصلي وصنّفه كنشاط سالب مؤجل |
هنا أيضاً يبدأ الارتباك في نهاية الشهر. سجل مبيعات Shopify لشهر أبريل قد يحتوي على طلبات أثرها النقدي يقع في تسوية Klarna لشهر مايو. ليست هذه بيانات خاطئة. هذا هو جدول التسوية.
إن ظل في قائمتك غير المحلولة كتلة كبيرة من الصفوف السالبة أو غير المطابقة بعد فصل التوقيت عن مسائل الوجود، المشكلة غالباً هيكل المراجع لا مبيعات مفقودة. النمط ذاته يظهر في مطابقات متعددة المنصات، منها البحث عن مبيعات غير مطابقة بين Shopify وتصدير دفع آخر، حيث يوجد مرجع الطلب لكن ليس بالشكل نفسه على الجانبين.
تعامَل مع الصفوف التي لا تنتمي إلى المطابقة الفردية
بعض صفوف Klarna تنتمي إلى المطابقة لكن ليس إلى شبكة مطابقة الطلبات.
صفوف FEE مهمة لأنها تفسّر لماذا المبيعات لا تساوي الدفعة. لكنها ليست دليلاً على غياب طلب Shopify. هي استقطاعات فوق نشاط الطلبات المطابق.
صفوف HOLDBACK وRELEASE مهمة لأنها تحرّك سيولةً دون تمثيل مبيعات جديدة للعملاء. الاحتجاز يخفض الدفعة الحالية لتغطية مخاطر مستقبلية. التحرير يعيد أموالاً محتجزة سابقاً إلى دفعة لاحقة. لا ينبغي قياس أي منهما مقابل مبلغ طلب Shopify.
صفوف CHARGE وCREDIT وCOMMISSION تنتمي هي الأخرى إلى مجموعة مستقلة. يمكنها تغيير إجمالي التسوية دون أن تكون مطابقة الطلبات قد فشلت.
يجب أيضاً مراجعة نوع تسوية Klarna. إن كان نوع تسوية التاجر NET، تُستقطع رسوم Klarna من الدفعة. إن كان GROSS، تُفوتَّر الرسوم منفصلةً — قد تكون مطابقة طلباتك صحيحة حتى حين يختلف حساب الدفعة عن توقعات التسوية الصافية. هذا الحقل الواحد يغيّر منطق إقفال الأرصدة النقدية النهائي.
مطابقة نظيفة تنتج أربعة مخرجات، لا مخرجاً واحداً:
| المخرج | ما ينتمي إليه |
|---|---|
| الطلبات المطابقة | المبيعات والاستردادات المتوافقة وفق مفتاح الطلب المختار |
| التسويات المؤجلة | طلبات صحيحة تسويتها أو دفعتها تقع في نافذة لاحقة |
| تسويات الدفعة فقط | الرسوم، والاحتجازات، والتحريرات، والمدفوعات، والائتمانات، والعمولات |
| الفروق الحقيقية | الصفوف التي تظل دون حل بعد فحص المراجع والتوقيت |
إن كانت هذه المجموعات الأربع واضحة، المطابقة منجزة. إن ظل كل شيء مخلوطاً في تبويب "غير مطابق" واحد، العمل لم ينتهِ بعد.
حين تصبح إعادة المطابقة الشهرية يدوياً غير مجدية
هذا الأسلوب يؤدي الغرض. لكنه أيضاً يكرر العمل ذاته في كل دورة: تصدير من Shopify، وتصدير من Klarna، وحذف صفوف غير Klarna، واختيار المفتاح مجدداً، وتجميع الطلبات ذات الالتقاطات المجزأة، وفصل تسويات الدفعات، وإعادة بناء قائمة الفروق.
هذا قابل للإدارة حين يكون الحجم صغيراً وتركيب الدفعات ثابتاً. يصبح مكلفاً حين تحتوي كل تسوية على استردادات مؤجلة، والتقاطات جزئية، وحركات احتياطي، وجولة جديدة من تنظيف المراجع.
عند تلك النقطة، لا يعود عنق الزجاجة في الحكم المحاسبي. بل في إعداد الملفات وترتيب الفروق — وهذا هو الجزء الجدير بالانتقال من جدول البيانات.
