برنامج محاسبة وفواتير إلكترونية لمتجر ووكومرس: كيف تربط قيود مع ووكومرس

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

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

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

ما يجعل محاسبة متجر ووكومرس مختلفة عن غيرها

معظم أسئلة ربط المحاسبة بالمتاجر تُطرح كأن المنصات كلها من نوع واحد. في الواقع، الفرق بين ووكومرس وغيره فرق في البنية لا في الميزات، وهو الفرق الذي يحدد شكل الربط ومن يتحمل مسؤوليته.

الاستضافة الذاتية على ووردبريس بلا متجر تطبيقات مركزي

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

وهذا يفسّر لماذا يمر الربط عبر Zapier. فالوسيط هنا يقوم بالدور الذي يقوم به متجر التطبيقات في المنصات المستضافة: يتحدث مع متجرك من جهة، ومع قيود من جهة، ويترك لك تحديد أي حدث في المتجر يقابله أي إجراء في دفاترك. الجانب الآخر من هذه الحرية أن ضبط الحقول واختبارها ومتابعتها مسؤوليتك، لا مسؤولية المنصة.

لا تكامل أصلي، ولا عبارة «بدون وسيط»

يجب أن يكون هذا صريحًا: لا يوجد تكامل مباشر بين قيود ومتجر ووكومرس، وعبارة «بدون وسيط» غير صحيحة في هذه الحالة. العبارة صحيحة في حالة سلة وحدها، حيث يُربط المتجر عبر تطبيق قيود الرسمي المثبَّت في المنصة. حتى منصة زد تُربط عبر تطبيق شريك هو FAI Sync، لا عبر ربط مباشر. لو قرأت في أي مكان أن ووكومرس يتصل بقيود بدون وسيط، فالمعلومة غير دقيقة، والبديل الحقيقي مساران فقط: Zapier أو واجهة برمجة التطبيقات.

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

توزيع الأدوار بين المتجر وبرنامج المحاسبة

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

ما ينتهي عنده دور المتجر

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

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

كيف تربط قيود مع ووكومرس عبر Zapier

الربط أربع خطوات لا تحتاج مبرمجًا وتستغرق نحو 10 دقائق. لكن قبل الخطوة الأولى يوجد شرط لا يمكن تجاوزه، وترتيب البداية ليس من حيث يتوقعه معظم الناس.

شرط الباقة قبل أي خطوة إعداد

الربط الإلكتروني عبر Zapier غير متاح في الباقة الأساسية. يبدأ من الباقة الاحترافية ثم المتقدمة. وبما أن التجربة المجانية 14 يومًا تعمل على الباقة الأساسية، فلا يمكن تنفيذ ربط ووكومرس أثناء التجربة، وهذه نقطة تُربك كثيرًا من المتاجر لأنها تُكتشف بعد بناء التوقعات لا قبلها.

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

الخطوات الأربع للربط

الخطوة 1 تبدأ من داخل قيود: الإعدادات ثم الربط الإلكتروني ثم خدمات ربط قيود ثم «ابدأ الربط» مقابل Zapier. البداية من قيود لا من Zapier، وهذا ما يجعل حسابك موثّقًا قبل أي شيء آخر.

الخطوة 2: يحوّلك قيود تلقائيًا إلى Zapier ويُتَمّ ربط حساب قيود هناك. بعد اكتمال التوثيق تبدأ من قالب ووكومرس مع قيود بدل بناء مسار من الصفر، ويبقى عليك تسجيل الدخول إلى متجرك واعتماد الصلاحيات المطلوبة.

الخطوة 3: اربط الحقول. حدد أي حالة طلب تشغّل المسار، وطابق أصناف المتجر مع أصنافها في قيود، وحدد حساب الضريبة وطريقة الدفع والحساب البنكي. هذه الخطوة هي التي تحدد جودة دفاترك بعد شهر، فلا تستعجلها.

الخطوة 4: اختبر ثم فعّل. مرّر طلبًا اختباريًا واحدًا وتابعه حتى الفاتورة والقيد، وتحقق من الضريبة والمبلغ والعميل، ثم فعّل المسار على كل الطلبات.

ثلاث ملاحظات قبل الإعداد

(أ) الصلاحية شرط لظهور الخيار. يحتاج المستخدم صلاحية «الربط الإلكتروني»: الإعدادات ثم المستخدمون ثم إدارة المناصب ثم تعديل المنصب المرتبط بالمستخدم ثم تفعيل «الربط الإلكتروني». وبدونها لن يظهر خيار الربط أصلًا، فلا تظن أن الميزة غير موجودة قبل أن تفحص منصبك.

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

(ج) إدارة مسارات Zapier مسؤوليتك. قيود لا يقدّم مساعدة في إنشاء مسارات Zap ولا في تصميمها، وإدارتها بالكامل من Zapier: التشغيل والإيقاف والتعديل وفصل الربط. وأي خطأ في المسار يُراجَع مع Zapier أولًا، لأن الخطأ يقع في طبقة الوسيط لا في دفاترك.

مسار الطلب من ووكومرس إلى فاتورة ضريبية

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

ما ينتقل فعلًا في كل حدث

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

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

الإلغاء والإرجاع يقابلهما إشعار دائن تربطه أنت

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

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

كيف تحسب مهام Zapier مقابل حجم طلبات متجرك

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

طريقة الحساب: عدد الطلبات مضروبًا في عدد الأحداث

Zapier لا يحسب عدد مساراتك بل عدد المهام التي تنفّذها. كل حدث ينفّذه المسار يستهلك مهمة واحدة. فإن ربطت أربعة أحداث لكل طلب، وهي إنشاء الفاتورة وإنشاء العميل وتسجيل الدفعة وإشعار التنبيه، فمعادلتك: عدد الطلبات مضروبًا في 4.

متجر يستقبل 100 طلب شهريًا وربط أربعة أحداث لكل طلب يستهلك 400 مهمة (100 × 4 = 400). وإن ربطت حدث الإرجاع أيضًا، أضف مهمة لكل مرتجع، وهي مهام تُحسب فوق الأربع. اقرأ الرقم كسقف لا كمتوسط، لأن أشهر الحملات ترفع الطلبات دفعة واحدة.

مثال عملي على متجر بثلاثمئة طلب شهريًا

خذ متجرًا يستقبل 300 طلب شهريًا بأربعة أحداث لكل طلب. الأساس 1,200 مهمة (300 × 4). ولو كانت نسبة المرتجعات 6%، فذلك 18 مرتجعًا (6% من 300 = 18)، وكل مرتجع يقابله إشعار دائن تربطه أنت، فيرتفع الاستهلاك إلى نحو 1,218 مهمة شهريًا. وحين تصل الحملة الموسمية بمتجرك إلى 600 طلب في شهر واحد، يتضاعف الرقم مباشرة.

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

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

متى يكفي Zapier ومتى تحتاج واجهة برمجة التطبيقات

Zapier ليس حلًا لكل متجر، وواجهة برمجة التطبيقات ليست ترقية تلقائية. الفرق بينهما في طبيعة دورة البيع لا في حجم الشركة.

الحالات التي يكفيها Zapier

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

العلامات التي تدفعك إلى مسار API

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

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

والملاحظة الحاكمة هنا أن تغيير المسار لا يغيّر شرط الباقة: المساران كلاهما، Zapier وواجهة برمجة التطبيقات، يبدآن من الباقة الاحترافية فما فوق. فالانتقال إلى API لا يفتح لك بابًا مغلقًا بحكم الباقة، بل يعطيك تحكمًا أدق داخل الباب نفسه.

إضافات ووردبريس التي تغيّر بنية الطلب فيتوقف الربط

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

كيف تتسبب إضافة في توقف الربط وكيف تحمي نفسك

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

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

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

بيانات العميل: الشراء بدون تسجيل وتسعير مجموعة العميل

بعد الأحداث والحقول يبقى سؤال يتكرر في كل متجر ووكومرس: من هو العميل في دفاترك حين لا يكون له حساب في المتجر، وماذا يحدث للسعر حين يكون العميل متعاقدًا معك؟

الشراء بدون تسجيل وتنظيم جهات الاتصال

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

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

تسعير مجموعة العميل: تحذير لا وعد

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

الضريبة والفاتورة الإلكترونية في متجر ووكومرس

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

ضريبة 15% واحتسابها على سطر الفاتورة

ووكومرس يحسب ضريبة القيمة المضافة على السلة ويعرضها للمشتري، وهذا كافٍ للعرض لا للإقرار. القيمة المحاسبية تتحقق حين تُحتسب الضريبة بنسبة 15% على سطر الفاتورة في قيود وتُرحَّل إلى حسابها الصحيح، لأن الإقرار يُبنى من الحساب الضريبي لا من تقرير المتجر. وإن أردت التحقق من صحة رمز QR على فاتورة صادرة، فاستخدم قارئ رمز QR للفاتورة الإلكترونية ليقرأ محتواه فورًا.

المرحلة الثانية والربط مع الهيئة

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

قائمة التحقق قبل أول Zap

الربط الناجح يبدأ قبل المسار: حساب مرتّب وبيانات معرّفة. القائمة التالية سبعة بنود، كل بند منها سبب معروف لتوقف الربط أو لفواتير ناقصة بعد التفعيل.

ترتيب البيانات قبل الربط واختباره على طلب واحد

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

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

كيف يساعدك قيود في محاسبة متجر ووكومرس

بعد أن تعمل المسارات، ما يفرق بين متجر يقرأ أرقامه ومتجر يجمعها هو ما يوفّره النظام حول الفاتورة نفسها:

• فاتورة ضريبية كاملة لكل طلب بأصنافها وخصوماتها والشحن، مع احتساب ضريبة القيمة المضافة 15% وترحيلها إلى حسابها الصحيح.
• استيراد فواتير المبيعات عبر إكسل حتى 5,000 سطر، مع تقرير أخطاء لكل سطر يصلك بالبريد، وهو مخرجك لترحيل أرشيف المتجر السابق دفعة واحدة.
• التسوية والمطابقة البنكية الذكية، فتقابل كل حوالة واصلة مع فواتيرها بدل مراجعة كشف الحساب سطرًا سطرًا.
• مراكز التكلفة، لتفصل نتائج المتجر الإلكتروني عن بقية قنوات البيع وتعرف أي قناة تكسب فعلًا.
• المخزون بمواقع متعددة، فتعرف رصيد كل موقع بدل رصيد إجمالي لا يخبرك من أين تشحن.
• مقارنة حتى 13 فترة في التقارير، لتقرأ الموسمية في متجرك، وتصدير النتائج إلى إكسل وPDF.

وهذه القدرات وغيرها يختلف نطاقها بحسب الباقة: فعمليات المخزون وفواتير المشتريات ومراكز التكلفة وربط Zapier تبدأ من الباقة الاحترافية فما فوق، وبعض القدرات تحتاج المتقدمة. راجع نطاق باقتك مع فريق المبيعات قبل أن تبني عليها.

أسئلة شائعة عن ربط قيود مع ووكومرس

هل يوجد تكامل مباشر بين قيود ووكومرس؟

لا. الربط بين قيود ومتجر ووكومرس يمر عبر Zapier فقط، ولا يوجد تكامل أصلي أو مباشر بينهما. الوصف الذي يُقال عن منصة سلة، وهو ربط عبر تطبيق قيود الرسمي داخل المنصة، لا ينطبق على ووكومرس، ومنصة زد نفسها تُربط عبر تطبيق شريك هو FAI Sync. لذلك أي عبارة من نوع «بدون وسيط» أو «تكامل مباشر» غير صحيحة في حالة ووكومرس، والسبب بنيوي: ووكومرس إضافة مستضافة ذاتيًا على ووردبريس، فلا يوجد متجر تطبيقات مركزي تُنشر فيه تطبيقات رسمية.

كم يستغرق الإعداد ومن يستطيع تنفيذه؟

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

من أين يبدأ الإعداد بالضبط؟

يبدأ من داخل قيود لا من Zapier: الإعدادات ثم الربط الإلكتروني ثم خدمات ربط قيود ثم «ابدأ الربط» مقابل Zapier. عندها يحوّلك قيود تلقائيًا إلى Zapier ويُتَمّ ربط حساب قيود هناك، ثم تبدأ من قالب ووكومرس مع قيود بدل بناء مسار من الصفر، ويبقى عليك تسجيل الدخول إلى متجرك واعتماد الصلاحيات. توثيق حساب قيود يأتي قبل اختيار القالب لا بعده، وهذا الترتيب هو ما يجعل القالب يعرض حسابك الحقيقي عند ربط الحقول.

كيف تُحسب تكلفة Zapier في هذا الربط؟

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

هل تتيح التجربة المجانية تجربة الربط مع الهيئة للمرحلة الثانية؟

لا. التجربة المجانية 14 يومًا تعمل على الباقة الأساسية، والربط مع الهيئة للمرحلة الثانية غير متاح في الأساسية ومتاح في الاحترافية والمتقدمة. فإن كان متجرك داخل نطاق المرحلة الثانية، فالقدرة التي تحتاجها مرتبطة بالباقة لا بالتجربة، وراجع نطاق باقتك مع فريق المبيعات قبل أن تخطط لموعد الالتزام. الأمر نفسه يسري على الربط عبر Zapier.

هل يُنشئ الربط إشعارًا دائنًا تلقائيًا عند الإرجاع؟

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

كيف أتعامل مع المرتجعات في تقاريري المالية؟

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

ما الذي يحدث إن كان لديّ أكثر من منشأة أو أكثر من متجر؟

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

الخلاصة

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

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