Rajout de l'export des ventes en csv, par défaut sur les 12 derniers mois #769
No reviewers
Labels
No labels
devtype -- backend
devtype -- docs
devtype -- frontend
devtype -- user interface
difficulty -- easy
difficulty -- hard
difficulty -- normal
Doing
domain -- bda
domain -- bds
domain -- cof
domain -- core
domain -- kfet
Good first issue
priority -- high
priority -- low
priority -- medium
priority -- staff-wanted
status -- development
status -- discussion
status -- need review
status -- production
status -- ready to merge
status -- todo
To Do
type -- bug
type -- hygiene
type -- improvement
type -- new feature
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: DGNum/gestioCOF#769
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "thubrecht/export-ventes"
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?
On rajoute un lien vers
k-fet/purchases
qui permet d'exporter les ventes des articles en CSV par mois.Par défaut, on exporte les 12 derniers mois, mais il est possible de choisir les bornes de la période d'exportation en allant directement sur
k-fet/purchases/YYYY-MM/YYYY-MM
.Fixes #245
ça ne coute rien de mettre
{start,end}_{year,month}
comme paramètres ici, et c'est plus lisible !Sur le principe, je trouve ça assez peu ergonomique pour des utilisateurs lambda de devoir modifier à la main une URL pour pouvoir changer les dates d'export... Il vaudrait mieux une page pour leur permettre de choisir quelques settings (par exemple la granularité ?), qui renvoie (ou qui fait une requete AJAX) vers la vue que tu as faite.
Il y a un problème d'année bissextile si tu fais
timedelta(months=12)
?Pour timedelta, le plus gros truc que tu peux mettre c'est des jours, tu peux pas faire
timedelta(months=12)
Tu peux jeter un oeil à
statistic.py
et la classeScale
, qui a l'air de faire ce que tu veux !Exact, j'avai oublié... Mais on a déjà
dateutil
dans nos requirements, donc tu peux utiliserrelativedelta
à la place.changed this line in version 2 of the diff
changed this line in version 2 of the diff
added 1 commit
Compare with previous version
C'est vrai ^^
Tous ces calculs là se font bien en SQL avec des agrégations/annotations, et ça devrait être plus rapide/le code sera plus concis.
(techniquement l'agrégation entière par mois peut se faire en une seule requête SQL, mais il faut voir à quel point ça rend le code illisible...)
Ça existe des opérations de type
PURCHASE
avecarticle=None
?Le "purchase" devrait probablement être un
Operation.PURCHASE
On sait jamais ? ^^
Après réflexion, si l'article est supprimé, c'est possible... Mais dans tous les cas, ça devrait plutôt être
article__isnull=False
dans le.filter()
.Ça fait quoi cette partie ?
Ça fait la liste des mois dans l'intervalle
Je parlais du code en dessous de ce commentaire ^^
Un index des articles dans la liste des articles, pour savoir dans quelle colonne rajouter les consos
Ça me paraît un peu hackish, mais je range ça avec "ce serait surement plus propre avec de l'agrégation SQL" =)
on en est où de ça ?
Ça a pas vraiment avancé, il faudrait que je regarde cette histoire d'aggrégation SQL
marked this merge request as draft
changed this line in version 3 of the diff
changed this line in version 3 of the diff
changed this line in version 3 of the diff
changed this line in version 3 of the diff
changed this line in version 3 of the diff
added 177 commits
master
Compare with previous version
added 1 commit
Compare with previous version
marked this merge request as ready
???
Une opération simple ne peut pas avoir plusieurs articles, donc je ne suis pas sûr que l'annotation serve à quelque chose ici
Il doit y avoir un moyen d'agréger ça en SQL directement, non ? Quitte à ne pas faire de
values_list
avant...Ça manque possiblement toujours de granularité : un point par mois sur les 6 derniers mois, ça me parait pas très précis...
Vu qu'on groupe sur le mois ça donne le nombre d'articles vendu par mois non ? Ou alors j'ai mal compris comment marchait
Scale
Oui mais tu groupes avant de "chunkifier" donc ça donne le nombre d'articles vendus en tout... En tout cas c'est ce que je comprends de ce lien.
C'est bizarre, j'ai le même résultat si je mets l'annotation avant ou après chunkify_qs
Avec des articles répartis sur plus d'un mois ?
Oui
Bon bah si ça marche 🤷
Plus précisément, je pense que simplement mettre le
values_list
et l'annotation dansget_queryset
et simplement évaluerqs
devrait te donner les totaux de chaque article =)Ça donne le total depuis le début des temps ^^
Oui bon avec un filter en plus ^^ mais va pour la solution python
changed this line in version 5 of the diff
added 1 commit
Compare with previous version
C'était pour que ça prenne moins de place
Si tu veux que ça prenne moins de place tu peux supprimer ces lignes, tu ne réutilises pas la variable après ça 😛
Ah oui tiens
changed this line in version 6 of the diff
added 1 commit
Compare with previous version
added 12 commits
master
71355bbf
- Rajout de l'export des ventes en csv, par défaut sur les 12 derniers moiscecbb583
- Change le nom des paramètresad8c3143
- On utilise Scale44c729df
- Choix 6 mois/12 moisbd109be3
- On déplace l'annotation69472f2c
- Remove unused variableCompare with previous version
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.