Carnet Wiki

Plugin Echoppe: orientation.

Intro

C’est ici qu’on parle du projet spip-boutique. Un plugin SPIP de vente en ligne, gestion de stock et de clients. C’est ici que “s’entreposent” les idées et 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
http://zone.spip.org/trac/spip-zone/browser/_plugins_/_dev_/echoppe

Voir aussi Echoppe-boite-a-idees

Une rubrique a été ouverte pour recevoir la future documentation ... contributeurs à vos plumes

Un autre nom pour SPIP-boutique

Comme le nom “spip-boutique” est déjà utilisé ailleurs (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)(MJ +1)
-  spip-catalogue
-  spip-shop
-  spip-commerce ? (en référence à OsCommerce ?)
-  Echoppe ou E-shop crowfoot : +3000 pour Echoppe :)
-  spip-biz ? ou biz-spip ? (à articuler très vite trente fois de suite)

Conclusion: C’est donc Echoppe qui a été retenu ... et le titre de cette page changé en conséquence
.


Timeline

étape 0 et 1-a en cours

0- 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 ça 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 à toutes les fonctionnalités

3- on définit comment aborder le dév et on écrit une mini charte de
commit sur la zone, ou un fichier expliquant toutes nos discussions
permettant à qui voudrait nous aider dans le dév de le faire 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, ça permet d’écrire des trucs, et d’ouvrir un forum genre “Votre avis sur le produit”
crowfoot: il a été évoqué des “notes” des produits dans les dev futurs. Notes qui serait attribuées par les visiteurs/acheteurs. A voir si des forum propres au produit ne seraient pas mieux...

MJ-> ca fait une grosse partie déjà écrite à ne pas réécrire, donc je pense que garder l’article et son forum lié à l’article c’est plus simple.

Loiseau2nuit le 10.11.2K7 : C’est clair ! +1

JLG: l’article SPIP est un objet lié à du contenu textuel, alors que l’article “boutique” est un objet dont les propriétés incluent (entre autres) un prix, une description, une quantité, une valeur de stock, une date de dispo, etc. L’article SPIP pourrait donc être conservé pour implémenter la description du produit (avec images et tout autre fichier nécessaire). Ainsi un id_article_boutique pointerait sur une structure incluant, dans le champ “description”, la valeur de l’id_article_spip correspondant... A commenter évidemment !

— Une rubrique SPIP peut se lier à une catégorie de produits comme des villes liées à des hôtels ou restaurants par exemple....

Yoann: c’était matérialisé au niveau des articles ( produit-article ) , je l’ai rajouté pour les rubriques (produit-rubrique)

conventions:
les champs suivis de ’*’ sont des clefs

BD :Gestion des produits et catégories

table categorie soit on met des champs multi soit id_langue ??

-  id_categorie *
-  id_parent

table categorie_description
Si on utilise id_langue il faut séparer ces données (id_categorie serait la jointure) :
-  id_categorie_description *
-  id_categorie *
-  lang *
-  titre
-  resume
-  descriptif
-  logo
-  en ligne ( je le mets ici, comme ça, 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)
-  hauteur (crowfoot : serait important pour le calcul des frais de livraison ...)
-  largeur
-  longueur
-  en ligne (bool)
-  ref_produit

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
thierry: je pense qu’ici il peut y avoir un problème. En effet, cette structure permet d’avoir pour les 3 premiers champs une table qui comporterait les enregistrements 1,1,1 et 2,1,1. C’est à dire 2 descriptions dans la meme langue pour un produit. Je pense (toujours humblement) qu’il faut supprimer la clé id_descriptifs_produits pour la remplacer par une bi clé. meme remarques pour la table categorie_description.
crowfoot +1 mais on ne garderait pas un id unique pour les opérations sur les enregistrements ? Ainsi mysql devrait tester non pas 2 arguments (lang et id_produits) mais un seul (id_pdescriptifs_produits) et donc un gain substantiel en rapidité ... A vous de donner vos avis car je ne suis pas un expert en ce domaine.

Il faudrait d’ailleurs harmoniser le nom de ces deux tables genre descriptions_produits et descriptions_categories crowfoot: +1
-  id_produit *
-  lang *
-  - - - - - - - - - - - - - - - -
-  id_descriptifs_produits *
-  id_produit
-  lang

-  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-  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 à mon avis être internationalisé... non ? )
-  qte_mini
-  colisage (ça pourrait etre une donnée d’info sur la taille du colis ( ou lettre, ou palettes ... etc )

table langue ( celle de spip ? ) crowfoot : Elle servirait à quoi cette table ? à répertorier les langues utilisables et utilisée par le plug ??? Alors utilisons celle de spip. Tout est dans spip_meta...(yoann ok pour spip_meta, on supprime donc cette table)

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

yoann : finalement pour les jointures ce serait plus simple d’avoir
-  id_produit ( si =0 et id_categorie != 0 c’est donc une option sur une categorie ) crowfoot +1
-  id_categorie

que ca:
-  identifiant ( de la table catégorie de produit ou table produit )
-  type_identifiant ( valeur id_categorie ou id_produit ) ( pour pouvoir associer les options des catégories + les options des produits... )

table traduction_options (je reporte sur la table l’intervention de Thierry )
-  id_traduction_options *
-  id_option *
-  lang *
-  texte

table valeur_option (j’ai enlevé produit car on peut avoir des options sur des catégories , yoann:+1 )
-  id_valeur_options *
-  id_option
-  valeur (prix plutôt) (de l’option) crowfoot : je propose qu’ici, le gestionnaire puisse mettre une formule. Par exemple : $prix*1.1 ou $prix+1. Ainsi, pour chaque option, on peut modifier le prix. Or si on met juste un chiffre, on a moins de possibilité d’action sur le prix de base.
-  default (bool) dans le cas où l’acheteur ne choisit pas de valeur pour l’option (yoann je vois ce champ comme le choix par défaut de cette option si aucun choix n’est fait pour cet id_option crowfoot: oui en effet, si pas de sélection particulière par l’acheteur, c’est l’option true par defaut qui est prise. On est ok là dessus ? )

A mon avis il manque une table traduction_valeur_option, qui aurais le même rôle que
traduction_options.(yoann: ajoutée ci-dessous)

table traduction_valeur_option
-  id_traduction_valeur_option *
-  id_valeur_options
-  lang crowfoot: si langue ne vaut rien (ou 0), alors la valeur est accessible dans toutes les langues.( yoann: bonne idée)
-  texte ( pour une option couleur, on aura ici “rouge, vert” etc )

BD : PROBLEMATIQUE DES PRIX ET OPTIONS QUI JOUENT SUR LE PRIX

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

Là ça va pas : quand il y a plusieurs options on ne sait pas le prendre en compte...
je mettrais à la 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 a ça, 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 0, 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 ...
(yoann:+1 ton idée est pas mal, ça permettrait de définir un prix sur une configuration
par contre le commerçant s’il veut simplifier sa boutique ne devra pas trop utiliser la modification du prix sur les options
a ce niveau de toute façon on aura beaucoup de boulot c’est évident a partir du moment ou l’on prend un modéle extensible (de toute façon inévitable)

crowfoot : oué y va y avoir du taff. Surtout sur l’ergonomie de l’espace privé et des boucles/formulaires )

Des autres idées ?

Pour monnaie, j’ai un problème : le gestionnaire va pouvoir mettre n’importe quoi ? Je serais pour un système plus comme les langues : on a une liste de toutes les monnaies possibles, et le gestionnaire sélectionne celle qu’il utilise dans sa boutique. Ensuite, on convertit automatiquement...
Pour moi, la monnaie utilisée est une donnée globale de la boutique.
(yoann: ok pour moi par contre il faut un “module” de personnalisation des monnaies ( choix des monnaies utilisées et disponibles sur le site, choix du taux de conversion ( pourquoi pas donner la possibilité de se baser sur des flux xml de taux de change là ? ca doit bien exister ça? crowfoot pas con du tout. je vais demander à mon ami google.)

PierreT: il existe des fichiers de conversion,par exemple http://www.ecb.int/stats/eurofxref/eurofxref-daily.xml, reste à parser, j’ai fait un bidule qui fonctionne avec le plugin ecommerce, dispo le moment venu...
crowfoot :Je crois que ce sera le mieux : Le gestionnaire entre le prix en ## et on peut le convertir avec le lien donné ci-dessus :) les remarques de yoann sont à retenir aussi.

BD : Gestion des promotions

Ceci est un premier jet, en amélioration :)

Table promotions
-  id_promotion
-  configuration
-  formule_promotion

Table promotions_produits
-  id_promotion
-  id_produit

Table promotions_categories
-  id_promotion
-  id_categorie

Table promotions_clients
-  id_promotion
-  id_client

Table promotions_groupe_client
-  id_promotion
-  id_groupe_client

BD : Gestion des systèmes de livraisons

Yoann:
nouvelle proposition a ce niveau, longuement réfléchie
j’ai pas mis la table pays mais vu qu’elle est dans le plugin geo on ne l’aura pas dans la structure finale

je rajoute la hauteur, longueur,largeur comme caractéristiques sur le produit ( sans internationalisation )

#
# Structure de la table `type_envoi`
libelle : dans cette table on pourrait définir colissimo , courrier normal , envoi express fedex , etc

if_fournisseur_livraison : identifiant de la table fournisseur_livraison

assurance : permet de dire si oui ou non l’envoi est assuré ( pour sa valeur ) ( ceci est différent de surcout_assur et montant_assur qui eux ne font que calculer le surcout de cette assurance si ce surcout existe )

montant_assur et surcout assur sont la pour calculer un montant d’assurance (perte,vol) en fonction du montant total du panier. Comme la poste fonctionne par tranche de montant on défini cette tranche dans montant_assur et le surcout engendré par chaque dépassement de tranche dans surcout_assur

limite_volume défini si le type d’envoi est limité au niveau du volume ou pas , permet une config générale sans être obligé de définir des dimensions pour chaque montant d’envoi

délai : délais d’envoi , alors la on pourrait décomposé en 2 soit le délai est assuré par le prestataire_achemineur soit c’est un délai moyen constaté

#

CREATE TABLE type_envoi (

-  id_type_envoi bigint(20) NOT NULL auto_increment,
-  libelle varchar(255) NOT NULL default ’’,
-  id_fournisseur_livraison varchar(255) NOT NULL default ’’,
-  montant_min float(5,2) NOT NULL default ’0.00’,
-  montant_max float(5,2) NOT NULL default ’0.00’,
-  limite_volume enum(’oui’,’non’) NOT NULL default ’oui’,
-  montant_assur float(5,2) NOT NULL default ’0.00’,
-  surcout_assur float(5,2) NOT NULL default ’0.00’,
-  assurance enum(’oui’,’non’) NOT NULL default ’oui’,
-  delai int(4) NOT NULL default ’0’,
-  PRIMARY KEY (id_type_envoi)

)

# --------------------------------------------------------
#

# Structure de la table `montant_envoi`

limite_poids : donne le poids max de l’envoi

hauteur_max, largeur_max et longueur_max : définisse la taille du colis max (euh et si on peut retourner les produits on calcule ca dans les 3D ? )

id_zone : envoi sur la zone de pays ( groupement de pays )

montant : prix dans la monnaie
#

CREATE TABLE montant_envoi (

-  id_montant bigint(20) NOT NULL auto_increment,
-  limite_poids float(4,2) NOT NULL default ’0.00’,
-  hauteur_max float(4,2) NOT NULL default ’0.00’,
-  largeur_max float(4,2) NOT NULL default ’0.00’,
-  longueur_max float(4,2) NOT NULL default ’0.00’,
-  id_zone bigint(20) NOT NULL default ’0’,
-  montant float(4,2) NOT NULL default ’0.00’,
-  monnaie varchar(255) NOT NULL default ’’,
-  id_type_envoi bigint(20) NOT NULL default ’0’,
-  PRIMARY KEY (id_montant)

)
# --------------------------------------------------------

#
# Structure de la table `zones`
#

CREATE TABLE zones (

-  id_zone bigint(20) NOT NULL auto_increment,
-  description TEXT NOT NULL default ’’,
-  titre varchar(255) NOT NULL default ’’,
-  langue varchar(255) NOT NULL default ’’,
-  PRIMARY KEY (id_zone)

)

# --------------------------------------------------------

#
# Structure de la table `zones_pays`
#

CREATE TABLE zones_pays (

-  id_zone bigint(20) NOT NULL default ’0’,
-  id_pays bigint(20) NOT NULL default ’0’,
-  PRIMARY KEY (id_zone,id_pays)

)

# --------------------------------------------------------

Alors, pour cette partie, on a eu une super idée avec un ami :
Un système de ’module’ : ça 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érents 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.

Yoann : il faut aussi prendre en compte le volume !!! et j’ai bien peur que l’on arrive pas à avoir une “formule” générique ici ...mais l’idée est bonne, j’aime bien :)
crowfoot : A oui le volume !!!! c’est le mot que je cherchais à la place de masse ... Mais on peut rajouter des données qui sont utilisées par une partie seulement des fournisseurs de livraison.
Là on a vraiment besoin d’avis de personnes ayant déjà utilisé ce type de fournisseurs.

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)+($volume*0.21))</formule>

     <version_module>1.2</version_module>

</fournisseur_livraison>

Ou l’url servirait aussi de test pour ne pas avoir plusieurs modules 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 uploadé dans la partie admin et qui remplirait 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électionné par l’acheteur.
Q’en pensez-vous ?

BD : Gestion du stock

Repport du diagramme :
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
-  stock_mini (MJ) a prévoir pour gestion du stock ?_
crowfoot +1 : On pourrait s’en servir pour avertir le gestionnaire qu’il faut recommander des produits. On pourrait même proposer les deux options dans la config : Soit on avertit quand les stocks arrivent à un certain nombre minimum ou quand ils ont atteint la quantité de stock_mini.

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

BD : Gestion du panier

Il y a encore tout à faire ...

Le panier est stoqué dans la base de donnée. A chaque produits ajouter au panier, on ecrit une ligne dans la base de donnée. Datée et avec l’id produit, id auteur, le token du panier, le token du l’auteur et l’état de cet ajout : ajoute|supprimer. On pourra ainssi voir un prod ajouter puis supprimer et remplacer par un autre par exemple.

Dans une table séparée on gère le statut du panier complet via le token du panier. Les statut sont :

  • temporaire : Panier créer par un user non connu de spip.
  • reserve : Panier validé (plus modifiable) mais pas payer. Juste une option d’achat.
  • valide : Panier définitif, plus modifiable, en attente du paiement. Le visiteur est connu ou doit s’enregistrer.
  • paye : Le panier a été payer, on a soit recu le aiement par virement de la banque ou on a recu l’url de confirmation du module de paiement choisi par le user
  • traite : Le panier a été payé, les produits sont en cours de “rassemblement” avant envoi. Les produits sont supprimés du stock
  • evnoye : Le panier a été payé et envoyé, le stock à été débité. Plus rien à faire pour ce panier

Prévoir de mettre des commentaires sur les panier. De deux type : un type que seul les admins peuvent voir (commentaires en interne) et d’autre destiné aux client. Genre : “Votre panier est prêt mais notre secrétaire est malade et l’envois est retardé de 10jours.” ou “On a plus windows vista en stock, on vous a mis Ubuntu gratuit à la place.”

BD : Gestion des clients

clients
-  id_client
-  société
-  nom
-  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 ???? à quoi ça sert ? (ça 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 contacts par client). (Cyril) Ca me parait indispensable de séparer clients/contact (MJ)

groupe de clients
-  id_groupe
-  titre
-  descriptif

groupe-client
-  id_client
-  id_groupe

BD : Annexe

produit-article liaison des produits et des articles
-  id_produit *
-  id_article *

produit-rubrique liaison des produits et des rubriques
-  id_produit *
-  id_rubrique *

gestion des documents/ photos et bien celle de spip
-  > penser à internationaliser le titre / descriptif du document aussi => avec les multi ? pas vraiment
-  id_document_produit *
-  id_produit
-  lang
-  id_document
image valable pour toutes les langues (une écharpe a le même aspect en anglais qu’en chinois)) (yoann: je préconise plutot que l’on mette dans ce cas la lang=0 crowfoot +1)

sites syndiqués abandonnés , on les met en dur dans le descriptif du produit
Pour les sites syndiqués, je disais : en mettre un en dur dans le produit (comme l’url dans les articles) et ensuite en lier d’autres comme les documents ci dessus. La table ressemblerait à ça:
(Yoann : on en avait un peu parlé sur la liste et on avait dit que finalement ça ne serait pas trés intéressant d’avoir ça mais là je ne me souviens plus pourquoi )
crowfoot: pour l’adresse de descriptif du produit. comme http://www.intel.com/cd/products/services/emea/fra/desktop/processors/pentium_d/216814.htm pour le pentium D. Celle-ci, on la mettrait dans le champs spécifique au produit. Les autres liens comme http://fr.wikipedia.org/wiki/Pentium_D, on pourrait ajouter un simple site spip et le lier au produit.
sites-produits
-  id_site_produit
-  id_produit
-  id_langue
-  id_site
(- multilang (bool) (yoann: toujours pareil id_langue=0))

Les Objectifs majeurs

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

Yoann: à 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ée 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 spar 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 été prise 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à ça va ê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... à discuter.

Loiseau2nuit 10.11.2K7 : Je vois ca comme étant indispensable. Peut être plus qu’une table supplémentaire, on pourrait prévoir un champ prix supplémentaire ou un champ “redux” contenant un pourcentage qu’on activerait ou désactiverait depuis l’espace d’admin et qui serait invisible en front office le reste du temps

Gestion de clients
crowfoot: Bon ici certains proposent d’utiliser les auteurs spip. Je suis pour si on a 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 )

Sylvain: Il est important d’anticiper l’évolution légale (au moins française) à venir, qui consistera à obliger les marchands à permettre de commander (payer, être livré) sans forcément créer de compte utilisateur. C’est à dire que si le client en exprime le souhait, le marchand ne devra pas conserver durablement ces données.
Il faut à mon avis prévoir 2 modes d’emblée : achat “ponctuel” (visiteur simple) / achat “fidèle” (utilisateur loggué")

Gestion des Stocks
Comme cette partie implique beaucoup de choses, elle pourrait faire partie d’un sous plugin. Des choses à garder à l’oeil comme ça a été dit sur la liste, plusieurs fournisseurs,...
MD: Est-ce qu’une option de document à télécharger est prise en compte? En effet, il faudrait permettre la vente de produits électroniques (ebook, tutorial en pdf, images, galeries photographique, etc.). Qu’en pensez-vous?
(yoann : + 1 c’est une bonne idée , faut penser à la sécurisation de ça ( ce qui veut dire gérer un htaccess sur IMG et sur le cache aussi)

JLG: il faudrait peut-être également penser à la vente de services immatériels (un exemple bidon: le dépannage d’une télé), où le bon de commande devient un engagement contractuel plus qu’un bon d’achat, disposant ainsi d’une date contractuelle d’exécution, etc.

Loiseau2nuit 10.11.2K7 : Euh... âs compris là; Un bon de commande n’est -il pas déjà un engagement contractuel ?

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 l’a 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és aux clients.
ex : madame dupont a acheté les 3 derniers mois 200 euros de sous vetements, le moteur va automatiquement envoyer un mail avec une belle pub de sous vetements “de quoi l’inciter à acheter”.
Les statistiques pourraient aussi envoyer des bonnes affaires à certains bons 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és.
Exemple : Vous êtes sur la page des torchons rouges a carreaux bleus, en dessous en article associé un lien vers les serviettes de même couleur.

Loiseau2nuit 10.11.2K7 : +10000 (merci les mot-clés ???)

Avis des consommateurs : Ajouter une possibilité que les consommateurs puissent noter 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 ?

Loiseau2nuit 10.11.2K7 : pour moi, utiliser un article même vide en parallèle risque de faire redondant. Sinon, autant utiliser les articles dès le départ pour ranger nos produits.
Si l’on enregistre un produit comme on enregistre une brève ou un article, autant que ceux-ci aient leur propres forums. That was my 2 cents...
PierreT 15.11:Mince je pensais que les produits étaient des articles spip. Pourquoi créer un nouvel objet produit? On a déjà thelia?

Les Objectifs a long terme

Dominer le monde

Loiseau2nuit 10.11.2K7 : Il faudra que tu me passes sur le corps d’abord, rascal ! :D

Sebastien Denooz - Mise à jour :25 September 2013 at 01:46

Toutes les versions