لماذا تختلف تقارير مبيعات المطعم بين التطبيقات والكاشير؟ دليل التوحيد

تختلف أرقام مبيعات المطعم بين تطبيقات التوصيل ونظام الكاشير عندما يُحسب «البيع» بمعانٍ مختلفة: التطبيق قد يعرض إجمالي الطلب قبل العمولة، بينما يسجل POS العمليات التي وصلته فقط، ويعرض كشف التسوية مبلغًا بعد الخصومات والاستردادات. ابدأ بتوحيد تعريف كل مؤشر وتاريخ العملية ورقم الطلب والفرع، ثم افصل المبيعات عن المبالغ المحولة للحساب البنكي.

لماذا لا تتطابق أرقام مبيعات المطعم بين التطبيقات والكاشير؟

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

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

خمسة أرقام لا ينبغي اعتبارها رقمًا واحدًا

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

لماذا تختلف تقارير القنوات؟

اختلاف تاريخ الحدث

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

اختلاف حالات الطلب

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

الرسوم والخصومات والمبالغ المستردة

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

قنوات لم يصل طلبها إلى POS

إذا فشل انتقال طلب مؤكد من التطبيق إلى POS، سيظهر في مصدر ولا يظهر في الآخر. هنا المشكلة تشغيلية وقد تؤثر في التقرير؛ ابدأ بمعرف الطلب ونتيجة الاتصال لا بإجراء قيد تسوية يخفي الخلل. وتساعد فكرة تجميع الطلبات من لوحة واحدة على فهم هدف جمع المصادر، لكن يجب إثبات الدقة في سجلات طلبات منشأتك.

تصميم تقرير موحد للمبيعات: قاموس مؤشرات أولًا

قبل اختيار برنامج تقارير، وافق مع العمليات والمالية على تعريفات مكتوبة لكل مؤشر: المصدر، والتاريخ، وحالة الطلب الداخلة في الحساب، والمعاملة الضريبية، وأساس الخصم، ومن المسؤول عن الاعتماد. لا يكفي تسمية العمود «المبيعات»؛ يجب أن يعرف فريق الإدارة معناه بالضبط.

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

خطوات بناء تقرير واحد من مصادر متعددة

1. أحصِ المصادر: تقارير التطبيقات، POS، ملفات الاسترداد، كشوف التسوية، وأي بيانات تملكها المنشأة من بنكها.
2. وحّد المفاتيح: اربط معرف الطلب الخارجي بمعرف POS، ثم حدد العلامة والفرع والتوقيت وحالة العملية.
3. ثبّت قاموس الحالات: عرّف الحالات المؤهلة للمبيعات المكتملة والمستبعدة منها، واحتفظ بالحالة الأصلية للتدقيق.
4. افصل المبالغ: لا تدمج الإيراد والعمولات والخصومات والضريبة والتحصيل في خانة واحدة.
5. أجرِ مراجعة فروقات: اصنع قائمة بالطلبات المفقودة أو المتكررة أو التي لا تتطابق قيمها بين مصدرين.
6. اعتمد التقرير: اجعل العمليات مسؤولة عن حالة الطلب والمالية مسؤولة عن تصنيف المبالغ والمحاسبة.
7. تتبّع التغير: إذا أعادت إحدى المنصات احتساب خصم أو استرداد، سجل تاريخ التعديل بدل حذف النسخة السابقة من دون أثر مراجعة.

مثال افتراضي: لماذا يختلف الإجمالي؟

مثال حسابي افتراضي: يعرض تطبيق توصيل عشرة طلبات مؤكدة مجموع قيم الأصناف فيها 1,000 ريال. أُلغي طلب قيمته 100 ريال قبل التجهيز؛ وفي الطلبات المكتملة تحمل المطعم خصمًا بقيمة 40 ريالًا. عند استخدام تعريف تشغيلي مبسط يستبعد الإلغاء وخصم المطعم، تكون القيمة 860 ريالًا قبل مراجعة الضرائب والرسوم الأخرى. إذا خصم التطبيق عمولة قدرها 120 ريالًا وتعديلات أخرى 20 ريالًا، فقد يظهر في كشف التسوية 720 ريالًا، دون أن يعني ذلك أن «المبيعات كانت 720 ريالًا». المبالغ افتراضية ولا تمثل أسعارًا أو قواعد عمولة لأي منصة.

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

نموذج مراجعة يومية لتقارير القنوات

يجب ألا يُستخدم التقرير الموحد لتبرير تعديل مالي مباشر دون المستندات الأصلية؛ بل يُظهر أين يبدأ التحقيق وما المصدر المعتمد لكل مبلغ.

كيف تقرأ مؤشرات القنوات والفروع؟

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

كيف تختار الحل التقني المناسب؟

قد تكفي تقارير POS والتطبيقات إذا كانت أعداد الفروع والطلبات محدودة ويمكن مطابقتها يدويًا بوضوح. لكن عند تعدد القنوات، يصبح من المفيد تقييم منصة إدارة طلبات تعرض العمليات من مصادر مدعومة وتساعد على مراجعتها. السؤال في العرض التوضيحي يجب أن يكون: «هل أستطيع تتبع الطلب نفسه عبر القناة وPOS وتفسير فرق إجمالي قيمته؟» وليس «هل تعرضون مخطط مبيعات جميلًا؟».

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

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

لماذا يختلف تقرير التطبيق عن تقرير POS مع أن الطلبات نفسها؟

غالبًا لا يتطابق تعريف الفترة أو الحالة أو نوع المبلغ. اربط معرفات الطلبات أولًا، ثم قارن السعر والخصم والضريبة والإلغاء بمعايير موحدة قبل استنتاج وجود خطأ.

هل مبلغ التسوية يساوي مبيعات المطعم؟

ليس بالضرورة. قد يكون بعد خصم عمولات ورسوم واستردادات أو تعديلات، وقد يغطي فترة مختلفة عن يوم البيع. ينبغي الاحتفاظ بكشف التسوية ومفاتيح المطابقة.

ما المؤشر الأول الذي أبدأ به؟

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

هل يمكن لنظام إدارة الطلبات أن يحل محل المحاسبة؟

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

كم مرة أراجع الفروق؟

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

الخطوة التالية: اطلب عرضًا من LYNNC لمراجعة إمكانات تجميع بيانات الطلبات لقنواتك وفروعك؛ واطلب اختبارًا يثبت ما يمكن تتبعه وتصديره فعليًا قبل الاعتماد على النظام في إعداد التقارير.