Carnet Wiki

SPIP 3 et e-commerce

Version 25 — 20 janvier — 78.238.xx.xx

[Pierre-Jean] propose de :
-  Lister les demandes/propositions et le catégoriser (produits, paiement, déclinaisons, colisage, etc)
-  Lister les plugins (briques) existants et voir ce qui peut être réutilisé
-  Discuter de la composition de l’outil ; un plugin qui fait tout/un plugin par fonction (gestion produits, paiement, colisage...)

Petit point d’organisation :
-  On commence à avoir pas mal d’idées et de contenu, il serait temps de structurer le projet en grand chapitres et de faire un peu de curation sur ce qui a été dit afin de mettre au propre les fonctions et propositions qui font l’unanimité, celles en suspend, etc.
-  Il serait aussi intéressant que chacun des participants puisse se présenter (en bas de page par ex.) et indique ce qu’il sait/peut faire dans ce projet.


[rainer] : je propose récupére ce qui existe, faire des nouveaux plugins pour les fontionnalités non couvertes, puis integrer le tout via un plugin maitre dans le style de z-commerce (dont je ne trouve plus de trace) [Soon7] L’idée d’un plugin maitre (genre spip3ecommerce) et de plusieurs « sous plugins » utilisant des pipelines créés par le premier (par exemple un pipeline prepayement, postpayement, que peuvent appeler un plugin payement_atos, payement_paypal, etc) me parait très élégante. Idée pas de moi mais évoquée dans la liste. [Pierre-Jean] oui, élégant, maintenable et plus facile de faire évoluer les « sous-plugins » vers des besoins de plus en plus spécifiques

[triton] je parlais dans un mail d’un pipeline pour la gestion du prix d un produit. A partir d un prix HT, prévoir des points entrée genre : taxe, quantité, devise.. qui permettrait d effectuer des calculs sur le prix de base et d’obtenir l’affichage final d un prix net pour un client donné.

[Pierre-Jean]Merci à Ybbet pour l’espace !
[Soon7] oui ! Merci Ybbet !


FONCTIONS DES PLUGINS


Gestion des produits

[Pierre-Jean]
-  Classer les produits : à mon sens un produit est un objet éditorial comme un autre qui peut bénéficier de l’organisation classique de SPIP = on y attache des mots clefs, des documents, on l’ajoute à une rubrique, etc. En ce sens, je ne vois pas le besoin de créer une nouvelle structure de type Catégorie comme j’ai pu le lire ailleurs.
[triton] ça ne me parait pas une bonne idée de mélanger des produits et des articles au sein de rubriques... les produits sont vraiment des objets a part, pas des pseudos articles... imaginons par exemple ce qu il va se passer lorsque l on voudra faire un menu pour les produits s il faut aller chercher dans les rubriques ce qui est prod et ce qui est article (d un point de vue formelle, je ne sais si je peux intervenir comme ça dans le wiki ?)

[rainer] cela dépend, parfois il est utile de reprendre une structure déjà donnée, on pourrait le laisser au choix
[Pierre-Jean] Effectivement, dans de nombreux cas, les rubriques sont suffisantes. Et lorsque cela n’est pas le cas, une rubrique « Boutique » peut jouer ce rôle. L’intérêt que je vois à SPIP depuis le début dans ce projet e-commerce est de pouvoir contextualiser l’offre produit dans l’éditorial. Après je comprend qu’on puisse vouloir scinder en deux rubriques (éditorial) et catégories (produits à la vente) par soucis d’organisation. Néanmoins, si la demande de catégories est bien avérée, je serai d’avis que l’on propose, au choix, d’utiliser les rubriques et/ou les catégories.

-  Caractéristiques des produits : ont-elles besoin d’être gérées dans le plugin ? Je pense que pour beaucoup, l’ajout de mots clefs comme caractéristique serait pertinent et que pour d’autres les Champs Extras puissent remplir cette mission.
[triton] qu’entends-tu par Caractéristiques des produits ? champs extra m’en suis toujours méfiés, depuis le temps qu ils doivent disparaître de spip, mais surtout les champs extra ça implique qu il y aura de la bidouille de code a entreprendre pour chaque site ?

[rainer] faute de gestion dédié, les mots clés peuvent servir pour cataloguer (caractéristiques ?) les produits. Puis si il s’avère nécessaire un plugin spécifique pourra reprendre ce rôle. Pour les champs extras. Je crois qu’il est utile de prévoir un moyen, avec ou sans champs extras pour ajouter de nouveaux champs. J’ai déjà expérimenté des solutions qui avec une déclaration des champs dans un tableau (extensible via pipeline) et le plugin saisies (et parfois également avec cextras) crée un formulaire Config qui permet de choisir et rendre obligatoire de champs.

-  [alain]Les types de produits sont : objet unitaire, objets avec versions, virtuels - fichiers, abonnements (limite de durées) - (voir la logique du plugin abonnement de thélia). Ces typologies sont, à mon sens, du ressort du plugin, car elles induisent des traitements adaptés à chacune. Par exemple un produit en abonnement ne vas pas ’vivre’ de la même façon qu’un objet prototype.
[triton] a quoi ca va servir concrètement de typer les produits de cette manière (vraie question) ?
[Pierre-Jean] idem. Personnellement sur intéressé par la vente physique et dématérialisée. Mais que pourrait apporter de manière concrète cette classification ? Un système de tris/filtre pour les listing produits ou la navigation à facette par exemple ?
-  Référence produit ;
-  EAN13 ou JAN
-  UPC
-  Quantité minimale [Pierre-Jean] Devrait être un "minimum qu’il s’agisse de quantité (nombre de produits), de mètres (longueur de tissus par ex), de volume (vente de terreaux), de L ou CL (vente de liquides) ...


Déclinaisons
-  Attribut (ce en quoi il diffère)
-  Valeur de l’attribut
-  Caractéristique
-  Référence produit ;
-  EAN13 ou JAN
-  UPC
-  Stock
-  Prix
On retrouve ici les même infos que le produit. On prend par défaut les même que le produit d’origine. Possibilité de personnaliser chaque champ.
[Pierre-Jean] Je rajoute aussi « Stock »,« Prix ». Comment gère-t’on concrètement les déclinaisons ? C’est un nouvel objet ? Je pense que ça doit l’être car on voudra sans doute attacher des documents (visuels notamment) différents selon la déclinaison (de couleur par exemple). Ca me fait penser qu’on pourrait avoir une gestion proche de celle des rubriques avec les critères « parent » et « enfant », une déclinaison serait un « enfant » d’un article principal. Ce qui permettrait de faire des choses bien sympas : notamment lier les produits facilement entre-eux sur les fiches produit.


Prix
-  Prix d’achat HT ([triton] prix payé par le web commerçant, c est ca ?). [alain] c’est aussi LA RÉFÉRENCE du prix payé par le client. Avec ou sans les remises qui ne peuvent être que sur le prix HT. La tva ne venant qu’aprés.
-  Prix de vente HT
-  Règle de taxe [triton] je ne connais pas ce principe ? [Ybbet] TVA à 19,6, 5,5, 2,1 7 etc.
-  Prix de vente TTC [triton] le prix de vente est variable selon le contexte d’achat (devise, taxe, coupon...), d’ou l’idée d’un traitement par pipeline [Ybbet] Oui, ce champ là sera calculé selon les infos renseignées. Ce n’est pas « figé » mais juste à titre informatif sur la page. [alain] Sauf au niveau de la facture ou la alors plus rien ne doit changer.
-  Prix HT à l’unité par quantité (kg, 100 exemplaires, etc.)
[rainer] il y a le plugin prix qui fournit un api et qui peut servir de base

[Mist. GraphX] Thelia historiquement propose un champ PRIX_PROMO, qui est assez interessant (genre demandé a chaque fois) pour le e-commerçant, et permettant sur la partie publique de mettre cette information en avant de manière Visuelle. Est-ce à intégrer à l’API PRIX , pour qu’elle prenne en compte le champ PRIX_PROMO sur le objets (un abonement, un produit, un article, ...) ?


Transport
-  Longueur du paquet (cm)
-  Hauteur du paquet (cm)
-  Profondeur du paquet (cm)
-  Poids du paquet (kg)
-  Frais de port supplémentaires (par unité) HT
Les transporteurs dédiés ; [alain] téléchargement ; envois de liens ou de fichier ?.
[triton] certains produits, par nature, sont traités différemment quelques soit leurs caractéristiques morphologiques... par ex certains trucs peuvent être expédiés en tant « qu’imprimé » d autres « colis » ou « courrier » ou carrément pas expédiés physiquement (téléchargement, abonnement, à chercher sur place) c’est pourquoi il me semble indispensable de pouvoir ajouter un champ « type de colisage » permettant a un moment donné du pipeline « calcul_de_prix_net » de calculer le prix total du transport en fonction du contexte et du type de colisage
[Ybbet] Justement, ces caractéristiques « transport » sont des « attributs » qu’on peut personnaliser selon besoin. Prestashop permet la création de champs personnalisés pour le transport… Je n’ai pas regardé à fond ce que ça donnait, mais ça peut être intéressant cette piste. [alain] voir la logique ’abonnements’ et ’produits virtuels’ utilisés par THELIA.

[Rainer] J’ai fait un plugin basique livraison pour un client (et ces besoins). On pourrait peut-être ce baser dessus


Quantités
Gestion des quantités et des stocks du produit et de ses déclinaisons.
Une piste : https://github.com/albert777/stock-1



Gestion des marques

Pouvoir ajouter des marques

[Pierre-Jean] Les marques ne pourraient-elles pas être gérée en tant que mot clef ou caractéristique afin de ne pas avoir à gérer un énième objet ?
[Ybbet] Oui, c’est faisable. Mais en créant un nouvel objet, on pourrait mettre des mots-clés sur cet objet. Exemple : Marque : Apple Inc. Mot-clés de la marque : high-tech, divertissement, ordinateur, etc.
L’avantage aussi, on pourrait attacher à une marque des fournisseurs… Et aussi mettre un adresse à la marque. Pas possible de faire ça à un mot-clé…
Autre possibilité. On rajoute à l’objet « fournisseur » un type. « Marque », « fabricant », etc.
[triton] pour gerer un site multilingues, il me semble qu il serait plus facile d’avoir un objet spécifique plutot qu’un mot clé (les japonnais traduisent les marques), mais il me semble aussi qu il serait intéressant d avoir un système équivalent a celui du « groupe de mot clé » et « mot clé » pour gérer un concept de « gamme » qui serait plus ouvert... concrètement, cela permettrait d avoir une gamme « Marque » (équivalent à un groupe de mc) mais aussi une gamme « Types publics » (groupe mot clés) contenant « Homme, femme, enfant » une gamme couleurs... bref... un moyen de classer les produits indépendamment de leurs catégories d origines

[Mist. GraphX] : Un produit étant forcément dépendant d"une marque, pourquoi ne pas utiliser le conteneur RUBRIQUE, plutôt que de créer un objet spécifique. Sous Thelia généralement je procéde ainsi, le reste n’est que caracteristique. Genre Rubrique Apple, Samsung, les caractéristiques seraient : taille ecran, autonomie, ... les déclinaisons produit impliquant une gestion de stock voir de prix différent.


Commandes

Je vois une commande comme un objet à part entière auquel on rattache :
-  un client (objet)
-  des produits (objet)
-  une somme HT
-  une réduction (objet ?)
-  un frais de port (objet ?)
-  un tarif
-  une TVA (differente 19,6% / 5,5%.. ou pas pour l’étranger
-  une adresse de facturation
-  une adresse de livraison
-  ...
[triton] le seul truc que j ai compris avec les commandes, c est qu il fallait les figer, les geler dans l’état ou elles ont été validé... par exemple le prix d un produit a pu changer depuis le moment de l’achat, le produit lui même a pu changer, ou disparaitre des rayons... il ne faut donc pas se contenter d un pointeur sur une tables produits par exemple, mais bel et bien récupérer toutes les infos au moment de l acte et les enregistrer... [alain] OUI, car la facture sanctionnent le ’transfert’ de propriété entre le vendeur et l’acheteur. Elle est donc UNIQUE (numéro) et non modifiable. En cas de remboursement, il est obligatoire d’avoir une logique ’AVOIR’ qui reprends les bases de la facture.

L’objet commande dispose (sur la même base que les articles traditionnels de SPIP) de statuts :
-  commande en cours (paniers non terminés)
-  commande en attente de paiement
-  commande payée (et à préparer)
-  commande prête (et à expédier)
-  commande expédiée
-  commande livrée (lorsqu’on a un système de suivi type Colissimo qui puisse interagir avec le BO)
-  commande retournée [triton] mais l idéal c est de pouvoir créer ses propres statuts pour s adapter aux flux parfois bizarre du traitement des commandes

[Rainer] Il y a déjà un plugin commandes qui gère la plupart des aspects mentionnés ci-haut

les taxes je les gérerai plus tot au niveau du produit ou dans un plugin à part
[triton]niveau pipeline calcul du prix final, puisqu il faudra attendre de connaitre la devise et la destination du client pour le calculer, non ?
[rainer]oui avec en plus une declaration de tva par defaut avec la possibilite de surcharger au niveau du produit, si les site vend des produits soumis a differents taux de tva. [alain] et si le taux change au fils du temps (disparition du 5,5 pour du 7 récemment).

Cas particulier de la TVA - pays de livraison

[Soon7] Il existe plusieurs TVA ; celle ci variant en fonction du lieu de livraison.
çàd que pour un meme produit, selon qu’il soit livré en france ou au states, il aura (ou pas) une certaine TVA. qui plus est cette tva peut varier en fonction du produit (bouquin, alcool, etc)
Dans prestashop, cette problématique est gérée de la façon suivante, on a des zones qui sont constitués de pays qui peuvent avoir des états. ceci permet d’attribuer une tva à une zone donnée, et aussi par exemple un livreur à une zone donnée (genre colissimo pour la france, chronopost pour l’europe, etc).
Cette approche me semble vraiment pas mal, la question est comment la mettre en place dans spip.
est ce qu’on part sur des articles « spip de base » contenant certaines infos ou on crée un nouvel objet éditorial

[triton] pour moi, partir sur un article bricolé, c est vraiment pas bon... tellement moche comme truc, on va se retrouver a l ancienne avec le champ chapo pour mettre le prix, le ps pour la tva... alors qu il est devenu tellement évident en spip3 plus la fabrique de creer de chouettes petits objets tout bien concu.... spip est devenu bien plus qu un cms, y a vraiment une tres chouette api derrière....
[Soon7] Oui triton je te rejoins, je me suis mal exprimé, je voulais dire soit un article avec de nouveaux champs (style genre extra) ou alors nouvel objet éditorial. mais tu as quand meme répondu, mieux vaut partir sur un nouvel objet editorial


Paiement

Il me semble que le plugin Transaction est particulièrement bien avancé et pourrait peut-être même en l’état (ou avec de petits ajustement ?) s’interfacer avec ce projet de plugin de VAD.

[Rainer] voir également le plugin bank
Je ne l’ai pas encore regarde de près

Les types de paiements

[alain]Espèces, chèque, virement (penser tout de suite SEPA), CB (banque-ATOS, ou autres prestataires), prélèvements pour les abonnements.


le bon de livraison - la facture

[alain]
-  numérotation incrémentale
-  date
-  référence de la commande et presque copie du bon de commande pour les lignes.


Relation Client /Interractions

Peut-on utiliser « simplement » le plugin Notifications pour gérer les différents envois de mails, ou rêvons, de SMS lorsque le statut de commande change ?

Annexe

[Soon7]schéma de la bdd de prestashop, permettant d’avoir des idées pour certains éléments (produits, transporteurs, zones, etc)
http://doc.prestashop.com/download/attachments/1409078/prestashop-datamodel.png
http://doc.prestashop.com/display/PS15/Fondamentaux#Fondamentaux-SchémaSQL


Le who’s who du Carnet commerce

Je suis [Pierre-Jean], je veux me battre pour que ce projet voit le jour en amenant idées et best practices pour une solution e-commerce full SPIP, et réaliser des tests fonctionnels. Financer à mon échelle des bouts de dév, en mode « participatif ».