QuickBooks Online والتحديث الذي يمحو ما يُغفله

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

لا شيء معطوب. فعل التكامل تمامًا ما قيل له، وما قيل له هو السلوك الافتراضي لنظامين يختلفان على معنى التحديث.

Eloquent يرسل التغييرات، والواجهة تريد الكائن

نداء save() يرسل الصفات المتغيّرة. هذا صحيح لقاعدة بيانات وحمولة خاطئة لهذه الواجهة، لأنها تعامل جسم التحديث كالسجل الذي ينبغي أن يصير إليه. والحقول التي تُغفلها لا تبقى كما هي - تُفرَّغ.

فطبقة الربط لا يمكن أن تكون ترجمة رقيقة لصفات موديل متغيّرة. عليها أن تنتج كائنًا كاملًا، وهذا يعني عمليًا قراءة السجل الحالي من QuickBooks وتطبيق التغيير عليه وإرسال الناتج.

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

والاستنتاج البنيوي أن هذا التكامل يحتاج مُخطِّطًا خاصًا به لا دالةً على الموديل. فالكائن الذاهب إلى نظام المحاسبة ليس الموديل، بل وثيقة مركّبة منه، واعتبارهما شيئًا واحدًا هو أصل هذا الخطأ.

النسخة تجعل إعادة المحاولة العمياء خاطئة

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

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

لذلك على المهمة أن تحفظ النيّة لا الحمولة. ما تحمله هو «اضبط بريد هذا العميل على هذه القيمة»، لا جسم طلب مُسلسَل. وفي كل محاولة تقرأ السجل الحالي وتطبّق النيّة وترسل الناتج بالنسخة التي قرأتها للتو.

وهذا يجعل المهمة آمنة للتشغيل مرتين فعلًا، وهو أهم هنا من المعتاد لأن طابور Laravel يعيد المحاولة سواء خطّط أحد لذلك أو لا.

والنصف الثاني من مسألة النسخة هو ما يُفعل عند تعارض حقيقي - عندما يغيّر أحد في المالية الحقل نفسه. الطمس قرار لا سلوك افتراضي. ولأكثر الحقول يكون الجواب الصادق أن نظام المحاسبة يغلب، ويسجّل تطبيقكم أن تغييره رُفض، لأن طمس تصحيح محاسبٍ في صمت هو السلوك الذي ينهي مصداقية تكامل في اجتماع واحد.

الاتصال شركة وليس مستخدمًا

يُمنح التصريح لملف شركة محدّد، والدخول الواحد قد يمنح عدة ملفات. فما تخزّنه هو اتصال - معرّف الشركة والرموز ووقت آخر تجديد وهل هو سليم الآن - في جدول خاص به.

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

ولتجديد الرمز الخطر نفسه الموجود في كل واجهة محاسبية: عاملان يجدّدان في اللحظة نفسها فيُبطل كلٌ الآخر. هذا الفشل وعلاجه مشروحان في نص Xero، والميكانيكا متقاربة إلى حدّ يجعل تكرارها هنا إهدارًا لوقتكم. المُدد تختلف - راجعوا الحالية في وثائق Intuit بدل تثبيت ما قاله نص مدوّنة - وشكل المشكلة لا يختلف.

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

مطابقة العملاء جدول لا استعلام

يشترط QuickBooks أن يكون الاسم الظاهر للعميل فريدًا داخل الشركة. وهذا الشرط وحده مسؤول عن أكثر الألم في هذه المشاريع.

قاعدتكم فيها «Acme Ltd». وقاعدتهم فيها «Acme Limited»، وفيها أيضًا «ACME LTD - لا تستخدم» من 2019، وفيها «Acme » بمسافة في آخرها. والمطابقة بالاسم تُنشئ مكررًا أول مرة يكتب أحد الصيغة القانونية بشكل مختلف، والمكرّرات في نظام محاسبة عمل تنظيف لمحاسب لا خطأ تستطيعون إصلاحه.

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

وذلك التمرين ليس عملًا هندسيًا وهو أكثر الوقت المنقضي. ويُظهر أيضًا السؤال الذي لم يطرحه أحد: أي نظام يملك اسم العميل، وما يحدث إذا تغيّر في الجهة الأخرى.

حسم من يرقّم الفواتير

القرار الأخير تجاري ويجب أن يُحسم قبل كتابة أي شيء.

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

وإن أسندها تطبيقكم، فعلى أحد تعطيل الترقيم التلقائي في QuickBooks، وتصير فراغات التسلسل مسؤوليتكم في الشرح.

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

متى لا يُبنى هذا

إن كان المطلوب أن تظهر الفواتير في QuickBooks، ولا يحتاج شيء للعودة، والحجم عشرات في الشهر، فالموصّل الجاهز هو الجواب الصحيح وهو يعمل بعد الظهر.

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