لو بتدوّر على «برنامج فواتير» أو «نظام كاشير»، غالباً إنت في واحدة من تلات حالات: بتشتغل على إكسل وبقى مؤلم، أو عندك نظام قديم بيعمل مشاكل، أو بتفتح نشاط جديد وعايز تبدأ صح. التلات حالات بيسألوا نفس السؤال الغلط: «أنهي برنامج أحسن؟»
السؤال الصح: «أنهي نظام بيتعامل مع الحالات الشاذة عندي صح؟» لأن كل الأنظمة بتعرف تعمل فاتورة بيع عادية. الفرق بيظهر في المرتجع، والإلغاء، والخصم الاستثنائي، والعميل اللي دفع نص المبلغ، والكهربا اللي قطعت.
الدليل ده مكتوب من زاوية بناء النظام مش استخدامه — يعني هيوريك القرارات اللي وراه، عشان تعرف تسأل البائع أسئلة تكشف الفرق الحقيقي.
أول حاجة: إنت محتاج فوترة ولا محاسبة؟
ده أكتر خلط بيكلّف فلوس. الكلمتين بتتقالوا بالتبادل في السوق، وهما حاجتين مختلفتين.
نظام الفوترة ونقاط البيع
بيدير دورة البيع: كتالوج الأصناف وأسعارها، إنشاء الفاتورة ببنودها، إصدارها، تحصيل المدفوعات، المرتجعات، وشاشة الكاشير للبيع المباشر. مخرجاته: فواتير، تحصيلات، تقارير مبيعات، وحركة مخزون.
النظام المحاسبي
بيدير الدفاتر: دليل الحسابات، القيود اليومية، الأستاذ العام، الميزانية وقائمة الدخل، والتسويات البنكية. مخرجاته: قوائم مالية.
ليه الفرق ده مهم عملياً
نسبة كبيرة من الشركات الصغيرة والمتوسطة محتاجة الأول بس. المحاسبة بتتعمل عند مكتب محاسبي خارجي بيستلم تصدير شهري من نظام الفوترة. الشركة اللي بتشتري نظام ERP محاسبي كامل وهي محتاجة فوترة بس، بتدفع أضعاف وبتستخدم ١٥٪ من النظام — وبتتعب في التشغيل والتدريب.
والعكس صحيح: شركة عندها عمليات مالية معقّدة وبتحاول تديرها ببرنامج فوترة، بتفضل تعمل نص الشغل في إكسل جنب النظام.
الاختبار العملي: اسأل نفسك — محتاج تطلع قائمة دخل من النظام نفسه؟ لو أيوه، إنت محتاج محاسبة. لو المحاسب بتاعك بيعمل ده من التصدير، إنت محتاج فوترة كويسة وتصدير نضيف.
مكوّنات نظام الفوترة ونقاط البيع
كتالوج الأصناف
ده الأساس اللي كل حاجة بتقف عليه. الصنف بيحمل: الاسم، الكود، سعر البيع، نسبة الضريبة، والوحدة. والقرار المهم هنا إن الأصناف لازم تكون مشتركة بين الفوترة والمخزون — جدول واحد مش اتنين. لو كل وحدة عندها كتالوج مستقل، هتلاقي صنف موجود في المبيعات ومش موجود في المخزون، والفرق ده بيكبر مع الوقت.
الفاتورة وبنودها
الفاتورة مش سطر واحد فيه إجمالي — هي رأس (العميل، التاريخ، الرقم، الحالة) وبنود (كل بند: صنف، كمية، سعر، خصم، ضريبة). والإجماليات محسوبة من البنود مش مكتوبة.
المدفوعات
الفاتورة ممكن تتحصّل على دفعات. فحالة الفاتورة (غير مدفوعة / مدفوعة جزئياً / مدفوعة بالكامل) لازم تكون محسوبة من مجموع المدفوعات، مش حقل بيتغيّر بالإيد. الفرق: لو الحالة حقل، ممكن تتغيّر من غير ما يكون فيه فلوس دخلت فعلاً.
شاشة الكاشير (POS)
واجهة سريعة للبيع المباشر: بحث بالكود أو الباركود، سلة، دفع، طباعة. متطلباتها مختلفة تماماً عن شاشة الفوترة العادية — هنا السرعة أهم من التفصيل.
المرتجعات
مش وحدة منفصلة — هي دفعة بالسالب على نفس الفاتورة. أي تصميم تاني بيكسر الأثر.
قرارات التصميم اللي بتفرق فعلاً
الجزء ده هو جوهر الدليل. دي القرارات اللي مش بتظهر في العرض التقديمي بس بتحدّد إذا كان النظام هيصمد ولا لأ.
١. رقم الفاتورة بيتولّد وقت الإصدار
لو النظام بيدّي رقم للمسودة، وبعدين المستخدم ساب المسودة أو حذفها، التسلسل هيبقى فيه فجوة: ١٠٠١، ١٠٠٢، ١٠٠٤.
الفجوة دي مش تفصيلة جمالية. هي أول حاجة بيسأل عنها المراجع، والسؤال بيبقى «فين فاتورة ١٠٠٣؟» — وإجابة «دي كانت مسودة» محتاجة إثبات. النظام اللي بيرقّم وقت الإصدار بس، تسلسله متصل بطبيعته.
٢. الفاتورة الصادرة سجل رسمي مبيتعدّلش
لما تصدر فاتورة، هي بقت مستند. لو فيه غلط:
- إلغاء بسبب — الفاتورة بتفضل موجودة بحالة «ملغاة» وسبب مكتوب، مش بتختفي.
- دفعة استرداد — لو فيه فلوس اتقبضت.
والقاعدة المهمة: الإلغاء يترفض لو فيه تحصيل. لازم الاسترداد يتسجّل الأول. النظام اللي بيسمح تلغي فاتورة محصّلة بضغطة، بيسيب فلوس في السجلات مالهاش مقابل.
٣. البند بيحتفظ بسعره وضريبته
لما تعمل فاتورة، البند بيتخزّن بسعره ونسبة ضريبته وقت الإصدار. مش بيقراهم من جدول الأصناف وقت العرض.
ليه؟ لأنك لو غيّرت قائمة الأسعار الشهر الجاي، كل الفواتير القديمة هتتغيّر أرقامها لو النظام بيقرا من الأصناف. وده معناه إن فاتورة اتحصّلت من ٦ شهور ممكن تبان بمبلغ مختلف عن اللي العميل دفعه فعلاً.
٤. سلة الكاشير محفوظة في قاعدة البيانات
مش في جلسة المتصفح. السبب بسيط: انقطاع الكهربا أو إعادة تشغيل الجهاز أو قفل المتصفح بالغلط. لو السلة في الجلسة، العملية ضاعت والزبون واقف. لو في قاعدة البيانات، الجهاز يرجع والسلة زي ما هي.
ده اختبار تقدر تعمله في العرض التقديمي: اطلب من البائع يقفل المتصفح في نص عملية بيع ويفتحه تاني.
٥. الكاشير بيسجّل المستحق مش المدفوع
لو الفاتورة ١٨٠ ريال والعميل دفع ٢٠٠، النظام بيسجّل تحصيل ١٨٠ والباقي بيرجع للعميل. مش بيسجّل ٢٠٠ كتحصيل زيادة. حاجة تبان بديهية لكن أنظمة كتير بتغلط فيها، والنتيجة أرقام تحصيل متضخّمة متطابقش الخزنة.
الضريبة: التفصيلة اللي بتوقّع
ضريبة القيمة المضافة مطبّقة في السعودية والإمارات ومصر بنسب مختلفة، والفوترة الإلكترونية بقت إلزامية في أكتر من سوق. أي نظام فوترة لازم يتعامل مع التالي:
الضريبة على مستوى البند
مش على مستوى الفاتورة. لأن الفاتورة الواحدة ممكن يكون فيها أصناف خاضعة وأصناف معفاة أو بنسبة صفر. النظام اللي بيحط نسبة واحدة على الفاتورة كلها بيبقى غير صالح لأي نشاط عنده تنوّع في الأصناف.
الأسعار شاملة ولا غير شاملة
قرار لازم يتحدّد من البداية ويكون واضح في العرض والفاتورة. المحلات غالباً بتعرض أسعار شاملة (الزبون بيدفع الرقم المكتوب)، والبيع للشركات غالباً غير شامل. النظام لازم يدعم الاتنين ويحسب صح في الحالتين.
بيانات الفاتورة الضريبية
الرقم الضريبي للبائع وللمشتري (في فواتير الشركات)، التاريخ والوقت، تفصيل الضريبة، والإجمالي قبل وبعد. النظام لازم يخزّن الرقم الضريبي للعميل التجاري — وده سبب إن العميل الشركة لازم يكون كيان مستقل عن الشخص اللي بيتعامل معاك.
ملاحظة عن الفوترة الإلكترونية
متطلبات الربط مع المنظومات الحكومية بتختلف من دولة لدولة وبتتحدّث دورياً. لو نشاطك خاضع لإلزام الفوترة الإلكترونية، ده بند مستقل في التقييم لازم تسأل عنه صراحة: النظام بيدعم الربط؟ ومين مسؤول عن التحديثات لما المتطلبات تتغيّر؟ ماتفترضش إن أي نظام فوترة بيدعمه تلقائياً.
الربط بالمخزون
نظام فوترة مش مربوط بالمخزون بيخلق شغل يدوي شهري ثابت.
الخصم التلقائي
الفاتورة لما تتصدر بتخصم من المخزون تلقائياً. من غير ده، هتفضل تعمل جرد وتلاقي فروقات وتقعد تدوّر على مصدرها.
متوسط التكلفة المتحرك
تكلفة البضاعة المباعة لازم تتحسب بمتوسط متحرك مش بآخر سعر شراء. لو اشتريت ١٠٠ قطعة بـ١٠ و١٠٠ بـ١٢، القطعة اللي بعتها تكلفتها ١١ مش ١٢. الفرق ده بيظهر في هامش الربح، ولو غلط يبقى كل تقارير الربحية غلط.
مخازن متعددة وتحويلات
لو عندك أكتر من فرع أو مخزن، لازم النظام يعرف كل صنف موجود فين، ويسجّل التحويلات بينهم كحركة مستقلة.
حد إعادة الطلب
تنبيه لما الرصيد ينزل تحت حد معيّن. حاجة بسيطة بتمنع نفاد أصناف بتبيع.
لو عايز تتعمّق في الجانب ده تحديداً، فيه دليل منفصل عن أنظمة إدارة المخزون بيغطي دفتر الحركات والجرد والتسويات.
التقارير اللي بتحتاجها فعلاً
أغلب الأنظمة بتتباهى بعدد التقارير. العدد مش مهم — دي التقارير اللي بتتستخدم فعلاً:
- مبيعات بالفترة — يومي وشهري، مع مقارنة بالفترة السابقة.
- الأصناف الأكثر مبيعاً — بالكمية وبالقيمة (مش نفس الترتيب).
- المتحصّل مقابل المستحق — الفرق ده هو الفلوس اللي برّه.
- المرتجعات — نسبتها لكل صنف، لأن الصنف اللي بيترجع كتير فيه مشكلة.
- حركة المخزون — دخول وخروج وتسويات.
- أداء الكاشير — عدد العمليات ومتوسط الفاتورة لكل موظف.
والأهم من التقارير نفسها: التصدير. لازم تقدر تطلع CSV يفتح صح بالعربي — لأن ده اللي هتديه للمحاسب.
جاهز ولا مخصص؟
ده قرار بيتاخد بالحساب مش بالانطباع.
الجاهز يكفيك لو
- دورة البيع عندك قياسية: صنف، سعر، فاتورة، تحصيل.
- التسعير بسيط أو بقوائم أسعار محدودة.
- مش محتاج ربط بأنظمة قائمة عندك.
- عدد المستخدمين مستقر.
ابدأ تحسب المخصص لو
- عندك منطق تسعير أو خصومات خاص بنشاطك.
- محتاج دورة موافقات قبل الإصدار.
- محتاج ربط بنظام قائم (موقع، تطبيق، نظام محاسبي).
- بتشتغل بأكتر من كيان أو شركة تحت نفس الإدارة.
- الاشتراك الشهري لكل مستخدم بقى بند كبير مع نمو الفريق.
الاختبار العملي
اكتب دورة البيع عندك خطوة بخطوة على ورقة. بعدين شوف كل خطوة: النظام الجاهز بيعملها؟ لو لقيت أكتر من خطوتين هتضطر تعملهم خارج النظام (في إكسل أو ورق أو واتساب)، ابدأ تقارن تكلفة المخصص. والحساب بيكون على ٣ سنين مش سنة — لأن الاشتراك بيتراكم والترخيص الواحد لأ.
لو وصلت لنقطة إن المخصص هو الحل، دليل تطوير الأنظمة والبرمجيات المخصصة بيشرح مراحل البناء ومعايير تقدير التكلفة.
الأخطاء الشائعة في التطبيق
١. الترحيل بدون تنضيف
نقل كتالوج الأصناف من النظام القديم بكل ما فيه من تكرار وأصناف ميتة. النتيجة: نظام جديد بنفس فوضى القديم. النقل فرصة للتنضيف — استغلها.
٢. التدريب على الحالة العادية بس
الكاشير بيتعلّم يبيع في ساعة. اللي بيحتاج تدريب هو: العميل اللي غيّر رأيه بعد الدفع، والصنف اللي رجع تالف، والخصم اللي المدير وافق عليه بالتليفون. لو الحالات دي مش مغطّاة بإجراء واضح، الموظف هيخترع حل — والحل ده غالباً بيكسر السجلات.
٣. الصلاحيات المفتوحة
كل الموظفين بصلاحية إلغاء وخصم. ده مش تيسير — ده فتح باب. الأدوار لازم تكون محدّدة: مين يبيع، مين يلغي، مين يخصم، ومين يشوف التقارير.
٤. تجاهل النسخ الاحتياطي
سؤال بسيط: لو السيرفر وقع النهاردة، ترجع لآخر إمتى؟ لو الإجابة مش واضحة أو «الشركة بتعمل نسخ»، اطلب تشوف النسخة وتجرّب استرجاعها. النسخة اللي متجرّبتش استرجاعها مش نسخة.
٥. البدء بكل الفروع مرة واحدة
فرع واحد لأسبوعين بأرقام حقيقية بيكشف مشاكل مستحيل تظهر في بيئة تجريبية. بعدها التوسّع بيبقى أسهل بكتير.
أسئلة تسألها للبائع قبل الشراء
الأسئلة دي مصمّمة تكشف التصميم مش تسمع العرض:
- رقم الفاتورة بيتولّد إمتى — عند المسودة ولا عند الإصدار؟
- ينفع أعدّل فاتورة صادرة؟ لو لأ، إزاي بتصحّحوا الأخطاء؟
- لو فاتورة اتحصّلت وعايز ألغيها، النظام بيعمل إيه؟
- الضريبة على مستوى البند ولا الفاتورة؟
- البند بيحتفظ بسعره لو قائمة الأسعار اتغيّرت؟
- اقفل المتصفح دلوقتي في نص عملية بيع — السلة هترجع؟
- الفاتورة بتخصم من المخزون تلقائي؟ التكلفة بتتحسب إزاي؟
- المرتجع بيتسجّل إزاي — دفعة بالسالب ولا تعديل؟
- حد المستخدمين بيتحسب بالحسابات ولا بالجلسات المتزامنة؟
- بيشتغل لو النت قطع؟
- التصدير بيطلع CSV بالعربي صح؟
- لو وقفت الاشتراك، بياناتي تطلع إزاي؟
البائع اللي بيجاوب على دي بوضوح وسرعة، غالباً النظام عنده مبني صح. اللي بيلف حوالين الإجابة، دوّس على السؤال تاني.
متطلبات مختلفة حسب نوع النشاط
«نظام نقاط بيع» مصطلح واحد بيغطي احتياجات متباينة. اللي يشتغل في محل ملابس ممكن يفشل في مطعم.
محلات التجزئة
الأولوية للسرعة والباركود. الكاشير بيمسح، السلة بتتكوّن، الدفع بيتم. المتطلبات الخاصة:
- المقاسات والألوان — القميص الأزرق مقاس L صنف مستقل في المخزون بكود مستقل، مش «قميص». لو النظام مابيدعمش المتغيّرات (variants)، هتبقى كل مقاس صنف منفصل بالإيد — فوضى.
- الاستبدال — مش مرتجع ومش بيع جديد، هو الاتنين مع بعض. النظام لازم يسجّل الحركتين مربوطتين.
- الجرد المتكرر — التجزئة بتحتاج جرد جزئي دوري مش سنوي.
المطاعم والكافيهات
الأولوية لدورة الطلب مش لسرعة المسح:
- الطاولات — الفاتورة بتفضل مفتوحة والزبون بيزوّد. فالسلة عمرها ساعة مش ثانيتين، وده بيخلّي حفظ السلة في قاعدة البيانات مش رفاهية.
- تقسيم الفاتورة — طاولة أربعة أشخاص كل واحد بيدفع نصيبه. لو النظام مابيدعمش التقسيم، الكاشير هيعمل أربع فواتير يدوي والأرقام هتبوظ.
- الإرسال للمطبخ — الطلب لازم يوصل للتحضير قبل الدفع.
- الوصفات — بيع كوب قهوة يخصم بُن ولبن وكوب، مش «كوب قهوة». من غير ده، المخزون مش هيتخصم صح.
ولو نشاطك مطعم، فيه دليل منفصل عن منيو QR للمطاعم بيغطي جانب القائمة الرقمية وربطها بالطلب.
الصيدليات
أعلى مستوى تعقيد رقابي:
- تاريخ الصلاحية والدفعات — الصرف بالأقرب انتهاءً أولاً، وتنبيه قبل الانتهاء بفترة كافية للإرجاع للمورّد.
- الأصناف المقيّدة — بعض الأدوية محتاجة تسجيل بيانات إضافية عند الصرف.
- البدائل — الصنف الناقص له بديل بنفس المادة الفعالة.
التفاصيل دي مغطّاة أعمق في دليل أنظمة إدارة الصيدليات.
الشركات الخدمية
مافيش مخزون ومافيش كاشير — الفوترة هنا مختلفة:
- الفوترة الدورية — عقد شهري بيولّد فاتورة تلقائياً.
- الفوترة بالساعة أو بالمرحلة — بند الفاتورة مرتبط بشغل اتنفّذ مش بصنف.
- الدفعات المقدّمة — دفعة قبل بدء الشغل، والفواتير بتتخصم منها.
الأجهزة: اللي محتاجه فعلاً
سؤال بيتنسي في التقييم وبيظهر يوم التشغيل.
الطابعة الحرارية
مش طابعة عادية. الطباعة الحرارية أسرع ومافيهاش حبر. النقطة المهمة: عرض الورق — ٥٨ مم أو ٨٠ مم. النظام لازم يدعم العرض اللي عندك، والفاتورة تتقص صح. اسأل عن ده تحديداً لأن قالب مطبوع على عرض غلط بيطلع مقطوع من الجنب.
قارئ الباركود
أغلب القارئات بتشتغل كلوحة مفاتيح — بتكتب الكود وتضغط Enter. يعني بتشتغل مع أي نظام تقريباً. القرار الوحيد: سلكي أرخص وأثبت، لاسلكي أريح لو بتمسح بضاعة كبيرة.
درج النقدية
بيتفتح بإشارة من الطابعة الحرارية غالباً. فلو النظام بيطبع، الدرج بيفتح. تأكّد إن النظام بيدعم إشارة الفتح ومش محتاج تفتحه بالإيد كل عملية.
شاشة العميل
مش ضرورية، بس بتقلّل الخلافات — الزبون شايف الأصناف والسعر وهو بيتحاسب.
الجهاز نفسه
جهاز POS مخصص أغلى وأقوى ومقاوم للأتربة والسوائل. تابلت أو كمبيوتر عادي أرخص وبيشتغل تمام في بيئة نضيفة. القرار حسب المكان مش حسب الميزانية بس.
تعدد الفروع
لما تفتح فرع تاني، مجموعة أسئلة جديدة بتظهر:
الأسعار موحّدة ولا لكل فرع؟
محلات كتير بتسعّر مختلف حسب المنطقة. النظام لازم يدعم قوائم أسعار متعددة، والفاتورة تتخزّن بالسعر اللي اتباع بيه فعلاً.
المخزون منفصل ولا مشترك؟
كل فرع رصيده المستقل، مع إمكانية تحويل بينهم. والتحويل حركة مستقلة ليها تاريخ ومسؤول — مش تعديل أرقام.
التقارير مجمّعة ومفصّلة
المدير محتاج يشوف الإجمالي ويقدر ينزل لفرع واحد. ومدير الفرع المفروض يشوف فرعه بس — دي صلاحية مش تفضيل.
ترقيم الفواتير بين الفروع
تسلسل واحد لكل الشركة ولا تسلسل لكل فرع ببادئة؟ الاتنين مقبولين، بس لازم القرار يتاخد من البداية ويكون ثابت. التغيير بعد التشغيل بيخلق فوضى في السجلات.
سجل المراجعة والصلاحيات
ده الجزء اللي محدش بيسأل عنه لحد ما يحصل مشكلة.
إيه اللي لازم يتسجّل
كل عملية حسّاسة: إصدار، إلغاء، خصم، مرتجع، تعديل سعر، تسوية مخزون. والسجل لازم يحتوي: مين، إمتى، إيه القيمة قبل وبعد. سجل بيقول «اتعدّل» من غير تفاصيل مش سجل.
السجل مبيتمسحش
لو المستخدم يقدر يمسح من سجل المراجعة، السجل بلا قيمة. الصلاحية دي المفروض متكونش موجودة لأي حد — ولا حتى المدير.
الأدوار العملية
- كاشير — بيبيع ويحصّل. مش بيلغي ومش بيخصم فوق حد معيّن.
- مشرف وردية — بيوافق على الإلغاء والخصم الاستثنائي.
- مدير فرع — تقارير فرعه وإدارة مستخدمينه.
- محاسب — قراءة وتصدير بدون تعديل.
- مدير عام — كل حاجة ما عدا مسح السجل.
قفل الوردية
نهاية الوردية بيتقفل: عدد العمليات، الإجمالي، والنقدي المفروض يكون في الدرج. الفرق بين المفروض والفعلي بيتسجّل. من غير الخطوة دي، أي عجز بيظهر بعد شهر ومحدش يعرف حصل إمتى.
حساب التكلفة على ثلاث سنين
مقارنة السعر الشهري لوحدها مضلّلة. الحساب الصح على ثلاث سنين وبيشمل بنود مش ظاهرة في العرض.
بنود التكلفة الكاملة
- الترخيص أو الاشتراك — والفرق الجوهري: الاشتراك لكل مستخدم بيتضاعف مع نمو الفريق، والترخيص للمنشأة ثابت.
- التركيب والإعداد — مرة واحدة، بتشمل رفع الأصناف والأرصدة الافتتاحية.
- الترحيل — لو عندك نظام قديم فيه تاريخ محتاج ينتقل.
- التدريب — الأول ومع كل موظف جديد.
- الأجهزة — طابعة ودرج وقارئ لكل نقطة بيع.
- الدعم السنوي — اسأل: مشمول ولا نسبة من الترخيص؟
- التخصيص — أي تعديل خارج المتاح.
مثال عملي على الفرق
افترض شركة بـ٦ مستخدمين. اشتراك بـ٢٥ دولار للمستخدم شهرياً = ١٥٠ دولار شهرياً = ١,٨٠٠ سنوياً = ٥,٤٠٠ على ثلاث سنين — ودي لو عدد المستخدمين ما زادش. لو بقوا ١٠ في السنة التانية، الرقم بيقفز.
في المقابل، ترخيص للمنشأة بتكلفة مقدّمة أعلى بس ثابتة، بيبقى أرخص من نقطة معيّنة. النقطة دي بتختلف حسب حجم الفريق — والحساب ده هو اللي المفروض يحدّد القرار مش الانطباع عن السعر الشهري.
السؤال اللي بينسي
لو وقفت الاشتراك، بياناتك تطلع إزاي؟ بصيغة تقدر تستوردها في نظام تاني ولا PDF؟ ده بند تفاوضي المفروض يتحدّد قبل التوقيع مش بعده.
الترحيل من نظام قديم
أكتر مرحلة بتفشل فيها المشاريع، وأغلب الفشل بيبقى في التخطيط مش في التقنية.
الترتيب الصح
- الأصناف الأول — كل حاجة تانية معلّقة عليها. نضّف التكرار واحذف الميت قبل النقل.
- العملاء — مع توحيد أرقام التليفون في صيغة واحدة، لأن ده مفتاح البحث والدمج.
- الأرصدة الافتتاحية للمخزون — بجرد فعلي في يوم محدد، مش بأرقام النظام القديم.
- الأرصدة المدينة — الفواتير غير المحصّلة بس، مش تاريخ المبيعات كله.
- التاريخ — اختياري. الأغلب بيحتفظ بالنظام القديم للقراءة فقط بدل نقل سنين من البيانات.
قاعدة عملية
ماتنقلش تاريخ المبيعات كله. سيب النظام القديم شغّال للاطلاع لمدة سنة، وابدأ الجديد برصيد افتتاحي نضيف. نقل ٥ سنين من البيانات بيجيب معاه ٥ سنين من الأخطاء.
التشغيل المتوازي
أسبوع بالنظامين مع بعض على فرع واحد. مرهق لكنه بيكشف الفروقات وهي صغيرة. والمقارنة اليومية بتكون على رقمين: إجمالي المبيعات وعدد العمليات. لو اتطابقوا لأسبوع، إنت جاهز.
مؤشرات تتابعها بعد التشغيل
النظام مش هدف — هو أداة بتدّي أرقام. دي الأرقام اللي بتفرق:
- متوسط قيمة الفاتورة — بيقيس فعالية البيع الإضافي.
- عدد العمليات في الساعة — بيكشف أوقات الذروة ويحدّد احتياج الموظفين.
- نسبة المرتجعات لكل صنف — الصنف اللي بيترجع أكتر من غيره فيه مشكلة جودة أو وصف.
- معدل دوران المخزون — الصنف اللي بيقعد شهور فلوسك واقفة فيه.
- نسبة الخصومات — لو بتزيد بدون قرار، فيه تسريب.
- فروقات قفل الوردية — لو بتتكرر مع موظف معيّن، ده مؤشر مش صدفة.
وأهم من كل ده: راجعهم شهرياً بشكل ثابت. التقارير اللي محدش بيفتحها مالهاش قيمة مهما كانت دقيقة.
نموذج النشر: سحابي ولا محلي؟
قرار بيأثر على التكلفة والاعتمادية والتحكم، وأغلب الناس بتاخده بالانطباع.
السحابي
النظام على سيرفر الشركة المزوّدة، وإنت بتدخل من المتصفح.
- ليه: بدء سريع، بدون سيرفر عندك، تحديثات تلقائية، وصول من أي مكان، نسخ احتياطي مسؤولية المزوّد.
- عليه: النت شرط للتشغيل، التكلفة متكرّرة وبتنمو مع المستخدمين، وبياناتك عند طرف تاني.
المحلي
النظام على سيرفر في مقرّك أو فرعك.
- ليه: بيشتغل من غير إنترنت، البيانات عندك، التكلفة مقدّمة وثابتة، والأداء أسرع داخل الشبكة.
- عليه: مسؤولية النسخ الاحتياطي والصيانة عليك، والوصول من برّه محتاج إعداد إضافي.
الهجين
نقاط البيع بتشتغل محلياً وبتزامن مع مركزي لما النت يرجع. الأنسب لتعدد الفروع في أماكن النت فيها غير مستقر — بس أعقد في التنفيذ، فاسأل عن سلوك التعارض: لو نفس الصنف اتباع في فرعين والاتنين أوفلاين، النظام بيتصرّف إزاي؟
إزاي تختار عملياً
اسأل سؤالين:
- لو النت قطع ساعتين، البيع بيقف؟ لو الإجابة كارثية، السحابي البحت مش خيارك.
- عندك حد يقدر يتابع سيرفر؟ لو لأ، المحلي هيبقى عبء إلا لو المزوّد بياخد المسؤولية بعقد صيانة واضح.
ولاحظ إن السؤال مش «أنهي أحدث». المحلي مش قديم — هو خيار هندسي بيتاخد لأسباب.
التكاملات: إمتى تحتاجها وإزاي تسأل عنها
نظام الفوترة نادراً ما بيعيش لوحده. دي أكتر التكاملات طلباً وإيه اللي تسأل عنه في كل واحد.
مع المتجر الإلكتروني
لو بتبيع أونلاين وفي المحل، المخزون لازم يكون واحد. من غير التكامل ده هتبيع أونلاين صنف خلص من المحل — وده بيخلق إلغاء طلب وتجربة سيئة.
اسأل: المزامنة لحظية ولا كل فترة؟ والاتجاه واحد ولا الاتنين؟ ولو الطلب أونلاين اتلغى، الرصيد بيرجع تلقائي؟
مع النظام المحاسبي
لو عندك محاسبة منفصلة، التكامل بيوفّر إدخال مزدوج.
اسأل: التصدير بصيغة النظام المحاسبي اللي عندك؟ وبيتم يدوي ولا مجدول؟ والمرتجعات بتنتقل صح؟
مع واتساب
إرسال الفاتورة أو تأكيد الطلب على واتساب بقى متوقّع من العميل في السوق العربي، ومعدل قراءته أعلى بكتير من البريد.
اسأل: الربط بواجهة واتساب الرسمية (Business API) ولا بأداة غير رسمية؟ الفرق مهم لأن غير الرسمي معرّض للحظر. وفيه دليل منفصل عن ربط المتاجر بواتساب API بيشرح الفرق ده بالتفصيل.
مع بوابات الدفع
اسأل: البوابات المدعومة إيه؟ والتحصيل بيتسجّل تلقائي على الفاتورة ولا بالإيد؟ والاسترداد بيتم من النظام ولا من لوحة البوابة؟
وجود API
حتى لو مش محتاج تكامل دلوقتي، وجود واجهة برمجية بيعني إنك تقدر تربط لاحقاً من غير ما تستنى المزوّد. غيابها بيعني إن أي ربط مستقبلي هيبقى مشروع تخصيص.
الدعم وما بعد البيع
الجزء اللي بيحدّد تجربتك على المدى الطويل، وأقل جزء بيتسأل عنه قبل الشراء.
أسئلة محدّدة
- وقت الاستجابة — مكتوب في العقد ولا وعد شفهي؟ وإيه الفرق بين مشكلة توقّف البيع ومشكلة عادية؟
- ساعات الدعم — لو بتبيع للساعة ١٢ بالليل والدعم بينتهي ٥، ده فارق مهم.
- قنوات التواصل — تليفون ولا تذاكر بس؟
- الوصول عن بُعد — بيحتاج إذنك كل مرة ولا مفتوح؟ ده سؤال أمني.
- التحديثات — مشمولة ولا بمقابل؟ وبتتنزّل تلقائي في وقت العمل؟
علامة مهمة
اطلب تتكلم مع عميل حالي في نفس مجالك وبنفس الحجم تقريباً. المزوّد الواثق بيرشّح واحد بسهولة. التردد هنا مؤشر بذاته.
الخروج
ناقش سيناريو إنك تسيب النظام قبل ما تدخله. بياناتك بتطلع بأي صيغة؟ وفي خلال كام يوم؟ ومين مالك البيانات في العقد؟ الاتفاق على ده وإنت داخل أسهل بمراحل من الاتفاق عليه وإنت خارج.
يوم كامل في محل: إزاي النظام بيتصرّف
الجزء النظري خلص. دلوقتي نمشي على يوم عمل عادي ونشوف كل قرار من اللي فوق بيظهر فين.
٩ صباحاً — فتح الوردية
الكاشير بيسجّل دخوله وبيدخل رصيد الدرج الافتتاحي. الرقم ده مش شكليات — هو نقطة البداية اللي هيتقارن بيها قفل الوردية آخر اليوم. النظام اللي مافيهوش فتح وردية، قفل الوردية فيه بلا معنى لأن مافيش نقطة مرجعية.
١٠:١٥ — بيعة عادية
زبون بثلاث أصناف. الكاشير بيمسح، السلة بتتكوّن، الإجمالي بيتحسب مع الضريبة لكل بند حسب نسبته. الزبون بيدفع نقدي ٢٠٠ والمستحق ١٨٣. النظام بيسجّل تحصيل ١٨٣ ويعرض الباقي ١٧ — مش بيسجّل ٢٠٠. الفاتورة بتاخد رقمها دلوقتي عند الإصدار، والمخزون بيتخصم تلقائي بمتوسط التكلفة المتحرك.
١١:٤٠ — الكهربا قطعت
في نص عملية بأربع أصناف. الجهاز بيقفل. بعد ١٠ دقايق النور رجع، الكاشير بيفتح النظام — السلة موجودة بنفس البنود لأنها محفوظة في قاعدة البيانات مش في جلسة المتصفح. الزبون كان مستني بس مش هيبدأ من الأول.
في نظام بيحفظ السلة في الجلسة، الموقف ده معناه إعادة مسح كل حاجة والزبون بيتضايق — وده مش سيناريو نادر في محل بيشتغل ١٢ ساعة.
١٢:٣٠ — الزبون غيّر رأيه بعد الدفع
فاتورة اتصدرت واتحصّلت، والزبون عايز يرجّع صنف واحد. النظام مابيسمحش بتعديل الفاتورة. اللي بيحصل: تسجيل مرتجع كدفعة بالسالب مربوطة بالفاتورة الأصلية، والمخزون بيرجع للصنف.
النتيجة في السجلات: الفاتورة الأصلية زي ما هي بقيمتها، ومعاها حركة مرتجع بتاريخ ومسؤول. لو حد سأل بعد ٦ شهور «الفاتورة دي اتحصّل منها كام فعلاً؟» الإجابة موجودة كاملة. في نظام بيعدّل الفاتورة، الإجابة ضاعت.
٢ ظهراً — خصم استثنائي
عميل قديم والمدير وافق على خصم ١٥٪ بالتليفون. الكاشير صلاحيته للخصم لحد ٥٪ بس، فالنظام بيطلب موافقة مشرف. المشرف بيدخل بحسابه ويعتمد. العملية اتسجّلت في سجل المراجعة باسم المشرف والنسبة والسبب.
من غير حدود صلاحيات، الخصم ده كان هيعدّي بدون أثر — ولو اتكرر بيبقى تسريب مالي محدش واخد باله منه لحد ما يظهر في هامش الربح آخر الشهر.
٤ عصراً — صنف قرب يخلص
الرصيد نزل تحت حد إعادة الطلب، فالنظام بيطلّع تنبيه. المسؤول بيعمل طلب شراء قبل ما الصنف يخلص فعلاً. الحاجة البسيطة دي بتمنع خسارة مبيعات محدش بيحسبها لأنها مش بتظهر في أي تقرير — الزبون بيسأل، الصنف مش موجود، الزبون بيمشي.
٦ مساءً — تغيير قائمة الأسعار
الإدارة رفعت أسعار مجموعة أصناف. الفواتير اللي اتصدرت الصبح مابتتغيّرش لأن كل بند محتفظ بسعره وضريبته وقت الإصدار. لو النظام بيقرا السعر من جدول الأصناف وقت العرض، كل فواتير النهاردة كانت هتبان بأسعار جديدة والعميل دفع القديمة — فرق بيظهر في التسوية ومحدش يعرف مصدره.
١١ مساءً — قفل الوردية
النظام بيطلّع: عدد العمليات، إجمالي المبيعات، تفصيل طرق الدفع، والنقدي المفروض في الدرج. الكاشير بيعدّ الفعلي ويدخله. الفرق (لو فيه) بيتسجّل باسم الموظف والوردية.
الرقم ده لوحده على مدى شهر بيقول حاجات كتير: فرق عشوائي صغير طبيعي، وفرق متكرّر مع موظف معيّن مؤشر يستاهل نظرة.
اللي اليوم ده أثبته
مافيش خطوة من اللي فوق فيها ميزة «مبهرة». كلها قرارات تصميم أساسية بتشتغل في الخلفية. والنظام اللي مبني صح مش بتحس بيه — بتحس بالنظام اللي مبني غلط، لما تقف قدام زبون وتقوله «استنى، الجهاز عمل مشكلة».
الخلاصة
نظام الفوترة ونقاط البيع مش شاشة جميلة — هو مجموعة قرارات عن إزاي بتتعامل مع الحالات اللي بتغلط فيها. الترقيم، والتعديل بعد الإصدار، والمرتجع، والانقطاع في نص العملية.
لو النظام اللي بتقيّمه بيتعامل مع الأربع دول صح، الباقي تفاصيل تتحل. ولو بيتعامل معاهم غلط، مافيش مميزات هتعوّض — لأن المشكلة هتظهر في المراجعة أو في الخزنة، والوقتين متأخرين.
وقبل أي حاجة: اعرف إنت محتاج فوترة ولا محاسبة. الإجابة دي لوحدها بتوفّر عليك نص المشوار.