- 1الطرق الثلاث لإنشاء تكامل WooCommerce QuickBooks
- 2لماذا يؤدي مزامنة مستوى الطلب إلى كسر التسوية
- 3مثال عملي
- 4"إنها مفتوحة المصدر - يجب أن يتعامل المكون الإضافي المجاني مع هذا"
- 5الهندسة المعمارية التي تعمل: حسابات التصفية، الملخصات اليومية، سطور الرسوم
- 6في LedgerPort، هذه الهندسة المعمارية هي صفحة إعدادات
- 7متى يكون المكون الإضافي كافيًا - ومتى لا يكون كذلك
- 8شريط الهندسة الذي يجب أن يتجاوزه طبقة المزامنة
- 9ما يبدو عليه هذا تلقائيًا
- 10وعندما يفشل خطاف الويب - لأن واحدًا سيفشل
- 11ضريبة المرونة
يعد إدخال الطلبات في QuickBooks الجزء السهل. هذا الدليل يدور حول الجزء الذي لا يذكره إدراج المكون الإضافي: مطابقة الكتب مع البنك.
هناك 1400 فاتورة جديدة في ملف WooCommerce QuickBooks الخاص بك، وكل واحدة منها صحيحة.
لقد قمت بتثبيت الموصل، وربطت بعض الحقول، وشاهدته يعمل. وصل كل طلب WooCommerce إلى QBO مع اسم العميل، وعناصر السطر، والشحن، والضريبة. بكل المقاييس الموجودة في صفحة ميزات المكون الإضافي، كان تكامل WooCommerce QuickBooks الخاص بك قد اكتمل.
ثم فتحت تغذية البنك. أودعت Stripe مبلغ 6782.40 دولارًا يوم الاثنين. أسقط PayPal مبلغ 1911 دولارًا يوم الأربعاء. ولم تتطابق أي من هذه الفواتير الـ 1400 - ولا واحدة منها - مع أي من الرقمين. يطلب منك QuickBooks الآن مطابقة إيداع واحد مقابل عشرات الفواتير المفتوحة، ولا يتطابق أي منها معه.
إذا كنت قد مررت بهذا، فربما فعلت ما يفعله معظم أصحاب المتاجر: ألغيت تثبيت المكون الإضافي، وعدت إلى تصدير CSV، واستنتجت أن الفئة بأكملها معطلة. إنها ليست كذلك. لكن الشيء الذي تم بيعه لك - مزامنة الطلبات - لم يكن المشكلة الفعلية أبدًا.
المشكلة الفعلية هي أن WooCommerce وحسابك المصرفي يصفان واقعين مختلفين، ولا يمكن لأي قدر من مزامنة الطلبات أن يترجم بينهما. يشرح هذا المنشور السبب، مع الأرقام، ويتناول الإعداد الذي يقوم بالتسوية فعليًا.
الطرق الثلاث لإنشاء تكامل WooCommerce QuickBooks
بشكل عام، تندرج كل طريقة ضمن إحدى ثلاث فئات.
1. موصل QuickBooks الرسمي. يدفع الموصل الخاص بـ Intuit (المبني على محرك OneSaas القديم) طلبات WooCommerce إلى QBO كفواتير أو إيصالات مبيعات. إنه غير مكلف، ومدعوم من Intuit، وللنسخ الأساسي للطلبات يقوم بما يقوله. ما يعرفه هو الطلبات - ما اشتراه العميل وما قام WooCommerce بفرضه عليه.
2. مكونات إضافية للمزامنة مخصصة. أدوات مثل MyWorks Sync تتعمق أكثر: مزامنة ثنائية الاتجاه، وربط حقول دقيق، ومزامنة المخزون والعملاء، ودفعات في الوقت الفعلي. إذا كان عملك يعتمد على الفواتير الفردية - حسابات البيع بالجملة، وعملاء B2B، والمدفوعات المرتبطة بأشخاص معينين - فإن دقة كل طلب تكون ذات قيمة حقيقية، و MyWorks قوي في ذلك. لقد كتبنا مقارنة مفصلة في LedgerPort مقابل MyWorks إذا كنت تفكر في هذا المسار.
3. تصدير CSV يدويًا. تصدير الطلبات من WooCommerce، ومعالجة جدول البيانات، وإدخال قيود اليومية في QBO يدويًا. تحكم كامل، تكلفة برامج صفر، وما بين ساعتين وثماني ساعات شهريًا اعتمادًا على الحجم - بالإضافة إلى كل خطأ يرتكبه إنسان متعب في الساعة الثالثة.
| الطريقة | ما تنقله | التكلفة | هل تتم التسوية مع البنك؟ |
|---|---|---|---|
| موصل QuickBooks | الطلبات ← الفواتير/الإيصالات | منخفض | ليس بمفردها |
| ملحق المزامنة (مثل MyWorks) | الطلبات والعملاء والمخزون | دولار - دولارات | فقط مع تكوين دقيق للسداد |
| ملف CSV يدوي | كل ما تكتبه | وقتك | فقط إذا قمت بحسابات السداد بنفسك |
لاحظ ما هو مشترك بين الثلاثة: تبدأ جميعها من بيانات الطلب. وبيانات الطلب هي نصف مجموعة البيانات التي تحتاجها فقط.
لماذا يؤدي مزامنة مستوى الطلب إلى كسر التسوية
هذه هي المشكلة الهيكلية، ولا علاقة لها بالملحق الذي اخترته.
يعرف WooCommerce الطلبات: العميل، العناصر، الإجماليات، الضرائب. لا يعرف ما خصمته Stripe من رسوم المعالجة، أو متى قامت PayPal بتجميع دفعة، أو أي استرداد من الأسبوع الماضي تم خصمه من إيداع هذا الأسبوع، أو ما فعلته رسوم الاعتراض على صرف يوم الثلاثاء. هذه المعلومات موجودة لدى بوابات الدفع الخاصة بك - مجموعة بيانات منفصلة تمامًا، وجدول زمني منفصل تمامًا.
في غضون ذلك، لا يرى سجل حسابك المصرفي سوى جانب بوابة الدفع من القصة: الإيداعات الصافية، المجمعة حسب جدول بوابة الدفع. لذلك، عندما يقوم أداة مزامنة بنسخ الطلبات إلى QBO، فإنه يسجل بصدق مجموعة بيانات لن يؤكدها حسابك المصرفي أبدًا.
مثال عملي
لنفترض أن متجرك تلقى 96 طلبًا خلال عطلة نهاية الأسبوع، بإجمالي 7200 دولار أمريكي إجمالي. يبلغ WooCommerce عن ذلك على أنه ثلاثة أيام منفصلة من المبيعات، وينشئ مزامنة مستوى الطلب الخاصة بك 96 فاتورة في QBO.
يوم الاثنين، ترسل Stripe دفعة واحدة:
| دفعة Stripe - الاثنين | المبلغ |
|---|---|
| إجمالي مبيعات عطلة نهاية الأسبوع (96 طلبًا) | $7,200.00 |
| رسوم المعالجة (2.9% + 0.30 دولار × 96) | −237.60 دولار |
| المبالغ المستردة (طلبان من الأسبوع الماضي) | −180.00 دولار |
| صافي الإيداع في حسابك المصرفي | $6,782.40 |
يحتفظ QuickBooks الآن بـ 96 فاتورة بإجمالي 7200 دولار، موزعة على أيام الجمعة والسبت والأحد. يحتفظ سجل حسابك المصرفي بإيداع واحد يوم الاثنين بقيمة 6782.40 دولارًا. لا توجد رسوم الـ 237.60 دولارًا في سجلاتك. الـ 180 دولارًا من المبالغ المستردة تخص طلبات غير موجودة حتى في بيانات عطلة نهاية الأسبوع هذه. لا يوجد أي مزيج من هذه الفواتير الـ 96 يساوي هذا الإيداع - لا يمكن مطابقة الحسابات بحكم الإنشاء.
اضرب هذا في كل دفعة، وكل بوابة دفع، وكل شهر. هكذا ينتهي بك الأمر بـ 1400 فاتورة مثالية وسجل مصرفي لا يتفق مع أي منها.
[صورة: رسم توضيحي يظهر بيانات طلبات WooCommerce وبيانات دفع Stripe كتيارين منفصلين، مع ربط السجل المصرفي بتيار الدفع فقط - والفجوة حيث توجد الرسوم وتوقيت الاسترداد]
عند هذه النقطة، يستنتج معظم الناس أحد ثلاثة أشياء: يقرر البعض أنهم بحاجة إلى توظيف محاسب، ويعود البعض إلى جداول البيانات، ويدرك البعض أن المشكلة هيكلية ويقومون بإصلاح الهيكل. هذا القسم مخصص للمجموعة الثالثة.
"إنها مفتوحة المصدر - يجب أن يتعامل المكون الإضافي المجاني مع هذا"
دعنا نسمي الافتراض مباشرة، لأنه معقول ولكنه خاطئ.
WooCommerce مفتوح المصدر، والنظام البيئي لديه ملحق لكل شيء، ومعظمها مجاني أو رخيص. لذلك، الغريزة هي: يجب أن يتعامل ملحق مجاني مع QuickBooks أيضًا. ويمكن للملحق المجاني التعامل مع ما تجيده الملحقات - نقل بيانات الطلب من قاعدة بيانات إلى أخرى. هذا الجزء هو بالفعل مشكلة محلولة.
لكن التسوية ليست مشكلة نقل بيانات. إنها مشكلة ترجمة بين مجموعتي بيانات تختلفان حول المبالغ (الإجمالي مقابل الصافي)، والتوقيت (تاريخ الطلب مقابل تاريخ الدفع)، والنطاق (طلبات نهاية هذا الأسبوع مقابل استردادات الأسبوع الماضي). لا يوجد مكون إضافي يصلح ذلك عن طريق نقل الطلبات بشكل أسرع أو تعيين الحقول بدقة أكبر - لم تقم بتكوينه بشكل خاطئ، ولم يفعل مطور المكون الإضافي ذلك أيضًا. لقد حلت الأداة المشكلة التي فهمتها. المشكلة التي لديك بالفعل أكبر من نموذج الأداة لها.
الهندسة المعمارية التي تعمل: حسابات التصفية، الملخصات اليومية، سطور الرسوم
الحل هو هيكل استخدمه المحاسبون لعقود، مطبقًا على البوابات. ثلاثة مكونات: حساب مقاصة لكل بوابة، ملخصات يومية بدلاً من فواتير لكل طلب، وبنود رسوم صريحة في كل دفعة. إليك الإعداد اليدوي، خطوة بخطوة.
أنشئ حساب مقاصة لكل بوابة. في QBO، أضف حسابًا من نوع أصول متداولة أخرى باسم "Stripe Clearing"، وآخر لـ "PayPal Clearing"، وواحد لكل بوابة إضافية. يمثل هذا الحساب الأموال التي دفعها العملاء ولم تصل إلى بنكك بعد - وهو بالضبط ما هو عليه.
قم بنشر ملخصات المبيعات اليومية بدلاً من الفواتير الفردية. مرة واحدة في اليوم، سجل إدخالًا واحدًا لكل بوابة: إجمالي المبيعات، والخصومات، والمبالغ المستردة المصدرة، ودخل الشحن، وضريبة المبيعات المحصلة. قم بخصم حساب المقاصة للمبلغ الإجمالي؛ قم بائتمان حسابات الدخل والشحن وضرائب الالتزامات الخاصة بك. يظهر بيان الأرباح والخسائر الخاص بك الآن الإيرادات حسب اليوم - وهو كل ما تحتاجه الضرائب وتحليل الهامش - بدون 96 فاتورة يتيمة. (إذا كنت تقوم بإعداد حسابات الدخل والضرائب من البداية، فإن دليل مسك الدفاتر لـ WooCommerce الخاص بنا يغطي هيكل دليل الحسابات الكامل.)
سجل كل دفعة كقيد يومية عند وصولها. قم بائتمان حساب المقاصة للمبلغ الإجمالي للدفع. قم بخصم حسابك المصرفي للمبلغ الصافي المودع. قم بخصم حساب مصروف "رسوم معالجة التاجر" لفرق الرسوم، وقم بنشر عكس المبالغ المستردة مقابل الدخل. باستخدام مثال عطلة نهاية الأسبوع: قم بائتمان Stripe Clearing بمبلغ 7,200 دولار، وخصم الحساب المصرفي بمبلغ 6,782.40 دولار، وخصم الرسوم بمبلغ 237.60 دولار، وسجل المبالغ المستردة البالغة 180 دولارًا مقابل الإيرادات. كل دولار له الآن مكان.
طابق الإيداع في موجز البنك. نظرًا لأن سطر البنك في قيدك اليومي هو 6,782.40 دولارًا والإيداع هو 6,782.40 دولارًا، فإن QuickBooks يطابقهما بنقرة واحدة. هذه هي اللحظة التي يؤتي فيها الهيكل بأكمله ثماره: تصبح التسوية تأكيدًا بدلاً من تحقيق.
راقب رصيد حساب المقاصة. يجب أن يحوم بالقرب من المبلغ قيد النقل حاليًا مع البوابة - بضعة أيام من المبيعات، لا أكثر. الرصيد المتزايد باستمرار يعني أن الرسوم أو المبالغ المستردة لا يتم تسجيلها في مكان ما. هذا الرقم الوحيد هو نظام الإنذار المبكر الخاص بك، وهو أول شيء سيتحقق منه أي محاسب قانوني جيد.
[صورة: مخطط تدفق - إدخالات الملخص اليومي تتدفق إلى حساب Stripe Clearing، ثم قيد يومية الدفع ينقسم إلى الحساب المصرفي (صافي) ورسوم المعالجة (مصروف)، مع مطابقة موجز البنك في النهاية]
يستغرق هذا، الذي يتم يدويًا، محاسبًا كفؤًا من 30 إلى 60 دقيقة لكل بوابة في الأسبوع، وكل خطوة هي فرصة لخطأ مطبعي. لكن الهيكل صحيح - والهيكل هو الشيء الذي لا يمنحك إياه أي مكون إضافي لمزامنة الطلبات.
في LedgerPort، هذه الهندسة المعمارية هي صفحة إعدادات
إذا بدت هذه الخطوات الخمس الكثير من الانضباط الدفتري، فإليك الجزء الذي يستحق المعرفة: في إضافة LedgerPort لـ WooCommerce، يوجد كل مكون كإعداد. يقوم علامة التبويب المدفوعات في إعداد المزامنة بالكشف التلقائي عن كل بوابة دفع نشطة في متجرك وتعيين حساب مقاصة خاص بها لكل منها، مع حساب مقاصة افتراضي كحل بديل لأي شيء لم تقم بتكوينه. حساب مقاصة واحد لكل بوابة ليس تمرينًا دفتريًا - إنه قائمة منسدلة لكل بوابة.
يتم التعامل مع الضرائب بنفس الطريقة: يتم نشر ضريبة المبيعات إلى حساب التزام QuickBooks الذي تحدده، ويستوعب بند تقريب السنتات الفروقات بين حسابات الضرائب في WooCommerce و QuickBooks - الورقة المحاسبية التي لا يحذرك منها أحد. كيفية نشر الطلبات هي قائمة منسدلة أخرى: إيصال مبيعات للطلبات المدفوعة، فاتورة عند وصول الدفع لاحقًا، تقدير للاقتباسات. وتصنيف طرق المزامنة عام للمنصة - توجيهات الوثائق نفسها تضع حوالي 100+ طلب في اليوم كنقطة تتوقف فيها السجلات لكل طلب عن كونها مسك الدفاتر وتبدأ في كونها رواسب، وهذا بالضبط حيث تكسب الملخصات اليومية قيمتها.
لا يتطلب أي من هذا مشروع تكوين أيضًا. وفقًا للأسئلة الشائعة الخاصة بالوثائق، تأتي كل علامة تبويب مع إعدادات افتراضية معقولة - يمكن لمعظم المتاجر البدء في المزامنة دون لمس إعداد المزامنة على الإطلاق، وتشديد الإعدادات لاحقًا حسب ما تتطلبه الكتب.
متى يكون المكون الإضافي كافيًا - ومتى لا يكون كذلك
إجابة صريحة: أحيانًا تكون أدوات مستوى الطلب هي الحل الصحيح.
من المحتمل أن يكون مكون إضافي لمزامنة مستوى الطلب كافيًا إذا: كنت تتلقى حوالي 100-200 طلب شهريًا ويمكنك رؤية الفجوات بالعين؛ تدير بوابة واحدة مع عمليات استرداد بسيطة وغير متكررة؛ أو يعتمد عملك على الفواتير - متاجر البيع بالجملة و B2B حيث ترتبط المدفوعات فعليًا بفواتير عملاء محددة. في هذه الحالة الأخيرة، لا تعد المزامنة لكل طلب خطأ، بل هي المتطلب، وأداة مثل MyWorks مبنية خصيصًا لذلك.
توضيح واحد بشأن هذه الحالة الأخيرة، لأنها هي التي يتم فهمها بشكل خاطئ. سواء كان متجرك يعتمد على الفواتير أم لا، فهذه ليست خاصية لأداة المزامنة التي تختارها - بل يتم تحديدها في مرحلة سابقة، على مستوى المتجر. يصدر متجر WooCommerce طلبات على شكل فواتير فقط إذا كان هناك شيء ما يقوم بتعيين أدوار البيع بالجملة، وتطبيق أسعار B2B، والسماح للمشترين المعتمدين بالدفع بشروط؛ Wholesale Suite هي الطريقة المعتادة للقيام بذلك. لذا، اقرأ متجرك قبل قراءة قائمة الميزات: إذا كان ينتج طلبات بشروط صافية، فسيلخص ملخص يومي مدرك للدفع هذه الطلبات بسعادة في سطر إيرادات واحد ويأخذ تفاصيل الذمم المدينة معه.
تحتاج إلى طبقة الوعي بالدفع إذا: كنت تدير بوابات متعددة (Stripe بالإضافة إلى PayPal هو المكان الذي تعبر فيه معظم المتاجر الخط)؛ عمليات الاسترداد والنزاعات هي واقع أسبوعي؛ حجم عملك يجعل إدخالات كل طلب غير قابلة للإدارة؛ أو يقوم محاسب قانوني بإغلاق كتبك شهريًا ويتوقع أن يتطابق كشف الحساب البنكي. في تلك المرحلة، لا يمكن لبيانات الطلب وحدها إنتاج كتب قابلة للتسوية - بغض النظر عن مدى جودة مزامنتها.
إذا كنت تميل نحو مسار الوعي بالدفع، فإن ثلاثة اعتراضات عملية تميل إلى الظهور بعد ذلك:
"هل سيتعامل مع اشتراكاتي؟" يقوم LedgerPort بمزامنة بيانات طلبات وعملاء WooCommerce القياسية، وتصل تجديدات الاشتراك كطلبات عادية عندما ينشئها WooCommerce - لذا تتدفق الإيرادات المتكررة عبر نفس خط الأنابيب، ولا يوجد شيء خاص لتكوينه.
"ماذا لو فشلت المزامنة بصمت؟" تعتمد المزامنة في الوقت الفعلي على خطافات الويب الخاصة بـ WooCommerce، وتقوم WooCommerce بإعادة محاولة تسليم الطلبات الفاشلة تلقائيًا. إذا فات شيء ما، فإن صفحة المزامنة اليدوية داخل wp-admin تدفع البيانات عند الطلب - لن تضطر أبدًا إلى انتظار الدعم لإعادة إرسال طلب.
"هل يمكنني تشغيل عدة متاجر مقابل حساب واحد؟" نعم - كل متجر متصل يُحتسب كوصلة واحدة مقابل حد خطتك، وهو مرئي في صفحة الاتصال. بقية الأسئلة العملية (التوافق مع HPOS، تخزين بيانات الاعتماد، أدوار المستخدم المطلوبة) تمت الإجابة عليها في البدء مع LedgerPort لـ WooCommerce.
شريط الهندسة الذي يجب أن يتجاوزه طبقة المزامنة
هناك محور تقييم آخر، وهو المحور الذي لا تعرضه قوائم الإضافات أبدًا: ما يفعله البرنامج بمتجرك عند الاتصال - وعند المغادرة. توفير LedgerPort تلقائي ومعاملاتي. يؤدي الاتصال إلى إنشاء مفتاح واجهة برمجة تطبيقات WooCommerce REST للقراءة فقط - يقرأ متجرك، ولا يكتب فيه - ويسجل 13 خطاف ويب مسماة تغطي الطلبات والمنتجات والاختلافات والعملاء والمبالغ المستردة. إذا فشلت أي خطوة من خطوات التوفير في منتصف الطريق، يتم التراجع تلقائيًا عن كل ما تم إكماله بالفعل، لذلك لا يُترك متجرك أبدًا نصف مُكوّن.
بقية الوضع الأمني يمكن التحقق منه بنفس القدر: يتم تخزين بيانات الاعتماد مشفرة بـ AES-256-CBC باستخدام مفاتيح أمان WordPress الخاصة بموقعك، ويتطلب الاتصال القدرة manage_woocommerce (المسؤولون ومديرو المتجر)، ولا يلمس LedgerPort أبدًا خطافات الويب التي أنشأتها بنفسك. إلغاء الاتصال نظيف بنفس القدر - يحذف مفتاح واجهة برمجة التطبيقات وخطافات الويب التي أنشأها بالضبط، ويظل متجرك وطلباتك دون تغيير، وتظل تعييناتك سليمة لإعادة الاتصال. محاولة أولى فاشلة لا تكلف شيئًا.
يظهر نفس الانضباط عندما تسوء المزامنة. الإخفاقات ليست فجوة صامتة أو إشعار PHP - إنها تصنيف مسمى مع إصلاحات موثقة: رمز QuickBooks منتهي الصلاحية (الاختيار الخاص بالمستندات لخطأ المزامنة الأكثر شيوعًا)، منتج غير معين، إدخال مكرر، حقل مطلوب مفقود. يوضح كل خطأ سببه ومسار استعادته. هذا، أكثر من أي مربع ميزة، هو الحد الحقيقي لـ "المكون الإضافي كافٍ": ينتهي حيث يبدأ الفشل غير القابل للاسترداد وغير المرئي.
ما يبدو عليه هذا تلقائيًا
تم بناء LedgerPort كطبقة الوعي بالدفع هذه، وهو يدعم WooCommerce جنبًا إلى جنب مع Shopify. يتصل بمتجرك و بواباتك، ثم يقوم بتشغيل البنية المذكورة أعلاه تلقائيًا: ملخصات يومية تُنشر في حسابات تسوية البوابة، قيود دفع مع تفصيل الرسوم، إيداعات تتطابق مع كشف حسابك البنكي بدقة. يستغرق الإعداد حوالي 15 دقيقة، والمتاجر ذات الحجم الكبير توفر ساعات كل أسبوع.
إليك إعداد WooCommerce بالكامل، من البداية إلى النهاية:
تثبيت المكون الإضافي. في مسؤول WordPress الخاص بك، انتقل إلى الإضافات » إضافة إضافة جديدة، ابحث عن LedgerPort، انقر فوق التثبيت الآن، ثم التفعيل. ستحتاج إلى HTTPS على موقعك وحساب LedgerPort - الدليل الكامل للتثبيت يغطي كلا الشرطين المسبقين.
قم بتشغيل معالج الإعداد. بعد التنشيط، يفتح LedgerPort المعالج تلقائيًا كطبقة تراكب بملء الشاشة. انقر فوق الاتصال بـ LedgerPort للبدء.
مصادقة الاتصال. تتم إعادة توجيهك إلى app.ledgerport.com لتسجيل الدخول، واختيار الشركة التي تتصل بها، والنقر فوق مصادقة — ثم إعادتك مباشرة إلى مسؤول WordPress الخاص بك.
- دع التزويد يعمل. ينشئ LedgerPort مفتاح WooCommerce REST API مع حق الوصول للقراءة، ويسجل خطافات الويب للطلبات، والمبالغ المستردة، والمنتجات، والعملاء، ويؤكد الاتصال. إذا فشلت أي خطوة، يتم التراجع عن كل شيء تلقائيًا — لا يوجد متجر تم تكوينه جزئيًا. عندما ينجح، تصل إلى لوحة تحكم LedgerPort، متصلًا.
من هناك، كل شيء يعيش تحت قائمة LedgerPort داخل wp-admin — لوحة التحكم، التعيينات، المزامنة اليدوية، سجلات التدقيق — لذا فإن التحقق من آلية العمل لا يعني أبدًا مغادرة WordPress. وهيكل حساب التسوية من القسم السابق ليس مشروع تكوين منفصل: إنه طريقة مزامنة الملخص اليومي، قائمة منسدلة واحدة من خمسة، تم اختيارها مرة واحدة.
وعندما يفشل خطاف الويب - لأن واحدًا سيفشل
تعتمد المزامنة في الوقت الفعلي على خطافات الويب، وخطافات الويب صادقة بشأن طبيعتها: عاجلاً أم آجلاً، يفشل التسليم. السؤال الذي لا تستطيع معظم المكونات الإضافية المجانية الإجابة عليه هو ما يحدث بعد ذلك. هنا الإجابة لها طبقات. يقوم WooCommerce نفسه بإعادة محاولة تسليم خطافات الويب الفاشلة تلقائيًا. أي شيء لا يزال يفلت لا يختفي - بل يظهر كحالة مزامنة لكل سجل، يمكن استرداده من صفحة المزامنة اليدوية داخل wp-admin.
سير العمل هو تحديد مربع الاختيار، ثم دفع المحدد أو دفع الكل، ثم نافذة منبثقة للتقدم المباشر تعرض كل سجل يصل أو يفشل - مع سبب مرفق، وليس مجرد أيقونة حمراء. والتفاصيل التي تجعل اللحاق بالركب بعد انقطاع التيار آمنًا: يُضمن عدم تكرار الدفع. يتم تخطي السجلات التي تمت مزامنتها بالفعل تلقائيًا، وإعادة دفع سجل فاشل ينشئ أو يحدث إدخال QuickBooks بدلاً من نشره مرتين. "تحديد كل شيء، دفع الكل" بعد أسبوع سيء لا يمكن أن ينشر الإيرادات مرتين.
حقيقتان أخريان من الأسئلة الشائعة تنتميان إلى هنا: المكون الإضافي متوافق تمامًا مع تخزين الطلبات عالي الأداء في WooCommerce بدون أي تكوين إضافي، و - كما هو مغطى أعلاه - تجديدات اشتراكات WooCommerce تستخدم نفس خط الأنابيب مثل الطلبات العادية. يستخدم الملء التاريخي نفس هذه الصفحة أيضًا، مما يعني أن "لقد كنا على جداول البيانات طوال العام" هو استيراد، وليس مشروع إدخال بيانات: تصفح العام، ادفع، شاهد الحالات تتحول إلى اللون الأخضر.
المقايضة، بعبارات بسيطة: LedgerPort يلخص. لن يقوم بمزامنة سجلات العملاء الفردية أو إدارة المخزون في QBO — إذا كانت شركتك تحتاج إلى فواتير لكل عميل، فإن أداة مثل MyWorks تظل الخيار الأفضل، و المقارنة تشرح هذا الخط بصدق.
الأسعار تبدأ من مجاني — ما يصل إلى 30 طلبًا شهريًا، متجر واحد، مزامنة يدوية عند الطلب — حتى تتمكن من مشاهدة تسوية دفعة حقيقية قبل دفع أي شيء. يبدأ النمو من 25 دولارًا شهريًا مع مزامنة يومية آلية؛ يبدأ التوسع من 67 دولارًا شهريًا، ويضيف مزامنة في الوقت الفعلي بالإضافة إلى دفاتر يومية الدفع ومعالجة الرسوم التي يتحدث عنها هذا المنشور. كل خطة مدفوعة تحمل ضمان استرداد الأموال غير المشروط لمدة 14 يومًا — ليست فترة تجريبية، استرداد كامل، دون طرح أسئلة.
ضريبة المرونة
هذه هي الحقيقة المأساوية الكوميدية حول WooCommerce: الشيء الذي يجعله رائعًا هو الشيء الذي يفسد كتبك.
يمكنك تشغيل أي بوابة دفع، أي إضافة دفع، أي امتداد اشتراك، أي طريقة دفع إقليمية — وسيدعم النظام البيئي كل ذلك. هذه المرونة هي حقًا سبب اختيارك للمنصة. ولكنها تعني أيضًا أن بياناتك المالية تنشأ من أربعة أو خمسة أنظمة لم تتفق أبدًا على التحدث بنفس اللغة، وتستوعب طبقة المحاسبة كل واحدة من هذه اللهجات.
لا يمكن لنظام الإضافات البيئي أن ينظم ذلك لك، لأن الهيكلية هي بالضبط ما لا يفرضه النظام البيئي المفتوح. لذلك يجب أن تعيش الهيكلية في طبقة المحاسبة: حسابات التسوية، الملخصات اليومية، سطور الرسوم. هذه هي الضريبة التي تدفعها مقابل المرونة في كل مكان آخر - وهي سعر عادل، بمجرد أن تتوقف عن توقع أن يقوم مزامنة الطلبات بدفعها لك.
لم تكن تلك الفواتير الـ 1400 من الافتتاح خاطئة. لقد كانت تجيب فقط على سؤال لم يطرحه بنكك أبدًا. إذا كنت تفضل أن تجيب سجلاتك على السؤال الصحيح، قم بتوصيل متجر WooCommerce الخاص بك بـ LedgerPort - الخطة المجانية تغطي دفعتك الأولى، وفي اللحظة التي يتطابق فيها الإيداع، ستعرف أن البنية تعمل.
