Discussion :

[fsmrel]

Hello seabs,

Je n’ai pas bien compris votre explication

C’est la conséquence d’un quiproquo…
En effet, votre MCD contient une entité-type "Plan", en conséquence de quoi, j’ai cru qu’il s’agissalt du plan comptable (ses propriétés générales, à savoir sans les lignes), alors qu’au vu de votre message précédent, une écriture détermine une ligne de plan. Si c’est bien cela, pour éviter toute confusion j’interpréterai l’entité-type "Plan", comme ligne de plan, auquel cas elle serait à renommer en "PlanLigne", ou quelque chose de ce genre.


A cette occasion, j’ai relu votre 1er message :

P01 Un dossier comporte obligatoirement un plan comptable
P02 Un plan comptable ne peut pas être commun, il doit être attaché à un seul dossier

Règles que j’interprète ainsi dans le style de Merise ::

P01 Un dossier comporte au moins et au plus un plan comptable
P02 Un plan comptable est attaché à au moins et au plus un seul dossier [/quote]

Mais si on renomme l’entité-type "Plan" en "PlanLigne", il n’y a plus d’entité-type "Plan", et en vertu de P01 et P02 elle serait donc à créer. ça devient scabreux...
Votre position ?

[escartefigue]

Par contre, pourrais-tu me donner ton avis, pour l'ensemble de mon MCD, et notamment les points à corriger avant de passer à la création de la base.

Je vois que Fsmrel et Paprick ont veillé au grain, le sujet est donc entre de bonnes mains

Je n'ai donc parcouru que superficiellement la discussion, mais, sauf erreur de ma part, je ne vois pas la notion de compte comptable, élément incontournable de la comptabilité.

À ce sujet, la TVA se répartit dans différents comptes comptables (TVA collectée sur les ventes, TVA déductible sur achats...).
Par ailleurs, le taux de TVA est fonction de la date de l'opération et de la localisation (les ventes à l'étranger sont sans TVA et les DOM-TOM bénéficient de taux réduits).
Il me semble donc plus approprié de ne pas associer le taux à chaque écriture.

Par ailleurs, l'attribut Ecr_Mode_Paie, s'il s'agit du mode de paiement, ne doit pas être porté par le type d'entité [ECRITURE], car la plupart des écritures ne sont pas concernées.

Je lis régulièrement tes interventions dans cette rubrique, mais avec l'arrivée de l'IA, il semble que le forum a perdu une partie de son activité. Dommage !

Je le déplore aussi, l'IA ne fait pas tout, loin s'en faut, les quelques essais que j'ai fait concernant la modélisation des données ne m'ont guère convaincu.

[seabs]

Bonjour fsmrel,

En effet, votre MCD contient une entité-type "Plan", en conséquence de quoi, j’ai cru qu’il s’agissait du plan comptable, etc.

Effectivement, votre remarque est pertinente pour un lecteur dont la comptabilité n’est pas sa tasse de thé. Dans le jargon du milieu comptable, la dénomination « Plan » sous-entend le détail des comptes. J’ai donc modifié l’entité « Plan » qui devient « Num_Compte ».

Mais si on renomme l’entité-type "Plan" en "PlanLigne", il n’y a plus d’entité-type "Plan", et en vertu de P01 et P02 elle serait donc à créer. ça devient scabreux...

L’entité-type « Plan » n’est absolument pas nécessaire. La dénomination d’un plan est l’ensemble des trois entités suivantes.

• Classe_Comptable ;
• Sous_Classe_Comptable ;
• Num_Compte

Dans le but de préciser les choses, je remets un extrait, lequel présente une partie (très faible) d’un plan comptable.

• 6 = classe ;
• 61 = sous-classe ;
• 611 = Compte = Num_Compte

À partir de la 4éme position, le compte est complété par des zéros pour atteindre le nombre de positions prévues. En général, de 6 à 8 positions. L’ensemble sera piloté par un trigger ou une procédure stockée SQL pour ajouter automatique le nombre de zéros nécessaires.
Par contre, l’opérateur a la possibilité de créer des subdivisions pour les besoins complémentaires. Exemple, il pourra créer un compte : 621 450 – Personnel prêté à l’usine B.
Il faut reconnaître, dans le cas présent, mon manque de précision. Quand les éléments me sont évidents, il m’arrive de créer des raccourcis.

Ci-dessous, la présentation partielle rectifiée.


Encore merci pour tes remarques. Il me semble préférable de présenter un travail compréhensible pour tous les lecteurs et pas seulement par moi.

A plus.

[seabs]

Bonjour escartefigue,

Je vois que Fsmrel et Paprick ont veillé au grain, le sujet est donc entre de bonnes mains

Sur ce point, je n’ai aucun souci pour leur niveau de compétences. Je lis très souvent ce forum, et je remarque que votre trio apporte toujours des précisions utiles voire indispensables.

Je n’ai donc parcouru que superficiellement la discussion, mais, sauf erreur de ma part, je ne vois pas la notion de compte comptable, élément incontournable de la comptabilité.

Pour la réponse, voir le message précédent que je viens poster.

Par ailleurs, l’attribut Ecr_Mode_Paie, s’il s’agit du mode de paiement, ne doit pas être porté par le type d’entité [ECRITURE], car la plupart des écritures ne sont pas concernées

La dénomination n’était pas pertinente, j’ai modifié « Ecr_Operat ». Il me semble opportun de fournir, pour chaque écriture, un symbole pour visualiser d’un seul coup d’œil les écritures identiques dans un journal.
Les différentes possibilités peuvent-être : Achat, Virt, chq n°, etc. Il sera peut-être approprié de créer une entité avec ces dénominations pour améliorer la saisie et d’inclure le choix par un simple clic. (à étudier)

À ce sujet, la TVA se répartit dans différents comptes comptables (TVA collectée sur les ventes, TVA déductible sur achats…).

Ce sujet est développé dans les règles de gestion — Schéma des écritures. J’ai fait ce choix pour permettre une centralisation des écritures en fin de journal Achats et Ventes. Il est toujours possible de ne pas utiliser cette option dans les journaux de trésorerie. Dans ce cas, l’écriture sera scindée sur 2 lignes.
Il faut savoir que la comptabilité que je développe s’adresse pour l’essentiel à des associations ou des microentreprises, lesquelles ont peu de moyen et seulement des notions comptables. Le cercle est restreint, mais, dès qu’il se dirige vers des logiciels plus professionnels, le coût pour ces associations ou ces personnes devient vite prohibitif.
Mon objectif est de présenter, à partir de cette comptabilité, en automatique, le bilan et le compte de résultat. La réalisation de ces deux derniers documents à partir de tableaux établis sur Excel présente souvent une acrobatie sans filet, surtout pour l’ajustement des derniers centimes, euros ou centaines d’euros.
Pour les entreprises ayant une organisation, il existe sur les marchés des logiciels adaptés. Enfin, d’après le vendeur, car dans la pratique, c’est parfois assez soyeux aussi.
Exemple vécu – Comptabilité dans ERP SAP avec une seule colonne. Pour distinguer le débit du crédit, il était obligatoire d’insérer le signe + ou le signe – avant de saisir la valeur. Bonjour le travail

Merci pour tes remarques.

A plus.

[fsmrel]

Bonjour seabs,

Merci pour les précisions que vous avez fournies, j’y vois plus clair

Je reviens sur les règles de gestion :

P01 Un dossier comporte obligatoirement un plan comptable
P02 Un plan comptable ne peut pas être commun, il doit être attaché à un seul dossier

Mais par référence au post du 28 juillet (post #16) :

https://www.developpez.net/forums/d2.../#post12127308

la situation est la suivante :

[Dossier]------1,n----(definir)----0,n----[Num_Compte]

En conséquence de quoi la règle P02 ne serait-elle pas à aménager ?

Sinon, on tendrait vers :

[Dossier]------1,n----(definir)----1,1----[Num_Compte]

[seabs]

Bonjour fsmrel,

En conséquence de quoi la règle P02 ne serait-elle pas à aménager ?
Sinon, on tendrait vers :
[Dossier]------1,n----(Utiliser)----1,1----[Num_Compte]

Effectivement, c'est cette association qu'il faut retenir. J'ai remplacer « Definir » par « Utiliser ».
Comme souvent, une ânerie de ma part.

Merci pour cette correction.
A plus.

[fsmrel]

Salve vaillants seabs et escartefigue !

Avec la correction on a donc :

[Dossier]------1,n----(Utiliser)----1,1----[Num_Compte]

Quel inconvénient à considérer qu’un compte est en l’occurrence une propriété multivaluée d’un dossier ?

La situation deviendrait alors la suivante (identification relative) :

[Dossier]------1,n----(Utiliser)----1,1(R)----[Num_Compte]

Comme j’y ai fait allusion dans le post #13, il existe un cycle pour "aller" de Dossier à Num_Compte puisqu’on a aussi le chemin :

Dossier > Journal > Exercice > Ecriture > Num_Compte

Si on utilise à fond l’identification relative :

[Dossier]--1,n--()--1,1(R)--[Journal]

[Journal]--1,n--()--1,1(R)--[Exercice]

[Exercice]--1,n--()--1,1(R)--[Ecriture]

Alors Looping produira par exemple le code suivant :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE Ecriture(
   Dos_Id INTEGER,
   Jal_Id SMALLINT,
   Exe_Debut DATE,
   Ecr_Id INTEGER,
   Ecr_Montant NUMERIC(15,2) NOT NULL,
   Ecr_Date DATE NOT NULL,
   Dos_Id_1 INTEGER NOT NULL,
   Num_Cpte INTEGER NOT NULL,
   CONSTRAINT Ecriture_PK PRIMARY KEY(Dos_Id, Jal_Id, Exe_Debut, Ecr_Id),
   CONSTRAINT Ecriture_Exercice_FK FOREIGN KEY(Dos_Id, Jal_Id, Exe_Debut) REFERENCES Exercice(Dos_Id, Jal_Id, Exe_Debut),
   CONSTRAINT Ecriture_Num_Compte_1_FK FOREIGN KEY(Dos_Id_1, Num_Cpte) REFERENCES Num_Compte(Dos_Id, Num_Cpte)
);

Code dans lequel l’attribut Dos_Id est présent deux fois (Dos_Id, Dos_Id_1).
Il suffit de remplacer par (en virant Dos_Id_1) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE Ecriture(
   Dos_Id INTEGER,
   Jal_Id SMALLINT,
   Exe_Debut DATE,
   Ecr_Id INTEGER,
   Ecr_Montant NUMERIC(15,2) NOT NULL,
   Ecr_Date DATE NOT NULL,
   Num_Cpte INTEGER NOT NULL,
   CONSTRAINT Ecriture_PK PRIMARY KEY(Dos_Id, Jal_Id, Exe_Debut, Ecr_Id),
   CONSTRAINT Ecriture_Exercice_FK FOREIGN KEY(Dos_Id, Jal_Id, Exe_Debut) REFERENCES Exercice(Dos_Id, Jal_Id, Exe_Debut),
   CONSTRAINT Ecriture_Num_Compte_FK FOREIGN KEY(Dos_Id, Num_Cpte) REFERENCES Num_Compte(Dos_Id, Num_Cpte)
);

Ainsi on a la certitude qu’une écriture fait référence au bon compte (et les bons comptes font les bons amis...)

Votre avis à vous deux, amis ?

[seabs]

Bonjour fsmrel,

Avant de répondre, il m’a été nécessaire d’effectuer un peu de lecture pour mettre à niveau certains neurones.

Quel inconvénient à considérer qu’un compte est en l’occurrence une propriété multivaluée d’un dossier*?

Effectivement, en première approche, je ne vois aucun inconvénient majeur.

J’ai donc retenu ta solution.

Je commence à mettre en place une base pour effectuer les tests. Si le schéma de la comptabilité ne me pose aucun souci, il me reste quelques interrogations sur la mise en œuvre et notamment dans la situation où plusieurs dossiers différents sont présents sur le même ordinateur.

Il doit bien rester quelques améliorations à apporter à mon MCD, cependant, l’essentiel me semble traité.

Encore merci pour ton aide, sans laquelle j’aurais pataugé.

À plus.

[fsmrel]

Salve,

Quel inconvénient à considérer qu’un compte est en l’occurrence une propriété multivaluée d’un dossier?

Effectivement, en première approche, je ne vois aucun inconvénient majeur. J’ai donc retenu ta solution.

D’accord.
Mutatis mutandis, ce qui vaut pour les comptes ne vaut-il pas à son tour pour les journaux ?

il me reste quelques interrogations sur la mise en oeuvre et notamment dans la situation où plusieurs dossiers différents sont présents sur le même ordinateur.

Je reviens sur ma proposition :

[Dossier]--1,n--()--1,1(R)--[Journal]

[Journal]--1,n--()--1,1(R)--[Exercice]

[Exercice]--1,n--()--1,1(R)--[Ecriture]

Comme je l’ai laissé entendre, le but est en fait d’empêcher de façon automatique de faire de la salade de dossiers. Ainsi, Une écriture du dossier d1 ne peut pas référencer un compte d’un dossier d2 (et lycée de Versailles).

Je rappelle la structure correspondante de la table Ecriture (après nettoyage) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE Ecriture(
   Dos_Id INTEGER,
   Jal_Id SMALLINT,
   Exe_Debut DATE,
   Ecr_Id INTEGER,
   Ecr_Montant NUMERIC(15,2) NOT NULL,
   Ecr_Date DATE NOT NULL,
   Num_Cpte INTEGER NOT NULL,
   CONSTRAINT Ecriture_PK PRIMARY KEY(Dos_Id, Jal_Id, Exe_Debut, Ecr_Id),
   CONSTRAINT Ecriture_Exercice_FK FOREIGN KEY(Dos_Id, Jal_Id, Exe_Debut) REFERENCES Exercice(Dos_Id, Jal_Id, Exe_Debut),
   CONSTRAINT Ecriture_Num_Compte_FK FOREIGN KEY(Dos_Id, Num_Cpte) REFERENCES Num_Compte(Dos_Id, Num_Cpte)
);

Hasta luego

[Bardoire37]

Bonjour,

Je ne suis pas un expert ni un théoricien de la conception des bases de données, il ne s'agit que d'un avis.
Pour ma part j'approfondirai encore l'analyse du processus métier.
Quel objectif ? Pour quoi faire ?
Quelle est la base technique du processus métier ?

Je commencerai par le minimum de base : les entités principales
ensuite j'aborderai le multi-dossier
et plus tard les entités de service notamment pour faciliter la saisie des opérations (utilisateur pas spécialiste de la comptabilité)



** Rappel du processus métier **

✅ l'objectif de la comptabilité est d'enregistrer les mouvements financiers afin de
déterminer l'actif et le passif d'un organisme (Bilan)
ainsi que le compte de résultat ( recettes, dépenses, résultat).
Pour une période annuelle (exercice)

✅ La technique de base : la comptabilité en partie double : égalité des débits et des crédits (Actifs Passifs)
c'est la technique officielle qui permet une gestion complète et sûr.

Schématiquement il s'agit, pour une période (l'exercice) d'
enregistrer les montants de chaque transaction
en ventilant (imputation) au débit et au crédit des bons comptes
(voir exemples de transaction en fin de document)

Les entités principales sont :
L'écriture
et les montants imputés
les comptes
L'exercice
Ces éléments sont suffisants pour une comptabilité de base (un seul dossier)
Pour une gestion multi-dossier il faut rattacher les entités principales à un dossier


✅ L'écriture : C'est l'élément de base qui représente un mouvement financier
L'opération sera enregistrée à partir d'une pièce justificative qui sera numérotée et archivée
Chaque écriture contient 1 ou plusieurs montants imputés au débit/Actif d'un /plusieurs compte(s)
et 1 ou plusieurs montants imputés au Crédit/Passif d'un/plusieurs compte(s)
le total des montants débit est égal au total des montants crédit (partie double)

La compilation, le tri et le regroupement des imputations permettrons d'élaborer les divers documents de comptabilité
Grand livre, opérations de clôture, bilan, compte de résultat (compte d'exploitation)

NB : le grand livre c'est une représentation de tous les comptes avec les écritures au débit et au crédit de chaque compte
ainsi que le solde

✅ La plan comptable : c'est l'ensemble des comptes classés selon leur utilité et/ou leur représentation
Classe 1 : Capital
Classe 2 : Immobilisation
Classe 3 : Stocks
Classe 4 : Tiers (clients, fournisseurs, ...)
Classe 5 : Financiers
Classe 6 : Charges (Dépenses)
Classe 7 : Produits (Recettes )
NB : les charges et les produits sont classés par nature.

✅ les journaux :
- Avec une comptabilité manuelle papier
ils servaient à organiser (répartir) les tâches de saisie selon les types d'opération .
ils étaient surtout nécessaires pour faciliter la ventilation et l'imputation des montants
Ils se présentaient sous forme de colonnes. Le total de ces colonnes étaient imputés périodiquement sur les comptes correspondants.
- Avec un système informatisé, ça peut être un moyen de visualisation et facilitation de la saisie

l'élément de base est l'écriture et les imputations

✅ Lettrage : Opération qui permet de comparer essentiellement les comptes de banque avec les relevés de la banque
en ce qui concerne les tiers (Clients , fournisseurs), il est préférable d'avoir un compte par client et fournisseur
pour connaitre le solde de chaque tiers et savoir ou l'on en est

NB : la facturation fait partie de la gestion commerciale

** Approche de conception de la BDD **

Il s'agit simplement d'une approche de recensement des entités et des attributs principaux
permettant de (commencer à ) définir les règles de gestion et le MCD

Dossier : l'organisme concerné
Nom/Libellé
> Adresse
> Mail
> Tel
> Contacts
TypOrganisme Entreprise/Personne/Association/Collectivité/Organisme autre/...
fk_Entreprise
fk_Personne
fk_Association
Fk_Collectivite
fk_Organisme
Memo-Notes
...
Exercice : la période comptable
Fk_Dossier
Année milésime
Date début supérieur à date de fin du milésime précédent
date Fin supérieur à date de fin
Libellé
Avancement Le statut d'avancement de l'exercice : en attente, ouverture, encours, Clôture, Compte exploitation, Bilan
Memo-Notes
...
Compte : les comptes d'imputation fait partie du plan comptable avec les classes
Fk_Dossier
Fk_Classe
No Char(6) No Classe + 3
Libellé
IsLettrage
Is SousCompte pour les comptes de tiers
Fk Compte de regroupement
Coté du bilan Actif/Passif
...
Classe de compte : les classes de regroupement des comptes
Fk_Dossier
fk Classe Parent
No Char(3)
Libellé
Type Bilan/Gestion (Resultat)
Memo-Notes
...
NB : Il estt possible de définir une entité 'Plan_Comptable' et d'y rattacher les classes et les comptes
si un même plan comptable peut servir à plusieurs dossiers.
les comptes et les classes font alors référence à un plan comptable
et le dossier référence un plan comptable

Ecriture : correspond à un fait comptable, un mouvement financier
Fk_Exercice (donc un dossier et une période )
?? Fk_ Journal si journal, pas indispensable
Date enregistrement
Date imputation Peut être différente, surtout en fin et début d'exercice
Libellé
Ref piece justificative obligatoire
Desc-Info
...
Imputation : les comptes concernés par une écriture
pour une écriture, le total des débits est égal au total des crédits
Fk_Ecriture
Fk_Compte
Montant Débit
Montant crédit
Desc-Info
fk_Rubrique pour la Gestion budgétaire
...


Journal : sert à présenter la saisie selon les types de fait comptable
Tiers (Client, Fournisseurs, Personnel, ... )
Financiers ( Caisse, Banque)
Opérations Diverses ( salaires, TVA, etc... )
Fk Exercice
Key Code Char(3)
Libellé
> Comptes concernés Débit/Actif
> Comptes concernés Credit/Passif
...
Lettrage : Pour le pointage des comptes banque
Fk_Imputation
référence Banque/Tiers
Date Banque/Tiers
Montant Banque/Tiers
Débit/Credit de Banque/Tiers inversé par rapport à comptabilité
Memo-Notes
Date lettrage
Mode 1/1 ; 1/x ; x/1 ; x/x (x = Plusieurs)
Statut Egal/Différent
...

** Exemples d'opérations **

✅ Achats
Cas "Standard"
. à réception de facture

Achat HT	90.00
TVA payée	10.00
Fournisseur		100.00

on a fait une dépense, on doit au fournisseur
. on paye (chèque)

Fournisseur	100.00
banque		100.00

on ne doit plus rien, on a moins d'argent en banque

Cas "sur la trésorerie"
on enregistre sur les paiements

Achat Ht	90.00
Tva payée	10.00
Banque		100.00

✅Ventes
Cas Standard
. à l'envoi de la facture au client

Vente		180.00
TVA encaissée		20.00
Client	200.00

on a fait une vente, le client nous doit de l'argent
. le client nous paye

Banque	200.00
Client		200.00

Cas sur la trésorerie
on enregistre sur les encaissements

Vente		180.00
TVA encaissée		20.00
Banque	200.00

✅ Frais de personnel
. à l'établissement de la paye

Salaires Bruts	20.00
Charges patronales	10.00
Personnel		16.00
URSSAF		14.00

. on paye le personnel

Personnel	16.00
Banque		16.00

. on paye l'URSSAF

URSSAF	14.00
Banque		14.00

le cas standard est celui appliqué par les entreprises
le cas 2 peut être appliqué par une association
on peut oublier la TVA si on n'y est assugéti.
Il est possible de mixer les 2 formules (selon le régime)


*** En fin d'exercice ***

** le compte de résultat **

Recettes		180.00
Dépenses	120.00
Resultat	60.00

** le bilan (très simplifié) **

Client	0.00	0.00
Fournisseur	0.00	0.00
Etat (TVA)		10.00
URSSAF	0.00	0.00
Banque	70.00
Résultat		60.00
	70.00	70.00

Le résultat correspond à ce que l'on a en banque moins ce que l'on doit à l'état

[Bardoire37]

Bonjour
En complément un premier jet de MCD





Il faudrait vérifier les cardinalités car je suis un peu faché avec.

Cordialement

[seabs]

Bonjour fsmrel,

Je te remercie pour ta suggestion, mais j’avais anticipé l’identification relative pour les journaux, les exercices et les écritures.

En conséquence, voici le MLD avec lequel j’ai mis en place une base provisoire afin d’effectuer un certain nombre de tests

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE Ecriture(
   Dos_Id INT,
   Jal_ID INT,
   Exe_Debut DATE,
   Ecr_ID INT,
   Ecr_Date DATE NOT NULL,
   Ecr_Operat CHAR(12)  NOT NULL,
   Ecr_Libelle VARCHAR(100)  NOT NULL,
   Ecr_Montant DECIMAL(12,2)   NOT NULL,
   Ecr_D_C CHAR(1)  NOT NULL,
   Num_Cpte INT NOT NULL,
   CONSTRAINT PK_Ecriture PRIMARY KEY(Dos_Id, Jal_ID, Exe_Debut, Ecr_ID),
   CONSTRAINT FK_Ecriture_Exercice FOREIGN KEY(Dos_Id, Jal_ID, Exe_Debut) REFERENCES Exercice(Dos_Id, Jal_ID, Exe_Debut),
   CONSTRAINT FK_Ecriture_Num_Compte FOREIGN KEY(Dos_Id, Num_Cpte) REFERENCES Num_Compte(Dos_Id, Num_Cpte)
);

Je vais commencer à tester l’ensemble de la base. Bien entendu, si certains points ne te semblent pas satisfaisants, tu peux toujours me faire part de tes réflexions et appréciations.
Toutefois, je pense pour les traitements envisagés, nous ne sommes pas loin de la vérité.

Cordialement et à plus.

[seabs]

Bonjour Bardoire37,

Je n’ai pas très bien compris l’intérêt de ton intervention. J’ai survolé ta littérature sur la comptabilité, car c’est une activité que je connais parfaitement. Mon problème n’est pas ce niveau, il se situe dans la rédaction du MCD dans le but de créer une base opérationnelle et qui ne conduise pas vers une modification lourde après 6 mois d’utilisation.

J’ai regardé ton MCD, a priori, il n’apporte rien par rapport à celui mis en place avec l’aide @fsmrel et @escartefigue. Alors, je vais continuer avec le modèle initial. En plus, dans ta présentation, aucune règle de gestion n’est incluse. Alors, pour comprendre et examiner les raisons de tes choix, il est nécessaire de s’accrocher.

D'autre part, je note l'absence des journaux. Il faudra m'expliquer comment mettre en place une comptabilité sans aucun journal.

En résumé, la comptabilité est un métier que je maîtrise totalement, la présentation MCD, ce n’est pas le cas. C’est la raison pour laquelle je respecte les recommandations qui me sont faites par les vrais spécialistes cités précédemment.

Cordialement.

[fsmrel]

Bonjour,

voici le MLD avec lequel j’ai mis en place une base provisoire afin d’effectuer un certain nombre de tests

D’accord pour le code SQL de la table Ecriture. Attention, le MLD est un cran au-dessus du code SQL (dans cet exemple : Looping, onglet Fenêtres, cocher la case "MLD textuel").

Ça serait bien que vous fournissiez le code SQL des autres tables, qu’escartefigue et moi-même puissions au besoin faire nos remarques.

A propos des contraintes :

Si ça n’est pas déjà fait, s’assurer des contraintes qui peuvent être sous-traitées au SGBD.

Exemple (à adapter en fonction du SGBD) :

Ecr_D_C CHAR(1) NOT NULL CHECK (Ecr_D_C IN ('C', 'D'))

Concernant la table Exercice :

Exe_Fin DATE NOT NULL CHECK (Exe_Fin > Exe_Debut)

A noter que ces contraintes ne concernent que la ligne en cours d’insert ou d’update.

Sinon, comme vous l’aviez fait observer dans le post #16 :

la date du prochain exercice ne peut pas être inférieure à la date de fin de l’exercice précédent. Il me semble que ce point doit être géré par trigger ou dans la programmation SQL.

Hélas, c’est exact, ça sent le trigger...

[escartefigue]

la date du prochain exercice ne peut pas être inférieure à la date de fin de l’exercice précédent. Il me semble que ce point doit être géré par trigger ou dans la programmation SQL.

Hélas, c’est exact, ça sent le trigger...

Certains SGBD permettent d'associer une UDF à une contrainte CHECK

Voir l'article de Fred Brouard pour SQL server ICI

[fsmrel]

Bonsoir,

Certains SGBD permettent d'associer une UDF à une contrainte CHECK

Exact.

@seabs
 
Pour notre information, est-ce que cela vaut pour vos SGBD (cités dans le post #20) ?

[seabs]

Bonjour fsmrel,

Ecr_D_C CHAR(1) NOT NULL CHECK (Ecr_D_C IN ('C', 'D'))
Exe_Fin DATE NOT NULL CHECK (Exe_Fin > Exe_Debut)

Pour ces contraintes sous-traitées, j'avais effectué le nécessaire.

Ça serait bien que vous fournissiez le code SQL des autres tables, qu’escartefigue et moi-même puissions au besoin faire nos remarques.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Dossier = (Dos_Id INTEGER, Dos_Adresse VARCHAR(100) , Dos_Code CHAR(5) , Dos_Commune VARCHAR(80) );
Journal = (#Dos_Id, Jal_ID INTEGER, Jal_Type CHAR(8) , Jal_Code CHAR(7) , Jal_Descript VARCHAR(50) , Jal_TVA BOOLEAN, Jal_Arret BOOLEAN);
Identif_Indiv = (#Dos_Id, Ide_Nom VARCHAR(50) , Ide_Prenom VARCHAR(50) );
Dos_Assoc_Auto = (#Dos_Id, Dos_Siren CHAR(9) , Dos_APE CHAR(5) );
Unite = (Uni_Id INTEGER, Uni_Design CHAR(20) );
Classe_Comptable = (Clas_Compt INTEGER, Cla_Denominat VARCHAR(60) );
Sous_Classe_Comptable = (SCla_Compte INTEGER, SCla_Denominat VARCHAR(50) , #Clas_Compt);
Num_Compte = (#Dos_Id, Num_Cpte INTEGER, Num_Lettrage BOOLEAN, Num_NomCompte VARCHAR(50) , Num_Bloquer BOOLEAN, Num_Ligne_Etat CHAR(3) , #SCla_Compte);
Exercice = (#(#Dos_Id, Jal_ID), Exe_Debut DATE, Exe_Fin DATE, Exe_Bloque BOOLEAN);
Ecriture = (#(#(#Dos_Id_1, Jal_ID), Exe_Debut), Ecr_ID INTEGER, Ecr_Date DATE, Ecr_Operat CHAR(12) , Ecr_Libelle VARCHAR(100) , Ecr_Montant NUMERIC(12,2)  , Ecr_D_C CHAR(1) , #(#Dos_Id, Num_Cpte));
Identif_Associat = (#(#Dos_Id), Soc_Denominat VARCHAR(50) );
Identif_Auto = (#(#Dos_Id), Ide_Nom VARCHAR(50) , Ide_Prenom VARCHAR(50) );
Quantite = (#(#(#(#Dos_Id, Jal_ID), Exe_Debut), Ecr_ID), Qua_Valeur NUMERIC(8,2)  , #Uni_Id);
TVA = (#(#(#(#Dos_Id, Jal_ID), Exe_Debut), Ecr_ID), Tva_Montant MONEY, Tva_Taux NUMERIC(5,2)  );
Lettrage = (#(#(#(#Dos_Id, Jal_ID), Exe_Debut), Ecr_ID), Let_Date DATE, Let_Lettres CHAR(3) );

Si nécessaire, je peux te remettre le script LDD.

Certains SGBD permettent d'associer une UDF à une contrainte CHECK
Pour notre information, est-ce que cela vaut pour vos SGBD (cités dans le post #20) ?

Les SGBD Interbase et Frebird ne sont pas aussi puissantes que SQL Server. Pour Interbase , je l'utilise seulement dans deux applications déjà anciennes, donc, je sais pas.

Pour Frebird les UDF existaient jusqu'à la version 3.0 avec une approche particulière, mais en rien comparable avec SQL Server. Depuis la version 4.0, les UDF n'existent plus, ils sont remplacés par les UDR. À ce jour, aucune utilisation pour moi. Mais après lecture de la documentation, il semble possible de réaliser des opérations ayant une équivalence proche de SQL Server. Depuis, la version Firebird 5.0 est sortie, mais, personnellement, j'attends la version Firebird 6.0 qui doit arriver en fin d'année.

En conclusion sur ce point, je pense maintenir, dans l'immédiat, l'utilisation des triggers que je maîtrise correctement. Les applications que je développe sont modestes et je suis conscient de ne pas toujours optimiser autant les SGBD que le code de développement.

Mon objectif est de rendre service en trouvant une solution qui simplifie la vie des demandeurs.

Cordialement et encore merci pour votre aide. Mon MCD précédent date quelque temps, d’où des oublis dans sa construction.

[fsmrel]

Bonjour seabs,

Si nécessaire, je peux te remettre le script LDD.

Je préfère évidemment le code SQL (le script LDD), car le MLD textuel n’est pas SQL et je le trouve particulièrement pénible à lire...

On attendra quand même que le code SQL soit à jour.
 

Je pense maintenir, dans l'immédiat, l'utilisation des triggers que je maîtrise correctement.

D’accord, c’est plus prudent, pour ma part j’en ferais autant.

Mon objectif est de rendre service en trouvant une solution qui simplifie la vie des demandeurs.

Encore !

A bientôt, quand le MCD et le code SQL (le script LDD) seront donc à jour.

Encore bon courage !

[SQLpro]

...


Attention à la précision des montants
Les types REAL et DOUBLE ont pour vocation de contenir des grands valeurs dont on se fiche de la précision décimale.
Pour des montants précis, il est préférable d'utiliser le type DECIMAL.


...

Je dirais absolument indispensable sinon erreurs constantes lors des clôtures d’exercice. De la même manière tous les calculs comptables doivent impérativement être contre typées en DECIMAL... et les calculs effectués d'une seule manière (instaurer des vues pour ce faire me parait la meilleure garantie...)

A +

[SQLpro]

...
Entièrement d'accord. Dans le cas présent, il s'agit de données comptables, lesquelles n'ont que deux décimales. Pour ce type de données, j'utilise «Currency» qui est adapté à ce type de données. Cependant, je retiens ta remarque.
...

N'utilisez JAMAIS ce genre de type exotique spécifique à un SGBDR. Créez vous un DOMAINE avec par exemple du DECIMAL(16,2) que vous appelez "D_FINANCE_COMPTA". En pure SQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE DOMAIN D_FINANCE_COMPTA
AS DECIMAL(16,2)
CHECK VALUE >=0;

A +