رؤى وتحديثاتMonday, October 26, 2026Vol. I — No. 1

✦ Est. 2026 ✦

المدونة

"كل ما يهم من رؤى، يُقدم بوضوح"

العدد الحالي

آخر المقالات

القصة الرئيسية

Oct 20, 2026

Using AI Tools Safely at Work: A Practical Guide for Teams and Business Owners

Ahmed Infan · Oct 20, 2026

ما الذي يمكن مشاركته، وما الذي يجب إبقاؤه خارجًا، وكيف تضع قواعد بسيطة يلتزم بها فريقك بالكامل.الصورة العامةأصبحت روبوتات المحادثة ومساعدات الكتابة المعتمدة على الذكاء الاصطناعي جزءًا من العمل اليومي دون ضجة. يستخدمها الناس لصياغة رسائل البريد الإلكتروني، وتلخيص المستندات، وكتابة الأكواد، وترجمة النصوص، وتوليد الأفكار. وعند استخدامها بشكل جيد توفّر وقتًا حقيقيًا. أما عند استخدامها بإهمال، فقد تكشف بيانات العملاء، أو تسرّب خططًا سرية، أو تنتج أخطاء تبدو واثقة وتصل في النهاية إلى العميل.نادرًا ما يأتي الخطر من الأداة نفسها، بل من عدم معرفة ما يحدث للمعلومات التي تكتبها، ومن غياب قواعد مشتركة. يتناول هذا الدليل أهم المخاطر بلغة بسيطة، ويقدّم إطار عمل عمليًا يمكنك اعتماده هذا الأسبوع.لماذا يهمّ هذا الآن؟يبدأ اعتماد الذكاء الاصطناعي في معظم الشركات من القاعدة إلى القمة. يجرّب موظف أداة، ويجدها مفيدة، ويخبر زميلًا بها. وخلال أسابيع قليلة يستخدم نصف الفريق أداة لم تراجعها الإدارة قط. يُطلق على هذا أحيانًا «الذكاء الاصطناعي الخفي» (Shadow AI)، وهو يخلق ثلاثة أنواع من المخاطر:تسرّب البيانات: يتم لصق معلومات سرية أو شخصية في أداة لم تفحصها الشركة.أخطاء الجودة: يُستخدم محتوى مولَّد بالذكاء الاصطناعي دون مراجعة، فتصل الأخطاء إلى العملاء أو العقود أو الأكواد.ثغرات الامتثال: تتم معالجة بيانات العملاء أو الموظفين بطرق لا تسمح بها قواعد الخصوصية أو اتفاقيات العملاء.غالبًا ما يفشل الحظر التام للذكاء الاصطناعي، لأن الناس يواصلون استخدامه سرًّا. أما التوجيهات الواضحة فتعطي نتائج أفضل.اعرف ما يحدث لما تُدخلهقبل استخدام أي أداة ذكاء اصطناعي في العمل، اعرف إجابات بعض الأسئلة الأساسية. وتوجد عادةً في سياسة الخصوصية لدى المزوّد أو شروط الخدمة أو إعدادات المسؤول:هل يتم تخزين ما تُدخله، ولمدة كم؟هل يمكن استخدامه لتدريب نماذج المزوّد أو تحسينها؟ وهل يوجد إعداد لإيقاف ذلك؟من لدى المزوّد يمكنه الاطلاع عليه، وفي أي ظروف؟هل تختلف شروط البيانات في الخطة التي تستخدمها (المجانية أو الشخصية أو الخاصة بالفرق أو الخاصة بالمؤسسات) عن الخطط الأخرى؟هل يستطيع المسؤولون التحكم في الإعدادات والمستخدمين ومدة الاحتفاظ بالبيانات؟تختلف السياسات بين المزوّدين وبين أنواع الخطط، كما تتغيّر بمرور الوقت. وغالبًا ما تكون الحسابات الشخصية المجانية أضعف حماية من خطط الأعمال، فلا تفترض أن الشروط التي قرأتها لمنتج ما تنطبق على منتج آخر. تحقّق من الشروط الحالية للمنتج والخطة اللذين يستخدمهما فريقك تحديدًا.قاعدة إشارة المرور البسيطة للبياناتأسهل طريقة لحماية الناس هي تصنيف المعلومات إلى ثلاث مجموعات وربط كل مجموعة بقاعدة واضحة.الأخضر: يمكن استخدامه عمومًامواد عامة أو غير حساسة، مثل:نصوص من موقعك العام أو من مواد تسويقية منشورةأسئلة عامة وشروحات وعصف ذهنيمسوّدات لا تحتوي على أسماء أو أرقام أو تفاصيل خاصةالأصفر: استخدمه بحذر فقطمواد داخلية ليست شديدة الحساسية لكنها ليست عامة أيضًا، مثل:ملاحظات العمليات الداخلية أو ملخصات الاجتماعاتمسوّدات عروض بعد حذف تفاصيل العميلمقاطع أكواد غير حساسةاستخدم أداة معتمدة، واحذف التفاصيل التي تدل على الهوية، ولا تحتفظ بالنص إلا بقدر ما تتطلبه المهمة.الأحمر: ابقِه خارجًا ما لم تتم الموافقة صراحةًمعلومات حساسة، مثل:البيانات الشخصية للعملاء أو الموظفين (الأسماء مع بيانات الاتصال، وأرقام الهوية، والمعلومات الصحية أو المالية أو معلومات الموارد البشرية)كلمات المرور ومفاتيح API والرموز (Tokens) وكل ما يمنح صلاحية وصولالعقود والمستندات القانونية والبيانات المالية غير المنشورة والأسرار التجاريةالأكواد المصدرية أو البيانات المشمولة باتفاقية سرية مع العميلإذا توفرت أداة معتمدة بشروط تعاقدية مناسبة، فاتبع سياستك الخاصة بها. وإلا فتبقى البيانات الحمراء خارجها.أخفِ الهوية قبل اللصقغالبًا يمكنك الحصول على المساعدة التي تحتاجها دون مشاركة التفاصيل الحقيقية. قبل لصق نص في أداة ذكاء اصطناعي:استبدل الأسماء بأدوار، مثل «العميل أ» أو «العميل».احذف عناوين البريد الإلكتروني وأرقام الهواتف وأرقام الحسابات والعناوين.استبدل الأرقام الدقيقة بأرقام مقرّبة أو رمزية عندما لا تكون القيمة الدقيقة مهمة.أزل الأسرار وبيانات الاعتماد من الأكواد وملفات الإعدادات.التحقق السريع قبل الضغط على «إدخال» عادة قوية: هل سأكون مرتاحًا لو وصل هذا النص إلى خارج الشركة؟تعامل مع المخرجات كمسودة لا كحقيقةقد تنتج أدوات الذكاء الاصطناعي إجابات سلسة وواثقة لكنها خاطئة. فقد تختلق مصادر، أو تنقل أرقامًا بشكل خاطئ، أو تسيء قراءة مستند، أو تصف ميزة غير موجودة. كوّن عادة المراجعة:تحقّق من الحقائق والأرقام والاقتباسات من مصدر موثوق قبل استخدامها.افحص أي مرجع أو رابط تقدمه الأداة. تأكد من أنه موجود ويقول فعلًا ما تدّعيه الأداة.اجعل شخصًا يراجع كل ما يتعلق بالعملاء أو الجوانب القانونية أو المالية أو التقنية قبل إرساله.اختبر الأكواد المولَّدة وراجعها بحثًا عن مشكلات أمنية قبل أن تقترب من بيئة الإنتاج.كن شفافًا بشأن الاستخدام حيثما يتوقع عملاؤك أو جهة عملك أو الجهة الناشرة الإفصاح عنه.الشخص الذي يرسل العمل هو المسؤول عنه، سواء ساعده الذكاء الاصطناعي في كتابته أم لا.مخاطر أخرى يجب وضعها في الاعتبارحقوق النشر والملكية: تختلف القواعد المتعلقة بالمحتوى المولَّد بالذكاء الاصطناعي وبالمواد التي دُرّبت عليها الأدوات من بلد إلى آخر، وما زالت قيد التطور. وبالنسبة لأي شيء ستنشره أو تبيعه، راجع شروط أداتك، واستشر محاميًا عندما تكون المخاطر عالية.حقن التعليمات (Prompt Injection): عندما تقرأ أداة الذكاء الاصطناعي صفحات ويب أو رسائل بريد أو مستندات، قد تحاول تعليمات مخفية داخل هذا المحتوى توجيهها. كن حذرًا عند ربط أدوات الذكاء الاصطناعي ببريدك أو ملفاتك أو حساباتك، وراجع الإجراءات المسموح لها بتنفيذها.الاعتماد المفرط: إذا توقف الناس عن التحقق، تتراكم الأخطاء الصغيرة. أبقِ الحكم البشري ضمن العملية، خاصة في القرارات التي تؤثر على الأشخاص.التحيّز: قد تعكس المخرجات تحيزات موجودة في بيانات التدريب، وهذا مهم في التوظيف والإقراض والتسعير وأي أمر آخر يؤثر على الأفراد.إعداد سياسة للذكاء الاصطناعي في خمس خطواتلا تحتاج إلى وثيقة من 30 صفحة. سياسة قصيرة وواضحة يقرؤها الناس فعلًا أفضل.احصر ما يُستخدم. اسأل فريقك عن أدوات الذكاء الاصطناعي التي يستخدمونها بالفعل ولأي غرض. افعل ذلك دون لوم، لتحصل على إجابات صادقة.اختر أدوات معتمدة. اختر مجموعة صغيرة من الأدوات، ويفضّل أن تكون ضمن خطط أعمال بشروط بيانات مناسبة وضوابط للمسؤولين، وأخبر الناس بما هي.حدّد قواعد البيانات. اعتمد نهج إشارة المرور المذكور أعلاه وقدّم أمثلة تناسب عملك.حدّد توقعات المراجعة. اذكر ما يجب أن يراجعه إنسان قبل مشاركته أو نشره أو إطلاقه.درّب وراجع. نظّم جلسة قصيرة، وحدّد شخصًا يمكن للناس سؤاله عند الشك، وراجع السياسة كل بضعة أشهر، لأن الأدوات والقواعد تتغير بسرعة.قائمة تحقق سريعة للأفرادقبل استخدام أداة ذكاء اصطناعي في العمل، اسأل نفسك:هل هذه الأداة معتمدة، أو هل يُسمح لي باستخدامها لهذه المهمة؟هل يحتوي نصي على معلومات شخصية أو سرية أو أسرار؟هل يمكنني إخفاء الهوية أو اختصاره أولًا؟هل أعرف المدة التي تحتفظ فيها الأداة بما أُدخله، وهل يُستخدم في التدريب؟من سيفحص النتيجة قبل استخدامها؟للفرق التي تبني منتجات بالذكاء الاصطناعيإذا كانت شركتك تبني منتجات فوق الذكاء الاصطناعي، مثل مساعدات المحادثة أو أدوات المستندات أو الأتمتة، فإن الأفكار نفسها تنطبق على نطاق أكبر. حدّد البيانات التي تتدفق إلى أي مزوّد، وقيّد ما يمكن للنظام الوصول إليه والقيام به، وسجّل النشاط، واختبر المخرجات الخاطئة أو غير الآمنة، وأبقِ إنسانًا ضمن العملية في الإجراءات المهمة. إن تصميم هذه الضوابط منذ البداية أسهل بكثير من إضافتها بعد الإطلاق.الخلاصةيتلخص الاستخدام الآمن للذكاء الاصطناعي في بضع عادات: اعرف أين تذهب بياناتك، وأبقِ المعلومات الحساسة خارجًا، وأخفِ الهوية متى استطعت، وافحص كل شيء قبل أن يغادر يدك. أضف سياسة قصيرة مشتركة، وستحصل على مزايا السرعة التي يوفرها الذكاء الاصطناعي دون أن تُسلّم ثقة عملائك إلى أداة لم يراجعها أحد.

اقرأ القصة الكاملة←

Oct 20, 2026

إدارة المخزون والمستودعات في أودو 20: ما الجديد ولماذا يهمّ؟

بواسطة SHIBIL

Oct 14, 2026

شرح وضع العمل دون اتصال في Odoo: المميزات والفوائد وحالات الاستخدام

بواسطة Athul

Oct 8, 2026

تصميم منصة ويب متعددة اللغات: من قاعدة البيانات إلى المتصفح

بواسطة Shifan V

✦ قراءات إضافية ✦

Oct 8, 2026

كيف يحوّل «مساعد الجداول الزمنية» في Odoo 20 نشاطك اليومي على الحاسوب إلى سجلات وقت لا عليك سوى الموافقة عليها.

Mithun Mohan

المشكلة التي يعرفها كل فريق عمل اسأل أي شخص يحاسب العملاء بالساعة، أو يتابع التكلفة الفعلية للمشروع، وسيخبرك بالأمر نفسه: تعبئة الجداول الزمنية هي المهمة التي ينساها الجميع. في نهاية اليوم، أو الأسوأ في نهاية الأسبوع، يحاول الناس إعادة بناء جدولهم من الذاكرة. تُنسى اجتماعات، وتختفي مكالمات سريعة، وتبقى ساعات عمل حقيقية دون فوترة. يعالج Odoo 20، أحدث إصدار من برنامج إدارة الأعمال الشهير، هذه المشكلة بميزة جديدة تسمى «مساعد الجداول الزمنية» (Timesheet Assistant). لا تحتاج إلى معرفة Odoo لفهم الفكرة، لذلك يشرح هذا المقال كل شيء من البداية. تعريفان سريعان Odoo هو برنامج لإدارة الأعمال (يُعرف غالبًا بنظام ERP) يجمع المبيعات والمحاسبة والمخزون والمشاريع والموارد البشرية في نظام واحد، وتستخدمه شركات من مختلف الأحجام. الجدول الزمني (Timesheet) سجل يوضح مقدار الوقت الذي قضاه شخص ما في كل عمل. يُستخدم لفوترة العملاء ولمعرفة ما إذا كانت المشاريع ضمن الميزانية. ماذا يفعل مساعد الجداول الزمنية؟ باختصار: يراقب التطبيقات والمواقع التي تستخدمها خلال اليوم، ويخمّن المشروع الذي ينتمي إليه كل عمل، ثم يقدّم لك قائمة جاهزة من سجلات الوقت. تراجع القائمة، وتصحح ما يبدو خاطئًا، ثم تضغط «إنشاء». لا تتم إضافة أي شيء إلى جدولك الزمني تلقائيًا. المساعد يقترح فقط، والتحكم دائمًا بيدك. 1. التتبّعالتطبيقات والمواقع 2. المطابقةالقواعد تصنّف النشاط 3. الاقتراحمجمّعة حسب المشروع 4. التأكيدتضغط «إنشاء» الخطوات الأربع لمساعد الجداول الزمنية. الخطوتان 1 و2 تحدثان بهدوء في الخلفية (مع تقويم Odoo والتخطيط الخاص بك). الخطوتان 3 و4 هما الوحيدتان اللتان تقوم بهما أنت. كيف يعمل من الداخل التتبّع. يعتمد المساعد على أداة مجانية مفتوحة المصدر تسمى ActivityWatch تُثبَّت على حاسوبك. تسجّل الأداة التطبيق أو تبويب المتصفح النشط ومدة استخدامه. وتضيف إضافة اختيارية للمتصفح (Chrome أو Firefox) تفاصيل على مستوى المواقع. المطابقة. بعد ذلك يطبّق Odoo «قواعد المساعد». القاعدة نمط نصي صغير (يُسمى تقنيًا «تعبيرًا نمطيًا» Regular Expression) يتعرّف على نشاط معيّن، مثل مكالمة Google Meet أو العمل في مستودع برمجي، ويضع له تسمية. يأتي Odoo بقواعد جاهزة لـ Odoo نفسه وGitHub وGoogle Docs وGmail وGoogle Meet وDiscord. وبمجرد تفعيل قاعدة ما، يُنسب النشاط اللاحق إليها حتى تُفعَّل قاعدة أخرى. الاقتراح. يدمج Odoo هذه الأنشطة المصنّفة مع أحداثك في تقويم Odoo وتخطيطك، ثم يسند كل اقتراح إلى مشروع ومهمة. كما يتعلم من اختياراتك السابقة، فإذا أسندتَ اقتراحًا إلى مشروع مرة واحدة فمن المرجّح أن يذهب إليه مجددًا. التأكيد. تفتح شاشة المساعد، وتحدد اقتراحًا واحدًا أو أكثر، وتعدّل التفاصيل عند الحاجة، ثم تضغط «إنشاء». عندها تتحول إلى سجلات وقت عادية. أين تجده وكيف تُعدّه يوجد المساعد داخل تطبيق الجداول الزمنية (Timesheets). ويستغرق الإعداد دقائق قليلة لكل شخص. فعّله. انتقل إلى Timesheets > Configuration > Settings وفعّل خيار Timesheets Assistant. يجب أن تُسجَّل الجداول الزمنية بالساعات والدقائق (إعداد «طريقة الترميز» Encoding method)، وإلا فلن يكون الخيار متاحًا. ثبّت أداة التتبّع. افتح Timesheets > Assistant. سيرشدك Odoo خطوة بخطوة لتثبيت ActivityWatch على حاسوبك. الأنظمة المدعومة تشمل Windows 10 وmacOS 10.15 وUbuntu 22 أو أحدث. إضافة المتصفح اختيارية. اربطها بـ Odoo. انسخ عنوان Odoo الخاص بك إلى إعدادات ActivityWatch (وهذا يخبرها بأن Odoo مسموح له بقراءة بياناتها)، ثم اضغط Test connection. اعمل كالمعتاد. يبدأ التتبّع تلقائيًا كل يوم. تُتجاهل الفترات الأقصر من دقيقة، وتُحتسب ثلاث دقائق دون نشاط على لوحة المفاتيح أو الفأرة استراحةً. راجع وأنشئ. في أي وقت، افتح Timesheets > Assistant، وحدد الاقتراحات التي تريدها، وعدّلها إن لزم، ثم اضغط Create. ويمكن حذف الاقتراحات غير المرغوبة ببساطة. القواعد ببساطة: مثال تطبيقي القواعد هي ما يحوّل النشاط الخام إلى شيء ذي معنى. إليك شكل قاعدة لمكالمات الفيديو مع العملاء. الحقول هي نفسها التي يطلب منك Odoo تعبئتها. الحقلقيمة المثالمعناه الاسم (Name)Customer Meetingتسمية القاعدة النمط (Pattern)meet - (.*)|https://meet.google.comيتعرّف على نافذة أو عنوان Google Meet القالب (Template)Customer Meeting ($1)يسمّي السجل باسم عنوان الاجتماع الذي وجده Odoo نشطة دائمًا (Always active)نعميواصل احتساب الوقت حتى لو لم تلمس لوحة المفاتيح، وهو أمر طبيعي أثناء الاجتماعات المشروع والمهمةفارغقد ينتمي كل اجتماع إلى عميل مختلف ماذا عن الخصوصية؟ هذا أول سؤال يطرحه معظم الناس، وجواب وثائق Odoo مطمئن: تُعالَج جميع بيانات النشاط محليًا على جهازك الخاص ولا تُشارَك مع أي أحد، داخل شركتك أو خارجها. تبقى الاقتراحات خاصة بك إلى أن تقرر تحويلها إلى سجلات وقت. والسجلات التي تنشئها وحدها هي التي تصبح مرئية لمديرك ولبقية النظام. قاعدة حكيمة للفرق اشرح الميزة للموظفين قبل تفعيلها. ولأنها اختيارية لكل حاسوب، ولا يُسجَّل شيء في الجدول الزمني للشركة حتى يضغط الموظف «إنشاء»، فإنها تعمل بأفضل صورة كأداة مساعدة للذاكرة، لا كأداة مراقبة. Odoo 19 مقابل Odoo 20 كان Odoo 19 يدعم الجداول الزمنية عبر الإدخال اليدوي والمؤقّتات. أما الجديد في Odoo 20 فهو مصدر السجلات. Odoo 19Odoo 20 تسجيل الوقتتكتب السجلات أو تشغّل المؤقّت بنفسكيقترح المساعد السجلات وأنت تؤكدها مصدر المعلوماتذاكرتك وما تتذكر إدخالهنشاط الحاسوب والمتصفح، إضافةً إلى تقويم Odoo والتخطيط المشروع والمهمةتختارهما بنفسك في كل مرةتُطابَق بالقواعد وباختياراتك السابقة الجهد في نهاية اليومإعادة بناء اليوم من الذاكرةمراجعة قائمة والضغط على «إنشاء» الإعدادلا شيء إضافيتفعيل الإعداد وتثبيت ActivityWatch على كل حاسوب من المستفيد وكيف؟ الموظفون يقضون وقتًا أقل في الأعمال الإدارية ويتوقفون عن القلق بشأن الساعات المنسية. المديرون يرون جداول زمنية أكثر اكتمالًا، مما يجعل تقارير المشاريع والتخطيط أكثر موثوقية. فرق المالية والفوترة تستطيع فوترة وقت كان سيبقى دون تسجيل في السابق. الشركات القائمة على المشاريع (الاستشارات والوكالات وفرق البرمجيات) تحصل على صورة أدق لتكلفة كل مشروع الفعلية. أمور يجب وضعها في الحسبان يتطلب تثبيتًا لمرة واحدة على حاسوب كل شخص، لذا فهو يناسب العمل المكتبي على الحاسوب أكثر من العمل الذي يتم في معظمه بعيدًا عنه. جودة الاقتراحات من جودة القواعد التي تقف خلفها. توقّع أن تعدّل القواعد أو تضيف قواعد جديدة خلال الأسابيع الأولى. قد تحتاج المهام القصيرة والمتفرقة إلى تصحيح يدوي قبل إنشاء السجل. هو مساعد وليس بديلًا عن الحكم البشري: الناس هم من يقررون ما يدخل في الجدول الزمني. الخلاصة لطالما طلبت الجداول الزمنية من الناس أن يتذكروا الماضي. أما مساعد الجداول الزمنية في Odoo 20 فيقلب المعادلة: يحتفظ النظام بسجل خاص ليومك، وما عليك سوى الموافقة على ما هو دقيق. وبالنسبة لأي فريق يحاسب بالساعة أو يدير مشاريع، فهذا تحسين عملي، ولا يتطلب من أحد فهم البرنامج الذي يعمل خلف الكواليس. المصادر: وثائق Odoo 20 (Timesheet assistant، odoo.com/documentation)؛ ملاحظات إصدار Odoo 20؛ مقالات الشركاء من Octura Solutions وTarget Integration.

Oct 6, 2026

مراقبة الموظفين دون لقطات شاشة: نهج أكثر مراعاة للخصوصية لإدارة القوى العاملة

Mishal

مراقبة الموظفين دون لقطات شاشة | TIMO360 شهدت مراقبة الموظفين تحولاً كبيراً خلال العقد الماضي. فالشركات تريد رؤية أوضح لمستويات الحضور وأنماط العمل والإنتاجية، بينما يتوقع الموظفون بشكل متزايد أن تحترم تقنيات مكان العمل خصوصيتهم. وهذا يطرح سؤالاً مهماً على الشركات الحديثة: كيف يمكن للفرق أن تعرف ما إذا كان العمل يتم فعلاً دون تحويل مراقبة الموظفين إلى رقابة دائمة؟ إحدى الإجابات هي التوقف عن جمع كل شيء، والتركيز بدلاً من ذلك على المؤشرات التي تساعد المديرين فعلاً على فهم العمل. مشكلة المراقبة المتطفلة للموظفين تحاول برامج مراقبة الموظفين التقليدية غالباً تحقيق الرؤية عبر جمع أكبر قدر ممكن من المعلومات. فلقطات الشاشة وتسجيل ضغطات المفاتيح والمراقبة التفصيلية للنشاط قد تنتج كميات هائلة من البيانات. لكن زيادة البيانات لا تعني تلقائياً إدارة أفضل. ففي كثير من الحالات قد تجعل المراقبة المفرطة الموظفين يشعرون بأنهم مراقَبون لا مدعومون. 01 مخاوف الخصوصية قد يشعر الموظفون بعدم الارتياح عندما تُلتقط معلومات شخصية أو تفصيلية بلا داعٍ بشكل مستمر. 02 فائض البيانات قد تجعل الكميات الكبيرة من بيانات النشاط من الصعب تحديد المعلومات التي يحتاجها المديرون فعلاً. 03 تراجع الثقة قد تؤثر بيئة العمل القائمة على الرقابة المشددة في نظرة الموظفين إلى الإدارة وتقنيات مكان العمل. 04 حوافز خاطئة النشاط الظاهر على الحاسوب ليس دائماً مساوياً للعمل الهادف أو النتائج المفيدة. لماذا تهمّ الخصوصية في مراقبة الموظفين ينبغي أن تبدأ مراقبة الموظفين بغرض عمل واضح. فقد تحتاج الشركات إلى معلومات عن الحضور والجداول ونشاط التطبيقات وأنماط العمل، لكن هذا لا يعني أن كل إجراء على الحاسوب يجب أن يتحول إلى سجل دائم. يبدأ نهج الخصوصية أولاً بمبدأ بسيط: اجمع المعلومات لأنها تخدم غرضاً تشغيلياً محدداً، لا لمجرد أن التقنية تتيح ذلك. الهدف هو فهم العمل المطلوب إدارته، لا مراقبة كل تفاصيل الشخص الذي يؤديه. بديل أفضل للقطات الشاشة ما زالت الشركات تحتاج إلى الرؤية. فالمديرون بحاجة إلى معرفة ما إذا كان الموظفون يعملون خلال ساعات العمل المحددة، وما إذا كانت التطبيقات تُستخدم بشكل مناسب، وما إذا كانت الفرق تحافظ على إنتاجيتها. ويمكن الإجابة عن كثير من هذه الأسئلة عبر مؤشرات أقل تطفلاً. سؤال العمل المؤشر المفيد نهج الخصوصية هل كان الموظف يعمل؟ الحضور ووقت النشاط/الخمول لا حاجة إلى محتوى الشاشة ما التطبيقات التي استُخدمت؟ نشاط التطبيقات التركيز على استخدام التطبيقات بدلاً من محتوى الشاشة هل أُنجز العمل المجدول؟ الجداول وأنماط النشاط قياس أنماط العمل بدلاً من التقاط كل شيء أين توجد مشكلات الإنتاجية؟ رؤى الإنتاجية استخدام المؤشرات لتحديد الأنماط ومجالات التحسين المراقبة التقليدية مقابل المراقبة القائمة على الخصوصية الفرق ليس في وجود الرؤية لدى الشركة من عدمه. الفرق في كيفية تحقيق هذه الرؤية. الرقابة التقليدية نهج الخصوصية أولاً التقاط الشاشة قد تلتقط لقطات الشاشة المستمرة أو الدورية كل ما يظهر على شاشة الموظف. مؤشرات النشاط التركيز على الحضور ووقت النشاط/الخمول ونشاط التطبيقات. تسجيل ضغطات المفاتيح قد تصبح إجراءات لوحة المفاتيح الفردية جزءاً من المراقبة. أنماط العمل فهم نشاط العمل دون تسجيل ضغطات المفاتيح الفردية. أقصى قدر من جمع البيانات جمع أكبر قدر ممكن من المعلومات من الناحية التقنية. جمع هادف جمع المعلومات المفيدة فعلاً لإدارة القوى العاملة. عقلية الرقابة قد تبدو المراقبة وكأنها مراقبة مستمرة. عقلية الإدارة استخدام المعلومات لفهم الحضور والجداول والإنتاجية. كيف تبدو مراقبة الموظفين القائمة على الخصوصية لا يعني نهج المراقبة القائم على الخصوصية إزالة كل أشكال الرؤية، بل اختيار المستوى المناسب منها. فبدلاً من التساؤل عن مقدار نشاط الموظفين الذي يمكن التقاطه، يمكن للشركات أن تبدأ بالتساؤل عن المعلومات اللازمة لإدارة العمل بفعالية. 01 حدّد السؤال حدّد ما يحتاج المديرون فعلاً إلى فهمه بشأن العمل أو الحضور أو الإنتاجية. 02 اختر المؤشرات المفيدة استخدم الحضور والنشاط واستخدام التطبيقات والجداول للإجابة عن هذه الأسئلة. 03 حوّل المؤشرات إلى رؤى استخدم المعلومات الناتجة لفهم الأنماط وتحسين إدارة القوى العاملة. كيف تتعامل TIMO360 مع مراقبة الموظفين TIMO360 مبنية على نهج يضع الخصوصية أولاً في مراقبة الموظفين وإدارة القوى العاملة. فبدلاً من جعل لقطات الشاشة أو تسجيل ضغطات المفاتيح أساس المراقبة، تركّز TIMO360 على مؤشرات القوى العاملة التي تساعد الشركات على فهم كيفية سير العمل. وتشمل هذه المؤشرات الحضور ووقت النشاط والخمول ونشاط التطبيقات والجداول ورؤى الإنتاجية. نهج الخصوصية أولاً الهدف هو رؤية مفيدة للقوى العاملة دون الاعتماد على لقطات الشاشة أو تسجيل ضغطات المفاتيح. خمسة مبادئ لمراقبة أفضل للموظفين 01 ابدأ بسؤال العمل حدّد ما يحتاج المديرون إلى معرفته فعلاً قبل تحديد البيانات التي يجب أن يجمعها النظام. 02 اجمع مؤشرات مفيدة يمكن للحضور والجداول والنشاط واستخدام التطبيقات أن توفر معلومات مفيدة دون تسجيل كل شيء. 03 اجعل المراقبة مفهومة ينبغي أن يفهم الموظفون ما الذي يُقاس ولماذا تتصل هذه المعلومات بعملهم. 04 ركّز على الأنماط نادراً ما ترسم إشارة نشاط واحدة الصورة كاملة. والاتجاهات والأنماط أكثر فائدة عموماً للإدارة. 05 استخدم المراقبة لتحسين العمل ينبغي أن تساعد المراقبة على تحديد المشكلات التشغيلية وتحسين سير العمل ودعم حوارات أفضل. ماذا ينبغي أن يوفّر نظام المراقبة القائم على الخصوصية؟ ينبغي أن يوفر نظام مراقبة الموظفين المفيد رؤية كافية لمساعدة المديرين على فهم العمل دون تحويل كل تفاعل على الحاسوب إلى رقابة. ✓ معلومات واضحة عن الحضور ✓ رؤية وقت النشاط والخمول ✓ معلومات عن نشاط التطبيقات ✓ رؤية الجداول ✓ رؤى إنتاجية مفيدة ✓ عدم الاعتماد على لقطات الشاشة أو تسجيل ضغطات المفاتيح مستقبل مراقبة الموظفين أكثر هادفية لا يجب أن تكون مراقبة الموظفين خياراً بين انعدام الرؤية ومراقبة كل ما يفعله الموظفون. هناك حل وسط: اجمع المعلومات المفيدة، وافهم أنماط العمل، وتجنّب الرقابة غير الضرورية. بالنسبة للشركات، قد يعني ذلك رؤية تشغيلية أفضل. وبالنسبة للموظفين، قد يعني تقنية مكان عمل تحترم الحدود المعقولة. الهدف ليس معرفة كل ما يفعله الموظف، بل معرفة ما يكفي لإدارة العمل بفعالية. الأسئلة الشائعة هل يمكن أن تعمل مراقبة الموظفين دون لقطات شاشة؟ نعم. يمكن للشركات استخدام مؤشرات مثل الحضور ووقت النشاط والخمول ونشاط التطبيقات والجداول ورؤى الإنتاجية دون جعل لقطات الشاشة أساس استراتيجية المراقبة. هل مراقبة الموظفين متطفلة دائماً؟ ليس بالضرورة. يعتمد الأثر على المعلومات التي تُجمع، وسبب جمعها، وكيفية استخدامها. ويمكن لنهج هادف أن يوفر رؤية للقوى العاملة بجمع بيانات أقل تطفلاً. لماذا نتجنب تسجيل ضغطات المفاتيح؟ قد تحتوي ضغطات المفاتيح الفردية على معلومات تفصيلية جداً دون أن توفر بالضرورة رؤية إدارية مفيدة. وغالباً ما تستطيع مؤشرات العمل الأوسع الإجابة عن سؤال العمل دون تسجيل كل إجراء على لوحة المفاتيح. ماذا تراقب TIMO360؟ تركّز TIMO360 على مؤشرات القوى العاملة مثل الحضور ووقت النشاط والخمول ونشاط التطبيقات والجداول ورؤى الإنتاجية بدلاً من الاعتماد على لقطات الشاشة أو تسجيل ضغطات المفاتيح. الرؤية الأفضل لا تتطلب مزيداً من الرقابة. اكتشف نهجاً يضع الخصوصية أولاً في مراقبة الموظفين مع TIMO360. اكتشف TIMO360

Sep 30, 2026

الجديد في إطار عمل جافاسكربت في أودو

Faisal

إعداد: فيصل · Codeox Technologies الصورة الكبيرة في سطر واحد أعادت أودو بناء الواجهة الأمامية للموقع بالكامل تقريبًا من الصفر (الجزء الذي يشغّل المتجر الإلكتروني والنماذج وبناء الصفحات)، بينما بقي إطار العمل الأساسي للواجهة الخلفية مستقرًا في معظمه مع الكثير من التحسينات الصغيرة المفيدة، خاصة في السرعة ودعم العمل دون اتصال. شريحة ملخّص من أودو نفسها: إعادة هيكلة كبيرة في جانب الموقع، وسلسلة مستمرة من التحسينات في جانب عميل الويب. إطاران يعملان جنبًا إلى جنب يظن كثيرون أن أودو تملك إطار جافاسكربت واحدًا اسمه Owl، وهذا ليس دقيقًا تمامًا. في الواقع هناك نظامان مختلفان يعملان معًا، وفهم هذا الفرق يفسّر لماذا تغيّرت أشياء كثيرة هذا العام بينما لم يتغيّر غيرها تقريبًا. عميل الويب (تطبيقات الواجهة الخلفية مثل المحاسبة وإدارة العلاقات وإدارة المخزون) مبني على Owl، بينما يستخدم الموقع (المتجر الإلكتروني وصفحات الهبوط) نظامًا جديدًا وأخف يسمى «Interaction». Owl هو نظام المكوّنات في أودو، ويشبه في فكرته React. يُستخدم لبناء التطبيقات التي نعمل عليها كل يوم: المبيعات والمحاسبة والمخزون وإدارة علاقات العملاء وغيرها. أما الموقع فيعمل بطريقة مختلفة: تُصيَّر الصفحات على الخادم أولًا، ثم تُضاف فوقها طبقة أخف من جافاسكربت لإضافة سلوكيات مثل النوافذ المنبثقة والشرائح وأزرار «أضف إلى السلة». ولأن الأمرين يعملان بطريقتين مختلفتين، احتاجت أودو دائمًا إلى مقاربتين منفصلتين، لكنها قلّصت الفجوة بينهما بشكل ملحوظ هذا العام. تطبيقات الواجهة الخلفية (CRM والفوترة والمحاسبة ونقاط البيع) وميزات الموقع (المتجر الإلكتروني والاستبيانات) ترتبط جميعها بنفس الإطار الأساسي، لكن من أبواب مختلفة. إعادة بناء كاملة للموقع كان هذا هو التغيير الأبرز. لسنوات اعتمد جانب الموقع في أودو على ما يسمى «Public Widgets»، وهي طريقة أقدم وأثقل لربط سلوك جافاسكربت بصفحات الويب. كانت تعمل، لكنها بدت منفصلة عن بقية كود أودو، مما جعل تنقل المطورين بين العمل على الموقع والعمل على الواجهة الخلفية أصعب. وقد استبدلت أودو Public Widgets بالكامل بنظام جديد خفيف يسمى «Interactions». التغييرات الثلاثة الكبرى في الموقع: اختفاء Public Widgets، ومحرر HTML جديد، وإعادة بناء منشئ المواقع (Website Builder) باستخدام Owl. ما هي «Interactions»؟ يمكنك تخيّل Interactions كقريب أبسط وأخف من Owl، مصمَّم خصيصًا للمواقع. ليس الهدف منه استبدال واجهة تطبيق كاملة، بل إضافة سلوكيات صغيرة (مثل معالج نقر أو عدّاد أو إظهار/إخفاء عنصر) إلى صفحات ما زالت تُصيَّر على الخادم. الفائدة: أصبح كود الموقع وكود التطبيقات يتحدثان لغة متقاربة جدًا، ويمكن مستقبلًا أن تقدّم أودو صفحات خفيفة للغاية لا تحتاج إلى تحميل الإطار كاملًا. توصف Interactions بأنها بديل خفيف و«تفاعلي» لـ Public Widgets، ويمكنه الوصول مباشرة إلى خدمات أودو الأساسية مثل الإشعارات. هكذا يبدو الكود الجديد فعليًا: كلاس جافاسكربت حديث بقواعد واضحة لما يجب مراقبته في الصفحة (dynamicContent) وما يحدث عند الأحداث مثل النقر. منشئ مواقع أُعيد بناؤه فوق نظام Interactions الجديد، أعادت أودو بناء منشئ المواقع (Website Builder) بالكامل بالسحب والإفلات، وهو الأداة التي يصمم بها العملاء صفحاتهم، وذلك باستخدام Owl. شارك في هذا العمل نحو 30 مطورًا. والخبر الجيد لنا أن التقنية الأساسية تغيّرت، ولوحة الخيارات لها صياغة جديدة للمطورين، لكن الـ snippets المخصصة الحالية (اللبنات التي يستخدمها العملاء) يفترض أن تستمر بالعمل دون الحاجة لإعادة بنائها. واجهة منشئ المواقع الجديدة بعد إعادة بنائها بـ Owl: التجربة نفسها للمستخدم النهائي بالسحب والإفلات، مع كود حديث تحتها. الواجهة الخلفية (عميل الويب): تغييرات كبيرة أقل، ومكاسب هادئة أكثر على عكس الموقع، لم يتغير عميل الويب الأساسي، وهو الجزء الذي تعمل عليه المبيعات والمحاسبة والمخزون وكل تطبيقات الواجهة الخلفية، كثيرًا في الظاهر. وأكدت أودو أن Owl نفسه شهد أقل من 20 commit طوال العام. وهذا خبر جيد لنا: فهو يعني أن تخصيصاتنا ووحداتنا من غير المرجح أن تتعطل بسبب هذه الطبقة. بدلًا من ذلك، ذهب الجهد الحقيقي إلى جعل أودو أسرع وأكثر مرونة، خاصة في الاستخدام دون اتصال. التخزين المؤقت و«وضع عدم الاتصال» تبني أودو بهدوء نظام تخزين مؤقت (caching) يتيح للتطبيق تذكّر البيانات التي جلبها سابقًا بدل الانتظار دائمًا للخادم. يمكن للمطورين الآن تحديد استدعاءات بيانات معينة ليتم تخزينها مؤقتًا، إما في الذاكرة (RAM) أو على القرص، واختيار وتيرة تحديث هذا التخزين. نظرة على الكود: يمكن للمطورين الآن تحديد أي طلب بيانات ليُخزَّن مؤقتًا، واختيار مكان التخزين (الذاكرة أو القرص)، وتحديد وتيرة تحديثه. شاشات تبدو أسرع (العرض التفاؤلي) بفضل عمل التخزين المؤقت هذا، تستطيع أودو الآن عرض الشاشة فورًا باستخدام آخر بيانات معروفة، وجلب البيانات الحقيقية في الخلفية، ثم تحديث الشاشة بهدوء فقط إذا تغيّر شيء فعلًا. عمليًا، يجعل هذا التطبيق يبدو أسرع بشكل ملحوظ رغم أن الطلب الفعلي ما زال يحدث. ومن المهم الإشارة إلى أن أودو أوضحت أن هذا ليس تحريرًا كاملًا دون اتصال بعد، فغالبًا لا يمكنك إنشاء السجلات أو تعديلها دون اتصال بالإنترنت اليوم. الهدف هو جعل الأمور تبدو سريعة وقابلة للاستخدام عندما يكون الاتصال بطيئًا أو ينقطع لوقت قصير. «العرض التفاؤلي» (Optimistic rendering): اعرض ما لديك أولًا، واجلب أحدث البيانات في الخلفية، ولا تحدّث الشاشة إلا إذا تغيّرت البيانات فعلًا. تغييرات صغيرة يسهل أن تحبها إلى جانب إعادة البناء الكبيرة، هناك عدة تحسينات أصغر تستحق الإشارة لأن العملاء والمستخدمين سيلاحظونها مباشرة. إضافات أخرى في الإطار هذا العام: دعم الترجمات الخاصة بكل وحدة، وتوجيهات قوالب مخصصة للمطورين المتقدمين، وأدوات مطوّر أفضل. النقر بالزر الأوسط / Ctrl+نقر يعمل الآن بشكل صحيح في كل الواجهة، مثل فتح مهمة من عرض المشاريع في تبويب جديد، وهو أمر لم يكن ممكنًا قبل أودو 19. نوافذ منبثقة بنمط bottom sheet على الجوال: تُفتح النوافذ المنبثقة على الجوال افتراضيًا كـ«bottom sheet» تنزلق من أسفل الشاشة، وهو نمط أنسب بكثير للهواتف. إزالة jQuery من كود الموقع المعاد بناؤه. ما زالت مضمّنة تقنيًا للتوافق مع الإصدارات السابقة، لكن أي كود مخصص كتبناه ويعتمد عليها سيحتاج إلى مراجعة في مرحلة ما مستقبلًا. «لغة تواريخ» مصغّرة للمرشحات: يمكن كتابة المرشحات كتعبيرات بسيطة مثل "today" أو "-monday" أو "now -5M" بدلًا من كود معقد، مما يجعلها أسهل في القراءة والإعداد. نقطة نهاية /doc جديدة توفر مرجعًا يمكن تصفحه ومحدَّثًا دائمًا لكل نموذج وحقل في نسخة أودو معينة، وهو مفيد عند تحديد نطاق التكاملات أو كتابة التوثيق التقني للعملاء. النقر بالزر الأوسط أو Ctrl+نقر يفتح السجلات الآن في تبويب جديد بشكل موثوق في كل الواجهة، وهو تغيير صغير لكنه مرحَّب به جدًا في الاستخدام اليومي. على الجوال، تنزلق القوائم والمرشحات الآن من أسفل الشاشة كـ«bottom sheet» بدلًا من النافذة العائمة، وهو إحساس أقرب لتطبيقات الجوال. jQuery لم تختفِ تمامًا، لكنها لم تعد اعتمادًا أساسيًا في كود الموقع المعاد بناؤه. يمكن الآن كتابة المرشحات والتواريخ بلغة بسيطة بدلًا من التعبيرات المعقدة، وهو تحسين صغير يسهّل على من يضبط العروض والمرشحات المخصصة. نقطة النهاية /doc الجديدة توفر مرجعًا حيًا يمكن تصفحه لكل نموذج وحقل، وهي مفيدة في تحديد النطاق التقني وكتابة التوثيق. لماذا يهمنا هذا في عملنا اليومي على المشاريع، الخلاصات العملية هي: ينبغي أن تستمر الـ snippets والتخصيصات الحالية للموقع بالعمل، لكن أي وحدة مخصصة ترتبط بنظام Public Widget القديم أو تعتمد على jQuery في طبقة الموقع ستحتاج إلى مراجعة عندما نعود إلى تلك المشاريع. تخصيصات الواجهة الخلفية (معظم عملنا: CRM والمحاسبة والمخزون وMRP) تقف على أساس أكثر استقرارًا هذا العام، لأن Owl نفسه تغيّر قليلًا جدًا. العملاء الذين يستخدمون إصدارات أودو الأحدث سيلاحظون واجهة أسرع وأكثر ملاءمة للجوال دون أي جهد إضافي منا. قد توفر نقطة النهاية /doc الجديدة وقتًا حقيقيًا أثناء جمع المتطلبات وتحديد النطاق التقني في المشاريع الجديدة. معادلة التوازن الصعبة كان مطورو أودو صريحين في أن هذا النوع من التغيير لا يخلو من المخاطر. كل إعادة كتابة قد تكسر تخصيصًا لدى شخص ما، لكن التوقف عن التطوير ليس خيارًا أيضًا، فالكود يجب أن يتطور ليبقى قابلًا للصيانة ويواصل إضافة الميزات التي يطلبها العملاء. تلخيص أودو نفسها للمعادلة الصعبة: الحفاظ على استقرار الواجهة البرمجية، وإضافة الميزات، وتقليل الدين التقني، كل ذلك في وقت واحد. الخلاصة إصدار هذا العام هو في الحقيقة قصة نصفين: إعادة بناء كبيرة من الصفر لتقنية الموقع ومنشئ الصفحات (Interactions ومنشئ المواقع الجديد)، يقابلها عام أهدأ وأكثر تحفظًا لإطار الواجهة الخلفية الأساسي ركّز على السرعة والتخزين المؤقت وتحسينات صغيرة في سهولة الاستخدام. وبالنسبة لعملائنا، يعني ذلك تجربة أسرع وأحدث مع أقل قدر من الإرباك للتخصيصات الحالية، مع الانتباه أساسًا إلى أي كود قديم في طبقة الموقع اعتمد على Public Widgets أو jQuery.

Sep 30, 2026

بنية الخدمات المصغّرة: من التطبيقات المتجانسة إلى أنظمة قابلة للتوسّع ويمكن نشرها باستقلال

Muhammed Mishal

من التطبيقات المتجانسة إلى أنظمة قابلة للتوسّع ويمكن نشرها باستقلال مقال تقني عملي للمطوّرين والمعماريين وفرق الهندسة الصورة العامة بنية الخدمات المصغّرة (Microservices Architecture) هي أسلوب لتصميم البرمجيات كمجموعة من الخدمات الصغيرة المركّزة القابلة للنشر باستقلال. فبدلًا من وضع كل قدرة تجارية داخل تطبيق واحد كبير، يُقسَّم النظام حول مسؤوليات تجارية ذات معنى مثل المستخدمين والطلبات والمدفوعات والمخزون والبحث أو الإشعارات. وتعرض كل خدمة عقدًا واضحًا وتُخفي تفاصيل تنفيذها الداخلي عن بقية أجزاء المنصة. الفكرة المهمة ليست مجرد إنشاء الكثير من تطبيقات الخلفية. فالتغيير المعماري الحقيقي هو إرساء حدود واضحة للملكية. ينبغي أن تملك الخدمة قدرة ذات معنى، وقواعد عملها، وعادةً البيانات اللازمة لدعم تلك القدرة. ثم تتعاون الخدمات عبر واجهات برمجية (API) أو أحداث غير متزامنة. وتؤكد إرشادات البنية الحديثة بالمثل على النشر المستقل والواجهات جيدة التحديد والحالة التي تملكها الخدمة. الشكل 1. منصة خدمات مصغّرة نموذجية تضم بوابة API وخدمات مستقلة وقواعد بيانات تملكها الخدمات وناقل أحداث. لماذا أصبحت الخدمات المصغّرة مهمة كثيرًا ما يكون التطبيق المتجانس (Monolith) نقطة انطلاق ممتازة. فهو سهل نسبيًا في التشغيل والتصحيح والاختبار والنشر لأن التطبيق موجود كوحدة رئيسية واحدة. وتظهر المشكلات حين ينمو المنتج. تبدأ المجالات التجارية المختلفة بالتغيّر بسرعات مختلفة، ويحتاج أحد الأجزاء إلى طاقة حوسبة أكبر من غيره، ويصبح النشر محفوفًا بالمخاطر، ويبدأ فريق التطوير المتنامي بالتزاحم على قاعدة الشيفرة نفسها. تعالج الخدمات المصغّرة هذه الضغوط بالسماح لكل قدرة تجارية بالتطور بمعزل عن غيرها. يمكن نشر خدمة المدفوعات دون إعادة بناء خدمة المخزون. ويمكن توسيع خدمة الكتالوج ذات الحركة العالية دون إنشاء العدد نفسه من نسخ خدمة المدفوعات. كما تستطيع الفرق تولّي ملكية أوضح لكل خدمة. لكن المقابل هو أن التطبيق يصبح نظامًا موزّعًا، ولذلك يجب تصميم الشبكات والأعطال والاتساق والمراقبة والنشر بصورة صريحة. التطبيق المتجانس والخدمات المصغّرة: التحول المعماري يسهل فهم الفرق أكثر عند رؤيته بصريًا. ففي التطبيق المتجانس التقليدي، تنتمي شيفرة واجهة المستخدم ومنطق العمل ووحدات الأعمال المتعددة عادةً إلى تطبيق واحد قابل للنشر، وتتعامل غالبًا مع قاعدة بيانات مشتركة. أما في نظام الخدمات المصغّرة فتُفصل هذه القدرات إلى خدمات قابلة للنشر باستقلال. ويمكن لكل خدمة أن تملك قاعدة بيانات أو حدًّا آخر واضح التحكم للتخزين. الشكل 2. التحول المعماري من تطبيق متجانس واحد قابل للنشر إلى خدمات قابلة للنشر باستقلال. لا يعني هذا أن كل وظيفة تستحق خدمة خاصة بها. فالتجزئة المفرطة تخلق المشكلة المعاكسة: عمليات نشر كثيرة جدًا، واستدعاءات شبكة كثيرة جدًا، وتنسيق أكثر من اللازم. والهدف هو إيجاد حدود تمثّل قدرات تجارية مستقرة وتتيح تغييرًا مستقلًا ذا معنى. كيف يُبنى نظام الخدمات المصغّرة يبدأ النظام الإنتاجي عادةً من تطبيق ويب أو تطبيق جوال أو عميل خارجي. تدخل الطلبات عبر طبقة حافة، غالبًا بوابة API (API Gateway) أو موزّع أحمال. توفّر البوابة نقطة دخول خارجية ثابتة بينما يمكن لخدمات الخلفية أن تتغير داخليًا. ويمكنها أيضًا المشاركة في فرض المصادقة والتوجيه وتحديد معدل الطلبات وإنهاء TLS وتحويل الطلبات وغيرها من الاهتمامات العابرة. وتصف مايكروسوفت بوابة API بأنها نقطة دخول مركزية للتفاعل بين العملاء وخدمات التطبيق. الشكل 3. توفّر بوابة API نقطة دخول محكومة وتوجّه الطلبات إلى الخدمة المناسبة. خلف البوابة توجد خدمات المجال. فمنصة التجارة الإلكترونية مثلًا قد تضم قدرات العملاء والكتالوج والسلة والطلبات والمدفوعات والمخزون والتوصيل والإشعارات. وتعتمد الحدود الدقيقة على المجال التجاري. وتتجنب أقوى التصاميم كشف هياكل قواعد البيانات الداخلية، وتتواصل بدلًا من ذلك عبر واجهات مستقرة. حدود الخدمات أهم من عددها أصعب قرار في الخدمات المصغّرة هو تحديد أين تنتهي خدمة وأين تبدأ أخرى. الحد المفيد يبقي قواعد العمل المترابطة معًا. فإذا كانت عملية التحقق من الطلب وانتقالات حالة الطلب وقواعد العمل الخاصة بالطلبات موزّعة باستمرار على خمس خدمات، يصبح النظام صعب الفهم. وفي المقابل، إذا وُضعت الطلبات والمدفوعات والمخزون والإشعارات كلها في خدمة عملاقة واحدة، فإن الفريق يكون قد أعاد إنشاء تطبيق متجانس باسم مختلف. يفيد التصميم الموجَّه بالمجال (Domain-Driven Design) كثيرًا هنا لأنه يشجّع الفرق على تحديد القدرات التجارية والسياقات المحدودة (Bounded Contexts) قبل تقرير بنية الخدمات التقنية. ينبغي أن يكون السؤال: «أي قدرة تجارية تحتاج إلى ملكية مستقلة؟» بدلًا من: «كم واجهة برمجية نستطيع إنشاءها؟» كيف تتواصل الخدمات تتواصل الخدمات المصغّرة أساسًا عبر طلبات متزامنة أو رسائل غير متزامنة. يناسب التواصل المتزامن عبر HTTP أو gRPC الحالات التي يحتاج فيها المتصل إلى نتيجة فورية. فعلى سبيل المثال، قد تسأل خدمة الطلبات خدمةَ المخزون بشكل متزامن عمّا إذا كان يمكن حجز منتج ما. أما التواصل غير المتزامن فمختلف. فبدلًا من انتظار انتهاء خدمة أخرى، تنشر الخدمة حدثًا إلى وسيط رسائل (Message Broker). وتستهلك الخدمات الأخرى ذلك الحدث حين تكون جاهزة. يقلّل هذا الأسلوب الترابط المباشر، وهو مفيد بشكل خاص للإشعارات والتحليلات وسير عمل التكامل وسائر العمليات التي لا تحتاج إلى حجب الطلب الأصلي. الشكل 4. سير عمل طلب قائم على الأحداث تتفاعل فيه خدمات الدفع والمخزون والإشعارات باستقلال مع حدث الطلب. يُدخل الأسلوب غير المتزامن مفهوم الاتساق النهائي (Eventual Consistency). فقد يُقدِّم المستخدم طلبًا قبل أن تنتهي كل الخدمات اللاحقة من معالجته. وهذا ليس مشكلة بالضرورة، لكن على فرق المنتج والهندسة أن تحدّد صراحةً الحالات التي يمكن أن يكون عليها الطلب، وما يحدث عند فشل إحدى الخطوات اللاحقة. ملكية البيانات وفكرة قاعدة بيانات لكل خدمة من أهم القواعد في الخدمات المصغّرة ملكية البيانات. ينبغي عادةً أن تتحكم الخدمة في البيانات التي تنتمي إلى قدرتها التجارية. وعلى الخدمات الأخرى الوصول إلى تلك المعلومات عبر واجهة برمجية أو حدث، لا عبر تحديث جداول خدمة أخرى مباشرةً. لا يتطلب هذا أن تستخدم كل خدمة منتج قاعدة بيانات مختلفًا تمامًا. فقد يستخدم الفريق تقنية قاعدة البيانات نفسها عبر عدة خدمات مع الحفاظ على ملكية منطقية وحدود وصول. والهدف الأساسي هو تفادي وضع تستطيع فيه كل خدمة تعديل أي جدول بحرية. فهذا النوع من الملكية المشتركة يعيد الترابط الوثيق ويصعّب النشر المستقل. كما أن المعاملات الموزّعة أصعب من المعاملات داخل تطبيق واحد. وفي سير العمل الممتد عبر عدة خدمات، يمكن استخدام أنماط مثل ساغا (Saga) وصندوق الصادر المعاملاتي (Transactional Outbox) والمستهلكين عديمي الأثر عند التكرار (Idempotent Consumers) وإعادة المحاولة والإجراءات التعويضية للحفاظ على الاتساق التجاري. الأمان في بيئة الخدمات المصغّرة يجب أن يوجد الأمان في طبقات متعددة. تستطيع البوابة التحقق من رموز المصادقة وتطبيق سياسات عامة، لكن على كل خدمة أن تفرض التفويض للموارد التي تملكها. ولا ينبغي لأي خدمة أن تفترض أن الطلب آمن لمجرد أنه مرّ عبر البوابة. ينبغي للأنظمة الإنتاجية حماية بيانات الاعتماد والأسرار، والتحقق من صحة البيانات الواردة، واستخدام اتصال مشفّر عند الاقتضاء، وتطبيق حدود للمعدل على الواجهات العامة، والحفاظ على هويات واضحة للخدمات. ويزداد الأمان أهمية مع زيادة عدد الحدود الشبكية، لأن كل مسار اتصال إضافي يصبح جزءًا من سطح الهجوم على النظام. المرونة: التصميم مع توقّع الأعطال عادةً ما يفشل استدعاء الدالة داخل التطبيق المتجانس في العملية نفسها. أما في الخدمات المصغّرة فقد تعبر العملية نفسها عدة شبكات وعمليات مستقلة. وقد تكون الخدمة سليمة بينما تابعتها غير متاحة أو بطيئة أو تعيد أخطاء. لذلك فالفشل حالة معمارية طبيعية وليس وضعًا استثنائيًا. تمنع مهل الانتظار (Timeouts) تبعيةً غير متاحة من احتجاز الموارد إلى أجل غير مسمّى. ويمكن لإعادة المحاولة أن تتعافى من الأعطال العابرة، لكن ينبغي أن تكون محدودة وأن تستخدم التراجع التدريجي (Backoff) حتى لا تُغرَق خدمة متعثّرة. ويمكن لقواطع الدائرة (Circuit Breakers) إيقاف الاستدعاءات مؤقتًا إلى تابعة فاشلة، بينما تعزل الحواجز (Bulkheads) الموارد بحيث لا يستهلك حمل عمل واحد كل ما هو متاح للخدمة. وعدم تأثر النتيجة بالتكرار (Idempotency) لا يقل أهمية. فإذا أُعيدت محاولة طلب دفع بسبب فشل الشبكة، ينبغي أن يتمكن النظام من التعرف على العملية المكرّرة وتفادي خصم المبلغ من العميل مرتين. هذه القرارات التصميمية الصغيرة هي ما يجعل النظام الموزّع موثوقًا في الواقع العملي. قابلية المراقبة ليست خيارًا مع كثرة الخدمات، قد يمر إجراء واحد من المستخدم عبر البوابة وطبقة المصادقة وخدمة الطلبات وخدمة المدفوعات ووسيط الرسائل وخدمة المخزون وخدمة الإشعارات. ولم يعد النظر في ملف سجل خدمة واحدة كافيًا لفهم الطلب كاملًا. لذلك تجمع المنصة الناضجة بين سجلات مركزية منظّمة ومقاييس وتتبّع موزّع (Distributed Tracing) وفحوصات صحة وتنبيهات قابلة للتنفيذ. وتتيح معرّفات الارتباط (Correlation IDs) للمهندسين تتبّع الطلب عبر الخدمات. وتكشف المقاييس زمن الاستجابة وحجم الحركة ومعدلات الأخطاء وتشبّع الموارد. أما التتبّع الموزّع فيُظهر أين يُقضى الوقت وأي تابعة تسبب التباطؤ. الشكل 5. حلقة تسليم مستمر ومراقبة للخدمات المصغّرة المنشورة باستقلال. اختبار نظام موزّع يتطلب اختبار الخدمات المصغّرة أكثر من اختبارات الوحدة. تظل اختبارات الوحدة مهمة لقواعد العمل، لكن الخدمات تحتاج أيضًا إلى اختبارات تكامل لقواعد البيانات والتبعيات الخارجية، واختبارات واجهات برمجية للعقود العامة، واختبارات عقود (Contract Tests) للتأكد من اتفاق المُنتِجين والمستهلكين على شكل الطلبات والأحداث ومعناها. كما ينبغي اختبار رحلات العملاء الحرجة من طرف إلى طرف. ويلزم اختبار الأداء للخدمات عالية الحجم، بينما ينبغي أن يحاكي اختبار المرونة انتهاء المهل وأعطال التبعيات والرسائل المكرّرة والانقطاعات الجزئية. والغرض ليس إثبات أن الفشل لا يحدث أبدًا؛ بل التحقق من أن النظام يتصرف بصورة متوقعة حين يحدث الفشل. التكامل والنشر المستمران والنشر المستقل النشر المستقل من الأسباب الرئيسية التي تدفع المؤسسات إلى اعتماد الخدمات المصغّرة. ينبغي أن يكون لكل خدمة خط أنابيب قابل للتكرار يبني الشيفرة، وينفّذ الاختبارات الآلية، ويجري فحوصات الأمان، ويعبّئ الخدمة، وينشرها، ويتحقق من سلامتها، ويدعم التراجع عند الحاجة. تُستخدم الحاويات (Containers) كثيرًا لتعبئة الخدمات بصورة متسقة عبر البيئات. ثم تتولى منصات التنسيق الجدولة والتوسّع واكتشاف الخدمات وفحوصات الصحة وعمليات النشر المتدرجة. ويمكن لاستراتيجيات النشر مثل الإصدار الكناري (Canary) والأزرق-الأخضر (Blue-Green) تقليل مخاطر الإنتاج بحصر عدد المستخدمين المعرّضين للإصدار الجديد. التكلفة الخفية للخدمات المصغّرة لا تزيل الخدمات المصغّرة التعقيد، بل تنقله من تنظيم الشيفرة إلى تنسيق النظام. فبدلًا من عملية تطبيق واحدة، يشغّل الفريق الآن عمليات كثيرة. وبدلًا من استدعاء دالة محلي، قد يكون هناك طلب شبكي. وبدلًا من معاملة واحدة، قد يكون هناك سير عمل موزّع. وبدلًا من مجرى سجلات واحد، تلزم مراقبة مركزية. وهذا يعني أن الخدمات المصغّرة قد تكون خيارًا سيئًا لمنتج صغير أو فريق صغير أو نظام لم يستقر مجاله بعد. فالتطبيق المتجانس المعياري (Modular Monolith) يمكن أن يوفّر فصلًا قويًا للمسؤوليات مع بقائه بسيطًا تشغيليًا. ويمكن لاحقًا استخراج الخدمات حين يوجد سبب واضح يتعلق بالتوسّع أو النشر أو التنظيم أو الموثوقية. مثال عملي: معالجة الطلبات تخيّل سوقًا إلكترونية يقدّم فيها عميل طلبًا. يصل الطلب أولًا إلى بوابة API ويُوجَّه إلى خدمة الطلبات. تتحقق خدمة الطلبات من صحة الطلب وتنشئ طلبًا في مخزن بياناتها الخاص. ثم تنشر حدث OrderCreated. تستهلك خدمة المدفوعات الحدث وتنفّذ سير عمل الدفع. وتحجز خدمة المخزون الأصناف المطلوبة، بينما تجهّز خدمة الإشعارات رسالة بريد إلكتروني أو إشعارًا فوريًا. ولا تحتاج هذه الخدمات إلى التنفيذ كمعاملة كبيرة واحدة. فهي تحتفظ بحالتها الخاصة وتتواصل عبر عقود محددة جيدًا. إذا فشل الدفع، يمكن أن ينتقل الطلب إلى حالة «فشل الدفع». وإذا تعذّر حجز المخزون بعد نجاح الدفع، فقد يُطلق النظام إجراء دفع تعويضيًا أو يحيل الطلب إلى مراجعة يدوية، بحسب قواعد العمل. وهكذا تجعل البنية معالجة الفشل جزءًا صريحًا من سير العمل بدلًا من إخفائها داخل معاملة كبيرة واحدة. متى تختار الخدمات المصغّرة؟ الخدمات المصغّرة خيار قوي حين يتضمن المنتج حدودًا تجارية واضحة، أو عدة فرق تطوير، أو متطلبات توسّع مختلفة، أو إصدارات مستقلة متكررة، أو أحمال عمل تحتاج إلى عزل قوي. وهي مفيدة أيضًا حين يجب أن تتطور قدرات معينة بإيقاع مختلف عن بقية المنصة. لكنها ليست تلقائيًا أفضل بنية. فإذا كان التطبيق صغيرًا والفريق صغيرًا والنشر بسيطًا والمجال ما زال يتغير بسرعة، فقد يكون التطبيق المتجانس المعياري جيد التنظيم أكثر اقتصادية. وينبغي أن تتبع البنية المشكلةَ لا الموضة. الخلاصة بنية الخدمات المصغّرة تدور في جوهرها حول الاستقلال المنضبط. الهدف هو منح الفرق والقدرات التجارية فصلًا كافيًا لتتغير وتُنشر وتتوسّع وتتعافى دون أن تضطر المنصة كلها إلى التحرك كوحدة واحدة. وتجمع أقوى الأنظمة بين حدود خدمات واضحة، وواجهات برمجية منضبطة، وبيانات مملوكة، وأحداث غير متزامنة حيث يلزم، واتصال مرن، وأمان قوي، وتسليم آلي، ومراقبة عميقة. لذلك فإن أنجح منصة خدمات مصغّرة ليست تلك التي تضم أكبر عدد من الخدمات، بل تلك التي لكل خدمة فيها سبب واضح لوجودها، ومالك واضح، وعقد واضح، وقصة تشغيلية واضحة. ملاحظات مرجعية في مناقشة البنية، جرت الاستعانة بإرشادات معمارية عامة حديثة، منها توثيق مايكروسوفت أزور (Microsoft Azure) للخدمات المصغّرة وبوابة API.

Sep 30, 2026

البنية القائمة على الأحداث: من الأنظمة القائمة على الطلبات إلى منصات تفاعلية ضعيفة الترابط

Nakhul Krishna

من الأنظمة القائمة على الطلبات إلى منصات تفاعلية ضعيفة الترابط الصورة العامة البنية القائمة على الأحداث (Event-Driven Architecture أو EDA) هي أسلوب لتصميم البرمجيات حول «الأحداث»—وهي سجلات تصف أمرًا حدث فعلًا. فبدلًا من إجبار كل عملية لاحقة على الانتهاء داخل طلب متزامن واحد، تستطيع الخدمة نشر حدث وترك مستهلكين مستقلين يتفاعلون معه. والفكرة الأساسية هي ضعف الترابط: فالمُنتِج ينشر حقيقة تجارية دون الحاجة إلى معرفة كل مستهلك. كيف تعمل التدفق المعتاد هو: المُنتِج (Producer) ← وسيط الأحداث / ناقل الأحداث (Event Broker / Event Bus) ← المستهلكون (Consumers). فعلى سبيل المثال، عندما تُنشئ خدمة الطلبات طلبًا، يمكنها نشر حدث OrderCreated. وتستطيع خدمات الدفع والمخزون والإشعارات والتحليلات وغيرها استهلاك هذا الحدث كلٌّ على حدة. ولا يحتاج الطلب الأصلي إلى انتظار انتهاء كل العمليات اللاحقة. المكوّنات الأساسية تمثّل الأحداث حقائق مثل OrderCreated وPaymentCompleted وAppointmentCancelled. ينشئ المُنتِجون هذه الأحداث وينشرونها. ويشترك المستهلكون فيها وينفّذون مسؤولياتهم الخاصة. أما وسيط الأحداث فينقل الرسائل ويوزّعها، بينما تحدّد مخططات الأحداث (Event Schemas) العقد المشترك بين المُنتِجين والمستهلكين. وتُعدّ الملكية الواضحة أمرًا مهمًا: إذ ينبغي أن تتحكم كل خدمة في قواعد عملها وبياناتها بنفسها، بدلًا من تعديل قاعدة بيانات خدمة أخرى مباشرةً. لماذا نستخدم البنية القائمة على الأحداث؟ تفيد هذه البنية عندما يمكن تنفيذ العمل بشكل غير متزامن، أو عندما تحتاج عدة خدمات إلى التفاعل مع الحدث التجاري نفسه، أو عندما تحتاج أحمال العمل إلى التوسّع بشكل مستقل. ويمكنها تقليل الترابط المباشر بين الخدمات، والسماح بإضافة مستهلكين جدد دون تغيير المُنتِج الأصلي. وهي مفيدة بوجه خاص في الإشعارات والتحليلات ومعالجة التدقيق والتكاملات وسير العمل في الخلفية. التحديات الهندسية تُدخل الأنظمة غير المتزامنة مفهوم الاتساق النهائي (Eventual Consistency): فقد تعرض خدمات مختلفة حالات متباينة مؤقتًا أثناء معالجة الحدث. لذلك تحتاج الأنظمة الموثوقة إلى معالجة صريحة للرسائل المكرّرة وإعادة المحاولة وانتهاء المهلة والترتيب والمستهلكين الفاشلين. ويمنع المستهلكون عديمو الأثر عند التكرار (Idempotent Consumers) الأحداث المكرّرة من إنتاج آثار تجارية مكرّرة. أما معالجة الرسائل الميتة (Dead-Letter Handling) فتوفّر وجهة منضبطة للرسائل التي تفشل مرارًا. صندوق الصادر المعاملاتي تحدث مشكلة موثوقية شائعة عندما تُحدّث الخدمة قاعدة بياناتها بنجاح ثم تتعطل قبل نشر الحدث المقابل. ويحلّ نمط صندوق الصادر المعاملاتي (Transactional Outbox) هذه المشكلة بتخزين التغيير التجاري وسجل الحدث في المعاملة نفسها على قاعدة البيانات. ثم يرسل ناشر منفصل الحدث المخزَّن إلى الوسيط، مما يجعل التعافي ممكنًا إذا فشل النشر. البنية القائمة على الأحداث مقابل الخدمات المصغّرة ترتبط البنية القائمة على الأحداث والخدمات المصغّرة (Microservices) ببعضهما لكنهما ليستا الشيء نفسه. فالخدمات المصغّرة تحدّد قدرات تجارية مملوكة باستقلال وحدودًا للنشر؛ أما البنية القائمة على الأحداث فتحدّد أسلوب اتصال قائمًا على الأحداث. وقد تستخدم منصة الخدمات المصغّرة HTTP/gRPC المتزامن لبعض العمليات والأحداث غير المتزامنة لعمليات أخرى. كما يمكن أن يوجد الاتصال القائم على الأحداث دون خدمات مصغّرة. الخلاصة هدف البنية القائمة على الأحداث ليس مجرد إدخال Kafka أو RabbitMQ أو وسيط آخر. الهدف الحقيقي هو إرساء ملكية واضحة وإتاحة تفاعل المكوّنات باستقلال مع الحقائق التجارية. وتجمع البنية القوية بين عقود أحداث محددة جيدًا، وتسليم موثوق، وعدم تأثر النتيجة بالتكرار، وقواعد اتساق صريحة، ومعالجة للأعطال، والأمان، والاختبار، وقابلية المراقبة. وكما في الخدمات المصغّرة، ينبغي أن تتبع البنية المشكلةَ لا الموضة.

Sep 30, 2026

المسح بدل الكتابة: نظرة على تطبيق الباركود في أودو

Rinsa Sabir PC

الخلاصة السريعة معظم أخطاء المستودعات لا تنتج عن إهمال العاملين، بل عن الكتابة اليدوية. رمز منتج خاطئ، أو كمية خاطئة، أو موقع خاطئ — موظف مرهق يُدخل الأرقام نفسها للمرة المئتين في اليوم لا بدّ أن يخطئ في النهاية. يزيل تطبيق الباركود في أودو (Odoo Barcode) معظم هذه الكتابة تقريبًا. توجّه الماسح الضوئي أو كاميرا الهاتف نحو الملصق، ويتولى أودو الباقي. ما الذي يستبدله: البحث اليدوي عن المنتج أو الموقع في النموذج وكتابة الكميات باليد ما الذي يستخدمه بدلًا من ذلك: مسح الباركود بالهاتف أو بماسح يدوي أو بماسح خاتم يعمل بالبلوتوث أين يظهر: المخزون والتصنيع ونقطة البيع تشترك جميعها في محرك المسح نفسه محرك واحد يُستخدم في أكثر من مكان من السهل اعتبار الباركود ميزة تخص تطبيق المخزون وحده، لكن هذا ليس دقيقًا. فقد بنى أودو منطق قراءة الباركود مرة واحدة كجزء مشترك من الإطار البرمجي، ثم سمح للتطبيقات الأخرى بالاتصال به. يستخدمه المخزون في الاستلام والتسليم وجرد المخزون. ويستخدم التصنيع المحرك نفسه لاستهلاك المواد الخام وتسجيل المنتجات النهائية على أرض المصنع. وتستخدمه نقطة البيع عند الصندوق لاستدعاء المنتج فور مسح باركوده. وحتى فحوصات الجودة يمكن تشغيلها بعملية مسح. شاشات مختلفة ومنطق واحد — ولهذا فبمجرد أن تفهم آلية المسح في تطبيق واحد، تكون قد فهمت معظمها في بقية التطبيقات. المخزون والتصنيع ونقطة البيع والجودة تقرأ الباركود جميعها عبر محرك الترميز (Nomenclature) نفسه — اضبط القواعد مرة واحدة وتستفيد كل التطبيقات. المشكلة التي يحلّها فعلًا تخيّل شركة توزيع متوسطة الحجم. تصل شاحنة عليها أربعون منتجًا مختلفًا، بعضها في صناديق وبعضها على منصات سائبة، وبعضها مُتتبَّع بالدفعات لأن له تواريخ انتهاء. الطريقة القديمة للاستلام: يقف شخص أمام حاسوب مكتبي ومعه قائمة تعبئة ورقية، ويفتح عملية النقل المقابلة في أودو، ويكتب رمز كل منتج وكميته يدويًا أثناء مطابقتها مع الورقة. الأمر بطيء، ويُبعد الشخص عن عملية التفريغ الفعلية، وكل سطر يُكتب هو فرصة لتسلل خطأ إلى سجلات المخزون التي تعتمد عليها الشركة كلها. أما مع تطبيق الباركود، فيفتح الشخص نفسه التطبيق على هاتف أو ماسح يدوي، ويضغط على إيصال الاستلام المنتظر (أو يمسح باركودًا يفتحه مباشرة)، ويبدأ بمسح المنتجات فور نزولها من الشاحنة. كل عملية مسح تضيف المنتج إلى الإيصال بكمية واحدة؛ ومسحه مرة أخرى يزيد الكمية. وإذا كان المنتج مُتتبَّعًا بالدفعات، فقد يلتقط مسح باركوده رقم الدفعة وتاريخ الانتهاء في الحركة نفسها، بشرط أن يكون الملصق مطبوعًا بصيغة يتعرف عليها أودو. وعند اكتمال كل شيء، يكفي مسح باركود «تأكيد» (Validate) مطبوع لإغلاق العملية بأكملها. لا أحد يجلس أمام حاسوب مكتبي، ولا أحد يعيد كتابة أي شيء من القائمة الورقية. يصبح المخزون دقيقًا لحظة مسح آخر منصة، لا بعد ساعات حين يتفرغ أحدهم لإدخال البيانات. استلام الشحنة نفسها بالطريقة القديمة مقابل مسحها مباشرة — يصبح المخزون دقيقًا لحظة مسح آخر منصة. كيف يقرأ أودو الباركود فعلًا هذا الجزء يستحق الفهم إن كنت أنت من يقوم بالإعداد، لأنه ليس سحرًا — بل قواعد. كل باركود يُمسح يُقارَن بـ«ترميز الباركود» (Barcode Nomenclature)، وهو في حقيقته قائمة مرتّبة من الأنماط يعرف أودو كيف يفسّرها. رمز EAN-13 العادي يُطابَق مباشرة مع منتج. وملصق الموقع يُطابَق مع موقع في المستودع. ويمكن لرمز بصيغة خاصة أن يحمل وزنًا أو كمية داخل الباركود نفسه، وبهذه الطريقة يستطيع ملصق مطبوع من ميزان لكيلوغرام من الجبن أن يخبر أودو بعملية مسح واحدة ما هو المنتج وكم كميته. تُقارَن كل عملية مسح بقواعد الترميز حتى يجد أودو تطابقًا — منتج، أو موقع، أو رقم دفعة، أو أمر مثل «تأكيد». يأتي أودو بنظامَي ترميز جاهزين. الأول افتراضي ويغطي الحالات الشائعة التي تحتاجها معظم الشركات مباشرة. والثاني يتبع معيار GS1-128، وهو صيغة الباركود التي يستخدمها كثير من المصنّعين وتجار التجزئة على عبواتهم — ويمكنه حمل رمز المنتج ورقم الدفعة وتاريخ أفضل استخدام قبله والكمية في عملية مسح واحدة. وإذا كان العميل يطبع باركوداته الخاصة بصيغة لا تطابق أيًّا منهما، فيمكن إضافة قواعد جديدة إلى الترميز ليتعلم أودو التعرف على ملصقاته الحالية، بدلًا من مطالبة المستودع بتغيير صيغة الملصقات. يمكن لملصق GS1-128 واحد أن يحمل رمز المنتج ورقم الدفعة وتاريخ الانتهاء والكمية كلها في عملية مسح واحدة — دون حاجة إلى بحث منفصل. وهناك أيضًا ما يسميه أودو «باركودات الأوامر» — باركودات قابلة للطباعة لإجراءات مثل التأكيد (Validate) والتجاهل (Discard) والطباعة (Print) أو إضافة كمية محددة. وبعد طباعتها ولصقها قرب محطة المسح، يستطيع المشغّل إتمام عملية نقل كاملة دون أن يلمس لوحة مفاتيح أو فأرة أو شاشة لمس. كل شيء يتم عبر الماسح. ما يستحق معرفته عنه لا حاجة إلى أجهزة خاصة للبدء. كاميرا الهاتف أو الجهاز اللوحي تكفي للأحجام المتوسطة. أما المستودع المزدحم الذي يعمل بهذا طوال اليوم، فالماسح اليدوي المخصّص أو ماسح الخاتم المقترن عبر البلوتوث أكثر راحة بكثير، ويدعم أودو النوعين. يستمر بالعمل حين ينقطع الواي فاي. ما دام التطبيق قد فُتح مرة واحدة على الأقل أثناء الاتصال بالإنترنت، فإنه يخزّن ما يحتاجه مؤقتًا ويتيح متابعة المسح خلال أي منطقة بلا تغطية في المستودع. وتتم مزامنة كل شيء تلقائيًا مع الخادم عند عودة الاتصال. التجميع بالدفعات وبالموجات. بدلًا من معالجة أوامر التسليم واحدًا تلو الآخر، يستطيع المشغّل تجميع عدة أوامر معًا في جولة واحدة داخل المستودع، بينما يخبره التطبيق بما عليه أخذه وأين يضعه. تُلتقط أرقام الدفعات والأرقام التسلسلية من المصدر. فبدلًا من أن يكتب أحدهم الرقم التسلسلي في نموذج لاحقًا، يُمسح عند الاستلام أو الإنتاج، وهو بالضبط الموضع الأقل عرضة لأخطاء الكتابة. يستفيد التصنيع بقدر ما يستفيد المستودع. يستطيع مشغّل الإنتاج مسح المكوّنات التي يستهلكها ورقم دفعة المنتج النهائي الذي أنتجه للتو، مباشرة على أرض المصنع، دون العودة إلى حاسوب المكتب. مثال واقعي لنأخذ شركة تجمّع وتشحن حقائب إلكترونيات. كانت جولة الإرسال بعد الظهر تسير هكذا: يطبع فريق المستودع أوامر التسليم لذلك اليوم، ويتجول في الأرضية ومعه لوحات كتابة، ويسحب الأصناف الصحيحة من الذاكرة، ثم يسلّم كل شيء إلى شخص على مكتب يطابق ذلك كله في أودو ويكتب الكميات قبل تأكيد كل عملية تسليم. ومع وصول أوامر البيع طوال اليوم، كان المكتب يتأخر بانتظام ساعة أو ساعتين، مما ظهر في صورة تأخر تأكيدات الشحن للعملاء. بعد تحويل ذلك الفريق إلى تطبيق الباركود، انقلبت العملية. يفتح موظفو المستودع التطبيق، ويدخلون إلى دفعة من عمليات التسليم الجاهزة لذلك اليوم، فيرشدهم التطبيق عبر كل موقع سحب بالترتيب. يمسحون الموقع، ثم المنتج، ثم الموقع التالي، وهكذا. لا لوحة كتابة، ولا جولة منفصلة لإدخال البيانات، ولا فجوة بين «غادر المنتج الرف فعليًا» و«عرف أودو أنه غادر الرف». والشخص الذي كان يجلس على المكتب لإعادة كتابة كل شيء يقضي وقته الآن في معالجة الاستثناءات — المشكلات الحقيقية التي تحتاج إلى إنسان، لا الإدخال الروتيني الذي لم يكن يحتاج إليه أصلًا. لماذا يستحق التوصية به بالنسبة للعملاء الذين ينقلون مخزونًا ماديًا — وهم معظمهم بصورة ما — يُعدّ الباركود من أكثر المكاسب وضوحًا التي يمكننا تقديمها دون جهد تطوير كبير. فتفعيله في معظمه عملية إعداد: طباعة الملصقات، وضبط الترميز (أو تعديله)، وتدريب فريق الأرضية على تسلسل المسح في عملياته. ونادرًا ما تكون هناك حاجة إلى كتابة شيفرة مخصّصة، إلا إذا كانت ملصقات العميل الحالية لا تطابق ترميزًا قياسيًا، وفي هذه الحالة تكفي عادةً إضافة بضع قواعد إلى الترميز. تحسّن سريع وواضح يلاحظه العملاء خلال أيام، مما يجعله محطة مبكرة جيدة في مشروع تطبيق المخزون أو التصنيع. الأخطاء التي كانت تظهر كفروقات في المخزون أثناء جرد نهاية الشهر تميل إلى الانخفاض بوضوح بمجرد إزالة الكتابة من العملية. يصلح للأحجام الصغيرة كما يصلح للكبيرة — فمستودع من خمسة أشخاص يستفيد منه تقريبًا بقدر مستودع من مئة شخص، لأن المشكلة التي يحلّها (أخطاء الإدخال اليدوي) لا تعتمد فعلًا على عدد العاملين. أين تكمن حدوده إنه ليس حلًّا لمستودع لم يُنظَّم بعد. فإذا لم تكن مواقع التخزين معنونة بملصقات، أو لم تكن للمنتجات باركودات مطبوعة في أي مكان، فلن يجد المسح شيئًا يمسحه. كما يحتاج الترميز إلى بعض العناية أثناء الإعداد — فإذا تطابقت صيغتان مختلفتان للملصقات مع القاعدة نفسها عن طريق الخطأ، فقد يقرأ التطبيق شيئًا خاطئًا من الباركود، وهذا أسوأ من عدم المسح أصلًا. إنها أداة تكافئ قدرًا من الإعداد والتدريب المسبقين؛ ولا تغني المستودع عن ترتيب أساسياته (الملصقات والمواقع ورموز المنتجات) أولًا. الخلاصة لا يُتحدَّث عن الباركود بقدر التطبيقات الأكبر، ربما لأنه لا يبدو كثيرًا بمفرده — فهو في معظمه شاشة هاتف بزر مسح كبير. لكنه يزيل بهدوء واحدًا من أكثر أجزاء تشغيل المستودع أو أرضية المصنع عرضة للأخطاء: كتابة رموز المنتجات والكميات نفسها مرارًا وتكرارًا، طوال اليوم، كل يوم. وأي عميل يجري حركة مخزون مادية حقيقية، فمن المفيد التحقق مما إذا كان يستخدمه بالفعل، وإن لم يكن، فلماذا.

Sep 30, 2026

تقييم المخزون في Odoo 20: أربعة حسابات استحقاق جديدة لتوضيح تباين المخزون

Muhammed Shayar CV

أخيرًا ستعرف لماذا لا يساوي حساب فروقات المخزون صفرًا المشكلة التي يحلّها هذا التحديث إذا سبق لك إقفال الدفاتر في أودو 18 أو 19 باستخدام التقييم المستمر (Perpetual / Automated) للمخزون، فأنت تعرف هذه المشكلة جيدًا: تُستلم البضاعة ولم تصل فاتورة المورّد بعد، أو تُسجَّل الفاتورة قبل أن تصل البضاعة فعليًا. وفي جانب المبيعات تظهر الفجوة نفسها — إما أن تخرج التسليمات قبل إصدار الفواتير، أو تصدر الفواتير قبل تسليم البضاعة. كان أودو يضع كل ذلك في حساب واحد هو حساب فروقات المخزون (Stock Variation). كان الإجمالي صحيحًا، لكنك في نهاية الشهر لا تستطيع معرفة سبب عدم مساواة الرصيد للصفر. فينتهي بك الأمر إلى إنشاء حسابات إضافية يدويًا وتسجيل قيود يومية خاصة بك لمجرد اكتشاف السبب. يعالج أودو 20 هذه المشكلة بشكل أصلي، بتقسيم حساب الفروقات الواحد إلى أربعة حسابات استحقاق مخصّصة لكل حالة، وبأتمتة القيود المرتبطة بها. أودو 19 مقابل أودو 20: ما الذي تغيّر فعلًا؟ الجانب أودو 19 أودو 20 وضوح الفروقات حساب واحد لفروقات المخزون (Stock Variation) يمتص كل فجوات التوقيت تقسيم إلى 4 حسابات مخصّصة: فواتير قيد الإصدار (Invoices to be Issued)، مفوتر غير مسلَّم (Invoiced Not Delivered)، فواتير قيد الاستلام (Bills to Receive)، مفوتر غير مستلم (Billed Not Received) مكان الإعداد فئة المنتج فقط فئة المنتج، بالإضافة إلى قسم مركزي جديد في الإعدادات العامة ← المحاسبة ← «الاستحقاقات» (Accruals)، ترثه كل فئة تلقائيًا جهد التهيئة كان على المستشار أو المستخدم إنشاء هذه الحسابات الأربعة في دفتر الأستاذ يدويًا وإعداد القيود كل شهر دليل الحسابات القياسي يأتي بها جاهزة (مثل 121200 و212000 و211100 و141000) — ما عليك سوى الربط والبدء تسمية تقييم المخزون «مستمر» (Perpetual) / «دوري» (Periodic) أُعيدت تسميتهما إلى «مستمر (عند الفوترة)» Perpetual (at invoicing) / «دوري (عند الإقفال)» Periodic (at closing) — لتوضيح توقيت ترحيل التقييم صراحةً قيود الاستحقاق والعكس قيود يومية يدوية لتسجيل الاستحقاق ثم عكسه يدويًا في الفترة التالية أمر «إنشاء القيود» (Generate Entries) ينشئ قيد الاستحقاق تلقائيًا، ويرحّل أودو قيد العكس في اليوم التالي من تلقاء نفسه تشخيص نهاية الشهر فحص رصيد فروقات المخزون يدويًا لمعرفة السبب تقرير تقييم المخزون يعرض الحساب المحدّد (وبالتالي السبب المحدّد) في قسم مستقل توضّح لقطتا الشاشة أدناه ذلك عمليًا: شاشة الإعدادات العامة ← الاستحقاقات تتيح لك تحديد حسابات فواتير قيد الإصدار (121200)، ومفوتر غير مسلَّم (212000)، وفواتير قيد الاستلام (211100)، ومفوتر غير مستلم (141000) مرة واحدة على مستوى الشركة — ثم ترث كل فئة منتجات (مثل «Goods» في الصورة) هذه الحسابات ما لم تُعدَّل، إلى جانب خيار تقييم المخزون المعاد تسميته Perpetual (at invoicing) وحقلَي حساب المخزون وفروقات المخزون الموجودين سابقًا. الشكل 1 — الإعدادات العامة ← المحاسبة ← الاستحقاقات: الحسابات الافتراضية على مستوى الشركة لاستحقاقات المبيعات والمشتريات. الشكل 2 — فئة المنتج («Goods») ترث حسابات الاستحقاق الأربعة، مع طريقة التقييم المعاد تسميتها «مستمر (عند الفوترة)». الحسابات الأربعة الجديدة الحساب النوع الجانب يُفعَّل عندما فواتير قيد الاستلام (Bills to Receive) التزام متداول المشتريات استُلمت البضاعة ولم تُنشأ فاتورة المورّد بعد مفوتر غير مستلم (Billed Not Received) أصل متداول المشتريات أُنشئت فاتورة المورّد ولم تُستلم البضاعة بعد فواتير قيد الإصدار (Invoices to be Issued) أصل متداول المبيعات سُلّمت البضاعة ولم تُنشأ الفاتورة بعد مفوتر غير مسلَّم (Invoiced Not Delivered) التزام متداول المبيعات أُنشئت فاتورة العميل ولم تُسلَّم البضاعة بعد خطوات الإعداد دليل الحسابات: تأتي الحسابات الأربعة جاهزة افتراضيًا (مثل 121200 و212000 و211100 و141000) — ويمكنك إنشاء حساباتك الخاصة إن أردت أكوادًا مخصّصة. الإعدادات العامة ← المحاسبة ← الاستحقاقات: حدّد هنا الحسابات الافتراضية لاستحقاقات المبيعات واستحقاقات المشتريات على مستوى الشركة — وترثها كل فئة منتجات تلقائيًا. فئة المنتج ← تقييم المخزون: اختر طريقة التكلفة (مثل Perpetual (at invoicing) / متوسط التكلفة)، ثم عدّل أيًّا من الحسابات الأربعة لكل فئة عند الحاجة. ويمكنك أيضًا إعادة تسمية حساب «فروقات المخزون» الافتراضي إلى اسم أوضح مثل «تكلفة الإيرادات». بعد الربط لا تحتاج إلى أي قيود يومية يدوية — إذ يوجّه أودو فروقات التوقيت إلى الحساب الصحيح تلقائيًا. جانب المشتريات: سيناريوهان بضاعة مستلمة والفاتورة معلّقة تم اعتماد استلام مشتريات بقيمة 100 دولار ولم تُنشأ فاتورة المورّد بعد. يعرض تقرير تقييم المخزون مبلغ 100 دولار ضمن «فواتير قيد الاستلام» بدلًا من سطر فروقات عام. ينشئ «إنشاء القيود» في نهاية الشهر قيد الاستحقاق: يُدين حساب تقييم المخزون عند الاستلام؛ ثم يصفّر قيد الاستحقاق فروقات المخزون ويُقيّد 100 دولار دائنًا في «فواتير قيد الاستلام». الميزانية العمومية: الأصول المتداولة +100 (المخزون)، والالتزامات المتداولة +100 (فواتير قيد الاستلام) — استحقاق نظيف، وفروقات الأرباح والخسائر تصبح صفرًا. يعكس أودو هذا القيد تلقائيًا في اليوم التالي، فعند ترحيل الفاتورة الفعلية ينتهي الاستحقاق بسلاسة. فاتورة واردة والبضاعة لم تصل من المورّد أمر شراء ثانٍ بتكلفة 200 دولار أُكّدت فاتورته، لكن الاستلام لم يتم بعد. يعرض التقرير الآن «مفوتر غير مستلم» بمبلغ 200 دولار إلى جانب «فواتير قيد الاستلام» السابقة بمبلغ 100 دولار. يصفّر «إنشاء القيود» تكلفة البضاعة المباعة، ويُدين «مفوتر غير مستلم»، ويُقيّد فروقات المخزون دائنًا. الميزانية العمومية: الأصول المتداولة = 100 دولار (المخزون الفعلي) + 200 دولار («مفوتر غير مستلم» وهو بمثابة دفعة مقدمة لبضاعة في الطريق) = 300 دولار؛ بينما تحمل الالتزامات المتداولة 100 دولار «فواتير قيد الاستلام». وبمجرد استلام البضاعة فعليًا يُصفَّى هذا الحساب تلقائيًا. جانب المبيعات: سيناريوهان بضاعة مسلّمة والفاتورة معلّقة أمر بيع مؤكَّد وتم تسليمه، لكن فاتورة العميل لم تصدر بعد — وهي الحالة الأكثر شيوعًا في نهاية الشهر. يعرض تقرير تقييم المخزون قيمة البضاعة المسلّمة ضمن «فواتير قيد الإصدار» بدلًا من فروقات غير مفسَّرة. ينتج «إنشاء القيود» قيد الاستحقاق على جزأين: القيد 1 — مبيعات المنتجات دائنة ← فواتير قيد الإصدار مدينة (وهي وظيفيًا بمثابة حساب «Stock Interim Delivered» في أودو 18) ← فروقات المخزون دائنة ← تكلفة البضاعة المباعة مدينة. القيد 2 — فروقات المخزون مدينة مقابل دائن القيد 1 ← يتصفّر الرصيد ← تقييم المخزون دائن. العكس (تلقائي في اليوم التالي): يرحّله أودو من تلقاء نفسه — دون حاجة إلى عكس يدوي. الأرباح والخسائر: تكلفة المبيعات وفروقات المخزون كلاهما يتصفّر؛ وتتطابق الإيرادات مع تكلفة البضاعة المباعة للفترة حتى قبل وجود الفاتورة. الميزانية العمومية: تظهر «فواتير قيد الإصدار» ضمن الأصول المتداولة — إيراد مُكتسَب لم يُفوتر بعد. عند إنشاء الفاتورة الفعلية لاحقًا، تُدين حساب الذمم المدينة وتُقيّد الإيراد دائنًا كالمعتاد؛ ويضمن العكس التلقائي عدم احتساب أي مبلغ مرتين. فاتورة صادرة والتسليم معلّق الفجوة المعاكسة: فاتورة العميل مؤكَّدة، لكن البضاعة لم تغادر المستودع فعليًا. يعرض التقرير القيمة ضمن «مفوتر غير مسلَّم» — للتنبيه إلى أن الإيراد سُجّل قبل التسليم الفعلي. يُرحَّل هذا كالتزام متداول: لقد فوترت العميل ولا تزال مدينًا له بالبضاعة. لماذا يهمّ المنطق الكامن وراء ذلك هذا في حقيقته دمج بين أودو 18 وأودو 19 في نموذج واحد: مثل أودو 18، يستخدم حسابات وسيطة لسدّ فجوة التوقيت بين حركة المخزون الفعلية والمستند المالي. ومثل أودو 19، تبقى هذه الحسابات ظاهرة في تفاصيل تقرير تقييم المخزون، فيمكنك تتبّع سبب أي فرق دون مغادرة التقرير. وخلافًا للإصدارين، يؤتمت «إنشاء القيود» دورة الاستحقاق والعكس بالكامل، وأصبحت الحسابات افتراضيات قياسية في دليل الحسابات تُضبط مركزيًا، بدلًا من أن تبنيها بنفسك. الخلاصة لأي نشاط يعمل بتقييم «مستمر (عند الفوترة)» — وهو ما يغطي معظم تطبيقات أودو للمخزون والمحاسبة — يمثّل هذا ترقية وظيفية حقيقية لا مجرد تغيير شكلي. فهو يأخذ حساب فروقات المخزون «الصندوق الأسود»، ويقسّمه حسب السبب، ويتيح الإعدادات الافتراضية على مستوى الشركة في الإعدادات العامة، ويؤتمت عملية الإقفال بأكملها حوله. وهذا يستحق أن يؤخذ في الحسبان عند تقييم الترقية إلى أودو 20.

Sep 30, 2026

ODOO APPOINTMENTS Booking Straight From Google How Odoo Appointments and Google Reserve turn a search into a confirmed booking

Nidha Rahman

How Odoo Appointments and Google Reserve turn a search into a confirmed booking For many local businesses, the customer's journey no longer begins at the company website. It begins with a search. A prospective patient, diner or client types a service and a location into Google, scans the listings that appear, and decides within moments whom to contact. The businesses that make it easiest to act on that decision are the ones that win the booking. Odoo's Appointments app can now meet customers at that moment. Through its Google Reserve integration, customers book directly from Google Search, Google Maps and the Google Assistant, and the booking is created in Odoo without the customer having to visit the company's website. This article explains how the integration works, what else Odoo 19 adds to Appointments, and what to verify before recommending it to a client. Key Points Customers can book from Google Search, Google Maps and the Google Assistant, and the booking is created directly in Odoo. Setup is configuration rather than development: one module, one merchant record and one synchronization. Eligibility is set by Google, and the business address must match its Google Maps listing exactly. Why the Booking Channel Matters A conventional online booking asks a lot of the customer. They find the listing, open the website, locate the booking page, choose a time and complete a form. Every step is a chance to lose them. Behind the scenes, each channel that accepts bookings, whether a phone line, a web form or a walk-in, also creates work for staff, who must reconcile the results in a single system. Consider an illustrative case: a physiotherapy clinic that closes at six. A prospective patient finds it on Google Maps at 9:40 in the evening. Without an online option, the best likely outcome is that the patient remembers to call the next day. With Google Reserve connected to Odoo, the patient can choose from the availability Odoo supplies and confirm a slot on the spot. The patient's details are written to Odoo Contacts, and the appointment is already in the therapist's calendar the next morning. Nobody has to answer a call, and nobody has to re-enter anything. Figure 1. How a booking travels from a Google search to an Odoo calendar. How the Integration Works Configuration takes place entirely inside Odoo. According to Odoo's documentation, the process has four steps: Install the module. Install Appointment Google Reserve from the Apps menu. The default Apps filter must be removed before searching for "Google". Open an appointment type. In the Appointments app, open an existing appointment type or create a new one, then go to its Google Bookings tab. Add the merchant. Select or create a Google Reserve Merchant and complete the business details. The business address must match the Google Maps listing exactly. Synchronize. Select Synchronize with Google Reserve. The first synchronization can take up to 24 hours to propagate to Google's systems. Figure 2. The setup flow, including the address check flagged in Odoo's documentation. Odoo also exposes the settings Google expects from a booking partner. These include availability based on resources such as staff members or tables, automatic assignment, a scheduling window of up to 31 days, minimum lead times for booking and cancelling, and email reminders. Once the connection is live, the details a customer enters on Google are written to Odoo Contacts, and the booking appears in Odoo alongside those made through any other channel. Restaurants follow a variation of the same model. Tables defined on the Point of Sale floor plan, each with a maximum number of guests, act as the bookable resources, and reservations made through Google appear in the floor plan and the booking pipeline. Other Appointments Improvements in Odoo 19 The Google integration sits alongside several other additions to Appointments listed in Odoo 19's release notes. Group sessions allow a capacity limit and multiple bookings in a single slot, which suits classes and workshops. An appointment type can move from a weekly recurring schedule to a flexible one, with durations shown on the booking page. Booking calendars can be embedded on external websites using an iframe, which is useful for clients whose sites are not built on Odoo. Reusable default questions keep intake forms consistent and make the answers easier to report on. And when a confirmed appointment creates a Field Service task, the appointment details are carried into that task automatically. Practical Considerations Eligibility is determined by Google rather than Odoo. Google's documentation requires a business with a physical location whose address can be matched to its Maps database, and eligibility may further depend on business type and country. It should be confirmed for each client before the feature is proposed. Address matching deserves particular care. Odoo's documentation warns that mismatches in formatting or unit numbers can cause synchronization to fail or prevent the listing from appearing, and because the first synchronization can take up to a day, testing should be planned accordingly. The integration is an Enterprise feature; Odoo has described synchronization with Google Bookings as available from Odoo Enterprise 18 onward. Finally, customers see the availability that Odoo supplies, so the integration is only as reliable as the calendars behind it. Out-of-date staff availability will lead to bookings the business cannot honour. Conclusion Google Reserve addresses a simple problem: customers who are ready to book at a moment when the business is unreachable. For clients whose revenue depends on appointments or reservations, and who already use or are considering Odoo Appointments, the integration adds a channel customers already rely on, at the cost of a modest amount of configuration. The real work lies in verifying eligibility and aligning the business's details with its Google listing, and doing that before the feature is promised is what keeps the rollout smooth. Sources and Further Reading Google reserve integration. Odoo 19.0 documentation, Appointments. odoo.com/documentation/19.0/applications/productivity/appointments/google_reserve.html Odoo 19 Release Notes. Appointments section. odoo.com/odoo-19-release-notes POS Restaurant: Reservations with Google Bookings. Odoo blog. odoo.com/blog/business-hacks-1/pos-restaurant-reservations-with-google-bookings-2211 Skip the line, book online with Google table reservation integrated with Odoo. Odoo Experience 2025 session summary. oduist.com/blog/odoo-experience-2025-ai-summaries-2/261-skip-the-line-book-online-with-google-table-reservation-integrated-with-odoo-263 Reservations: Overview and Eligibility. Google Actions Center documentation. developers.google.com/actions-center/verticals/reservations/bl/overview

...