Libellés d'écritures comptables configurables par gabarit
Created by: JocelynDelalande
Résoud #578 (closed)
TODO :
-
encaissements : il manque peut-etre la reference a la facture donc le {invoice.official_number} et le code ana {company.code_compta} -
Documenter la troncature du n° de facture -
Doc migration -
Bug à l'export des encaissementsc'était un oubli d'application de migrations sur mon serveur de démo -
Rappel dans le bloc d'aide de bien séparer les champs par des espaces -
Initialiser en config les gabarits de chaque type -
Faire le ménage dans le code Mort des modules devenus custom -
utiliser les templates en config plutôt qu'en attribut des classes des modules -
documenter les variablesdispo dans l'interface (cf liste #578 (closed) ) -
ajouter (ou documenter) toutes les variables listées en #578 (closed) -
VENTES :
-
{CODE_ANA} -
{NOM_CLIENT} -
{NUM_FACT_SMALL}pas de format de n° de facture commun, vu que fortement configurable (#577 (closed))
-
-
ACHATS DETAILLES :
-
{NUM_FACT} -
[ ] {NOM_FRN} (nom fournisseur)on a pas cette info dans autonomie -
{MOTIF_ACHAT}
-
-
ACHATS REGROUPES :
-
[ ] {NUM_PIECE_JOURNAL}notion inexistante pour autonomie
-
-
FRAIS DETAILLES :
-
{MOTIF_FRAIS} -
{MOIS}{AN} -
{NOM_ES}
-
-
FRAIS REGROUPES :
-
[ ] {NUM_PIECE_JOURNAL}notion inexistante pour autonomie
-
-
ENCAISSEMENTS :
-
{CODE_ANA} -
{NOM_CLIENT} -
{NUM_FACT_SMALL}pas de format de n° de facture commun, vu que fortement configurable (#577 (closed))
-
-
REMISES DE CHEQUES :
-
{NUM_REMISE}
-
-
chrono facture -> c'est en fait le n° de facture complète, pour la même raison que NUM_FACT_SMALL -
code analytique enseigne -
nom client -
code client
-
-
gérer une stratégie de troncature sur les libellés -
gérer la taille de troncature des libellés en conf -
validation du contenu de la config (nombre positif) -
documenter le fait qu'on tronque (idéalement, en help text du champ de formulaire).
Questions :
❓ OK si on privillégie les variables « natives » aux alias ?
Pour les modules custom (déjà configurables par gabarit de libelle), on pouvait écrire {num_facture}
.
Je propose qu'on s'en tienne à une version plus proche des noms « natifs » : {invoice.official_number}
. Bien sûr, on documente les variables utiles listées dans #578 (closed).
Il faudrait alors penser à ré-écrire (migrer) la config des modules custom en conséquence
❓ Quels gabarits doivent-être disponibles ?
Je suis parti sur un gabarit configurable pour chacun des modules suivants:
-
Facturation -
Contribution -
RG Interne -
RG Client -
Frais -
Paiement -
Renomme Renomme Payment.remittance_amount -
TVA?https://github.com/CroissanceCommune/autonomie/issues/578#issuecomment-400566214
(+ les modules custom, qui étaient déjà configurables).
Est-ce ok avec ce niveau de détail ?