Druidefou Posté 22 Août 2006 Posté 22 Août 2006 Bonjour, Je réfléchis au système d'un panier d'achat, mais étant limité aux niveaux des connaissances, j'ai probablement râté un épisode. Lorsqu'une personne visite une boutique en ligne, elle va choisir un ou plusieurs articles. Ces articles vont s'ajouter dans son panier, ce que je ne comprend pas bien, c'est où stocker ces articles, en session, dans un cookie (si les cookie ne sont pas acceptés ?), dans une base de données (combien d'occurence ca va prendre ?) ? Bref je ne saisis pas bien le système. Je m'étais dis que stocker ca en session était probablement la solution la plus employés, mais ne connaissant pas le nombre d'articles choisit à l'avance, je ne vois pas tropcomment faire pour stocker à la fois les articles et leurs quantités dans des variables de sessions. Les cookies j'ai vite abandonné, au cas où des personnes les bloquent. La base de données me semblait donc la meilleure solution, mais je ne vois pas trop comment la construire, un champ id, timestamp (date de la commande), id_article, quantite, id_client (pour savoir à qui appartient cette commande). Auquel cas à chaque fois qu'une personne commande un article ca fera une ligne, et au moment de la commande il faut récupérer tous les id_client pour ensuite lui faire sa facture ? Cela veut dire qu'il faut d'abord demander à la personne de s'authentifier avant qu'elle puisse commander. Je pense qu'il y un moyen mais je ne parviens pas à le trouver, je vous serais reconnaissant de me guider. Merci.
KaRaK Posté 22 Août 2006 Posté 22 Août 2006 Ton id_client peut tres bien être un id de session tant que le client ne s'est pas identifié (ou n'a pas créé de compte). De cette manière tu identifies bien chaque client et chacun de ses produits.
Druidefou Posté 22 Août 2006 Auteur Posté 22 Août 2006 Mais est-ce une solution valable de procéder comme ca ? Comment font la plupart des boutiques ? Donc il s'agirait que je récupère l'id de session et que je le stock, je vais me renseigner là dessus.
Druidefou Posté 22 Août 2006 Auteur Posté 22 Août 2006 Merci pour ce lien. Merci à vous deux pour vos réponses, je vais encore réfléchir à tout ca, pour savoir un peu comment font les autres.
manmachine Posté 23 Août 2006 Posté 23 Août 2006 Il plusieurs méthode mais la plus répandues reste celle ci 1 - ton client n'est pas loggé : - tu stock les informations de son panier dans la session 2- ton client est loggué - Si il a rempli son panier en etant pas loggué tu enregistre les informations de son panier en base de données, ce qui permet de le sauvergardé pour sa prochaine visite. - Tu recré le panier à partir des informations de la bdd Pour la table panier c'est pluto simple : id du client | id du propduit | date d'ajout | etc ...
robinsonvendredi Posté 23 Août 2006 Posté 23 Août 2006 Auquel cas à chaque fois qu'une personne commande un article ca fera une ligne, et au moment de la commande il faut récupérer tous les id_client pour ensuite lui faire sa facture ? Cela veut dire qu'il faut d'abord demander à la personne de s'authentifier avant qu'elle puisse commander. On dirait que c'est l'enchaînement panier-commande-facturation qui te pose problème. La façon la plus simple de le faire est de gérer les paniers en variable de session. Les stocker dans la base de données n'est utile que pour un panier dit "persistant", le client a la possibilité de ré-ouvrir son panier en revenant sur ton site après l'avoir quitté. La variable session qui maintient le panier est un array qui n'est vidé que lorsque la commande est validée par le client. Entretemps il peut ajouter ou enlever des lignes. Le processus de passation de commande /enregistrement client dépend de ton business, il existe plusieurs scénarios. Dans le cas d'une boutique B2C classique, tout le monde peut compléter un panier avec le même tarif, l'identification préalable du client n'est donc pas nécessaire. Elle peut intervenir juste avant de valider la commande (écran : "J'ai déjà un compte de client / je n'ai pas encore de compte de client"). La facturation c'est une autre histoire...Ton client a passé une commande, mais un certain nombre d'étapes te séparent de la facturation. Notamment le bon de livraison qui retire physiquement des stocks les articles commandés.
Druidefou Posté 25 Août 2006 Auteur Posté 25 Août 2006 Bonjour, Merci pour ces détails. J'ai donc fais avec des sessions, et ca marche plutôt bien, quelques petits soucis à régler, mais c'est en bonne marche. Ma méthode était de laisser la personne faire ses achats, et de lui demander ses informations au moment où elle souhaite payer. Je lui propose de créer un compte client, afin de ne pas avoir à retaper ce genre d'informations plus tard (pour pouvoir sauvegarder son panier aussi, mais pour le moment c'est pas trop ma tasse de thé). Il me reste donc maintenant, à sauvegarder ce que j'ai en session dans une base de données, pour que ce soit en dur. J'ai donc une table commande, avec l'id de la commande, l'id du client, l'id du produit, la quantité, et la date. Je n'aurais plus qu'à tirer toutes les lignes du même id client et qui correspondent à une date précise (même jour, si un client passe 2 commandes le même jour ca peut poser problème). Néanmoins j'ai un soucis de taille. J'utilise les sessions en faisant donc mon session_start(). Ce qui a pour effet de mettre un sid derrière l'url. Ce qui apparement n'est pas très bon pour les moteurs de recherches, car ils indexent plusieurs fois la même url. D'où ma question, comment faire pour que cet id disparaisse ? Parce qu'une personne n'étant pas loggué pouvant faire ses achats, cela inclus forcement un robot, qui ne sera pas non plus loggué. J'ai aussi un autre soucis, mais là ca sors un peu du sujet, c'est pour faire de l'url rewriting, juste savoir si quelqu'un a une page qui expliquerait comment modifier les liens d'un script php (et non pas créer le htaccess). En tout cas merci de votre aide.
robinsonvendredi Posté 25 Août 2006 Posté 25 Août 2006 Il me reste donc maintenant, à sauvegarder ce que j'ai en session dans une base de données, pour que ce soit en dur. J'ai donc une table commande, avec l'id de la commande, l'id du client, l'id du produit, la quantité, et la date. Je n'aurais plus qu'à tirer toutes les lignes du même id client et qui correspondent à une date précise (même jour, si un client passe 2 commandes le même jour ca peut poser problème). Ce n'est pas exactement comme cela qu'il faut faire. 1. Je te conseille de dénormaliser la table commande, donc ce n'est pas des ID mais le nom du client, la référence du produit, son nom, etc... En effet une commande "vit sa vie" indépendamment du reste de la base de données, une fois qu'elle a été passée. Les infos sont figées une fois pour toutes. Inpensable par exemple de ne pas pouvoir supprimer un produit ou un client de ta base à cause de l'intégrité référentielle avec une commande passée il y a deux mois. Au niveau de la structure de la bdd, il est plus logique d'avoir une table "en-têtes de commandes" et une table dépendante "lignes de commandes" plutôt que tout dans la même table. 2. Il faut un système de tracking des commandes. L'iD de la commande distingue parfaitement deux commandes enregistrées le même jour par le même client. En revanche, en e-commerce, se pose le problème des commandes imprimées avec ou sans validation par le client. Par exemple un client imprime la commande sans la valider (donc elle n'est pas enregistrée) et il envoie un chèque en règlement. C'est pourquoi je te conseille, en plus du tracking par l'ID, d'avoir un identificateur jour/minute/seconde/nombre aléatoire qui s'affiche sur la page commande et te permet de savoir si elle a été enregistrée en double ou pas.
Druidefou Posté 25 Août 2006 Auteur Posté 25 Août 2006 Au niveau de la structure de la bdd, il est plus logique d'avoir une table "en-têtes de commandes" et une table dépendante "lignes de commandes" plutôt que tout dans la même table. Je comprend pas bien ce passage. Ce que j'en ai compris c'est qu'au lieu de mettre des id dans ma table commande, je dois mettre les véritables noms pour ne pas resté dépendant de la table article. Mais je ne saisis pas "en-têtes de commandes" et "lignes de commandes". Je pensais mettre les ID pour un gain de place dans la bdd, mais bon pourquoi pas. Pour le tracking je pense pas pousser le truc jusque là (pour le moment, sait-on jamais), pour la simple raison que le site n'aura pas autant de commande qu'un site comme surcouf par exemple, les commandes par jours ne seront pas énormes, donc je pense qu'on s'y retrouvera au jour le jour. De toute manière, une personne envoie sa commande imprimée ou la confirme en ligne, et ce n'est que ca qui sera rentré dans la bdd, donc pour le tracking à priori aucun soucis puisqu'on aura uniquement les articles voulut dans la bdd, pas de parasites ou erreurs (sauf cas exceptionnel que je ne gère pas pour le moment puisqu'on saura différencier le vrai du faux à la main). En tout cas merci de ces précisions, donc pour résumer ma table commande ressemblera à : id_commande | ref_produit | nom_produit | quantite | date (voir une clé histoire d'être sûr que c'est bien de cet commande qu'il s'agit). Décidement à chaque fois que je suis allé sur ce forum, j'ai trouvé mon bonheure, vraiment merci !
objectifweb Posté 27 Août 2006 Posté 27 Août 2006 Bonjour Druidefou, Je dis peut-être une bêtise, peut-être tu prends plaisir à programmer ta propre boutique ou bien elle est tellement spécifique qu'aucun script ne répond à tes besoins, mais as tu songé à utiliser des scripts qui fonctionnent déjà avec toutes les options comme OSCommerce ? http://oscommerce.com/ Amicalement Patrick
Anonymus Posté 27 Août 2006 Posté 27 Août 2006 Je comprend pas bien ce passage. Ce que j'en ai compris c'est qu'au lieu de mettre des id dans ma table commande, je dois mettre les véritables noms pour ne pas resté dépendant de la table article. Mais je ne saisis pas "en-têtes de commandes" et "lignes de commandes". Je pensais mettre les ID pour un gain de place dans la bdd, mais bon pourquoi pas. Pour le tracking je pense pas pousser le truc jusque là (pour le moment, sait-on jamais), pour la simple raison que le site n'aura pas autant de commande qu'un site comme surcouf par exemple, les commandes par jours ne seront pas énormes, donc je pense qu'on s'y retrouvera au jour le jour. De toute manière, une personne envoie sa commande imprimée ou la confirme en ligne, et ce n'est que ca qui sera rentré dans la bdd, donc pour le tracking à priori aucun soucis puisqu'on aura uniquement les articles voulut dans la bdd, pas de parasites ou erreurs (sauf cas exceptionnel que je ne gère pas pour le moment puisqu'on saura différencier le vrai du faux à la main). En tout cas merci de ces précisions, donc pour résumer ma table commande ressemblera à : id_commande | ref_produit | nom_produit | quantite | date (voir une clé histoire d'être sûr que c'est bien de cet commande qu'il s'agit). Décidement à chaque fois que je suis allé sur ce forum, j'ai trouvé mon bonheure, vraiment merci ! L'idée est celle-ci : Si tu fais référence à l'objet, pour la commande, ca va donner des effets de bord. Exemple : Un produit 'cassoulet en boite 250g' (ID=15) est acheté le 1er janvier. Le 30 janvier, ton client veut changer ce produit, qui ne correspond plus à la demande. Il le modifie en 'cassoulet en boite 500g', (ID=15). Pour lui, il n'y a pas de conséquences. Pour ta base de données, le client qui a acheté le 1er janvier du cassoulet 250g. va se retrouvé avec une commande IDproduit=15, soit 'boite de cassoulet 500g'. Ce que veut dire robinsonvendredi, c'est que tu doit pouvoir modifier/supprimer un produit, tout en gardant, dans les commandes, les 'produits' qui ont été acheté auparavant. Les 2 (la table produits et la table commande) doivent être séparées. L'une (le produit) doit pouvoir être changé n'importe quand (le produit bouge, change), l'autre la commande doit être figée dans le temps. Elle est passée, elle a été passée, elle est.. figée. Pour cela, donc, il te faut créer 2 tables, non liées avec des ID quelconques. Pour info, il te faut faire de même pour les clients (avec l'idée qu'un client peut changer d'adresse, il te faudra garder l'ancienne adresse) Anonymus.
Druidefou Posté 27 Août 2006 Auteur Posté 27 Août 2006 Ok je vois plus claire dans l'explications. Oui en faite c'est logique, je n'avais pas suffisament réfléchit à ce problème. Sinon pour répondre à objectifweb, je ne prend pas de script tout fait pour plusieurs raisons. D'abord parce qu'il faudrait adapter ce script à notre charte graphique, modifier certaines choses dans le fonctionnement, supprimer certains modules, ... bref pas mal de boulot qui ne seront pas forcement du bon temps étant donné que ce n'st pas mon code. Ensuite pour le challenge, finalement j'en apprend beaucoup en le faisant moi même. Et puis ce script étant grand public, je suppose qu'il a des failles et qu'elles sont donc rapidement connut, pour un site de commerce je pense que c'est plutôt moyen, même si le miens doit comporter des failles aussi, le code n'étant pas connut à l'avance pas sûr que ca se trouve rapidement. Néanmoins j'y avais réfléchis et c'est vrai que ca aurait une solution de facilité, tant pis.
robinsonvendredi Posté 27 Août 2006 Posté 27 Août 2006 Les 2 (la table produits et la table commande) doivent être séparées. L'une (le produit) doit pouvoir être changé n'importe quand (le produit bouge, change), l'autre la commande doit être figée dans le temps. Elle est passée, elle a été passée, elle est.. figée. C'est exactement cela. Il ne faut pas oublier qu'une commande est contractuelle : elle t'engage et elle engage ton client. D'ailleurs, si tu as le temps de le développer, garde une trace des principales étapes de la transaction : devis / commande / BL / facture. Pour cela j'ai choisi d'enregistrer des fichiers XML sur ma base, qui correspondent à chaque étape.(d'autres méthodes que XML sont possibles, mais pour moi c'était le meilleur choix). Comme ça à tout moment, je peux sortir les pdf correspondant à ces fichiers XML, ils sont figés et j'ai une bonne traçabilité de toutes les opérations du devis jusqu'à la comptabilisation. En cas de litige, ce type de système peut te sauver.
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant