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

ملخص

• الإصدار الحالي من Odoo هو 20.0 (صدر سبتمبر 2026)، ويحدد توثيقه دورة مبيعات من خمس مراحل: عرض السعر Quotation، أمر البيع Sales order، التسليم Delivery، الفاتورة Invoice، والتحصيل Payment.
• تاريخ انتهاء عرض السعر (Expiration) يُحسب تلقائياً من إعداد Default Quotation Validity أو من مدة قالب العرض، وقابل للتعديل قبل الإرسال؛ وزر Confirm يحوّل العرض إلى Sales Order.
• سياستا فوترة على مستوى الصنف: Ordered quantities فور تأكيد أمر البيع، وDelivered quantities بعد تسليم الكمية فعلياً ولو جزئياً.
• الدفعة المقدمة، نسبة أو مبلغ ثابت، تُنشأ من أمر البيع نفسه وتظهر بنداً مستقلاً على الفاتورة؛ والفاتورة المعتمدة لا تُعدَّل مباشرة: تُلغى أو تُرَدّ أو تُعدَّل في Odoo بإشعار خصم أو إضافة.
• فاتورة العميل تصل إلى منظومة المصلحة عبر وحدة l10n_eg_edi_eta المهيَّأة على يومية المبيعات؛ وبحسب ملاحظات إصدار 20.0 صار الإرسال جزءاً من معالج Send، وتُرسَل إيصالات البيع والمرتجع من نقطة البيع إلى المصلحة كإيصالات إلكترونية.
• ضبط الائتمان في التوثيق تحذير لا حظر: لا يمنع أي إعداد موثَّق إتمام بيع تجاوز حد العميل.

من عرض السعر إلى أمر البيع

عرض السعر يُنشأ من تطبيق Sales بحقل Expiration يحدد تاريخ انتهائه؛ ومعاينته بزر Preview، كما يراه العميل على بوابته، تُظهر تاريخ انتهائه بوضوح. التاريخ الافتراضي فيه يُؤخذ من إعداد Default Quotation Validity (أيام على مستوى الشركة، Sales ‣ Configuration ‣ Settings) أو من حقل Quotation Validity على القالب المستخدم، وقابل للتعديل قبل الإرسال. وبالضغط على Confirm تتحول الحالة إلى Sales Order، وهو التأكيد الذي يبدأ منه التسليم والفوترة؛ وإعداد Lock Confirmed Sales يقفل الأمر أمام أي تعديل بعده. ودورة المشتريات المقابلة، من طلب عرض السعر إلى السداد، موضوع دليل منفصل.

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

الإعداد الافتراضي لتطبيق Inventory تسليم بخطوة واحدة: يظهر زر Delivery بعد تأكيد أمر البيع ويفتح أمر التسليم، وتحرّك مصادقته (Validate) الصنف من المخزون إلى العميل مباشرة، وتتحدث كمية Delivered على أمر البيع تبعاً لذلك. ويوثّق Odoo أيضاً مسارين إضافيين بخطوتين وبثلاث خطوات (انتقاء ثم تعبئة ثم شحن) لمن يحتاج فصل هذه المراحل.

سياسة Delivered quantities تمنع تفعيل Automatic Invoicing (الفوترة التلقائية عند تأكيد دفعة إلكترونية). والصنف الجديد يأخذ السياسة المفعَّلة في الإعدادات تلقائياً، أما الأصناف القائمة فتُعدَّل يدوياً من تبويب General Information في نموذج الصنف.

الدفعة المقدمة

من نافذة Create invoice(s) بعد تأكيد أمر البيع، يُختار Down payment (percentage) أو Down payment (fixed amount)؛ تظهر الدفعة بنداً في مسودة الفاتورة، وبعد تأكيدها تُدرَج في قسم Down Payments على أسطر أمر البيع. ودفعة بنسبة 100% ليست سداداً كاملاً: يبقى زر Create Invoice ظاهراً لأن فاتورة ثانية لا تزال مطلوبة لإتمام الأمر. وحساب الإيراد المرتبط بالدفعة قابل للتغيير على المسودة فقط، ولا يمكن تعديله بعد الترحيل. وإن كانت سياسة الصنف Delivered quantities، فالدفعة المقدمة لا تُخصَم في الفاتورة النهائية قبل تسليم الصنف، لأن Odoo لا يسمح بفاتورة إجماليها سالب؛ وإن لم يُسلَّم شيء، يُنشأ إشعار خصم يُلغي مسودة الفاتورة التي أُنشئت بعد الدفعة المقدمة.

المرتجعات وإشعار الخصم

قبل الفوترة، يُعالَج المرتجع بتحويل إرجاع وحده (Reverse Transfer في التوثيق) يُنشأ بزر Return من أمر التسليم المرتبط بأمر البيع؛ وبعد تصديقه تتحدث كمية Delivered بالفرق، والفاتورة التالية لا تشمل إلا ما احتفظ به العميل. أما بعد الفوترة، فتحويل الإرجاع وحده لا يكفي لأن الفاتورة المعتمدة أو المرسلة لا تُعدَّل؛ فيُستخدَم مع Credit Note: من الفاتورة، زر Credit Note، بسبب ويومية وتاريخ عكس، ثم إما Reverse (مسودة قابلة للتعديل، تصلح لرد جزئي) أو Reverse and Create Invoice (يُعتمد ويُسوَّى تلقائياً مع الأصل، وتُفتح فاتورة مسودة جديدة). ويبدأ تسلسل إشعار الخصم بحرف R، وقيده قيد عكسي لقيد الفاتورة الأصلية؛ وبإشعار خصم أو إضافة تُلغى الفاتورة المعتمدة أو تُرَدّ أو تُعدَّل. وتذكر ملاحظات إصدار 20.0 أن معالج الإرجاع أُلغي والإجراء بُسِّط، بينما لا تزال صفحة المرتجعات في التوثيق تصف نافذة Reverse Transfer السابقة.

الفاتورة الإلكترونية وربطها بمنظومة المصلحة

فاتورة العميل الناتجة عن أمر البيع هي المستند الذي يمر عبر وحدة l10n_eg_edi_eta فوق حزمة التوطين الأساسية l10n_eg. ولكل فرع من فروع المنشأة يومية مبيعات (Type: Sales) خاصة به، بجهة اتصال من نوع Company مستوفاة العنوان والرقم الضريبي، وبإعدادي ETA Activity Code وETA Branch ID. وبيانات العميل والصنف (الرقم الضريبي، وباركود GS1 أو EGS أو ETA Item code) تُضبط قبل إصدار الفاتورة من أمر البيع لا بعده. وبحسب ملاحظات إصدار Odoo 20.0: صار اختيار نشاط الفرع بكوده ووصفه العربي معاً، وصار إرسال الفاتورة إلى المصلحة جزءاً من معالج Send بتنبيهات تحقق مسبق، مع وضع تجريبي (Demo Mode) لاختبار سير العمل داخلياً دون أي بيانات دخول، وتُرسَل إيصالات البيع والمرتجع من نقطة البيع إلى المصلحة كإيصالات إلكترونية؛ ولم تصل هذه التفاصيل بعد إلى صفحة التوطين المصري نفسها في التوثيق وقت الكتابة. وتفصيل الإلزام القانوني بالفاتورة الإلكترونية في الفاتورة الإلكترونية في مصر. وأخطاء إعداد هذا الربط وآلية التكامل الفني الكاملة مع منظومتي الفاتورة والإيصال موضوع دليلين منفصلين.

متابعة التحصيل والتسوية وضبط الائتمان

مستويات المتابعة (Follow-up Levels، من Accounting ‣ Configuration) تُطلَق بحسب أيام التأخر عن الاستحقاق، تلقائياً أو يدوياً، بالبريد الإلكتروني أو WhatsApp أو SMS أو خطاب بريدي؛ ومن نموذج العميل يُرسَل التذكير يدوياً بزر Send في قسم Invoice follow-ups، ويُستخرج له Customer Statement أو Follow-up Report، ولمجموعة عملاء دفعة واحدة بأمر Process Follow-ups من قائمة العملاء. وتذكر ملاحظات إصدار 20.0 أن سير التذكير التلقائي واليدوي بُسِّط، وأن التذكير صار متاحاً أيضاً بزر Send على نموذج الفاتورة نفسه، والتلقائي منه يُفعَّل ويُدار من إعدادات المحاسبة. وفي التسوية البنكية، إن لم توجد فاتورة بعد، يفتح إجراء Sales على الحركة أوامر بيع الشريك نفسه، فتُنشأ الفاتورة منها بأمر Create Invoices ثم تُسوَّى بإجراء Reconcile. وضبط الائتمان تحذير لا حظر: إعداد Sale Warnings يُظهر رسالة عن عميل أو صنف بعينه، وفي نقطة البيع حد ائتمان أقصى يجعل زر العميل برتقالياً بعلامة تحذير عند بلوغه، ولا يمنع إتمام البيع بنص التوثيق.

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

• ضبط Default Quotation Validity ومراجعة تاريخ Expiration على كل عرض قبل إرساله.
• اختيار سياسة الفوترة على كل صنف بما يطابق طريقة تسليمه فعلياً، لا بالافتراضي.
• تحديد حساب الإيراد على الدفعة المقدمة في المسودة، إذ يتعذر تعديله بعد الترحيل.
• معالجة أي مرتجع بعد الفوترة بتحويل إرجاع من أمر التسليم مع Credit Note معاً، وعدم لمس الفاتورة المعتمدة مباشرة.
• تجهيز يومية مبيعات مستقلة بإعدادات ETA لكل فرع، بكود ووصف عربي للنشاط، والتحقق من بيانات العميل والصنف قبل أول فاتورة.
• ضبط Follow-up Levels وتسوية الحركات البنكية أولاً بأول، حتى لا يُرسَل تذكير عن فاتورة سُدِّدت.

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

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

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

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

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