مكتبة الأخطاء الشائعة 🩺

السبب

المنتج غالباً مش متعلّم إنه قابل للبيع، أو متأرشف، أو تابع لشركة غير شركة أمر البيع. وفي الحالات دي البحث في السطر بيتجاهله.

الحل

1. افتح كارت المنتج وتأكد إن خيار البيع متعلّم (Can be Sold / Sales) وإن المنتج مش Archived.
2. راجع حقل Company على المنتج: لو متحدد لشركة معينة لازم تكون هي نفس شركة أمر البيع، أو سيبه فاضي لو المنتج مشترك.
3. لو المنتج ليه Variants، اتأكد إن الـ Variant المطلوب مش متأرشف وإن قيم الـ Attributes بتاعته موجودة.
4. جرّب تدوّر بالـ Internal Reference أو الاسم الكامل، ولو لسه مش ظاهر استخدم Search More في القائمة المنسدلة وامسح الفلاتر.

إزاي ما تتكررش

اعمل Checklist ثابتة لإنشاء أي منتج (النوع، قابل للبيع، الشركة، وحدة القياس) قبل ما يتحط في أي Quotation.

السبب

الـ Pricelist المختارة على الأمر بتدوّر على قاعدة (Rule) تطابق المنتج والكمية الدنيا وتاريخ الصلاحية. لو ملقتش قاعدة مطابقة، Odoo بيرجع لسعر البيع الأساسي على كارت المنتج.

الحل

1. تأكد إن الـ Pricelist المطلوبة مختارة فعلاً على أمر البيع نفسه (مش بس على كارت العميل) وإن عملتها هي عملة الأمر.
2. افتح الـ Pricelist وراجع القاعدة: المنتج أو فئة المنتج صح، والـ Min. Quantity أقل من أو تساوي كمية السطر، وتواريخ البداية والنهاية سارية.
3. لو غيّرت الـ Pricelist بعد ما السطور اتضافت، حدّث الأسعار على الأمر أو امسح السطر وضيفه من جديد.
4. اربط الـ Pricelist بكارت العميل علشان تتختار تلقائي في أي أمر جديد.

إزاي ما تتكررش

حدد Pricelist افتراضية لكل عميل، واكتب تواريخ صلاحية واضحة للقواعد، وسيب قاعدة عامة تغطي باقي المنتجات.

السبب

كمية الفاتورة بتتحدد من Invoicing Policy على المنتج: Ordered quantities بتفوتر الكمية المطلوبة كلها، و Delivered quantities بتفوتر اللي اتسلّم بس. وأي فاتورة أو Down Payment قبل كده بتقلل الكمية المتبقية للفوترة.

الحل

1. افتح سطر أمر البيع وقارن Ordered و Delivered و Invoiced؛ ده بيوضّح الكمية جت منين.
2. افتح كارت المنتج وراجع Invoicing Policy، ولو عايز تفوتر المطلوب قبل التسليم خليها Ordered quantities.
3. لو الفاتورة لسه Draft، عدّل الكمية على سطر الفاتورة مباشرة. ولو اتعملها Post اعمل Credit Note وبعدها فاتورة صح.
4. راجع إن مفيش فاتورة تانية على نفس الأمر أخدت جزء من الكمية.

إزاي ما تتكررش

حدد سياسة الفوترة لكل نوع منتج من البداية، وراجع عمود Qty to Invoice قبل ما تضغط Create Invoice.

السبب

كل سطور الأمر كمية الفوترة فيها صفر. يا إما السياسة Delivered quantities ولسه مفيش تسليم اتأكد، يا إما كل الكمية اتفوترت قبل كده.

الحل

1. شوف Invoice Status على الأمر وعمود Qty to Invoice في السطور.
2. لو السياسة Delivered quantities: سلّم البضاعة (Validate للتسليم) وبعدها اعمل الفاتورة. وفي الخدمات راجع إزاي الكمية المسلّمة بتتسجل (يدوي أو من Timesheets).
3. لو عايز تفوتر قبل التسليم: غيّر سياسة المنتج لـ Ordered quantities، أو اعمل Down Payment.
4. لو الأمر اتفوتر بالكامل فعلاً، افتح الفواتير المرتبطة بدل ما تعمل فاتورة جديدة.

إزاي ما تتكررش

اختار سياسة الفوترة الصح للمنتج قبل أول بيع، وخلّي المخازن تعمل Validate للتسليم قبل ما المحاسب يفوتر.

السبب

الأمر المؤكد مربوط بتسليم وفاتورة، فـ Odoo بيمنع مسحه إلا بعد ما يتلغي. والإلغاء نفسه بيتعطّل لو فيه تسليم Done أو فاتورة Posted لأنهم أثّروا على المخزون والحسابات.

الحل

1. اعمل Cancel للأمر الأول؛ المسح بيتم بس على أمر ملغي أو في المسودة.
2. لو فيه تسليم Done: اعمل Return للتسليم علشان الكمية ترجع للمخزون.
3. لو فيه فاتورة Posted: اعمل Credit Note (Reverse) على الفاتورة بدل ما تحاول تمسحها.
4. بعد ما كل المستندات المرتبطة تتلغي أو تتعكس الغي الأمر. ولو التعديل بسيط (كمية أو سعر) عدّل على الأمر نفسه لو لسه مفتوح بدل الإلغاء.

إزاي ما تتكررش

ما تأكدش الأمر إلا بعد موافقة العميل، واستخدم Quotation للمسودات والتعديلات.

السبب

أمر التسليم بيتولّد بس للمنتجات الفعلية، والمنتجات من نوع Service ما بتعملش تسليم. وكمان لازم تطبيق Inventory يكون متثبّت والـ Warehouse عليه Route للتسليم.

الحل

1. اتأكد إن تطبيق Inventory متثبّت، لأن من غيره أمر البيع مش هيولّد تسليم.
2. افتح كل منتج في سطور الأمر وتأكد إنه منتج فعلي مش Service.
3. راجع الـ Warehouse على أمر البيع وإن Route التسليم بتاعه شغّال.
4. دوّر في Inventory على التحويلات (Transfers) بمرجع الأمر في Source Document، يمكن التسليم اتعمل واتلغى.

إزاي ما تتكررش

حدد نوع المنتج صح (خدمة ولا منتج فعلي) وقت إنشاءه، وجرّب أمر تجريبي على أي منتج جديد قبل الـ Go-live.

السبب

الضريبة بتتحمّل تلقائي من Customer Taxes على المنتج، وممكن الـ Fiscal Position بتاعة العميل تبدّلها. لو الحقل فاضي أو الـ Fiscal Position بتحوّلها، السطر بيطلع من غير ضريبة أو بضريبة تانية.

الحل

1. افتح المنتج وراجع Customer Taxes: لازم تكون ضريبة المبيعات الصح (VAT حسب الدولة) وتابعة لنفس شركة الأمر.
2. افتح كارت العميل وراجع الـ Fiscal Position، ولو متحددة راجع قواعد استبدال الضرايب (Tax Mapping) جواها.
3. راجع الـ Fiscal Position المتسجلة على الأمر نفسه وعدّلها لو غلط.
4. السطور اللي اتعملت قبل التعديل امسحها وضيفها تاني علشان تاخد الضريبة الجديدة.

إزاي ما تتكررش

اضبط Customer Taxes أول ما تعمل أي منتج جديد، وجرّب فاتورة تجريبية لكل Fiscal Position قبل الـ Go-live.

السبب

في بيئة أكتر من شركة، كل سجل (عميل، منتج، Pricelist، Warehouse، ضريبة) ممكن يتربط بشركة معينة. لو الأمر تابع لشركة A وفيه سجل تابع لشركة B، Odoo بيرفض بسبب فحص توافق الشركات.

الحل

1. اقرا نص الخطأ كله: بيسمّي السجل والحقل اللي تابع لشركة تانية.
2. افتح السجل ده وراجع حقل Company: سيبه فاضي (مشترك) لو ده المقصود، أو استبدله بسجل تابع لشركة الأمر.
3. راجع الشركات المفعّلة في مبدّل الشركات أعلى الشاشة وإن الشركة الحالية هي المقصودة.
4. راجع Warehouse و Pricelist والضرائب على الأمر: لازم كلها تبع نفس الشركة.

إزاي ما تتكررش

قرر لكل نوع سجل (منتجات، عملاء، ضرائب) هو مشترك ولا خاص بشركة، وطبّق القرار وقت الإنشاء.

السبب

الاستلام بيتولّد بس من أمر شراء مؤكد (مش RFQ) فيه منتجات فعلية، وسطور الخدمات ما بتعملش استلام. وكمان لازم Inventory يكون متثبّت وفيه Operation Type للاستلام مربوط بالـ Warehouse.

الحل

1. اتأكد إن حالة الأمر Purchase Order مش RFQ أو RFQ Sent (يعني اتضغط Confirm Order).
2. افتح سطور الأمر وتأكد إن المنتجات فعلية مش Service.
3. راجع حقل Deliver To على الأمر: لازم يكون استلام (Receipts) لـ Warehouse صحيح.
4. لو الاستلام موجود بس مش باين، دوّر عليه في Inventory بمرجع الأمر في Source Document وشوف لو اتلغى.

إزاي ما تتكررش

راجع نوع المنتج وحقل Deliver To قبل التأكيد، وبعد Confirm Order اتأكد دايماً إن زرار Receipt ظهر.

السبب

السعر بيتجاب من قائمة Vendors في تبويب Purchase على المنتج، بعد فلترة بالمورد والكمية الدنيا والتاريخ والعملة والـ Variant. لو مفيش سطر مطابق بيطلع سعر مختلف عن المتوقع (زي تكلفة المنتج أو صفر).

الحل

1. افتح المنتج وتبويب Purchase وتأكد إن المورد مضاف في Vendors بسعره.
2. راجع الكمية الدنيا في سطر المورد: لازم تكون أقل من أو تساوي كمية أمر الشراء.
3. راجع تواريخ الصلاحية والعملة، وإن الـ Variant المقصود (لو فيه) هو اللي في سطر المورد.
4. لو المورد على الأمر غلط، صحّحه وامسح السطر وضيفه تاني علشان السعر يتحدّث.

إزاي ما تتكررش

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

السبب

المنتج عليه سياسة تحكم (Control Policy) في تبويب Purchase: On received quantities بتمنع الفاتورة لحد ما الاستلام يتسجّل، و On ordered quantities بتسمح بالفاتورة قبل الاستلام.

الحل

1. شوف حالة الاستلام على الأمر: لو لسه ما اتعملش Validate، اعمله بالكمية المستلمة فعلاً.
2. لو محتاج الفاتورة قبل الاستلام (دفعة مقدمة مثلاً)، غيّر سياسة المنتج لـ On ordered quantities.
3. لو الأمر لسه RFQ، أكّده الأول.
4. راجع إن الكمية كلها مش اتفوترت قبل كده في فاتورة تانية.

إزاي ما تتكررش

اتفقوا في الشركة على سياسة التحكم لكل نوع منتج، وحطوها على مستوى الفئة لو الإعداد بيسمح.

السبب

Odoo بيمنع إلغاء أمر شراء اتعمله استلام Done أو فاتورة مورد، علشان المخزون والحسابات ما يتعارضوش مع الأمر.

الحل

1. لو الرسالة عن الاستلام: افتح الاستلام الـ Done واعمل Return بنفس الكمية.
2. لو الرسالة عن الفاتورة: الغي فاتورة المورد لو لسه Draft، أو اعمل Credit Note (Reverse) لو اتعملها Post.
3. بعد ما الاستلامات والفواتير تتلغي أو تتعكس ارجع الغي الأمر.
4. لو الهدف تعديل كمية بس، اعمل Return جزئي وصحّح الفاتورة بدل إلغاء الأمر كله.

إزاي ما تتكررش

الغي أو عدّل الأمر قبل الاستلام والفوترة، وبعدهم اشتغل بالـ Return والـ Credit Note.

السبب

الـ Route شغّال على Buy، بس Odoo ملقاش سطر مورد صالح للمنتج يحدد منه المورد والسعر. يا إما مفيش مورد، يا إما الكمية المطلوبة أقل من الكمية الدنيا عند المورد، يا إما التواريخ منتهية.

الحل

1. افتح المنتج وتبويب Purchase وضيف مورد بسعره.
2. قارن الكمية الدنيا عند المورد بكمية الطلب اللي القاعدة بتطلبها، وعدّل واحد منهم.
3. راجع تواريخ سطر المورد والعملة، وإنه تابع لنفس شركة القاعدة.
4. شغّل Replenish تاني بعد التصحيح وراجع الـ RFQ اللي اتولّد.

إزاي ما تتكررش

ما تفعّلش Reordering Rule لمنتج قبل ما تضيف له مورد معتمد وكمية دنيا منطقية.

السبب

Odoo بيحجز الكمية من الـ Source Location بتاع التسليم. لو مفيش كمية متاحة هناك (أو الكمية في موقع أو Lot تاني) الحجز بيفشل والتسليم بيفضل Waiting، ومن غير حجز أو كمية معمولة الـ Validate بيترفض.

الحل

1. اضغط Check Availability وافتح Detailed Operations علشان تشوف إيه اللي اتحجز وإيه الناقص.
2. افتح On Hand للمنتج وتأكد إن الكمية موجودة فعلاً في الموقع المصدر للتسليم (مش في موقع أو Warehouse تاني).
3. لو الكمية مش موجودة فعلاً: سجّل الاستلام. ولو موجودة على الرف بس مش في Odoo اعمل Inventory Adjustment.
4. لو الكمية موجودة والحجز لسه فاشل، شوف إن المنتج مش محجوز لتحويلات تانية واعمل Unreserve عليها لو لزم.

إزاي ما تتكررش

اتأكد من الرصيد في الموقع الصحيح قبل تأكيد أمر البيع، وسجّل كل استلام في Odoo قبل ما البضاعة تتحرك.

السبب

On Hand بتتحسب من الحركات المسجّلة مش من اللي على الرف، فأي استلام أو تسليم اتنسى أو اتسجّل بوحدة قياس غلط بيعمل فرق. وكمان Available هي On Hand ناقص المحجوز، والرقم بيتغير حسب الـ Warehouse أو الـ Location المتفلتر عليه.

الحل

1. اتأكد إنك بتقارن بنفس الـ Warehouse أو الـ Location اللي حصل فيه الجرد.
2. افتح سجل حركات المنتج (Moves History) علشان تعرف أي حركة ناقصة أو مكررة أو بوحدة غلط.
3. لو الفرق حقيقي: اعمل Physical Inventory واكتب الكمية المعدودة (Counted Quantity) وبعدين Apply.
4. سجّل سبب التسوية (Inventory Reference / Reason) علشان الفرق يتراجع عليه محاسبياً.

إزاي ما تتكررش

اعمل جرد دوري، وما تسمحش بحركة بضاعة من غير تسجيل في Odoo، وسجّل أي تالف عن طريق Scrap.

السبب

المنتج معمول له تتبّع (Tracking) بـ Lot أو Serial، فكل حركة ليه لازم يتسجّل عليها رقم. وفي الـ Serial لازم رقم مختلف لكل وحدة.

الحل

1. افتح Detailed Operations على سطر المنتج وسجّل رقم الـ Lot/Serial لكل كمية.
2. في الاستلام اكتب الأرقام أو ولّدها أو استوردها، وفي التسليم اختار Lot موجود فعلاً في المخزون.
3. لو المنتج ما كانش المفروض يتتبّع، عدّل التتبّع على كارت المنتج (والأفضل قبل ما تتعمل عليه حركات).
4. لو بتحمّل رصيد افتتاحي لمنتج متتبّع، حدد الأرقام وقت الـ Inventory Adjustment.

إزاي ما تتكررش

قرر نوع التتبّع (Lot / Serial / بدون) وقت تعريف المنتج، واتفق مع المورد على إنه يبعت الأرقام مع الشحنة.

السبب

الحركة اللي اتأكدت أثّرت فعلاً على الكميات وعلى القيد المحاسبي، فـ Odoo بيمنع إلغاءها ويطلب منك تعمل حركة عكسية بدلها.

الحل

1. افتح التسليم أو الاستلام الـ Done واضغط Return.
2. في نافذة الـ Return حدد الكميات اللي هتتعكس وأكّد علشان يتولّد تحويل عكسي.
3. اعمل Validate للتحويل العكسي، كده المخزون والقيود بيتعدلوا.
4. لو الغلط كان خطأ في تسجيل الكمية مش بضاعة راجعة فعلاً، اعمل Inventory Adjustment وسجّل السبب.

إزاي ما تتكررش

راجع الكميات قبل ما تضغط Validate، لأن بعدها مفيش رجوع غير بحركة عكسية.

السبب

المنتج مفيهوش Route (زي Buy أو Manufacture) تغطّي الموقع المطلوب، أو الـ Route مش شغّال على الـ Warehouse. فـ Odoo معرفش يولّد أمر شراء أو تصنيع.

الحل

1. افتح المنتج وضيف Route مناسب: Buy للمشتريات أو Manufacture للتصنيع.
2. اتأكد إن الـ Route شغّال على الـ Warehouse وبيخدم الموقع المكتوب في الرسالة.
3. راجع إن الموقع في Reordering Rule أو في الطلب تابع للـ Warehouse الصحيح.
4. لو تطبيق Purchase أو Manufacturing مش متثبّت، ثبّته الأول علشان الـ Route يظهر.

إزاي ما تتكررش

اضبط الـ Routes على فئة المنتج (Product Category) لو الإعداد بيسمح، علشان أي منتج جديد يرثها.

السبب

التحويلات بتحجز الكمية أول ما تتأكد، وبتفضل محجوزة لحد ما تتسلّم أو تتلغي أو يتعمل لها Unreserve. فالمنتج بيبان في On Hand بس مش Available لأمر جديد.

الحل

1. افتح المنتج وشوف الكمية المحجوزة (Reserved) واعرف أنهي تحويلات ماسكاها.
2. افتح التحويل اللي مش محتاجه واضغط Unreserve، أو الغيه لو ملوش لازمة.
3. ارجع للتحويل الجديد واضغط Check Availability علشان يحجز الكمية.
4. لو لازم أمر معين ياخد الأولوية، حدد أولوية التحويلات (Priority) وجدول التسليمات.

إزاي ما تتكررش

راجع التحويلات المعلقة (Ready من زمان) بشكل دوري وألغي أو سلّم اللي مالوش لازمة.

السبب

لما الكمية المعمولة (Done) تبقى أقل من الطلب، Odoo بيسألك: تعمل Backorder للباقي (تحويل جديد) ولا No Backorder فيتلغي الباقي.

الحل

1. قبل Validate راجع عمود الكمية المعمولة، وكمّله لو المفروض تسلّم الكل.
2. لما السؤال يظهر: اختار Create Backorder لو الباقي هيتسلّم بعدين، و No Backorder لو الباقي مش هيتسلّم.
3. لو اخترت Backorder بالغلط ومش محتاجه: افتح الـ Backorder واضغط Cancel.
4. لو اخترت No Backorder بالغلط، الباقي اتلغى. اعمل تحويل جديد بالكمية الباقية وحط مرجع الأمر في Source Document.

إزاي ما تتكررش

اتفقوا في الشركة على سياسة التسليم الجزئي، وفهّم الفريق الفرق بين الاختيارين قبل الضغط.

السبب

أمر التصنيع (MO) بيحجز المكونات من الـ BoM من الموقع المصدر بتاع عملية التصنيع. لو مكوّن واحد مش متاح هناك، الـ MO بيفضل Confirmed ومبيبقاش Ready.

الحل

1. افتح سطور Components في الـ MO وشوف أنهي مكوّن ناقص أو غير محجوز.
2. وفّر الكمية (استلام شراء أو Inventory Adjustment لو موجودة فعلاً) وبعدين اضغط Check Availability.
3. لو المكوّن موجود في موقع أو Warehouse تاني، اعمل Internal Transfer ليه للموقع المصدر للتصنيع.
4. لو لازم تبدأ بالمتاح، قلل الكمية المطلوب إنتاجها على الـ MO علشان تتناسب مع أقل مكوّن.

إزاي ما تتكررش

فعّل Reordering Rules للخامات الأساسية، وراجع توفر الخامات قبل ما تأكد الـ MO.

السبب

الـ MO بيختار الـ BoM تلقائي حسب المنتج والـ Variant والشركة. لو مفيش BoM مطابق أو فيه أكتر من واحد، المكونات بتطلع فاضية أو من BoM مش المقصود.

الحل

1. افتح المنتج وزرار Bill of Materials وتأكد إن فيه BoM نوعه Manufacture this product ومش Archived.
2. راجع الـ Variants على الـ BoM إنها بتطابق المنتج اللي بتصنّعه.
3. على الـ MO وهو لسه Draft، اختار الـ BoM الصح في حقل Bill of Material والمكونات هتتحدّث.
4. لو فيه أكتر من BoM لنفس المنتج، رتّبهم بالـ Sequence أو أرشف القديم.

إزاي ما تتكررش

ما تأكدش MO جديد قبل ما تراجع الـ BoM، وأرشف القوائم القديمة لما الوصفة تتغير.

السبب

المحاسبة عندها تاريخ قفل (Lock Date) على الشركة، وأي قيد أو فاتورة تاريخها قبله أو عليه Odoo بيرفض يرحّلها أو يعدّلها عشان الفترة اتقفلت رسمياً.

الحل

1. اتأكد الأول إن التاريخ على الفاتورة (Invoice/Accounting Date) مش غلطة كتابة، وغيّره لتاريخ في فترة مفتوحة لو ده المقبول عند المحاسب الأول.
2. لو لازم فعلاً تسجّل في الفترة المقفولة، مستخدم بصلاحية Adviser (مدير المحاسبة) يفتح الفترة بتغيير Lock Date من إعدادات المحاسبة بموافقة المحاسب الأول.
3. رحّل الفاتورة، وبعدها رجّع Lock Date لقيمته الأصلية على طول.

إزاي ما تتكررش

اتفق مع المحاسب الأول على سياسة قفل الفترات، وماتقفلش الشهر قبل ما كل الفواتير والمصاريف بتاعته تتسجل.

السبب

Odoo بيشيك إن مجموع المدين (Debit) = مجموع الدائن (Credit) في القيد الواحد. الفرق غالباً من سطر ناقص أو مبلغ مكتوب غلط، أو من سطور القيد الواحد اتقسمت في أكتر من ملف عند الاستيراد.

الحل

1. افتح القيد وقارن إجمالي Debit بإجمالي Credit، وحدد قيمة الفرق.
2. ضيف السطر الناقص أو صحّح المبلغ الغلط على الحساب المناسب لحد ما الفرق يبقى صفر.
3. لو القيد جاي من استيراد: اتأكد إن كل سطور القيد الواحد في نفس الملف وبنفس المرجع (Reference)، وإن مفيش تقريب أو عملة بتغيّر المبالغ.

إزاي ما تتكررش

قبل أي استيراد قيود، اعمل Test الأول، وراجع إن كل قيد متوازن في الملف نفسه قبل الاستيراد الفعلي.

السبب

Odoo بيمنع ترحيل قيد غير متوازن، فالفرق الحقيقي نادر. الأغلب إنه اختلاف في الفلاتر (Posted مقابل All Entries، فترة، Journals، شركات)، أو قيود Draft، أو رصيد افتتاحي اتسجل غلط، أو بيانات اتعدّلت بكود أو SQL من برّه Odoo.

الحل

1. وحّد الفلاتر في كل التقارير اللي بتقارن بينها: نفس الفترة، نفس الشركات، Posted Entries بس.
2. دوّر على قيود Draft في الفترة، وكمان على رصيد افتتاحي اتسجل في قيد منفصل ومش متوازن.
3. اعرض Journal Items مجمّعة بـ Journal Entry وقارن المدين والدائن لكل قيد لحد ما تلاقي القيد اللي مش متوازن.
4. لو لقيت قيد مش متوازن فعلاً، ما تصلّحوش بنفسك على الإنتاج: بلّغ المطوّر الأول لأن السبب غالباً كود مخصص أو استيراد بالـ SQL.

إزاي ما تتكررش

ما تعدّلش قيود بـ SQL أو سكربتات على الإنتاج، وراجع ميزان المراجعة بعد أي استيراد أو ترقية.

السبب

لما الدفعة تتسجل على Journal بنكي، الفاتورة بتتقفل على الحساب المعلّق وبتفضل In Payment لحد ما كشف الحساب البنكي يتطابق (Reconcile) مع الدفعة. وفي حالة تانية الدفعة نفسها لسه Draft مش Posted.

الحل

1. افتح الدفعة (Payment) وتأكد إنها Posted مش Draft.
2. لو حالتها In Payment: سجّل أو استورد سطر كشف الحساب البنكي وطابقه (Reconcile) مع الدفعة.
3. لو الدفعة اتسجلت على Journal غلط (بنك بدل كاش مثلاً)، الغيها وسجّلها على الـ Journal الصح.
4. لو الحالة Partial: المبلغ المدفوع أقل من إجمالي الفاتورة، كمّل الباقي.

إزاي ما تتكررش

اختار Journal الدفع الصح من البداية (Cash أو Bank)، وخلّي المطابقة البنكية دورية بدل ما تتراكم.

السبب

الجهة الضريبية بترفض الفاتورة لو بيانات فيها مش مطابقة لمتطلباتها: بيانات العميل أو الشركة (الرقم الضريبي والعنوان)، أو أكواد الأصناف ووحدات القياس، أو الضرايب.

الحل

1. افتح الفاتورة واقرا رد الجهة وسبب الرفض بالظبط (من حالة الإرسال أو الـ chatter) قبل أي تعديل.
2. صلّح البيانات من المصدر (العميل أو المنتج أو الضريبة أو إعدادات الشركة) مش في الفاتورة بس.
3. أعد الإرسال. ولو الفاتورة اتقبلت قبل كده وفيها غلط، ما تعدّلهاش: اعمل Credit Note أو إلغاء حسب قواعد الجهة.
4. جرّب الحالة الجديدة على بيئة الاختبار بتاعة الجهة قبل الإنتاج.

إزاي ما تتكررش

جهّز بيانات العملاء والأصناف (الرقم الضريبي، أكواد الأصناف، وحدات القياس) قبل أول فاتورة، وجرّب على بيئة الاختبار.

السبب

الـ Payslip بيتحسب من بيانات العقد (Contract) والـ Salary Structure وقواعدها، ومن أيام العمل (Work Entries والإجازات) والمدخلات الإضافية. أي حاجة من دول غلط بتطلّع رقم غلط.

الحل

1. افتح الـ Payslip وراجع تبويب Worked Days: عدد الأيام والساعات والإجازات صح ولا لأ.
2. افتح Salary Computation وشوف أنهي Rule طلع منها الرقم الغلط، وراجع المدخلات الإضافية (Other Inputs) لو فيه.
3. راجع العقد: الأجر، الـ Salary Structure، وتواريخ البداية والنهاية.
4. صلّح اللي لقيته وبعدها اعمل Compute Sheet تاني والـ Payslip لسه Draft.

إزاي ما تتكررش

بعد أي تعديل في Salary Rules أو العقود، جرّب Payslip لموظف من كل فئة قبل ما تولّد الرواتب كلها.

السبب

لازم كل الـ Work Entries في الفترة تتأكد (Validated) قبل ما الـ Payslip يتولّد. الـ Conflict بيحصل لما وقتين يتداخلوا (إجازة مع حضور مثلاً)، أو يبقى فيه وقت من غير عقد ساري، أو من غير نوع شغل.

الحل

1. اتأكد إن عقد الموظف Running وتاريخه بيغطي الفترة كلها.
2. افتح الـ Work Entries للموظف والفترة وفلتر على Conflicts.
3. حل كل Conflict: عدّل الوقت أو النوع، أو احذف المتداخل. ولو السبب جدول عمل أو عقد غلط، صلّحه وولّد الـ Work Entries تاني للفترة.
4. بعد ما كلها تبقى Validated ولّد الـ Payslip.

إزاي ما تتكررش

جدّد العقود قبل ما تخلص، وراجع الـ Work Entries في آخر كل شهر قبل يوم توليد الرواتب.

السبب

نوع الإجازة معرّف إنه محتاج رصيد (Allocation)، والموظف مالوش رصيد معتمد يغطي الأيام المطلوبة، أو رصيده محجوز في طلبات إجازة لسه مستنية موافقة.

الحل

1. افتح رصيد الموظف في نوع الإجازة ده وشوف الأيام المتاحة وأي طلبات لسه Waiting for validation.
2. لو الرصيد فعلاً ناقص: اعمل Allocation للموظف واعتمدها، أو راجع الـ Accrual Plan وتاريخ بدايته.
3. لو نوع الإجازة ده المفروض من غير حد (زي إجازة مرضي بدون رصيد)، اظبط نوع الإجازة على No Limit.

إزاي ما تتكررش

حدّد من الأول أنهي أنواع الإجازات ليها رصيد وأنهي من غير حد، وولّد الأرصدة السنوية قبل أول السنة.

السبب

الموظف عنده سجل حضور مفتوح من غير Check-out، فـ Odoo مش بيسمح بسجل جديد قبل ما السجل القديم يتقفل.

الحل

1. افتح سجلات الحضور (Attendances) وفلتر على الموظف والسجلات اللي من غير Check Out.
2. مسؤول HR يكتب وقت الـ Check Out الصح يدوياً على السجل المفتوح.
3. الموظف يعمل Check-in تاني وهيشتغل عادي.

إزاي ما تتكررش

نبّه الموظفين يعملوا Check-out كل يوم، وشوف لو الإصدار بتاعك فيه خيار خروج تلقائي.

السبب

المصروف بيتربط بالمشروع عن طريق الحساب التحليلي (Analytic Distribution) على سطر المصروف، ومش بيتحسب في تكلفة المشروع إلا بعد ما يتعمله قيد مرحّل (Posted).

الحل

1. افتح سطر المصروف وتأكد إن الـ Analytic Distribution فيها الحساب التحليلي بتاع المشروع. ولو الحقل مش ظاهر، فعّل Analytic Accounting من إعدادات المحاسبة.
2. افتح المشروع وتأكد إن عنده Analytic Account وإنه نفس اللي في سطر المصروف.
3. تأكد إن تقرير المصروفات (Expense Report) اتقدّم واتعتمد واتعمله Post للقيد.
4. بعد الـ Post راجع لوحة ربحية/تكلفة المشروع (Profitability) تاني.

إزاي ما تتكررش

اعمل قاعدة توزيع تحليلي افتراضية (Analytic Distribution Model) وخلّي الموظفين يختاروا المشروع من أول سطر المصروف.

السبب

تسجيل الساعات محتاج المشروع يكون مفعّل عليه Timesheets، واليوزر يكون مربوط بسجل موظف (Employee) وعنده صلاحية Timesheets، والمهمة تكون جوه مشروع.

الحل

1. افتح المشروع وفعّل خيار Timesheets عليه.
2. اتأكد إن اليوزر مربوط بسجل موظف (Employee) في نفس الشركة.
3. اتأكد إن اليوزر معاه صلاحية Timesheets، على الأقل User: own timesheets only.
4. اتأكد إن المهمة جوه مشروع، لأن المهام الخاصة (من غير مشروع) مبتدّيش تسجيل ساعات.

إزاي ما تتكررش

لما تعمل يوزر جديد، اربطه بسجل موظف وادّيه صلاحية Timesheets من أول يوم، وفعّل Timesheets على المشاريع اللي محتاجاها.

السبب

الساعات بتتحول لكمية مسلّمة (Delivered) بس لو سطر أمر البيع (Sales Order Item) مربوط بالمهمة أو المشروع، وسياسة الفوترة للمنتج Based on Timesheets. لو الربط فاضي، الساعات بتفضل غير قابلة للفوترة.

الحل

1. افتح سطر الـ Timesheet وبص على حقل Sales Order Item، لو فاضي يبقى ده السبب.
2. على المهمة أو المشروع، اختار الـ Sales Order Item الصح.
3. راجع منتج الخدمة: سياسة الفوترة Based on Timesheets، وإعداد Service Tracking يعمل مشروع أو مهمة من أمر البيع.
4. ارجع لأمر البيع وتأكد إن Delivered اتحدّثت، وبعدها اعمل Create Invoice.

إزاي ما تتكررش

استخدم منتج خدمة بـ Service Tracking بيعمل المشروع أو المهمة تلقائي من أمر البيع بدل الربط اليدوي.

السبب

اليوزر مش في أي Group بيدّي Access Rights على الموديل ده للعملية المطلوبة (قراءة أو تعديل أو إنشاء أو حذف). والرسالة نفسها بتكتب الـ Groups اللي مسموح لها.

الحل

1. اقرا الرسالة كويس: فيها اسم الموديل والعملية وقايمة الـ Groups المسموحة.
2. من بطاقة اليوزر، ادّيه الـ Access Level المناسب في التطبيق المعني، من غير ما تديه Administration إلا لو لازم.
3. اطلع وادخل تاني (Logout/Login) وجرّب العملية.
4. لو الموديل مخصص (Custom): راجع ملف ir.model.access.csv في الموديول.

إزاي ما تتكررش

وثّق الـ Groups لكل وظيفة، وجرّب كل دور بيوزر تجريبي قبل الـ Go-live.

السبب

الـ Access Rights سليمة، لكن الـ Record Rules (زي Own Documents Only أو قيود الشركة والفريق) بتمنع السجل ده بالذات.

الحل

1. من الرسالة اعرف الموديل والعملية اللي اتمنعت.
2. راجع مستوى الـ Access بتاع اليوزر في التطبيق (مثلاً Own Documents Only مقابل All Documents) وارفعه لو ده المطلوب فعلاً.
3. لو السجل تابع لشركة تانية: ضيف الشركة في Allowed Companies لليوزر، وفعّلها من مبدّل الشركات.
4. لو فيه Record Rule مخصصة: راجعها في Developer Mode في قسم Technical.

إزاي ما تتكررش

وثّق الـ Record Rules المخصصة، وجرّب الدور بسجلات من فريق أو شركة تانية قبل التسليم.

السبب

السجل مربوط بحقول (عميل أو منتج أو مخزن أو حساب) تابعة لشركة غير شركة السجل نفسه، و Odoo بيمنع الخلط ده في الـ Multi-company.

الحل

1. اقرا الرسالة: بتقول السجل واسم الحقل اللي تابع لشركة تانية.
2. اتأكد إن الشركة النشطة في مبدّل الشركات هي اللي المفروض تشتغل بيها.
3. غيّر القيمة لحاجة تابعة لنفس الشركة، أو خلّي حقل Company فاضي في البيانات المشتركة (عميل أو منتج) عشان تبقى مشتركة بين الشركات.
4. لو ده جاي من استيراد، حط الشركة الصح في الملف.

إزاي ما تتكررش

قرّر من الأول أنهي بيانات مشتركة (منتجات وعملاء) وأنهي مفصولة لكل شركة، وسيب Company فاضي في المشترك.

السبب

الـ Login أو الباسورد غلط، أو الـ Login مش هو الإيميل اللي المستخدم فاكره، أو بيدخل على Database غلط، أو اليوزر مؤرشف (Archived).

الحل

1. اتأكد من الـ Login المكتوب في بطاقة اليوزر لأنه ممكن يختلف عن الإيميل، واتأكد مفيش مسافة زيادة.
2. لو الشركة عندها أكتر من Database، اتأكد إنه بيدخل على الصح.
3. الأدمن يبعت Password Reset أو يحط باسورد جديد من بطاقة اليوزر. ومتنساش إن إرسال الريست بيحتاج الإيميل الصادر يكون شغال.
4. اتأكد إن اليوزر Active مش Archived.

إزاي ما تتكررش

استخدم Reset Password بدل مشاركة الباسورد، وخلّي إيميل الأدمن بتاع النظام شغال.

السبب

الإيميل بيتحط في طابور (Outgoing) وبيتبعت عن طريق Scheduled Action وOutgoing Mail Server. لو السيرفر مش متظبط أو الـ Scheduled Action واقف أو البيئة Staging/Dev، الإيميل بيفضل واقف أو بيفشل.

الحل

1. افتح الإيميل نفسه في قايمة Emails (محتاجة Developer Mode) وشوف حالته وسبب الفشل (Failure Reason).
2. افتح Outgoing Mail Server واضغط Test Connection، وراجع بيانات SMTP أو OAuth وعنوان الـ From.
3. اتأكد إن Scheduled Action بتاع طابور الإيميلات شغّال (اسمه تقريباً Mail: Email Queue Manager).
4. لو بتجرّب على Staging أو Dev في Odoo.sh، الإيميلات هناك غالباً بتتحجز عمداً ومش بتتبعت.

إزاي ما تتكررش

اظبط SPF وDKIM للدومين وخلّي الـ From من نفس الدومين، وجرّب Test Connection بعد أي تغيير في باسورد الإيميل.

السبب

الاستيراد بيطابق عنوان العمود مع اسم حقل في Odoo. لو العنوان مكتوب بصيغة مختلفة أو الحقل مش موجود في الموديل، العمود بيفضل من غير ربط ومش بيتستورد.

الحل

1. في شاشة الاستيراد دوس Test وبص على الأعمدة اللي من غير حقل مربوط.
2. اربط العمود يدوياً من قايمة الحقول قصاده، أو غيّر عنوان العمود في الملف لاسم الحقل بالظبط.
3. الأضمن: اعمل Export لسجل واحد بخيار I want to update data (import-compatible export) واستخدمه كقالب للملف.
4. لو الحقل مخصص ومش لاقيه، اتأكد إنه موجود في الموديل (من Studio أو الموديول).

إزاي ما تتكررش

خلّي عندك قالب Export جاهز لكل نوع بيانات، وماتغيّرش عناوين الأعمدة فيه.

السبب

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

الحل

1. قارن الاسم في الملف بالاسم في Odoo حرفياً (مسافات، همزات، حروف كبيرة وصغيرة).
2. لو السجل مش موجود، أنشئه الأول وبعدها استورد الحاجات اللي بتعتمد عليه.
3. لو الرسالة Found multiple matches: فيه أكتر من سجل بنفس الاسم، استخدم عمود External ID أو Database ID للحقل بدل الاسم.
4. اتأكد إن السجل مش مؤرشف وتابع لنفس الشركة.

إزاي ما تتكررش

رتّب الاستيراد: الأساسيات الأول (عملاء، منتجات، حسابات) وبعدين الحركات، واستخدم External IDs.

السبب

البطء ليه أسباب كتير: تقرير أو قايمة على بيانات كبيرة من غير فلاتر، أو Scheduled Actions تقيلة شغالة في نفس الوقت، أو كود مخصص بيعمل استعلامات كتير، أو موارد السيرفر والـ workers مش كفاية.

الحل

1. حدّد النطاق: شاشة واحدة ولا النظام كله؟ يوزر واحد ولا الكل؟ وبدأ إمتى (بعد تحديث، موديول جديد، زيادة بيانات)؟
2. على الشاشة البطيئة استخدم الـ Profiler من Developer Mode عشان تعرف الاستعلام أو الكود اللي بياخد الوقت.
3. راجع الـ Scheduled Actions وقت البطء واللوجز لو فيه طلبات طويلة.
4. لو السيرفر بتاعك: راجع عدد الـ workers والذاكرة وحدود limit_time_cpu وlimit_time_real مع مسؤول السيرفر.

إزاي ما تتكررش

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

السبب

الـ Upgrade بيرحّل الموديولات القياسية (Standard) بس. الكود والـ Views المخصصة اتكتبت للنسخة القديمة وممكن تستخدم APIs أو صياغة اتغيرت أو اتشالت.

الحل

1. ما تعملش Upgrade على الإنتاج مباشرة: اعمله على نسخة اختبار من قاعدة بيانات حقيقية.
2. اقرا الـ Upgrade log والـ traceback وحدد الموديول والملف اللي بيفشل.
3. حدّث الـ Custom Modules للنسخة الجديدة (مثلاً attrs وstates اتشالوا في 17، وعنصر tree اتغير لـ list في 18) وثبّتها على النسخة التجريبية واحد واحد.
4. اختبر الدورات الأساسية (فاتورة، دفع، مخزون، رواتب) وخد موافقة العميل، وبعدها كرّر الـ Upgrade على الإنتاج بعد Backup.

إزاي ما تتكررش

خلّي الكود المخصص في Git وفيه اختبارات، وابدأ الـ Upgrade التجريبي بدري مش قبل الـ Go-live بأيام.

السبب

تعديلات Studio والـ Views المخصصة بتتخزن كـ Inherited Views بتشاور على عنصر في الشاشة الأصلية. لما الشاشة الأصلية تتغير بالتحديث أو الترقية والعنصر يتشال أو يتحرك، الـ View الوارثة مبقاش ليها مكان تتركّب فيه.

الحل

1. من الرسالة حدد اسم الشاشة (الموديل والـ View).
2. فعّل Developer Mode وافتح الـ Inherited View المسؤولة (اللي اتعملت من Studio أو من موديول مخصص).
3. صلّح الـ xpath أو الحقل عشان يشاور على عنصر موجود دلوقتي، أو اعمل لها Archive مؤقتاً عشان الشاشة ترجع تشتغل.
4. أعد التعديل من Studio على الشاشة الجديدة وجرّب.

إزاي ما تتكررش

قبل أي تحديث أو Upgrade جرّب على نسخة اختبار، وسجّل تعديلات Studio وقلّل اللي بيعتمد على عناصر داخلية.