حمزة احساين
تواصل

Tahanot

نظام ERP مصغر، مساعده لا يدخل إلا من الباب الأمامي

نظام Tahanot هو ERP مصغر ذاتي الاستضافة، مستوحى من أفكار Odoo ومعاد بناؤه من الصفر: المبيعات والمشتريات والمخزون والفوترة ولوحة متابعة لنشاط تجاري صغير متعدد الشركات. ومساعده الذكي يجيب عن الأسئلة المتعلقة بالنشاط باستدعاء الخدمات نفسها، وبفحوص الصلاحيات نفسها، التي يمر بها باقي التطبيق. ولا يكتب SQL أبدًا.

النوع
مشروع شخصي، 2026، من تصميمي وتنفيذي بالكامل
الوحدات
المبيعات، المشتريات، المخزون مع الطلبات المؤجلة، الفوترة والمدفوعات، لوحة المتابعة
المساعد
حلقة أدوات مكتوبة يدويًّا، 10 أدوات محددة الأنواع، 8 جولات على الأكثر
البيانات
قاعدة PostgreSQL 16 مع SQLAlchemy 2 وترحيلات Alembic
الاختبارات
220 دالة اختبار للواجهة الخلفية و26 للواجهة الأمامية

نسخة أولية تعمل، الإصدار 0.1. المشتريات والإشعارات الدائنة والواجهة الفرنسية موجودة في فرع تطوير لم يدمج بعد.

سؤال واحد إلى المساعد

المساعد نموذج واحد في حلقة مع أدوات محددة الأنواع. وكل ما يستطيع رؤيته يمر عبر طبقة الخدمات نفسها وفحوص الوصول نفسها التي تمر بها REST API، فلا يمكنه أن يعرف أكثر مما يعرفه السائل.

سؤال واحد عن المخزون، من اللوحة الجانبية إلى الإجابة
المستخدم يسأل في اللوحة الجانبية المصادقة والسياق JWT، الشركة، الحقوق حد المعدل 10 في الدقيقة النموذج أي API متوافقة أدوات محددة النوع يتحقق منها Pydantic طبقة الخدمات PostgreSQL، نفس الحقوق كتل النتائج جداول، رسوم، مؤشرات الإجابة نص + مكونات المستخدم يسأل في اللوحة الجانبية المصادقة والسياق JWT، الشركة، الحقوق حد المعدل 10 في الدقيقة النموذج أي API متوافقة أدوات محددة النوع يتحقق منها Pydantic طبقة الخدمات PostgreSQL، نفس الحقوق كتل النتائج جداول، رسوم، مؤشرات الإجابة نص + مكونات
  • إدخال أو إخراج
  • استدعاء LLM
  • شيفرة
  • مخزن بيانات
  • فحص أو بوابة
  1. المستخدم «كم وحدة بقيت من SKU-102 في المستودع 1؟» وفي صفحة سجل ما، ترسل اللوحة أيضًا السجل المعروض.
  2. المصادقة والسياق يحدد JWT وترويسة الشركة هوية المستخدم، والشركات التي يحق له رؤيتها، ومجموعاته، وحقوقه على كل نموذج بيانات. وطلب شركة لا يحق له رؤيتها يقابل بالخطأ 403.
  3. حد المعدل 10 رسائل لكل مستخدم في الدقيقة. يجري تحميل المحادثة أو إنشاؤها، ثم حفظ الرسالة.
  4. النموذج موجِّه النظام (system prompt) يعاد بناؤه مع كل طلب: التاريخ، المستخدم، المستودعات، العملة، قواعد الالتزام بالبيانات، وفهرس حقول يولد من سجل نماذج البيانات الحي. فيطلب النموذج get_stock(sku="SKU-102", warehouse_id=1).
  5. أدوات محددة النوع يتحقق Pydantic من الوسائط، ثم تستدعي الأداة خدمة المخزون بحقوق المستخدم نفسه. وحقول التكلفة تعود بقيمة «restricted» للمستخدمين الذين لا يملكون حق الوصول.
  6. النموذج تعود النتيجة محاطة بسياج يعلن أنها بيانات غير موثوقة، لا تعليمات أبدًا. لا استدعاءات أخرى للأدوات، فيجيب.
  7. كتل النتائج مخرجات الأدوات تتحول إلى مكونات واجهة حقيقية: بطاقة مخزون هنا؛ وفي حالات أخرى جداول تحيل إلى السجلات، ورسوم أعمدة، وبطاقات مؤشرات أداء (KPI) يمكن تثبيتها في لوحة المتابعة.
  8. الإجابة الرقم كما ورد في نتيجة الأداة، معروضًا بجانب النص الذي يشرحه.

مسارات أخرى في المخطط

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

نظام ERP في الأساس

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

  • سجل عام لنماذج البيانات

    وحدة توجيه CRUD واحدة مع مرشحات النطاق (domain filters) تخدم كل النماذج؛ أما إجراءات العمل، كتأكيد طلب أو اعتماد تسليم، فلها مسارات خاصة بها.

  • المستندات آلات حالات

    عروض الأسعار والطلبات وعمليات التسليم تنتقل عبر حالات صريحة.

  • مخزون قائم على الكميات (quants)

    يمسك المخزون في صورة كميات لكل منتج وموقع، مع متغيرات المنتجات، وطلبات مؤجلة حين لا ينجز التسليم إلا جزئيًّا.

  • الفواتير والمدفوعات

    مدفوعات الفواتير والإشعارات الدائنة، مع اختبارات للتزامن والأقفال تعمل على PostgreSQL.

  • عملية تجميع أساسية واحدة

    الدالة read_group تغذي لوحة المتابعة والعروض المحورية والمساعد على حد سواء.

  • شركتان، ولغتان

    تعدد الشركات مدمج ابتداء من نموذج البيانات، مع واجهة إنجليزية وأخرى فرنسية قيد الإنجاز.

خيارات هندسية

  • النموذج لا يكتب SQL أبدًا

    يستدعي أدوات محددة الأنواع يجري التحقق من مدخلاتها، ومبنية على الخدمات نفسها وفحوص الصلاحيات نفسها التي تعتمدها REST API.

  • غير مرتبط بمزود بعينه

    الرسائل تستخدم صيغة محايدة، ونقطة الوصول الافتراضية متوافقة مع OpenAI، فالانتقال إلى Claude أو إلى خادم محلي مجرد تغيير في الإعدادات.

  • نماذج بيانات في قائمة سماح، وحقول مخفية

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

  • غير موثوق افتراضيًّا

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

  • الكتابة تحتاج إلى خطوة ثانية

    عملية الكتابة تعيد أولًا مقترحًا ورمزًا موقعًا على حمولته؛ وأي حمولة معدلة ترفض.

  • إجابات في صورة مكونات

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

التقنيات

الواجهة الخلفية
Python 3.12، FastAPI، SQLAlchemy 2، Alembic، Pydantic، PyJWT، Server-Sent Events
البيانات
PostgreSQL 16
الذكاء الاصطناعي
حلقة أدوات مكتوبة يدويًّا، حزمتا SDK من Anthropic و OpenAI
الواجهة الأمامية
React 18، TypeScript، TanStack Query و Table، Recharts، Tailwind CSS 4، Vite
البنية التحتية
Docker Compose، nginx
الجودة
pytest، Vitest، Testing Library

هل تبني شيئًا مشابهًا؟

يسعدني أن أشرح التصميم والمفاضلات، أو ما سأغيّره في الخطوة التالية.

راسلني كل المشاريع