WEBIV

Pas besoin sur les fiches produit, mais c'est pas plus mal. C'est vraiment une source de galères...

Bonjour Kaby, bonjour Michel, Le choix des transporteurs est impactant si mes souvenirs sont bons (je n'y ai pas touché depuis longtemps), d'ailleurs c'était la base de mon erreur à l'époque. Pensez bien à sélectionner tous les transporteurs dans la page stock -> entrepôt pour que l'action soit prise en compte. Si ça ne marche toujours pas à ce moment là, envoyez moi un mp que je puisse vous aider en direct. Cdlt Edit : Petite précision : ne sélectionner aucun transporteur ne veut pas dire à cet endroit qu'ils sont tous sélectionnés.

S'il y en a que ça intéresse toujours, Sachez qu'il existe les API suivantes pour vous y aider : Google maps API Bing maps API Personnellement j'ai réussi à faire quelque chose avec la Google maps API mais dans l'empressement je n'ai pas pris le temps d'en faire un module.

Hi, I'll try to translate next part in english but i'm not sure of translation. ==========FRENCH========== Les droits d'accises en France se calculent comme suit : Ils concernent les produits contenant plus de 1.2% vol d'alcool et les bières contenant plus de 0.5% vol. Pour faire simple : Les droits d'accises s'ajoutent au prix du produit hors taxes / hors droits pour donner le prix NET Ils sont différents selon la teneur en alcool de chaque boisson et sont calculés sur la base de l'hectolitre. (Idem pour les droits de sécurité sociale et la taxe sur les boissons sucrées). Pour vendre ces produits-là sur prestashop de façon correcte il faudrait pouvoir en ajouter tant qu'il le faudra de taxes qui s'ajouteront au prix HT pour donner le NET (AVANT le calcul de la TVA). Exemple : Droits d'accises + droits de sécurité sociale + taxe sur les boissons sucrées. On aura donc quelque chose comme : Prix TTC = (Prix HT + Taxes diverses) + TVA ==========ENGLISH========== In France, Excise taxes (right word ?) are calculating like this on products containing more than 1.2% vol alcohol and beers containing more than 0.5% vol. Excise Taxes are added to the price without taxes to result the NET price of a product. The more the product contain alcohol, the more the % of taxe will be high. (Idem for the "securité sociale" tax and the sugary (?) drinks tax) To correctly sell these products on prestashop, we have to be able to add some taxes that will be added to the price without taxes to have a NET price (BEFORE calculating the price with taxes). For example : Excise taxes + "sécurité sociale" taxes + sugary drinks tax So we have something like that : Price = (Price without taxes + Taxes) + TVA Thanks you for helping. PSEN : If you can correct my bad translation, don't hesitate. PSFR : Si vous pouvez corriger ma mauvaise traduction, n'hésitez pas. EDIT : J'ai trouvé la solution : règles de taxes. Désolé pour le dérangement EDIT : I've found the solution : taxes rules. Sory for the post.

J'ai aussi l'erreur 500, une solution ?

Bonjour tout le monde, J'ai eu quelques soucis en installant le module atos, paiement en 1x et 3x sur mon serveur chez gandi. Le problème était que les exécutables s'exécutaient une fois puis avec le temps ne s'exécutaient plus. En fait chez Gandi on ne peut pas utiliser la fonction exec() de php n'importe où, question de sécurité. Du coup tous les fichiers sur le serveur, du moins dans le répertoire htdocs (=celui qui est sur Internet), sont repassés aux droits 0640 Deux solutions pour résoudre le problème : Pour le paiement en une fois, j'ai modifié la base de données et ai remplacé l'adresse d'exécution des binaires par celle du répertoire cgi-bin, à la racine de mon serveur. C'est la solution que je préfère, simple à mettre en place et ne risque pas de causer de soucis Table : ps_configuration Ligne du champ name : ATOS_BIN_DIR Value de cette même ligne : /srv/mon_serveur/www/www.monsite.com/cgi-bin/ Ne pas oublier le "/" final et de mettre les fichiers dans ce répertoire. Pour le paiement en trois fois, le module ne va pas rechercher les informations en base de données (allez savoir ce qui s'est passé dans la tête des développeurs !), j'ai tenté plusieurs choses et la seule qui a fonctionné a été de mettre le code suivant au début des methodes appelant la fonction "exec()", dans le fichier atos3x.php : chmod(dirname(__FILE__)."/bin/request", 755); chmod(dirname(__FILE__)."/bin/response", 755); Ce qui aura pour effet de permettre l'exécution des exécutables et ainsi de pouvoir commander ! Notez que la solution 2 peut être utilisée dans le cas 1 et non l'inverse. Un autre problème a été trouvé chez moi : La solution ? raccourcir le nom du fichier appelé à cette ligne et renommer le fichier de la même façon. Sinon il faudra le déplacer dans un répertoire plus proche de la racine et mettre le bon chemin de fichiers dans le fichier pathfile. En espérant que ça puisse aider une ou deux personnes ;-) Nicolas de Webiv

Je vous en prie, c'est normal. En ce qui concerne les prix d'achat, ils sont gérés via les commandes fournisseurs si je ne m'abuse.

Bonjour Horlabxl, Si je ne me trompe pas, il faut modifier les tables "ps_warehouse_product_location" et "ps_stock". "Chounpyt" nous dira (je l'espère) s'il y a autre chose à modifier puisque je n'ai pas eu à le faire et donc n'ai pas vérifié si c'était tout. Pour modifier les tables et tous les articles d'un coup, le plus simple serait de lancer directement une requête. 1. se connecter à la base de données 2. taper la requête suivante : Update ps_warehouse_product_location set id_warehouse=id; Il ne faut pas oublier de modifier le "ps" par le prefixe s'il a été changé lors de l'installation de prestashop =id devra être remplacé par = l'identifiant de l'entrepôt à utiliser. (exemple si l'entrepôt à l'id 1 et que le prefixe est "presta" il faudra mettre Update presta_warehouse_product_location set id_warehouse=1; 3. taper la requête suivante : Update ps_stock set id_warehouse=id; idem que le 2. Conseil : faites une copie de la base de données au cas où ça ne passerait pas du premier coup ;-) Et n'hésitez pas à me contacter au besoin.Cdlt

Bonjour, La solution qui devrait fonctionner m'a-t-on dit (j'avoue ne pas avoir eu le temps de vérifier, l'utilisateur du site me dit que ça fonctionne comme ça) c'est de mettre les statuts dans l'ordre : passer la commande en statut payée avant de la passer en cours d'expédition ou livrée. Merci de me tenir au courant pour que je puisse changer le statut du poste. Edit : Merci à Domiscope qui a testé une autre astuce donnée en privé : Dans la page stock -> entrepôt Il faut sélectionner tous les transporteurs pour que tout soit pris en compte correctement.

C'était bien ça, grand merci à toi ! :-)

Salut à tous ! Encore un problème de mon côté : J'ai modifié le module homefeatures pour que ça passe mieux dans mon site. En faisant des modifications dans le CSS tout est nickel En faisant des modifications dans le tpl rien n'est pris en compte, y-compris la suppression pure et simple du contenu... J'ai pourtant bien désactivé le cache... Si quelqu'un avait une idée pour m'aider je suis largement preneur... Merci par avance ! :-) Webiv

Personne ne peut m'aider ??

Bonsoir ! J'espère que depuis le temps tu as trouvé une réponse... Sinon pense à faire une requête directement en DB +++

Salut à tous ! Voilà, c'est mon tour d'avoir des soucis et de ne pas réussir à les corriger seul... J'ai cherché sur le forum et google mais personne n'a eu ces soucis :-/ Mon problème en version aussi courte que possible : J'ai un site sur lequel est installée une boutique prestashop. Cette boutique fonctionne sous presta 1.5.3.1 J'utilise le multiboutique ainsi que la gestion avancée des stocks. J'ai créé un produit intitulé test et en ai ajouté 100 au stock (initialisation du stock). Ce qui se passe quand on modifie le statut d'une commande (de 1 pièce pour le test ici) : en attente de paiement, paiement accepté ou préparation en cours La quantité réelle de l'état instantané du stock est décrémentée à 99 (normal) [*]en cours de livraison La quantité réelle remonte à 100 (elle devrait rester à 99 !) aucun mouvement de stock n'est créé. la quantité physique et utilisable n'ont pas bougé (physique au moins devrait passer à 99) [*]livré - validé - payé La quantité réelle ne bouge pas (reste à 100, elle devrait être à 99) aucun mouvement de stock la quantité physique et utilisable ne bougent pas (normalement 99) [*]remboursé la quantité réelle passe à 99 aucun mouvement de stock quantité physique et utilisable ne bougent pas. Je précise que j'ai fait des tests ailleurs et que je n'ai pas rencontré ce problème... Si une âme charitable pouvait me filer un coup de main, je lui en serais éternellement reconnaissant... Par avance, merci :-)