تسوية فروقات مبيعات تطبيقات التوصيل مع بيانات الكاشير يوميًا

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

كيف أعالج فرق مبيعات جاهز وهنقرستيشن مع الكاشير؟

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

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

اجمع الملفات الصحيحة قبل مقارنة الأرقام

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

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

صنّف مصادر الفروقات إلى أربع فئات

1. طلب موجود في التطبيق ولا يظهر في POS

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

2. طلب موجود في POS ولا يظهر ضمن تقرير التطبيق

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

3. العدد متطابق والمبلغ مختلف

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

4. المبيعات متطابقة والإيداع أقل

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

نموذج جدول مطابقة على مستوى الطلب

احتفظ بالمبلغ الأصلي لكل مصدر وبالفروق المحسوبة؛ تجنب استبدال القيمة المصدرية بالقيمة «المصححة» حتى لا تفقد أثر المراجعة. سجل كل تعديل مع اسم صاحبه وتاريخ اعتماده والمستند الذي يبرره.

توقيت الإغلاق والطلبات العابرة لمنتصف الليل

اختر أساسًا واضحًا للمعالجة اليومية: هل المقارنة بحسب وقت إنشاء الطلب أو وقت اكتماله في المنطقة الزمنية السعودية؟ إذا بدأ الطلب 11:58 مساءً واكتمل بعد منتصف الليل، فقد يظهر في يومين مختلفين وفق نظام التقرير. عالج هذا الفرق بقاعدة نافذة موحدة أو تقرير عبور، ولا تسجله كطلب مفقود لمجرد اختلاف اليوم.

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

خطوات الإغلاق اليومي: إجراء قابل للتنفيذ

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

كشف تسوية افتراضي يوضح اختلاف الأرقام

مثال افتراضي مبسط بالريال السعودي: سجل تطبيق خمسة طلبات بقيمة 550 ريالًا، ثم أُلغي طلب قيمته 50 ريالًا قبل التنفيذ؛ فأصبحت قيمة الطلبات المكتملة 500 ريال. تحمل المطعم خصمًا بقيمة 20 ريالًا، لتصبح القيمة المستخدمة في هذا المثال 480 ريالًا وفق تعريفه المفترض. يوضح كشف المنصة عمولة 60 ريالًا ورسومًا أخرى 10 ريالات؛ فيكون المبلغ المتوقع من كشف التسوية 410 ريالات إذا لم توجد بنود أخرى. المعادلة: 480 - 60 - 10 = 410. لا تمثل هذه الأرقام أسعارًا فعلية أو معالجة ضريبية معتمدة.

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

تقرير الاستثناءات اليومي

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

من المسؤول عن كل نوع من الفروق؟

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

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

مؤشرات تبين جودة الإقفال اليومي

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

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

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

هل سبب اختلاف الإجمالي هو عمولة التطبيق دائمًا؟

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

كيف أطابق طلبًا ليس له نفس الرقم في POS؟

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

هل أستخدم تاريخ الطلب أم تاريخ التسوية؟

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

ماذا أفعل عندما يتكرر الطلب في الكاشير؟

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

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

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

الخطوة التالية: ناقش متطلبات متابعة قنوات الطلبات مع LYNNC واطلب عرضًا يبين أي حقول وسجلات يمكن توفيرها فعليًا لإجراء مراجعة يومية موثقة.