Discussion :

[chamz93]

Bonjour,

Je réalise un logiciel en C++ et SQLite dit "logiciel caisse" avec gestion d'articles/stock, et j'aimerais avoir une structure propre et cohérente.
On me demande, de prendre en compte le fait qu'une transaction peut contenir différente TVA, et qu'elle puisse être payé par différent mode de paiement si nécessaire (une partie en espèce et le reste en CB, par exemple).
J'ai prévu pour chaque table qui contient des montants/tva d'ajouter deux colonne: Checksum et Signature pour chaîner une transaction ajoutée avec la précédente pour être conforme avec la loi anti fraude TVA, qui d'après ce que j'ai pu lire ne nécessite pas une expertise tant que je donne une attestation individuelle certifiant le respect des conditions.

J'ai déjà fait il y a un moment un logiciel similaire dont j'aimerais prendre la même structure mais il y avait seulement une seule TVA à gérer, il me semble que le hors taxe de chaque tva doit être enregistrer, de ce fait je ne peux créer de colonne avec comme nom la valeur de la tva car si elle venait à changer dans le temps ce serait trop confus.



Précisions:
- Les colonnes ont un préfixe suite a des erreurs côté framework dû aux colonnes de même nom des tables ayant des relations.
- Le checksum est le hash, de chaque colonne et du checksum de la transaction précédente.
- La signature du checksum est faite par la clé privée du logiciel.
- Je compte vérifier à chaque démarrage du logiciel les checksum des tables et leurs signatures.

Questions:
- Devrais-je faire une table pour mieux gérer les différents type de paiements par transactions au lieu des colonnes paiement1 et paiement2?
- Devrais-je faire une table qui enregistre les montants hors taxes par tva?
- Chaque transactions enregistrées imprime un ticket qui est réalisé en html, devrais-je stocker le ticket par: fichier dans des dossiers, directement en base de donnée ou juste enregistrer chaque valeurs inséré dans l'html du ticket avant impression suffirais?
- En cas de mise à jour des tables contenant des checksums, par exemple ajouter une nouvelle colonne plus tard je devrais forcément actualiser les checksums, est-ce problématique?

En espérant avoir posté dans la bonne rubrique, je suis preneur de toute remarque et retour d'expériences, que ce soit pour les structures, l'inaltérabilité, optimisations...

Merci d'avance

[escartefigue]

Bonsoir chamz93,

J'ai déjà fait il y a un moment un logiciel similaire dont j'aimerais prendre la même structure mais il y avait seulement une seule TVA à gérer, il me semble que le hors taxe de chaque tva doit être enregistrer, de ce fait je ne peux créer de colonne avec comme nom la valeur de la tva car si elle venait à changer dans le temps ce serait trop confus.

Il y a des lustres que je n'ai pas eu à travailler sur ce genre de sujet, mais, de mémoire, il faut être en capacité de restituer tous les éléments liés à la facturation au moment où la facture a été établie
Ce qui signifie que
- soit vous stockez à la fois le montant HT, le montant TVA, le taux TVA et le montant TTC pour chaque ligne ;
- soit (mais je n'en suis pas certain, à vérifier donc) vous stockez le montant HT et un identifiant de TVA puis, grâce à cet identifiant et à la date de la facture, vous êtes en capacité de retrouver le taux grâce à une table des taux à date.

Précisions:
- Les colonnes ont un préfixe suite a des erreurs côté framework dû aux colonnes de même nom des tables ayant des relations.

C'est plutôt pratique d'affecter un préfixe ou un suffixe à chaque table et de retrouver celui-ci dans chaque colonne de cette table.
Par contre, il est également beaucoup plus pratique d'utiliser le même nom de colonne dans la table où un attribut est FK que celui de la table d'où cet attribut est hérité.
Exemple (PK en gras, FK suffixées #) :
CL_CLIENT(CL_ident, CL_numero, CL_dtcrea...)
FA_FACTURE(FA_ident, FA_date, CL_ident#...) <-- on sait d'emblée que la FK CL_ident provient de la table CL_CLIENT
LF_LIGNE_FAC(FA_ident#, LF_ident, LF_qte, AR_ident#) <-- on sait d'emblée que la PK est composée d'une part de la FK FA_ident issue de la table FA_FACTURE et d'autre part d'un identifiant propre, on sait également que la FK AR_ident provient de la table AR_ARTICLE
AR_ARTICLE(AR_ident, AR_reference, AR_libelle...)

- Le checksum est le hash, de chaque colonne et du checksum de la transaction précédente.
- La signature du checksum est faite par la clé privée du logiciel.
- Je compte vérifier à chaque démarrage du logiciel les checksum des tables et leurs signatures.

Je suis ignare en la matière, mais sur le dernier point ça me semble complètement aberrant : imaginez le travail considérable à accomplir quand la BDD aura vécu quelques années et comportera des centaines de milliers de factures, voire plus

Questions:
- Devrais-je faire une table pour mieux gérer les différents type de paiements par transactions au lieu des colonnes paiement1 et paiement2?
- Devrais-je faire une table qui enregistre les montants hors taxes par tva?
- Chaque transactions enregistrées imprime un ticket qui est réalisé en html, devrais-je stocker le ticket par: fichier dans des dossiers, directement en base de donnée ou juste enregistrer chaque valeurs inséré dans l'html du ticket avant impression suffirais?

Raisonner sur les tables c'est réfléchir sur le "comment". Ce n'est pas la bonne approche.
Il faut d'abord décrire le "quoi" c'est à dire les objets de gestion (factures, types de paiement, modalités de paiement etc.) et leurs interactions
À partir de la, on rédige les règles de gestion qui permettent de produire un MCD dont on dérivera automatiquement un MLD grâce aux nombreux logiciels de modélisation dont certains sont gratuits
On pourra directement produire le MLD dans les cas les plus simples

[chamz93]

Bonsoir,

Il y a des lustres que je n'ai pas eu à travailler sur ce genre de sujet, mais, de mémoire, il faut être en capacité de restituer tous les éléments liés à la facturation au moment où la facture a été établie
Ce qui signifie que
- soit vous stockez à la fois le montant HT, le montant TVA, le taux TVA et le montant TTC pour chaque ligne ;
- soit (mais je n'en suis pas certain, à vérifier donc) vous stockez le montant HT et un identifiant de TVA puis, grâce à cet identifiant et à la date de la facture, vous êtes en capacité de retrouver le taux grâce à une table des taux à date.

Les tables dans l'image sont uniquement liée a la transaction, j'ai aussi celle des articles, et aussi une table des TVA, car bien entendu chaque article à une TVA et ça me permet de facilement mettre à jour en cas de changement.
En tout cas, je ne pourrais pas tout garder sur une même table, je veux dire je ne peux pas mettre une colonne dans "transactions" nommé "montant_tva_20" je pense qu'il va de soit de faire une table "transactions_tva" par exemple qui chaque ligne aura un taux de tva, le montant de la tva sur la somme ttc des articles ayant le même taux et l'id de la transaction concernée. Après est-ce normal d'avoir des informations dîtes comptable éparpillé dans plusieurs tables, ça je ne sais pas.

C'est plutôt pratique d'affecter un préfixe ou un suffixe à chaque table et de retrouver celui-ci dans chaque colonne de cette table.
Par contre, il est également beaucoup plus pratique d'utiliser le même nom de colonne dans la table où un attribut est FK que celui de la table d'où cet attribut est hérité.

Effectivement, mais j'ai toujours été habitué de mettre les tables sans préfixe, et uniquement les colonnes si un problème ce posais mais je reconnais que ce serais pratique!

Je suis ignare en la matière, mais sur le dernier point ça me semble complètement aberrant : imaginez le travail considérable à accomplir quand la BDD aura vécu quelques années et comportera des centaines de milliers de factures, voire plus

La loi depuis 2018 impose l'inaltérabilité, de haut et bas niveau, je me demandais donc si c'était utile pendant le "splashscreen" de l'application de vérifier les signatures pour que, en cas échéant je mentionne que la base de donnée est corrompue, ça ferais une couche supplémentaire de sécurité. Je reconnais que selon le nombre de ligne en base de données sur des années pourrais prendre plusieurs secondes à être traitées. Sinon je peux aussi faire pour l'année en cours uniquement, ou lors d'exportation de donnée d'une période choisie.

Raisonner sur les tables c'est réfléchir sur le "comment". Ce n'est pas la bonne approche.
Il faut d'abord décrire le "quoi" c'est à dire les objets de gestion (factures, types de paiement, modalités de paiement etc.) et leurs interactions

C'est pas faux, notamment pour les deux nouvelles tables, mais concernant l'html c'est plus sujet à réflexion car passer d'un stockage html (que ce soit sur disque ou BDD), à une table avec juste les valeurs, ça change totalement la taille du stockage utilisé, et comme vous avez dit plus haut, sur des années ça peut être contraignant.


Merci pour votre réponse rapide, vous avez souligné certains points intéressants.

Je reste ouvert également pour d'autre avis

[Paprick]

Bonjour,

Raisonner sur les tables c'est réfléchir sur le "comment". Ce n'est pas la bonne approche.
Il faut d'abord décrire le "quoi" c'est à dire les objets de gestion (factures, types de paiement, modalités de paiement etc.) et leurs interactions
À partir de la, on rédige les règles de gestion qui permettent de produire un MCD dont on dérivera automatiquement un MLD grâce aux nombreux logiciels de modélisation dont certains sont gratuits

Je rejoins l'avis de notre imminent expert escartefigue : avant de s'embarquer dans des considérations techniques, il est essentiel de réaliser le modèle conceptuel de données.
Parmi les logiciels que je connais : Win'Design, PowerAMC, JMerise, Looping (et il en existe bien d'autres) => cf. discussion Quel logiciel télécharger pour réaliser un MCD

Une fois la phase de conception parfaitement effectuée, passer au niveau logique puis physique pose rarement de problèmes, si ce n'est des histoires d'optimisations propres au SGBD.