دورة المشتريات في Odoo 20.0: من طلب عرض السعر إلى السداد

ملخص

• دورة المشتريات في Odoo 20.0 (الإصدار الحالي، صدر سبتمبر 2026) تبدأ بطلب عرض سعر (RFQ) من تطبيق Purchase، وتُؤكَّد أمر شراء (PO) بالضغط على Confirm Order، ثم استلام في المخزون واعتماد فاتورة مورد.
• سياسة المراقبة (Control Policy) على كل صنف تحكم فاتورة المورد: On ordered quantities تُفوتِر ما طُلب ولو لم يُستلم بعد، وOn received quantities لا تُفوتِر إلا ما استُلم فعلاً.
• المطابقة الثلاثية (3-way matching)، المُعدّة بحسب التوثيق لسياسة On received quantities وحدها، تربط حالة Should Be Paid على الفاتورة (Yes/No/Exception) بما استُلم فعلاً.
• التكاليف الإضافية (Landed Costs) كالشحن والتأمين والجمارك تُضاف إلى تقييم الصنف بمنتج خدمي مخصَّص، وتُوزَّع بإحدى خمس طرق، وتُرحَّل بقيد محاسبي مستقل.
• ضريبة الخصم تُبنى في Odoo كضريبة سالبة من نوع Purchase لفواتير الموردين، تُطرح من الدفعة نفسها؛ ونسبها المصرية ونموذج 41 في دليل مستقل.
• أما قواعد الفاتورة الإلكترونية وأثرها على خصم تكلفة الشراء فمسألة قانونية مصرية لا إعداد في Odoo، ورابط دليلها أدناه.

من طلب عرض السعر إلى تأكيد أمر الشراء

طلب عرض السعر (Request for Quotation، RFQ) في تطبيق Purchase يُوحِّد شراء الأصناف من أكثر من مورد بأسعار ومواعيد تسليم مختلفة. ويحمل حقل Vendor Reference رقم أمر البيع أو التسليم الذي يرسله المورد، ويُستفاد منه عند وصول الأصناف في مطابقة أمر الشراء بأمر التسليم. وحقل Order Deadline هو الموعد الذي يجب أن يوافق المورد بحلوله؛ وتجاوزه لا يمنع الشراء، بل يُعلِّم الطلب "متأخراً" فقط. ومتى وافق المورد، فالضغط على Confirm Order يحوّل الـRFQ مباشرة إلى أمر شراء (Purchase Order، PO) نشِط؛ ومع تثبيت تطبيق Inventory يُنشئ هذا التأكيد مستند استلام (Receipt) تلقائياً، ببيانات الأصناف وموعد الوصول المتوقع.

الاستلام في المخزون

الإعداد الافتراضي لمستودعات Odoo استلام وتسليم بخطوة واحدة: الأصناف المشتراة تدخل المخزون مباشرة. بعد تأكيد الـPO يظهر زر Receipt الذكي أعلى نموذجه، وفتحه يعرض مستند الاستلام (WH/IN). والضغط على Validate ينقل المستند إلى حالة Done ويحدِّث عمود Received في سطر الـPO ليطابق الكمية المطلوبة.

مراقبة فاتورة المورد: الكمية المطلوبة أو المستلمة

حقل Control Policy على تبويب Purchase بكل صنف (قسم Vendor Bills) يحدد أساس الفاتورة: On ordered quantities تبني الفاتورة المسودة على الكميات المطلوبة فور تأكيد الـPO ولو لم يصل شيء بعد؛ وOn received quantities لا تُنشأ معها فاتورة إلا بعد استلام جزء من الطلب، وتقتصر عندها على ما استُلم فعلاً. والافتراضي بحسب نوع الصنف، كما ورد بالتوثيق:

وتسمية التوثيق لافتراضي السلع، On delivered quantities، لا تطابق أياً من خياري الحقل اللذين يذكرهما (ordered وreceived)؛ فيُتحقَّق من الافتراضي الفعلي على نموذج الصنف.

ولضمان ألا تُسدَّد الفاتورة إلا بعد استلام بعض ما في أمر الشراء أو كله، تُفعَّل المطابقة الثلاثية (3-way matching) من Purchase ‣ Configuration ‣ Settings، قسم Invoicing؛ ويذكر التوثيق أنها مُعدّة للعمل مع سياسة On received quantities وحدها. ومتى فُعِّلت يظهر على الفاتورة حقل Should Be Paid: Yes عند إنشائها، وNo بعد سدادها وظهور شريط Paid عليها، وException إن عُدِّلت بيانات المسودة — وعندها لا يمنع Odoo التعديل، بل يُنبِّه فقط. ولمطابقة الفاتورة بأمر الشراء يعرض زر Purchase matching الذكي كل سطور أوامر الشراء المرتبطة بمورد الفاتورة، فتُحدَّد السطور المعنية مع الفاتورة المسودة ثم يُضغط Match. ويورد توثيق 20.0 هذه الخطوة في صفحة رقمنة المستندات (Document Digitization)، لفاتورة رُفعت وقرأتها تقنية OCR، بعدما كانت في توثيق 19.0 جزءاً من صفحة فواتير الموردين العامة. أما من يملك تغيير حالة Should Be Paid يدوياً فمسألة صلاحيات، موضوع مقالة مستقلة عن الرقابة الداخلية في Odoo.

التكاليف الإضافية على الشحنة (Landed Costs)

الشحن والتأمين والجمارك ورسوم أخرى تُضاف إلى تكلفة الصنف نفسه لا تُقيَّد مصروفاً مستقلاً، بخاصية Landed Costs التي تُفعَّل من Inventory ‣ Configuration ‣ Settings، قسم Valuation، مع تحديد Default Journal. ولكل تكلفة متكررة يُنشأ صنف خاص (Product Type: Service إلزامياً)، بتفعيل Is a Landed Cost في تبويب Purchase، واختيار Default Split Method: بالتساوي (Equal)، أو بالكمية، أو بالتكلفة الحالية، أو بالوزن، أو بالحجم. وتطبيقها مشروط بأن تكون أصناف الـPO الأصلي في فئة صنف بطريقة تقييم AVCO أو FIFO. عملياً: إضافة صنف التكلفة سطراً في فاتورة المورد تُظهر زر Create Landed Costs؛ والسجل الذي يُنشئه يُربط بتحويل (Transfer) مُعتمَد، ثم يُضغط Compute فيعرض تبويب Valuation Adjustments القيمة الأصلية والتكلفة الإضافية والقيمة الجديدة، وValidate يُرحِّل القيد إلى دفتر اليومية المحدَّد.

السداد والدفعات المجمّعة

تسجيل السداد على فاتورة مفردة بالضغط على Pay، واختيار Journal وPayment Date، ثم Create Payment؛ فتتحول الفاتورة إلى In payment، وإلى Paid بعد مطابقتها مع حركة البنك. وإن قلّ المبلغ المسدَّد عن المستحق وكان لطريقة السداد حساب مدفوعات معلّقة (outstanding account)، يعرض حقل Payment Difference الفارق، وتُختار Keep open لتبقى الفاتورة جزئية، أو Mark as fully paid بترحيل الفارق إلى حساب آخر؛ ودونه يُكتفى بإدخال المبلغ الجزئي. وعدة فواتير لنفس المورد تُسدَّد بدفعة واحدة بتحديدها معاً والضغط على Pay وتفعيل Group Payments. أما تجميع دفعات مستقلة لعدة موردين في ملف أو إيداع واحد فبخاصية Batch Payments، بعد تفعيلها من Accounting ‣ Configuration ‣ Settings، قسم Customer Payments؛ وتُنشأ الدفعة المجمّعة من Vendors ‣ Batch Payments بتحديد Batch Type (Outbound للموردين) وBank وPayment Method — وكل دفعات الحزمة الواحدة بطريقة سداد واحدة — ثم Validate، فتُطابَق الحزمة كلها بمرجع واحد عند ظهور المبلغ الإجمالي في كشف البنك.

نقطتان ضريبيتان مصريتان على مسار السداد

ضريبة الخصم (الاستقطاع) تُبنى في Odoo كضريبة بمبلغ سالب: فالضريبة العادية تُحسب ضمن الإجمالي، أما ضريبة الاستقطاع فتُخصم من الدفعة نفسها مباشرة. تُنشأ من Accounting ‣ Configuration ‣ Taxes، وتُنسَب في تبويب Advanced Options إلى مجموعة ضريبية (Tax Group) للاستقطاع؛ فإن كانت نسبة من ضريبة أخرى، تُنشأ ضريبة يكون حقل Tax Computation فيها Group of Taxes وتضم الضريبتين معاً. ولتظهر على فواتير الموردين لا فواتير العملاء، يُضبط حقلها Tax Type على Purchase — الحقل الذي يحدد أين تُتاح الضريبة للاختيار. النسب المصرية لضريبة الخصم وإجراءات نموذج 41 في ضريبة الخصم ونموذج 41.

أما الفاتورة الإلكترونية التي يصدرها المورِّد، وأثرها على خصم تكلفة الشراء، فمسألة قانونية تخص مستند المورِّد نفسه لا إعداداً في تطبيق المشتريات؛ تفصيلها في الفاتورة الإلكترونية في مصر.

ما يترتب على المنشآت

• ضبط Control Policy على كل صنف عمداً والتحقق من افتراضيها على نموذج الصنف، خصوصاً الخدمات التي تُفوتَر افتراضياً على الكمية المطلوبة.
• تفعيل 3-way matching مع سياسة On received quantities حيث يجب أن ينتظر السداد استلاماً فعلياً لا مجرد تأكيد أمر.
• ضبط منتجات Landed Cost قبل أول شحنة تستوجبها، في فئات أصناف بطريقة تقييم AVCO أو FIFO.
• إنشاء ضريبة الاستقطاع بنوع Purchase قبل أول فاتورة تخضع لها.
• تسجيل دفعات الموردين بطريقة سداد الحزمة قبل تجميعها، إذ لا يُضاف إلى الحزمة إلا ما يطابق طريقتها.
• مطابقة عمود Received بالـPO مع المستلم فعلياً قبل اعتماد أي فاتورة مبنية على الكمية المطلوبة.

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

ويتولى قسم استشارات أنظمة ERP بالمكتب ضبط سياسات المراقبة ومنتجات التكاليف الإضافية وإعداد ضريبة الاستقطاع عند تطبيق Odoo لمنشآت مصرية.

محمود ناصف — محاسب قانوني، الشريك المؤسس

عضو جمعية المحاسبين والمراجعين المصرية
عضو جمعية الضرائب المصرية
عضو الجمعية المصرية للمالية العامة والضرائب

صفحة الشريك · حجز استشارة

تنويه: أُعدت هذه النشرة لأغراض العلم العام بالتشريع الساري في تاريخ نشرها، ولا تُشكّل رأياً مهنياً ولا استشارة ضريبية أو قانونية بشأن واقعة بعينها، ولا يجوز التعويل عليها بديلاً عن مشورة مبنية على فحص ظروف كل حالة على حدة. ولا تتحمل «ناصف وشركاه الدولية — محاسبون ومراجعون» مسؤولية عن أي تصرف اتُّخذ أو امتُنع عنه استناداً إلى ما ورد بها. وتظل الأحكام الواردة بها رهناً بما قد يصدر من تشريعات أو قرارات لاحقة.