Discussion :

[Gardener68]

Bonjour,

On vient de me remettre un projet comptable à mettre sur pied sous Access (préexistant et opérationnel sous Visual Foxpro mais devant être transféré pour des raisons de licence si j'ai bien compris) pour lequel je constate l'existence d'un très (trop?) grand nombre d'articles comptables à manipuler.
Il s'agit d'une comptabilité budgétaire impliquant bien entendu un budget prévisionnel, des modifications budgétaires en cours d'année (normalement entre 0 et 2 mais j'ai vu plusieurs cas où il y en a eu jusqu'à 15) et un compte annuel.

Parmi les exigences, je devrais afficher des écrans synoptiques pouvant comporter jusqu'à 360 données (au secours) :
28 articles de recettes
71 articles de dépenses
45 totalisations partielles ou intermédiaires (pourraient être des champs calculés)
le tout multiplié par 3 puisqu'il faut montrer simultanément le budget initial, la somme des modifications budgétaires et le compte annuel plus bien sûr une série de champs informatifs et de sélection. (voir photo) Je suis donc très au-dessus des capacités d'Access en terme des nombre de variables notamment pour les requêtes (255)

La table de base est constituée de 135 champs (un par article budgétaire et éléments de sélection et d'appui)
Chaque exercice comptable comprend entre entre 2 et 17 records par centre de fonctionnement (il y en a 45 à ce jour et d'autres s'ajouteront dans le futur)

J'avoue ne pas voir comment m'en sortir devant la masse de datas à gérer simultanément.

Quelqu'un a-t-il une idée ? please......

Guy

[accessisgood]

Bonjour,

je crois que le principe est de bien distinguer la partie acquisition de données, la partie transactionnelle (saisie et maintenance des données) et la restitution.

pour la partie transactionnelle, il faut un modèle de données robuste (et évolutif), qui soit détaché des contraintes de reporting et qui permette de saisir, modifier en masse toute l'information; pas de tables de 255 champs, mais un modèle de données relationnel cohérent entre article, type de budget, exercice...

pour la partie restitution, lorsque c'est un peu compliqué il vaut mieux faire un lien entre Access et Excel (préparer des query adaptés dans Access) et faire le reporting sous Excel (voire d'autres outils comme MS-PowerBI)

pour la partie acquisition, c'est un peu plus compliqué: les utilisateurs travaillent souvent en tableau alors que Access travaille en liste. il y a plusieurs approches, par exemple!
- des tables Access dédiées à l'interface utilisateur, suivi de programmes (VB, datamacro ou query le choix est large) pour transférer l'information dans la partie transactionnelle
- des fichiers Excel pré-structurés (ex avec autorisation par cellule)… mais pareil!, il faudra un peu de programmation pour importer la donnée en masse et l'intégrer correctement dans la partie transactionnelle.

[Gardener68]

Bonjour,

Merci pour la réponse,

C'est en effet ainsi que je conçois la chose.

Pour le moment, je suis en discussion approfondie avec le propriétaire des données pour comprendre le fonctionnement de son système (qui existe depuis 1990), les flux d'informations, les documents à obtenir (il y a de très nombreuses contraintes légales car il s'agit en fait d'organismes semi-publics donc dépendant des législations locales, régionales, fédérales et européennes).
J'espère aussi parvenir à définir la faisabilité en fonction de ses réelles attentes et pas que la réalisation d'un "simple" écran comme celui fourni à titre d'exemple qui déjà suppose de très nombreuses informations quant à l'alimentation des données mises à jour.

Donc on reste à la discussion pour le moment et ensuite décision de faire ou non (et dans quels délais).

Merci

Guy
Bruxelles