التاجر متعدد الفروع: أدوار الموظفين وظهور الفروع وصلاحيات النقاط

لماذا يحتاج التاجر متعدد الفروع إلى نموذج خاص

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

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

ويتبع T-CODE، تطبيق العروض والولاء الذي صمّمته FLUIDS وبنته، هذا النهج. ينشئ التاجر ملف المتجر ويضيف الفروع، ويُظهر كل فرع أو يخفيه بحسب جاهزيته. ويتضمن نموذج أدوار التاجر فيه المالك والموظف، وإسناد الموظفين إلى الفروع، وفصل صلاحية منح نقاط الولاء عن صلاحية استخدامها. ويمكن أن يحصل الموظف على إسناد إلى فرع ووصول إلى نقطة البيع دون دور المالك الكامل.

نموذج بيانات المتجر والفرع والموظف

يحتاج نموذج الفروع المتعددة الواضح إلى كيانات قليلة، يجيب كل منها عن سؤال سيُطرح على التطبيق يوميًا:

• طلب التاجر: من قدّم الطلب، وهل وافقت عليه المنصة؟ في T-CODE تأتي الموافقة قبل إنشاء المتجر.
• المتجر: النشاط كما يعرفه المتسوّقون، باسمه وتصنيفه وبيانات تواصله وملفه.
• الفرع: موقع فعلي بإحداثياته وبيانات تواصله ومؤشر ظهوره، وإليه تُربط العروض وعناصر القائمة والموظفون.
• العضوية: ربط بين شخص والمتجر، مع دور (مالك أو موظف)، وإسناد إلى فرع بالنسبة إلى الموظف.
• الصلاحيات: إجراءات محددة يحق للموظف تنفيذها، مثل تأكيد الأكواد أو منح النقاط أو قبول استخدامها.

وربط البيانات بالفرع لا بالمتجر يؤتي ثماره سريعًا. ففي T-CODE تُنشر العروض لفرع محدد، ويمكن أن تكون عناصر القائمة خاصة بفرع، وهذا مهم حين يبيع موقعان أشياء مختلفة. وتُجهَّز سلة الطلب بالنقاط لفرع من فروع المتجر؛ وربط السلة بالفرع يتيح أن تكون نقطة البيع التي تؤكّد العملية هي نفسها التي تسلّم الطلب.

أدوار المالك والموظف: جدول الصلاحيات

أبسط نموذج عملي هو دور مالك بتحكم كامل، ودور موظف تُفعَّل قدراته واحدة واحدة وتقتصر على الفرع المُسند إليه. والجدول التالي نقطة بداية مقترحة، لا الإعداد الفعلي في T-CODE، وهو مبني على الفصل الذي يعتمده T-CODE بين منح النقاط وقبول استخدامها:

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

ظهور الفروع: إظهار كل فرع أو إخفاؤه

ينبغي أن يكون لكل فرع مفتاح ظهور خاص به، لأن الفروع نادرًا ما تجهز كلها معًا. فقد يُعدّ فرع جديد في التطبيق قبل افتتاحه، وقد يُغلق فرع للتجديد، وقد يريد المالك تجربة الإعداد على فرع تجريبي أولًا. ويتيح T-CODE للتاجر إضافة الفروع وإظهار كل فرع أو إخفاءه بحسب جاهزيته.

ويجب أن تكون لإخفاء الفرع آثار متوقعة:

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

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

لماذا تنفصل صلاحية منح النقاط عن صلاحية استخدامها

يُفصل منح النقاط عن قبول استخدامها للسبب نفسه الذي تفصل به المنشآت بين من يسجّل البيع ومن يعتمد الاسترجاع: لا ينبغي لشخص واحد أن يتحكم في طرفَي تدفق القيمة دون رقابة. فإذا استطاع أي موظف صندوق أن يضيف النقاط ويستخدمها معًا، أمكنه إضافة نقاط إلى محفظة صديق واستبدالها بمنتجات مجانية في اليوم نفسه.

والفصل وحده لا يكفي، بل يعمل أفضل مع قواعد مساندة قليلة:

1. اربط المنح بالإيصالات. يحمل كل منح بيانات الإيصال، ولا يكسب الإيصال نفسه مرتين.
2. امنع المنح للنفس. لا يستطيع الموظف منح النقاط لمحفظته الشخصية بوصفه عميلًا.
3. سجّل المنفّذ. تحفظ كل عملية منح أو استخدام اسم الموظف والفرع.
4. راجع الكشوف. يقرأ المالك كشوف التاجر وشاشات الحركات بحسب الفرع والموظف.
5. احتفظ بسجلات نقطة البيع. تُظهر سجلات نقطة البيع ما تم تأكيده، ومن أكّده، ومتى.

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

تنفيذ صلاحيات الفروع بأمان

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

وبعض الممارسات تُبقي هذا الأمر قابلًا للإدارة مع نمو التجّار:

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

إذا كان نشاطك يدير عدة فروع ويريد العروض والولاء وضوابط الموظفين في منتج واحد، فاطّلع على دراسة مشروع T-CODE، وعلى طريقة عرض أرقام الفروع في لوحة عروض التاجر، وعلى خدمتَي البرمجيات المخصصة ومنصات الأسواق. وتتفق FLUIDS على النطاق والسعر والمدة في عرض مكتوب قبل التطوير، وتكون الشيفرة المصدرية ملكًا لك.