نموذج purchase.order: فهم بنية أوامر الشراء في Odoo

مقدمة

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

فهم النماذج في Odoo ضروري للمستشارين الفنيين والمطوّرين على حد سواء. النماذج تُعد العمود الفقري لهندسة البيانات في النظام، فهي تحدد الحقول، والعلاقات بين السجلات، والمنطق التجاري الذي يحكم سلوك التطبيق.

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

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

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

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

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

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

فيما يلي أهم الحقول التي يضمّها نموذج purchase.order. معرفتك بها تسرع العمل مع أوامر الشراء وتسهّل التكامل والتقارير.

1. name

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

2. state

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

3. partner_id

نوع: Many2one إلى res.partner. المزوّد أو الشركة الموردة. حقل إلزامي، ويُستخدم لكل المنطق المرتبط بالمورّد والتقارير.

4. partner_ref

نوع: نص. مرجع المورد أو رقم طلب الشراء لدى المزوّد. يظهر في الوثائق ويساعد على مطابقة إيصالات ومطالبات الفواتير.

5. date_order

نوع: تاريخ ووقت. تاريخ الطلب؛ للمسودات يعكس تاريخ الإنشاء، وللطلبات المؤكدة يعكس تاريخ التأكيد. يُستخدم في التقارير والترتيب وتوقع مواعيد التسليم.

6. date_approve

نوع: تاريخ ووقت. تاريخ الموافقة أو التأكيد؛ يُسجل عند الانتقال إلى حالة المؤكد. يُستخدم لأغراض التدقيق والتقارير، ويكون عادةً للقراءة فقط.

7. order_line

نوع: One2many إلى purchase.order.line. أسطر الطلب: كل سطر يحوي المنتج، الكمية، السعر، والضرائب. هنا يتضح التفصيل الفعلي للأمر.

8. amount_untaxed

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

9. amount_tax

نوع: عدد عشري. إجمالي الضرائب. يُحتسب حسب إعدادات الضريبة في الأسطر ويُعرض في الطلب والفاتورة.

10. amount_total

نوع: عدد عشري. المجموع الكلي شامل الضرائب. هو المبلغ الرئيسي للفوترة والتقارير.

11. currency_id

نوع: Many2one إلى res.currency. العملة المستخدمة؛ عادةً تُورث من الشركة أو المزوّد. كل الحقول المالية تعتمد هذه العملة.

12. origin

نوع: نص. المستند المصدر الذي أنشأ الطلب — كأمر مبيع أو أمر تصنيع عند حدوث دروبشيبينغ أو شراء تلقائي. مهم للتتبّع والمرجعية.

13. dest_address_id

نوع: Many2one إلى res.partner. عنوان التسليم؛ إن لم يُحدد يُستخدم عنوان الشركة. يُستخدم في سيناريوهات الشحن المباشر للعميل.

14. priority

نوع: اختيار. أولوية الطلب: عادي أو عاجل. تُستخدم للتمييز والفرز وقد تُفعّل معالجات خاصة للحالات العاجلة.

15. invoice_status

نوع: اختيار. حالة الفوترة: غير مفوترة، جاهزة للفوترة، مفوترة بالكامل. يؤثر على ظهور زر إنشاء الفاتورة.

16. invoice_count

نوع: عدد صحيح. عدد فواتير المورد المرتبطة. حقل محسوب يُستخدم للعرض وفتح قائمة الفواتير.

17. invoice_ids

نوع: One2many إلى account.move. روابط الفواتير الخاصة بالمورد؛ تربط الشراء بالمحاسبة وتدعم مطابقة ثلاثية وتتبع المدفوعات.

18. picking_ids

نوع: One2many إلى stock.picking. أوامر الاستلام أو التسليم المرتبطة؛ مُفعّلة عندما تكون وحدة المخزون منصّبة.

19. picking_count

نوع: عدد صحيح. عدد الحركات المرتبطة. حقل محسوب يُسهّل التنقل إلى إيصالات الاستلام.

20. create_date

نوع: تاريخ ووقت. تاريخ ووقت إنشاء السجل؛ يُدار أوتوماتيكيًا ويُستخدم في التقارير والتدقيق.

21. write_date

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

22. notes

نوع: نص طويل. شروط، ملاحظات داخلية أو تعليمات خاصة تُطبع على أمر الشراء إن لزم.

23. company_id

نوع: Many2one إلى res.company. في بيئات متعددة الشركات يحدد الشركة المالِكة للسجل ويؤثر على الرؤية والصلاحيات.

24. user_id

نوع: Many2one إلى res.users. المستخدم المسؤول أو المشتري؛ يُستخدم في متابعات الموافقة وتعيين الأنشطة.

25. fiscal_position_id

نوع: Many2one إلى account.fiscal.position. تحديد الخطة الضريبية المناسبة عند التعامل عبر حدود أو أنظمة ضريبية خاصة.

26. payment_term_id

نوع: Many2one إلى account.payment.term. شروط الدفع المتفق عليها (مثلاً صافي 30 يوم) وتُطبَّق على الفواتير.

27. display_name

نوع: نص محسوب. اسم العرض الذي يجمع المرجع مع معلومات المورد ليظهر في قوائم البحث والاختيار.

28. active

نوع: منطقي. مؤشر الأرشفة؛ عند جعله False يُخفي السجل دون حذفه فعليًا للحفاظ على السجلات التاريخية.

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

1. من RFQ إلى أمر شراء

المشتري ينشئ طلب عرض سعر في وضع المسودة ويضيف الأسطر ويرسله للمورد. بعد تأكيد المورد أو موافقة داخلية يتحوّل السجل لحالة مؤكدة وتُتَاح إمكانيات إنشاء إيصالات الاستلام وفواتير المورد.

2. استلام المورد

عند وصول البضائع يُنشأ سند استلام مرتبط بأمر الشراء، وتُحدَّث الحركات في المخزون والكميات المستلمة، وقد يتأثر حساب تكلفة المنتج بسعر الشراء الوارد.

3. فاتورة المورد

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

4. الشحن المباشر (Dropshipping)

عندما يبدّل أمر مبيع الشراء للمورّد، يُسجل الحقل origin للربط بأمر البيع، ويُعيّن dest_address_id لعنوان العميل ليُرسل المورد مباشرةً إلى الزبون.

5. التصنيع وMRP

عندما يحتاج أمر تصنيع لمكونات تُولَّد أوامر شراء للمواد الأولية ويرتبط أصلها بأمر التصنيع؛ نموذج الشراء يبقى حلقة وصل مهمة في دورة الشراء حتى الدفع.

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

المطوّرون يوسّعون نموذج purchase.order بعدّة طرق عبر وراثة النماذج وأنماط امتداد مختلفة.

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

استخدم _inherit = 'purchase.order' لإضافة خصائص جديدة أو تعديل سلوك موجود. تضيف الحقول أو تتجاوز دوال أو تضع قيودًا دون تغيير الكود الأصلي، مما يسهل الصيانة والترقية.

إضافة حقول

عرّف الحقول الجديدة في النموذج الموروث بنوع مناسب: نص، Many2one، منطقي، عدد صحيح، نص طويل، اختيار. فكّر في جعل الحقول متعلقة بالشركة عند التعامل مع بيئة متعددة الشركات.

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

تجاوز دوال مثل button_confirm أو create أو write لإضافة منطق مخصص، لكن استدعِ super() للحفاظ على سلوك الأساس. انتبه لحقول المحسوبة واعتماداتها لتجنب مشاكل الأداء أو التحديث.

Odoo Studio

Odoo Studio مفيد لإضافة حقول بسرعة من دون برمجة، لكنه أقل ملاءمة للمنطق المعقّد أو للحفاظ على قابلية التحديث على المدى الطويل. نموذج purchase.order متاح أيضًا عبر واجهات XML-RPC وJSON-RPC للتكاملات.

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

• استخدم الحالة الملائمة في كل مرحلة؛ تجنّب القفز على حالات أو تجاوز منطق التأكيد.
• سجِّل partner_ref عندما يزودك المورد بمرجع خاص به — ذلك يُسهّل مطابقة الإيصالات والفواتير.
• استخدم حقل origin لتتبّع مصدر أمر الشراء؛ مهم في سيناريوهات الشحن المباشر والتصنيع.
• عند بناء تكاملات برمجية، استخدم واجهات XML-RPC أو JSON-RPC لنماذج Odoo. احذر من مطابقة المعرفات الخارجية بعناية لتفادي ازدواجية البيانات.
• للفروع المخصصة، ضع بادئة مثل x_ أو بادئة موديول لتفادي تعارضات مع نسخ Odoo المستقبلية.

أخطاء شائعة

• تعديل أوامر مؤكدة بدون التحقق من الحالة. الأوامر المؤكدة لها قيود على الحقول؛ إن لزم تغييره اتبع سير العمل الصحيح أو أعد إصدار أمر جديد.
• الخلط بين partner_id و dest_address_id. الأول للمورد، والثاني لعنوان التسليم (مهم في الشحن المباشر).
• تجاوز button_confirm دون استدعاء super(). هذا قد يكسر عمل وحدات أخرى أو يجعل الترقية صعبة.
• إضافة حقول إجبارية بدون قيم افتراضية. سيؤدي ذلك إلى فشل السجلات القائمة عند الترقية أو الاستيراد.
• نسيان ضبط currency_id مع موردين بعملات مختلفة. العملة الخاطئة تؤدي إلى حسابات تكلفة وفوترة غير صحيحة.

خلاصة

نموذج purchase.order هو قلب ميزة المشتريات في Odoo: يجمع طلبات الأسعار والأوامر المؤكدة. الإلمام بالحقول وكيفية توسعتها يساعدك على ضبط النظام وتخصيصه ودمجه بشكل صحيح.

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

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

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

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