Carnet Wiki

SPIP 3 et e-commerce

Version 12 — July 2013 Teddy Payet

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

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.

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

-  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)
-  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
-  Prix de vente HT
-  Règle de taxe
-  Prix de vente TTC
-  Prix HT à l’unité par quantité (kg, 100 exemplaires, etc.)

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.

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, on pourrait. 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 mettre 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.

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

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)

[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

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

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 ?

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