Dies ist eine HTML Version eines Anhanges der Informationsfreiheitsanfrage 'SJ-Datenbanken'.

 
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 
 
 


 
 
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 


 
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. 


 
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. 


 
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. 


 
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. 


 
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. 


 
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. 


 
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