مقدمة
في أودو، تُحدَّد البُنى التي يخزن فيها النظام بيانات الأعمال عن طريق النماذج. كل عنصر بيانات تجاري تتعامل معه—من عروض الأسعار إلى الفواتير إلى جهات الاتصال—موجود داخل نموذج منظّم في قاعدة البيانات.
فهم النماذج في أودو أمر ضروري سواء كنت مطوّراً تكتب أكواد أو مستشارًا وظيفيًا يضبط النظام بحسب العمليات. النماذج تشكّل العمود الفقري لهندسة البيانات: تحدد الحقول، وترابط السجلات، والمنطق التجاري.
سيركّز هذا الدليل على واحد من أهم نماذج أودو: res.partner. سواء كنت تطوّر إضافات، توصل نظام خارجي، أو تضبط سير عمل للمبيعات والمشتريات—ستلتقي مع هذا النموذج كثيرًا.
ما هو نموذج res.partner
يمثل نموذج res.partner في أودو كل طرف تجاري: زبائن، موردين، جهات اتصال داخل شركات، أو حتى شركات كاملة. هو المكان المركزي الذي تُخزّن فيه كل بيانات الأطراف.
يُستخدم هذا النموذج عبر معظم تطبيقات أودو: المبيعات، إدارة العملاء (CRM)، المحاسبة، المشتريات، والمتاجر الإلكترونية كلها تعتمد عليه. إنشاء زبون أو مورد يعني إنشاء أو ربط بسجل res.partner.
النموذج مُعرَّف ضمن الوحدة الأساسية (base)، والوحدات الأخرى توسّع عليه عبر وراثة النماذج. على سبيل المثال، CRM يضيف حقول تتعلق بالفرص، والمحاسبة تضيف شروط دفع وحدود ائتمان—كل وحدة تضيف ما تحتاجه دون تكرار الهيكل الأساسي.
حقول رئيسية في النموذج
فيما يلي أهم الحقول في نموذج res.partner التي يجب أن تعرفها لتتعامل بكفاءة مع جهات الاتصال والشركاء داخل أودو.
1. الاسم (name)
نوع: نص قصير (Char). يحمل اسم السجل: اسم الشركة أو اسم الشخص الكامل. يظهر في قوائم وأشكال أودو ويُعتبر المعرّف الرئيسي للشريك.
2. تاريخ الإنشاء (create_date)
نوع: توقيت (Datetime). يخزن الوقت الذي تم فيه إنشاء السجل. يُدار تلقائيًا ومفيد للتقارير والتدقيق.
3. تاريخ التعديل (write_date)
نوع: توقيت (Datetime). يعكس آخر تعديل على السجل. مُدار تلقائيًا ويساعد في معرفة تواريخ تحديث البيانات.
4. البريد الإلكتروني (email)
نوع: نص (Char). عنوان البريد الأساسي للتواصل وإرسال الفواتير والوصول إلى البوابة. أودو يتحقّق من صحة الشكل حيث أمكن.
5. الهاتف (phone)
نوع: نص (Char). رقم الهاتف الرئيسي للجهة. يُعرض في استمارات التواصل ويُستخدم في إجراءات الاتصال.
6. الجوال (mobile)
نوع: نص (Char). رقم الهاتف المحمول، يُستخدم عادة للإشعارات العاجلة أو الرسائل القصيرة إذا اختلف عن الهاتف الرئيسي.
7. الشارع الأول (street)
نوع: نص (Char). سطر العنوان الأول، جزء من قالب العناوين القياسي المستخدم في المستندات.
8. الشارع الثاني (street2)
نوع: نص (Char). سطر إضافي للعنوان—مثل رقم الشقة أو اسم البناء أو تفاصيل إضافية.
9. المدينة (city)
نوع: نص (Char). اسم المدينة أو البلدة؛ صياغة العنوان قد تختلف حسب البلد.
10. الرمز البريدي (zip)
نوع: نص (Char). رمز بريدي يستخدم للتحقق من العناوين وحسابات الشحن.
11. الولاية/المحافظة (state_id)
نوع: Many2one (res.country.state). يمثل الولاية أو المقاطعة، مع نطاق مقيد بحسب الدولة. ليست كل الدول تستخدم ولايات.
12. الدولة (country_id)
نوع: Many2one (res.country). تحدد البلد، وتؤثر على تنسيق العنوان، وضرائب المبيعات، وإعدادات التعريب.
13. هل هو شركة؟ (is_company)
نوع: منطقي (Boolean). يميّز بين سجل شركة أو شخص. للشركات يمكن أن تكون لها جهات اتصال فرعية؛ للأشخاص يمكن ربطهم بشركة عبر parent_id.
14. الشركة الأم/الجهة المرتبطة (parent_id)
نوع: Many2one (res.partner). يربط جهة الاتصال بشركة أم، مما يتيح هيكلية شركة-جهات اتصال ويجعل بعض الحقول تُورَّث من الشركة.
15. جهات الاتصال الفرعية (child_ids)
نوع: One2many (res.partner). عكس parent_id؛ قائمة جهات الاتصال التي تنتمي إلى شركة ما لتسهيل التنقّل من الشركة إلى أفرادها.
16. شركة أودو المعنية (company_id)
نوع: Many2one (res.company). في بيئات متعددة الشركات، يوضح أي شركة داخل أودو يمتلك هذا السجل ويؤثر على رؤية السجل وصلاحيته.
17. رقم التعريف الضريبي (vat)
نوع: نص (Char). رقم الضريبة أو VAT، مع تحقق بحسب صيغة البلد. مهم لحسابات الفواتير والامتثال الضريبي.
18. مرتبة العميل (customer_rank)
نوع: عدد صحيح (Integer). مؤشر يزداد عندما يقوم الشريك بعمليات بيع؛ يُستخدم لترتيب العملاء والتصفية.
19. مرتبة المورد (supplier_rank)
نوع: عدد صحيح (Integer). مؤشر يزداد عند وجود أوامر شراء أو فواتير للمورد؛ يساعد في تمييز البائعين.
20. المستخدم المسؤول (user_id)
نوع: Many2one (res.users). المندوب أو المستخدم المسؤول عن الشريك، ويُستخدم في تتبع المبيعات والمهام.
21. نوع العنوان (type)
نوع: اختيار (Selection). يحدد دور عنوان الاتصال الفرعي: اتصال عام، فاتورة، توصيل، أو آخر—ويؤثر أي عنوان يُستخدم في المستندات.
22. المرجع الداخلي (ref)
نوع: نص (Char). رمز داخلي أو مرجع يُستخدم للربط مع أنظمة خارجية أو لأرقام داخلية مخصصة.
23. الموقع الإلكتروني (website)
نوع: نص (Char). رابط الموقع الإلكتروني للجهة، يظهر في استمارات التواصل والمتجر الإلكتروني.
24. ملاحظات داخلية (comment)
نوع: HTML. ملاحظات مرئية للمستخدمين الداخليين—تُستخدم لتعليمات المبيعات أو ملاحظات خاصة بالسجل.
25. مفعل/مؤرشف (active)
نوع: منطقي (Boolean). علم الأرشفة: عند إيقافه يُخفى السجل من العروض الافتراضية لكنه لا يُحذف فعليًا من القاعدة.
26. اللغة (lang)
نوع: اختيار (Selection). اللغة المفضلة للتواصل؛ تُورّث من الشركة الأم عند وجودها وتؤثر على رسائل البريد والمستندات.
27. شعار/صورة (image_1920)
نوع: ثنائي (Binary). صورة الشريك أو شعار الشركة؛ تُستخدم في الاستمارات والتقارير والموقع.
28. فئات/وسوم (category_id)
نوع: Many2many (res.partner.category). تقسيم مرن لتصنيف الشركاء للتسويق أو التصفية أو التقارير.
كيف يُستخدم هذا النموذج في سير عمل الشركات
1. المبيعات وCRM
عند إعداد عرض سعر، يختار المندوب العميل من سجلات res.partner؛ نفس السجل يُستخدم لفرصة المبيعات والطلب. حقول مثل customer_rank وuser_id تؤثر على التبويب والتقارير.
2. المحاسبة والفواتير
الفواتير والمستندات المرجعية تستخدم بيانات الشريك لعنوان الفوترة، ويُستعمل حقل vat لحساب الضريبة؛ شروط الدفع وحدود الائتمان غالبًا ما تُخزن على مستوى الشريك.
3. المشتريات والموردون
أوامر الشراء والفواتير الخاصة بالموردين ترتبط بسجلات res.partner، وsupplier_rank يساعد على تمييز الموردين في النظام. يمكن تعيين مسؤول شراء لكل مورد.
4. المتجر الإلكتروني وبوابة العملاء
زوار الموقع عند التسجيل يتحولون إلى سجلات شريك تُستخدم لاحقًا في الطلبات والوصول للبوابة، وتُسحب عناوينهم من حقول res.partner.
5. بيئات متعددة الشركات والتجميع
في إعدادات متعدد الشركات قد توجد كيانات قانونية مكررة عبر شركات أودو مختلفة؛ company_id وقواعد الشركات المشتركة تحدد كيفية مشاركة أو عزْل البيانات بين شركات المؤسسة.
كيف يطوّر المطوّرون هذا النموذج
يمدّ المطوّرون نموذج res.partner بعدة طرق وفق احتياجات المشروع، وتُعد وراثة النماذج الآلية الأساسية للتمديد.
وراثة النموذج
باستخدام _inherit = 'res.partner' يمكنك إضافة حقول، تعديل طرق (methods)، أو فرض قيود جديدة. هذا يبقي تغييراتك في وحدة مستقلة ما يسهل الترقية لاحقًا.
إضافة حقول
عَرِّف حقولًا جديدة في النموذج الموروث مع اختيار نوع الحقل المناسب: Char، Many2one، Boolean، Integer، Text، Selection. فكّر في جعل الحقول معتمدة على الشركة في بيئات متعددة الشركات.
امتدادات بايثون
يمكنك تجاوز create وwrite وunlink لإدخال منطق مخصّص—واستخدم super() للاستدعاء الآمن للمنطق الأصلي. كن حذرًا مع الحقول المحسوبة واعتمادياتها.
Odoo Studio
توفر Odoo Studio واجهة سريعة لإضافة حقول بدون كود، وهي مناسبة للتعديلات البسيطة أو الاختبارات. للتخصيصات المعقّدة أو القابلة للترقية، تظل الوحدات المخصصة أفضل.
ممارسات موصى بها
- أنشئ هيكل الشركة والاتصالات بالشكل الصحيح: أضف أولًا سجل الشركة ثم جهات الاتصال واربطها عبر parent_id.
- حدد country_id لتضمن تنسيق العنوان الصحيح وحسميات الضرائب المناسبة.
- استخدم commercial_partner_id عندما تحتاج إلى الكيان الأعلى لتجميع العمليات مثل حدود الائتمان أو تقارير المبيعات.
- عند بناء تكاملات API، استخدم XML-RPC أو JSON-RPC—نموذج res.partner متاح بالكامل. احرص على مطابقة معرّفات الجهات الخارجية بدقة.
- لحقولك المخصصة، استعمل بادئة
x_أو بادئة الوحدة لتجنّب تعارضات مع تحديثات أودو المستقبلية.
أخطاء شائعة
- إنشاء سجلات مكررة بدل البحث عن السجلات الموجودة. استعمل حقول مثل
email_normalizedأوrefللمساعدة في منع التكرار. - الخلط بين parent_id وcompany_id. parent_id لربط جهة اتصال بشركة؛ company_id يخص انتماء السجل لشركة أودو في بيئة متعددة الشركات.
- نسيان ضبط النوع (type) على جهات الاتصال الفرعية. عناوين الفاتورة والتوصيل تحتاج النوع الصحيح كي تُستخدم في المستندات.
- تجاوز طرق النظام الأساسية دون استدعاء
super(). ذلك قد يكسر وظائف وحدات أخرى أو يعرقل الترقية. - إضافة حقول مطلوبة جديدة بلا قيم افتراضية. السجلات الحالية قد تفشل في التحقق عند تحديث الوحدة.
خاتمة
نموذج res.partner هو حجر الزاوية في أودو لتخزين جهات الاتصال والعملاء والموردين. فهم حقوله وكيفية توسيعه يمكّنك من ضبط النظام ودمجه بشكل صحيح ودون أخطاء.
سواء كنت مستشارًا وظيفيًا يصمم خرائط العمليات أو مطوّرًا يبني وحدات مخصّصة، إتقان نموذج res.partner يوفر وقتك ويقلّل المشكلات في التنفيذ.
هل تحتاج مساعدة في تنفيذ أودو؟
تُقدم Dasolo خدمات تنفيذ وتخصيص وتحسين لأودو، مع خبرة واسعة في تكاملات API وتطوير أودو. فريقنا ملم ببنية بيانات أودو والنماذج الرئيسية مثل res.partner.
إذا احتجت دعمًا في تنفيذ أودو، أو تطوير وحدات مخصّصة، أو تكاملات مع أنظمة أخرى، فنحن جاهزون للمساعدة. حجز عرض توضيحي لمناقشة مشروعك.