Carnet Wiki

SPIP 3 et e-commerce

Version 19 — July 2013 — Nicolas Hoizey

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...)

[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é.

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

Fonctions des plugins

Gestion des produits

-  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] ca 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 ca dans le wiki ?)

[rainer] cela dépend, parfois il est util de reprendre une structure déjà donnée, on pourrait le laisser au choix

-  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 ca 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 deja eperimente des solutions qui avec une déclaration des champs dans un tableau (extensible via pipeleine) et le plugin saisies (et parfois également avec cextras) crée un formulaire config qui permet de choisir et rendre obligatoire de champs.

-  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)
[triton] a quoi ca va servir concrètement de typer les produits de cette manière (vraie question)?
-  Référence produit ;
-  EAN13 ou JAN
-  UPC
-  Quantité minimale

Déclinaisons
-  Attribut (ce en quoi il diffère)
-  Valeur de l’attribut
-  Caractéristique
-  Référence produit ;
-  EAN13 ou JAN
-  UPC
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.

Prix
-  Prix d’achat HT ([triton] prix payé par le web commerçant, c est ca ?)
-  Prix de vente HT
-  Règle de taxe [triton] je ne connais pas ce principe ? [Ybbet] TVA à 19,6, 5,5, 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.
-  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

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.
[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.

[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.

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

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...

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 ite vend des produits soumis a differents taux de tva.

[Soon7]

Cas particulier de la TVA - pays de livraison

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....

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

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


-  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 ?