1 السؤال اللي بنجاوب عليه
عايزين نقدر نراقب الحسابات (مين حصّل كام، بأي وسيلة، في أي فرع، وهل الخزنة متساوية آخر اليوم). السؤال: نعمل الخزن دي لكل فرع؟ لكل كاشير؟ ولا لكل وسيلة دفع؟
الإجابة المختصرة: الحسابات تُعمل لكل وسيلة (+ خزنة كاش لكل فرع). أما الكاشير فمايتعملوش له حساب — الكاشير يُراقَب عن طريق الوردية (Shift)، وهي مبنية فعلاً في النظام. تعمل حساب لكل كاشير = انفجار في شجرة الحسابات وكابوس مطابقة.
2 اكتشاف مهم: النظام بالفعل بيفصل 3 أبعاد على كل دفعة
كل LabPayment بيتختم أوتوماتيك بـ 3 أبعاد — ده أهم أساس للقرار:
الفرع — WHEREbranch_id
من الفاتورة أو فرع المستخدم
الكاشير — WHOcashier_session_id
وردية الكاشير المفتوحة
الوسيلة — HOWpayment_method
cash / visa / tamara…
وكمان فيه LisCashierSession (وردية الكاشير) كاملة:
| الحقل | معناه |
|---|
user_id + branch_id + treasury_id | مين الكاشير، أي فرع، أي خزنة |
opening_float | الفكّة اللي فتح بيها |
expected_cash | الكاش المتوقع (float + تحصيلات الكاش) |
counted_cash · over_short | المعدود فعليًا · الفرق (عجز/زيادة) |
opened_at / closed_at + payments() | وقت الفتح/القفل + كل دفعات الوردية |
المعنى: النظام أصلاً بيعرف مين حصّل كل قرش (عبر الوردية) وفي أي فرع (عبر branch_id). فمحتاجش حسابات منفصلة عشان تراقب الكاشير أو الفرع — دي أبعاد (dimensions) موجودة، مش محتاجة حسابات.
3 المبدأ المحاسبي: حساب (Account) مقابل بُعد (Dimension)
| الحاجة | تتعمل إزاي؟ | ليه |
|---|
| التمييز بين قنوات الدفع (كاش/فيزا/تمارا…) | حساب لكل وسيلة | كل قناة بتتسوّى مع جهة مختلفة (البنك، تمارا، تابي) — لازم رصيد مستقل للمطابقة |
| صندوق الكاش الفعلي | خزنة كاش لكل فرع | كل فرع عنده دُرج فيزيائي حقيقي منفصل |
| مين الكاشير المسؤول | وردية (Shift) — مش حساب | المسؤولية تتحدد بالعدّ آخر الوردية (Z-report)، مش برصيد منفصل |
| أي فرع | بُعد branch_id — مش حساب | موجود على كل دفعة؛ المراقبة بالفلترة/التقرير |
ليه مش حساب لكل كاشير؟ 10 كاشير × 5 وسائل × 3 فروع = 150 حساب في شجرة الحسابات — مستحيل تتطابق أو تتقفل سنويًا. الكاشير وردية مش حساب.
4 المقارنة بين النماذج الثلاثة
| النموذج | المميزات | العيوب | الحكم |
|---|
لكل وسيلة فقط
(كاش، فيزا، تمارا… عامة) |
أبسط؛ مطابقة كل قناة سهلة |
ميفرقش بين الفروع في الكاش الفعلي |
ناقص للفروع |
لكل فرع
(طقم حسابات لكل فرع) |
رصيد كاش مستقل لكل فرع — واقعي للدُرج |
تكرار حسابات الفيزا/تمارا بلا داعٍ (بتتسوّى مركزيًا) |
للكاش فقط |
لكل كاشير
(حساب لكل موظف) |
— |
انفجار الحسابات؛ والوردية بتعمل نفس الغرض أحسن |
لأ |
| الهجين (التوصية) |
وسيلة للقنوات + كاش لكل فرع + كاشير عبر الوردية |
يحتاج طبقة ربط لكل فرع |
✓ الأنسب |
5 التوصية — النموذج الهجين
أ) الحسابات (الخزائن)
- قنوات إلكترونية مشتركة: حساب واحد لكل وسيلة — فيزا/شبكة، تمارا، تابي، تحويل بنكي. (اتعملوا فعلاً: 228/229/230/231). بتتسوّى مركزيًا مع المزوّد، فمفيش داعي تتكرر لكل فرع — إلا لو كل فرع عنده ماكينة شبكة/حساب تاجر مستقل.
- الكاش: خزنة كاش لكل فرع (دُرج فيزيائي مستقل). الفرع الواحد ممكن أكتر من كاشير بالتناوب على نفس الخزنة عبر الورديات.
ب) الكاشير = وردية (مبني فعلاً)
الكاشير يفتح وردية (float)→
يحصّل (كل دفعة تتختم session+branch+method)→
يقفل ويعدّ الكاش→
Z-report: متوقع مقابل معدود = عجز/زيادة
ج) خريطة الربط «وسيلة ← حساب» تبقى على مستويين
- افتراضي عام للشركة (cash, visa, tamara, tabby, transfer).
- تخصيص لكل فرع (override): الكاش يروح لخزنة الفرع؛ والقنوات تورِث الافتراضي العام (أو تتخصص لو الفرع عنده ماكينته).
- وقت التحصيل: النظام يحلّ الحساب =
override الفرع → الافتراضي العام حسب الوسيلة المختارة.
6 إزاي المراقبة هتشتغل (المخرجات)
| التقرير | البُعد | بيجاوب على |
|---|
| Z-report للوردية | الكاشير (session) | الكاشير ده حصّل كام بكل وسيلة؟ كاشه متساوي؟ فيه عجز؟ |
| ملخص الفرع | branch_id | الفرع حصّل كام النهارده، موزّع على الوسائل؟ |
| مطابقة الوسيلة | method account | رصيد حساب الفيزا = كشف البنك؟ تمارا = تقرير تمارا؟ |
كل ده من نفس بيانات الدفعة (branch + session + method) — مفيش تعقيد جديد في الحسابات.
7 الموجود فعلاً مقابل الناقص
| العنصر | الحالة |
|---|
ختم branch_id + cashier_session_id + payment_method على الدفعة | موجود |
| وردية الكاشير (float/expected/counted/over_short) + شاشات Shift/Reconciliation | موجود |
| خزائن لكل وسيلة (فيزا/تمارا/تابي/تحويل) | اتعملت |
| خريطة «وسيلة ← حساب» (إعداد) + تابة في الإعدادات | بدأناها — متوقّفة للنقاش |
| تخصيص الخريطة لكل فرع (override) | ناقص |
| خزنة كاش لكل فرع + ربط الوردية بخزنة الفرع | جزئي (treasury_id موجود) |
| توجيه نافذة التحصيل + الويزارد حسب الوسيلة | ناقص |
8 قرارات محتاج رأيك فيها
قرار 1 — القنوات الإلكترونية لكل فرع؟
الفيزا/تمارا/تابي:
حساب واحد مشترك لكل الفروع (تسوية مركزية)، ولا
كل فرع عنده ماكينة/حساب تاجر مستقل فنعملها لكل فرع؟
(توصيتي: مشتركة، إلا لو فعلاً كل فرع له ماكينة مستقلة)قرار 2 — الكاش لكل فرع
نعمل
خزنة كاش لكل فرع ونلزم الكاشير يفتح ورديته على خزنة فرعه؟
(توصيتي: نعم)قرار 3 — خريطة الربط بمستوى الفرع
الخريطة «وسيلة ← حساب» تبقى
افتراضي عام + override لكل فرع؟
(توصيتي: نعم — مرونة بلا تعقيد)قرار 4 — تمارا وتابي
كل واحد حساب مستقل (أفضل للمطابقة) ولا حساب «محافظ/BNPL» واحد؟
(توصيتي: مستقلين)
9 خطة التنفيذ (بعد موافقتك)
المرحلة 1 — خريطة الربط + تابة الإعدادات
إعداد
lis.method_accounts (عام) + تابة «حسابات وسائل الدفع» في إعدادات المعمل + توجيه نافذة التحصيل والويزارد حسب الوسيلة.
المرحلة 2 — خزن الكاش لكل فرع + الفرع في الخريطة
خزنة كاش لكل فرع + طبقة override لكل فرع + ربط فتح الوردية بخزنة الفرع.
المرحلة 3 — تقارير المراقبة
Z-report للوردية (لو محتاج تحسين) + ملخص الفرع بالوسائل + شاشة مطابقة كل حساب وسيلة.
10 الخلاصة
حساب لكل وسيلة + خزنة كاش لكل فرع + الكاشير عبر الوردية. النظام أصلاً بيختم (فرع + وردية + وسيلة) على كل دفعة، فالمراقبة أبعاد جاهزة مش حسابات جديدة. الكاشير وردية مش حساب. كل اللي ناقص: طبقة ربط لكل فرع + توجيه التحصيل بالوسيلة + تقارير المطابقة.