Une petite modif apparait dans la gestion des status, afin que ceuc xi soit plus souple d’usage.
L’exemple concerne la gestion des commandes, et les statut, en attente, en preparation, livré et annulé.
Une petite modif apparait dans la gestion des status, afin que ceuc xi soit plus souple d’usage.
L’exemple concerne la gestion des commandes, et les statut, en attente, en preparation, livré et annulé.
la gestion des paiements, avec leur lots de différence entre les mode bancaire, et le fait de quitter la shop, pour y revenir ensuite, posent quelques question, quant à la transmission des information, et l’enregistrement des commandes.
L’osCSS 2 contient sur ce sujet 2 series de tables jummelle , les orders et les holding_orders.
Les holding order servaient a présent uniquement a recupérer les commande « perdu » ou non validés.
L’evolution qui devrait apparaitre, va changer quelques peu la procedure des enregistrement des orders.
La table orders, reste donc la table des comment dûment validé et confirmé, et les tables holding_orders, passe donc, de leur usage de commande perdues à un usage de pre-commande.
Cette transition permettra donc, de pre-enregsitré toutes les commandes, avant affichage et ainsi generé un numero unique de reference pour cette commande.
Ce numero pourra donc facielment être transmis au different module bancaire, comme Id unique, et utilisé lors des retour bancaire comme reference.
Dans le cas d’une confimation bancaire, arrivant sur la shop, avant le retour du client sur la page checkout, la page response du module prendra donc en charge la convertion des table holding_orders, vers order; et aussi la prise en charge de l’update du status en fonction de la reponse.
Dans le cas ou le client revient sur la boutique via la page process, c’est cette derbière qui prendra en charge la bascule de holding vers orders.
La page response dans ce cas ne prendra en charge que l’update du status.
Concretement, ces modification vont ce traduire par:
…
il n’y a pus qu’a.