مدار | Madar Business Management

هيكل تطوير أولي لإعادة بناء SM Elite SQL باستخدام Rust + Tauri + SQLite.

القرارات المعتمدة

• اسم المنتج: مدار
• جهاز محلي واحد، دون مزامنة بين الأجهزة
• قاعدة بيانات SQLite محلية
• نسخ احتياطي واستعادة محليان مع نقاط استعادة تلقائية
• واجهة عربية RTL
• كل صنف له باركود أساسي فريد؛ يحافظ البرنامج على الباركود المقدم أو يولد باركودًا داخليًا إذا كان الحقل فارغًا
• دعم باركودات متعددة للصنف حسب الوحدة/العبوة في نموذج البيانات

باركود مدار

الصيغة الداخلية الحالية MAD متبوعة بعشرة أرقام، مثل MAD0000000001. هي قيمة فريدة داخل قاعدة بيانات مدار ومناسبة للطباعة بصيغة Code 128. ليست GTIN/EAN عالميًا ولا ينبغي اعتبارها باركود بيع عالميًا مسجلًا. تبقى أرقام الباركود القديمة نصوصًا للحفاظ على الأصفار في البداية.

تشغيل المشروع

يلزم تثبيت Rust وNode.js ومتطلبات Tauri للنظام من الدليل الرسمي: https://tauri.app/start/ ثم استكمال إعداد حزمة الواجهة وأوامر Tauri حسب نظام التشغيل. لم يتم بناء ملف تثبيت نهائي أو اختبار تجميع Rust في هذه البيئة لعدم توفر Cargo.

تنبيه بخصوص قاعدة البيانات الأصلية

database/schema.sql هو مخطط تطوير أولي، وليس تحويلًا كاملًا لقاعدة SQL Server الأصلية. يحتوي المصدر الأصلي على جدول Product وجدول Barcodes منفصل وبيانات وحدات متعددة؛ لذلك يلزم تحليل العلاقات والبيانات وتحديد قواعد ترحيلها قبل الاستيراد. لا تُستخدم النسخة الحالية للإنتاج أو كبديل عن البرنامج القديم حتى اكتمال الاختبارات.

النسخ الاحتياطي والاستعادة

أضيفت واجهة لاختيار مكان النسخة الاحتياطية وحفظها عبر SQLite Backup API، ثم التحقق منها باستخدام PRAGMA quick_check. يمكن اختيار ملف نسخة خارجي لاستعادته؛ يطلب التطبيق تأكيدًا صريحًا، ويتحقق من سلامة الملف ووجود جدول products قبل الاستعادة. قبل استبدال قاعدة البيانات الحالية، يحفظها باسم Madar.before-restore.<timestamp>.db في مجلد بيانات التطبيق. تعرض واجهة نقاط الاستعادة المحفوظة داخل مدار هذه النسخ التلقائية مرتبة من الأحدث إلى الأقدم، وتسمح باستعادة أي منها مباشرة دون أن يضطر المستخدم للبحث عن ملفها يدويًا. بعد كل استعادة ناجحة، تُحدّث القائمة وتظهر نقطة الأمان الجديدة التي تم إنشاؤها قبل الاستعادة. لا تحذف ملفات الأمان يدويًا إلا بعد التأكد من سلامة البيانات المستعادة.

يتطلب التعديل الإضافة tauri-plugin-dialog، وسيقوم Cargo بتنزيلها عند البناء لأول مرة إذا لم تكن مخزنة محليًا.

اختبار التعديلات على Fedora

من مجلد src-tauri شغّل:

cargo check
cargo run

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

صلاحيات نوافذ اختيار الملفات

يحتوي src-tauri/capabilities/default.json على صلاحيات نافذتي فتح الملفات وحفظها المستخدمتين في النسخ الاحتياطي والاستعادة (dialog:allow-open وdialog:allow-save).

إدارة المنتجات (الإصدار الحالي)

• البحث بالاسم أو كود الصنف أو أي باركود مرتبط بالصنف، بما في ذلك الباركودات البديلة. حقل البحث يقبل إدخال قارئ USB الذي يعمل كلوحة مفاتيح، ويحفظ الباركود كنص للحفاظ على الأصفار في البداية.
• تعديل الكود والاسم والوحدة وسعري الشراء والبيع. لا يغيّر التعديل الباركود الأساسي، ويتم تسجيل التعديلات في audit_log.
• إضافة باركود بديل، مع رفض الباركود الفارغ أو المكرر. يمكن ربط أكثر من باركود بالصنف.
• إيقاف الصنف (حذف منطقي) بعد نافذة تأكيد داخل التطبيق؛ لا يتغير شيء عند اختيار «إلغاء». بعد التأكيد ينتقل التطبيق تلقائيًا إلى قائمة الأصناف الموقوفة لعرض الصنف هناك.
• قائمة منفصلة للأصناف الموقوفة تدعم البحث بالاسم والكود والباركود، وزر «إعادة تفعيل» يعيد الصنف إلى القائمة النشطة بعد التأكيد، دون حذف بياناته أو باركوداته. يسجل الإيقاف وإعادة التفعيل في audit_log ضمن معاملات قاعدة بيانات.
• عند تعديل الوحدة، تتحدث وحدة الباركود الأساسي؛ قيمة الباركود نفسها تظل كما هي.

اختبار يدوي بعد تشغيل التطبيق

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

تم اختبار منطق أوامر SQLite المكافئ في بيئة اختبار مؤقتة، بما في ذلك الإغلاق وإعادة الفتح والحفاظ على الباركود. يلزم تشغيل cargo tauri dev على جهاز التطوير للتحقق النهائي من تكامل Rust/Tauri في بيئة المستخدم.

تحديث واجهة المنتجات

• نموذج إضافة الصنف يفتح الآن في نافذة فرعية، مثل نموذج تعديل الصنف، بدل ظهوره دائمًا في الصفحة.
• إضافة الباركود البديل تتم من نافذة داخل التطبيق بدل نافذة window.prompt التي كانت تعرض عنوان بيئة التطوير (127.0.0.1:1430) بشكل مربك.
• يمكن إضافة عدة باركودات بديلة واحدًا تلو الآخر، مع بقاء الباركود الأساسي دون تغيير.

المخزون وحركات الوارد والمنصرف

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

اختبار يدوي للمخزون

1. افتح شاشة «المخزون»، اختر صنفًا نشطًا وسجل واردًا بكمية 10.
2. تأكد أن الرصيد أصبح 10 وأن سجل الحركات يعرض واردًا بكمية موجبة.
3. سجّل منصرفًا بكمية 3.5؛ يجب أن يصبح الرصيد 6.5.
4. حاول صرف 7؛ يجب رفض الحركة وألا يتغير الرصيد أو سجل الحركات.
5. أعد تشغيل مدار وتأكد أن الرصيد وسجل الحركات لا يزالان محفوظين.
6. ابحث عن الصنف بالاسم والكود والباركود، واختبر قارئ الباركود في حقل المسح مع الضغط على Enter.

المستخدمون والصلاحيات وسجل النشاط (الإصدار 0.3.0)

• عند فتح قاعدة بيانات قديمة لأول مرة بعد هذا التحديث، ستظهر شاشة إعداد لإنشاء أول حساب «مدير النظام»؛ لا توجد كلمة مرور افتراضية. اسم المستخدم من 3 إلى 40 حرفًا/رقمًا بالإنجليزية مع ., _, -، وكلمة المرور لا تقل عن 12 حرفًا.
• كلمات المرور تُخزّن باستخدام Argon2 مع salt عشوائي، ولا تُحفظ كنص صريح. الجلسة محفوظة في حالة التطبيق داخل الذاكرة، ويجب تسجيل الدخول مجددًا بعد إغلاق التطبيق وإعادة فتحه.
• الأدوار المبدئية: مدير النظام (كل الصلاحيات)، مدير (المنتجات والمخزون والنسخ وسجل النشاط)، مسؤول مخزن (عرض المنتجات وإدارة حركات المخزون)، مبيعات (عرض المنتجات والمخزون فقط حتى إضافة شاشة المبيعات)، وعرض فقط (قراءة دون تعديل). يمكن لمدير النظام تغيير دور الحساب أو إيقافه أو إعادة تفعيله وإعادة تعيين كلمة مروره.
• الأوامر الحساسة تتحقق من الصلاحيات داخل Rust، وليس فقط عبر إخفاء الأزرار في الواجهة. من الصلاحيات الحالية: عرض/إدارة المنتجات، عرض/إدارة المخزون، النسخ والاستعادة، إدارة المستخدمين، وعرض سجل النشاط.
• يسجل audit_log عمليات إنشاء/تعديل/إيقاف الأصناف، الباركود البديل، حركات المخزون، تسجيل الدخول الناجح والفاشل والخروج، إدارة المستخدمين وتغيير كلمات المرور، إنشاء النسخ، حذف نقاط الاستعادة والاستعادة. يحتوي السجل على اسم المستخدم والوقت ونوع العملية والتفاصيل. واجهة السجل للقراءة فقط.
• عند استعادة نسخة بيانات، يحتفظ مدار بحسابات المستخدمين والأدوار وسجل التدقيق الحالي بدل استرجاع نسخة أقدم من إعدادات الوصول؛ وبعد الاستعادة يطلب تسجيل الدخول مرة أخرى.
• هذه حماية على مستوى التطبيق المحلي؛ يجب أيضًا حماية حساب Linux ومجلد بيانات مدار وملفات النسخ الاحتياطية من الوصول غير المصرّح به من نظام التشغيل.

اختبار يدوي لطبقة الوصول

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

حدود النسخة الحالية: محرر الصلاحيات يخصص صلاحيات كل مستخدم منفردًا، بينما أدوار النظام نفسها تظل قوالب ثابتة يمكن اختيار أحدها للحساب. يلزم اختبار بناء Rust/Tauri على جهاز التطوير قبل الاعتماد عليها.

محرر الصلاحيات التفصيلي

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

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

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

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

بيانات المستخدمين واللغات وسجل التدقيق

• شاشة المستخدمون تعرض الحسابات، ويُفتح زر إضافة مستخدم نموذجًا عائمًا مستقلًا. يتيح مربع تفاصيل المستخدم عرض وتحرير الاسم الظاهر والبريد الإلكتروني ورقم الهاتف والعنوان والصورة، مع إدارة الدور وحالة الحساب وإعادة تعيين كلمة المرور حسب صلاحيات الفاعل.
• الصورة اختيارية؛ عند عدم رفع صورة أو اختيار «استخدام الصورة الافتراضية» يظهر رمز مستخدم افتراضي مدمج في الواجهة. الصور المدخلة تُصغّر محليًا إلى صورة مربعة 256×256 ثم تُحفظ في قاعدة SQLite كبيانات صورة؛ الصيغ المدعومة JPG وPNG وWebP.
• تظل صلاحيات الوصول مفروضة في أوامر Rust. التعديل الشخصي يحتاج users.profile.edit، وإيقاف/تفعيل الحساب users.status.manage، وتغيير الدور users.role.manage، وإعادة تعيين كلمة المرور users.password.reset.
• رسائل النجاح تظهر باللون الأخضر ورسائل الأخطاء باللون الأحمر، مع دعم ألوان متناسبة مع الوضع الفاتح والداكن.
• يمكن التبديل بين العربية والإنجليزية من الشريط العلوي، وكذلك من شاشة الإعداد أو تسجيل الدخول. يُحفظ اختيار اللغة محليًا على الجهاز ويُضبط اتجاه الصفحة RTL للعربية وLTR للإنجليزية. بعض رسائل الأخطاء المفصلة التي يصدرها SQLite أو Rust قد تبقى جزئيًا بالعربية إذا لم يكن لها نص ترجمة محدد.
• يحتوي سجل النشاط على مرشحات مستقلة للبحث النصي، ونوع السجل، والعملية. تمت إضافة «مخزون» كنوع مستقل لحركات الوارد والمنصرف، مع استمرار ظهور سجلات الحركات القديمة تحت نوع المخزون عند استخدام هذا المرشح. زر مسح المرشحات يعيد البحث والنوع والعملية إلى الوضع الافتراضي.
• تم تنظيف التحذيرات المحددة سابقًا المتعلقة بمتغيرات mut غير اللازمة وactor غير المستخدم؛ عند ظهور تحذيرات جديدة بعد البناء، تُراجع بحسب مخرجات Cargo في جهاز التطوير.

اختبار يدوي لملف المستخدم وسجل النشاط

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

العملاء والموردون والمشتريات والمبيعات

• يمكن إضافة العملاء والموردين وتعديل بيانات الاتصال والعنوان والملاحظات وإيقاف السجل أو إعادة تفعيله دون حذف الفواتير المرتبطة.
• فواتير الشراء والبيع تنشأ كمسودات، ويمكن تعديل المسودة قبل اعتمادها.
• اعتماد فاتورة المشتريات يزيد المخزون، واعتماد فاتورة المبيعات يخصم الكميات بعد التحقق من الرصيد. يتم تحديث حالة الفاتورة وحركات المخزون وسجل النشاط ضمن معاملة SQLite واحدة.
• إلغاء فاتورة معتمدة ينشئ حركات عكسية موثقة؛ وقد يرفض النظام إلغاء فاتورة شراء إذا كان المخزون الحالي لا يكفي لعكس الكميات. لا يتم حذف سجل الفاتورة.
• يمكن إدخال الصنف بالاختيار من القائمة أو مسح الباركود داخل نافذة الفاتورة. وتظل القيم المالية محفوظة بوحدات العملة الصغرى، والكميات حتى ثلاث خانات عشرية.
• الصلاحيات الجديدة: customers., suppliers., purchases.* و sales.*، مع فصل صلاحية تجاوز سعر البيع.

قبل الاعتماد الفعلي، اختبر دورة كاملة (شراء واعتماد ثم بيع واعتماد ثم إلغاء) على قاعدة اختبار واحتفظ بنسخة احتياطية من قاعدة البيانات الحقيقية.

إدخال الفاتورة بقارئ الباركود

في نافذة فاتورة المشتريات أو المبيعات، انقر حقل «مسح باركود الصنف» وامسح الباركود. عند إرسال القارئ Enter، يبحث مدار عن الباركود الأساسي أو البديل ويضيف الصنف؛ وإذا كان الصنف موجودًا في الفاتورة يزيد الكمية وحدة واحدة. يتم تركيز المؤشر على حقل المسح مرة أخرى بعد كل عملية.

المراحل التشغيلية الأولى (العملاء والموردون والمشتريات والمبيعات)

تشمل النسخة شاشة العملاء والموردين، وفواتير مشتريات ومبيعات بمراحل المسودة والتعديل والاعتماد والإلغاء، ومسح باركود داخل محرر الفاتورة، وتحديث المخزون وسجل التدقيق ضمن معاملة واحدة عند الاعتماد. راجع docs/PHASES-1-3-ACCEPTANCE.md لقائمة اختبار يدوية كاملة قبل الاعتماد على بيانات فعلية.

أضيفت إدارة المدفوعات والخزنة والتقارير، وطباعة A4 لفواتير المشتريات والمبيعات وعروض الأسعار، وإعدادات بيانات الشركة. لا يتضمن الإصدار الحالي حساب ضرائب تلقائيًا أو مستندات مرتجعات مستقلة؛ كما أنه ليس استيرادًا مكتملًا لقاعدة SM Elite SQL الأصلية.

المرحلة التجارية الإضافية (v0.4)

• بيانات الشركة (الاسم، الهاتف، البريد، العنوان، الرقم الضريبي والسجل التجاري، الموقع، الشعار والتذييل) تُستخدم في المطبوعات.
• طباعة فواتير المشتريات والمبيعات وعروض الأسعار من خلال نافذة طباعة A4؛ ويمكن اختيار الطابعة أو الحفظ PDF من حوار النظام.
• عروض الأسعار لها دورة حالة مستقلة ولا تؤثر على المخزون، والعرض المقبول يمكن تحويله إلى مسودة فاتورة مبيعات.
• تسجيل دفعات جزئية للمبيعات والمشتريات، وسجل خزنة نقدية للحركات النقدية فقط، وتسويات محكومة بالرصيد.
• تقارير المبيعات والمشتريات والتحصيلات والمدفوعات والأرصدة المستحقة والربح الإجمالي للأصناف ذات تكلفة شراء محفوظة.
• إلغاء الفواتير التي عليها دفعات محظور لحماية الحسابات؛ يلزم إضافة عملية رد/عكس مالي موثقة قبل الإلغاء.
• الضرائب غير محسوبة تلقائيًا في هذه النسخة؛ الرقم الضريبي يُطبع إذا تم إدخاله. يلزم تحديد قواعد الضريبة/الإعفاء والأسعار شاملة أم غير شاملة قبل اعتماد الفواتير ضريبيًا.

المراحل التجارية الإضافية: عروض الأسعار والطباعة والمالية

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

اختبار القبول المقترح للدورة التجارية

1. أدخل بيانات الشركة والشعار والعملة، ثم اطبع فاتورة معاينة وتأكد من ظهور البيانات على ورق A4 أو في PDF.
2. أنشئ موردًا وفاتورة مشتريات من صنف موجود، واحفظها كمسودة؛ تحقق أن المخزون لم يتغير. اعتمدها وتأكد من زيادة المخزون وظهور الحركة وسجل التدقيق.
3. أنشئ فاتورة مبيعات، جرّب كمية تتجاوز الرصيد وتأكد من رفض الاعتماد. ثم اعتمد فاتورة بكمية متاحة واطبعها.
4. سجّل دفعة جزئية نقدية، وتأكد من تغير المتبقي في التقرير والفاتورة المطبوعة وزيادة رصيد الخزنة. جرّب مبلغًا أكبر من المتبقي، وتأكد من رفضه.
5. أنشئ عرض سعر واطبعه، ثم اقبل العرض وحوّله لمسودة بيع. تأكد أن التحويل لا يغيّر المخزون حتى اعتماد فاتورة البيع.
6. شغّل cargo check على Fedora، ثم اختبر كل ذلك بقاعدة اختبار قبل استعماله على البيانات الحقيقية.

Company tax settings and permissions

• Configure the VAT/tax rate from Company Settings (0–100%, two decimal places).
• Choose whether entered item prices include tax or tax is added to the discounted subtotal.
• Each saved invoice/quotation stores a tax-rate and tax-mode snapshot; existing saved documents are not retroactively recalculated when company settings change. Editing a draft recalculates it using the current settings.
• Viewing company settings requires company.settings.view or company.settings.manage; changing settings requires company.settings.manage. The Rust commands enforce these checks independently of UI visibility.
• Invoice/quotation printing loads the company profile through a separate command that checks the relevant sales.view, purchases.view, or quotations.view permission.

الإصدار 0.1.2

هذا رقم إصدار التطوير الحالي، ويُضبط في src-tauri/Cargo.toml وsrc-tauri/tauri.conf.json. يعرض أمر معلومات التطبيق رقم الحزمة المأخوذ من CARGO_PKG_VERSION؛ لذلك يجب إبقاء الرقمين متطابقين عند إصدار نسخة جديدة. نُقلت بطاقة حالة النظام من لوحة التحكم إلى أول قسم في صفحة المساعدة.

خطة الاختبار قبل الاستخدام الفعلي

نفّذ الاختبارات التالية على قاعدة بيانات تجريبية منفصلة، ولا تستخدم قاعدة العمل الحقيقية للاختبارات التي تغيّر البيانات أو تستعيدها. سجّل النتيجة (ناجح/فاشل) وأي رسالة خطأ.

1. فحص البناء والتشغيل

من جذر المشروع:

cd src-tauri
cargo check
cargo tauri dev

• يكتمل cargo check دون أخطاء. راجع التحذيرات بدل تجاهلها.
• يفتح التطبيق وتظهر صفحة تسجيل الدخول/الإعداد الأولي بصورة سليمة.
• رقم الإصدار المعروض في معلومات التطبيق هو 0.1.2.
• جرّب تبديل العربية والإنجليزية، واتجاه RTL/LTR، والوضع الداكن إن كان مفعّلًا.
• افتح صفحة المساعدة وتأكد أن حالة النظام هي أول بطاقة بعد عنوان الصفحة، وأنها لم تعد تظهر كبطاقة مستقلة في لوحة التحكم.

2. الدخول والصلاحيات

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

3. المنتجات والباركود

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

4. المخزون

• سجّل واردًا بكمية 10 وتأكد أن الرصيد زاد إلى 10.
• سجّل منصرفًا بكمية 3.5 وتأكد أن الرصيد أصبح 6.5.
• حاول صرف 7؛ يجب رفض الحركة دون تغيير الرصيد أو سجل الحركات.
• أعد تشغيل التطبيق وتأكد من بقاء الرصيد والحركات.
• تحقق من منع الحركة لصنف موقوف ومن منع تغيير وحدة صنف له رصيد قائم.

5. المشتريات والمبيعات وعروض الأسعار

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

6. المدفوعات والتقارير والطباعة

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

7. النسخ الاحتياطي والاستعادة

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

PRAGMA quick_check;
PRAGMA foreign_key_check;

8. تسجيل النتائج

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