Discussion :

[clavier12AZQSWX]

bonjour,

je me trouve face à un probleme, que j'illustre par un exemple simple :

mon application fait des factures et offre la possibilité au client de les avoir soit en pdf généré à la volée (sur clic à l'écran) soit de les avoir à l'écran en simple données affichées en html via la BDD (et non pas un pdf2txt..).

le problème :
si mon prestataire change son nom, les factures changent aussi (pdf généré à la volée) et données à l'écran (car dynamisme base de données relationnelles..Etc)
si l'orthographe des produits vendus changent, alors les factures aussi...
si un taux de tva d'un produit change, la facture change....
si le client vient changer son adresse, sa facture change aussi...

comment gérer ces problèmes au niveau relationnel ? comment font les erp sage, ciel, idylis..Etc pour gérer les données une fois la facture validée.
que dit la loi sur les infos qui sont autorisées à changer ou pas dans une facture validée-archivée ?

faut-il dans la table facture avoir un duplicata incheangeable des données servant à la facture à l'instant de la validation ?
faut-il garder le fichier pdf validée et toujours offir celui-là ? si oui (pdf archivé et réutilisé), qu'en-est-il des données à l'écran (qui différont du pdf!)

qu'en pensez-vous ?

[chewing-gum]

Bonjour,

c'est une bonne question et j'ai donc cherché un peu sur ce forum.
Tu as ta réponse (peut-être partielle) ici :

http://www.developpez.net/forums/d54...s/#post3226292
Mais du coup, ta base de données risque de pas mal changer.


Et les factures doivent être conservées un certain nombre d'années (10 ans je crois).

[clavier12AZQSWX]

bonjour,

merci de votre réponse mais la solution de l'historisation est trop conséquente je trouve.

j'ai testé dans un grand erp en ligne, et en changeant le nom d'un client, ça change la facture...
après interrogation d'un comptable,il est de la charge du prestataire de garder une version de la facture. Donc typiquement ça veut dire que le soft a beau être capable de générer une facture, c'est de la responsabilité du presta d'en garder une image de celle qu'il a fourni au client.
donc si le soft fait une facture pdf en temps réel, bun faut garder le pdf et vite le transmettre au comptable dès que le client l'a aussi !

cdt

[clavier12AZQSWX]

si quelqu'un a la main sur un ciel ou un sage ou unebp, ce serait intéressant de tester de changer le nom d'un client qui a déjà une facture....

[Tidus159]

Bonjour,

je ne comprends pas vraiment le problème.
Si dans une table spécifique de ta base, tu gardes toutes les données que tu as besoin sur ta facture (nom client, produits, total, etc.) - ce n'est pas de la redondance mais simplement de la copie pour garder en mémoire - tu pourras nécessairement recréer ta facture autant de fois que tu le veux...
C'est sur qu'une facture ne doit pas être modifiée...

@+,
Tidus.

[annickl]

Bonjour,

Réponse un peu tardive, mais puisque cela ne semble pas résolu :

- les données d'une facture validée et archivée doivent effectivement être immuables, et conservées -> nécessité de stocker les données ayant servi à générer la facture
- il n'est pas nécessaire de stocker les PDF dans la mesure où le système peut les regénérer .

Les progiciels que je connais (Sage, Ekip, Oracle App) gèrent une donnée "Statut" qui peut avoir trois ou quatre états dont : validé, à l'étude, annulé.

Sage offre en plus la possibilité de "dévalider" une facture, lorsque l'exercice comptable n'est pas cloturé informatiquement (très utile!). Dans ce cas, il est nécessaire de prévoir un statut supplémentaire "archivé", qui empêche l"invalidation. Accessoirement on peut prévoir ensuite toutes les données utiles pour la gestion de ces modifications unitaires : qui, à quelle date, pour quelles raisons.

Pour reprendre l'exemple des modifications des taux de TVA, le plus courant est d'affecter des dates de validité à chaque type de taux. Dans ce cas, il suffit de stocker le type de TVA s'appliquant (exonéré, taux réduit, taux coutant, etc...) et le taux est recalculé à partir de la date de la facture. En complément, la table des taux peut comprendre une zone géographique pour distinguer les taux à appliquer à l'exportation. Pour optimiser les accès, une table entière de taux est recréée à chaque modification, même s'il la modification ne concerne qu'un seul des taux. Cela permet d'entrer en direct par la date, sans aller rechercher dans chaque type de taux l'historique.

Si les factures sont volumineuses (comportant de nombreux articles, avec des libellés longs) on peut raisonner de la même façon avec les références, le stockage ne concernant alors qu'un numéro de référence que l'on ira retrouver en fonction de sa date de validité.


Annickl

[Richard_35]

Bonjour à tous,

le problème :
si mon prestataire change son nom, les factures changent aussi (pdf généré à la volée) et données à l'écran (car dynamisme base de données relationnelles..Etc)
si l'orthographe des produits vendus changent, alors les factures aussi...
si un taux de tva d'un produit change, la facture change....
si le client vient changer son adresse, sa facture change aussi...

==> tu l'as dit : c'est un problème et, donc, effectivement, ce n'est pas normal.

j'ai testé dans un grand erp en ligne, et en changeant le nom d'un client, ça change la facture...

==> cet ERP est donc à éviter... car, s'il existe une telle erreur de conception, alors on peut craindre d'autres anomalies moins visibles.

Sage offre en plus la possibilité de "dévalider" une facture, lorsque l'exercice comptable n'est pas cloturé informatiquement (très utile!).

==> Imaginons :
la facture n° 123 est émise, envoyée au client A ;
la facture n° 123 est "dévalidée" ;
une facture est émise, juste après, et envoyée au client B.
==> quel est le numéro attribué à la facture du client B ? 123 ou 124 ?
Il me semble qu'il est obligatoire de respecter une continuité dans la numérotation.
D'autre part, à ma connaissance, le seul moyen légal "d'annuler" une facture, c'est la génération d'un avoir toujours dans la continuité de la numérotation. A noter, qu'il peut s'agir d'avoir "interne" pour une "annulation interne" à la société émettrice.

je ne comprends pas vraiment le problème.
Si dans une table spécifique de ta base, tu gardes toutes les données que tu as besoin sur ta facture (nom client, produits, total, etc.) - ce n'est pas de la redondance mais simplement de la copie pour garder en mémoire - tu pourras nécessairement recréer ta facture autant de fois que tu le veux...
C'est sur qu'une facture ne doit pas être modifiée...

==> approuvé à 100%.

En fait, nous parlons "d'héritage" de données à une date donnée : le cahier des charges impose, en quelque sorte, une copie des données à l'édition de la facture.

Il vaut mieux copier, exhaustivement, toutes les données de la factures dans les tables "Facture entête/pied" (nom client, adresse, montant HT, etc... ) et "Facture détail" (code produit, libellé produit, etc...).

Concrètement, dans le développement, cela consiste à :
- créer les enregistrements qui vont bien dans les tables "Facture entête/pied" et "Facture détail" ;
- développer l'état à partir de ces tables.
==> de ce fait, la ré-édition de facture ne nécessite pas un re-développement, et toutes les données d'une facture "temps réel" sont archivées.

En MCD, cela donne :

Entité Client
- Id_Client (PK)
- Nom
...

Entité Produit
- Id_Produit (PK)
- Nom
...

Entité Facture_Entete_Pied
- Id_Numero_Facture (PK)
- Id_Client
- Nom_Client
- Date_facture
...

Entité Facture_Detail
- Id_Numero_Facture (PK)
- Id_Numero_Ligne (PK)
- Id_Produit
- Libelle_Produit
- Quantité_facturée
...

Relations
Client ---(0,n)---[possède]---(1,1)--- Facture_Entete_Pied ;
Facture_Entete_Pied ---(1,n)---[est composée]---(1,1)--- Facture_Detail ;
Produit ---(0,n)---[est concerné]---(1,1)--- Facture_Detail.