Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

windev et les bases sql

14 réponses
Avatar
Jacques TREPP
Bonjour,
juste une question concernant les bases de type sql (postgresql, mysql, etc)
ces bases n'acceptent pas des colonnes tableau, contrairement à HF.
Dans le cas de logiciels de gestion, c'est très pratique (hors taxes, tva,
familles, etc.)

je me retrouve avec des déclarations de tables du genre :
base_exo numeric(10,2) NOT NULL DEFAULT 0,
base_ht1 numeric(10,2) NOT NULL DEFAULT 0,
base_ht2 numeric(10,2) NOT NULL DEFAULT 0,
base_ht3 numeric(10,2) NOT NULL DEFAULT 0,
base_ht4 numeric(10,2) NOT NULL DEFAULT 0,
taux_tva1 numeric(10,2) NOT NULL DEFAULT 0,
taux_tva2 numeric(10,2) NOT NULL DEFAULT 0,
taux_tva3 numeric(10,2) NOT NULL DEFAULT 0,
taux_tva4 numeric(10,2) NOT NULL DEFAULT 0,
tva_tva1 numeric(10,2) NOT NULL DEFAULT 0,
tva_tva2 numeric(10,2) NOT NULL DEFAULT 0,
tva_tva3 numeric(10,2) NOT NULL DEFAULT 0,
tva_tva4 numeric(10,2) NOT NULL DEFAULT 0,
taux_remise1 numeric(10,2) NOT NULL DEFAULT 0,
taux_remise2 numeric(10,2) NOT NULL DEFAULT 0,
taux_remise3 numeric(10,2) NOT NULL DEFAULT 0,
taux_remise4 numeric(10,2) NOT NULL DEFAULT 0,
taux_remise5 numeric(10,2) NOT NULL DEFAULT 0,
mt_remise1 numeric(10,2) NOT NULL DEFAULT 0,
mt_remise2 numeric(10,2) NOT NULL DEFAULT 0,
mt_remise3 numeric(10,2) NOT NULL DEFAULT 0,
mt_remise4 numeric(10,2) NOT NULL DEFAULT 0,
mt_remise5 numeric(10,2) NOT NULL DEFAULT 0,

On peut bien sur utiliser un varchar, et écrire tous les chiffres
(verschaine) avec un séparateur genre pipe '|', et décompacter à la lecture.
c'est ce que je fais avec des chaines, mais ça m'embête avec des chiffres.

Comment faites-vous, sachant que l'indirection ne fonctionne pas :
avec sqlmanagerX, l'indirection : {"ETFAC:m_mt_remise"+1} n'est pas reconnue
?

Merci

--
Jacques TREPP
Albygest
3, rue Jean Mermoz
81160 ST-JUERY
(enlevez 'pasdespam' pour me joindre)

4 réponses

1 2
Avatar
Jerome PAULIN
> Bonjour,

Par principe, je ne stocke pas les données de bases (teux de TVA) dans
les autres tables (ligne de facture) pour :

Raisons écologique, cette données est redondante.
Raisons de maintenance des données, le taux est stocké une seule
fois, donc si le comptable oubli de changer le taux on peut
théoriquement avoir de lignes de TVA avec le mauvais taux.
Raisons de maintenance de l'application, le taux étant stocké une
seule fois, il y a moins de risque d'erreur (taux de TVA dans les lignes
commandes ? taux de TVA dans les lignes des livraisons des expéditions ?
...)





Salut,

J'étais parti sur le même principe que toi (recalculer les données de
pied de facture au besoin), mais je suis en train de tout modifier pour
cause de problèmes d'arrondi lors de l'exportation des données vers la
comptabilité (notamment à cause des remises à la ligne, et du fait que
l'on peut avoir plusieurs taux de tva sur une même facture).
Mes données sont accédées par plusieurs langage/systèmes, qui n'ont pas
l'air de calculer de la même manière (Delphi / Rave Reports / procédures
stockées FIREBIRD et Windev via SQLManagerX).

gg
Avatar
Jacques TREPP
"Firetox" a écrit dans le message de
news:48e46abb$0$3881$
Bonjour, jacques

comme le dit moua le stockage de la tva dans la facture fait une
redondance d'information
j'ai pris pour habitude de stocker dans la facture toutes les infos liées
a la facture et qui permettent de la recréer ou de la rééditer sans relire
le taux de tva qui a pu changer
je m'explique

le taux de tva est pour ma part dans une table parametre (cela rempli
aussi les combos) donc pour la mise a jour du taux un seul endroit et
toutes les fenetres sont impactées même les combos de selection. par
contre dans la facture je stock le ht le ttc par ligne de produit avec
aussi les remises en valeur. cela permet de réediter la facture a
l'identique meme apres plusieurs années je fais egalement une archive de
l'edition qui permet de réediter la facture telle qu'elle etait si elle
n'est plus dans la base ou si la structure evolue. ce qui est important
n'est pas la valeur du taux de tva mais bien la valeur du ttc (on peut
recalculer le taux tres facilement, mais c'est prendre des risques de
recalculer le ttc tu risque d'avoir des difference entre ce qui est partie
en compta et ton ecran alors qu'en figeant le ttc tu as toujours la bonne
valeur.

de ce fait la tva peut evoluer sans modifier les factures, ni les
archives, seules les nouvelles factures seront impactées. on peut
egalement choisir de recalculer une facture avec les nouveau taux si elle
n'est pas passée en compta : car une fois en compta plus de modif
possible. a ce moment la c'est un update simple des valeurs ttc ( en
jointure sur mes parametres je peux en une seule requete mettre a jours
toutes les lignes de la facture a modifier.)

c'est juste pour nfos de ma façon de fonctionner




Pareil pour moi : il me suffit d'ouvrir la fenètre Imprime_facture en
envoyant l'identifiant de la facture pour ressortir une facture. Aucun
calcul n'est effectué.
J'ai modifié ma base.
j'ai maintenant :
une table principale : factures
4 tables liées avec foreign key:
lignes de facture
règlements
remises
bases ht et tva.
Je suis en train de modifier mon appli en conséquence.

merci

--
Jacques TREPP
Albygest
3, rue Jean Mermoz
81160 ST-JUERY
(enlevez 'pasdespam' pour me joindre)
Avatar
Moua
Firetox a présenté l'énoncé suivant :
Bonjour, jacques

comme le dit moua le stockage de la tva dans la facture fait une redondance
d'information
j'ai pris pour habitude de stocker dans la facture toutes les infos liées a
la facture et qui permettent de la recréer ou de la rééditer sans relire le
taux de tva qui a pu changer
je m'explique

le taux de tva est pour ma part dans une table parametre (cela rempli aussi
les combos) donc pour la mise a jour du taux un seul endroit et toutes les
fenetres sont impactées même les combos de selection. par contre dans la
facture je stock le ht le ttc par ligne de produit avec aussi les remises en
valeur. cela permet de réediter la facture a l'identique meme apres plusieurs
années je fais egalement une archive de l'edition qui permet de réediter la
facture telle qu'elle etait si elle n'est plus dans la base ou si la
structure evolue. ce qui est important n'est pas la valeur du taux de tva
mais bien la valeur du ttc (on peut recalculer le taux tres facilement, mais
c'est prendre des risques de recalculer le ttc tu risque d'avoir des
difference entre ce qui est partie en compta et ton ecran alors qu'en figeant
le ttc tu as toujours la bonne valeur.

de ce fait la tva peut evoluer sans modifier les factures, ni les archives,
seules les nouvelles factures seront impactées. on peut egalement choisir de
recalculer une facture avec les nouveau taux si elle n'est pas passée en
compta : car une fois en compta plus de modif possible. a ce moment la c'est
un update simple des valeurs ttc ( en jointure sur mes parametres je peux en
une seule requete mettre a jours toutes les lignes de la facture a modifier.)

c'est juste pour nfos de ma façon de fonctionner

"Jacques TREPP" a écrit dans le message de news:
48e37904$0$10806$
"Moua" a écrit dans le message de
news:gbvnl4$kuo$
Jacques TREPP a couché sur son écran :
"Firetox" a écrit dans le message de
news:48e3396a$0$6891$
Bonjur, jacques

j'utilise aussi des tables liées :
- pas de probleme de d'indirection sur les colonnes
- je peux mettre plus de 10 valeur sans modifier l'analyse
- les elements n'ayant pas 10 lignes n'occupe pas d'espace sur la
base
bref que des avantages et en plus cela devient plus simple en
programmation

sinon l'inderction fonctionne mais pas en externe
tu peux faire {":nomMembre"} = "Toto" dans la classe mais pas a
l'exterieur

bon dev
@+




Bonjour Frederic,

je comprend ... et je bute sur la réalisation.
Admettons que je crée une table tva_factures dont les colonnes seraient
: id_auto, id_facture, baseht, taux_tva, montant_tva
je peux aller jusqu'à 5 taux de tva :
0 % -> exonéré
2 % -> taux spécial Corse
8% -> taux spécial Corse
5,5 % -> bien connu
19,6% -> encore mieux connu !

Vu que tous les taux ne sont pas utilisés dans la même facture, il faut
que j'ajoute unc colonne id_tva pour retrouver mes petits.
Sachant que le taux 0 qui n'existe pas sera codé à 0 (id_tva =0).
Dans ce cas, ce serait jouable en utilisant une table mémoire cachée:
select id_tva, id_auto, id_facture, baseht, taux_tva, montant_tva from
tva_factures where id_facture = x
suivi d'un pgsql;mysqltable(nreq,tablemémoire)

Est-ce que je vais bien dans le bon sens ?

Merci pour vos conseils



Il faut une table TVA avec un ID et le taux (Pour être plus précis, il
faudrait aussi une notion de date en cas de changement de taux).

Code TVA : Date d'application : Taux
________________________________
0 : 01/01/1998 : 0%
1 : 01/01/1998 : 2%
2 : 01/01/1998 : 8%
3 : 01/01/1998 : 5,5%
4 : 01/01/1980 : 20,6% <----- Changement de taux
4 : 01/01/1998 : 19,6%

Il faut mettre l'ID de la TVA dans la table des lignes de factures. (Pas
le taux)

ID Facture : ID LIGNE : ID TVA : Montant HT ...........
____________________________________________
1 : 1 : 3 : 123 <--- Une ligne à 5,5%
1 : 2 : 4 : 234,50 <--- Une ligne à 19,6%


Il faut une table des entêtes de factures

ID Facture : Date Facture : Id Client ............
_____________________________________________________
1 : 01/10/2008 :


Pour plus de facilité, il faut aussi une table des TVA par facture qui
enregistre le total par ID TVA dans la facture, avec L'ID de la facture
L'ID de la TVA et le total. (On peut avoir plusieurs TVA dans une facture)

ID Facture : ID TVA : Montant HT : Montant TVA
_______________________________________________
1 : 3 : 123 :
1 : 4 : 234,50 :

Le taux de la TVA 4 est retrouvé avec la date de la facture (plusieurs
taux en cours).

Voili, y'a plus ca !!!!!!!!!!





Merci,
la table tva, je l'ai : c'est un truc que je connais assez bien, vu que
j'équipe des hôteliers qui, chacun le sait, ont des régimes de tva assez
Rock'nRoll :
tva sur les pensions calculées à 75% au taux 5.5% et 25% au taux 19.6%, le
tout calculé sur le ttc.

Mon souci était la structure de la table factures.
Si je lis bien ton post, tu confirmes ce que préconise plus haut. Pour
info, je stocke le code tva, mais aussi le taux, justement . ça permet en
cas de changement de taux, de pouvoir ré-imprimer une facture au taux en
vigueur lors de sa création.

Merci encore

-- Jacques TREPP
Albygest
3, rue Jean Mermoz
81160 ST-JUERY
(enlevez 'pasdespam' pour me joindre)





Bonjour,

Je rajoute quelques autres principes de bases :

Les données fondamentales (Montant HT, Montant Remise, Montant
T.V.A., Montant TTC) ne doivent-être calculées que par une seule
procédure/méthode.
Ces données doivent être stockées en l'état, de façon à être
utilisées sans recalcul par les autres
procédures/méthodes/états/requêtes ...
Les régles d'arrondis doivent-être identiques quelque soit
l'application le lanquage ou le SGBRD. Ce n'est pas à eux de faire
l'arrondi qui leur convient. Les régles d'arrondis sont comptables,
administratives, législatives.
Les arrondis sont fait ligne à ligne sur deux décimales, les prix
unitaires peuvent-être sur cinq décimales ou par lot de 10,100,1000,
mais les montants sont arrondis à la deuxième décimale.

Autre chose, si il y a plusieurs taux de T.V.A dans une facture, il
faut que sur chaque ligne produit il y ait un signe distinctif du taux
de T.V.A utilisé (souvent on utilise le code TVA).
Il est aussi plus sympatique pour celui qui reçoit la facture de lui
ajouter le total par taux de TVA avec le même signe distinctif.
Avatar
Jacques TREPP
"Moua" a écrit dans le message de
news:gc4nq9$dlj$
Firetox a présenté l'énoncé suivant :
Bonjour, jacques

comme le dit moua le stockage de la tva dans la facture fait une
redondance d'information
j'ai pris pour habitude de stocker dans la facture toutes les infos liées
a la facture et qui permettent de la recréer ou de la rééditer sans
relire le taux de tva qui a pu changer
je m'explique

le taux de tva est pour ma part dans une table parametre (cela rempli
aussi les combos) donc pour la mise a jour du taux un seul endroit et
toutes les fenetres sont impactées même les combos de selection. par
contre dans la facture je stock le ht le ttc par ligne de produit avec
aussi les remises en valeur. cela permet de réediter la facture a
l'identique meme apres plusieurs années je fais egalement une archive de
l'edition qui permet de réediter la facture telle qu'elle etait si elle
n'est plus dans la base ou si la structure evolue. ce qui est important
n'est pas la valeur du taux de tva mais bien la valeur du ttc (on peut
recalculer le taux tres facilement, mais c'est prendre des risques de
recalculer le ttc tu risque d'avoir des difference entre ce qui est
partie en compta et ton ecran alors qu'en figeant le ttc tu as toujours
la bonne valeur.

de ce fait la tva peut evoluer sans modifier les factures, ni les
archives, seules les nouvelles factures seront impactées. on peut
egalement choisir de recalculer une facture avec les nouveau taux si elle
n'est pas passée en compta : car une fois en compta plus de modif
possible. a ce moment la c'est un update simple des valeurs ttc ( en
jointure sur mes parametres je peux en une seule requete mettre a jours
toutes les lignes de la facture a modifier.)

c'est juste pour nfos de ma façon de fonctionner

"Jacques TREPP" a écrit dans le message de news:
48e37904$0$10806$
"Moua" a écrit dans le message de
news:gbvnl4$kuo$
Jacques TREPP a couché sur son écran :
"Firetox" a écrit dans le message de
news:48e3396a$0$6891$
Bonjur, jacques

j'utilise aussi des tables liées :
- pas de probleme de d'indirection sur les colonnes
- je peux mettre plus de 10 valeur sans modifier l'analyse
- les elements n'ayant pas 10 lignes n'occupe pas d'espace sur la
base
bref que des avantages et en plus cela devient plus simple en
programmation

sinon l'inderction fonctionne mais pas en externe
tu peux faire {":nomMembre"} = "Toto" dans la classe mais pas a
l'exterieur

bon dev
@+




Bonjour Frederic,

je comprend ... et je bute sur la réalisation.
Admettons que je crée une table tva_factures dont les colonnes
seraient
: id_auto, id_facture, baseht, taux_tva, montant_tva
je peux aller jusqu'à 5 taux de tva :
0 % -> exonéré
2 % -> taux spécial Corse
8% -> taux spécial Corse
5,5 % -> bien connu
19,6% -> encore mieux connu !

Vu que tous les taux ne sont pas utilisés dans la même facture, il
faut que j'ajoute unc colonne id_tva pour retrouver mes petits.
Sachant que le taux 0 qui n'existe pas sera codé à 0 (id_tva =0).
Dans ce cas, ce serait jouable en utilisant une table mémoire cachée:
select id_tva, id_auto, id_facture, baseht, taux_tva, montant_tva from
tva_factures where id_facture = x
suivi d'un pgsql;mysqltable(nreq,tablemémoire)

Est-ce que je vais bien dans le bon sens ?

Merci pour vos conseils



Il faut une table TVA avec un ID et le taux (Pour être plus précis, il
faudrait aussi une notion de date en cas de changement de taux).

Code TVA : Date d'application : Taux
________________________________
0 : 01/01/1998 : 0%
1 : 01/01/1998 : 2%
2 : 01/01/1998 : 8%
3 : 01/01/1998 : 5,5%
4 : 01/01/1980 : 20,6% <----- Changement de taux
4 : 01/01/1998 : 19,6%

Il faut mettre l'ID de la TVA dans la table des lignes de factures.
(Pas le taux)

ID Facture : ID LIGNE : ID TVA : Montant HT ...........
____________________________________________
1 : 1 : 3 : 123 <--- Une ligne à 5,5%
1 : 2 : 4 : 234,50 <--- Une ligne à 19,6%


Il faut une table des entêtes de factures

ID Facture : Date Facture : Id Client ............
_____________________________________________________
1 : 01/10/2008 :


Pour plus de facilité, il faut aussi une table des TVA par facture qui
enregistre le total par ID TVA dans la facture, avec L'ID de la facture
L'ID de la TVA et le total. (On peut avoir plusieurs TVA dans une
facture)

ID Facture : ID TVA : Montant HT : Montant TVA
_______________________________________________
1 : 3 : 123 :
1 : 4 : 234,50 :

Le taux de la TVA 4 est retrouvé avec la date de la facture (plusieurs
taux en cours).

Voili, y'a plus ca !!!!!!!!!!





Merci,
la table tva, je l'ai : c'est un truc que je connais assez bien, vu que
j'équipe des hôteliers qui, chacun le sait, ont des régimes de tva assez
Rock'nRoll :
tva sur les pensions calculées à 75% au taux 5.5% et 25% au taux 19.6%,
le tout calculé sur le ttc.

Mon souci était la structure de la table factures.
Si je lis bien ton post, tu confirmes ce que préconise plus haut. Pour
info, je stocke le code tva, mais aussi le taux, justement . ça permet
en cas de changement de taux, de pouvoir ré-imprimer une facture au taux
en vigueur lors de sa création.

Merci encore

-- Jacques TREPP
Albygest
3, rue Jean Mermoz
81160 ST-JUERY
(enlevez 'pasdespam' pour me joindre)





Bonjour,

Je rajoute quelques autres principes de bases :

Les données fondamentales (Montant HT, Montant Remise, Montant T.V.A.,
Montant TTC) ne doivent-être calculées que par une seule
procédure/méthode.
Ces données doivent être stockées en l'état, de façon à être utilisées
sans recalcul par les autres procédures/méthodes/états/requêtes ...
Les régles d'arrondis doivent-être identiques quelque soit l'application
le lanquage ou le SGBRD. Ce n'est pas à eux de faire l'arrondi qui leur
convient. Les régles d'arrondis sont comptables, administratives,
législatives.
Les arrondis sont fait ligne à ligne sur deux décimales, les prix
unitaires peuvent-être sur cinq décimales ou par lot de 10,100,1000, mais
les montants sont arrondis à la deuxième décimale.

Autre chose, si il y a plusieurs taux de T.V.A dans une facture, il faut
que sur chaque ligne produit il y ait un signe distinctif du taux de T.V.A
utilisé (souvent on utilise le code TVA).
Il est aussi plus sympatique pour celui qui reçoit la facture de lui
ajouter le total par taux de TVA avec le même signe distinctif.





Absolument d'accord avec toi. Les règles d'arrondi sont quelques fois
complexes, à cause du fait qu'on facture en ttc.
Je fais en sorte de stocker les montants ttc, ht, dans le détail de manière
à n'avoir aucun calcul lors d'une ré-impression de facture.
Par contre, il n'est pas rare qu'un client rouspète parce qu'une facture de
2 lignes soit longue à cause du récap des tva, de l'entète, et la liste des
règlements.
Mais bon : c'est ça, le show-biz ;)

Merci pour ton intervention

--
Jacques TREPP
Albygest
3, rue Jean Mermoz
81160 ST-JUERY
(enlevez 'pasdespam' pour me joindre)
1 2