Discussion :

[cafeine]

Bonjour à tous !

Ce sujet a pour but de vous faire participer à la création d'un projet d'application Access dédiée à la gestion personnelle des comptes bancaires.

L'originalité du projet repose sur deux aspects :
- échange entre les participants
- conception et publication par étape

L'idée est de créer une application de gestion des comptes pour les particuliers qui offre des fonctionnalités standard :
- multicompte / multibanque
- saisie des opérations
- rapprochement bancaire
- consultation / etats et statistiques

Parce qu'il faut bien commencer, je vous propose de commencer à échanger sur la conception/modélisation de la base.

Merci d'avance pour votre participation !

[Lou Pitchoun]

Salut Cafeine,

Sans entrer trop dans le détail pour la conception/modélisation de la base, je propose :

• Un compte est dans une banque.
• Une opération est affectée à un compte.
• Une opération concerne une catégorie de dépenses ou revenus.
• Une catégorie comporte plusieurs sous catégories.
• Une sous catégorie peut appartenir à plusieurs catégories.
  Exemple :
  Catégories : maison, voiture
  Sous catégorie : assurance
  Il y a pour chacune d'elles une assurance : assurance est une sous catégorie de maison et voiture

Voilà pour un début.

[Dolphy35]

Salut Cafeine,

Sans entrer trop dans le détail pour la conception/modélisation de la base, je propose :

• Un compte est dans une banque.
• Une opération est affectée à un compte.
• Une opération concerne une catégorie de dépenses ou revenus.
• Une catégorie comporte plusieurs sous catégories.
• Une sous catégorie peut appartenir à plusieurs catégories.
  Exemple :
  Catégories : maison, voiture
  Sous catégorie : assurance
  Il y a pour chacune d'elles une assurance : assurance est une sous catégorie de maison et voiture

Voilà pour un début.

Ca me plait pas trop mal, juste une chose :

• Les taches répétitives

exemple :Assurance xxx le 05 de chaque mois avec montant pré-renseigné.

Sinon très bonne idée cafeine

Dolphy

[cafeine]

Merci de vos idées !

Kikof > j'adhère avec toi sur les grandes lignes de la modélisation !
pour les sous-catégories, c'est une bonne idée à laquelle je n'avais pas trop pensé.

Dolphy > cette fonctionnalité faisait partie de ce que j'avais intégré, alors pour aller plus loin voici les fonctionnalités envisagées :

Fonctions de base :
- saisie / consultation / modification opérations
- pointage des relevés bancaires
- suivi de la position / résultat du mois
- paramétrage comptes / banques / catégories
- gestion d'enveloppes budgétaires
- programmation des opérations récurrentes

Fonctions évoluées :
- gestion de l'épargne : opérations sur titres - comptes épargne - valorisations
- communication : envoi de mail / courrier / fax
- sauvegardes

Cette liste n'est pas fermée, n'hésitez pas à participer !

[Lou Pitchoun]

Merci de vos idées !

Kikof > j'adhère avec toi sur les grandes lignes de la modélisation !
pour les sous-catégories, c'est une bonne idée à laquelle je n'avais pas trop pensé.

C'est l'expérience

Dolphy > cette fonctionnalité faisait partie de ce que j'avais intégré,

Obligatoire pour éviter de saisir trop d'opérations.

alors pour aller plus loin voici les fonctionnalités envisagées :

Fonctions de base :
- saisie / consultation / modification opérations
- pointage des relevés bancaires
- suivi de la position / résultat du mois
- paramétrage comptes / banques / catégories
- gestion d'enveloppes budgétaires
- programmation des opérations récurrentes

Fonctions évoluées :
- gestion de l'épargne : opérations sur titres - comptes épargne - valorisations
- communication : envoi de mail / courrier / fax
- sauvegardes

Cette liste n'est pas fermée, n'hésitez pas à participer !

C'est du taff. mais on va y arriver.

Par contre, avant de partir dans tous les sens, il faut :
1) définir les tables pour cela continuer de discuter
2) en fonction de ce qui aura été dit : on voit ce que vont contenir les tables (champs, case à cocher pour les rapprochements la périodicité de certaines écritures etc...

Enfin laissons Cafeine le chef d'orchestre de tout ça non

[cafeine]

Ce n'est pas faux, un moment il faut s'y mettre ...

Voici une ébauche de modèle, vue l'heure tardive vous me pardonnerez les bourdes ...

[cafeine]

A titre d'info, pour construire le modèle, j'ai utilisé AnalyseSI :

http://analysesi.free.fr/

Pourquoi ?
- gratuit
- léger
- simple d'emploi
- bien clair avec la logique MCD >>> MPD >>> implémentation
- capable de générer le code SQL de création de la base

ci-joint le fichier du projet zippé (lisible uniquement par AnalyseSI).

Toutes vos remarques seront les bienvenues.

[cafeine]

Hello,

Pas de commentaires sur le modèle conceptuel ?

[Lou Pitchoun]

J'ai pas trop eu le temps de m'y pencher...

Là comme ça sur le gaz :
ok pour les tables : compte, banque, contact, relevé.

Attention pour les opérations : si tu fais un virement entre 2 comptes ??
Tu dois pouvoir sélectionner en cas d'opération de type virement le compte à créditer.

Pour la table récurrente une opération peut être récurrente : je lierais les 2 tables...

A quoi correspond la table destination ?

[DelphiManiac]

Bonjour, je viens de découvrir ce sujet, et la première question que je me serais posé, c'est la méthode d'enregistrement des écritures :

Simple partie, comme proposé, un montant est enregistré de manière unique.

Double partie comme en compta, cela permettrait de définir les catégories comme étant l'autre partie de l'écriture.

Il est évident qu'en double partie, il serait préférable que cela reste transparent pour l'utilisateur (dans la mesure du possible).

On aurait d'une part les comptes bancaires et chaque écriture créditerais/débiterais 2 comptes. D'une part le compte bancaire et d'autre part le tiers (catégorie : voiture, loyer, voyage, autre compte, employeur, etc ...)

[cafeine]

Merci d'avoir regardé !

1- Cas du virement compte à compte.
On peut soit :
- saisir deux écritures une débitrice sur un compte et une créditrice sur l'autre

+ : simple à gérer

- : oblige à une double saisie

- soit prévoir un champ compte destinataire.

+ : une seule saisie

- : oblige à créer un type pour l'opération créditrice et une pour l'opération créditrice

A débattre donc ...

2- Recurrente recueille les opérations qui ont une fréquence.
Je prévoyais qu'un traitement interfacé par un formulaire laisse l'initiative à l'utilisateur de sélectionner les opérations récurrentes et les déverse dans operations. J'imaginais aussi que l'application surveille les dates et suggère à l'utilisateur de déverser sa sélection des écritures récurrentes.

3- La table destination est le synonyme de sous-catégorie.

J'ai pas trop eu le temps de m'y pencher...

Là comme ça sur le gaz :
ok pour les tables : compte, banque, contact, relevé.

Attention pour les opérations : si tu fais un virement entre 2 comptes ??
Tu dois pouvoir sélectionner en cas d'opération de type virement le compte à créditer.

Pour la table récurrente une opération peut être récurrente : je lierais les 2 tables...

A quoi correspond la table destination ?

[cafeine]

Bonsoir DelphiManiac, bienvenue sur ce fil !

Pourquoi j'ai écarté la comptabilisation en partie double ?
Parce qu'il s'agit de gérer des comptes personnels, qu'il n'y a pas de notion d'exercice, pas de stocks, pas d'amortissements, pas d'immobilisations ...
D'autre part toutes les écritures ont une répercussion en banque.

Imaginons que l'utilisateur achète une télévision :
1 opération - compte LCL - Date du jour - 999 € - Matériel Hi-Fi - Loisirs

Une entreprise achète une télévision
Dt Achat non immobilisable 999

Ct Compte Fournisseur 999

elle paie
Dt Compte Fournisseur 999

Ct Banque 999

Je voudrais savoir pourquoi tu suggères ce mode ? J'ai du mal à en voir l'intérêt pour les comptes d'un particulier.

Bonjour, je viens de découvrir ce sujet, et la première question que je me serais posé, c'est la méthode d'enregistrement des écritures :

Simple partie, comme proposé, un montant est enregistré de manière unique.

Double partie comme en compta, cela permettrait de définir les catégories comme étant l'autre partie de l'écriture.

Il est évident qu'en double partie, il serait préférable que cela reste transparent pour l'utilisateur (dans la mesure du possible).

On aurait d'une part les comptes bancaires et chaque écriture créditerais/débiterais 2 comptes. D'une part le compte bancaire et d'autre part le tiers (catégorie : voiture, loyer, voyage, autre compte, employeur, etc ...)

[DelphiManiac]

Tout à fait d'accord sur la vision simplifié de la gestion d'un compte personnel. Le compte de banque intervient dans toutes les écritures.

L'avantage que je vois à créer une double partie, c'est d'une part de ne pas voir les opérations de virement comme des opérations spécifiques et d'autre part de voir les catégories comme étant la contrepartie de l'écriture bancaire.

Ca pourrait aussi simplifier la notion de budget, un budget c'est quoi ? C'est une somme que l'on alloue à une catégorie et qui est débité lors de toutes opérations sur cette catégorie.

Enfin c'est une question que je me suis posé, donc je la soumets. Je ne suis pas sur que ce soit plus complexe à implémenter, la seule restriction, c'est qu'il faut essayer de masquer l'implémentation 'comptable' pour ne pas rebuter l'utilisateur standard.

[cafeine]

Je pense qu'on peut évacuer la difficulté des opérations compte-à-compte une gestion en VBA en fonction du type d'opération (transparent pour l'utilisateur).

La modélisation en partie-double me semble louable mais requiert une complexité qui n'est peut être pas pertinente dans notre cas.

Si j'ai bien compris tu voudrais pouvoir débiter le Budget à chaque opération ... pourquoi pas mais le problème est que tu n'as pas qu'un seul budget ... d'où quel budget imputer ?

Ma vision :
- saisir un budget (je l'ai imaginé plutôt mensuel : rythme de versement des salaires) en fixant des montants par destinations et catégories.
- créer une requête et un état de comparaison avec le réel.

Ce fonctionnement permet de gérer plusieurs budgets, si par exemple on change de logement, de travail etc.

Merci d'avance pour vos commentaires.

Tout à fait d'accord sur la vision simplifié de la gestion d'un compte personnel. Le compte de banque intervient dans toutes les écritures.

L'avantage que je vois à créer une double partie, c'est d'une part de ne pas voir les opérations de virement comme des opérations spécifiques et d'autre part de voir les catégories comme étant la contrepartie de l'écriture bancaire.

Ca pourrait aussi simplifier la notion de budget, un budget c'est quoi ? C'est une somme que l'on alloue à une catégorie et qui est débité lors de toutes opérations sur cette catégorie.

Enfin c'est une question que je me suis posé, donc je la soumets. Je ne suis pas sur que ce soit plus complexe à implémenter, la seule restriction, c'est qu'il faut essayer de masquer l'implémentation 'comptable' pour ne pas rebuter l'utilisateur standard.

[cafeine]

Est-ce que les participants ou de nouveaux intervenants bienvenus souhaitent valider le modèle ?

Merci d'avance !

[Tofalu]

Je vois un autre truc sympa :

Gestion de tache

Le 10/12/2006 : envoyer chèque EDF pour facture 000125

Avec :

- affichage d'une fenêtre de notification (comme sous Outlook ou MSN)
- Possibilité de répéter l'alarme (me le rappeler dans X (jours, minutes, etc)
- Quand la tache est validée, appliquer l'opération financière sur le compte
- Mailing de rappel

[Tofalu]

Pour simplifier l'analyse, je serais d'avis de stocker le montant du compte :

Pourquoi ?

- Facilite les requêtes et les temps de réponses si beaucoup d'opération
- possibilité de fixer le montant actuel du compte lors de sa création
- permettra aussi de vérifier la cohérence des opérations avec le total du compte. ça permettra une fonction de "récupération". Si par malheur il manque des opérations, on créera une opération "RECUP" qui remettra d'aplomb les deux tables

Au truc, définir un seuil critique du compte.

[DelphiManiac]

Pour simplifier l'analyse, je serais d'avis de stocker le montant du compte :

Pourquoi ?

- Facilite les requêtes et les temps de réponses si beaucoup d'opération
- possibilité de fixer le montant actuel du compte lors de sa création
- permettra aussi de vérifier la cohérence des opérations avec le total du compte. ça permettra une fonction de "récupération". Si par malheur il manque des opérations, on créera une opération "RECUP" qui remettra d'aplomb les deux tables

Au truc, définir un seuil critique du compte.

Si c'est stocker le solde courant, c'est une grosse erreur d'après moi. Rien ne garantit que le solde soit à jour (erreur réseau, disque, plantage) et il est utopique de croire que tu peux te fier à cette valeur pour remonter une ligne de recup.

Sans une base de données, il faut à tout prix éviter les redondances d'informations. Au mieux avec une base hyper sécurisés et des triggers tu pourrais te le permettre.

[Tofalu]

En effet, rien ne garantit que le solde soit à jour. Mais y a quand même plus de chance qu'il le soit étant donné le nombre de ligne d'opération.

Et puis, en mode ajout, en utilisant une transaction :

Je mets mon solde à jour, je crée l'opération

Le solde sera forcément à jour.

Mais bon si ne voulez pas le stocker, vous ne le stockez pas.

il est utopique de croire que tu peux te fier à cette valeur pour remonter une ligne de recup.

Je ne comprend pas. Bien au contraire, je peux :

Afficher("L'application constate une incohérence dans les données. Le solde actuel de votre compte est : " & solde &sautligne & "Confirmez vous ce solde ?")

[JeremieT]

Bonjour à tous !!!

Ce projet m'intéresse fortement car j'avais en mon temps fais quelque chose d'assez sympa sur excel !
Me mettant depuis qq tps maintenant à Access je suis fortement intéressé par ce projet, je pourrais aider au développement si besoin et les idées ne me manqueront pas si jamais je vois des pistes d'amélios ou autres ;-)

Par quoi puis-je commencer ???

@+