بدائل QuickBooks عندما تحتاج إلى واجهة برمجة تطبيقات (API) وليس تطبيقاً
لماذا تتجاوز فرق المنصات قدرات QuickBooks، وما الذي يتطلبه "API، وليس تطبيقاً" بالفعل، والبدائل التي تناسب كل مهمة.
يُعد QuickBooks Online تطبيق محاسبة كفؤاً للشركات الصغيرة مع قاعدة تثبيت واسعة، واجهة برمجة تطبيقات REST تدعم OAuth 2.0، وخطافات ويب (webhooks)، ومجتمع مطورين كبير. معظم الفرق التي تبحث عن بديل ليست غير راضية عنه كطبيق، بل واجهت مشكلة مختلفة: فهي بحاجة إلى برمجيات، وليس إلى شخص، لحفظ الدفاتر، في حين صُمم QuickBooks على افتراض أن هناك شخصاً يقوم بذلك.
تتناول هذه المقالة هذا التناقض وما ينبغي استخدامه بدلاً من ذلك. إذا كنت شركة صغيرة تختار برنامج إمساك دفاتر، فقد يكون QuickBooks هو الخيار الصحيح ولا ينطبق عليك أي مما ييلي.
أين يظهر التناقض
اتصال API واحد يعادل ملف شركة واحدة. واجهة برمجة التطبيقات الخاصة بـ QuickBooks مقتصرة على شركة واحدة، يُعرّفها مُعرّف نطاق (realm). المنصة التي تحتاج إلى دفاتر لـ 300 كيان بائع تدير 300 اتصال و300 اشتراك، وليس حساباً واحداً بداخله 300 شركة. هذه الحقيقة وحدها هي التي تنهي عادةً مرحلة التقييم.
واجهة برمجة التطبيقات (API) هي مكمل للتطبيق وليست المنتج الأساسي. تصل الميزات إلى واجهة المستخدم وتصل إلى واجهة برمجة التطبيقات وفق جدولها الزمني الخاص. عندما يعتمد تكاملك بالكامل على إمكانية استدعاء وظيفة ما، فإن عبارة "متاح في التطبيق" لا تعني أنها متاحة عبر الواجهة البرمجية.
معدل تقييد الطلبات (Throttling) مصمم للمزامنة وليس لتدفق المعاملات. حدود QuickBooks م وثقة بشكل شائع عند 500 طلب في الدقيقة لكل شركة، مع حدود أكثر صرامة على نقاط نهاية الدفعات والتقارير؛ تأكد من الأرقام الحالية مقابل وثائق مطوري Intuit نفسها. هذا معدل سخي لمزامنة سجلات نشاط تجاري واحد، ولكنه يمثل أمراً مختلفاً تماماً عندما تقوم منصتك بترحيل قيود لآلاف الشركات في الوقت الفعلي.
الضرائب عبر الحدود في الاتحاد الأوروبي بها ثغرات. تشير مواد دعم Intuit الخاصة إلى أنه لا توجد إجراءات قياسية لتسجيل ضريبة القيمة المضافة لنظام IOSS في QuickBooks وتوجه المستخدمين إلى مُمسك دفاتر أو محاسب. بالنسبة لمنصة تبيع عبر حدود الاتحاد الأوروبي، لا يُعد التعامل مع التجارة الإلكترونية للمسافات البعيدة ونظام نافذة الشباك الواحد (One Stop Shop) حالة استثنائية، لذا يجدر التحقق من ذلك لبلدانك المحددة قبل البناء.
لا شيء من هذا يُعد عيوباً، بل هي نتائج لبناء تطبيق ممتاز للشركات التي توظف مُمسك دفاتر.
ما يتطلبه "API، وليس تطبيقاً" بالفعل
قبل مقارنة البدائل، من المفيد تسمية ما تطلبه فرق المنصات حقاً، لأن عبارة "يحتوي على API" تتوافق مع كل شيء تقريبا.
- تغطية شاملة. كل ما يمكن للتطبيق القيام به قابل للاستدعاء. يتمثل موقف Nordlet هنا في أن التطبيق لا يحتوي على نقاط نهاية خاصة، فواجهة المستخدم تعمل على نفس نقاط النهاية التي يحصل عليها المطورون الخارجيون.
- شركات متعددة تحت حساب واحد. دفاتر لكيانات عديدة بدون الحاجة لاشتراكات متعددة.
- عمليات كتابة متطابقة (Idempotent writes). لا يمكن للطلب المُعاد محاولته إنشاء فاتورة ثانية أو قيد يومية مكرر.
- تسليم الأحداث. خطافات ويب (webhooks) يتم تشغيلها عند تغير الحالة، لكي يتفاعل نظامك بدلاً من الاستعلام المتكرر (polling).
- فرض الثوابت المحاسبية. رفض القيود غير المتوازنة، قفل الفترات المغلقة، وعدم السماح بتعديل المستندات المُرحّلة.
- الضرائب كبيانات وليس كشاشة. الوصول برمجياً إلى المعدلات، قرارات مكان التوريد (place-of-supply)، نتائج التحقق، والسجلات.
- بيئة اختبار (sandbox) تتطابق مع بيئة الإنتاج، وشركات اختبار غير محدودة لتصبح اختبارات التكامل رخيصة التكلفة.
قّم أي بديل بناءً على تلك القائمة بدلاً من مقارنته بمصفوفة ميزات.
البدائل، حسب ما تحاول إنجازه
| وضعك الحالي | الجأ إلى | لماذا |
|---|---|---|
| يجب أن تمتلك منصتك الدفاتر لعدة مستأجرين | واجهة برمجة تطبيقات محاسبية مُضمنة مثل Nordlet | شركات متعددة تحت حساب واحد، تسعير قائم على الاستخدام، وقواعد محاسبية مفروضة من جانب الخادم |
| يحتفظ عملاؤك بالدفاتر في QuickBooks وتتكامل معهم | ابقَ على واجهة برمجة تطبيقات QuickBooks، أو استخدم مجمّعاً (aggregator) | الدفاتر تخص العميل، والذهاب إليه هناك هو القرار الصحيح |
| تحتاج إلى دفاتر في عدة تطبيقات محاسبية دفعة واحدة | مجمّع مثل Codat أو Rutter أو Merge | واجهة واحدة عبر العديد من الأنظمة الأساسية |
| تحتاج إلى أرصدة محافظ في الوقت الفعلي وليس دفاتر قانونية | بنيّة دفاتر أساسية مثل Modern Treasury Ledgers | صُممت للإنتاجية العالية والثبات، وليست لتقديم الإقرارات الضريبية |
| تريد نظاماً واحداً يغطي العمليات والمالية | نظام تخطيط موارد المؤسسات (ERP) مثل Odoo | الشمولية، مقابل تكلفة إدارته بنفسك |
| أنت شركة صغيرة مع مُمسك دفاتر | Xero أو QuickBooks أو بديل محلي مكافئ | التطبيق هو الغاية الأساسية |
واجهة برمجة تطبيقات محاسبية مُضمنة (Embedded accounting API)
هذه هي الإجابة المباشرة لعبارة "API، وليس تطبيقاً". يصبح النظام المحاسبي خدمة خلفية (backend service) يستدعيها منتجك، ولا يرى المستخدمون لديك دفتر الأستاذ العام (general ledger) أبداً.
صُممت Nordlet لهذا الشكل: دفتر أستاذ ثابت ذو قيد مزدوج يتم فرض التوازن فيه بواسطة مشغل قاعدة بيانات (database trigger) وقت الالتزام (commit)، ترقيم مستندات متصل بلا فجوات، قفل الفترات الذي يرفض القيود ذات التاريخ الواقع داخل شهر مغلق برمز 409، سجل تدقيق (audit record) لكل عملية تعديل، دعم لخاصية Idempotency-Key التي تعيد تشغيل الاستجابة المخزنة عند إعادة المحاولة، وخطافات ويب (webhooks) موقعة تتم كتابتها في صندوق صادر للمعاملات (transactional outbox) في نفس معاملة قاعدة البيانات التي تم فيها التغيير. التسعير قائم على الاستخدام بدلاً من الدفع لكل شركة: يبدأ من 10 يورو شهرياً مع تضمين 3,000 طلب، مع شركات ومستخدمين وشركات اختبار غير محدودة في كل خطة.
العيوب بصراحة: لا تزال Nordlet في مرحلة الوصول المبكر وتصميم الشركاء؛ تغطي ضريبة القيمة المضافة في الاتحاد الأوروبي المعدلات الخاصة بكل دولة، والتحقق عبر نظام VIES، وحساب إقرارات نظام الشباك الواحد (OSS/IOSS)، ولكن حزم الإقرارات الضريبية المحلية تتوفر حالياً لثلاث دول فقط - ليتوانيا (FR0600)، ألمانيا (UStVA)، وبولندا (JPK_V7M)، بينما تقتصر الرواتب والأجور على ليتوانيا وحدها.
المجمّعات (Aggregators)
تمنحك Codat وRutter وMerge واجهة واحدة لأي نظام محاسبي يستخدمه كل عميل بالفعل. إذا كانت مهمة منتجك هي قراءة أو كتابة دفاتر عملائك - الإقراض، إدارة الإنفاق، التحليلات - فهذه هي الفئة الصحيحة وسيكون دفتر الأستاذ المضمن خياراً خاطئاً. أما إذا كانت منصتك بحاجة إلى أن تكون نظام السجل الأساسي، فلا يمكن للمجمّع أن يقوم بهذا الدور.
بنيّة الدفاتر الأساسية (Ledger infrastructure)
تتعقب المنتجات في هذه الفئة الأرصدة بشكل ثابت وبإنتاجية عالية دون إجراء المحاسبة القانونية. وهي تتناسب بشكل جيد مع منتجات المحافظ أو المدفوعات، وتترك ضريبة القيمة المضافة، والفوترة، والتقارير السنوية لأشياء أخرى.
تخطيط موارد المؤسسات (ERP)
تغطي Odoo والأنظمة المشابهة جانباً أكبر بكثير من الأعمال مقارنة بالمحاسبة وحدها. تتمثل التكلفة التي يتحملها بناة المنصات في واجهة التكامل: تعمل واجهة برمجة التطبيقات الخارجية ل Odoo على مستوى نموذج البيانات عبر RPC، وتوضح وثائقها أن الوصول عبر واجهة برمجة التطبيقات يقتصر على مستوى التسعير المخصص (Custom)، ومن المقرر استبدال نقاط نهاية RPC الحالية بواجهة برمجة تطبيقات JSON أحدث. تمت تغطية ذلك في مقال Nordlet مقابل Odoo لمطوري المنصات.
إذا كنت تنتقل بعيداً عن QuickBooks
هناك بعض الأمور التي تستغرق دائماً وقتاً أطول مما هو متوقع:
- تعيين شجرة الحسابات (Chart of accounts mapping). قم بذلك بعناية، واحتفظ برمز الحساب القديم كحقل مرجعي في الحساب الجديد. ستحتاج إليه عندما يسأل شخص ما عن سبب تغير رقم المقارنة.
- الأرصدة الافتتاحية. قم بالترحيل كأرصدة في تاريخ قطع محدد (cut-off date)، وليس كتاريخ مُعاد ترحيله. احتفظ بالنظام القديم قابلاً للقراءة طوال فترة الاحتفاظ بالبيانات بدلاً من محاولة إعادة تشغيل سنوات من القيود.
- ترقيم المستندات. قرر ما إذا كانت السلسلة الجديدة ستستمر في الترقيم القديم أم تبدأ من جديد، وتأكد من المتطلبات القانونية في ولايتك القضائية قبل الاختيار.
- البنود المفتوحة. يجب أن تصل الفواتير غير المدفوعة، والائتمانات غير المستخدمة، والمدفوعات المطابقة جزئياً كبنود مفتوحة وليست كأرصدة صافية، وإلا فلن تعمل التسويات المحاسبية بشكل صحيح لاحقاً.
- الفترات الضريبية. لا تقم بالترحيل في منتصف الفترة الضريبية ما لم تكن مستعداً لتقديم إقرار واحد من نظامين.
- تشغيل النظامين معاً لدورة واحدة. قم بترحيل نفس الشهر في النظامين وقارن ميزان المراجعة قبل إيقاف النظام القديم.
FAQ
هل يوجد بديل مجاني لQuickBooks؟
توجد أنظمة محاسبية مجانية ومفتوحة المصدر، وتنشر Odoo طبقة مجانية تقتصر على تطبيق واحد. نادراً ما يظل المجاني مجانياً للمنصة، لأن التكاليف تنتقل إلى الاستضافة، والترقيات، وتحديثات الامتثال، ووقت الهندسة اللازم للحفاظ على عمل التكامل. احسب التكلفة الإجمالية وليس سعر الترخيص فقط.
ما هو الأفضل مقارنة بQuickBooks للمتاجر الإلكترونية (marketplaces)؟
بالنسبة لمحاسبة المتاجر الإلكترونية على وجه تحديد، تُعد واجهة برمجة التطبيقات المحاسبية المضمنة ملائمة هيكلياً بشكل أفضل، لقدرتها على الاحتفاظ بدفاتر لعدة كيانات تحت حساب واحد، وفرض القواعد المحاسبية من جانب الخادم، والتحكم بها بالكامل عبر برمجياتك. بينما يظل QuickBooks منتجاً أفضل لنشاط تجاري فردي مع مُمسك دفاتر.
هل يمتلك QuickBooks واجهة برمجة تطبيقات (API) للمطورين؟
نعم. يوفر QuickBooks Online واجهة برمجة تطبيقات REST تدعم OAuth 2.0 مع خطافات ويب (webhooks) وبوابة للمطورين. القيود المفروضة عند الاستخدام في المنصات لا تتعلق بجودة الواجهة البرمجية بل بنطاقها: فهي مصممة للتكامل مع دفاتر شركة واحدة، وليست لتكون دفتر الأستاذ الداخلي داخل منتج آخر.
هل يمكنني الاحتفاظ بQuickBooks وإضافة واجهة برمجة تطبيقات محاسبية؟
يمكنك ذلك، وتقوم بعض الفرق بذلك: دفاتر المنصة الخاصة تعيش في دفتر أستاذ مضمن، بينما تدفع عمليات التكامل بقيود إجمالية ملخصة إلى النظام المحاسبي الذي يستخدمه كل عميل تجاري. القاعدة الأساسية التي يجب التمسك بها هي أن نظاماً واحداً فقط يجب أن يكون هو السجل المعتمد لأي مجموعة دفاتر معينة. وجود نظامين يدعي كل منهما أنه المرجع هو بداية مشاكل التسوية المحاسبية.
ماذا عن استخدام Xero بدلاً من ذلك؟
يُعد Xero بديلاً قوياً كطبيق ولديه واجهة برمجة تطبيقات موثقة بشكل جيد، لكنه يحمل نفس الشكل الهيكلي: الاشتراكات وحدود واجهة برمجة التطبيقات تكون لكل مؤسسة، وتقتصر التطبيقات غير المُعتمدة على 25 مؤسسة متصلة. تم توضيح المقارنة في مقال Nordlet مقابل Xero للمحاسبة المضمنة.