Carnet Wiki

Plugin Spip-boutique : orientation

Version 25 — July 2007 — biniasz

Intro

C’est ici qu’on parle du projet spip-boutique. Un plugin de spip de vente en ligne, gestion de stock et de client. C’est ici que “s’entreposent” les idées et que se valident les décisions. En tout cas pour la plupart. L’espace sur la zone est celui-ci :
http://zone.spip.org/trac/spip-zone/browser/_plugins_/_dev_/spip-boutique


Un autre nom pour spip-boutique

Comme le nom “spip-boutique” a déjà l’air d’être utilisé ailleur(et en non libre) , il serait utile de changer de nom avant le début des développements. Vos propositions se font ici :

-  Marché
-  magasin
-  spip-vente (yoann +1)
-  spip-catalogue
-  spip-shop
-  
.
spip-commerce ? (en référence à OsCommerce ?)
.
.
.
_____

Timeline

étape 0 et 1-a en cours

-  faire un résumé des fonctionnalités de maniére générale puis rentrer
dans les détails pour chacune d’entre elles ( j’ai sauté cette étape
mais ca serait bon de la formaliser si quelqu’un a le temps )

1- on défini un modéle conceptuel ( uml ou merise ) par parties
a- la gestion des produits
b- La gestion des promotions / prix
c- la gestion des stocks
d- la gestion des commandes et du panier
e- La gestion des clients

2- on adapte les différentes parties du MCD a toutes les fonctionnalités

3- on défini comment aborder le dév et on écrit une mini charte de
commit sur la zone , ou un fichier expliquant toutes nos discussions
permettant a qui voudrait nous aider dans le dév le fasse le plus
simplement possible

4- on dév

Notions générales


-  internationalisation de toutes les données textuelles
-  le lien avec Form et Tables a été évoqué par Cédric , pour pouvoir paramétrer simplement les produits.
Ceci dit pour conserver l’indépendance de spip-boutique, on penche plutôt vers la structure ci-dessous.
-  La gestion des produits / catégories ne se calquera pas sur les tables des rubriques / articles de spip
-  (Es-ce que ca serait illégal ou antinaturel de prévoir un pointeur tout simple vers les “rubriques” et “articles” pour les fous qui pensent que
— Un article lié à un produit ca permet d’écrire des trucs, et d’ouvrir un forum genre “Votre avis sur le produit” crowfoot: il as été évoquer des “notes” des produits dans les dev futurs. Notes qui serait attribuées pas les visiteurs/acheteurs. Avoir si des forum propre au produits ne seraient pas mieux...
— Une rubrique spip peut se lier à une catégorie de produits comme des villes liées à des hotels ou restaus par exemple....
(MJ)
Yoann: c’était matérialisé au niveau des articles ( produit-article ) , je l’ai rajouté pour les rubriques (produit-rubrique)

La Base de données

table categorie produit soit on mets des champs multi soit id_langue ??

-  id_categorie
-  id_categorie_parent ( plutot id_parent)

table categorie produit description
Si on utilise id_langue il faut séparer ces données (id_categorie serait la jointure) :
-  id_categorie
-  id_langue
-  titre
-  resume
-  descriptif
-  logo
-  en ligne ( je le met ici comme ca on peut avoir moins de catégories dans les langues étrangères)

la table produits
-  id_produit
-  date_mise_en_ligne
-  date_retrait_mise_en_ligne
-  poids ( crowfoot : probablement pas internationalisé pour le calcul des frais de port)
-  en ligne (bool)

thierry continue humblement à penser qu’il doit manquer une table ressemblant à: ( yoann : +1, crowf00t +1 )
table categories_produits
-  id_categorie
-  id_produit

table descriptifs_produits
-  id_produit
-  id_langue (crowfoot : juste un truc comme ca : je nommerais ce champ lang, encore pour coller à la nomenclature des autres tables spip.)
-  titre
-  resume
-  chapeau
-  descriptif
-  ps
-  prix_base ( permettrait de donner un prix de base et pas faire 50000 jointures pour retrouver le prix dans une liste de produits....)
-  monnaie
-  tva ( doit a mon avis etre internationaliser... non ? )

ce qui suit est proposé par Daniel : ( je le mets dans la table spécifique a la langue car ces donnés peuvent aussi être internationalisées)
crowfoot : +1, oué, c’est plus une données pour le gestionnaire de la boutique.)
-  ref_produit ( encore que ca a internationalisé ca parait moins flagrant
-  qte_mini
-  colissage

table langue ( celle de spip ? ) crowfoot : Elle servirait à quoi cette tables ? à répertorier les langues utilisables et utilisée par le plug ??? Alors utilisont celle de spip. Tout est dans spip_meta...

table options (celle des produits: permet de gérer les différentes données pour les produits)

-  id_option
-  identifiant ( de la table categorie de produit ou table produit )
-  type_identifiant ( valeur id_categorie ou id_produit ) ( pour pouvoir associer les options des categories + les options des produits... )

table traduction_options
-  id_option
-  id_langue
-  texte

table valeur_option_produit
-  id_options_produit
-  id_langue
-  id_option
-  id_produit
-  valeur (de l’option)
-  default (bool) dans le cas ou l’achteur ne choisit pas de valeur pour l’option
A mon avis il manque une table traduction_valeur_option_produits, qui aurais le même rôle que
traduction_options.

table Prix
-  id_produit
-  id_option
-  id_valeurs_options
-  prix
-  monnaie
-  date_début_prix
-  date_fin_prix

Là ca vas pas : quand il y a plusieurs options on ne sait pas le prendre en compte...
je mettrais à le place de id_option et id_valeur_option un champs configuration, qui serait un blob dans lequel on aurait des données de type :
’id_option1’=>’id_valeur_option1’,
’id_option75’=>’id_valeur_option38’,
...
qui pourrait vouloir dire :
’couleur’=>’vert’,
’longueur’=>’10’,
...
Et quand on as ca, il est facile de le mettre dans un tableau php pour tester si la configuration demandée existe ou pas. Si oui on prend ce prix là, si non, on affecte le prix de base en rapport avec la valeur des différentes options (la valeur de couleur pourrait être , tandis que celle de longueur pourrais être de 5. on ferais alors prix_base + 5)
Mais bon, je me rend compte que tout ca devient assez lourd ...

Des autres idées ?

Pour monnaie, j’ai un problème : le gestionnaire vas pouvoir mettre n’importe quoi ? Je serais pour un système plus comme les langues : On a une liste de toutes les monnaies possible, et le gestionnaire sélectionne celle qu’il utilise dans sa boutique. Ensuite, on converti automatiquement...
Pour moi, la monnaie utilisée est une donnée globale de la boutique.

zone de livraison
-  id_zone
-  libellé_zone

prix frais livraison zone ( je ne suis pas bien sur que ce soit pérenne )
-  id_zone
-  id_produit
-  montant
-  monnaie

Alors, pour cette partie, on a eu une super idée avec un ami :
Un système de ’module’ : Ca ne serait plus une idée de montant mais de formule. Comme les frais de livraisons dépendent d’un fournisseur de livraison (ups, fed-ex, la poste, ...) les calculs des frais seront donc différent pour chaque fournisseur de livraison.
Le truc serait de faire une formule de calcul des frais pour chaque fourn. de livr. qui prendrait en compte le poids, la masse et la quantité de produit voulue. Ainsi, on peut imaginer un petit fichier xml comme suit :

<fournisseur_livraison>


<nom>UPS</nom>


<url>http://www.ups.com</url>


<logo>http://www.ups.com/img/global_logo.gif</logo>


<formule>($prix_base*$quantite)*(($poids/100)+($masse*0.21))</formule>


<version_module>1.2</version_module>


</fournisseur_livraison>

Ou l’url servirait aussi de test pour ne pas avoir plusieurs module pour le même fournisseur, ou en tout cas avertir le gestionnaire. Au cas ou UPS fait des changement dans sa manière de calculer, on crée le module 1.3 avec une formule mise à jour :)

Fichier xml qui pourrait être uploader dans la partie admin et qui remplirais une table

fournisseur_livraison
-  id_fournisseur_livraison
-  nom
-  url
-  logo
-  formule
-  version
-  statut (si le module est sélectionable ou pas par l’acheteur)

et ainsi le prix serait modifié par la formule du module de livraison sélectionner par l’acheteur.
Q’en penssez-vous ?

produit-article liaision des produits et des articles
-  id_produit
-  id_article

produit-rubrique liaision des produits et des rubrique
-  id_produit
-  id_rubrique

gestion des documents/ photos et bien celle de spip
-  > penser a internationaliser le titre / descriptif du document aussi => avec les multi ? pas vraiment
-  id_document_produit
-  id_produit
-  id_langue
-  id_document
-  multilang (bool) image valable pour toutes les langues (un écharpe à le même aspect en anglais qu’en chinois)

sites syndiqués abandonnés , on les mets en dur dans le descriptif du produit
Pour les sites syndiqués, je disait : en mettre un en dur dans le produit (comme l’url dans les articles) et ensuite en lier d’autre comme les documents ci dessus. La table ressemblerait à ca:

sites-produits
-  id_site_produit
-  id_produit
-  id_langue
-  id_site
-  multilang (bool)

Quid des options des produits qui joue sur le prix du produit...
comment mettre ca en place dans cette structure ?
le soucis vient quand on a plusieurs options ...
si vous avez des idées ...
=> on prend le prix le plus élevé de l’option choisie ? (j’ai mis une proposition plus haut.)

Tables a discuter report du diagramme dia

http://zone.spip.org/trac/spip-zone/browser/_plugins_/_dev_/spip-boutique/Boutique.png?format=raw

stock-produit
-  id_stock
-  id_produit
-  id_depot
-  qte

depots on gére l’internationalisation ?
-  id_depot
-  titre
-  adresse
-  tel
-  fax
-  mail
-  url depot

clients
-  id_client
-  nom
-  prenom
-  num rue
-  rue
-  adresse bis (etage , appt , batiment ?
clients )

-   id_client cp
-  société localite
-  nom pays
-  prenom
-  
rue1_facturation
-  
rue2_facturation
-  
cp_facturation
-  
localite_facturation
-  
pays_facturation
-  
rue1_livraison
-  
rue2_livraison
-  
cp_livraison
-  
ville_livraison
-  
pays_livraison
-  
tel
-  fax
-  gsm
-  numéro TVA ???? a quoi ca sert ? (ca sert quand tes clients font de la revente pour générer leur facture je pense, et quand ils sont éxonérés de TVA => la facture doit porter ce numéro)

Suggestion : on pourrait séparer clients et contacts, client en terme d’entité facturable, et contact en terme de personne physique (il peut y avoir plusieurs contact par client). (Cyril)

groupe de clients
-  id_groupe
-  titre
-  descriptif

groupe-client
-  id_client
-  id_groupe

Les Objectifs majeurs

Gestion de produits
Crowfoot : Une des choses qu’il faut mettee en place au niveau sql au début du projet, c’est des produits complet. Ne pas lésiner sur ce qu’on vas mettre dans cet “objet spip”. Et il faut le faire en relation avec le panier.

Yoann: a ce niveau j’ai proposé la gestion d’options modélisée dans la base ci-dessus
_

Pierre : Avoir un historique des prix. “D’autres part s’agissant d’une données sensible ne faut il
pas garder une traçabilité des modifications (savoir qui et quand le
prix a été modifié ?
Il faudrait peut-être envisager une table supplémentaire”
_

Gestion de catégories de produits
crowfoot: Pour cette partie je vois un truc simple. J’ai envie de dire “comme les rubriques”. Tout en réfléchissant bien pour prévoir des ajout par la suite. Mais ama qu’un titre, texte, logo devrait suffire en tant que contenu visible par les clients finaux.

Yoann: la notion du “enligne / hors ligne” n’a pas du tout était pris en compte tant au niveau des rubriques qu’au niveau des produits ( c’est rajouté dans la base ci-dessus)
_

Gestion de ristourne/promotion
crowfoot: Là ca vas être chaud à coder. Je pense qu’on dois partir sur un truc simple mais trés évolutif. Je remet ici un résumé de ce qu’on doit pouvoir coder au final :

Et pourquoi pas un sous plugin pour cette partie? Histoire d’alléger si pas besoin... mais bon, c’est quand même un point important d’une boutique... a discuter.

Gestion de clients
crowfoot: Bon ici certain proposent d’utiliser les auteur spip. Je suis pour si on as un truc qui fonctionne bien. je vais aller voir ce fameux plugin inscription2. Si c’est facilement intégrable à why not ;)
_

Gestion de commandes

-  gestion d’un panier
-  gestion des factures : qui ne doivent pas changer avec le temps ( je pense a la liaison avec le produit , son prix , ...Etc )

Gestion des Stocks
Comme cette partie implique beaucoup de choses, elle pourrait faire partie d’un sous plugin. Des choses à garder à l’oeuil comme ca a été dis sur la liste, plusieurs fournisseur,...
_

Gestion des modes de paiement
Cette partie peut être gérée par des formulaires différents dans un premier temps. Ceux-ci contiendraient les données à envoyer à l’outil de paiement.
_

Yoann: “une chose que l’on pourrait avoir pour les systémes de paiement comme
quelqu’un la dit dans cette discussion ce sont des formulaires ( simple
fichiers html ) configurés via l’interface d’admin ... ca serait une
bonne chose”

_

Les Objectifs secondaires

iMaTh :

Statistique commerçante : Le plus à ajouter sur ce plugin qui ferait de spip un CMS de Ecommerce professionnel serait d’ajouter une fonctionnalité faisant des statistiques des ventes, et en fonctions des statistiques des Emails sont envoyé au clients.
ex : madame dupont a acheté les 3 derniers mois 200 euros de sous vetements, le moteur va automatiquement envoyé un mail avec une belle pub de sous vetements “de quoi l’insité a acheté”.
Les statistiques pourrait aussi envoyé des bonnes affaires a certains bon clients aussi.

Yoann: on pourrait prévoir avec ceux qui connaissent bien spip-listes ou autre la gestion de ces envois :)

Articles associé : Il serait interessant que lorsque vous êtes sur la page d’un produit, vous pouvez y trouvé les articles associé.
Exemple : Vous êtes sur la page des torchons rouge a carreaux bleu, en dessous en article associé un lien vers les serviettes de même couleurs.

Avis des consommateurs : Ajouter une possibilité que les consommateurs puissent noté les articles. (MJ) d’où l’intérêt de prévoir un pointeur vers un “article spip” même vide, et se servir des forums ?

Les Objectifs a long terme

Retour à la version courante

Toutes les versions