unanim

Bonjour, Pareil depuis que je suis passé d'un MXPlan au mail pro d'OVH... j'ai lu pas mal de post sur ce sujet dont un ou la personne concernée a passé plus d'une heure avec OVH sans trouver de solution. Du coup j'ai utilisé un autre mail que celui d'OVH pour la fonction SAV.

@FEP La version utilisée pour l'un de nos clients est "CB Monetico Paiement en 1 Fois v1.7.2.8 - par Hosteco.fr". Le bug est aussi apparu subitement et est dû à OVH. Donc votre pb ne peut être résolu comme nous l'avons fait que si vous avez ce même module, êtes aussi chez OVH et avez un presta 1.7.8.8. Ravi d'apprendre que Monetico a enfin décidé de proposer son propre module gratuit, comme avant. C'était dans les tuyaux quand nous avons mis en place cette solution pour notre client. Merci de l'info car nous préférons toujours un module développé par le service que par des tiers.

@FEP j'ai donné la réponse... paramètre Mode CURL en "substitution-1" au lieu de "standard" c'est dans les réglages du module Monetico. @Médiacom87 Oui bien sûr... mais Hosteco n'est pas non plus responsable des manips des hébergeurs et ne connait pas forcément leurs choix. Mais lorsqu'on explique bien un pb, un bon dév comprend tout de suite et m'avait donné l'astuce en quelques secondes. Après, vu les tarifs des modules Monetico, selon moi exagérés, normal qu'on se tourne vers d'autres solutions. D'autant qu'avant le module était gratuit et fourni par la banque. On paie déjà assez cher de frais bancaires sans encore payer un module pour eux hors de prix.

RESOLU Ce soucis avec le module Monetico Paiement v.3.0 DSP2 de Hosteco vient en fait d'OVH qui fait joujou avec les paramètres de ses serveurs et donc de nos hébergements. En l'occurence une gestion calamiteuse des CURL. Sa résolution consiste simplement à modifier le paramètre Mode CURL en "substitution-1" au lieu de "standard".

Résumé: Depuis un panier dès que le client clique sur "commander" son navigateur mouline environ 4' avant d'afficher la page suivante, et ainsi de suite pour toutes les pages du process de commande. Le problème est apparu subitement, concerne tous les navigateurs, mais fait suite à la maj des modules panier, PayPal, menu de PS sans que nous puissions savoir s'il y a un lien. Actions: Cette boutique dispose des modules paiements CB PayPal et Monetico Paiement v.3.0 DSP2 de Hosteco. Nous avons fini par isoler le problème en désactivant le module Monetico. Sa ré-initialisation, reconfiguration ne change rien. Pas plus que son activiation et la désactivation du module PayPal recemment mis à jour. On en déduit donc que seul le module Hosteco pose problème. Si vous rencontrez ce problème, désactivez le module Monetico Paiment d'Hosteco le temps qu'une solution soit trouvée.

Bonjour, Un bail que je n'avais pas parcouru les topic du forum... ma boutique passée d'une vieille 1.5.6.2 à une 1.7 voici 4 mois. C'est lourd, lent, beaucoup de fonctions disparaissent comme la gestion des ventes en HT à l'export et la possibilité d'annoter les factures en conséquence. Plus beaucoup de possibilité d'adapter facilement les css pour modifier les background, couleurs de fond, textes... Etc, sans passer par des modules payants. Bien sûr les dév doivent aussi gagner leur vie mais là j'ai l'impression que tout est orienté pour faire de la solution un faux gratuit. Bref vous semblez dire que Presta va s'orienter sur un business plan payant avec l'abandon de l'open source. Qu'il faudrait qu'on reste sur la dernière version de la 1.6 C'est bien ce que dois comprendre? Merci

et personne n'a encore trouvé le moyen de modifier l'état produit "Nouveau" en "Neuf" sans que cela modifie également la traduction du tag "nouveau" dans le bloc "nouveaux produits". Du coup un produit "nouveau" (nouvellement proposé sur la boutique) apparaît avec le tag bandeau "Neuf" même s'il est d'occasion ou reconditionné. J'ai lu tous les topic possibles sur cette question sans arriver à la résoudre.

on est d'accord ;-) Mais c'est bien de faire le tour de toutes les options possibles. Pour ne pas être emmerdé suffit de ne pas éditer de facture avec Presta et d'encaisser CB et virements sur le compte pro. Et on peut se passer de certif. Pour le chèque je sais pas exactement mais je crois qu'à partir du moment ou vous éditez manuellement ou via un logiciel de compta forcément certifié une facture dont le paiement se fait par chèque il n'y pas de conflit avec le texte sur la certif du moment que le chèque est encaissé sur un compte pro et que vous êtres membres d'une AGA*. Donc votre presta peut accepter le paiement par chèque aussi. *AGA = centre de gestion agrée par l'administration fiscale, auquel on devrait tous adhérer -même si on a un comptable- ne serait ce que pour ne pas se voir imposer 25% de plus sur les résultats. Cela vaut surtout, bien sûr, pour les entreprises en nom propre, EURL...

Non, non et non... aucune loi n'impose à un commerçant/entreprise d'avoir une caisse enregistreuse. Il peut donc faire des factures papiers à l'ancienne sur un facturier à partir du montant minimum imposé par la loi pour l'obligation d'une facture. Je connais encore des cas... Bien sûr suivant l'activité c'est ni adapté ni pratique. Bien sûr en cas de contrôle fiscal les contrôleurs sont plus tatillons... mais cela concerne généralement des petites structures avec de petits C.A. ... qui n'intéressent pas le Fisc. En revanche s'il a une caisse enregistreuse ou émet ses factures à partir d'un logiciel de comptabilité, l'un comme l'autre doivent être certifiés. Donc si vous avez un logiciel de compta, forcément certifié, éditez vos factures prestashop avec!

Mais pourquoi externaliser les factures??? Presta ne peut émettre qu'un bon de livraison, voire un devis ou bon de commande. La facture c'est vous qui la faîtes. Rien ne l'interdit. Ce serait comique si on interdisait maintenant aux entreprises d'émettre des factures. Quand aux paiements: un paiement CB ou virement qui arrive sur votre compte pro assure la traçabilité et n'exige aucune certification. Qui utilise encore le chèque? Certains continuent de se prendre le choux avec des interprétations d'un texte si abscon que même les services fiscaux ne le comprennent pas.

Ben normalement oui. Pour opérer en France comme intermédiaires de banque ils doivent être immatriculés à l'Orias.

@KevinNash, @doekia, Je crois qu'il n'y pas de différences intrinsèque entre une société privée et une banque. Pour opérer en France, normalement l'établissement doit être immatriculé à l'Orias et l'IOPBSB. Cela signifiant qu'il répond aux exigences de transparence et communication. C'est le cas de PayPlug. Pour Paypal, effectivement ils se conforment aux lois américaines mais pas françaises en la matière.

Ben c'est bien expliqué: "Il en est de même, lorsque tous les paiements reçus en contrepartie d'une vente ou d'une prestation de services sont réalisés avec l'intermédiation directe d’un établissement bancaire établi au sein d'un pays de l'Union européenne soumis à l'obligation d'échange automatique d'informations en application de la directive 2011/16/UE du Conseil du 15 février 2011 relative à la coopération administrative dans le domaine fiscal." Payplug est de droit de Français, je crois, si pas revendu entre temps... donc comme une banque. Paypal est basé en UE mais quand à l'échange d'info, j'ai un doute.

Ce post n'a rien à voir avec le sujet traité dans ce fil, mais c'est dimanche et on peut s'aérer le cerveau. Or donc, pour les dizaines de petits boutiquiers comme moi qui ont lus ces 8 pages, en se perdant parfois dans des concepts qui leurs sont étrangers, vous avez aussi fait la connaissance de Mme Michu. Mme Michu c'est un peu comme le "con". On est tous la Mme Michu de quelqu'un. Et pourtant elle mérite beaucoup plus d'attention qu'on ne lui accorde généralement. Bertrand Duperrin l'avait déjà bien résumé il y a 10 ans pour le domaine de l'informatique. Mais cela vaut aussi pour tous les autres domaines... http://www.duperrin.com/2009/03/24/comment-madame-michu-a-transforme-linformatique/

Donc pour le retour, pour une 1.4.6, code de contrôle inséré seulement dans contact-form.php et history.php (à la racine) puis script dans le header.tpl du thème avec ajout de la classe "contact-form-box" dans le contact-form.tpl et order-detail.tpl du thème (ce que j'avais déjà fait) et tout fonctionne à merveille. Je vois enfin le captcha sur le formulaire de contact ainsi que sur celui d'un compte client (order-detail). Finalement très simple! Quand on connait hein ;-) Grand merci à vous @Eolia et @Doekia