rastapopougros
commented
3 years ago Glop, alors pour ce point, j'ai peut-être mal compris l'intérêt.
"n'est pas forcément identique dans tous les cas" : bé oui, c'est bien déjà cela dans le code, depuis le départ (avant même nos modifs) puisque c'est dans chaque implémentation, au moment de l'envoi à l'API du prestataire (donc déjà dans du code qui est spécifique à ce prestataire) que c'est multiplié (ou pas !) par ci ou ça. Et en plus parfois c'est même possiblement différent dans la fonction d'envoi de départ, et dans la gestion du retour pour le même prestataire (cf Ogone).
Du coup quel intérêt d'avoir toute une suite de fonctions possibles de personnalisation, alors qu'à priori toutes les normalisations (et utilisation de la fraction) sont… déjà dans le code qui est spécifique à ce prestataire ?
On pourrait même imaginer, c'est plausible, qu'une API chelou (ce n'est pas ce qui manque dans la banque, tu le dis toi-même) pour le même morceau (l'envoi de départ par ex) demande que tel argument soit normalisé de telle manière, et telle autre argument d'une autre manière ! Je dis n'importe quoi hein mais par ex que le paramètre du montant normal soit normalisé d'une manière alors que le param des échéances soit une autre.
Du coup j'ai pas l'impression qu'avoir ce test de spécificité de fonctions, avec possiblement une fonction pour tel presta ou telle devise, résolve le problème, vu que ça peut être vraiment à chaque param un truc différent (chaque presta fait ce qu'il veut). J'ai plutôt l'impression que le seul moyen de s'assurer que chaque argument a le bon format, c'est bien de transformer à l'endroit où on utilise de la manière indiquée dans la doc du presta pour tel argument particulier, ce qui est déjà le cas (mais toujours à compléter pour chaque presta).
Cerdic
cf https://github.com/nursit/bank/pull/52#issuecomment-636862758
La normalisation du montant n'est pas forcément identique dans tous les cas
Par ailleurs, comme indiqué au dessus pour ogone, les api bancaire étant chacune uniques et non standards, on ne peut pas présupposer que les montants sont toujours convertis en multipliant par 10^(nombre de décimales de la monnaie) : c'est peut-être en général vrai, mais pas tout le temps Cf donc :
Il faut donc que la conversion montant décimal => montant à envoyer se fasse via une fonction générique, qui se chargera de regarder si on a une fonction spécifique pour ce couple (presta-devise) ou pour le presta, et le cas échéant appellera la fonction spécifique, ou sinon appliquera le traitement par défaut.