Skip to content

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 encaissements c'é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:

(+ les modules custom, qui étaient déjà configurables).

Est-ce ok avec ce niveau de détail ?

Merge request reports