مقدمة
في أودو، تُعرّف النماذج الطريقة التي يُنظّم بها البيانات ويُحفظ جدولها في قاعدة البيانات. كل كيان تجاري تتعامل معه — من أوامر البيع إلى الفواتير وإدخالات الدفاتر — يُخزّن داخل نموذج منظّم.
فهم نماذج أودو أمر ضروري للمطورين والاستشاريين الوظيفيين على حدّ سواء. هذه النماذج تشكّل العمود الفقري لبنية البيانات في أودو، وتحدّد الحقول، والروابط بين السجلات، والمنطق التجاري الذي يحكم سلوك النظام.
هذه المقالة مخصّصة لواحد من أهم نماذج المحاسبة في أودو: account.move. سواء كنت تبني تقارير مخصّصة، توصل أنظمة خارجية، أو تضبّط سير إصدار الفواتير، فستقابل هذا النموذج مرارًا وتكرارًا.
ما هو نموذج account.move
نموذج account.move يرمز إلى قيود اليومية والمستندات الحسابية داخل أودو. في الإصدارات الحديثة تم توحيد الفواتير، فواتير الموردين، الملاحظات الائتمانية، وإدخالات اليومية اليدوية تحت هذا النموذج الواحد.
يعمل هذا النموذج ضمن تطبيق المحاسبة، وهو الأم لمدخلات السطور account.move.line التي تحوي حركات المدين والدائن. كل فاتورة أو سند أو قيد يظهر كسجل account.move واحد يحتوي سطرًا واحدًا أو أكثر.
التعريف الأساسي للنموذج موجود في وحدة account، بينما الوحدات الأخرى توسّعه عبر الوراثة النمطية في أودو. على سبيل المثال، وحدة المبيعات تضيف آليات إنشاء الفواتير من أوامر البيع، ووحدة المشتريات تضيف إنشاء الفواتير من أوامر الشراء دون إعادة تصميم هيكل النموذج المركزي.
الحقول الأساسية في النموذج
فيما يلي الحقول الأكثر أهمية داخل account.move. معرفتك بها تسهّل التعامل مع الفواتير، والسندات، وقيود اليومية عند إعداد تقارير أو تكاملات.
1. name
نوع: Char. يخزن رقم أو اسم القيد/المستند، وغالبًا ما يُولّد تلقائيًا من تسلسل اليومية. يظهر في القوائم والمطبوعات.
2. move_type
نوع: Selection. يحدّد نوع المستند — قيد يدوي، فاتورة عميل، ملاحظة ائتمانية، فاتورة مورد — وهو الذي يوجه النموذج لاستخدام واجهات وسير عمل محددة.
3. state
نوع: Selection. حالة المستند: مسودة، مسجلة (مقيدة)، أو ملغاة. المسودات قابلة للتعديل، والمستندات المسجلة تُقفل وتؤثر في الدفاتر.
4. date
نوع: Date. تاريخ المستند المستخدم في التقارير، والتحصيل، وإقفال الفترات. في الفواتير يكون تاريخ الفاتورة عادةً.
5. journal_id
نوع: Many2one (account.journal). اليومية التي ينتمي إليها القيد — مبيعات، مشتريات، بنوك، أو يوميات أخرى — وهي تحدّد الترقيم والحسابات الافتراضية.
6. company_id
نوع: Many2one (res.company). في بيئات الشركات المتعددة يبيّن أي شركة يتبع لها القيد، ويؤثر على صلاحيات الرؤية والتقارير الموحدة.
7. partner_id
نوع: Many2one (res.partner). العميل أو المورد المرتبط بالمستند. مطلوب للفواتير والسندات، ويُستخدم في تقارير التحصيل ومطابقة الدفعات.
8. currency_id
نوع: Many2one (res.currency). العملة التي يُسجّل بها المبلغ. عند استخدام عملات متعددة تُحوّل القيم لعملة الشركة للتقارير الموحّدة.
9. amount_total
نوع: Monetary. إجمالي قيمة المستند. في الفواتير يعبّر عن المبلغ المستحق ويُحسب من سطور الفاتورة.
10. amount_residual
نوع: Monetary. المتبقي غير المدفوع. للفواتير المدفوعة تكون قيمته صفرًا، ويُستخدم في دوال التحصيل.
11. payment_state
نوع: Selection. حالة الدفع: غير مدفوع، قيد الدفع، مدفوع، مدفوع جزئيًا، مرفوع، أو حالات تراثية. تُستخدم في تذكير المدفوعات وتقارير التحصيل.
12. line_ids
نوع: One2many (account.move.line). سطور القيد المحاسبي، كل سطر يحدّد الحساب، المدين، والدائن. يجب توافق مجموع المدينين مع مجموع الدائنين.
13. invoice_line_ids
نوع: One2many (account.move.line). سطور المنتجات أو الخدمات على الفواتير؛ عند التقييد تولّد هذه السطور واحدًا أو أكثر من سطور القيد.
14. invoice_date
نوع: Date. تاريخ الفاتورة المرتبط بفترات الضرائب والفوترة، وقد يختلف عن تاريخ القيد في بعض الإعدادات.
15. invoice_date_due
نوع: Date. تاريخ الاستحقاق المحسوب من شروط الدفع أو المُحدّد يدويًا، ويُستخدم في تقارير الأعمار وإجراءات التحصيل.
16. ref
نوع: Char. مرجع خارجي مثل رقم فاتورة المورد، مفيد للمطابقة والمصالحة مع مستندات خارجية.
17. invoice_origin
نوع: Char. مصدر المستند؛ عند إنشاء الفاتورة من أمر بيع يحمِل هذا الحقل رقم الأمر لتتبع السلسلة من الطلب إلى الفاتورة.
18. create_date
نوع: Datetime. تاريخ ووقت إنشاء السجل تُدار تلقائيًا من أودو لتوثيق الزمن.
19. write_date
نوع: Datetime. تاريخ ووقت آخر تعديل على السجل، كذلك يُدار آليًا.
20. narration
نوع: Text. ملاحظات داخلية أو قيد مذكّرة تظهر في مطبوعات قيود اليومية لكنها عادةً لا تُعرض للعميل على الفاتورة.
21. fiscal_position_id
نوع: Many2one (account.fiscal.position). الوضع الضريبي الذي يحدد قواعد تطبيق الضرائب بناءً على الشريك والبلد.
22. invoice_payment_term_id
نوع: Many2one (account.payment.term). شروط الدفع مثل صافي 30 يومًا تُستخدم لحساب تاريخ الاستحقاق وتجزئة المدفوعات.
23. invoice_user_id
نوع: Many2one (res.users). المستخدم المسؤول أو مندوب المبيعات عن الفاتورة، ويُستخدم لأغراض التقارير والعمولات.
24. reversed_entry_id
نوع: Many2one (account.move). عند عمل قيد عكسي يرتبط هذا الحقل بالقيد الأصلي ليسهّل التتبّع والتدقيق.
25. to_check
نوع: Boolean. علامة تُشير إلى أن القيد يحتاج مراجعة — تُستعمل في التسوية البنكية وسيناريوهات الاستثناء.
26. active
نوع: Boolean. علم الأرشفة؛ عند جعله False يُعتبر السجل مؤرشفًا بدلاً من حذفه، ويُستخدم عادةً للقيمة الملغاة.
27. sequence_number
نوع: Integer. رقم الترتيب المأخوذ من تسلسل اليومية لعرض وترتيب السجلات، وتُديره مزايا التسلسل في أودو.
28. amount_untaxed
نوع: Monetary. المجموع الفرعي قبل الضريبة — مجموع سطور الفاتورة قبل إضافة الضرائب.
29. amount_tax
نوع: Monetary. إجمالي الضرائب المحسوب من سطور الفاتورة وإعدادات الضرائب.
30. invoice_source_email
نوع: Char. عند استيراد فواتير المورد من البريد الإلكتروني، يُخزّن عنوان البريد المصدر لمطابقة الإدخالات الآلية.
كيف يُستخدم هذا النموذج في سير العمل التجاري
1. فواتير العملاء
عند تسليم بضاعة أو خدمة من أمر بيع، ينشئ أودو سجل account.move من نوع out_invoice وتُورَّد سطور الفاتورة من سطور الطلب؛ عند التقييد تتكوّن سطور القيد ويتم تحديث حسابات القبض.
2. فواتير الموردين
أوامر الشراء قد تولّد فواتير تلقائيًا أو تُسجّل يدويًا؛ كل فاتورة مورد تُنشأ كسجل account.move من نوع in_invoice ويرتبط بها المورد عبر partner_id، وعند التقييد تُحدث حسابات الدائنين.
3. تسوية المدفوعات
تُطابق الدفعات مع الفواتير باستخدام amount_residual وpayment_state؛ عملية التسوية تربط قيود المدفوعات بقيود الفاتورة وتُنقِل الرصيد المتبقي.
4. قيود يدوية
يُنشئ المحاسبون قيودًا من نوع entry لتسويات دوريّة، استحقاقات، أو تصحيحات؛ يضيفون سطور القيد مع تحديد الحسابات والمدين والدائن، ويجب توازن القيد قبل التقييد.
5. ملاحظات ائتمانية واستردادات
الملاحظات الائتمانية تكون من نوع out_refund أو in_refund وتُعيد أثر الفاتورة الأصلية؛ الحقل reversed_entry_id يُستخدم لربط القيد المعكوس بالأصلي لأغراض التدقيق.
كيف يضيف المطورون وظائف إلى هذا النموذج
يطوّر المبرمجون امتدادات على account.move بعدة طرق، والوراثة النموذجية في أودو هي الأداة الأساسية لذلك.
وراثة النموذج
باستخدام _inherit = 'account.move' يمكنك توسيع النموذج بإضافة حقول جديدة أو تعديل سلوكيات أو إضافة قيود؛ الاحتفاظ بالتعديلات في وحدة منفصلة يسهل التحديثات المستقبلية.
إضافة حقول
عَرّف حقولًا جديدة في الوحدة الموروثة باستخدام نوع الحقل المناسب — نص، مرجع Many2one، منطق صحيح/خاطئ، عدد صحيح، نص طويل، أو اختيار — وفكّر في جعل الحقول قابلة للتهيئة حسب الشركة في بيئات متعددة الشركات.
امتدادات بايثون
يمكن تجاوز دوال مثل create، write، _post أو button_draft لإضافة منطق مخصّص، لكن استدعاء super() ضروري للحفاظ على السلوك الافتراضي. راعِ الحقول المحسوبة واعتمادياتها واستخدم مزايا API مثل @api.model و@api.depends بالشكل الصحيح.
Odoo Studio
يتيح Odoo Studio إضافة حقول وتعديلات سريعة بدون كتابة كود، وهو مناسب للتغييرات البسيطة. لكن للمنطق المعقّد أو التحقق أو الأتمتة المستدامة، تُفضّل الحزم المخصّصة القابلة للصيانة.
ملاحظة: account.move نموذج قياسي يخزن بيانات دائمة — ليس نموذجًا مجردًا أو مؤقتًا. النماذج المجردة تُستخدم كقوالب وليست لها جداول في قاعدة البيانات، والنماذج المؤقتة (transient) تُستخدم للنوافذ الوسيطة.
ممارسات موصى بها
- دوامًا ضع عامل التصفية على move_type عند بناء تقارير أو تكاملات، لأن كل نوع قد يملك متطلبات وسلوكًا مختلفًا.
- استخدم اليومية المناسبة لكل نوع حركة لأن المزج بين يوميات مختلفة قد يفسد الترقيم والتقارير.
- عند إنشاء قيود عبر واجهة برمجة التطبيقات، تأكد من توازن line_ids (مجموع المدين = مجموع الدائن) قبل محاولة التقييد، لأن القيود غير المتوازنة ستُرفض.
- عند جلب فواتير من أنظمة خارجية، خزّن ترجمات أنواع المستندات إلى move_type الصحيحة — out_invoice للمبيعات وin_invoice للمشتريات.
- استخدم بادئة x_ للحقول المخصصة لتجنّب تعارضات مع إصدار أودو المستقبلي.
أخطاء شائعة
- نشر قيود غير متوازنة سيؤدي إلى فشل العملية؛ تحقق دومًا من تساوي مجموعي المدين والدائن.
- تعديل السجلات المقيدة مباشرة غير مُستحسن لأن القيد يظل مقفلًا؛ استخدم قيدًا معكوسًا أو أنشئ قيدًا جديدًا لتصحيح الأخطاء.
- نسيان تعيين partner_id على فواتير العملاء أو الموردين سبب شائع لمشكلات في التقارير وعمليات المطابقة.
- استخدام move_type غير الصحيح يؤدي إلى سلوك غير سليم — ملاحظة ائتمانية (out_refund) ليست ببساطة فاتورة سالبة، استخدم النوع المناسب.
- تجاوز الدوال الأساسية دون استدعاء super() قد يكسر وظائف وحدات أخرى أو يعقّد التحديثات المستقبلية.
خاتمة
نموذج account.move مركزي في محاسبة أودو، فهو يجمع الفواتير، والسندات، وقيود اليومية في هيكل موحّد، ومعرفة حقوله وكيفية امتداده يساعدك على إعداد وتخصيص وربط أودو بكفاءة.
سواءً كنت مستشارًا وظيفيًا يخرط العمليات التجارية أو مطورًا يبني وحدات مخصّصة، فهم account.move يوفر وقتك ويقلّل الأخطاء.
هل تحتاج مساعدتنا في تنفيذ أودو؟
تساعد Dasolo الشركات على تنفيذ وتخصيص وتحسين أودو، مع خبرة خاصة في تكامل واجهات برمجة التطبيقات وتطوير الوحدات. فريقنا متمكّن من بنية بيانات أودو ونماذج مثل account.move.
إذا احتجت مساعدة في تنفيذ أودو أو تطوير وحدات مخصّصة أو تكاملات، نحن هنا لدعمك. احجز عرضًا تجريبيًا لمناقشة مشروعك.