قد ينجح الضيف في الطلب عبر QR من طاولته، ومع ذلك لا تظهر «مبيعات QR» كبند مستقل في تقرير المطعم. السبب غالبًا ليس اختفاء الإيراد؛ فقد يسجل POS العملية ضمن مبيعات الصالة دون حفظ قناة المصدر أو معرّف الطاولة، أو تختلف حالات الطلب والدفع بين النظامين. ابدأ بتتبع رقم طلب واحد من مسح الرمز إلى POS، ثم راجع حقل مصدر الطلب قبل إعادة احتساب الإجماليات.
لماذا لا تتطابق طلبات QR مع مبيعات الطاولات؟
لكي تنجح عملية توحيد تقارير طلبات QR للمطاعم، لا بد من الفصل بين الطريقة التي بدأ بها الضيف طلبه والقناة المالية التي سجّل فيها الكاشير البيع. قد تكون الوجبة مباعة داخل الصالة في الحالتين، لكن إحداهما بدأها النادل في POS والثانية بدأها الضيف من هاتفه بعد مسح الرمز. إذا جمع النظام الحالتين في فئة واحدة، فلن تستطيع الإدارة قياس اعتماد الطلب الذاتي على نحو منفصل رغم أن مجموع البيع العام قد يكون صحيحًا.
هذا الدليل يركز على وسم مصدر الطلب (Order Source / QR Attribution) وحالات التسجيل والإلغاء في طلبات الطاولات. ولا يكرر طريقة إعداد التقارير المالية الشاملة لكل التطبيقات والفروع؛ كما أنه مختلف عن دليل المنيو والدفع عبر QR الذي يشرح رحلة الضيف ووظائف القائمة. الهدف هنا هو إنشاء أثر تتبع واضح يجعل تقرير QR قابلًا للفحص دون نسب أرقام غير موثقة إلى النظام.
ما البيانات التي يتركها طلب QR؟
يمكن أن تتضمن رحلة QR عدة معرّفات لا يراها الضيف: رابط أو رمز الطاولة، جلسة التصفح، رقم طلب واجهة QR، رقم الطلب لدى POS، ومرجع الدفع عند توفره. لا يعني ذلك أن كل منصة توفرها تلقائيًا. يجب أولًا فحص مخطط البيانات وإمكان التصدير لدى مورد الخدمة، ثم تحديد المفاتيح التي يمكن ربطها بثقة.
| الحقل | ما فائدته؟ | ماذا يحدث إن غاب؟ |
|---|---|---|
| order_source | تمييز QR عن النادل أو الكاشير أو التوصيل | تجميع طلبات QR مع مبيعات الصالة العامة |
| source_order_id | الرجوع إلى طلب واجهة QR الأصلي | صعوبة كشف الطلب المفقود أو المكرر |
| pos_order_id | مطابقة الطلب المسجل في POS | عدم معرفة هل نُفذت العملية فعلًا |
| branch_id | تحديد الفرع والبيانات التشغيلية المناسبة | التباس تقارير الفروع المتشابهة |
| table_id / session_id | ربط الطلب بطاولة أو جلسة عند دعم النظام | فقد سياق زيارة الضيف |
| order_status | استبعاد الإلغاء من الطلبات المكتملة | احتساب محاولات لم تحقق بيعًا |
| payment_status | التمييز بين بدء الدفع ونجاحه | تضخيم المبيعات من عمليات معلقة |
| event_time | المقارنة على فترة موحدة | ظهور فرق زمني في التقارير اليومية |
استخدم هذه الحقول بوصفها متطلبات بيانات مقترحة للمراجعة وليس وصفًا مؤكدًا لواجهة LYNNC. قد تستعمل المنظومة أسماء مختلفة أو تمرر المصدر داخل نوع طلب ثابت، وقد لا يكون معرّف الجلسة متاحًا. على فريق المطعم أن يطلب حقلًا قابلًا للتفسير لا مجرد لون أو أيقونة في شاشة الإدارة.
افصل مصدر الطلب عن مكان تناوله وطريقة دفعه
هناك ثلاثة أسئلة مستقلة: كيف بدأ الطلب؟ (QR أو موظف أو تطبيق)، أين سينفذ؟ (داخل المطعم أو استلام أو توصيل)، وكيف دُفع؟ (بطاقة أو طريقة أخرى). قد يكون طلب QR داخل المطعم ومدفوعًا عند الكاشير، أو يبدأ عبر موظف ويُستكمل الدفع رقميًا. لذلك لا يصح استنتاج أن كل عملية على طاولة فيها QR تُحسب «مبيعات QR»، أو أن كل دفع رقمي بدأ من مسح الرمز.
للحفاظ على دقة المصدر، اعتمد قاعدة واضحة: إذا بدأ الضيف إنشاء الطلب من واجهة QR واحتفظ النظام بمعرف أصل موثوق، فمصدره QR. وإذا نقل الموظف الطلب يدويًا إلى POS دون معرّف المصدر، فصنّفه «إدخال يدوي يحتاج تحققًا» بدل نسبته إلى QR بناءً على ظن العامل.
كيف يتنقل الطلب من QR إلى POS والمطبخ؟
- يمسح الضيف رمزًا مرتبطًا بمنيو الفرع، وقد يحمل مرجع طاولة عند وجود هذه الوظيفة.
- ينشئ طلبًا مع أصناف وكميات وإضافات ويستلم معرّف طلب من الواجهة.
- تُمرّر البيانات إلى POS أو طبقة إدارة الطلبات وفق التكامل المعتمد، مع الحفاظ على علاقة المعرف الخارجي بالداخلي.
- تُرسل تفاصيل التحضير للمطبخ، بينما تظل حالة الطلب قابلة للمراجعة.
- بعد الإتمام أو الإلغاء أو الاسترداد، يستخدم التقرير الحالة النهائية الصحيحة للفترة المعتمدة.
إذا اكتفى التقرير بعدد مرات فتح المنيو، فهذا ليس عدد الطلبات. وإذا احتسب جميع المحاولات التي دخلت السلة، فقد يُظهر «مبيعات» لم تكتمل. افحص أن التقرير يعتمد على معرّفات طلبات متميزة وحالات مؤهلة لا عدد أحداث الواجهة.
جدول التمييز بين QR والتوصيل والطلبات اليدوية
| الطلب | مصدر الطلب المقترح | نوع التنفيذ | هل يدخل مبيعات QR؟ |
|---|---|---|---|
| ضيف طلب من رمز طاولته واكتمل | QR | داخل الصالة | نعم، بعد إثبات الاكتمال وفق التعريف |
| النادل أدخل الطلب مباشرة في الكاشير | POS / Staff | داخل الصالة | لا |
| طلب من تطبيق توصيل خارجي | Marketplace | توصيل | لا |
| ضيف فتح QR ولم ينشئ طلبًا | QR Page View | لا يوجد طلب | لا |
| طلب QR أُلغي قبل التنفيذ | QR | داخل الصالة | يظهر في إجمالي المحاولات لا المبيعات المكتملة |
| طلب أُدخل يدويًا بعد عطل QR | Manual / Unknown | حسب الحالة | لا يُنسب تلقائيًا إلى QR دون دليل |
يمكن لطلبين من الطاولة نفسها أن يكون لهما مصدران مختلفان، ويمكن للعميل فتح صفحة QR عدة مرات ثم إكمال طلب واحد؛ لذا يجب فصل الجلسات والزيارات عن الطلبات وعن المقبوضات المالية. وقد تؤثر سياسة تجميع الطلبات على معرّفات POS، فتحتاج علاقة واحد إلى متعدد أو العكس ضمن الربط بدل اشتراط التطابق المباشر في جميع الحالات.
كيف تفحص مشكلة «الطلب موجود لكن مصدره غير معروف»؟
اختر طلبًا تجريبيًا مصرحًا به، واحفظ معرّف QR وتوقيت الإنشاء ورقم الطاولة والفرع، ثم ابحث عنه في سجلات الموصل وPOS. إذا وصل الطلب لكن لم ينتقل حقل المصدر، فهذه فجوة Mapping؛ وإذا وصل المصدر لكنه اختفى بعد تصدير التقرير، فالمشكلة في طبقة التقارير أو الفلترة. لا تغير تعريف المبيعات لمجرد أن الحقل غير ظاهر في الواجهة؛ فالأولوية إثبات انتقال المعرّف من المصدر.
نموذج تقرير مصغر لمطابقة مبيعات QR
سيناريو حسابي افتراضي لا يمثل بيانات من LYNNC: سجّل المطعم خلال مناوبة واحدة ثمانية طلبات بدأت عبر QR. اكتملت ست عمليات بقيمة 420 ريالًا، وأُلغي طلب بقيمة 50 ريالًا قبل استحقاقه، وبقي آخر معلقًا بقيمة 70 ريالًا حتى نهاية المناوبة. أظهر POS ست عمليات QR مكتملة بقيمة 420 ريالًا وفق التعريف نفسه. إذن عدد طلبات QR المنشأة 8، بينما عدد الطلبات المكتملة المؤهلة 6، وقيمة المبيعات المكتملة 420 ريالًا قبل مراجعة أي استردادات أو فروق ضريبية. لا يجوز نشر 540 ريالًا باعتبارها «مبيعات QR المكتملة» لأنها تشمل المعلق والملغى.
| المؤشر الافتراضي | القيمة | أساس الاحتساب |
|---|---|---|
| طلبات QR المنشأة | 8 | معرّفات المصدر المتميزة |
| طلبات QR المكتملة | 6 | الحالة النهائية المؤهلة |
| طلبات ملغاة | 1 | تُفصل عن المبيعات المكتملة |
| طلبات معلقة | 1 | تحتاج متابعة أو ترحيل فترة |
| قيمة QR المكتملة | 420 ريالًا | قيمة العمليات الست المعتمدة |
| قيمة POS المطابقة | 420 ريالًا | نفس الست عمليات والفترة |
قد يتغير تفسير المبلغ إذا كانت عملية الاسترداد لاحقة أو إذا كان POS يسجل القيم قبل الخصم بينما مصدر QR يعرضها بعده. لا تجعل هذا التقرير بديلًا عن سياسات الاعتراف بالإيراد أو الفوترة أو كشف التسوية؛ هدفه التأكد من نسبة المصدر الصحيح إلى الطلب التشغيلي أولًا.
فروق الإلغاء والدفع والتوقيت
الطلب الملغى ليس مبيعًا مكتملًا
يجب الاحتفاظ به ضمن تقرير محاولات QR أو إلغاءات الطاولات لتحليل تجربة الضيف، ولكن استبعاده من قيمة المبيعات المكتملة وفق السياسة المالية المعتمدة. قد تختلف دلالات حالات «مقبول» و«مكتمل» بين الواجهة وPOS؛ أنشئ جدول ترجمة لا يعيد تسمية الحالات عشوائيًا.
بدء الدفع لا يثبت تحصيل المبلغ
إذا فتح العميل بوابة الدفع ثم عاد قبل صدور نتيجة مؤكدة، فلا تعلن البيع مكتملًا من حدث النقر وحده. اطلب ربط مرجع الدفع بالطلب والتحقق من النتيجة الحقيقية، مع إجراء آمن للمهل الزمنية يمنع إنشاء دفع أو طلب مكرر.
فارق منتصف الليل بين الأنظمة
قد ينشأ طلب QR قبل الساعة 12 ليلًا ويكتمل بعد ذلك. إذا كان أحد التقريرين مبنيًا على وقت الإنشاء والآخر وقت الإقفال، فستظهر فجوة يومية رغم وجود الطلب في المصدرين. حدد قاعدة موحدة وتاريخًا تشغيليًا معروفًا للمناوبة، واحفظ وقت الحدث الأصلي.
اختبارات قبول تقارير QR قبل التعاقد
| اختبار QA | الدليل المتوقع | ما يعنيه الفشل |
|---|---|---|
| طلب QR مكتمل | وجود مصدر QR ومعرف POS مطابق | فقدان حقل المصدر أو فشل الربط |
| طلب عبر موظف للطاولة نفسها | لا يصنف QR تلقائيًا | خلط المصدر بمكان التنفيذ |
| طلبان QR من جلسة واحدة | رقمان أصليان أو علاقة مفهومة عند الدمج | تجميع خاطئ أو تكرار |
| طلب QR ملغى | يظهر في الإلغاء لا المبيعات المكتملة | تضخيم قيمة البيع |
| دفع غير مؤكد | لا يحتسب كتحصيل ناجح | تضخيم المبيعات المدفوعة |
| تصدير التقرير | حقول المصدر والفرع والمعرف محفوظة | قصور في التصدير أو التحويل |
| فرعان يستخدمان طاولة 5 | تمييز الفرعين بمعرّف مستقل | خلط المبيعات عبر الفروع |
| عملية نهاية المناوبة | قواعد زمنية واضحة ومتسقة | فرق توقيت لا يمثل فقد بيانات |
أضف لكل اختبار تاريخ التنفيذ والطلب المرجعي ولقطة أو تصديرًا داعمًا واسم صاحب الإصلاح. إذا لم توفر المنصة حقل المصدر أصلًا، فلا تكتب في التقرير أن «دعم QR مؤكد من الناحية التحليلية» لمجرد أن واجهة المنيو تعمل؛ اطلب أولًا إثبات إمكانية استخراج المصدر أو تطويرها.
متى تحتاج إلى تعديل الربط لا تغيير النظام؟
إذا وصلت الطلبات إلى POS بصورة صحيحة لكن لا يظهر مصدر QR في التقرير، فقد يكون الحل إضافة Mapping للحقل أو تعديل الاستعلام والتصدير. أما إذا كان مصدر الطلب لا يُمرّر من الأساس أو توجد معرّفات مكررة دون قاعدة معالجة، فقد يحتاج الأمر مراجعة موصل الخدمة. لا تستبدل POS قبل التأكد من مكان فقد المعلومة؛ والمشكلة في التقرير ليست دليلًا على فشل عملية التحضير أو التحصيل.
يمكن أن تساعد منصة LYNNC في ربط الطلبات بأنظمة POS متوافقة ومتابعة حالات التشغيل ضمن الوظائف المعلنة، لكن وجود تقرير مستقل باسم «مبيعات QR» أو حقل تصدير معين أو ربط جلسات الطاولات يحتاج إلى اختبار فعلي مع الفريق قبل اعتماده. كذلك لا تُعامل المنصة بوصفها نظام محاسبة بديلًا، وتُراجع المبالغ والإيداعات بواسطة الفريق المالي.
مؤشرات تقيس جودة إسناد مبيعات QR إلى مصدرها
- نسبة اكتمال إسناد المصدر: طلبات QR المؤهلة التي تحفظ مصدرًا صحيحًا ÷ الطلبات المؤهلة ذات المصدر المعروف في الواجهة.
- نسبة مطابقة المعرف: طلبات QR المكتملة التي تملك مرجع POS قابلًا للربط ÷ إجمالي طلبات QR المكتملة في النطاق.
- الطلبات مجهولة المصدر: عدد طلبات POS في الفئة المعنية دون دليل يثبت مصدرها؛ لا تُوزعها افتراضيًا على QR.
- فارق القيمة المفسرة: إجمالي الاختلافات المصنفة كإلغاء أو خصم أو توقيت بعد توحيد التعاريف.
- عدد المعرفات ذات إعادة محاولة مكررة: المعرفات التي نتج عنها طلب إنتاج إضافي غير مقصود بعد التحقق.
لا تستخدم عدد زيارات صفحة QR بدل عدد الطلبات المدفوعة أو المكتملة؛ فالزيارة مؤشر تفاعل مختلف. وإذا كانت أداة التحليلات تسجل حدث purchase من الموقع، تحقق من عدم تكرار الحدث أو نسبته إلى مصدر طلب آخر؛ فإسناد الزيارات التسويقي ليس هو إسناد مصدر العملية داخل POS.
سيناريو افتراضي في مطعم بمدينة جدة
مثال افتراضي: يلاحظ مدير مطعم في جدة أن إجمالي مبيعات الصالة يطابق الإيرادات العامة، لكن بند QR يساوي صفرًا في التقرير. يختبر طلبًا جديدًا ويكتشف أن السجل الأصلي يحمل المصدر QR بينما يسجله الكاشير بنوع «Dine-in» فقط؛ تُفقد علامة المصدر أثناء التحويل. بعد تعديل الربط في بيئة اختبار، يعيد الفريق استخراج التقرير ويقارن المعرفات قبل اعتبار المشكلة مغلقة. لا تمثل القصة حالة عميل أو تكاملًا موثقًا لدى LYNNC.
الأسئلة الشائعة
لماذا لا تظهر طلبات QR في تقارير المبيعات؟
قد تُسجّل ضمن مبيعات الصالة لأن حقل مصدر الطلب غير محفوظ أو غير معروض في التقرير، أو لأن التقرير يقارن حالات وفترات مختلفة. تحقق من معرف الطلب في الواجهة وفي POS قبل تعديل الإجماليات.
كيف أميز مبيعات QR عن الطلب الذي أخذه الموظف؟
احفظ مصدر الإنشاء كحقل مستقل عن رقم الطاولة ونوع الخدمة وطريقة الدفع. لا يكفي وجود الطلب داخل الصالة لنسبته إلى QR.
هل يُحتسب الطلب الملغى ضمن مبيعات QR؟
يُحفظ في تقرير الطلبات المنشأة والإلغاءات لتحليل التشغيل، لكنه لا يُضاف تلقائيًا إلى المبيعات المكتملة. ارجع إلى تعريف الحالة والمستندات المالية المعتمدة عند وجود استرداد لاحق.
ما أهم اختبار عند ربط QR بنقطة البيع؟
أرسل طلبًا تجريبيًا واضح المرجع، ثم افحص مصدره ومعرفه والفرع والطاولة والحالة والقيمة بعد وصوله إلى POS. كرر الاختبار مع إلغاء ودفع غير مؤكد وتحقق من عدم تضخيم التقرير.
هل أحتاج نظامًا جديدًا إذا اختفى مصدر QR؟
ليس بالضرورة؛ قد تكون المشكلة في Mapping أو التصدير أو تعريف التقرير فقط. حدّد المرحلة التي فقد فيها الحقل ثم قارن تكلفة الإصلاح ومحدودية المنصة قبل الاستبدال.
الخطوة التالية: اطلب عرضًا من LYNNC يوضح ما يمكن تصديره أو عرضه من مصدر الطلب ومرجع POS وحالة الدفع لطاولاتك وفروعك، مع اختبار مطابقة حقيقي بدل الاعتماد على وصف عام للتقارير.
.webp)
.webp)
