المتجر الإلكتروني: منصة مستأجَرة أم تطوير مخصّص؟

ترى Mesterséges Intelligencia Központ Kft.، شركة تطوير البرمجيات في بودابست بالمجر، أن البدء بمتجر إلكتروني على منصة مستأجَرة يجدر إذا اتسعت حدودها للتشكيلة؛ ويستحق التطوير المخصّص العناء عندما يتجاوز التسعير أو التكاملات تلك الحدود.

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

ما الخيارات المتاحة؟

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

المتجر الإلكتروني على منصة مستأجَرة (SaaS)

يعني SaaS (software as a service، البرمجيات كخدمة) أن مزوّد الخدمة يشغّل برنامج المتجر الإلكتروني ويحدّثه ويحميه، بينما يشترك فيه التاجر ويديره من المتصفح. ومن الأمثلة الدولية Shopify، وفي السوق المجرية Shoprenter وUNAS. ويمكن توسيع المنصات المستأجَرة بالإضافات، ويقدّم معظمها API أيضًا: وهي الواجهة البرمجية التي يمكن لنظام آخر عبرها أن يقرأ البيانات من المتجر الإلكتروني أو يكتبها فيه.

تصف وثائق المطوّرين لدى Shoprenter الواجهة موردًا بموردٍ، ومن بينها المنتجات والعملاء والطلبات، وتقدّم webhook أيضًا: رسالة تلقائية يرسلها المتجر الإلكتروني إلى نظام خارجي بعد حدث ما، مثل تقديم طلب أو تغيّر حالته (Shoprenter: WebHook automation). وبحسب وثائق UNAS، فإن الغرض من API هو ربط المتجر بالأنظمة الخارجية، وحتى في الاتجاهين، مثل برنامج الفوترة أو نظام إدارة المخزون؛ وتتاح الواجهة مع باقتَي الاشتراك PREMIUM وVIP (UNAS: وثائق API، تم التحقق في 17 أكتوبر 2026). ولذلك يجدر التحقق مما يتيحه المستوى المعني منذ اختيار الباقة.

متجر إلكتروني مفتوح المصدر بتشغيل ذاتي

من الأمثلة الشائعة WooCommerce، وهي إضافة متجر إلكتروني مفتوحة المصدر لنظام إدارة المحتوى WordPress. وشيفرتها المصدرية متاحة بموجب GNU General Public License، الإصدار 2 أو أي إصدار لاحق (WooCommerce: الترخيص)، ويذكر وصف الإضافة واجهة REST API وwebhooks للتكاملات، ويؤكد أن محتوى المتجر وبياناته تبقى لدى المالك (WordPress.org: WooCommerce). وللحرية ثمن: فعلى المالك، أو الجهة المشغّلة التي يكلّفها، أن يتولى أمر الاستضافة، وتحديث WordPress والإضافات، والنسخ الاحتياطي، والحماية.

المتجر الإلكتروني headless

في بنية headless («بلا رأس») تكون الواجهة التي يراها المشتري ومحرك المتجر الإلكتروني نظامين منفصلين. وبحسب وثائق المطوّرين لدى Shopify، تفصل التجارة headless الواجهة الأمامية (frontend) للمتجر عن واجهته الخلفية (backend): إذ يمكن بناء الواجهة وتشغيلها بأي تقنية، بينما تقدّم API المنصة المنتجاتِ وسلةَ التسوق وإتمامَ الشراء (Shopify: Headless). ويفيد ذلك عندما يجب أن تكون تجربة الشراء مميَّزة جدًا، أو عندما يكون المتجر الإلكتروني جزءًا من موقع غني بالمحتوى، أو عندما يجب عرض التشكيلة نفسها في عدة قنوات: على الويب، وفي تطبيق جوال، وفي كشك. والمقابل هو صيانة نظامين: المنصة والواجهة الخاصة.

المتجر الإلكتروني المطوَّر خصيصًا

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

مقارنة في جدول واحد

المعيار	منصة مستأجَرة	مفتوح المصدر (مثل WooCommerce)	Headless	التطوير المخصّص
البدء	الأسرع: قالب وإعدادات جاهزة	سريع، إذا كفت القوالب والإضافات الجاهزة	أطول: يجب بناء الواجهة الخاصة	الأطول؛ يحسمه حجم التطوير
نموذج الرسوم	اشتراك، وقد تُضاف رسوم التطبيقات الإضافية بشكل منفصل	لا اشتراك مقابل البرنامج؛ الاستضافة والإضافات المدفوعة والتشغيل	اشتراك المنصة، إضافةً إلى تطوير الواجهة الخاصة وتشغيلها	تطوير لمرة واحدة، ثم التشغيل والتطوير اللاحق
قابلية التوسيع	ضمن حدود المنصة وسوق إضافاتها	بحرية، لكن كل إضافة عنصر آخر يجب تحديثه	يمكن تشكيل الواجهة بحرية، والمحرك للمنصة	غير محدودة، وتخضع الشيفرة المصدرية لأحكام العقد
التكاملات (المخزون، ERP، الفوترة، التوصيل)	بإضافة جاهزة أو عبر API، إذا أتاحت الباقة ذلك	بإضافة أو بشيفرة مخصّصة	عبر API المنصة	عبر أي واجهة، بحسب احتياجات الشركة
الأداء	تحدّده البنية التحتية لمزوّد الخدمة وجودة القالب	يتوقف على الاستضافة وعدد الإضافات	يمكن تحسينه جيدًا، لكنه عمل ذاتي	يتوقف على التصميم والتشغيل
البيانات والتصدير	وفق وظائف التصدير في المنصة وشروطها	قاعدة البيانات كاملة ملك للمالك	بيانات المحرك موجودة على المنصة	قاعدة البيانات كاملة ملك للعميل
الاستضافة والأمان	مزوّد الخدمة مسؤول عنهما	المالك أو الجهة المشغّلة التي يكلّفها	مشتركة: المحرك للمنصة، والواجهة للشركة	العميل أو الجهة المشغّلة التي يكلّفها

السرعة يجدر قياسها لا تخمينها: فمؤشرات Core Web Vitals التي توصي بها Google تقيس التحميل (LCP)، والاستجابة (INP)، والثبات البصري (CLS) (web.dev: Web Vitals)، وتنطبق بالطريقة نفسها على أي نوع من المتاجر الإلكترونية.

متى تكفي المنصة المستأجَرة، ومتى يستحق التطوير المخصّص العناء؟

علامات على أن المنصة المستأجَرة تكفي

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

علامات على أنه يجدر الاتجاه نحو المخصّص أو headless

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

ومن الحلول الوسطى الشائعة والجيدة المتجر الإلكتروني على منصة مستأجَرة مع تكامل مخصّص: يبقى المتجر على المنصة، وخلفه تربط خدمة مخصّصة الطلباتِ ببرنامج الفوترة، والمستودع، ونظام تخطيط موارد المؤسسة. وهذه مهمة تكامل أنظمة؛ وتصف صفحة أتمتة العمليات التفاصيل. ويتناول مقال برمجيات مخصّصة أم حل جاهز (SaaS)؟ المقارنة العامة بين البرمجيات المخصّصة والمنتج الجاهز.

الخصوصيات المجرية: الفوترة، وNAV، وشركات التوصيل، والدفع

الفوترة وNAV Online Számla

بحسب ما تعلنه مصلحة الضرائب المجرية (NAV)، يشمل الإبلاغ عن بيانات الفواتير منذ 4 يناير 2021 أيضًا الفواتير الصادرة للأشخاص غير المسجلين في ضريبة القيمة المضافة، ومنهم المشترون الأفراد؛ ويجب على برنامج الفوترة أن يرسل البيانات إلكترونيًا إلى نظام Online Számla فور إصدار الفاتورة، دون تدخّل بشري، بصيغة XML (NAV). وتنشر NAV وصف الواجهة الآلية في مستودع عام أيضًا (NAV: Online-Invoice). وتعالج المتاجر الإلكترونية ذلك عادةً عبر خدمة فوترة: فبحسب وثائق Számlázz.hu مثلًا، يمكن عبر الواجهة المسمّاة Számla Agent أتمتة عمليات الفواتير والإيصالات بصيغة XML (Számlázz.hu: وثائق API). والجوهر هو العملية: أن تنشأ الفاتورة من الطلب المدفوع أو المنفَّذ دون نقل يدوي، وأن يُبلَّغ أحدٌ عندما يفشل الإبلاغ عن البيانات أو يُرفض.

شركات التوصيل وخزائن استلام الطرود

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

الدفع الإلكتروني

في الدفع بالبطاقة المصرفية، ينطبق معيار الأمان الدولي PCI DSS على كل من يخزّن بيانات البطاقات أو يعالجها أو ينقلها. وبحسب وثائق Stripe، تصل بيانات الدفع في التكاملات التي تقلّل المخاطر مباشرة إلى مزوّد خدمات الدفع، دون أن تمرّ عبر خوادم التاجر، وهذا يخفّف التزامات التاجر المتعلقة بـPCI (Stripe: Integration security guide). ولذلك نوصي بألّا يخزّن المتجر الإلكتروني بيانات البطاقات، وبأن يجري الدفع على صفحة مزوّد الخدمة أو في واجهته المضمَّنة، مثل Barion أو SimplePay أو Stripe.

المخزون وتخطيط موارد المؤسسة

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

المعلومات القانونية التي تسري على كل متجر إلكتروني

تسري القوانين بصرف النظر عن المنصة: ففي المنصة المستأجَرة تساعد المنصة في أمور كثيرة، لكن التاجر هو المسؤول عن الامتثال. هذه معلومات إرشادية وليست استشارة قانونية؛ ومن المفيد في الحالة المحددة استشارة محامٍ.

حق العدول

ينظّم التوجيه 2011/83/EU حقوق المستهلكين في العقود المبرمة عن بُعد؛ وتستند النقاط التالية إلى النص الموحَّد بتاريخ 27 سبتمبر 2026 (EUR-Lex: التوجيه 2011/83/EU، النص الموحَّد):

بموجب الفقرة (1) من المادة 9، يجوز للمستهلك العدول عن العقد خلال 14 يومًا دون إبداء أسباب؛ وفي حالة السلع، تُحسب المدة كقاعدة عامة من يوم استلام السلعة.
بموجب البند (h) من الفقرة (1) من المادة 6، يجب على التاجر أن يُعلم المستهلك قبل إبرام العقد بشروط حق العدول ومهلته وإجراءاته؛ ويشمل ذلك نموذجَ إشعار العدول، والإعلامَ (عند الاقتضاء) بوجود وظيفة العدول وموضعها.
بموجب المادة 11a التي أُدرجت بالتوجيه (EU) 2023/2673، يجب على التاجر في العقود المبرمة عن بُعد عبر واجهة إلكترونية أن يوفّر وظيفة عدول تحمل عبارة تفيد «العدول عن العقد» (وفي النص الإنجليزي للتوجيه: “withdraw from contract here”)، أو صيغة مقابلة لا لبس فيها، وتكون متاحة باستمرار طوال مدة العدول، يستطيع المستهلك بها إرسال إشعار عدول إلكتروني؛ ويُرسَل الإشعار بخطوة تحمل عبارة تفيد «تأكيد العدول» (“confirm withdrawal” في النص الإنجليزي)، ويرسل التاجر إقرارًا باستلامه على وسيط دائم. وتطبّق الدول الأعضاء هذه الأحكام اعتبارًا من 19 يونيو 2026 (EUR-Lex: التوجيه (EU) 2023/2673).
إذا لم يُقدَّم هذا الإعلام، فبموجب المادة 10 تنتهي مدة العدول بعد 12 شهرًا من انتهاء المهلة الأصلية.
بموجب المادة 13، يردّ التاجر كامل المبلغ الذي دفعه المستهلك، بما في ذلك تكاليف التوصيل عند الاقتضاء، خلال 14 يومًا من إبلاغه بالعدول.
تسرد المادة 16 استثناءات، مثل السلع المصنوعة وفق مواصفات حدّدها المستهلك، أو المخصّصة لشخصه بوضوح.

وفي المجر ترد القواعد التفصيلية في المرسوم الحكومي رقم 45/2014 (II. 26.)؛ وتنظّم وظيفةَ العدول أحكامُ المادة 22 منه التي أُدرجت بالمرسوم الحكومي رقم 415/2025 (XII. 23.) (Nemzeti Jogszabálytár، تم التحقق في 17 أكتوبر 2026). ويعني ذلك للمتجر الإلكتروني وظائف ملموسة: يجب أن يظهر الإعلام قبل الطلب، ويجب أن تكون وظيفة العدول الإلكترونية متاحة باستمرار طوال مدة العدول، مع إقرار بالاستلام، ويجب تتبّع الإرجاع وردّ المبالغ، ويجب تمييز المنتجات المخصّصة للشخص.

إمكانية الوصول

بموجب التوجيه (EU) 2019/882، يتعيّن على الدول الأعضاء أن تطبّق اعتبارًا من 28 يونيو 2025 متطلبات إمكانية الوصول الخاصة بخدمات التجارة الإلكترونية المقدَّمة للمستهلكين (وتستند القواعد المجرية إلى نقل هذا التوجيه إلى القانون الوطني)؛ وتُعدّ خدمةَ تجارة إلكترونية الخدمةُ المقدَّمة عبر المواقع الإلكترونية والخدمات القائمة على الأجهزة المحمولة بهدف إبرام عقد مع المستهلك (EUR-Lex: التوجيه (EU) 2019/882). ويجب إعفاء المؤسسات متناهية الصغر التي تقدّم الخدمات من هذه المتطلبات (الفقرة (5) من المادة 4)، وهي بحسب التوجيه المؤسسات التي يعمل لديها أقل من عشرة أشخاص، ويقل رقم أعمالها السنوي أو مجموع ميزانيتها عن حدّ معيّن. وبحسب الملحق الأول من التوجيه، يجب جعل المواقع الإلكترونية وتطبيقات الجوال قابلة للإدراك، وقابلة للتشغيل، ومفهومة، ومتينة. وفي المنصة المستأجَرة يتوقف جزء من ذلك على المنصة وعلى جودة القالب المختار، ولذلك يجدر فحص القالب من حيث إمكانية الوصول أيضًا؛ وفي المتجر الإلكتروني المخصّص نتبع إرشادات WCAG 2.2.

ملفات تعريف الارتباط والموافقة

بموجب الفقرة (3) من المادة 5 من النص الموحَّد لتوجيه الخصوصية والاتصالات الإلكترونية، التوجيه 2002/58/EC، لا يجوز تخزين البيانات على جهاز المستخدم أو الوصول إلى البيانات المخزّنة عليه إلا بموافقة مسبقة تُعطى بعد إعلام واضح وشامل. ويُستثنى التخزين الضروري حتمًا لتقديم خدمة طلبها المستخدم صراحةً (EUR-Lex: التوجيه 2002/58/EC). ولذلك يُعامَل ملف تعريف الارتباط اللازم لعمل سلة التسوق معاملة مختلفة عن ملف تعريف ارتباط للقياس أو الإعلان: فهذان الأخيران يتطلبان الموافقة، ويجب أن يتيح شريط ملفات تعريف الارتباط اختيارًا حقيقيًا.

الذكاء الاصطناعي في المتجر الإلكتروني

نصوص المنتجات: إعداد أوصاف المنتجات ونصوص الفئات والترجمات بنموذج لغوي كبير. وبعض المنصات المستأجَرة تقدّم ذلك مدمجًا بالفعل: فبحسب مركز مساعدة Shopify، تكتب وظائف الذكاء الاصطناعي في واجهة الإدارة أوصاف المنتجات أيضًا، وتطلب Shopify نفسها من التاجر أن يراجع كل محتوى ينشئه الذكاء الاصطناعي، لأنه قد يكون خاطئًا (Shopify Help Center: وظائف الذكاء الاصطناعي).
البحث: بحث عن المنتجات يفهم نية المشتري أيضًا («حذاء مشي مقاوم للماء للمطر»)، لا الكلمة المفتاحية الدقيقة فحسب.
خدمة العملاء: روبوت محادثة بالذكاء الاصطناعي يجيب من بيانات المتجر نفسه، أي المنتجات وشروط الشحن وحالة الطلب، ويوضح أن المشتري يتحدث مع ذكاء اصطناعي. التفاصيل في صفحة روبوتات المحادثة ووكلاء الذكاء الاصطناعي؛ ويتناول مقال AI Act وGDPR الخلفية القانونية.

وفي المنصة المستأجَرة يتوقف نطاق وظائف الذكاء الاصطناعي على ما تقدّمه المنصة أو إحدى الإضافات. أما في المتجر الإلكتروني المخصّص أو مع التكامل المخصّص، فيمكننا الاختيار من بين نماذج OpenAI (ChatGPT) وAnthropic (Claude) وGoogle (Gemini)، ونربط النموذج مباشرة ببيانات المتجر الإلكتروني، مع مراجعة بشرية حيث يكلّف الخطأ مالًا أو ثقة.

الانتقال: من منصة مستأجَرة إلى متجر مخصّص

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

جرد البيانات: ما البيانات الموجودة في النظام القديم (المنتجات، والمتغيّرات، والصور، والعملاء، والطلبات السابقة، والقسائم، وصفحات المحتوى)، وما الذي يمكن تصديره منه.
مطابقة البيانات وتنظيفها: إلى أين ينتقل كل حقل قديم، وما الذي يحتاج إلى ترتيب، مثل العملاء المكرّرين أو بيانات المنتجات الناقصة.
خريطة عناوين URL وإعادة التوجيه: بحسب إرشادات Google Search Central، يجب ربط كل عنوان قديم بعنوان جديد، وإعداد إعادة توجيه دائمة من جهة الخادم (301 أو 308)، حتى لا يضيع الترتيب الذي تحقق في محركات البحث (Google Search Central).
إعادة ربط التكاملات: الفوترة، والدفع، والتوصيل، والمخزون، مع اختبارها من البداية إلى النهاية بطلبات تجريبية.
الإطلاق الفعلي والمتابعة: مزامنة أخيرة لبيانات النظام القديم، ثم مراقبة المؤشرات والأخطاء بعد الانتقال.

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

علامَ تتوقف التكلفة والمدة؟

في المنصة المستأجَرة تتكون التكلفة من الاشتراك، والتطبيقات الإضافية، والقالب، والعمل المبذول في الإعداد؛ وإذا لزم تكامل مخصّص أيضًا، فهو تطوير منفصل. أما في المتجر الإلكتروني المخصّص فنقيس الحجم الوظيفي للتطوير بنقاط COSMIC الوظيفية (ISO/IEC 19761)، ومنه يُعَدّ العرض والجدول الزمني. وإلى جانب الحجم، تهمّ العوامل التالية:

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

وتصف صفحة التسعير طريقة القياس.

الأخطاء الشائعة عند اتخاذ القرار

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

الأسئلة الشائعة

هل نختار متجرًا إلكترونيًا على منصة مستأجَرة أم متجرًا مخصّصًا؟

إذا اتسعت حدود منصة مستأجَرة (مثل Shopify أو Shoprenter أو UNAS) أو WooCommerce لتشكيلة المنتجات وعملية الطلب، فهذا هو البدء الأسرع والأقل مخاطرة. ويستحق المتجر الإلكتروني المخصّص العناء إذا كانت التشكيلة أو التسعير غير معتادين، أو إذا لزم ارتباط وثيق وآني بنظام ERP أو بمستودع، أو إذا كان المتجر الإلكتروني قناة المبيعات الرئيسية وتريدون تطويره دون قيود المنصة. والطريق الوسط هو المتجر الإلكتروني على منصة مستأجَرة مع تكامل مخصّص.

هل يمكن الانتقال من منصة مستأجَرة إلى متجر مخصّص؟

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

هل يمكن ربط المتجر الإلكتروني ببرنامج الفوترة والمستودع؟

نعم. نربط برنامج الفوترة (مثل Számlázz.hu وBillingo) عبر إصدار الفواتير تلقائيًا، ونظام إدارة المستودع أو نظام ERP عبر مزامنة المخزون، إذا كانت لديهما واجهة متاحة (API)، أو كانت البيانات متاحة في ملف أو قاعدة بيانات. ويمكن بناء ربط كهذا خلف متجر إلكتروني على منصة مستأجَرة أيضًا، إذا كانت API المنصة متاحة في الباقة المختارة.

لمن تعود البيانات في المنصة المستأجَرة؟

تحدّد ذلك شروطُ استخدام المنصة واتفاقيةُ معالجة البيانات الخاصة بها؛ فبموجب المادة 28 من GDPR، يجب أن ينظّم عقدٌ معالجةَ البيانات التي تجري نيابةً عن المتحكّم في البيانات (EUR-Lex: اللائحة (EU) 2016/679). والحاسم عمليًا هو ما إذا كان بإمكانكم إخراج بياناتكم: فالمنصات الأكبر تقدّم التصدير وAPI، لكن نطاق ذلك يختلف من منصة إلى أخرى ومن باقة إلى أخرى. أما في المتجر الإلكتروني ذاتي التشغيل أو المخصّص، فقاعدة البيانات كاملة لدى المالك.

هل يجب أن يستوفي المتجر الإلكتروني متطلبات إمكانية الوصول؟

بموجب القواعد التي تنقل التوجيه (EU) 2019/882 إلى القانون الوطني، يجب أن تستوفي خدمات التجارة الإلكترونية المقدَّمة للمستهلكين متطلبات إمكانية الوصول منذ 28 يونيو 2025؛ ويجب بحسب التوجيه إعفاء المؤسسات متناهية الصغر التي تقدّم الخدمات. وإذا لم تكن الشركة مؤسسة متناهية الصغر، فيجدر فحص المتجر الإلكتروني من حيث إمكانية الوصول، وكذلك القالب في المنصة المستأجَرة. هذه معلومات إرشادية وليست استشارة قانونية.

كيف نساعدكم؟

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

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