Frais de ports selon qtt et adresse de livraison ?

Bonjour,

Ce produit semble superbe, et j'ai cru qu'il pourrait satisfaire mon besoin, mais je n'arrive pas à trouver comment faire !

Je gère des commandes groupées de bouteilles, et les frais de ports sont donnés sous forme d'un cout à la bouteille (que l'on peut convertir effectivement en poids) qui change en fonction de l'adresse de livraison.

Il m'a sembler lire ça dans les spécifs, mais je ne trouve pas une fois le composant en place.

Qu'en est il ?

Merci d'avance
Jacques

Bonjour,

Quand vous allez dans Système->méthodes de livraison il vous faut aller dans manual shipping methods plugin. Là, vous pouvez créer vos méthodes de livraison avec des limites de poids et de zone. Ensuite, en fonction du poids des produits du panier et de l'adresse de livraison du client, les méthodes de livraisons seront filtrées pour n'afficher que celles possible pour la commande de l'utilisateur.

ok

En fait mon besoin serait d'afficher un prix à la bouteille fonction de l'adresse de livraison...

Il n'est pas possible d'avoir un prix de livraison dynamique sans modifier le plugin des méthodes de livraison. Si vous savez coder en php vous pouvez éditer le fichier plugins/hikashopshipping/manual.php dans la fonction onShippingDisplay qui retourne dans $usable_rates la liste des méthodes de livraison possible avec leur prix, et vous pourrez ainsi faire ce que vous voulez.

OK, c'est envisageable...

J'essaie de configurer un échantillon pour bien me rendre compte, mais ça ne fonctionne pas du tout !

Impossible de sélectionner les éléments dans les fenêtres qui s'ouvrent, je peux cocher et cliquer sur valider, mais ça ne fonctionne pas !

-> Mettre un produit dans une catégorie
-> Choisir justement une zone pour les modes de livraison
etc...

???

Est ce que vous avez le même problème sur notre site de démo ?

Si oui, cela doit venir d'une incompatibilité avec votre explorateur. Lequel utilisez-vous ?

Si non, peut être une incompatibilité avec l'une des autres extensions installée sur votre site web.

sur le site démo, liste des produits, clic sur une catégorie (toys) :

jtablesession::store failed
DB function failed with error number 1146
Table 'demo.jos_session' doesn't exist SQL=INSERT INTO `jos_session` ( `session_id`,`time`,`username`,`gid`,`guest`,`client_id` ) VALUES ( 'adc9e88f5bb94cf4af78bc3f340c0f3f','1288774812','','0','1','1' )
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 24 bytes) in /home/demo/www/libraries/joomla/error/exception.php on line 117

j'utilise FireFox dernière version sur Mac.

Par contre, une fois décoincé et e sélectionnant uen autre catégorie j'ai pu faire l'association.

Je n'ai pas grand chose comme composants, je vais essayer d'en supprimer...

Le site de démo est remis à zéro toutes les heures. Lors de la remise à zéro, il se pourrait que ce genre d'erreur se produise. C'est surement ce qui c'est produit ici.

Donc, ça marche sur le site de démo. Ce qui veut dire que le problème vient d'un problème de compatibilité sur votre site. Après avoir essayé d'ajouter une catégorie sur votre site web, si vous allez dans la console d'erreur javascript de Firefox, est-ce que vous voyez des erreurs ?
www.siteduzero.com/tutoriel-3-332493-deb...-code.html#ss_part_2

Effectivement, ça viens d'un pb de domaine car j'utilise un reroutage de domaine avce vin.fadeuilhe.com qui renvoie sur www.fadeuilhe.com/vins et cela génère un erreur d'autorisation !

lorsque je passe en direct sur www.fadeuilhe.com/vins ça fonctionne.

Donc je continue mes tests, en espérant qu'en frontend je n'aurais pas ce type de pb...

Les popup mootools étant faites avec des iframes, le contenu de l'iframe n'aura pas le droit d'accéder au reste de la page pour ajouter l'élément dans le listing correpsondant si le nom de domaine est différent. C'est une sécurité dans tous les navigateur web.
Il serait peut être possible de corriger le problème en rajoutant dans le fichier de configuration de joomla la ligne var $live_site = " www.fadeuilhe.com/vins ";
De ce fait, joomla renverrait directement la bonne URL quand HikaShop demande l'URL courrante.
webcache.googleusercontent.com/search?q=...igital.com/FAQs/sh40

Also , something I didn't think of last time.

If you want to have a variable rate based on the price of the order, you can use the tax category option of the shipping method. This way you can create special tax rules for a special "shipping" category of taxes and on top of the flat shipping price, the system will add a variable rate which will be the tax rate matching the tax rules set for this special tax category. So it's even possible to do that without changing the code if you can base shipping prices variation on the order total price.

Salut Nicolas,

je reviens un peu dans la bataille... et je profite de ce poste pour soumettre mon besoin qui se raproche de celui de jfa :

Pourquoi de pas pouvoir faire évoluer le prix de la livraison automatiquement en fonction du poids...? Les articles ont un poids et au moment de la création d'un mode de livraison, il demande un poids maximum... Pourquoi ne pas prévoir un barème ? cela ne doit pas être bien compliqué.... (en fait j'en sais rien, je suis une bille en programmation :blush: )

Mais ce serait génial pour une boutique en ligne de proposer par exemple une livraison Collissimo qui va automatiquement changer en fonction du poids : 25€ entre 0 et 5Kg - 35€ entre 5 et 50kg...

C'est déjà faisable dans HikaShop.
Il suffit pour cela de créer plusieurs méthodes de livraison:
une pour un poid entre 0 et 5 avec un prix de 25 euros
une pour un poid entre 5 et 50 avec un autre prix

Lors de la commande le poids total est calculé automatiquement par HikaShop et seules les méthodes de livraisons dont les limites de poid sont respectés par la commande seront affichées.

C'est exactement ce qu'a fait un autre utilisateur qui a posté une capture d'écran de ses méthodes de livraisons:
essentialsoffirefighting.com/shipping2.jpg

autant pour moi.... j'ai honte j'étais toujours en version 1.1.1..... Ha la la !!! Voila la mise à jour est passée !

Je vais me donner 10 coups de fouets de ce pas !!!! :evil:

Bonjour Nicolas,

Je reviens sur ce poste car j'ai une demande d'un client qui peut intéresser plus d'une personne : les achats groupés !

en effet, la problématique est relativement simple :
- on a un site qui autorise des remises très grandes (-40%) lors d'un achat d'au minimum 1500 € avec 1 seul bon de commande et 1 seul lieu de livraison
- il faudrait donner la possibilité de grouper des commandes sur un seul bon de commande et que chacun puisse payer sa part !

Mon idée, pour simplifier :
- on créer un compte client (celui qui gère la vente groupée)
- on donne accès à ce compte à chaque personne souhaitant se joindre à la vente, et chacun paye sa part
- une fois que l'on décide, le bon de commande est clôturé et validé

Je sais, cela semble un peu tiré par les cheveux, c'est pour cela que je demande l'aide du grand spécialiste Nicolas (ou tout autre personne ayant réfléchit ou réaliser ce genre de chose...

Merci de votre aide !

Fafamaster

Bonjour,

Je vois bien ce que vous voulez faire. Ce qu'il faut, c'est garder le fait qu'une commande est pour un client (pour que vous de votre coté vous sachiez qui veut quoi et en quelle quantité). Le passage en caisse se passerait normalement, avec la remise appliquée déjà au prix du produit. Au lieu de valider les paiements, il faudrait modifier légèrement le plugin de paiement pour qu'ils ne soient qu'autorisés (il y a une option à passer à la plateforme de paiement en général pour cela). Une fois que vous avez votre quota, ou que le temps est écoulé, soit vous avez assez de commandes et vous validez les paiement dans l'interface de configuration de la plateforme de paiement, soit vous les annulez.

Il faudrait créer un compteur pour savoir le nombre de personnes ayant déjà eu leur paiement autorisé par rapport au nombre requis si vous souhaitez faire comme groupon.

A la base, HikaShop n'est pas vraiment fait pour cela, mais avez quelques modifications et une configuration bien faite, il devrait être possible d'arriver à un résultat équivalent.

Merci Nicolas pour la réponse pleine de bon sens !

Cependant, contrairement à groupons, dans notre cas il s'agit d'achat groupé c'est à dire, que pour la boutique je regroupe ttes les commandes en 1 seule (pour faire comme si il n'y avait qu'une seule commande à livrer en 1 seul endroit)
Auriez vous une idée ?

pour le paiement j'ai bien compris l'idée

De plus, il faudrait que la validation de la commande soit donné au client (c'est à dire que le client qui regroupe les commandes de ses amis, peut valider la commande quand il le désire du moment que sa commande fasse plus de 1500 €)

Comme cela on aurait un fonctionnement complètement autonome !

Merci de donner votre avis...

PS : faites-vous des développement spécifique sur devis ? Cela pourrait-être une façon de réaliser cela ?

Il y a quelque chose que je ne comprends pas dans votre explication. Est ce que toutes les personnes qui commandes sur votre site veulent feront cela ?
Car si oui, alors vous pouvez en effet directement appliquer les 40% sur toutes les commandes mais ne livrer que les commandes regroupées. Sinon, je ne vois pas comment vous allez faire car si les gens doivent payer au moment de leur commande alors qu'ils n'ont pas eu la réduction, finalement, il auront déjà payé avant d'avoir la réduction au moment du regroupement. Et donc ils ne pourront bénéficier de la réduction sur le prix qu'ils ont déjà payé.

Le système que vous décrivez nécessitera un gros travail de développement. Il faudra un moyen pour que les personnes regroupant les commandes puissent avoir accès aux commandes de leur amis, et ensuite il faudra une vue pour que l'utilisateur puisse valider une commande pour être livré.

Ce dévelopement est trop important pour nous faibles ressources que nous dédions principalement à l'amélioration d'hikashop. Vous pourriez voir du coté de joomlancers.com pour poster une annonce de développement.

bonne remarque Nicolas,

non, les clients traditionnels payent normalement, mais certains les "regroupeurs" auraient des remises.

en fait le processus complet que je voyait est le suivant :
- un "regroupeur" s'inscrit sur le site (et est reconnu comme tel) : il a des droits qui lui donne d'office -40% (la commande ne pouvant être validée que si montant > 1500)
- chaqu'un de ses amis qui commandent, utilise le compte du regroupeur et payent (en utilisant le paiement "en attente")
- quand le regroupeur le décide, il rassemble ses commandes en une seule et la valide (ce qui déclenche les paiements)
en fait c'est ce dernier point (regroupement de commande) qui me parait le plus délicat, non ?

pour l'instant j'en suis la de ma réflexion, mais je vais y travailler encore pour améliorer ...

Merci beaucoup pour vos remarque et si vous avez des idées dites moi. L'idée étant de vraiment faire simple avec un minimum de dev spécifique et si possible vous le sous-traiter (ou sinon je le ferais)

Merci encore et toujours bravo pour votre réactivité et votre qualité

En effet le regroupement est le plus délicat. Il faudrait générer une sorte de méga commande avec un lien vers les autres commandes et ensuite valider le paiement de chaque commande. Cela peut dés fois se faire avec une api du plugin de paiement, mais des fois cela n'est pas possible et il faudra alors valider les paiements un par un dans l'interface de la plate forme de paiement.