تخطي للذهاب إلى المحتوى

فهم نموذج sales.order: بنية أوامر البيع في Odoo

دليل شامل لموديل فواتير البيع في أودو مخصّص للمطوّرين ومستشاري النظم في هذا الدليل سنأخذك خطوة بخطوة عبر بنية كيان فواتير البيع في أودو — من الحقول الأساسية إلى العلاقات والآليات البرمجية التي تتحكم بسريان العملية التجارية. الهدف أن تفهم كيف تُخزّن بيانات الفاتورة، كيف تُبنى الروابط مع العملاء والمنتجات والمخزون، وما هي نقاط التمديد (hooks) المناسبة لتعديل السلوك الافتراضي دون تعطيل الترقية. من ناحية وظيفية، سنغطي حالات الاستخدام الشائعة: إنشاء فاتورة جديدة يدوياً، استيراد دفعات من ملف CSV، تحويل عروض الأسعار إلى فواتير، وإدارة جداول الدفع والضرائب والخصومات. سنشرح أيضاً دورة الحالة (مسودّة، مؤكّدة، مرسلة، مدفوعة، ملغاة) وكيف تؤثّر كل حالة على محاسبة الدفعات والمخزون. من ناحية تقنية، ستتعلم بنية النموذج (model) في أودو: الحقول الأساسية مثل partner_id وorder_line وamount_total، وأنواع الحقول (Many2one, One2many, Float, Selection)، وكيف تُعرّف القيود (constraints) وحسابات الحقول المحسوبة (compute) ونموذج التحكم بالعرض (views) والسلوك عبر الـORM. سنعرض أمثلة عملية لتوريث (inherit) النموذج، إضافة حقل جديد، والاعتراض على طرق (override) مثل action_confirm وcreate/write. سنسلّط الضوء على التكاملات الحيوية: الربط مع المحاسبة (account.move/account.invoice)، مع إدارة المخزون عند إصدار الفواتير لمخزون مسحوب، ومع بوابات الدفع الإلكترونية، وكيفية معالجة الضريبة حسب البلاد. كما سنتطرّق لأفضل الممارسات في كتابة اختبارات وحدات (unit tests) ومجموعات بيانات تجريبية (demo data) لضمان استقرار التخصيصات. في النهاية، ستجد نصائح عملية لتصميم تخصيصات قابلة للترقية: استخدم الوراثة بدل التعديل في المصدر، تجنّب تغيير سجلات البيانات الأساسية مباشرة، احفظ المنطق المعقد في موديولات منفصلة، واكتب وثائق وواجهات إعداد واضحة للمستخدم النهائي. هذا الدليل موجّه لمن يريد التحكم الكامل في سلوك فواتير البيع داخل أودو — سواء لتسليم مشاريع عملاء أو لبناء حلول جاهزة للتوزيع.
10 مارس 2026 بواسطة
فهم نموذج sales.order: بنية أوامر البيع في Odoo
Dasolo
لا توجد تعليقات بعد

مقدمة


في Odoo، تُعرّف النماذج كيف يُنظّم النظام البيانات ويخزنها في قاعدة البيانات. كل سجل تجاري تتعامل معه—من طلبات البيع إلى الفواتير وقوائم العملاء—يُخزَّن داخل نموذج محدد.


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


سأركز هنا على أحد أهم النماذج في النظام: sales.order. سواء كنت تبني وحدات مخصّصة، أو تربط نظامًا خارجيًا، أو تضبط سير مبيعات، فالتعامل مع هذا النموذج سيكون متكررًا.

ما هو نموذج sales.order


نموذج sales.order يجمع بيانات العروض وطلبات البيع. هو النقطة المركزية التي تُسجل فيها تفاصيل المعاملة قبل أن تُصدَر الفواتير أو تُجرى التسليمات.


هذا النموذج يُستخدم داخل تطبيق المبيعات في Odoo.


المسار الاعتيادي يبدأ بمندوب المبيعات يُنشئ عرض سعر (مسجّل كـ sales.order في حالة مسودة). عندما يوافق العميل ينتقل السجل إلى حالة مؤكدة. نفس النموذج يستضيف عروض الأسعار والمسودات والطلبات المؤكدة، وحقل الحالة يوضح مرحلة العملية.


المزايا الوظيفية تأتي من تمديد النموذج عبر آلية الوراثة في Odoo. على سبيل المثال، CRM يربط الفرص بالطلبات، والمحاسبة تضيف حقول الفوترة، والمخزون يضيف تواريخ التسليم. كل وحدة تضيف احتياجاتها دون تكرار بنية الأساس.

الحقول الأساسية في النموذج


فيما يلي الحقول التي تحتاج لمعرفتها عند العمل على العروض والطلبات؛ فهمها يسهّل التكوين والتكامل والبرمجة.


1. name

النوع: Char. رقم مرجع الطلب أو رقم العرض. عادة يُولَّد أوتوماتيكيًا ويُستخدم كمعرّف مرئي في القوائم والمستندات.


2. state

النوع: Selection. يبيّن مرحلة الطلب: مسودة، مُرسلة، مؤكدة، مُنجزة أو ملغاة. الحالة تحكم الإجراءات المتاحة على السجل.


3. partner_id

النوع: Many2one (res.partner). الجهة العميلة الأساسية. حقل مطلوب ويُستخدم في جميع منطق العملاء والتقارير.


4. partner_invoice_id

النوع: Many2one (res.partner). عنوان الفوترة. إن لم يُحدد، يُرث من partner_id. يُستخدم عندما يختلف عنوان الفاتورة عن العنوان الأساسي.


5. partner_shipping_id

النوع: Many2one (res.partner). عنوان التسليم. إن لم يُحدد، يُرث من partner_id ويُستخدم لحسابات الشحن وجدولة التسليم.


6. user_id

النوع: Many2one (res.users). مندوب المبيعات المسؤول. يُستخدم في تقارير الأداء والعمولات وتعيين المهام.


7. team_id

النوع: Many2one (crm.team). فريق المبيعات الذي ينتمي إليه السجل. مهم لتقسيم التقارير وحساب الحصص.


8. date_order

النوع: Datetime. تاريخ الطلب؛ في المسودات يكون تاريخ الإنشاء، وبعد التأكيد يصبح تاريخ التأكيد. يُستخدم في التحليل والفرز.


9. validity_date

النوع: Date. تاريخ انتهاء صلاحية العرض. بعد هذا التاريخ يصبح العرض غير صالح عادةً.


10. commitment_date

النوع: Datetime. تاريخ التسليم المتفق عليه. تُبنى حجوزات التسليم حوله بدلاً من زمن توافر المنتج الافتراضي.


11. order_line

النوع: One2many (sale.order.line). سطور الطلب: المنتج، الكمية، السعر، والضرائب—هي تفاصيل الطلب الأساسية.


12. amount_untaxed

النوع: Float. المجموع قبل الضريبة. يُحتسب من سطور الطلب ويُعرض في الشاشات والتقارير.


13. amount_tax

النوع: Float. مجموع الضرائب المحتسبة للطلب. يظهر في الفاتورة والطلب.


14. amount_total

النوع: Float. المبلغ الإجمالي شاملاً الضرائب؛ الرقم الرئيسي للفوترة والتقارير.


15. currency_id

النوع: Many2one (res.currency). العملة المعتمدة للسعر. تُورَّث عادة من الشركة أو قائمة الأسعار.


16. pricelist_id

النوع: Many2one (product.pricelist). قائمة الأسعار المستخدمة لتحديد أسعار السطور. يمكن اختيارها يدويًا أو تحديدها من بيانات العميل.


17. payment_term_id

النوع: Many2one (account.payment.term). شروط الدفع مثل صافي 30 أو دفعة مقدمة، وتنتقل للفاتورة عند إنشائها.


18. fiscal_position_id

النوع: Many2one (account.fiscal.position). الوضع الضريبي لتطبيق خرائط الضريبة الخاصة ببلد أو نظام ضريبي مختلف.


19. client_order_ref

النوع: Char. مرجع العميل أو رقم أمر الشراء الذي يزودك به العميل؛ يُعرض على المستندات.


20. origin

النوع: Char. مصدر السجل—مثلاً اسم الفرصة التي أنشأت الطلب—مفيد للتتبع وربط العمليات.


21. create_date

النوع: Datetime. وقت إنشاء السجل تلقائيًا. مهم للتدقيق والتقارير الزمنية.


22. write_date

النوع: Datetime. وقت آخر تعديل للسجل؛ يُدار تلقائيًا لمتابعة التغييرات.


23. note

النوع: Text. ملاحظات داخلية أو شروط وأحكام يمكن عرضها في العرض أو الفاتورة.


24. require_signature

النوع: Boolean. تطلب توقيع العميل الإلكتروني قبل تأكيد الطلب—مفيد لمبيعات الويب والبوابة.


25. require_payment

النوع: Boolean. تطلب دفعًا إلكترونيًا قبل التأكيد—مناسب للطلبات المسبقة أو الدفعات الجزئية.


26. invoice_status

النوع: Selection. يبيّن حالة الفوترة: لا شيء، مستحقة للفوترة، مفوترة كليًا، أو أجزاء إضافية للفوترة.


27. locked

النوع: Boolean. عندما يكون صحيحًا، يمنع تعديل السجل—يُفعّل عادة بعد التأكيد أو ترحيل المستندات.


28. company_id

النوع: Many2one (res.company). في إعدادات تعدد الشركات يحدد الشركة المالكة للطلب ويؤثر على الصلاحيات.


29. tag_ids

النوع: Many2many (crm.tag). وسوم للتصنيف والفلترة؛ مفيدة لتجزيء تحليلات المبيعات.


30. signed_by

النوع: Char. اسم الشخص الذي وقّع عند تمكين التوقيع الإلكتروني؛ يُحفظ لأغراض التدقيق.


31. signed_on

النوع: Datetime. وقت وتاريخ التوقيع الإلكتروني.


32. prepayment_percent

النوع: Float. نسبة الدفعة المسبقة المطلوبة عند استخدام دفع مُلزِم أو عربون.

كيف يُستخدم هذا النموذج في سير العمل التجاري


1. من عرض إلى طلب

المسار النموذجي: مندوب ينشئ عرضًا في حالة مسودة، يضيف السطور والأسعار ويرسله للعميل. عند قبول العميل ينتقل السجل إلى حالة مؤكدة ويُنشأ سندات الفاتورة والتسليم حسب الحاجة.


2. التجارة الإلكترونية وبوابة العملاء

طلبات المتجر الإلكتروني تُسجَّل مباشرة كسجلات sales.order. إعدادات require_signature وrequire_payment تسمح بإجبار الدفع أو التوقيع قبل التفعيل.


3. من CRM إلى المبيعات

عند فوز فرصة تُولَّد عرض سعر مرتبطًا بها؛ حقل origin يُبقي الصلة مرئية، وuser_id وteam_id تُستخدم في حسابات الأداء والعمولات.


4. الفوترة

من طلب مؤكد يُمكن إنشاء الفاتورة؛ يتم نقل سطور الفاتورة من سطور الطلب، وتورث شروط الدفع والوضع الضريبي من الطلب، وحالة الفوترة تتابع التقدّم.


5. التسليم والالتزام بالمواعيد

commitment_date يُنظّم جدولة التسليمات فلو تم تحديده تُحجز أوامر التسليم وفقًا له، وpartner_shipping_id يحدد وجهة الشحن.

كيف يطوّر المطوّرون هذا النموذج


المطوّرون يوسّعون نموذج sales.order بعدة طرق، والوراثة في Odoo هي الآلية الأساسية لذلك.


وراثة النموذج

استخدم _inherit = 'sale.order' لإضافة حقول جديدة، تعديل سلوكيات، أو إضافة قيود. يبقيك هذا النهج منفصلًا في وحدة مخصّصة ما يسهل الترقية لاحقًا.


إضافة حقول

علّف حقولًا جديدة في النموذج الموروث مع اختيار نوع الحقل المناسب: Char، Many2one، Boolean، Integer، Text، Selection. فكّر في جعل الحقول مرتبطة بالشركة عند الحاجة.


امتدادات بايثون

يمكنك تجاوز دوال مثل action_confirm، create أو write لإدخال منطق مخصّص. نادِمًا super() لاستدعاء السلوك الأصلي، وكن حذرًا مع الحقول المحسوبة واعتمادياتها.


Odoo Studio

توفر Odoo Studio وسيلة سريعة لإضافة حقول وتخصيص الشاشات دون كود، لكن للمنطق المعقّد أو للصيانة على المدى الطويل وحدات مخصصة تكون أفضل.

أفضل الممارسات


  • استخدم الحالة المناسبة لكل مرحلة ولا تخطِ المتطلبات المنطقية. تخطي حالات التأكيد قد يكسر عمليات مرتبطة.
  • عيّن commitment_date عندما يتفق العميل على موعد تسليم؛ هذا يحسّن دقّة التخطيط والالتزام.
  • استخدم commercial_partner_id عندما تحتاج كيانًا أعلى للتجميع—مثلاً لحساب اعتمادات أو لتقارير مجمعة.
  • عند بناء تكامل عبر API استخدم XML-RPC أو JSON-RPC. نموذج sales.order متاح بالكامل؛ احرص على مطابقة المعرفات الخارجية بعناية.
  • للفروع المخصّصة، ضع بادئة x_ أو بادئة اسم الوحدة للحقل لتجنّب تعارض مع تحديثات Odoo المستقبلية.

أخطاء شائعة


  • لا تعدّل الأوامر المؤكدة دون التحقّق من حقل locked. عند اللزوم أنشئ نسخة مراجعة أو اتبع مسار العمل الصحيح.
  • لا تخلط بين partner_id وpartner_invoice_id وpartner_shipping_id؛ لكلِّ واحد غرضه. اضبط الثلاثة عند اختلاف العناوين.
  • تجنّب تجاوز action_confirm دون استدعاء super() لأن ذلك قد يقطع تفاعل وحدات أخرى أو يؤدي لمشكلات عند الترقية.
  • لا تجعل حقلاً مخصصًا مطلوبًا دون قيمة افتراضية؛ ذلك يُسبّب فشل السجلات القائمة عند ترقية الوحدة.
  • تذكّر ضبط pricelist_id عندما تختلف العملة أو سياسة التسعير عن الافتراضي؛ الأسعار الخاطئة تؤدي إلى أخطاء في الفوترة.

خاتمة


نموذج sales.order هو القلب لنشاط مبيعات Odoo—يجمع العروض والطلبات المؤكدة. معرفة حقوله وكيفية تمديده تساعدك على التكوين، التخصيص، والتكامل بكفاءة.


سواء كنت استشاريًا وظيفيًا يُصمم عمليات مبيعات أو مطوّرًا يبني وحدات مخصّصة، فهم sales.order يوفّر وقتًا ويقلّل الأخطاء.

هل تحتاج مساعدة في تنفيذ Odoo؟


تعمل Dasolo مع الشركات لتنفيذ وتخصيص وتحسين Odoo، متخصّصون في تكاملات API والتطوير، ولدينا خبرة عميقة في بنية بيانات Odoo ونماذج مثل sales.order.


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

فهم نموذج sales.order: بنية أوامر البيع في Odoo
Dasolo 10 مارس 2026
شارك هذا المنشور
تسجيل الدخول حتى تترك تعليقاً