diff --git a/Apps/Trésorerie.md b/Apps/Trésorerie.md
index 8b660f7..b0c791c 100644
--- a/Apps/Trésorerie.md
+++ b/Apps/Trésorerie.md
@@ -1,2 +1,79 @@
L'application de Trésorerie facilite la vie des trésorier, et sert d'interface de création de facture.
-Elle permet également le suivi des remises de chèque reçu par le BDE.
\ No newline at end of file
+Elle permet également le suivi des remises de chèques reçus par le BDE.
+
+# Factures
+
+## Modèle des factures
+
+Il est possible de créer des factures, qui seront enregistrées en base de données. Les différents attributs sont :
+
+ * `id` : Le numéro de la facture
+ * `name` : Le nom de la personne ou la raison sociale à qui est destinée la facture
+ * `address` : L'adresse de cette personne ou raison sociale
+ * `bde` : Le nom du fichier contenant le logo du BDE sous lequel a été éditée la facture. Ce champ ne peut pas être modifié depuis la note, et vaut par défaut le logo du BDE en fonction (exemple : `Saperlistpopette.png`)
+ * `date` : Le jour d'émission de la facture (par défaut le jour même)
+ * `object` : L'objet de la facture, le titre
+ * `description` : La description de la facture
+ * `acquitted` : Indique si la facture a déjà été acquittée ou non.
+
+Les factures contiennent également certaines valeurs hard-codées pour ne pas polluer la base de données, telle que la raison sociale du BDE, son adresse ainsi que ses coordonnées bancaires.
+
+## Produits
+
+À chaque facture est associée plusieurs produits. Pour permettre cela, un modèle `Product` a été créé contenant 4 attributs :
+
+ * `invoice` : `ForeignKey` vers la facture associée au produit
+ * `designation` : Désignation du produit
+ * `quantity` : Quantité achetée
+ * `amount` : Prix unitaire (HT) du produit (peut être négatif si jamais il s'agit d'un rabais, d'un solde prépayé, ...)
+
+Pour ajouter des produits à une facture, cela se passe sur le même formulaire d'ajout/de modification de factures. Pour cela, on utilise un `FormSet`, qui permet de gérer un nombre arbitraire de formulaires (chaque produit est un sous-formulaire).
+
+En en-tête, ce code HTML est généré automatiquement :
+
+```html
+
+
+
+
+```
+
+Où `` est le nombre de produits initialement. Cela permet d'indiquer au FormSet combien de formulaires il y a et combien il faut en gérer. La partie HTML de chaque produit ressemble à ceci :
+
+```html
+
+
+
+
+
+
+
+ €
+
+
+
+
+
+
+```
+
+Où ``__prefix__`` est remplacé par le numéro de ligne et ```` l'identifiant de la facture (non renseigné si non encore créé). De cette manière, le FormSet sait associer chaque formulaire à ses données. On note la présence de deux champs cachés :
+
+ * ``product_set-__prefix__-invoice`` contient l'identifiant de la facture (si existant)
+ * ``product_set-__prefix__-id`` contient l'identifiant du produit en base de données (si existant, sinon 0)
+
+Deux boutons sont présents sur la page, pour ajouter et supprimer un produit. Cela a pour effet de mettre à jour les informations présentes dans les méta-données du formulaire présentées ci-dessus, et de copier une ligne vide (présentée ci-dessus) et de l'afficher en remplaçant ``__prefix__`` par les bonnes valeurs.
+
+Au moment de la sauvegarde du formulaire, on s'assure d'enregistrer tous les produits associés.
+
+## Génération
+
+Les factures peuvent s'exporter au format PDF (là est tout leur intérêt). Pour cela, on utilise le template LaTeX présent à l'adresse suivante : [/templates/treasury/invoice_sample.tex](https://gitlab.crans.org/bde/nk20/-/tree/master/templates/treasury/invoice_sample.tex)
+
+On le remplit avec les données de la facture et les données du BDE, hard-codées. On copie le template rempli dans un ficher tex dans un dossier temporaire. On fait ensuite 2 appels à `pdflatex` pour générer la facture au format PDF. Les deux appels sont nécessaires, il y a besoin d'un double rendu. Ensuite, le PDF est envoyé à l'utilisateur et on supprime les données temporaires.
+
+On remarque que les PDF sont générés à la volée et ne sont pas sauvegardés. Niveau performances, cela prend du temps au plus 2-3 secondes), mais cela n'est pas un problème car on ne génère pas des factures fréquemment. Niveau fiabilité des données, il faut s'assurer que les données hard-codées ne changent pas, et si elles sont amenées à changer (pour cause de déménagement), il faudra s'assurer que cela n'impacte pas les anciennes factures, en ajoutant par exemple un champ `old` (ou `kchan`) pour savoir s'il s'agit d'une nouvelle ou d'une ancienne facture.
+
+# Modèles
+
+
\ No newline at end of file