Le 21 Décembre 2000 Réunion Paris 5

Présentation au sujet: "Le 21 Décembre 2000 Réunion Paris 5"— Transcription de la présentation:

1 Le 21 Décembre 2000 Réunion Paris 5
JEFYCO Le 21 Décembre 2000 Réunion Paris 5

2 Qu’est-ce que JEFYCO? Une application de Gestion Financière et Comptable destinée à un établissement d ’enseignement supérieur. Rappel sur l’acronyme (nom d ’auteurs): J => Jean-Marc E => Etienne F => Frédéric Y => Yannick C => Claude O => « Others » pour les autres!! Mais aussi un clin d’œil à l ’application GEFICO de Paris 8 à l ’origine de JEFYCO.

3 Domaines fonctionnels directs (1)
Budget Mise en place DBM, Reports, Reprise des commandes N-1

4 Domaines fonctionnels directs (2)
Dépenses Fournisseurs Engagement Liquidations Mandatements Inventaire Missions Marchés Situations budgétaires Prémisses d’une comptabilité analytique

5 Domaines fonctionnels directs (3)
Recettes Liquidations Comptabilité Visa Dépenses et Recettes Disquettes Comptabilité Générale Editions Emargements Compte financier (à améliorer) ...

6 Domaines fonctionnels indirects
Gestion des droits de Scolarité Gestion du parc Informatique (cas particulier) Gestion des demandes de travaux Gestion de la taxe d ’apprentissage (en test) Gestion des conventions de Recherche (en cours) Gestion des stocks (produits chimiques-Soute) ...

7 Réponses aux questions exposées par PARIS 5:
Paie: cf A réaliser Club utilisateurs: 2 clubs (listes/Forums): Utilisateurs Informaticiens Marchés et fournisseurs: faits

8 Réponses aux questions exposées par PARIS 5:
Emargement automatique: fait Nouveaux bons de commande CNRS: fait et intégré Module inventaire: fait (avec financement et calcul amortissement)

9 Réponses aux questions exposées par PARIS 5:
Basculement d'un exercice sur l'autre: OK mais non encore automatique (peut le devenir) C.A.F. et FDR: oui dans le budget et calcul Gestion de la taxe d'apprentissage: oui (en test) Contrat de recherche: oui: développé à LA ROCHELLE qui se prépare, en outre à la création d’un SAIC

10 Réponses aux questions exposées par PARIS 5:
Gestion des stocks: oui (magasin) Mission à l’étranger : oui mais intégration taux de changes à faire Comptes rattachés (= cpte 18): oui Bordereau de remise chèques: oui mais à intégrer

11 Réponses aux questions exposées par PARIS 5:
Recettes: lettre de rappel et émargement: fait Documentation et formation sur JEFYCO: Assurée par l’Université ARTOIS Gestion du noyau de JEFYCO Assurée par l’Université LA ROCHELLE: Divers: Gestion des salles et gestion des services (heures complémentaires…): Faits => compatibilité Harpège rentrée 2001

12 A réaliser (1) Un module Paye. TVA Intracommunautaire TVA au prorata
Aujourd’hui l’université de La Rochelle utilise le logiciel Ciel-Paie ponté à l ’application. Cela convient à La Rochelle mais ne serait pas suffisant pour certains établissements. TVA Intracommunautaire TVA au prorata Comptabilité rattachée (exemple SAIC, Médecine préventive, services interuniversitaires ...)

13 A réaliser (2) Intégration en « temps réel » des taux de change dans l ’application missions Comptabilité Analytique d'Exploitation sur la base des prémisses pré-cités ... => procédure de demande de travaux

14 Un logiciel « libre » au développement sous contrôle!
Une charte de développement langage, environnement, architecture outils de développement collaboratifs SGBD cibles Une charte graphique (GUI) Partage des travaux forums utilisateurs/développeurs Gestion des versions Gestion des Frameworks Gestion de la documentation

15 Le cœur : le référentiel base de données
Gestion des versions des dictionnaires de données Gestion des demandes d ’évolution ou modification Gestion des effets de bords sur les applications clientes.

16 le référentiel base de données
Un serveur BD de développement unique Tout le monde peut disposer de la dernière version en cours de développement Un serveur BDs de test possible pour chaque établissement: 2 Bases possibles une base de test = version de développement à un instant t une base de test réplication de la base d ’exploitation à un instant t

17 le référentiel base de données
Aujourd ’hui: Un modérateur garant de son évolution, de sa cohérence, de son renseignement et de sa diffusion procédure de demande de travaux Demain: Un outil de développement collaboratif de gestion et de synchronisation des bases de données au sens « users Orcale »

18 Langages, outils, environnement
L’application de base et ses modules sont développés avec l’outil WebObjects disponible sur plate-forme Wintel ou Mac OS X Le langage pour tout nouveau module est JAVA. La modélisation base de données est faite avec EOF (inclu avec WebObject) L’architecture pour tout nouveau module est une architecture n-tiers

19 SGBD cibles Par défaut il s’agit d’Oracle
Toute autre source de données est possible pour autant qu ’il existe un « adaptor » ou un driver ODBC ou JDBC en version 5.0 Modéliser avec EOF crée un niveau d’abstraction indépendant des SGBD et permet de mixer plusieurs sources de données distinctes dans un même modèle Attention ce n’est pas forcément simple!

20 Gestion des demandes de travaux maintenance corrective et évolutive
Toute demande est enregistrée suivant un modèle prédéfini Chaque demande fait l’objet: d’un traitement indiquant: la durée l’action réalisée d’une information auprès des utilisateurs et des développeurs Les demandes sont traitées par les développeurs responsables (chefs de projets, de modules ou d’Objets

21 Forums et liste de discussions
Un forum utilisateur associé à une liste de diffusion est créé. Les modifications consécutives à une maintenance évolutive apparaissent dans ce forum Un forum développeur associé à une liste est créé.

22 Ressources en ligne Une charte graphique devra être élaborée
Les ressources graphiques seront en ligne suivant un dépôt de type CVS La méthodologie objet employée devrait permettre la réalisation d’objet métier, de palettes, de bundles qui seront disponibles sous forme de « Frameworks » ré-utilisables ou partageables Univers BO et requêtes Business Query

23 Les programmes sources: côté client
Disponible sur un serveur CVS à l ’aide d ’un client CVS disponible sous Windows ou sur Mac. Tout module ayant vocation à s’appuyer sur l’application JEFYCO est déposé dans cette base (« Repository ») Chaque développeur ou établissement peut en disposer pour l’enrichir, le corriger ou le tester.

24 « Reporting » et Infocentre
Business Object WebIntelligence Business query Univers en ligne

25 La documentation 2 types de documentations: Technique Utilisateur
La documentation technique recouvre plusieurs sous-types et engage chaque développeur. Elle nécessite une méthodologie commune et des outils idoines. La documentation utilisateur est intégrée au projet ou sous-projet. Son squelette est réalisé par le développeur mais sa version définitive est l’objet d’un non informaticien. Elle est disponible en ligne.

26 Procédure de validation
Développement et test niveau développeur/chef de projet/utilisateur Phase Bêta: niveau chef de projet/utilisateur choisi et volontaire Mise en exploitation niveau utilisateur

27 Principes de mutualisation
l’application JEFYCO n’est pas un produit commercial ; il ne peut-être ni acheté ni vendu, ni cédé à des tiers n’adhérant pas aux termes de la présente charte.. développée par l’Université de la Rochelle, celle ci consent à la mettre à disposition gratuitement d’autres universités qui demanderaient à en disposer, sous les conditions prévues aux articles suivants. la mise à disposition doit être sollicitée auprès de l’université de La Rochelle ; elle donne lieu à établissement d'une convention. la mise à disposition de JEFYCO implique pour l’établissement demandeur son engagement écrit à respecter les clauses de la présente charte.

28 Principes de mutualisation
les établissements qui décident d’opter pour JEFYCO s’engagent dans une démarche de mutualisation : mutualisation des développements, mutualisation de la documentation, mutualisation de la maintenance.

29 Principes de mutualisation
Il n ’y a pas obligation pour un établissement désireux d’exploiter JEFYCO d’être, pour les opérations ci-dessus, un membre actif si ce dernier ne dispose pas des moyens nécessaires. Cependant, l’université demandeuse doit s’engager, en contrepartie, à participer aux financements des coûts induits que pourraient engendrer l ’accès à JEFYCO (accompagnement, formation, implantation, suivi et maintenance, assistance, hot line, …) Ces coûts, éventuels, sont estimés par l’ensemble des partenaires sur la base du prix de revient de la prestation. En cela les pratiques de certains service de formation continues ou des futurs (?) SAIC pourront constituer une base de réflexion.

30 Principes de mutualisation
les universités ayant opté pour JEFYCO et adhéré aux principes de la présente charte se réunissent dans un comité d’application (dont la composition sera précisée mais associera politiques, experts fonctionnels et informaticiens): de donner un avis sur toute nouvelle adhésion, d’organiser et gérer les coopérations des différentes universités, de faire le point régulièrement sur les développements nécessaires (ici il sera nécessaire d ’y ajouter les utilisateurs) l’Université de la Rochelle se réserve la propriété de l’application et demeure la garante de sa cohérence.

31 Participation « active »
Rappel: l’usage du logiciel est gratuit. 1)Participation financière lorsque l’établissement utilisateur souhaite une assistance ou des aménagements spécifiques sans pour autant disposer des moyens nécessaires en local 2)Prise en charge de modules (ou objet métier!) comme la Paie par exemple par un établissement adhérant à la charte. L’intégration au système existant serait assurée par La Rochelle

32 Relations avec les autres applications
Compatibilité Harpège à 100% prévue rentrée 2001 (en cours de réalisation par La Rochelle) Compatibilité Apogée à 100% prévue rentrée 2002

33 Vers un Logiciel de Gestion Intégrée
La compatibilité avec les applications HARPEGE et APOGEE assurera à la communauté la disponibilité de l’ensemble des applications développées dans le cadre de cette charte. Cet ensemble constituant un système d ’information intégré modulaire.