Le 22/06/2016 23:19, gornety@no-log.org a écrit :
Log:
Gestion de prix_ht et taxe pour se rapprocher du fonctionnement de produits
le prix est copié dans prix_ht lors de la mise à jour du plugin
Super, merci pour cette amélioration !
--
RastaPopoulos
Le 23/06/2016 à 09:52, RastaPopoulos a écrit :
Le 22/06/2016 23:19, gornety@no-log.org a écrit :
Log:
Gestion de prix_ht et taxe pour se rapprocher du fonctionnement de
produits
le prix est copié dans prix_ht lors de la mise à jour du pluginSuper, merci pour cette amélioration !
problème tout de même avec cette version 3.1.0 : le prix est bien copié dans la nouvelle colonne "prix_ht", mais la colonne "prix" passe à '0'.
du coup, les abonnements ne marchaient plus...pas glop 
Une solution serait de modifier la ligne Connexion · GitLab
Sorry, rien à proposer ne connaissant pas l'instruction SQL qui permettrait de faire ça.
P
Le 27/06/2016 10:32, Peetdu a écrit :
problème tout de même avec cette version 3.1.0 : le prix est bien copié
dans la nouvelle colonne "prix_ht", mais la colonne "prix" passe à '0'.du coup, les abonnements ne marchaient plus...pas glop
Ah mais s'il y a la colonne "prix_ht" et la colonne "taxe" : il faut SUPPRIMER la colonne "prix" qui n'a plus de raison d'être à priori.
Sauf à avoir une synchronisation permanente dès qu'on modifie d'un côté ou de l'autre, ce qui est possible à implémenter et permet de saisir soit par le HT soit par le TTC, mais dans ce cas il faudrait implémenter ce fonctionnement partout… Mais actuellement dans Produits ce n'est pas ça, on a que prix_ht et taxe.
--
RastaPopoulos
Le 27/06/2016 10:32, Peetdu a écrit :
Le 23/06/2016 à 09:52, RastaPopoulos a écrit :
Le 22/06/2016 23:19, gornety@no-log.org a écrit :
Log:
Gestion de prix_ht et taxe pour se rapprocher du fonctionnement de
produits
le prix est copié dans prix_ht lors de la mise à jour du pluginSuper, merci pour cette amélioration !
problème tout de même avec cette version 3.1.0 : le prix est bien copié dans la nouvelle colonne "prix_ht", mais la colonne "prix" passe à '0'.
du coup, les abonnements ne marchaient plus...pas glop
Une solution serait de modifier la ligne Connexion · GitLab
Sorry, rien à proposer ne connaissant pas l'instruction SQL qui permettrait de faire ça.
P
désolé
cela dit je ne comprends pas comment il se fait que le prix à 0
bloque le fonctionnement des abonnements courants
yanic
--
Yanic Gornet - 06 08 60 46 81
Le 27/06/2016 à 18:20, gornety a écrit :
Le 27/06/2016 10:32, Peetdu a écrit :
Le 23/06/2016 à 09:52, RastaPopoulos a écrit :
Le 22/06/2016 23:19, gornety@no-log.org a écrit :
Log:
Gestion de prix_ht et taxe pour se rapprocher du fonctionnement de
produits
le prix est copié dans prix_ht lors de la mise à jour du pluginSuper, merci pour cette amélioration !
problème tout de même avec cette version 3.1.0 : le prix est bien
copié dans la nouvelle colonne "prix_ht", mais la colonne "prix" passe
à '0'.du coup, les abonnements ne marchaient plus...pas glop
Une solution serait de modifier la ligne
Connexion · GitLabSorry, rien à proposer ne connaissant pas l'instruction SQL qui
permettrait de faire ça.P
désolé
cela dit je ne comprends pas comment il se fait que le prix à 0
bloque le fonctionnement des abonnements courants
avant la modif, il n'y avait qu'un seul champ "prix" qui prenait la valeur de l'abonnement. Avec la modif de la 3.1, la valeur passait à '0'. Donc sur le site où j'utilise ce plugin, tous les abonnements sont passés à 0 €.
Je ne dois qu'à la vigilance du webmaster de ce site de mettre rendu compte du problème.
Je pense qu'il est possible que d'autres rencontre le pb. D'où, je pense, la nécessité d'un patch.
P
Le 28/06/2016 20:51, Peetdu a écrit :
avant la modif, il n'y avait qu'un seul champ "prix" qui prenait la valeur de l'abonnement. Avec la modif de la 3.1, la valeur passait à '0'. Donc sur le site où j'utilise ce plugin, tous les abonnements sont passés à 0 €.
Je ne dois qu'à la vigilance du webmaster de ce site de mettre rendu compte du problème.Je pense qu'il est possible que d'autres rencontre le pb. D'où, je pense, la nécessité d'un patch.
mouais
1) avec la modif 3.1, le champs prix est mis à 0
mais la valeur qui était dans ce champ est copiée dans prix_ht
donc on a rien perdu
2) en utilisant le plugin API Prix
la balise #PRIX donne le résultat prix_ht + prix_ht * taxe
donc le prix ttc, y compris lorsque taxe = 0
donc la même valeur que l'ancienne colonne "prix" (#PRIX)
en conclusion on devrait peut être ajouter dans plugin.xml de abonnements v3.1
<necessite nom="prix" compatibilite="[0.1.11;]" />
qu'en pensez-vous ?
--
Yanic Gornet - 06 08 60 46 81
Hello,
Ben non, pas mouais.
J'ai le même problème que Peetdu, suite à la mise à jour du plugin, sur notre site tous les prix des abonnements sont passé à 0€ (balise #PRIX avec api prix 0.1.11). Super promo !
Tu es bien sûr de toi gornety, la balise #PRIX renvoie le prix correct chez toi (avec prix_ht=N, taxe=0 et prix=0, ce qu'on obtient après la mise à jour) ?
Auquel cas, un patch est urgent là (et je me suis bien fait tiré les oreilles en passant).
Le 28/06/2016 à 23:34, gornety a écrit :
Le 28/06/2016 20:51, Peetdu a écrit :
avant la modif, il n'y avait qu'un seul champ "prix" qui prenait la valeur de l'abonnement. Avec la modif de la 3.1, la valeur passait à '0'. Donc sur le site où j'utilise ce plugin, tous les abonnements sont passés à 0 €.
Je ne dois qu'à la vigilance du webmaster de ce site de mettre rendu compte du problème.Je pense qu'il est possible que d'autres rencontre le pb. D'où, je pense, la nécessité d'un patch.
mouais
1) avec la modif 3.1, le champs prix est mis à 0
mais la valeur qui était dans ce champ est copiée dans prix_ht
donc on a rien perdu2) en utilisant le plugin API Prix
la balise #PRIX donne le résultat prix_ht + prix_ht * taxe
donc le prix ttc, y compris lorsque taxe = 0donc la même valeur que l'ancienne colonne "prix" (#PRIX)
en conclusion on devrait peut être ajouter dans plugin.xml de abonnements v3.1
<necessite nom="prix" compatibilite="[0.1.11;]" />qu'en pensez-vous ?
Le 27/06/2016 à 10:43, RastaPopoulos a écrit :
Le 27/06/2016 10:32, Peetdu a écrit :
problème tout de même avec cette version 3.1.0 : le prix est bien copié
dans la nouvelle colonne "prix_ht", mais la colonne "prix" passe à '0'.du coup, les abonnements ne marchaient plus...pas glop
Ah mais s'il y a la colonne "prix_ht" et la colonne "taxe" : il faut
SUPPRIMER la colonne "prix" qui n'a plus de raison d'être à priori.
ben autant faire comme chez les autre (thelia, presta) et considérer que un prix est ht
je vois pas l'intérêt de changer le champ sql, la tva change tout les ans et dès fois plus, suivant les produits…
donc je vois pas l'intérêt de la modif, un prix ht est un PRIX si y'a un champ taxe on ajoute et c'est du TTC sinon on facture sans taxe vu qu'elle est a 0 …
fin moi j'dis ça, …
j'dis rien ^^
--
Bonne journée
Arnaud B. (Mist. GraphX)
Le 30/08/2016 à 17:33, Charles Razack a écrit :
Tu es bien sûr de toi gornety, la balise #PRIX renvoie le prix correct chez toi (avec prix_ht=N, taxe=0 et prix=0, ce qu'on obtient après la mise à jour) ?
vouais, absolument
cela dit désolé pour la maladresse avec laquelle j'ai fait ce commit
je ne sais pas bien comment j'aurai du procéder autrement
mais je suis bien certain que j'aurai du faire autrement
--
Yanic Gornet - 06 08 60 46 81
Hello,
Bon, avant tout je trouve cette évolution bienvenue, merci pour ta contribution.
Par contre c'est dommage de ne pas t'être penché sur le problème dès que les 1ers retours te sont remontés.
Les boulettes, ça arrive (j'en ai fait !), mais sur quelque chose de bloquant comme ça, il ne faut pas laisser trainer.
Alors j'ai pu faire un test sur un autre site aujourd'hui (mise à jour de 3.0.x vers 3.1.x), et là surprise, #PRIX fonctionne !
Du coup je ne m'explique pas cette inconsistence avec les résultats obtenus sur le 1er site où j'ai mis à jour le plugin.
Quoiqu'il en soit, je suis d'accord avec la remarque de Rastapopoulos, la colonne "prix" n'a plus lieu d'être puisqu'on a prix_ht et taxe, je suis d'avis de la supprimer.
C'est consistant avec d'autres plugins qui gère des prix (produits, commandes), et je pense que ça règlera à coup sûr le souci du prix à 0 dans certains cas.
Je vois aussi que la fonction qui calcule les prix se rabat sur la taxe configurée dans le plugin produits, là je suis mitigé.
Est-ce que la taxe configurée dans produits est censée concerner *tous* les objets du site, ou juste les produits ?
Ce n'est pas forcément évident, de plus cette dépendance à produits n'est mentionnée nulle part.
En tout cas dans l'immédiat, pour rétablir à coup sûr le fonctionnement de #PRIX sur les offres d'abonnements, je propose de supprimer la colonne "prix" donc, à moins qu'il y ait objection.
Glop
Le 31/08/2016 à 22:13, gornety a écrit :
Le 30/08/2016 à 17:33, Charles Razack a écrit :
Tu es bien sûr de toi gornety, la balise #PRIX renvoie le prix correct chez toi (avec prix_ht=N, taxe=0 et prix=0, ce qu'on obtient après la mise à jour) ?
vouais, absolument
cela dit désolé pour la maladresse avec laquelle j'ai fait ce commit
je ne sais pas bien comment j'aurai du procéder autrement
mais je suis bien certain que j'aurai du faire autrement
Compte tenu que le plugin est dans la nature et qu'il y a eu des upgrade de base foireux, il faut faire une série de requêtes qui à la fois assure la migration pour une mise à jour depuis l'ancienne version et qui répare les versions existantes.
Ça peut etre un truc du genre (vu de loin, à verifier)
- si une colonne prix_ht existe, faire un
sql_update('spip_abonnements',array('prix_ht'=>'prix'),'prix_ht=0');
pour etre sur que on a bien les prix dans prix_ht et pas dans prix
puis un sql_alter pour renommer la colonne prix en colonne prix_ht
(marchera sur les 1ères migrations)
puis un sql_delete sur la colonne prix (pour les migrations foirées)
Enfin tu vois l'idée, une fonction de migration qui répare tous les cas et remets tout le monde au propre.
--
Cédric
Charles Razack a écrit :
Hello,
Bon, avant tout je trouve cette évolution bienvenue, merci pour ta
contribution.
Par contre c'est dommage de ne pas t'être penché sur le problème dès que
les 1ers retours te sont remontés.
Les boulettes, ça arrive (j'en ai fait !), mais sur quelque chose de
bloquant comme ça, il ne faut pas laisser trainer.Alors j'ai pu faire un test sur un autre site aujourd'hui (mise à jour
de 3.0.x vers 3.1.x), et là surprise, #PRIX fonctionne !
Du coup je ne m'explique pas cette inconsistence avec les résultats
obtenus sur le 1er site où j'ai mis à jour le plugin.Quoiqu'il en soit, je suis d'accord avec la remarque de Rastapopoulos,
la colonne "prix" n'a plus lieu d'être puisqu'on a prix_ht et taxe, je
suis d'avis de la supprimer.
C'est consistant avec d'autres plugins qui gère des prix (produits,
commandes), et je pense que ça règlera à coup sûr le souci du prix à 0
dans certains cas.Je vois aussi que la fonction qui calcule les prix se rabat sur la taxe
configurée dans le plugin produits, là je suis mitigé.
Est-ce que la taxe configurée dans produits est censée concerner *tous*
les objets du site, ou juste les produits ?
Ce n'est pas forcément évident, de plus cette dépendance à produits
n'est mentionnée nulle part.En tout cas dans l'immédiat, pour rétablir à coup sûr le fonctionnement
de #PRIX sur les offres d'abonnements, je propose de supprimer la
colonne "prix" donc, à moins qu'il y ait objection.Glop
Le 31/08/2016 à 22:13, gornety a écrit :
Le 30/08/2016 à 17:33, Charles Razack a écrit :
Tu es bien sûr de toi gornety, la balise #PRIX renvoie le prix
correct chez toi (avec prix_ht=N, taxe=0 et prix=0, ce qu'on obtient
après la mise à jour) ?vouais, absolument
cela dit désolé pour la maladresse avec laquelle j'ai fait ce commit
je ne sais pas bien comment j'aurai du procéder autrement
mais je suis bien certain que j'aurai du faire autrement----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Merci pour le retour, je vais partir sur quelque chose comme ça, dès que j'aurais le combo motivation + temps (ce week-end sans doute)
Le 02/09/2016 à 21:06, Cédric Morin a écrit :
Compte tenu que le plugin est dans la nature et qu'il y a eu des upgrade
de base foireux, il faut faire une série de requêtes qui à la fois
assure la migration pour une mise à jour depuis l'ancienne version et
qui répare les versions existantes.Ça peut etre un truc du genre (vu de loin, à verifier)
- si une colonne prix_ht existe, faire un
sql_update('spip_abonnements',array('prix_ht'=>'prix'),'prix_ht=0');
pour etre sur que on a bien les prix dans prix_ht et pas dans prix
puis un sql_alter pour renommer la colonne prix en colonne prix_ht
(marchera sur les 1ères migrations)
puis un sql_delete sur la colonne prix (pour les migrations foirées)
Enfin tu vois l'idée, une fonction de migration qui répare tous les cas
et remets tout le monde au propre.