e-commerce tout SPIP ?

Bonjour,

Un petit passage pour vous montrer mes derniers petits travaux..J'en suis pas mécontent !
Un plugin e-commerce en cours de dev et un squelette itou..
Pour le e-commerce, une simple boucle article et le tour est joué..Derrière c'est bourré d'AJAX et de javascript, un petit peu de php (il en faut)..

J'avoue en baver pour l'Ajax et éventuellement un petit coup demain ne serait pas négligeable :wink:

Mais ce petit mail juste pour vous demander votre avis, avant de poursuivre..

Merci

http://www.plugandspip.com/essai/

Bernard

Si vous pensez que ça vaut le coup, je glisse tout ça sur spipzone

bonjour,

Le 20 juin 07 à 15:30, monnaieancienne a écrit :

http://www.plugandspip.com/essai/

Bernard

Si vous pensez que ça vaut le coup, je glisse tout ça sur spipzone

hihi oui moi j'aime beaucoup :slight_smile:
Je veux bien tout ça sur la zone hein :slight_smile:

--
Philippe

Hello,

Ca serait plus logique de réaliser ca en jQuery.

Et le brancher sur le plugin spip-boutique pour la partie bdd.

BoOz

BoOz a écrit :

Hello,

Ca serait plus logique de réaliser ca en jQuery.

D'ailleurs c'est déjà codé :stuck_out_tongue:
http://interface.eyecon.ro/demos/cart.html

BoOz

BoOz a écrit :

BoOz a écrit :
  

Hello,

Ca serait plus logique de réaliser ca en jQuery.
    
D'ailleurs c'est déjà codé :stuck_out_tongue:
Shopping cart demo - Draggables, droppable, FX Highlight, Fx Drop, FX Pulsate, FX Shake, FX Transfer

BoOz

Oui pourquoi pas. Ce serait déjà un maillon de l'e-commerce spip. :wink:

Bernard

monnaieancienne a écrit :

BoOz a écrit :
  

BoOz a écrit :
  

Hello,

Ca serait plus logique de réaliser ca en jQuery.
    

D'ailleurs c'est déjà codé :stuck_out_tongue:
Shopping cart demo - Draggables, droppable, FX Highlight, Fx Drop, FX Pulsate, FX Shake, FX Transfer

BoOz

Oui pourquoi pas. Ce serait déjà un maillon de l'e-commerce spip. :wink:

Bernard
_______________________________________________
  

et une fois integre a contrib ; on pourra acheter des tee shirt spip..... :wink:

Imgur

--
-----
Break dans mon nettoyage des signes cabalistiques et hieroglyphes suite a ma fusion de base;
Merci pour votre réponse er du Coup de pouce.
@micalement stéphane.
-----
http://bachant.free.fr/ ==> Site en conformité KOAK 2.0 (strict)
-----
Hébergeur / FREE & ZMWS .
SPIP 1.9.2b [9381]
squelette Perso
Plugins==>http://bachant.free.fr/spip.php?article594

Mais ce petit mail juste pour vous demander votre avis, avant de
poursuivre..

Merci

http://www.plugandspip.com/essai/

Bernard

Si vous pensez que ça vaut le coup, je glisse tout ça sur spipzone

Ca tombe à point nommé : j'en ai rêvé et TU l'as fait :smiley: .

J'espère simplement que ce sera prêt avant que je mette les mains dans le
cambouis... de thélia (c'est très bien mais c'est trop gros pour moi et je ne
sais pas encore le fondre dans spip ^^)

mamzelle a écrit :

Mais ce petit mail juste pour vous demander votre avis, avant de poursuivre..

Merci

http://www.plugandspip.com/essai/

Bernard

Si vous pensez que ça vaut le coup, je glisse tout ça sur spipzone

Ca tombe à point nommé : j'en ai rêvé et TU l'as fait :smiley: .

J'espère simplement que ce sera prêt avant que je mette les mains dans le
cambouis... de thélia (c'est très bien mais c'est trop gros pour moi et je ne
sais pas encore le fondre dans spip ^^)

_______________________________________________

Merci mais ce n'est qu'un humble début..Si j'avance au rythme que je m'impose, dans moins d'un mois j'ai fini..
Par contre je me heurte à deux soucis majeurs et je rejoindrais sans doute spipzone pour finir de l'élaborer ..

Bernard

bonjour

j'avais commencé ça
http://thierry.schmit.free.fr/spip/
(pour poser le cookie du panier)
puis rubrique boutique

coté publique tout est fonctionnel sauf la paiement.
coté privé j'ai attaqué la gestion des commandes.

Mais ce que tu fais est bien plus beau. On semble avoir retenu le meme
principe (cf mon post spip boutique sur zone):
1 article spip = 1 article vendable (paramétrable via l'interface article de la zone privé)

comme ce n'est pas une compétition (bien au contraire) je pense qu'il est inutile de continuer chacun de notre coté.

En plus je dois avouer que j'ai une préférence pour ton interface publique meme si le fait de devoir passer par une page achat me contrarie. Je pense qu'on devrait pouvoir remplir le panier depuis la page article.

donc si tu veux mes sources, ou un accès admin à la partie privé pour voir à quoi ça ressemble, MP moi. Je te donnerais tout ça avec grand plaisir. Si je peux donner un coup de main, pareil.

bien amicalement

thierry (alias madbuilder)

Je crois que l'ideal pour ne pas se disperser serait de tous bosser sur le plugin spip-boutique qui est déjà démarré sur la zone.

BoOz

thierry a écrit :

bonjour

j'avais commencé ça
spip de madbuilder
(pour poser le cookie du panier)
puis rubrique boutique

coté publique tout est fonctionnel sauf la paiement.
coté privé j'ai attaqué la gestion des commandes.

Mais ce que tu fais est bien plus beau. On semble avoir retenu le meme
principe (cf mon post spip boutique sur zone):
1 article spip = 1 article vendable (paramétrable via l'interface article de la zone privé)

comme ce n'est pas une compétition (bien au contraire) je pense qu'il est inutile de continuer chacun de notre coté.

En plus je dois avouer que j'ai une préférence pour ton interface publique meme si le fait de devoir passer par une page achat me contrarie. Je pense qu'on devrait pouvoir remplir le panier depuis la page article.

donc si tu veux mes sources, ou un accès admin à la partie privé pour voir à quoi ça ressemble, MP moi. Je te donnerais tout ça avec grand plaisir. Si je peux donner un coup de main, pareil.

bien amicalement

thierry (alias madbuilder)

Le jeudi 21 juin 2007 16:54, BoOz a écrit :

Je crois que l'ideal pour ne pas se disperser serait de tous bosser sur
le plugin spip-boutique qui est déjà démarré sur la zone.

Je viens d'aller lire Spip-Boutique_Organisation_du_Developpement.txt et
structure.sql et je n'ai pas trouvé de notion de poids et volume des
produits, ni de calcul des frais de port. Si ce n'est pas encore prévu (mais
je suppose que si, c'est juste une précaution) je suggère d'intégrer ça,
ainsi que la notion de poids de l'emballage, lequel joue aussi sur les frais
de port. Et il faudrait aussi prévoir plusieurs types d'expédition, du
retrait sur place au colissimo, paramétrables par le propriétaire de la
boutique. Et mutualiser les tarifs, ce serait sympa. Je veux dire par là
qu'il faudrait prévoir que les différents tarifs puissent être importés d'une
base externe, laquelle servirait à toutes les boutiques, pour que les
changements de tarifs ne soient plus une corvée. Allez je continue sur ma
lancée, il faut un historique des tarifs, pas tant pour le passé mais pour le
futur : on connaît les futurs tarifs postaux à l'avance, donc on peux faire
en sorte que les nouveaux tarifs s'appliquent automatiquement à la bonne
date.

Autre chose, il n'y a pas de notion de gestion des factures dans le statut du
panier. Si on veut autoriser le paiement par chèque (ce qui est souhaitable)
ce statut est nécessaire AMHA. Et la notion de facture permettrait ensuite de
pouvoir basculer toutes les infos dans un fichier de compta, ce qui serait
également super cool.

Je peux aider à la réflexion des éléments à rajouter dans la base pour que ça
fonctionne, car si je ne sais pas coder en php j'ai un peu de connaissances
en merise et en compta, et pas mal en gestion commerciale.

Autres pistes à prendre en considération pour ne pas partir sur une base non
évolutive :

- possibilités de mailings
- gestion des stocks (et surtout comment les entrées/sorties sont-elles gérées
par le marchand) donc AMHA gestion de la douchette à code barres
- gestion des contremarques (je vend un produit que je n'ai pas en stock mais
que je sais trouver chez un autre marchand, donc le site génère
automatiquement mon achat pour équilibrer ma vente)
- possibilité de plusieurs fournisseurs pour le mm produit, et gestion des
références, prix, etc. de chaque fournisseurs.
- notions de colisage (si j'achète les crayons par paquets de 12 mais que je
les revent à l'unité il faut qu'une entrée égale 12 sorties) et là encore lié
à chaque fournisseur (il y en a qui les vendent par 20).
- gestion des vendeurs et des représentants éventuellement (notion de chiffre
d'affaire)
- notions de quantité mini ou maxi tant à la vente que pour le stock
- possibilité d'alerte si le stock atteint le mini, et réassort automatique

et je pourrais encore continuer...

Je suppose que vous allez dire que je complique pas mal mais AMHA mieux vaut
une base bien conçue au départ quitte à ce qu'une partie ne serve pas tout de
suite qu'imposer ensuite aux utilisateurs une modification de ladite base (et
aux développeurs de faire la moulinette qui va bien).

--
Cordialement, Daniel Cartron
« Les absents ont toujours tort de revenir. »
Jules Renard

et je pourrais encore continuer...

bonjour,
pas super competent la dessus, mais pour avoir fait de l integration sur MS
commerce serveur, me souviens qu il y avait un souci avec les differents
taux de tva possibles, dont la tva socia... non je deconne.... (on pouvait
en choisir qu un, alors que certains sites de vente en avaient besoin de
plusieurs)
triton

Le jeudi 21 juin 2007 17:44, PC_Triton a écrit :

pas super competent la dessus, mais pour avoir fait de l integration sur MS
commerce serveur, me souviens qu il y avait un souci avec les differents
taux de tva possibles

effectivement, c'est nécessaire aussi, surtout pour l'international. Et la
conversion des prix selon les monnaies.

Mais je me dis qu'on va décourager les codeurs à dire tout ça :slight_smile:

--
Cordialement, Daniel Cartron
« Pour être heureux avec les êtres, il ne faut leur demander que ce qu'ils
peuvent donner. »
Tristan Bernard

BoOz a écrit :

Je crois que l'ideal pour ne pas se disperser serait de tous bosser sur le plugin spip-boutique qui est déjà démarré sur la zone.

Connexion · GitLab

BoOz

je sais, j'avais meme posté ça sur zone (sans aucune réaction)

en gros je trouvais l'approche de spip boutique trop éloignée des
tables existant dans SPIP.

mais je reste ouvert et suis près à partir sur boutique.

-----------------------------------------------------------------
Est ce que spip-boutique est toujours vivant ?

Si oui, pourquoi ne pas s'etre appuyé sur la structure existante
Rubrique (=rayon) et article (=article) en étendant les champs
de la table articles par une table dont le nom reste à définir
et qui aurait comme clé primaire id_article.

Les développements seraient ainsi considérablement réduits, non ?

On pourrait ainsi associer des squelettes rubrique et article
spécifiques à un secteur qui serait la "galerie marchande" du site sous
spip.

Il suffirait d'ajouter une propriété aux rubriques selon qu'elles sont
un rayon ou non, ce qui impliquerait des champs de saisies
supplémentaires pour les articles dépendant d'une telle rubrique.

Parmi les squelettes il y aurait aussi au moins un squelette panier.
Le panier est un ensemble d'enregistrements dans un table ayant comme
clé primaire: id_client + id_article

Le panier est rempli depuis le site publique grace à du javascript de
type ajax, ou alors on traite la page article comme un formulaire (mais
ça je suis pas sur de savoir faire sous SPIP), ou un plugin du type F&T
permet de simplifier tout ça ?

Et enfin on valide le panier et on prévoit les moyens de paiement.

Reste la gestion des clients: table auteurs... ou table spécifique ?
Ici je penche pour l'utilisation de la table auteurs qui devra etre
étendue car cela évite d'avoir à re-implémenter un système
d'authentification.

est ce que l'approche semble bonne ?
ou alors il vaut mieux persévérer avec spip-boutique ?

merci
-----------------------------------------------------------------

Le jeudi 21 juin 2007 17:58, thierry a écrit :

Si oui, pourquoi ne pas s'etre appuyé sur la structure existante
Rubrique (=rayon) et article (=article) en étendant les champs
de la table articles par une table dont le nom reste à définir
et qui aurait comme clé primaire id_article.

produits ? Je suggère de prévoir un modèle pour afficher les infos des
produits de façon uniformisée

Les développements seraient ainsi considérablement réduits, non ?

On pourrait ainsi associer des squelettes rubrique et article
spécifiques à un secteur qui serait la "galerie marchande" du site sous
spip.

Il suffirait d'ajouter une propriété aux rubriques selon qu'elles sont
un rayon ou non, ce qui impliquerait des champs de saisies
supplémentaires pour les articles dépendant d'une telle rubrique.

et par mot clé ?

Parmi les squelettes il y aurait aussi au moins un squelette panier.
Le panier est un ensemble d'enregistrements dans un table ayant comme
clé primaire: id_client + id_article

pas d'accord, un panier a un id propre et il est constitué de deux tables :
- la table entete_panier qui contient id_panier, id_client, date_commande,
etc. (une ligne par panier)
- la table ligne_panier qui contient les id_panier, id_produit, quantité, etc.
(autant de lignes que de produites dans le panier)

Reste la gestion des clients: table auteurs... ou table spécifique ?
Ici je penche pour l'utilisation de la table auteurs qui devra etre
étendue car cela évite d'avoir à re-implémenter un système
d'authentification.

utiliser inscription2 ?

--
Cordialement, Daniel Cartron
« Quand on ne sait pas où l'on va, il faut y aller!!...
...et le plus vite possible. »
Devise Shadock

Daniel Cartron a écrit :

et je pourrais encore continuer...
  

vasy enfonce le couteau :stuck_out_tongue:
de mon coté je ne suis pas partisan ... du moins dans un premier temps d'intégrer toute la partie de gestion de stock ... c'est plus une fonctionnalité de logiciel de gestion commerciale ... mais bon a terme pourquoi pas gérer tout ca
a la limite juste gérer le stock de manière simple : définir un nombre d'objets en vente quand le nombre est vendu , mettre ca en avant dans l'administration et retirer le produit

chose que je n'ai pas vu dans spip-boutique
penser aussi a défnir un caractéres extensible des produits... avec un principe d'options qui lui aussi interviendrai dans le prix final
ex: une bague d'un certain type : sa taille influe sur le prix ne serait-ce que ca...

pouvoir copier des produits dans plusieurs rubriques et aussi pouvoir associer un produit a plusieurs rubriques ...

pourquoi ne pas fonctionner avec le principe des mots clefs pour organiser les produits justement ?
on fait des rubriques avec des mots clefs et dans cette rubrique on aura tous les produits qui ont au moins un de ces mots clefs
en gros dans cet esprit la

enfin moi je dis c'est un principe qui n'existe presque pas sur les boutiques (du moins sur celles que j'ai pu rencontrer) mais présent partout ailleurs ( blog , sites d'infos, etc...)

Le jeudi 21 juin 2007 18:18, Yoann NOGUES a écrit :

vasy enfonce le couteau :stuck_out_tongue:
de mon coté je ne suis pas partisan ... du moins dans un premier temps
d'intégrer toute la partie de gestion de stock ... c'est plus une
fonctionnalité de logiciel de gestion commerciale ... mais bon a terme
pourquoi pas gérer tout ca

parfaitement, c'est de la gescom mais la vente en ligne ça en est justement.
Et j'ai bien dit que je suggère simplement de prévoir la table de façon à ne
pas devoir la modifier plus tard.

a la limite juste gérer le stock de manière simple : définir un nombre
d'objets en vente quand le nombre est vendu , mettre ca en avant dans
l'administration et retirer le produit

ce qui rejoint ce que je dis, on n'est pas obligé de tout coder tout de suite

chose que je n'ai pas vu dans spip-boutique
penser aussi a défnir un caractéres extensible des produits... avec un
principe d'options qui lui aussi interviendrai dans le prix final
ex: une bague d'un certain type : sa taille influe sur le prix ne
serait-ce que ca...

ça fait partie du couteau à enfoncer : la notion de gamme. Ton exemple marche
aussi pour la taille des chaussures mais également la couleur. Donc on doit
pouvoir décliner un produit en gamme.

--
Cordialement, Daniel Cartron
« La terre étant ronde, les kilomètres devraient être ronds et non carrés. »
Ramon Gomez de la Serna

ça fait partie du couteau à enfoncer : la notion de gamme. Ton exemple marche aussi pour la taille des chaussures mais également la couleur. Donc on doit pouvoir décliner un produit en gamme.

autant la gestion commerciale ca pourrait etre le couteau qui ferais que spip serait le nouveau oscommerce :slight_smile: , autant cette fonctionnalité de gamme comme tu l'appelles, je pense que c'est quasiment rédibitoire au moins assez rapidement...

prévoir aussi que le prix d'un produit peut diminuer a l'unité quand on en achete des lots :
un chaussure ( non pas la paire ) = 10 €
2 chaussures = 20 €
3 chaussures= 25€ ... et si on implique le principe de gamme la dedans on va mourrir !!!

Daniel Cartron a écrit :

Le jeudi 21 juin 2007 16:54, BoOz a écrit :

Je crois que l'ideal pour ne pas se disperser serait de tous bosser sur
le plugin spip-boutique qui est déjà démarré sur la zone.

Je viens d'aller lire Spip-Boutique_Organisation_du_Developpement.txt

Tres bien, mais il faut en parler sur la liste spip-zone@rezo.net maintenant, c'est la bas qu'on développe les plugins.

C'est interressant ce que tu racontes mais ici, ce n'est pas le bon endroit (toujours rapport aux archives etc)

BoOz

Hello,

thierry a écrit :

est ce que l'approche semble bonne ?

Je pense qu'il vaut mieux

1) ne pas s'incruster dans les articles.
2) parler de tout ca sur la liste de SPIP-ZONE !

BoOz