قد تتضمن عملية الدفع بالبطاقة عدة تواريخ مختلفة، ولا تقع هذه التواريخ دائمًا في اليوم التقويمي نفسه.
قد يضع فريق ما طلبًا يوم الجمعة، ويتلقى فاتورة يوم السبت، ثم يرى أن معاملة البطاقة تم تسجيلها يوم الاثنين. ولا يعني ذلك بالضرورة أن أيًا من هذه التواريخ خاطئ.
فقد تمثل ببساطة مراحل مختلفة من عملية الدفع نفسها، تسجلها أنظمة مختلفة، وفي مناطق زمنية مختلفة، ووفق قواعد معالجة مختلفة.
إن فهم الفرق بين تاريخ الطلب، وتاريخ التفويض، وتاريخ الفاتورة، وتاريخ تسجيل المعاملة يجعل تسوية المدفوعات أسهل بكثير.
يمكن لعملية شراء واحدة أن تتضمن عدة تواريخ
يمكن لعملية شراء واحدة إنشاء عدة طوابع زمنية، بما في ذلك:
- وقت الطلب أو إتمام عملية الشراء،
- تفويض البطاقة،
- إتمام التاجر للمعاملة،
- إنشاء الفاتورة،
- تسجيل المعاملة على البطاقة،
- والتسوية.
ولا تحدث هذه الأحداث جميعها في اللحظة نفسها.
على سبيل المثال، قد يتم تقديم طلب في الساعة 23:58، وتفويضه فورًا، ثم إتمام المعاملة بعد منتصف الليل. لذلك قد يظهر الطلب ومعاملة البطاقة النهائية في يومين مختلفين، رغم أنهما ينتميان إلى عملية الشراء نفسها.
السؤال الأساسي ليس ببساطة:
«أي تاريخ هو الصحيح؟»
بل هو:
«ما الحدث الذي يمثله هذا التاريخ؟»
شرح تواريخ الطلب والتفويض وتسجيل المعاملة
غالبًا ما يتم الخلط بين هذه التواريخ الثلاثة.
يشير تاريخ الطلب عادةً إلى الوقت الذي أرسل فيه العميل طلب الشراء.
ويشير تاريخ التفويض إلى الوقت الذي طلب فيه التاجر لأول مرة الموافقة على الدفع من نظام البطاقة.
أما تاريخ تسجيل المعاملة فيشير إلى الوقت الذي تصبح فيه المعاملة قيدًا مكتملًا في سجل البطاقة.
وقد تختلف هذه التواريخ لأن التجار لا يقومون دائمًا بإتمام المدفوعات فورًا.
على سبيل المثال:
الجمعة: تم تقديم الطلب وتفويض البطاقة
الاثنين: أكمل التاجر المعاملة وتم تسجيلها
لذلك، قد يكون ظهور عملية تم تفويضها يوم الجمعة كمعاملة مسجلة يوم الاثنين جزءًا طبيعيًا من مسار الدفع.
كيف تؤثر المناطق الزمنية على تواريخ المعاملات؟
قد لا يستخدم نظام التاجر المنطقة الزمنية المحلية للمشتري.
وقد يسجل أحد الخدمات العالمية المعاملات وفقًا لـ:
- المقر الرئيسي،
- الكيان الذي يصدر الفاتورة،
- منطقة الحساب،
- إعدادات النظام،
- أو UTC.
وهذا يعني أن الحدث نفسه قد يظهر في تواريخ تقويمية مختلفة، اعتمادًا على المكان الذي تتم فيه مشاهدته.
على سبيل المثال، قد يرى مشترٍ في أوروبا تاريخًا للدفع يختلف بيوم واحد عن التاريخ الظاهر في بوابة تاجر مقرها الولايات المتحدة.
وقبل اعتبار تاريخين غير متسقين، تحقق من المنطقة الزمنية التي يستخدمها كل نظام.
لماذا يمكن أن تختلف تواريخ الفواتير؟
يتبع تاريخ الفاتورة العملية التجارية أو المحاسبية الخاصة بالتاجر.
وقد يتم إنشاء الفاتورة عند:
- قبول الطلب،
- بدء فترة تقديم الخدمة،
- شحن البضائع،
- أو انتهاء دورة الفوترة.
ولهذا السبب، لا يشترط أن يتطابق تاريخ الفاتورة مع تاريخ تسجيل المعاملة على البطاقة.
على سبيل المثال، قد تحمل فاتورة الاشتراك تاريخ اليوم الأخير من فترة الفوترة، بينما تتم معالجة خصم البطاقة في صباح اليوم التالي.
يمكن أن يكون كلا السجلين صحيحًا لأن كلًا منهما يصف حدثًا مختلفًا.
عطلات نهاية الأسبوع والعطلات وتأخيرات المعالجة
يمكن للخدمات الرقمية أن تتفعّل فورًا حتى عندما يتم تسجيل المعاملة النهائية على البطاقة في وقت لاحق.
على سبيل المثال:
السبت: تم تفويض الاشتراك وتفعيل الخدمة
الاثنين: تظهر المعاملة على أنها مكتملة
يمكن لعطلات نهاية الأسبوع والعطلات وجدول إتمام المعاملات لدى التاجر ودورات المعالجة أن تؤثر جميعها في وقت تسجيل معاملة البطاقة.
كما يمكن لتغييرات التوقيت الصيفي أن تؤثر في الوقت المحلي المعروض، حتى عندما يظل الطابع الزمني الأساسي وفق UTC كما هو.
لذلك، فإن وجود فرق لعدة ساعات، أو أحيانًا ليوم أو يومين، لا يعني تلقائيًا أن هناك خطأ ما.
لماذا تهم التواريخ عند إعداد تقارير نهاية الشهر؟
تصبح الاختلافات في التواريخ مهمة بشكل خاص قرب نهاية الشهر.
فقد يتم تفويض معاملة في شهر معين، ولكن تسجيلها في الشهر التالي.
على سبيل المثال:
31 ديسمبر: التفويض
2 يناير: تسجيل المعاملة
إذا كان أحد التقارير يستخدم تاريخ التفويض بينما يستخدم تقرير آخر تاريخ التسجيل، فقد تظهر عملية الدفع نفسها ضمن فترتين مختلفتين لإعداد التقارير.
لذلك، ينبغي للفرق تحديد التاريخ المستخدم من أجل:
- إعداد الميزانية،
- المحاسبة،
- تقارير المصروفات،
- وتسوية معاملات البطاقات.
والأهم هو الالتزام بمنهج متسق.
قد تختلف التواريخ في لوحة التحكم والتصدير أيضًا
قد تعرض لوحة التحكم وملف CSV المُصدَّر طوابع زمنية تبدو مختلفة، حتى عندما تشير إلى الحدث نفسه.
على سبيل المثال:
لوحة التحكم: 10:05 CET
CSV: 09:05Z
وقد يمثل الاثنان اللحظة نفسها تمامًا.
وقبل مقارنة الطوابع الزمنية، تحقق مما إذا كان:
- لوحة التحكم تحول الوقت تلقائيًا،
- ملف التصدير يستخدم UTC،
- أو كان التوقيت الصيفي مؤثرًا.
كيف تساعد Buvei في تسوية التواريخ؟
عندما تكون سجلات المعاملات وعمليات التصدير متاحة للحساب المعني، يمكن لسجلات Buvei أن تساعد في توفير الخط الزمني للدفع على جانب البطاقة.
أما طلبات وفواتير التاجر فتقدم الخط الزمني التجاري.
وينبغي استخدام هذه السجلات معًا.
على سبيل المثال، قارن بين:
- اسم التاجر،
- المبلغ،
- العملة،
- مرجع الطلب أو الفاتورة،
- حالة المعاملة،
- والطوابع الزمنية.
توضح فاتورة التاجر متى تم إنشاء الرسوم التجارية، بينما يساعد سجل معاملة Buvei في تأكيد كيفية ووقت معالجة الدفع على جانب البطاقة.
كما أن الاحتفاظ بالسجلين مرتبطين ببعضهما يجعل عمليات التسوية المستقبلية أسهل، دون تغيير أي من تواريخ المصدر الأصلية.
كيفية تسوية تواريخ الدفع المختلفة
عندما لا يتطابق تاريخا دفعتين، استخدم عملية مراجعة بسيطة:
- حدد الحدث — الطلب أو التفويض أو إتمام المعاملة أو الفاتورة أو التسجيل أو التسوية.
- تحقق من المنطقة الزمنية التي يستخدمها كل نظام.
- قارن سجلات التاجر والبطاقة باستخدام المبلغ والعملة ومعلومات المرجع.
- راجع عطلات نهاية الأسبوع والعطلات أو تأخر إتمام المعاملة.
- احتفظ بالطوابع الزمنية الأصلية بدلًا من تعديلها لتتطابق.
- تحقق من الأمر بشكل أعمق فقط عندما لا يتوافق التوقيت مع مسار الدفع المتوقع.
ومن المفيد استخدام الخط الزمني التالي:
الطلب → التفويض → إتمام المعاملة → الفاتورة → التسجيل → التسوية
الهدف ليس جعل جميع الأنظمة تعرض التاريخ نفسه.
بل هو جعل تسلسل الدفع واضحًا بما يكفي بحيث يتمكن شخص آخر من فهم عملية التسوية وإعادة تنفيذها.
الخلاصة
لا تتطابق تواريخ معاملات البطاقات والفواتير والطلبات دائمًا، لأنها تمثل مراحل مختلفة من عملية الدفع.
يمكن للمناطق الزمنية وتوقيت إتمام المعاملة لدى التاجر ودورات الفوترة وعطلات نهاية الأسبوع ومعالجة البطاقات أن تؤثر جميعها في الوقت الذي تظهر فيه المعاملة.
وبدلًا من اختيار تاريخ واحد باعتباره التاريخ «الصحيح» الوحيد، احتفظ بالسجلات الأصلية وافهم ما الذي يمثله كل طابع زمني.
وبمجرد أن يصبح التسلسل الزمني واضحًا، يصبح من الأسهل بكثير تفسير معظم الاختلافات بين التواريخ.
