Le 05/07/2013 11:27, Ybbet Spip a écrit :
Je rebondis sur le message d'Hervé. Je crée un autre topic pour ne pas
polluer le précédent topic.
Ça en est où le projet de plugin ecommerce pour SPIP ? Il y a zcommerce :
Connexion · GitLab
Il me semble que les plugins nécessaires sont portés sous SPIP 3 à peu
de choses prêt…
Bonjour,
il y a a pas mal de choses dans ce meta plugin, c'est une base.
Mais je pense qu'il y a encore des manques fonctionnels pour pouvoir proposer un système ecommerce vraiment généraliste.
J'en avais parlé rapidement avec Touti lors d'un apéro Spip mais je m'étais peut être mal exprimé.
(Touti, si tu me lis, au plaisir de se recroiser pour discuter de ça et d'autres choses...)
J'ai travaillé sur différents projets ecommerce ces dernières années, sur des bases oscommerce, thelia ou prestashop très customisées, je me permets d'apporter un petit retour d'expérience.
Il y a un point qui n'est pas traité par zcommerce et les plugins qui le composent, c'est le système de taxes (TVA).
Et c'est un gros morceau.
Déjà, une boutique peut proposer des produits (ou des services) à différents taux de TVA, certains produits à 19.6 et d'autres à 7 dans la même commande par exemple.
Il faut gérer tout ça et avoir ces taux détaillés dans les commandes (obligatoire pour la compta des entreprises, vendeuses ou clientes).
Ensuite, les taux de TVA ne s'appliquent pas de la même façon selon l'adresse de la boutique et le lieu de livraison : pour une boutique en France, par exemple, normalement la vente doit se faire HT dans les DOM TOM, idem hors UE : vente HT.
Les différentes solutions que je connais le gèrent à peu près de la même façon : un produit est lié à une classe de taxe, les classes de taxes sont liées à des zones fiscales et à des taux, les zones étant composées de pays (avec la subtilité des DOM TOM qui sont en France).
Les prix sont toujours stockés HT en base de données.
Au niveau logistique, une solution ecommerce doit pouvoir proposer plusieurs modes de livraison (colis, retrait en magasin...), qui peuvent pour certains s'interfacer avec des solutions existantes (socolissimo de la poste, relais de magasins, livreurs privés), avec des tarifs variables.
Idéalement, tout ça doit pouvoir être lié au système de zones (socolissimo par exemple, dispo uniquement en france et depuis peu en belgique).
Et ce système doit être suffisamment souple pour gérer des cas particuliers : par exemple pour une commande "virtuelle" (qui ne contient que des produits dématérialisés), zapper complètement la phase du transport.
Prévoir donc une API suffisamment souple et ouverte.
Idem pour les systèmes de paiement, hormis les chèques et les virements, tous les paiements s'appuient sur des API externes (banques, paypal...), là aussi l'API de paiement doit être suffisamment ouverte.
Et je suis complètement d'accord avec Gilles, qui préconise de proposer plutôt un framework (à la Drupal commerce) plutôt qu'une solution verticale toute prête, avec son template prêt à l'emploi.
C'est le modèle à suivre.
Le sur mesure, c'est la grande force de Spip.
--
Nico D.
après les freins ça eut être : la charte de contrib, le fait que historiquement spip est pas fait pour le business dans l’hétique.
après les freins ça eut