Update Trésorerie

Apps/Trésorerie.md

@@ -74,6 +74,53 @@ On le remplit avec les données de la facture et les données du BDE, hard-codé
 
 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
+# Remises de chèques
+
+L'application trésorerie permet aussi de gérer les remises de chèques. En réalité, elle permet de gérer également des remises de crédit par carte bancaire, virement ou espèces, mais cela n'étant pas utilisé, ces types de transactions aparaîtront comme non supportées.
+
+## Différents modèles
+
+### Types de remises
+
+Comme indiqué ci-dessus, tous les types de remises ne sont pas supportés. Pour cela, on passe par un modèle `RemittanceType` qui contient uniquement un champ `OneToOneField` vers un objet `NoteSpecial`. On peut alors voir `RemittanceType` comme un sous-ensemble des notes spéciales, qui correspond aux types de remises supportées. Par défaut, seule la note `Chèque` est supportée (après chargement des données initiales).
+
+L'intérêt de ce genre de procédé plutôt que d'ajouter un booléen dans le modèle `NoteSpecial` est d'empêcher toute dépendance de l'application `treasury` dans l'application `note`, la rendant plus externe.
+
+### Proxys vers transactions de crédit
+
+De la même manière que les types de remise, ce modèle, appelé `SpecialTransactionProxy`, n'existe que pour rendre l'application `treasury` externe et de ne pas surcharger le modèle `SpecialTransaction`.
+
+Ce modèle contient deux attributs :
+
+  * `transaction` : `OneToOneField` vers `SpecialTransaction`
+  * `remittance` : `ForeignKey` vers `Remittance` (voir ci-dessous), remise associée à cette transaction
+
+À chaque fois qu'une transaction spéciale d'un type accepté est créée, un proxy est ajouté automatiquement par le biais d'un signal. De plus, à chaque fois que le serveur web démarre, les vieilles transactions d'un bon type sans proxy s'en voient dotées d'un.
+
+### Remises
+
+Les modèles des remises contiennent les attributs suivants :
+
+  * `remittance_type` : `ForeignKey` vers `RemittanceType` : type de remise (chèque, carte bancaire, virement, espèces)
+  * `date` : date et heure d'ouverture de la remise (`DateTimeField`)
+  * `comment` : commentaire sur la remise, description
+  * `closed` : booléen indiquant si la remise est close ou non
+
+Ce modèle contient des propriétés supplémentaires :
+
+  * `transactions` : `QuerySet<SpecialTransaction>`, transactions liées à la remise
+  * `count` : nombre de transactions liées
+  * `amount` : somme totale des transactions liées
+
+## Relations
+
+* Toute transaction qui n'est pas attachée à une remise d'un bon type peut être attachée à une remise. Cela se passe par le biais d'un formulaire, où le trésorier peut vérifier et corriger au besoin nom, prénom, banque émettrice et montant.
+
+* Toute transaction attachée à une remise encore ouverte peut être retirée.
+* Pour clore une remise, il faut au moins 1 transaction associée.
+* Il n'est plus possible de modifier de quelque manière que ce soit une remise close, que ce soit en modifiant le commentaire, en ajoutant ou en supprimant une transaction attachée.
+* Il n'est pas possible de modifier le type d'une remise. De plus, il n'est pas possible d'ajouter une transaction à une remise si elle n'est pas du bon type.
+
+# Diagramme des modèles
 
 ![treasury.svg](uploads/deed2123ab1044d0db6756ebacef32bb/treasury.svg)