Discussion :

[JeremieT]

Bonsoir à tout le monde !

Cafeine, pourrais-tu remettre le dernier modèle stp, ou nous annoncer si tu as plus avancer et nous dire ce que l'on peut faire now ;-)

Je veux bien m'occuper des beta-test en V97 si besoin ;-)

@+

[serges]

salut!
je suivait parallement ce projet.et depuiis plus de news et les compte devienne difficile à gerer qu'en est-il?

[cafeine]

Bonjour à tous,

Pour cause de période de boulot intense (période budgétaire), je me suis tenu un peu éloigné du projet. Il n'est cependant pas du tout à l'abandon, je vais très prochainement reposter un modèle à jour des dernières remarques.

Je me fixe à moi même une échéance ... allez hop ce week end

Merci de votre participation !!!

[JeremieT]

ouf me voilà rassurer

j'attends alors avec impatience ce we et c'est reparti pour un tour !

Bonne semaine à tous...

[keita]

bonjour à tous
Boulap a ecrit:

Je veux bien m'occuper des beta-test en V97 si besoin ;-)

je serais dans le meme wagon que lui:
1-Je veux bien m'occuper des beta-test en V2003 si besoin
2-Dans les paramétrages, j'espère qu'on donnera la possibilté à l'utilisateur de choisir sa monnaie; je reflechis en F CFA moi.
@+

[cafeine]

Merci pour votre aide à tous ...

Voici un nouveau modèle, il intègre :
- les dates multiples si chers aux financiers de l'équipe.
- le rattachement du scenario budgétaire à un utilisateur.

Mais cette conception lève chez moi une question, est-il nécessaire de faire du multi-utilisateur ? ou bien dupliquer l'application pour une autre personne
du foyer ? Est-ce qu'un couple souhaite autant de transparence ?

Avantages du multi-utilisateurs :
- vision patrimoniale
- vision fiscale

Contraintes :
- transparence plus ou moins obligatoire
- accessibilité moindre à moins d'avoir plus d'un PC.

Vos avis ?

[Arkham46]

Mais cette conception lève chez moi une question, est-il nécessaire de faire du multi-utilisateur ? ou bien dupliquer l'application pour une autre personne
du foyer ? Est-ce qu'un couple souhaite autant de transparence ?

Etant donné qu'on est là pour apprendre, pourquoi ne pas implémenter une sécurité au niveau utilisateur?
Chaque personne a son utilisateur qui lui permet de voir ses comptes.
Comme ça on voit comment faire pour mettre des autorisations d'affichage partiel des données d'une table (j'ai jamais fais mais ça me semble un bon exercice)

Si on veut aller plus loin, on peut imaginer que chacun définissent ses propres règles dans une table de paramètrage.
Par exemple je décide de masquer tel ou tel catégorie aux autres utilisateurs.
Ou alors je refuse l'affichage des commentaires/descriptions des opérations.
Ou bien j'autorise la visualisation des catégories mais je refuse l'affichage des sous-catégories pour ne pas montrer trop de détail sur mes achats.

Bien sûr y a un compte administrateur qui pourrait tout voir.
Mais chacun choisi une partie du mot de passe et hop c'est sécurisé.
Si on veut se connecter en tant qu'administrateur il faut que tout le monde soit là.

Je ne sais pas si tout cela est bien nécessaire, mais sans la sécurité il manquerait quelque chose au projet non?

[B.AF]

Salut à tous j'ai lu avec intérêt tous les commentaires, a cela j'ai deux trois remarques :

Un utilisateur posséde un compte et depuis peu un compte = un IBAN.
Concernant les opérations, et pour les particuliers, les dates de valeur n'existe plus (le fameux j+1 date d'opération n'existe plus). L'astuce est aujourd'hui que les banques traites les dates d'execution.

Concernant un compte espéce, la gestion du solde peut se faire en passant par un objet et le stockage en temps réel de la position.

Il est bcp plus simple de traiter un solde comme le résultat d'un aggrégat de montant en période.
En revanche il est aussi utile de pouvoir réaliser un cut off qui permet de ne pas avoir systèmatiquement à récupérer imaginons 5 années d'historique.

Il faut donc que le compte travaillle sur une période en mon sens.
Autrechose, pour la gestion des opérations en devise, il est aussi utile de prévoir le stockage des contrevaleurs et le taux de référence de la contre valeur.
En outre, une opération en devise a parfois un coût non négligeable et prédictible.
D'ailleurs, il est aussi possible de calculer l'ensemble des frais bancaires, puisqu'ils sont connus (agios, inétrêts, abonnements Web).

Dans ce cas, il peut aussi être utile de travailler sur des écritures en hors chronologie (prévisionnelles)

Fred.

[Heureux-oli]

Pour la sécurité, les choses vont se corser, certains comptes pouvant être commun et d'autre pas.
Même chose lors de transactions de compte à compte, l'utilisateur aura accès aux données du compte de départ, mais pas nécessairement au compte d'arrivée.
L'exercice va devenir périlleux.

[cafeine]

Je partage ton point de vue ... et je me repose la question du multi-utilisateur ...

Pour la sécurité, les choses vont se corser, certains comptes pouvant être commun et d'autre pas.
Même chose lors de transactions de compte à compte, l'utilisateur aura accès aux données du compte de départ, mais pas nécessairement au compte d'arrivée.
L'exercice va devenir périlleux.

[B.AF]

Je comprends pas trop votre soucis, parce qu'en fait, c'est ce que font les sites des banques :

Ils vous autorisent a virer des sommes sur des comptes que vous ne voyez, mais que vous identifiez.

Donc a minima,

Il y a une association
Utilisateur --> Comptes Geres (Comptes sur lesquels l'utilisateur peut tout faire)
Utilisateur --> Comptes Accessibles (Comptes sur lesquels l'utilisateur peut effectuer une operation de virement)

Donc fondamentalement, il y a une relation
User
Compte
Autorisation Fonctionnelle

[Heureux-oli]

C'est ce que font les banques, mais alors il faut un seconde table pour les comptes.

Si j'ai bien compris la manoeuvre, il faut dans un premier temps faire un appli, il faut figer ses spécifications et ensuite envisager des modifications pour arriver à un résultat plus complet .

Si la bare est mise trop haut dès le départ, il va être difficile d'y arriver.
Je pense surtout au coordinateur (Cafeine) qui devra sans cesse revoir le cahier des charges.

Il me semble que pour l'instant la bare est déjà haute.

[cafeine]

Bon, puisque personne ne s'est exprimé depuis. Je vais un peu trancher dans le vif.

Je vais mettre de côté pour l'instant la gestion de la sécurité et le multi-utilisateur pour se concentrer sur le coeur de métier de l'application.

Si certains d'entre vous sont déçus et ne souhaitent pas donner suite, je les comprends et je les remercie pour leur aide. Pour les autres, ce n'est que le commencement !

Merci de revoir mon dernier modèle en fonction du cahier des charges ...

[Tofalu]

Hello,

dans le compte, je rejouterais bien le champ découvertAutorisé. Je n'ai pas vu cette notion quelque part

Sinon pour le reste du MCD, je suis OK.

[JeremieT]

Bonjour à tous !!!

Je vais essayer de regarder le modèle cette semaine mais vous savez tous ce que sais quand on a pas une seconde à soi, c'est compliqué.
La mise de coté des 2 "options" ne me gêne pas, je pense que l'on va avoir déjà de quoi faire avec ce qui est présent ;-)

@+

[DMboup]

Bon, puisque personne ne s'est exprimé depuis. Je vais un peu trancher dans le vif.

Désolé. Un peu trop occupé ces derniers temps

Je vais mettre de côté pour l'instant la gestion de la sécurité et le multi-utilisateur pour se concentrer sur le coeur de métier de l'application.

D'accord pour avancer.

Pour la sécurité, les choses vont se corser, certains comptes pouvant être commun et d'autre pas.
Même chose lors de transactions de compte à compte, l'utilisateur aura accès aux données du compte de départ, mais pas nécessairement au compte d'arrivée.
L'exercice va devenir périlleux.

D'accord pour la sécurité qui est de toute facon assez complexe à mettre en oeuvre.

Mais pour les transactions inter compte, un simple champ "Type Opération" permet d'avoir une solution simple d'accès aux autres comptes en lecture seules.

[rawsrc]

Bonjour

il faudrait prévoir la possibilité de ventiler une écriture sur d'autres comptes et non seulement sur plusieures catégories/sous-catégories.

Pour la gestion des types d'opérations (VRT, VRTREC, PRVLT...) il serait utile de précisier le sens normal du mouvement et prévenir l'utilisateur en cas d'utilisation à l'envers.

Du côté technique, les options sont nombreuses. Personnellement, je préférerais un développement axé principalement sur les modules de classes et évènements personnalisés. Cette approche permet de bien appréhender la complexité et autorise un développement plus collaboratif.

Ah j'oubliais, on implémente un suivi des moyens de pmt ? un compte rattache une ou plusieurs CB, un ou plusieurs chéquiers...
Et si on suivait plus finement les chéquiers en gérant leur numérotation ?

Ouala
Bye

[sebbar]

bonjour à tous
Je suis très interressé par ce projet, ayant eu l'idée (utopique?) de faire un logiciel de gestion de compte personnel. J'ai une petite expérience : j'ai réalisé un logiciel (perso) de gestion des absences et de suivi d'élèves (observations, courrier, événements) d'un établissement scolaire avec access et en autodicate. Je remercie au passsage les "forumeurs" car, sans même que je pose une question m'ont apporter souvent la solution à bien des soucis! de même pour les créateurs de tutoriels. Je vient d'appercevoir celui de Jean-Philippe Ambrosino sur les graphiques. Nous en aurons besoin pour ce nouveau projet d'ailleurs.

Pour ma part, je pense qu'il serait préférable de réaliser quelque chose de simple et de rapide concernant la saisie des opérations. Par ex. lorsque l'on sélectionne un tiers : le champ catégorie ou sous catégorie soit pré-sélectionné automatiquement. En effet pour bon nombre d'opérations à un tiers correspond souvent toujours la même catégorie, avec mise à jour auto de la date, voire du moyen de paiement. Il ne resterait qu'à saisir le montant.

2e idée. Il faudrait à mon avis que cette application soit simple (gestion de base de compte courrant) avec ajout optionnel de plugin pour ceux par ex pour ceux qui veuleut suivre un portefeuilles, des empruns, des placements...

Je partage l'avis de Cafeine pour se concentrer sur le coeur et s'occuper plus tard des extensions. La gestion de comptes multiutilisateurs, je n'en perçois pas l'intérê pour le simple utilisateur que je suis. La sécurité pourrait se résumer dans un premier temps à un mot de passe... non?

La recherche doit être très simple (j'apprécie la foncion de 'bankperfect' la dessus : il suffit de taper les derniers numéros d'un chèque pour le voir ou bien de taper les 1er chiffre d'un montant pour sélectionner tous ceux qui y correspondent.)

A bientôt

[jpbal]

Bonjour.
Je suis très interressé par cette gestion Banquaire.
j'ai réalisé une gestion banquaire pour une petite société.
Avec les rapprochements gérés par les dates.
Avec une gestion des banques de tiers.Il ya des petits problèmes que je n'ai pas réussi à surmonter. Une aide serait la bienvenue.
Je n'ai pas encore trouvé, ou vous rangez votre réalisation.
Il me semble que si l'on avait cette base à disposition.
Que chacun puisse apporter sa pierre, et que l'on puisse voir les résultats.
remerciements

[Dolphy35]

Bonjour,

Bonjour.
Je suis très interressé par cette gestion Banquaire.
j'ai réalisé une gestion banquaire pour une petite société.
Avec les rapprochements gérés par les dates.
Avec une gestion des banques de tiers.Il ya des petits problèmes que je n'ai pas réussi à surmonter. Une aide serait la bienvenue.
Je n'ai pas encore trouvé, ou vous rangez votre réalisation.
Il me semble que si l'on avait cette base à disposition.
Que chacun puisse apporter sa pierre, et que l'on puisse voir les résultats.
remerciements

Il n'y a pas encore de base car ce projet est en étape de modélisation

http://www.developpez.net/forums/sho...5&postcount=66

Dolphy