COMMISSION EUROPÉENNE
SERVICE JURIDIQUE
FinSJ
Suivi des dépenses effectuées dans le cadre des
affaires du SJ
Description des fonctions
Version: 2.00
Date: 20-04-2006
Ref. : FinSJ-SR (System
Requirements)
Audience: Groupe informatique
Commission européenne, B-1049 Bruxelles - Belgique. Téléphone: (32-2) 299 11 11.
Bureau:
. Téléphone: ligne directe (32-2) 29
E-mail:
@cec.eu.int
Document History
Version Date
Comment
Modified
Pages
0.1
20/09/2004
Document created by
0.1
25/11/2004
Modification by
0.1
26/11/2004
Reviewed by
0.2
3/12/2004
Modification by
All
0.2
7/12/2004
Reviewed by
1.0
14/12/2004
Modification by
All
1.01
17/12/2004
Various modifcations by
Use cases
1.02
07/01/2004
Added Class Diagram
2.0
20/04/2006
New version by
2
INTRODUCTION............................................................................................................... 4
1. FONCTIONS............................................................................................................... 4
1.1. Rappel de l’existant ........................................................................................... 4
1.2. Portée du système .............................................................................................. 4
1.3. Fonctionnalités
requises .................................................................................... 4
1.3.1. Gestion des dossiers : référencement des affaires et accès aux
documents............................................................................................ 5
1.3.2. Gestion
contractuelle........................................................................... 5
1.3.3. Gestion des avenants ........................................................................... 6
1.3.4. Gestion des dépens .............................................................................. 6
1.3.5. Récupération et affectation des mouvements Sincom......................... 6
1.3.6. Recherche et modification d’une affectation....................................... 7
1.3.7. Suivi des mouvements enregistrés sur une activité ............................. 7
1.3.8. Rapports............................................................................................... 7
1.3.9. Security................................................................................................ 7
1.3.10. Data availability of the system ............................................................ 7
1.3.11. Consistency and non-redundancy........................................................ 7
1.3.12. Performance......................................................................................... 8
1.4. Non-functional
requirements............................................................................. 9
1.4.1. Usability .............................................................................................. 9
1.4.1.1. User authentication / single sign-on. ................................... 9
1.4.1.2. Web-based
interface ............................................................ 9
1.4.1.3. Flexible
reporting .............................................................. 10
1.4.1.4. Online
help ........................................................................ 10
1.4.1.5. Reliability .......................................................................... 10
1.4.2. Hosting, support and maintenance .................................................... 10
1.4.3. Technical
constraints......................................................................... 10
2. CAS
D’UTILISATION............................................................................................. 11
2.1. Recherche/création d’un dossier pour une affaire gérée par un système
du SJ. 11
2.2. Création d’un dossier pour une affaire gérée par un système externe au
SJ. 11
2.3. Création d’un contrat....................................................................................... 11
2.4. Création d’un dépens....................................................................................... 12
2.5. Réception d’une facture................................................................................... 12
3
2.6. Création d’un avenant à un contrat.................................................................. 13
2.7. Affectation rapide d’un mouvement Sincom 2 à une activité ......................... 13
2.8. Affectation détaillée d’un mouvement Sincom 2 à une activité...................... 13
2.9. Création d’un tiers ou d’une entité légale ....................................................... 13
3. BUSINESS
CASE..................................................................................................... 14
3.1. Diagramme de classes ..................................................................................... 14
3.2. Liste des classes............................................................................................... 15
INTRODUCTION
Ce document décrit les fonctionnalités d’un système de suivi des aspects comptables,
budgétaires et contractuels des dossiers traités par le Service Juridique.
1. FONCTIONS
1.1. Rappel de l’existant
Le document finsj-existing.doc (cf. note JUR(2004)090033) décrit la manière dont la cellule
financière du SJ suit les dépenses effectuées dans le cadre des affaires que le SJ traite.
1.2. Portée du système
Les informations comptables proviennent des bases de données de la DG BUDG et sont
uniquement mises à jour par les applications mises à disposition par la dite DG (ABAC,
SI2). Le système FINSJ ne fait que lire ces informations mais en aucun cas ne les
modifie.
Le référencement des affaires traitées par le SJ se fait via le système SJDOSSIER,
système qui centralise les références des dossiers parmi les différentes applications en
place au SJ.
Une documentation comprenant la description des fonctions et des classes du système
SJDOSSIER est en cours de préparation.
Pour les dossiers provenant de sources extérieures au SJ, FinSJ permet d’introduire
directement une référence respectant un format prédéfini selon le domaine abordé ainsi
que quelques informations essentielles permettant d’identifier avec précision celui-ci.
1.3. Fonctionnalités requises
Le but du système FINSJ est d’offrir une vue détaillée des montants engagés, payés et à
venir (dépens) concernant les dossiers des affaires traitées par le SJ.
Le système doit offrir un reporting suffisant pour détecter des éventuelles différences
entre les montants des factures reçues par la cellule finances et le solde disponible des
contrats qu’elles référencient.
4
1.3.1. Gestion des dossiers : référencement des affaires et accès aux documents
Chaque fois qu’une affaire a des implications financières, un dossier est créé dans le
système FINSJ.
Ce dossier référencie l’affaire concernée soit parmi les autres systèmes de gestion déjà en
place au SJ (CC, CNAT, WTO-LD courant 2006), soit provenant de systèmes extérieurs
au SJ ou encore de systèmes non informatisés. Dans le premier cas, l’utilisateur doit juste
sélectionner le bon dossier dans une liste reprenant un condensé des informations de
l’affaire (via le système SJDOSSIER) ; dans les autres cas, l’utilisateur crée une fiche en
introduisant les informations essentielles qui permettent d’identifier l’affaire dont il est
question.
Le système reprend l’identification des affaires telles qu’elles sont définies dans les
applications qui les gèrent.
Le détail du dossier offre la possibilité de consulter le détail de l’affaire depuis
l’application qui la gère, tout au moins pour les affaires provenant de systèmes en place
au SJ et pour autant que les droits de l’utilisateur le permettent.
1.3.2. Gestion contractuelle
FINSJ permet une gestion contractuelle de base pour les affaires du SJ pour lesquelles il
y a participation d’intervenants extérieurs (avocats).
Un contrat est le lien d’un dossier FINSJ avec un contractant. Il reprend notamment les
données suivantes :
– Le contractant (entité légale SI2)
– Le compte bancaire
– Le type de contrat (forfait, plafond)
– Le montant
– La devise
– La possibilité de frais annexes
– La référence utilisateur SI2 (référence à mentionner dans SI2 pour relier
facilement les mouvements avec le contrat FINSJ)
Les contrats FINSJ ont une identification SJ/CNT/Numéro (ex : SJ/CNT/10).
Un même dossier FINSJ peut être lié à plusieurs contrats, par exemple lorsqu’il y a
plusieurs avocats externes pour défendre une même affaire.
Un contrat peut être clôturé à tout moment. S’il reste un solde disponible, il doit faire
l’objet d’un avenant avec un montant négatif correspondant au solde.
5
1.3.3. Gestion des avenants
Il est possible de créer des avenants à un contrat, dans ce cas le nouveau contrat reprend
la majorité des informations de l’original et porte le même numéro auquel vient s’ajouter
le numéro d’avenant (ex :SJ/CNT/10 avt 1).
Lorsque l’on crée un avenant, il faut obligatoirement en préciser la raison. S’il s’agit
d’une modification du montant du contrat, le nouveau montant est introduit sous la forme
d’une variation du montant initial, positive ou négative. C’est l’application qui calcule le
nouveau montant total de l’avenant.
L’historique des avenants est consultable depuis le détail d’un contrat.
1.3.4. Gestion des dépens
En plus des contrats, il est possible d’encoder les dépens d’un dossier. Ces dépens sont
soit de type à payer ou à récupérer en fonction de l’aboutissement de l’affaire liée.
Ces informations permettent de savoir à tout moment quels sont les montants que la
commission devra payer ou récupérer suite à l’aboutissement d’une affaire.
1.3.5. Récupération et affectation des mouvements Sincom
Le système FinSJ récupère à intervalles réguliers (actuellement 1x/jour) les paiements et
ordres de recouvrement de Sincom qui ont atteint un niveau de workflow 100 (clôturé).
Cette récupération des données est effectuée par une procédure automatique qui, pour des
raisons de performances, importe seulement les informations utiles de la base Sincom
dans la base FinSJ. L’accès à ces informations est soumis aux règles de sécurité de la DG
BUDG et dépend des droits alloués au user opérationnel « FINSJ$ » qui est sous la
responsabilité du service finances du SJ.
Ces règles évolueront d’ailleurs prochainement selon la note BUDG D05 D(2006) 3848.
Ces mouvements sont présentés à l’utilisateur qui a la possibilité de les affecter à une ou
plusieurs activités (activité : nom générique représentant un contrat, un dépens ou des
frais hors contrats).
Dans le cas où un mouvement doit être ‘ventilé’ parmi plusieurs activités (p.ex. lorsqu’un
avocat fournit une seule facture concernant plusieurs dossiers dont il a la charge), c’est le
gestionnaire qui décide de la répartition du montant du montant du mouvement parmi les
différentes activités.
Afin d’assister le travail du gestionnaire, l’application permet de présenter les
mouvements non affectés des derniers 30 jours et propose automatiquement pour chacun
d’eux un choix de (maximum) 5 contrats susceptibles de correspondre.
Le système FinSJ n’affecte en aucun cas un mouvement de façon automatique, il ne fait
que proposer des choix que le gestionnaire pourra valider.
6
1.3.6. Recherche et modification d’une affectation
Le système permet de rechercher n’importe quel mouvement provenant de la base
Sincom 2 (accessibles au user FINSJ$) et au besoin de changer son affectation dans le
cas où cette dernière aurait été attribuée erronément.
1.3.7. Suivi des mouvements enregistrés sur une activité
Le système permet de visualiser, pour une activité donnée, la liste des opérations
enregistrées avec les applications de la DG BUDG (Sincom 2), le total déjà consommé et
le cas échéant le solde restant à disposition.
Ces informations tiennent compte de la devise, de la date valeur et appliquent le taux de
change en vigueur tel que défini par la DG BUDG.
1.3.8. Rapports
Le système offre des rapports clairs et complets permettant d’aider le service finance
dans ses tâches.
– Fiche récapitulative des mouvements sur un dossier, groupés par contrats,
dépens et frais avec totaux et soldes
– Fiche détaillée des mouvements d’une activité
D’autres rapports seront mis à disposition selon les besoins de la cellule finance.
1.3.9. Security
Only authorised persons, members of the SJ IT domain, have an access to the system.
They are assigned a single role or a combination of role. The available roles include:
• read-only role with no modifications allowed – the viewer
• standard user role that allow modification of data except – the accountant
• administrative role that allows all operations, including modifying the reference
tables – the system administrator
1.3.10. Data availability of the system
In case the DB BUDG database becomes unavailable, the system can still be used but the
data coming from BUDG would be dated as of the last successful synchronisation.
1.3.11. Consistency and non-redundancy
The system maintains the information in a consistent state. Integrity constraint are
defined and implemented whenever possible, while the use of a high level of
normalisation of data keeps the redundancy of information to a minimum.
7
1.3.12. Performance
The BUDG SI2 database is too slow to be accessed from FINSJ every time SI2 data is
needed. Therefore a copy of the interesting data to a local database will be made,
allowing shorter response times.
The local data will be refreshed each morning. This refresh rate can be changed if
necessary.
8
1.4. Non-functional requirements
The system must seamlessly integrate within other systems built within the Legal Service
that are available from the Intranet: CN (“Contentieux national”), CC (“Contentieux
Communautaire”).
1.4.1. Usability
The system meets a set of usability requirements.
1.4.1.1. User authentication / single sign-on.
This system is using the centralized authentication service of the commission: ECAS.
A user already authenticated with ECAS, even in another application, does not have to
supply a username and password again.
1.4.1.2. Web-based interface
The user interface of the system is entirely web-based. It should therefore be efficiently
used with minimal training. The system should verify a minimum set of usability
requirements for Web applications. Specifically:
• The user interface is of a ‘point and click’ type
• Frames or other mechanisms that make navigation cumbersome are not used
• The consistency of the user interface is preserved by presenting navigation in the
form of links, while actions are shown as buttons
• A consistent and simple layout is be applied to all pages
• Little or no graphics are used
• The layout reflects changes in the internet options chosen by the user, namely the
font size and font types. This is also an accessibility requirement.
• The information is organised and presented in “tabs” where relevant
• No navigation link is hidden or accessible only through non standard, non
explicit action such as control key etc.
• The system only shows the links or actions buttons that are relevant to the
context of the page displayed and only the actions and the menu links that are
allowed by the security profile of the user are shown
• The menus permit rapid navigation from one part of the system to another,
without having to follow a single, constraining, predetermined path
• Adequate feedback is given on the system status: waiting for input, waiting for a
request to be processed.
9
1.4.1.3. Flexible reporting
The system offers a set of predefined reports, available either from the menus or from a
page dedicated to the reporting.
The system allows easy preparation of reports: choice of criteria, of sorting options, of
displayed columns.
The system makes it possible to share a report definition among all users or to restrict its
use to its author only
Export facilities to file formats are implemented: any report is made available as plain
XHTML format so that it can be printed easily without the application layout, or as a file
compatible and editable with the Excel spreadsheet format.
In addition, a limited set of reports may be available in PDF format.
1.4.1.4. Online help
There is a small help text on every data field in entry forms (known as the ‘title’ of an
input). When required, there is additional help for complex forms or processing.
1.4.1.5. Reliability
The system shows explicit error messages when handling errors on data entry: incorrect
format or type, non-existence, etc.
The system provides mechanisms to gracefully handle other errors. In particular, errors
as reported by the database system are translated into specific and user-friendly
messages.
When a serious, unrecoverable error occurs, the system generates and displays an alert
message providing an accurate description of the incident. This message is automatically
sent for action to the Legal Service IT Group.
The system offers fast navigation mechanisms within a report, allowing the navigation to
the next and previous pages, as well as the start and end of the report that does not
exceed one second.
The time for initialisation of the system for a user (retrieval of security profile, logging
etc) should not exceed 5 seconds while navigation times from one ‘tab’ to the other do
not exceed one second. No query execution issued from the complex query search form
lasts more that 20 seconds.
1.4.2. Hosting, support and maintenance
System hosting, applicative support and maintenance is provided by the Legal Service IT
Group and complies with its quality plan.
1.4.3. Technical constraints
The system is comprised of at least the following components:
10
• A web application based on an application server, currently Coldfusion MX that
will be hosted on the production application server
• A web service to retrieve and present the information on group membership in
the Active Directory
• Information on the content of groups in each of the security.xml application files
• A database schema that will be hosted in an Oracle instance, on the production
database server
Communication between the web application and the web service occurs over https.
The database schema and the web application will both support the multi-alphabet
Unicode UTF-8 character set.
There are preferably three instances of the system: the real, live production version, a
development version where system evolutions are built and a test version that is used as a
playground for training or the evaluation of upcoming versions.
2. CAS D’UTILISATION
2.1. Recherche/création d’un dossier pour une affaire gérée par un système du SJ.
Le gestionnaire recherche le dossier en introduisant ses critères de recherche (domaine,
type, année, numéro). Une liste d’affaires répondant aux critères introduits lui est alors
présentée présentant un lien qui est soit bleu si le dossier FinSJ existe déjà, soit rouge si
celui-ci n’a pas encore été créé.
Si le gestionnaire sélectionne un lien bleu, il est dirigé vers le détail de ce dossier.
S’il choisit un lien rouge, le système FinSJ lui présente une fiche de création de dossier
pré remplie avec les informations récupérées du système de gestion de l’affaire choisie.
Le gestionnaire complète alors les informations nécessaire et puis sauvebarge le dossier.
2.2. Création d’un dossier pour une affaire gérée par un système externe au SJ.
Les informations de l’affaire ne pouvant pas être récupérées de façon automatique, le
gestionnaire crée un nouveau dossier FinSJ. Le système ne lui propose que les types de
dossiers qui ne sont pas gérés par le SJ.
Le gestionnaire introduit les données du dossier et puis sauvegarde.
L’application génère automatiquement la référence du dossier sur base d’un format
prédéfini pour le type de dossier choisi. C’est cette référence qui servira à identifier le
dossier à travers l’application.
2.3. Création d’un contrat.
Un nouveau contrat est créé dans le système chaque fois qu’un accord est conclu entre le
SJ et un intervenant extérieur (le plus souvent, un cabinet d’avocat).
11
Le gestionnaire recherche le dossier FinSJ pour lequel il veut créer un contrat et le
sélectionne.
Dans le détail du dossier, il choisit le bouton « Nouveau contrat » qui ouvre une fiche de
création de contrat pour le dossier choisi avec une référence SI2 pré remplie (excepté le
nom de l’avocat).
Il complète les informations manquantes et sauvegarde le contrat.
Ce contrat se voit attribuer un numéro de référence interne par l’application au format
SJ/CNT/xxx.
2.4. Création d’un dépens.
Un nouveau dépens est créé dans le système lorsqu’une affaire a été jugée et qu’il y a des
dépens à payer ou récupérer.
Le gestionnaire recherche le dossier FinSJ pour lequel il veut créer un dépens et le
sélectionne.
Dans le détail du dossier, il choisit le bouton « Nouveau dépens » qui ouvre une fiche de
création de dépens pour le dossier choisi avec une référence SI2 pré remplie (excepté le
nom de l’avocat).
Il complète les informations manquantes et sauvegarde le dépens.
Ce dépens se voit attribuer un numéro de référence interne par l’application au format
SJ/DPS/xxx.
2.5. Réception d’une facture
La facture reçue est enregistrée dans le système de gestion du courrier. Le document lui-
même est scanné et stocké dans le repository de documents du SJ.
Le gestionnaire vérifie s’il existe bien un contrat comme base à cette facture. Si ce
contrat n’existe pas, il doit être créé (cf. cas d’utilisation 2.3).
Par consultation du détail du contrat, il est possible de vérifier si cette facture n’a pas
déjà été payée, auquel cas il s’agirait probablement d’un rappel ou d’une erreur.
Le gestionnaire vérifie également que le montant de la facture ne dépasse pas le solde
disponible du contrat.
Si la facture est valide, elle est créée par le gestionnaire dans l’outil mis à disposition par
la DG BUDG (actuellement ABAC Invoice) en se servant de la référence SI2 générée par
FinSJ lors de la création du contrat comme description. Cette description permettra plus
tard d’affecter rapidement le mouvement Sincom 2 à l’activité FinSJ correspondante
lorsque le paiement sera effectué.
La facture est transmise pour validation par l’ordonnateur. Le gestionnaire génère alors
un ordre de paiement dans SI2, lequel est à son tour validé dans SI2 par l’Assistant du
Directeur général.
12
2.6. Création d’un avenant à un contrat
Lorsqu’il y a modification significative d’un contrat (p.ex. montant, devise, avocat,etc.),
il y a lieu de créer un avenant à ce contrat.
Le gestionnaire recherche et sélectionne le contrat en question.
Dans l’écran de détail du contrat, il appuie sur le bouton « Créer avenant » qui lui
présente l’écran d’un nouvel avenant reprenant les données du contrat initial sans date de
signature.
Le gestionnaire doit obligatoirement préciser la raison de cet avenant dans un champ
réservé à cet effet.
Lorsqu’il s’agit d’une modification du montant du contrat, il ne faut pas entrer le
nouveau montant mais une différence par rapport au montant initial, l’application calcule
automatiquement le montant final.
Lors de la sauvegarde, l’application remplace le contrat par son nouvel avenant. L’ancien
contrat est archivé et peut être consulté depuis le détail du contrat.
2.7. Affectation rapide d’un mouvement Sincom 2 à une activité
Le gestionnaire navigue sur l’écran d’affectation et choisi « Affectation rapide ».
L’écran lui propose alors la liste des mouvements Sincom 2 des 30 derniers jours qui
n’ont pas encore été affectés à une activité et, pour chaque mouvement, un choix de
(maximum) 5 activités pouvant correspondre.
Le gestionnaire peut, pour chaque mouvement, soit directement choisir l’activité qui
correspond, soit demander le détail du mouvement et définir manuellement l’affectation
(cf. cas d’utilisation 2.8) ou encore demander à ignorer ce mouvement de telle sorte qu’il
n’apparaisse plus dans la liste lors des prochaines consultations.
Le gestionnaire valide ses choix en sauvegardant.
2.8. Affectation détaillée d’un mouvement Sincom 2 à une activité
Le gestionnaire navigue sur l’écran d’affectation et défini ses critères pour retrouver les
mouvements à affecter puis lance la recherche.
Il sélectionne le mouvement souhaité depuis la liste et obtient un écran lui montrant le
détail du mouvement et la liste des activités déjà affectées à ce dernier.
Le gestionnaire ajoute l’(les) activité(s) souhaitée(s) au mouvement Sincom 2 et précise
le cas échéant la répartition du montant parmi les différentes activités.
Le gestionnaire valide ses choix en sauvegardant.
2.9. Création d’un tiers ou d’une entité légale
Le gestionnaire financier envoie un formulaire de signalétique financier (tiers) et légal
(entité légale) au créancier. Lorsque les formulaires complétés sont de retour, il les
encode dans SI2 et envoie une copie des documents à la DG BUDG pour validation.
13
La DG BUDG valide le tiers ou l’entité légale dans ses systèmes.
3. BUSINESS CASE
3.1. Diagramme de classes
14
3.2. Liste des classes
Dossier FinSJ
Référence à une affaire traité par le SJ dans le cadre de ses
activités. Cela peut être les dossiers d’affaires du contentieux
communautaire, national, les consultations, le contentieux
OMC, etc. Seuls les dossiers qui ont des implications financières
doivent être créés dans FinSJ.
Activité
Classe générique regroupant les contrats, dépens et autres frais
Contrat
Contrat liant un intervenant extérieur à un dossier FinSJ
définissant les services fournis et les montants convenus.
Dépens
Dépens découlant de l’aboutissement d’une affaire. Ils sont soit
à récupérer ou à payer
Autres Frais
Frais affairant directement au dossier et non à un contrat ou
dépens
Mouvement
Classe générique regroupant les paiements et recouvrements
Paiement
Payment requests ABAC introduits via l’application Sincom2.
Recouvrement
Recovery orders ABAC introduits via l’application Sincom2.
Affectation
Tiers
Bank Account ABAC. Représente l’identité bancaire d’un tiers.
Entité légale
Legal Entity ABAC. Représente l’identité légale d’un tiers.
15