toulouse-maelis: gérer au mieux les factures renvoyées en double par maélis (#79157) #303

Closed
nroche wants to merge 2 commits from wip/79157-parsifal-validate-basket-with-duplicated-invoice into main
Owner

Premier patch pour ne pas crasher.
Second patch pour loguer les demandes wcs qui sont impactées.

Premier patch pour ne pas crasher. Second patch pour loguer les demandes wcs qui sont impactées.
nroche force-pushed wip/79157-parsifal-validate-basket-with-duplicated-invoice from 3842c4d31f to b4a5ee20a6 2023-06-29 11:43:35 +02:00 Compare
Owner

Je ne capte ni la situation ni ce qu'on essaie d'en faire.

DETAIL:  Key (resource_id, regie_id, invoice_id)=(4, 101, 5) already exists.

dans quelle situation, d'un point de vue fonctionne, se trouve-t-on ici ?

En pratique, est-on sur quelque chose qui arrive parce qu'il y a eu nouvelle mise à zéro de leur base de test et ça clashe avec des données résiduelles ?

Est-on sur une vraie situation où une facture avec un id connu existait déjà et une nouvelle avec le même id arrive ?

Si c'est le cas, ça veut plutôt dire que l'ancienne facture côté maélis avec l'identifiant en question n'existe pas ?

Ou est-ce je ne sais comment autre, deux factures différentes qui existent bel et bien avec deux fois le même numéro ?

Autre chose ?

Je ne capte ni la situation ni ce qu'on essaie d'en faire. ``` DETAIL: Key (resource_id, regie_id, invoice_id)=(4, 101, 5) already exists. ``` dans quelle situation, d'un point de vue fonctionne, se trouve-t-on ici ? En pratique, est-on sur quelque chose qui arrive parce qu'il y a eu nouvelle mise à zéro de leur base de test et ça clashe avec des données résiduelles ? Est-on sur une vraie situation où une facture avec un id connu existait déjà et une nouvelle avec le même id arrive ? Si c'est le cas, ça veut plutôt dire que l'ancienne facture côté maélis avec l'identifiant en question n'existe pas ? Ou est-ce je ne sais comment autre, deux factures différentes qui existent bel et bien avec deux fois le même numéro ? Autre chose ?
nroche force-pushed wip/79157-parsifal-validate-basket-with-duplicated-invoice from b4a5ee20a6 to a39f5e986b 2023-06-30 16:25:55 +02:00 Compare
Author
Owner

Dans quelle situation, d'un point de vue fonctionne, se trouve-t-on ici ?
Sur la recette j'ai fait des tests qui ont amené la création d'objets Invoice dans le connecteur.

Sigec a fait le ménage et a remis les compteurs à zéro sur les factures.
Lors de la phase de recette, un agent à Toulouse a fait des tests qui ont amené à créer une facture ayant le même identifiant que la mienne dans Maélis.

En pratique, est-on sur quelque chose qui arrive parce qu'il y a eu nouvelle mise à zéro de leur base de test et ça clash avec des données résiduelles ?

Oui.

Est-on sur une vraie situation où une facture avec un id connu existait déjà et une nouvelle avec le même id arrive ?

Oui. Aucune garantie que ça n'arrivera pas un jour en Production.

Si c'est le cas, ça veut plutôt dire que l'ancienne facture côté maélis avec l'identifiant en question n'existe pas ?

Oui, elle n'existe plus.

Ou est-ce je ne sais comment autre, deux factures différentes qui existent bel et bien avec deux fois le même numéro ?

Non, l'ancienne facture n'existe plus que dans le connecteur, et "bloque" l'enregistrement de la nouvelle.

Autre chose ?

Oui, je pense que c'est ne bonne chose de sortir en erreur sur des doublons de factures.

Après coup, on peut faire accepter la nouvelle facture au connecteur simplement en supprimant l'ancienne à la main.
Cependant, dans le cas des inscriptions panier, on rate le moment où l'on peut associer la facture aux demandes qu'elle concerne.

Les demandes concernées par des factures "doublons" sont notifiées comme si le panier qui leur était associé n'avait pas été validé. Pour améliorer ce point, il faudrait travailler sur les lignes de la facture qui arrive en double, mais sans enregistrer ensuite cette facture.

Il reste que la facture en double ne sera pas supprimée par le connecteur, parce qu'il ne supprime que les factures "panier" et qu'ici il l'identifiera comme étant une "vraie" facture (basket_generation_date à None).
Maélis ne supprimera pas non plus la facture (et l'inscription qui est effective avant que l'usager ait payé) de son côté à priori.

Ces deux derniers points si on veut les traiter, risquent de largement détériorer la lisibilité du code.

> Dans quelle situation, d'un point de vue fonctionne, se trouve-t-on ici ? Sur la recette j'ai fait des tests qui ont amené la création d'objets Invoice dans le connecteur. Sigec a fait le ménage et a remis les compteurs à zéro sur les factures. Lors de la phase de recette, un agent à Toulouse a fait des tests qui ont amené à créer une facture ayant le même identifiant que la mienne dans Maélis. > En pratique, est-on sur quelque chose qui arrive parce qu'il y a eu nouvelle mise à zéro de leur base de test et ça clash avec des données résiduelles ? Oui. > Est-on sur une vraie situation où une facture avec un id connu existait déjà et une nouvelle avec le même id arrive ? Oui. Aucune garantie que ça n'arrivera pas un jour en Production. > Si c'est le cas, ça veut plutôt dire que l'ancienne facture côté maélis avec l'identifiant en question n'existe pas ? Oui, elle n'existe plus. > Ou est-ce je ne sais comment autre, deux factures différentes qui existent bel et bien avec deux fois le même numéro ? Non, l'ancienne facture n'existe plus que dans le connecteur, et "bloque" l'enregistrement de la nouvelle. > Autre chose ? Oui, je pense que c'est ne bonne chose de sortir en erreur sur des doublons de factures. Après coup, on peut faire accepter la nouvelle facture au connecteur simplement en supprimant l'ancienne à la main. Cependant, dans le cas des inscriptions panier, on rate le moment où l'on peut associer la facture aux demandes qu'elle concerne. Les demandes concernées par des factures "doublons" sont notifiées comme si le panier qui leur était associé n'avait pas été validé. Pour améliorer ce point, il faudrait travailler sur les lignes de la facture qui arrive en double, mais sans enregistrer ensuite cette facture. Il reste que la facture en double ne sera pas supprimée par le connecteur, parce qu'il ne supprime que les factures "panier" et qu'ici il l'identifiera comme étant une "vraie" facture (basket_generation_date à None). Maélis ne supprimera pas non plus la facture (et l'inscription qui est effective avant que l'usager ait payé) de son côté à priori. Ces deux derniers points si on veut les traiter, risquent de largement détériorer la lisibilité du code.
nroche force-pushed wip/79157-parsifal-validate-basket-with-duplicated-invoice from a39f5e986b to e0316d50d4 2023-07-06 12:46:10 +02:00 Compare
Owner

Oui. Aucune garantie que ça n'arrivera pas un jour en Production.

S'il y a réutilisation de numéros de facture en production il y aura un réel problème général, et ça n'est pas dans le connecteur que les choses arriveront à se gérer.

Bref pour moi c'est juste un problème de recette et 1/ il y a suffisamment à faire et 2/ c'est déjà assez compliqué ainsi, pour justifier de ne rien faire ici.

> Oui. Aucune garantie que ça n'arrivera pas un jour en Production. S'il y a réutilisation de numéros de facture en production il y aura un réel problème général, et ça n'est pas dans le connecteur que les choses arriveront à se gérer. Bref pour moi c'est juste un problème de recette et 1/ il y a suffisamment à faire et 2/ c'est déjà assez compliqué ainsi, pour justifier de ne rien faire ici.
Author
Owner

Bref pour moi c'est juste un problème de recette et 1/ il y a suffisamment à faire et 2/ c'est déjà assez compliqué ainsi, pour justifier de ne rien faire ici.

Donc on peut reprendre la relecture : mes 2 patchs qui font

  1. en sorte de ne pas crasher
  2. que l'on log les demandes qui ne seront pas notifiées

n'apportent pas de réel changement (ni d'ailleurs dans le code qui se retrouve juste déplacé et ré-indenté).

> Bref pour moi c'est juste un problème de recette et 1/ il y a suffisamment à faire et 2/ c'est déjà assez compliqué ainsi, pour justifier de ne rien faire ici. Donc on peut reprendre la relecture : mes 2 patchs qui font 1) en sorte de ne pas crasher 2) que l'on log les demandes qui ne seront pas notifiées n'apportent pas de réel changement (ni d'ailleurs dans le code qui se retrouve juste déplacé et ré-indenté).
nroche force-pushed wip/79157-parsifal-validate-basket-with-duplicated-invoice from e0316d50d4 to e88ea1c065 2023-07-27 14:18:36 +02:00 Compare
Owner

Je suis du même avis que Fred, rien à faire ici, garder le code tel qu'il est (la validation d'un panier doit renvoyer une facture nouvelle, donc un id inconnu du système), mais prévoir une commande de ré-initialisation pendant recette pour supprimer tous les liens famille/facture.

Je suis du même avis que Fred, rien à faire ici, garder le code tel qu'il est (la validation d'un panier doit renvoyer une facture nouvelle, donc un id inconnu du système), mais prévoir une commande de ré-initialisation pendant recette pour supprimer tous les liens famille/facture.
nroche force-pushed wip/79157-parsifal-validate-basket-with-duplicated-invoice from e88ea1c065 to 1d93b97101 2023-08-25 15:52:25 +02:00 Compare
Author
Owner

Oui, j'arrête de compliquer.

Oui, j'arrête de compliquer.
nroche closed this pull request 2023-08-25 15:53:52 +02:00
Some checks are pending
gitea/passerelle/pipeline/head Build started...

Pull request closed

Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: entrouvert/passerelle#303
No description provided.