Jump to content

olea

Members
  • Posts

    1,258
  • Joined

  • Last visited

Everything posted by olea

  1. Pour info : https://www.ebp.com/aide-support/informations-legales/mentions-obligatoires
  2. Il faut potentiellement une 3ie adresse sur la facture : https://business.lesechos.fr/entrepreneurs/juridique/13957023-deux-nouvelles-mentions-obligatoires-sur-les-factures-329771.php
  3. Hello Doekia et Eolia, En fait, c'est une 3ie adresse qui doit potentiellement apparaitre sur les factures. La facture comporterait : - l'adresse de livraison - l'adresse du client - l'adresse de facturation Il faudra pouvoir différencier adresse du client et adresse de facturation si elles sont différentes (en plus de l'adresse de livraison) Pour le Numéro de commande, c'est une référence propre au client qu'il faut pouvoir faire apparaitre sur les factures En 1.7.5, je ne vois pas ces infos supplémentaires dans le tunnel de commande.
  4. En Octobre 2019, de nouvelles obligations légales entrent en application, notamment sur l'édition des factures : https://www.legifrance.gouv.fr/affichCode.do?idArticle=LEGIARTI000038414397&idSectionTA=LEGISCTA000038411053&cidTexte=LEGITEXT000005634379&dateTexte=20190813#LEGISCTA000038411051 En particulier : - ajout de l'adresse de facturation si elle est différente de l'adresse du client (en plus de l'adresse de livraison) - ajout du Numéro de commande (c'est une référence propre au client) Qu'en est-il de la mise en oeuvre de ces évolutions sur les différentes versions de Prestashop (Tunnel de commande / factures PDF) ? Merci
  5. Joli : le 23,74 est en TTC Passé en HT, ça fait 18.99HT et le compte est bon. "Vous l'aviez Bertrand?"
  6. moins complète que la 1.6 et une base pour l'avenir, c'est donc que c'est une version intermédiaire ?
  7. Comme on n'a pas eu d'hiver l'an dernier et que l'été a été long à arriver .....
  8. J'ai des modules qui font des choses sur certains événements, en complément des actions qui sont faites nativement. Jusqu'en 1.6, je duplique par exemple le cart.addToCart() en native_addtocart(<même params) et je réécris le cart.addToCart () comme mon compte perso suivi d'un appel native_addtocart() Voire même, dans certains cas, je décide d'appeler ou pas le code natif.
  9. Julien, Avec de telles déclaration d'event en JS, il deveint impossible à des modules de faire des surcharges. Genre un module qui fait quelque chose avant ou après la mise en panier native. Pourquoi ne pas définir une méthode standart (donc surchargeable) qui soit appelé par ce 'On()' ?
  10. On aurait aimé connaitre les gros acteurs de l'internet de demain dont vous semblez faire partie
  11. Ce n'était pas de la curiosité. Nous aimerions savoir quel niveau de prix vous appliquez et comment vous en vivez.
  12. Bon, ben on ne saura pas ce que vous vendez .... Sans doute pas grand-chose Dans ce cas, autant isntaller une nouvelle boutique et repartir de 0
  13. Vous êtes prêt à payer le prix d'un salaire net à un freelance ? et qui paie les charges ?
  14. Excellent...... Vous vendez quoi sur votre petite boutique 1.3.1 ? Vous faites quel ordre de grandeur de CA ?
  15. Bon effectivement c'est corrigé en 1.6.1.1RC1 : si j'ajoute 2 bons de réductions au panier qui ajoute les frais de port, ca ne compte bien qu'une seule fois les frais de port. En revanche, les bons de sont plus visibles dans le panier et je ne peux pas les supprimer :/ Je passe par où pour remonter ça ? dans le ticket? dans le PR ? dans le commit ?
  16. A l'occasion, des news sur ce problème : http://forge.prestashop.com/browse/PSCSX-6239
  17. Bonjour Xavier, Je suis un peu paumé dans le système de versionnage de Prestashop. D'après cet article du DevBlog, à partir de la 1.6.1, le nom des version est 1.MAJOR.MINOR.PATCH Donc 1.6.1.1 est le patch No1 de la version mineure 1.6.1 Quel est l'intérêt de proposer une (enfin plusieurs, puisque c'est la la première RC) sur un patch ? Ne devrait-elle pas plutôt s'appeler 1.6.2.0 dans ce cas ?
  18. +1 Toutefois, je ne trouve pas normal que les modérateurs aient des signatures à rallonge qui redirige vers leur business : - ils postent partout sur le forum (pas juste dans les appels à prestation) - les signatures sont bien plus longues que le message posté ou l'aide apportée. - sans compter tous les messages de pure modération ("vous ne respectez pas les règles", "je modère"...) où leur signature n'apporte rien @France, Bon courage, en espérant que la situation va se débloquer. Olivier
  19. Mais si elle bouge trop souvent, dates et contenus prévus changent constamment et au final on ne converge pas, ou je me trompe ?
  20. Hi Xavier, This is the same thing for us, as contributor, with our module that exists since many years (I have modules older than partner's ones). We can't change the code in one time. Fabien is aware of this, but sometimes the validator people are not :/ And I agree that all new code/module must follow the standards. Triple-checked -> Are you sure ?
  21. Please cancel your own coding standard and use a common one. Take care that refactoring the code may fix some bugs but also introduce new ones Have you all the test cases to check you don't have regressions ?
  22. Déjà, lors de la sortie de la 1.4, j'avais pas mal discuté avec Franck B. sur toutes ces problématiques de gestion de prix dans le TPL (et dans les PDF aussi tant qu'à faire) A l'époque, c'était déjà un véritable casse tête : prix par quantité, prix par client/par groupe/par pays, réduction de groupe, application des TVA... J'ai même encore des tickets dans la forge qui ne sont pas fermés.
  23. Perso, ce qui m'inquiète, c'est que ce genre de problème de fond n'ait pas été évité dès la sortie de la 1.6. C'est pas juste un bug dans un coin, c'est la fonctionnalité en elle-même qui est mal pensée bug de spécifications et non pas bug de codage.
  24. You can't do a foreach on the Tools::safePostVars(). This method modifies the $_POST but doesn't return it modified
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More