wip/71528-generate-draft-invoices (#71528) #1
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/71528-generate-draft-invoices"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
WIP: wip/71528-generate-draft-invoicesto WIP: wip/71528-generate-draft-invoices (#71528)b1e493ce7f
tofd6655bf74
c69e709638
toaed1a28f9c
8b0db21f12
to3141d3147a
3141d3147a
to6f51c84b9b
6f51c84b9b
to0ff2d1a203
0ff2d1a203
to3d8d6b1f4f
3d8d6b1f4f
toe9ef473660
e9ef473660
to4ad763f4c8
@ -508,4 +508,2 @@
criterias = {}
categories = []
# for each category (ordered)
for category in self.pricing.categories.all().order_by('pricingcriteriacategory__order'):
plus nécessaire depuis #66899
@ -513,3 +513,3 @@
categories.append(category.slug)
# find the first matching criteria (criterias are ordered)
for criteria in self.pricing.criterias.filter(category=category, default=False):
for criteria in self.pricing.criterias.all():
(pour utiliser le prefetch)
@ -87,0 +134,4 @@
class InvoiceLine(AbstractInvoiceLine):
invoice = models.ForeignKey(Invoice, on_delete=models.PROTECT, null=True, related_name='lines')
j'ai repris les models proposés dans #69728, avec quelques ajustements
Il reste plein de
XXX
dans le code, mais je les règlerai plus tard, dans d'autres tickets (quand j'aurai de quoi visualiser les lignes dans l'UI, pour voir exactement quelles informations il manque - pour les erreurs, pour avoir le contexte de calcul, etc)Voila donc une v1 de la génération de lignes de facturation, où chaque facture est facturée à l'enfant (et non à son payeur, ça viendra après).
Les lignes sont groupées par payeur (= enfant pour le moment) et par régie.
WIP: wip/71528-generate-draft-invoices (#71528)to wip/71528-generate-draft-invoices (#71528)@ -0,0 +94,4 @@
date_start=date_start,
date_end=date_end,
)
request = RequestFactory().get('/') # XXX
request qui in fine arrive sur pricing.get_extra_variables, pour un RequestContext pour le rendu de gabarits, pour que le context processor qui fournit la variable "cards" soit disponible; c'est bien ça ?
Peut-être on pourrait ne passer request nulle part et avoir cet appel à RequestFactory directement dans pricing.get_extra_variables ?
Je me demandais, sans avoir vérifié, si en terme de perfs c'était consommateur d'instancier RequestFactory à chaque ligne de facturation.
@ -0,0 +128,4 @@
except AgendaPricingNotFound:
# no pricing, no invoice
# can happen if pricing model defined only on a part of the requested period
# XXX error, warning, or ignore ?
Je pense que la politique globale pour le moment pourrait être d'arrêter sur une erreur; mais dessous pour gérer PricingError il y a ajout de l'info d'erreur dans une DraftInvoiceLine et peut-être que la même chose pourrait avoir lieu ici.
L'inconvénient si je capte bien c'est qu'on va avoir cette ligne d'erreur répétée pour toutes les présences, je dirais que c'est ok.
Je réfléchissais à un moyen de rattraper les erreurs (genre un pointage manquant), pour les ajouter à la facturation suivante.
Et du coup, avoir une ligne par erreur, ça permettrait peut-être de retrouver les erreurs pour les rejouer.
(ça vaut pour les PricingError)
Sauf que dans le cas d'une grille tarifaire manquante pour une date donnée, on peut se contenter de noter ça en warning, charge à l'agent de se dire "ha zut mon paramétrage", de corriger et rejouer.
Mais pas sûr, on verra dans des prochains tickets :)
@ -0,0 +204,4 @@
continue
regie = agendas_by_slug[agenda_slug].regie
if not regie:
# XXX what should we do if regie is not configured ?
On raise et ça s'arrête là, pour quelque chose gros comme ça je pense qu'on n'a pas à collecter toutes les erreurs pour les présenter en une fois, que l'agent peut souffrir de cliquer plusieurs fois et de chaque fois aller corriger une erreur, il ne devrait pas y en avoir trop.
@ -0,0 +219,4 @@
for adult_external_id, adult_lines in regie_subs.items():
invoice = DraftInvoice.objects.create(
label=_('Invoice from %s to %s') % (date_start, date_end - datetime.timedelta(days=1)),
date_issue=date_end, # XXX
À voir avec avec Stef comment on détermine la date qui apparait sur la facture ? (si j'ai bien compris l'enjeu).
Je pense que pour #71910 je vais ajouter un champ date_issue ailleurs, et setter les factures avec.
Très boulet j'ai vu le code avant ce commentaire et j'ai donc particulièrement relu les XXX... (je pense que comme c'était encore préfixé WIP gitea n'a pas envoyé de notification).
Ca me fait de la matière pour les prochains tickets :)
4ad763f4c8
to2e1644ac99
Pas mal du tout, j'ai mis deux remarques sur les noms de attributs "amount" et "adult_external_id" juste parce qu'il faut montrer que j'ai relu.
@ -87,0 +89,4 @@
class AbstractInvoice(models.Model):
label = models.CharField(_('Label'), max_length=300)
amount = models.DecimalField(max_digits=9, decimal_places=2, default=0)
On devra gérer les notions de montant total et montant dû (reste à payer) sur les factures, je pense qu'on peut déjà prévoir l'affaire et renommer "amount" en "total_amount".
ok je fais ça
@ -87,0 +114,4 @@
total_amount = models.DecimalField(max_digits=9, decimal_places=2)
user_external_id = models.CharField(max_length=250)
adult_external_id = models.CharField(max_length=250)
On parle ici adult_external_id et dans la facture de payer... c'est pas la même chose ? On pourrait pas déjà appeler ça "payer" ici aussi ?
dans tarification, c'est adult_external_id, mais peu importe on peut nommer ça payer pour que ce soit plus explicite