Development #39005
Toulouse Axel - endpoint de paiement des factures
0%
Description
opération FormPaiementDui
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Lauréline Guérin il y a plus de 4 ans
- Fichier 0001-toulouse_axel-endpoint-to-pay-an-invoice-39005.patch 0001-toulouse_axel-endpoint-to-pay-an-invoice-39005.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Lauréline Guérin il y a plus de 4 ans
- Statut changé de Solution proposée à En cours
Mis à jour par Lauréline Guérin il y a plus de 4 ans
- Lié à Development #39062: Lingo - envoyer le montant de la transaction lors du callback de paiement ajouté
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
Discussion dans #39062 et en jabber sur le problème de ne pas pouvoir retrouvé le DUI si pas de nameid de l'utilisateur rattaché.
(14:17:52) Laureline Guérin: pas con ta remarque, d'ailleurs dans le connecteur teamnet_axel c'est comme ça que ça marche :) (14:20:48) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: en fait j'allais rajouter un truc (14:21:00) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: je me dis que lingo devrait ne pas savoir comment on identifie la facture (14:21:11) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: on devrait juste lui filer une URL déjà formée avec ce qu'on veut dedans et il l'appelle (14:21:18) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: je pensais que c'était déjà comme cela (14:21:36) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: c'est toujours con de construire des URLs à la main dans une interface entre systèmes distant (14:21:50) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: si on peut fournir l'URL dejà formée c'est toujours plus simple de faire évoluer les choses ensuite (14:24:28) Laureline Guérin: mais du coup c'est l'objet d'un autre ticket, non ? (14:24:34) Laureline Guérin: là je peux me débrouiller avec l'existant (14:29:01) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: oui de toute façon ça demanderait de changer beaucoup trop de choses (14:29:17) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: typiquement il faudrait faire de l'URL de la facture son RemoteItem.id (14:29:43) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: et ne pas stocker les item_id séparé par des virgules (parce que la virgule est autorisé dans les URLs) mais des espaces (14:30:05) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: par contre je vois que ça gère déjà un display_id différent de id (14:30:09) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: faut profiter de ça (14:30:33) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: dans get_invoices() renvoie un display_id avec l'ancienne valeur de id (14:31:08) Laureline Guérin: yep ok (14:31:49) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: et dans id '%s-%s' % (link.dui, facture['IDFACTURE']) et en entrée if '-' in id: dui = id.split('-', 1)[0] else: # find dui by nameid (14:31:59) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: comme ça on gère les deux modes avec ou sans DUI (14:32:03) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: sait-on jamais (14:32:45) Laureline Guérin: on peut juste pas marquer la facture comme payée si on n'a pas le dui dans l'id :) (14:33:29) bdauvergne@im.libre-entreprise.com/25326598331579261034299156: sans dui on peut rien faire de tout façon
Mis à jour par Lauréline Guérin il y a plus de 4 ans
- Fichier 0001-toulouse_axel-endpoint-to-pay-an-invoice-39005.patch 0001-toulouse_axel-endpoint-to-pay-an-invoice-39005.patch ajouté
- Statut changé de En cours à Solution proposée
Mis à jour par Benjamin Dauvergne il y a plus de 4 ans
- Statut changé de Solution proposée à En cours
- est-ce qu'on a une liste des régies quelque part ? Pour documenter ça sur le connecteur directement (même si ça évoluera ça évitera d'avoir à chercher dans un premier temps)
- je ne suis pas fan du threading de error_status... il doit y avoir moyen de gérer ça autrement, uniquement dans invoice_pdf
- l.858
dui, invoice_id = invoice_id.split('-')
manque un, 1
et manque un try/except pour remonter une erreur de syntaxe - idem contrôler que regie_id est non vide (pareil pour tous les autres)
- l.857
data = json.loads(request.body)
je pense qu'on peut se permettre un schéma, après tous les autres (en plus celui là on devrait pouvoir le partager avec les autres connecteurs facture dans passerelle) - on devrait avoir un get_invoice_by_id() plutôt que de boucle sur get_invoices_by_dui ; en fait les cas où le name_id est nécessaire ou pas ne sont pas bien séparés, en fait
def invoice()
ne devrait pas attendre de NameID, invoice_id étant suffisant ou alors optionnelement (si présent on check que l'accès est bon, i.e. les DUI correspondent, mais c'est tout je pense) - manque try/except autour de strptime()
- IDREGIEENCAISSEMENT : on est sûr que ce sera toujours vide ? sinon poser la question à Toulouse
Mis à jour par Lauréline Guérin il y a environ 4 ans
est-ce qu'on a une liste des régies quelque part ? Pour documenter ça sur le connecteur directement (même si ça évoluera ça évitera d'avoir à chercher dans un premier temps)
On a une liste de regie de prod et de preprod dans le ticket #37600; je documente lesquelles ?
l.858 dui, invoice_id = invoice_id.split('-') manque un , 1 et manque un try/except pour remonter une erreur de syntaxe
Dans la regex de définition de l'url : (?P<invoice_id>\w+-\d+)
Du coup, en entrée on a forcément une string du bon format
idem contrôler que regie_id est non vide (pareil pour tous les autres)
Idem, (?P<regie_id>[\w-]+)
ça ne peut pas être vide
IDREGIEENCAISSEMENT : on est sûr que ce sera toujours vide ? sinon poser la question à Toulouse
Dans la doc:
Régie d’encaissement : si transmis vide par TS, prendre règle suivante pour déterminer la régie d’encaissement :
Régie d’encaissement : actuellement il n’y qu’une seule régie d’encaissement par régie de facturation qui est utilisée pour les paiements en ligne.
Dans le cas ou il y aura plusieurs régies d’encaissement il faudra soit passer son identifiant, soit avoir l’information dans Axel de laquelle il s’agit (onglet : ‘paiement en ligne’)
A priori ils ont tout de leur côté pour déterminer la régie d'encaissement
Mis à jour par Lauréline Guérin il y a environ 4 ans
- Fichier 0001-toulouse_axel-endpoint-to-pay-an-invoice-39005.patch 0001-toulouse_axel-endpoint-to-pay-an-invoice-39005.patch ajouté
- Statut changé de En cours à Solution proposée
je ne suis pas fan du threading de error_status... il doit y avoir moyen de gérer ça autrement, uniquement dans invoice_pdf
J'ai géré ça dans invoice_pdf avec un try/except
on devrait avoir un get_invoice_by_id() plutôt que de boucle sur get_invoices_by_dui ; en fait les cas où le name_id est nécessaire ou pas ne sont pas bien séparés, en fait def invoice() ne devrait pas attendre de NameID, invoice_id étant suffisant ou alors optionnelement (si présent on check que l'accès est bon, i.e. les DUI correspondent, mais c'est tout je pense)
J'ai simplifié.
Note: on a toujours besoin du DUI (on peut l'avoir en param ou le trouver grâce au name_id), car c'est un param du WS. invoice_id n'est pas suffisant.
manque try/except autour de strptime()
géré dans la fonction encode_datetime
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
Lauréline Guerin a écrit :
est-ce qu'on a une liste des régies quelque part ? Pour documenter ça sur le connecteur directement (même si ça évoluera ça évitera d'avoir à chercher dans un premier temps)
On a une liste de regie de prod et de preprod dans le ticket #37600; je documente lesquelles ?
Je découvre le bordel que c'est oublions.
l.858 dui, invoice_id = invoice_id.split('-') manque un , 1 et manque un try/except pour remonter une erreur de syntaxe
Dans la regex de définition de l'url :
(?P<invoice_id>\w+-\d+)
Du coup, en entrée on a forcément une string du bon format
Ok.
idem contrôler que regie_id est non vide (pareil pour tous les autres)
Idem,
(?P<regie_id>[\w-]+)
ça ne peut pas être vide
Ok.
IDREGIEENCAISSEMENT : on est sûr que ce sera toujours vide ? sinon poser la question à Toulouse
Dans la doc:
Régie d’encaissement : si transmis vide par TS, prendre règle suivante pour déterminer la régie d’encaissement :
Régie d’encaissement : actuellement il n’y qu’une seule régie d’encaissement par régie de facturation qui est utilisée pour les paiements en ligne.
Dans le cas ou il y aura plusieurs régies d’encaissement il faudra soit passer son identifiant, soit avoir l’information dans Axel de laquelle il s’agit (onglet : ‘paiement en ligne’)
Bon ok on verra plus tard si ça arrive.
Mis à jour par Benjamin Dauvergne il y a environ 4 ans
- Statut changé de Solution proposée à Solution validée
Lauréline Guerin a écrit :
J'ai simplifié.
Note: on a toujours besoin du DUI (on peut l'avoir en param ou le trouver grâce au name_id), car c'est un param du WS. invoice_id n'est pas suffisant.
invoice_id contenant le DUI il est toujours suffisant.
Mis à jour par Lauréline Guérin il y a environ 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 342121cf387f75282a88af6e7e909f68e8e0536b Author: Lauréline Guérin <zebuline@entrouvert.com> Date: Thu Jan 16 14:31:18 2020 +0100 toulouse_axel: endpoint to pay an invoice (#39005)
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
toulouse_axel: endpoint to pay an invoice (#39005)