تقوم مكاتب المحاماة على الوقت القابل للفوترة. وعندما يكون النظام الذي يتتبع القضايا وقيود الوقت (Legalsense) منفصلًا عن النظام الذي يصدر الفواتير ويمسك الدفاتر (زوهو Books)، تتحوّل كل دورة فوترة إلى عملية إعادة إدخال للبيانات — إذ ينسخ قسم المالية الأرقام بين الشاشات، ويتسع ببطء الفارق بين ما أُنجز من عمل وما صدرت به فواتير. يوضّح هذا الدليل كيف يمكن لمكتب محاماة أن يربط Legalsense بزوهو Books بحيث يبقى العملاء والقضايا وقيود الوقت والفواتير والمدفوعات متناغمين — ويحصل الشركاء على تقارير مالية يمكنهم الوثوق بها.
ملاحظة في البداية: Legalsense منصة طرف ثالث لإدارة الممارسة القانونية، وليست أحد منتجات ونس ابس، ولا يوجد زر جاهز "Legalsense ↔ زوهو Books" يمكن تفعيله. فالتكامل يُبنى بناءً — باستخدام أدوات الأتمتة وواجهات برمجة التطبيقات الخاصة بزوهو، أو قطعة من الوسيطة البرمجية المخصّصة. وفيما يلي المقاربات الواقعية، وما ينبغي مزامنته، والقرارات التي تجعل النتيجة متينة لا هشّة.
لماذا يتباعد النظامان
Legalsense هو نظام التسجيل للجانب القانوني: العملاء، والقضايا، والأشخاص العاملون عليها، وما يُسجَّل على كل قضية من وقت ومصروفات. أما زوهو Books فيملك الجانب المالي: العملاء، والفواتير، والمدفوعات، والضرائب، ودفتر الأستاذ الذي يغذّي حساب الأرباح والخسائر وإقرارات ضريبة القيمة المضافة. وعند ترك النظامين دون ربط، تظهر الفجوة على هيئة:
- إدخال مزدوج للبيانات. يجب إعادة إنشاء كل عميل وقضية جديدة في Legalsense على شكل عميل في زوهو Books قبل أن يتسنّى إصدار أي فاتورة.
- تأخّر الفوترة وتسرّب الإيرادات. لا يتحوّل الوقت المسجَّل هذا الأسبوع إلى فاتورة إلا حين يجمعه أحدهم يدويًا — والساعات التي لا تُنقل أبدًا هي ببساطة إيرادات ضائعة.
- عناء التسوية. عندما تَرِد دفعة في زوهو Books، لا شيء يُعلِم Legalsense بأن القضية قد سُدّدت، فيختلف النظامان حول ما هو مستحق.
- تقارير لا يمكن الوثوق بها. سؤال "ما حجم العمل قيد التنفيذ لدينا، وكم حصّلنا عن كل مجال ممارسة؟" تأتي إجابته مختلفة من النظامين.
الهدف هو تدفّق واحد ومؤتمت: إنشاء العميل والقضية مرة واحدة، والتقاط الوقت مرة واحدة، وإصدار الفاتورة مرة واحدة، والتحصيل مرة واحدة — مع وضوح ذلك كله في الموضعين معًا.
ما الذي ينبغي مزامنته فعلًا (وفي أي اتجاه)
قبل اختيار أداة، حدِّد نموذج البيانات. تتلخّص معظم عمليات تكامل مكاتب المحاماة في أربعة تدفّقات، وضبط الاتجاه بشكل صحيح أهمّ من الأدوات نفسها.
- العملاء ← العملاء (Customers). يُقابَل العميل (الكيان الذي تصدر له الفاتورة) في Legalsense بعميل (Customer) في زوهو Books. وLegalsense هو مصدر الحقيقة؛ وزوهو Books هو المتلقّي. اعتمد المطابقة على مفتاح ثابت — رمز عميل أو بريد إلكتروني — لا على الاسم وحده، وإلا أنشأت عملاء مكرّرين.
- القضايا ← المشاريع / سياق بنود السطور. القضية هي الوحدة التي تصدر الفواتير على أساسها. مثّلها في زوهو Books بوصفها مشروعًا (إن أردت تتبّع العمل قيد التنفيذ لكل قضية) أو احمل مرجع القضية على كل بند من بنود الفاتورة. هذا قرار المطابقة الأكثر تأثيرًا في التقارير لاحقًا، فاحسمه أولًا.
- قيود الوقت ← الفواتير. يتحوّل الوقت والمصروفات القابلة للفوترة بعد اعتمادها إلى بنود سطور في الفاتورة ضمن زوهو Books. لا تُزامن سوى الوقت المعتمَد فحسب — فدفع القيود غير المراجَعة مباشرة إلى فاتورة العميل هو الطريق الذي تفرط به المكاتب في الفوترة وتفقد الثقة.
- المدفوعات ← العودة إلى القضية. عندما يسدّد العميل فاتورة في زوهو Books، ينبغي أن تتدفّق هذه الحالة عائدةً إلى Legalsense كي تعكس القضية ما تمّ تسويته. وهذا هو التدفّق الذي تتخطّاه المكاتب غالبًا، وهو الذي يُبقي النظامين متّسقين.
بداية رشيدة: زامِن العملاء والفواتير أولًا، وأثبِت صحّة الدورة، ثم أضِف الكتابة العكسية للمدفوعات. لا تؤتمت التدفّقات الأربعة كلها في اليوم الأول.
المقاربة الأولى — زوهو Flow (منخفضة الكود، الأسرع في التهيئة)
زوهو Flow هو منصة زوهو للتكامل كخدمة: تبني فيها "تدفّقات" تنطلق عند وقوع حدث في تطبيق وتتصرّف في آخر، عبر منشئ مرئي ومنطق مدمج (قرارات، ودوال مخصّصة، وفترات تأخير). وهو المحطة الأولى الطبيعية لأنه لا يتطلّب خوادم خاصة بك.
يُطلِق Legalsense (أو وسيط — خطّاف ويب، أو إسقاط ملف CSV مشترك) حدثًا مثل عميل جديد أو فاتورة معتمَدة، فينشئ Flow السجلّ المطابق في زوهو Books أو يحدّثه. ويُدار في المنشئ ربطُ الحقول والتحويلات والتوجيه الشرطي، ويُظهر سجلّ كل تدفّق بالضبط أيّ سجلّ أخفق ولماذا.
التحذير الصريح: يتحدّث Flow مع أي تطبيق من زوهو بشكل أصيل، لكن Legalsense لا يشارك بسلاسة إلا إذا كان قادرًا على بثّ خطّافات الويب أو إتاحة نقطة نهاية يستطيع Flow استطلاعها. وإن لم يكن قادرًا على دفع الأحداث، فستجدول سحبًا دوريًا عبر واجهة برمجة التطبيقات الخاصة به (من دالة مخصّصة داخل Flow). فـ Flow أداة ربط ممتازة؛ لكنه ليس بديلًا عن واجهة برمجة تطبيقات في الطرف الآخر.
المقاربة الثانية — واجهة برمجة تطبيقات زوهو Books مباشرة
حين تحتاج إلى تحكّم دقيق، اتّجه مباشرة إلى واجهة برمجة تطبيقات زوهو Books (REST API)، التي تُتيح العملاء والفواتير والأصناف والمدفوعات وغيرها، مؤمَّنة بمصادقة زوهو OAuth. ويناسب هذا الخيار حين تنطوي المطابقة من قضية في Legalsense إلى فاتورة في زوهو Books على منطق أعمال حقيقي (تجميع قيود الوقت، أسعار خاصة بكل قضية، تقسيم المصروفات، ضريبة القيمة المضافة في الإمارات لكل بند)، أو حين تُنشئ الفواتير في دورات فوترة موثوقة وقابلة للتكرار دون آثار جانبية، أو حين تقرأ حالة الدفع وفق جدول لتسويتها مع Legalsense.
المقايضة: على أحدهم أن يستضيف ويشغّل الكود الذي يستدعي هذه الواجهات — تجديد OAuth، وإعادة المحاولات، ومفاتيح المطابقة التي تمنع التكرار. وهنا يأتي دور المقاربة التالية.
المقاربة الثالثة — وسيطة برمجية مخصّصة على زوهو Catalyst
لتكامل بمستوى إنتاجي ودون تدخّل يدوي، يكون الخيار الأكثر متانة هو وسيطة برمجية بلا خوادم صغيرة تقع بين Legalsense وزوهو Books وتتولّى المزامنة. وبناؤها على زوهو Catalyst يُبقي كل شيء داخل منظومة زوهو — هويّة واحدة، ومصادقة OAuth سهلة لزوهو Books — مع منحك واجهة خلفية حقيقية توفّر عادةً:
- نقطة نهاية لخطّاف الويب يستدعيها Legalsense (أو مهمّة مجدولة) عند تغيّر العملاء أو القضايا أو الفواتير المعتمَدة.
- منطق مزامنة دون آثار جانبية يطابق على مفاتيح ثابتة، بحيث لا تنشئ إعادةُ تشغيل المهمّة عملاء مكرّرين ولا تُصدر فاتورة مزدوجة لقضية.
- مهمّة مجدولة (cron) لسحب كل ما لا يمكن دفعه في الوقت الفعلي، ولقراءة حالة الدفع عائدةً من زوهو Books إلى Legalsense.
- معالجة الأخطاء والإشعارات. تُسجَّل عمليات المزامنة الفاشلة، ويُعاد تنفيذها بفترات تراجع متزايدة، وتُعرَض على شخص مسؤول — فلا ينبغي أبدًا أن يكتشف الشريك فجوة فوترة في نهاية الشهر لأن مزامنة أخفقت بصمت.
هذه هي البنية التي نلجأ إليها حين يريد المكتب أن يعمل التكامل وحده دون رقابة وأن يتوسّع مع نمو حجم القضايا — وهي الموضع الصحيح لفرض قاعدة الوقت المعتمَد فقط والاحتفاظ بسجلّ تدقيق لما جرت مزامنته ومتى.
ربط الحقول والحالات الحدّية وإتقان التنفيذ
أيًّا كانت المقاربة التي تختارها، يحيا التكامل أو يموت على التفاصيل غير البرّاقة:
- اعتمد المطابقة على معرّفات ثابتة — رمز العميل أو البريد الإلكتروني، لا الاسم المعروض. فالأسماء تُعدَّل؛ أما المفاتيح فلا ينبغي ذلك.
- معالجة الضرائب ليست اختيارية. تخضع الخدمات القانونية في الإمارات عمومًا للمعدّل القياسي لضريبة القيمة المضافة، فاضبط رقم التسجيل الضريبي (TRN) ومعدّل الضريبة ومكان التوريد بشكل صحيح في جانب زوهو Books للحفاظ على امتثال الفواتير وجاهزيتها لـ الهيئة الاتحادية للضرائب (FTA). وإن كنت تصدر فواتير إلكترونية، فوائِم ذلك مبكرًا مع إعداد الفوترة الإلكترونية لديك.
- حدِّد كيفية مطابقة القضايا بالفواتير — فاتورة لكل قضية، أم لكل عميل، أم لكل فترة فوترة؟ فهذا يقود كلًّا من ربط الحقول وتقارير العمل قيد التنفيذ التي سيطلبها الشركاء.
- احترز من الفوترة المزدوجة. تحتاج كل عملية إنشاء إلى مفتاح يمنع تكرار الأثر؛ وإعادة إرسال القيد الزمني نفسه ينبغي أن تحدّث لا أن تكرّر.
- لا تُزامن سوى الوقت المعتمَد والفواتير المنجَزة — فالقيود في المسودّة موضعها Legalsense.
المردود في التقارير المالية
بمجرد إغلاق الدورة، تكون التقارير هي الموضع الذي يلمس فيه الشركاء الفرق. فمع بيانات نظيفة ومحدّثة في زوهو Books، يمكنك أخيرًا الإجابة عن الأسئلة المهمّة — الإيرادات المحصَّلة بحسب مجال الممارسة، ومعدّلات التحقّق (ما صدرت به فواتير مقابل ما سُجِّل)، والعمل قيد التنفيذ لكل قضية، وأعمار الفواتير المستحقّة — دون تسوية نظامين يدويًا. وتغذّي بيانات الفوترة زوهو Analytics للوحات معلومات عابرة للأنظمة، لكن حتى دون أي تهيئة إضافية يمنح زوهو Books قسمَ المالية صورة موثوقة وفي الوقت الفعلي.
هذا هو العمود الفقري التشغيلي الذي نبنيه لشركات الخدمات المهنية — اطّلع على أعمالنا في مجال خدمات الأعمال والخدمات المهنية — وهو بالضبط نوع الأتمتة العابرة للأنظمة الذي يقدّمه فريقا تخصيص زوهو والتطوير والإسناد الخارجي لدينا.
ابنِه مع شريك سبق له ذلك
ليس ربط Legalsense بزوهو Books صعبًا من حيث المبدأ، لكن التفاصيل — الامتثال لضريبة القيمة المضافة، والوقاية من التكرار، وقواعد الوقت المعتمَد، والكتابة العكسية للمدفوعات — هي حيث يتحوّل البناء السريع إلى صداع صيانة. وبوصفها شريك زوهو المتميز النخبوي بفرق منتشرة عبر الإمارات العربية المتحدة ومصر وعموم الشرق الأوسط وشمال إفريقيا، تصمّم ونس ابس عمليات التكامل هذه لتعمل دون رقابة وتتوسّع مع المكتب، مستعينةً بزوهو Flow أو واجهة برمجة تطبيقات زوهو Books أو الوسيطة البرمجية على Catalyst بحسب ما تقتضيه المهمّة.
إن كان مكتبك يعيد إدخال الوقت في الفواتير أو يسوّي نظامين يدويًا، احجز استشارة مجانية مع ونس ابس. سنرسم تدفّق العميل–القضية–الفوترة لديك ونوصي بالطريقة الصحيحة المتينة لربطه.
