Télécharger le cahier des charges

Direction Générale de l'Administration et du Patrimoine
Direction du Budget et des Approvisionnements
DOSSIER D'APPEL D'OFFRES
N°2014/AO/AM/020
SELECTION D'UN PRESTATAIRE POUR L'ACCOMPAGNEMENT DES EQUIPES
INFORMATIQUES DE LA BANQUE CENTRALE DES ETATS DE L'AFRIQUE DE
L'OUEST POUR LA MIGRATION TECHNIQUE DE SON SYSTEME DE GESTION
ADMINISTRATIVE ET COMPTABLE DENOMME CAFIS
OCTOBRE 2014
Avenue Abdoulaye FADIGA
BP 3108 – Dakar - Sénégal
Tel. (221) 33 839 05 00 / Fax. (221) 33 823 93 35
www.bceao.int
2
GLOSSAIRE
BAOBAB : Système de gestion des opérations de caisse et de guichet de la BCEAO
BCEAO : Banque Centrale des Etats de l'Afrique de l'Ouest
CAFIS : Système d'information administratif et comptable de la BCEAO
ERP : Enterprise resource planning ou Progiciel de gestion intégré
GOREH : Système de gestion des ressources humaines de la BCEAO
IAS/IFRS : Normes internationales d'information financière
SICA-UEMOA : Système Interbancaire de compensation automatisée de l'UEMOA
STAR-UEMOA : Système de règlement brut en temps réel de l'UEMOA
SWIFT : Système de messagerie financière de la Society for Worldwide Interbank Financial
Telecommunication
TRANSFERTS : Système de gestion des transferts et des mises à disposition de fonds de la
BCEAO
UEMOA : Union Economique et Monétaire Ouest Africaine
UMOA : Union Monétaire Ouest Africaine
ZABBIX : Système centralisé de supervision des systèmes utilisés par la BCEAO
3
I - CONTEXTE
La Banque Centrale des Etats de l'Afrique de l'Ouest (BCEAO) est un établissement public
international dont le Siège est situé à Dakar, au Sénégal.
La BCEAO est l'Institut d'émission commun aux huit (8) États membres de l'Union Monétaire
Ouest Africaine (UMOA) que sont le Bénin, le Burkina, la Côte d'Ivoire, la Guinée-Bissau, le
Mali, le Niger, le Sénégal et le Togo.
Le système d'information administratif et comptable de la BCEAO, dénommé CAFIS, repose
principalement sur le progiciel Oracle Applications. CAFIS permet de gérer la comptabilité
générale, la comptabilité budgétaire, les fournisseurs et les achats.
Il s’appuie sur les modules d'Oracle Applications ci-après :
•
General Ledger (GL) pour la comptabilité générale et budgétaire ;
•
Purchasing Order (PO) pour les achats (commandes et réceptions) ;
•
Account Payables (AP) pour les fournisseurs (banques, comptes bancaires, factures et
règlements) ;
•
Inventory Control (IC) pour les stocks (codification des articles).
Afin de répondre aux besoins spécifiques de la BCEAO, des développements ont été réalisés
dans Oracle Applications, avec Oracle Developer Suite 6i. Ces développements portent sur la
réalisation de plusieurs programmes PL/SQL, formulaires, états et paramétrages spécifiques
basés sur des clés flexibles et des champs anonymes de tables de Oracle Applications.
La sécurité de CAFIS a également été renforcée avec des adaptations spécifiques. Par
ailleurs, un interpréteur d'événements comptables a été développé pour intégrer une
comptabilité événementielle dans le système CAFIS.
Les principales fonctionnalités de CAFIS sont présentées dans le chapitre y afférent.
Le système CAFIS est en service à la Banque Centrale depuis janvier 2004. A ce jour, les
versions utilisées sont :
•
Oracle Applications Release 11.5.8 fonctionnant sur Red Hat Enterprise Linux AS
Release 3 Update 2, pour le serveur d'applications ;
•
Oracle v8i Enterprise edition Release 8.1.7.4.0 tournant sur Red Hat Enterprise Linux
AS Release 3 Update 4, pour la base de données.
La BCEAO dispose d’autres applications métier interagissant avec le système CAFIS,
notamment la solution de gestion des ressources humaines et de la paie (GOREH) qui est
dans une autre instance d’Oracle e-Business Suite 11i (11,5,10,2). Les événements
comptables générés par ces applications en amont sont traduits par l'interpréteur comptable et
déversés dans Oracle GL via la table GL_INTERFACE ; à l’exception des modules Oracle,
notamment PAYROLL, gérés au niveau du système de gestion des ressources humaines qui
envoient directement leurs écritures comptables dans GL_INTERFACE.
Une interface de génération des paiements électroniques a également été réalisée en interne
pour dispatcher les règlements du module AP vers les systèmes de règlement, notamment
BAOBAB, SWIFT via TRANSFERTS, ainsi que STAR-UEMOA et SICA-UEMOA via BAOBAB.
4
II - OBJECTIFS DE LA MISSION
La présente consultation a pour objectif de sélectionner un prestataire qui
accompagnera les équipes informatiques de la Banque dans la migration du socle
technique du système CAFIS. A ce titre, il devra en collaboration avec les équipes
internes, réaliser les prestations ci-après.
1. Migration de l’application CAFIS
Il s'agira de procéder à une ré-implémentation du système CAFIS avec les dernières
versions compatibles des logiciels de base, notamment Oracle e-Business Suite R12
pour le serveur d'applications et Oracle Database 11g pour le système de gestion des
bases de données.
La ré-implémentation consistera en :
•
l’installation des dernières versions des outils nécessaires à l’implémentation des
fonctionnalités attendues par la Banque ;
•
la reprise du paramétrage des modules nécessaires à la couverture des besoins
fonctionnels ;
•
la reprise de toutes les données existantes du système actuel (11i) vers le système
futur (R12) ;
•
la reprise des développements spécifiques dans la nouvelle solution, de préférence
avec les fonctionnalités standards de la R12 ;
•
la reprise des états existants avec les nouveaux outils d'élaboration des rapports.
Par ailleurs, les préoccupations ci-après doivent être prises en charge par le projet :
•
la mise en œuvre dans le nouveau système, d'une fonction d'archivage périodique des
données ;
•
l’analyse et la ré-implémentation des développements spécifiques liés à la gestion de
la sécurité en réduisant sa très forte dépendance de l'organigramme de la Banque ;
•
l'analyse et la redéfinition de la politique de gestion multi-devise en utilisant les
standards tout en conservant les fonctionnalités de l’ancien système ;
•
la définition d'une stratégie de lettrage des comptes et son activation dans CAFIS, en
vue de l'automatisation de leur analyse et de leur justification ;
•
la mise en conformité des états comptables au format IAS/IFRS ;
•
le renforcement des pistes d'audit des applications afin de permettre la consultation de
toutes les actions effectuées sur les comptes et les profils des utilisateurs ainsi que sur
les données métiers (pièces comptables, commandes, réceptions, factures,
règlements, etc) ;
•
l'activation des journaux d'audit sur les bases de données ainsi que les journaux
système afin de tracer toutes les activités des administrateurs, notamment celles
effectuées par des requêtes SQL ;
•
la configuration des paramètres de sécurité des comptes utilisateurs et des mots de
passe (déconnexion automatique au bout de 30 secondes, durée de vie des mots de
passe de 90 jours, désactivation automatique des comptes dormants après 90 jours,
règles de complexité des mots de passe, etc).
•
l'évaluation et la mise en conformité des licences d'utilisation des différents modules
d'Oracle par rapport au nombre réel d'utilisateurs à la BCEAO.
2. Transfert de compétences
Le soumissionnaire devra procéder à un transfert de compétences aux équipes
informatiques de la Banque afin de faciliter et garantir leur implication pleine et entière
dans les travaux du projet de migration, notamment pour le paramétrage et la
5
personnalisation des modules d'Oracle EBS R12 selon les règles de l'art, d'une part, et
pour l'implémentation, l'administration ainsi que l'exploitation du nouveau système
CAFIS à l'issue du projet, d'autre part.
Il devra également former à l'utilisation des nouveaux outils l'équipe projet de la BCEAO qui se
chargera par la suite de répercuter cette formation aux autres utilisateurs de la Banque.
Les soumissionnaires devront ainsi proposer dans leurs offres un plan de formation et
d’accompagnement cohérent qui permettra dans un premier temps aux équipes internes de
participer activement aux travaux de migration, puis dans un second temps, d'assurer la
maîtrise fonctionnelle et technique des systèmes.
Ce plan devra préciser clairement les modalités de mise en œuvre du transfert de
compétences ainsi que le contenu de chaque module de formation.
Le plan de formation devra être mis en œuvre en collaboration avec un organisme de
formation agréé par Oracle de préférence dans les locaux de la Banque, à son Siège à
Dakar.
3. Fourniture de la documentation
La documentation complète de la solution, décrivant l’ensemble des tâches d'exploitation et de
maintenance ainsi que celles de configuration et de paramétrage des systèmes, doit être
élaborée dans le cadre du projet. Cette documentation doit comprendre, notamment :
•
les dossiers de paramétrage et de configuration des systèmes ;
•
les dossiers de spécifications fonctionnelles et techniques détaillées, ainsi que les
adaptations et interfaces réalisées spécifiquement pour la BCEAO ;
•
les manuels utilisateurs et guides de formation ;
•
les guides d’installation et d’exploitation du système.
Toute la documentation sera rédigée en français.
4. Résultats attendus
A l'issue du projet, les résultats ci-après devront être atteints :
•
le système CAFIS en production avec la version R12 de Oracle EBS, reprenant le
paramétrage et les développements spécifiques existants ;
•
la reprise complète de toutes les données existantes ;
•
la prise en compte des nouvelles contraintes et orientations souhaitées ;
•
la fourniture de la documentation de l'ensemble du projet ;
•
l'élaboration du paramétrage, des spécifications fonctionnelles et techniques des
développements spécifiques ;
•
la réalisation des manuels de formation et guides utilisateur spécifiques à la nouvelle
version d'Oracle ;
•
le transfert de compétences effectif aux équipes internes de la BCEAO sur l'ensemble
des solutions mises en œuvre dans le cadre du projet ;
•
l'évaluation et la mise en conformité des licences d'utilisation des modules Oracle et
des bases de données par rapport à l'effectif réel des utilisateurs de la Banque
Centrale.
6
III - DESCRIPTION ET CRITIQUE DU SYSTEME ACTUEL
1. Principales fonctionnalités du système CAFIS
a- Imputation des pièces
Toutes les pièces comptables, quelles que soient leurs origines, doivent être imputées dans
Oracle GL. Les pièces saisies manuellement dans Oracle GL suivent un processus de
validation. Les écritures provenant des modules en amont doivent d’abord être importées
après leur transfert dans une table nommée GL_Interface. Elles sont imputées
automatiquement. Après imputation, la contre-passation est le seul moyen d’annuler l’écriture.
b- Gestion des périodes comptables
Dans le système CAFIS, les soldes des comptes sont constitués en temps réel, au fur et à
mesure que les écritures sont imputées. Les états légaux sont imprimés en fin de mois, après
la clôture de la période. Toutefois, la possibilité reste offerte de définir des périodes
comptables plus rapprochées. Les ouvertures et fermetures de périodes se font au Siège pour
l'ensemble des sites par un responsable autorisé.
c- Pistes d’audit
L'existence de pistes d'audit permet, à partir d'un enregistrement comptable dans Oracle GL,
de remonter les opérations jusqu’à l’origine de l’événement. A titre d'illustration, à partir d’une
écriture comptable, il est possible d'accéder au règlement, du règlement à la facture, et de la
facture à la commande.
d- Harmonisation des nomenclatures comptable et budgétaire
Les nomenclatures comptable et budgétaire sont harmonisées pour la mise en place d’un
contrôle budgétaire automatisé.
Pour un compte budgétisable, le crédit disponible peut être déterminé automatiquement par le
système, en fonction des crédits accordés, des engagements et des réalisations.
e- Contrôle budgétaire
Le contrôle du disponible est une fonctionnalité du contrôle budgétaire permettant d'éviter
toute dépense au-delà du budget alloué. Cette vérification du crédit budgétaire disponible est
effectuée avant l'exécution d'une transaction. Il est ainsi possible de contrôler les mouvements
par rapport au budget disponible et de mettre immédiatement ce dernier à jour.
f- Gestion centralisée des dotations
La gestion centralisée des dotations budgétaires facilite la gestion des dépenses transférées
dans la mesure où un site peut engager une dépense pour un autre, en impactant en temps
réel le budget du site concerné par la dépense. Cette transaction requiert une approbation
préalable du site qui supporte la dépense.
g- Lettrage des comptes
Le module Oracle GL dispose d'un sous-module de lettrage des comptes qui facilite la
justification des comptes. En effet, les comptes à justifier sont déclarés « lettrable » dans le
système pour rendre obligatoire le code lettrage lors de la saisie ou de la génération
d'écritures portant sur ces comptes.
h- Gestion automatique du compte de liaison
Lorsqu'une pièce comptable ou d'engagement impacte plusieurs sites, le système génère
automatiquement lors de l'imputation, les écritures inter-sites qui permettent l'équilibre des
pièces au niveau de chaque site. Cette gestion automatique du compte de liaison, permet de
disposer de balance équilibrée sur chacun des sites.
7
i- Comptabilité fournisseur
Les modules Achats et Fournisseurs d'Oracle Applications permettent à la Banque de tenir une
comptabilité Fournisseur. Tous les détails des opérations d'achats sont gérés en amont par ces
applications ; les synthèses étant enregistrées en comptabilité générale à travers des comptes
fournisseurs ouverts à cet effet.
Cette comptabilité auxiliaire permet d'avoir à tout moment :
•
la position nette d'un fournisseur vis-à-vis de la Banque ;
•
les acomptes payés à un fournisseur et non encore soldés ;
•
les factures en instance de règlement ;
•
les factures non parvenues d'un fournisseur ;
•
les règlements effectués par facture et par fournisseur ;
•
le rapprochement automatique des acomptes avec les factures ;
•
le rapprochement automatique entre facture et commande.
Toutes les dépenses internes telles que la régie d'avance, les dépenses sociales et les jetons
de présence sont également gérées par le module Fournisseurs. Ceci permet de bénéficier de
toute la richesse fonctionnelle offerte par cette application, notamment la génération
automatique des écritures comptables et des engagements liés à ces types de dépenses.
j- Gestion des commandes
Le module Oracle PO permet la saisie des commandes et réceptions de biens et services. Les
commandes sont passées auprès des fournisseurs, sur la base des articles codifiés dans le
module Oracle IC.
Les fonctions de saisie des commandes et des réceptions ne sont accessibles que par les
agents déclarés « Acheteur ». Par ailleurs, les commandes doivent suivre le circuit
d'approbation défini au niveau de chaque site. Toutefois, les commandes inter-sites sont
transmises pour approbation, au responsable du budget du site concerné par la dépense.
k- Interpréteur d’événements comptables
L'interpréteur comptable développé en interne, est un middleware entre la comptabilité et les
applications spécifiques. En effet, toutes les opérations à incidence comptable initiées ou
engendrées par les applications spécifiques sont traduites en événements comptables. Ces
événements sont ensuite soumis à l’interpréteur qui s’appuie sur des schémas de
comptabilisation pour les traduire en écritures comptables.
ORACLE APPLICATION
AP/PO
A
INTERPRETEUR
D’EVENEMENTS
COMPTABLE
C
AUTRES
APPLICATIONS
GENERANTS
DES
EVENEMENTS
COMPTABLES
B
GL
Le cœur de l’interpréteur est constitué d’un processus s’exécutant à une fréquence
paramétrable. Les écritures comptables ainsi générées sont insérées automatiquement dans
le module GL.
8
Le processus de génération est le module principal de l’interpréteur. A chaque exécution, il
récupère les événements non encore générés ou générés précédemment avec erreurs puis
les traduit en écritures comptables en s’appuyant sur les schémas correspondants.
L’interpréteur permet de visualiser, pour une date et une application données, les événements
qui n’ont pas pu être traduits en écritures comptables. Les échecs peuvent être dus à une
absence de schéma de comptabilisation ou à un manque d’information pour traiter
l’événement.
2. Architecture technique
L’architecture technique actuelle de la BCEAO repose sur un environnement virtualisé avec
VMWARE 5 utilisant les ressources physiques d’un cluster à double nœuds.
Le serveur de données abrite une base Oracle 8i (8.1.7) avec le gestionnaire de traitement
(GTS).
Le serveur d’application exécutant la version e-business suite 11i (11.5.8) est connecté aux
clients via le LAN pour le Siège et un réseau VSAT pour les Agences.
Tous les deux serveurs tournent en trente-deux bits (32 bits) sous Red Hat Enterprise Linux
AS, Release 3 Update 2, pour le serveur d'applications et Release 3 Update 4, pour la base de
données.
Enfin, la Banque Centrale souscrit annuellement à un support qui lui permet de bénéficier des
nouvelles versions des produits Oracle qu'elle utilise.
3. Etat des lieux des développements spécifiques
En vue de garantir la sécurité des données et la fiabilité des procédures, la Banque Centrale a
réalisé des développements spécifiques dans Oracle applications. Le principe général retenu
dans ce cadre est la sauvegarde des programmes originaux, puis l’application des
développements spécifiques de la Banque Centrale sur une copie.
Les différentes catégories de développements spécifiques sont décrites ci-après :
a - La sécurité d’accès :
L’accès aux données de l’application CAFIS est fonction de l’initiateur via son affectation au
sein de l’organigramme de la BCEAO. Ainsi, il n’a accès qu’aux données initiées par lui-même
ou par un agent affecté à la même organisation que lui. Cette sécurité a été implémentée dans
GL et dans les modules auxiliaires.
b - Les traitements à la demande
Plusieurs traitements ont été mis en place pour répondre aux besoins des utilisateurs. Ils
portent principalement sur :
•
le nivellement des comptes ;
•
le décompte des intérêts sur certains comptes de dépôt ;
•
la réévaluation des comptes en devises ;
•
l'automatisation des paiements électroniques issus du module AP ;
•
l'automatisation des travaux de la clôture.
c - Les contrôles de cohérence
En plus des contrôles réalisés en standard par les règles de validation croisée et les règles de
sécurité, plusieurs attributs ont été ajoutés sur les valeurs du segment Compte permettant de
réaliser un certain nombre de contrôles spécifiques. Ces contrôles concernent principalement :
•
l’utilisation des comptes en devises ;
9
•
les opérations de caisse avec des comptes d’encaisse et l’autorisation exclusive aux
utilisateurs des services de caisse ;
•
les comptes manipulables exclusivement en intra-site ;
•
les comptes avec obligation de saisie de code de lettrage ;
•
les comptes avec saisie obligatoire de la date de valeur ;
•
les comptes spécifiques aux opérations FMI.
d - Reporting de gestion
Les états standards livrés avec Oracle EBS étaient pour la plupart inexploitables par la
Banque Centrale en raison des exigences de forme et parfois de contenu. Ainsi, l’ensemble
des rapports a été repris en interne. Ces états ont été intégrés dans l’ERP sous forme de
traitements simultanés. Tous les domaines sont concernés, notamment la comptabilité et le
budget, les modules auxiliaires et les extractions à la demande.
4. Volumétrie des développements spécifiques
La BCEAO a recensé environ cent vingt (120) programmes spécifiques en dehors des
rapports. Le tableau ci-dessous donne un aperçu du volume d’objets qui utilisent ces
programmes.
Type objet
Nombre
Oracle FORMS créés
5
FORMS EBS réadaptés
15
Oracle Reports
200
Autres programmes simultanés
50
Interface
10
5. Bilan critique du dispositif actuel
L'analyse du système actuel de la Banque fait ressortir les faiblesses ci-après :
1. les plate-formes techniques qui sous-tendent le système CAFIS sont obsolètes et ne
sont plus supportées par l'éditeur Oracle ;
2. les développements spécifiques réalisés dans CAFIS sont trop sensibles aux
migrations des systèmes de base ;
3. la gestion de la sécurité est très dépendante de l'organigramme de la Banque ; ce qui
induit des difficultés à prendre en charge les changements d'organisation dans le
système ;
4. les pistes d'audit ne sont pas exhaustives ; elles ne retiennent que les actions
effectuées lors de la création des pièces et la dernière modification les impactant ;
5. certaines tâches relevant des métiers sont toujours exécutées par les équipes
informatiques, notamment la création des comptes comptables ;
6. les états comptables édités actuellement à partir de CAFIS ne répondent pas aux
dispositions prévues par le référentiel IAS/IFRS ;
7. les travaux d'analyse et de justification des comptes sont réalisés manuellement,
induisant une grande mobilisation de ressources ainsi qu'une rallonge des délais de
production de certains états en raison de l'absence de fonctions automatiques de
lettrage de comptes.
10
IV - BESOINS ET ORIENTATIONS
1. Nouvelles fonctionnalités attendues
Lettrage automatique des comptes
Une stratégie de lettrage des comptes devra être définie et les fonctions de lettrage
automatique devront être activées dans GL afin de permettre, notamment :
•
l'attribution automatique d'un code lettrage à toutes les opérations générées sur un
compte déclaré lettrable quelle que soit l'application d'origine ;
•
la définition de principes de codification et l'harmonisation des codes lettrages
attribués automatiquement aux écritures générées sur un compte, pour une opération
donnée, y compris les opérations « groupées » pour lesquelles des montants globaux
portés dans un compte font l'objet d'apurements individuels (cas des virements de
salaire) ;
•
l'introduction d'une option permettant un traitement automatique de l'historique des
suspens. Il s'agira d'identifier et de marquer comme non lettrées les opérations en
suspens sur un compte à une date de référence donnée et permettre le lettrage
automatique de toutes les autres opérations sur ledit compte depuis le démarrage de
« CAFIS » en janvier 2004. Cette fonctionnalité permettrait ainsi de lever les difficultés
actuelles du programme de lettrage automatique liées à la prise en compte de
l'ensemble des opérations non lettrées depuis 2004 et apurées à ce jour ;
•
la création d'un état pouvant servir d'état justificatif de solde de compte, dont l'édition
sera possible à partir de GL. Cet état devra être conçu « par Service » et « par Site ».
Mise en conformité des états comptables au format IFRS
Les états comptables édités à partir de la nouvelle version de CAFIS doivent répondre aux
dispositions prévues par le référentiel IAS/IFRS.
Données historiques et archivage
Les fonctions d'archivage de données devront être mises en œuvre dans CAFIS afin d'offrir la
possibilité d'alléger périodiquement les serveurs de production.
Néanmoins, eu égard aux contraintes réglementaires qui exigent une disponibilité en ligne des
données durant au moins dix (10) ans pour l’ensemble des sites de la Banque Centrale, des
fonctions de consultation des données archivées devront également être implémentées dans
CAFIS.
En conséquence, les soumissionnaires devront décrire les fonctionnalités prévues dans leur
solution pour l’archivage des données existantes ainsi que les dispositifs pouvant être mis en
œuvre pour la consultation des données archivées.
Enfin, les données archivées doivent préserver les pistes d’audit et les règles de sécurité liées
aux accès.
2. Orientations techniques
a - Architecture technique cible
La nouvelle solution CAFIS sera hébergée dans les mêmes conditions que le système existant
à savoir sur des plate-formes ouvertes, et dans un environnement de haute disponibilité.
Le Datacenter de la Banque est réparti sur trois (3) sites : un site principal, un site de haute
disponibilité et un site de secours.
11
Le site principal et celui de haute disponibilité sont tous deux localisés à Dakar et distants de 4
km environ. Ils sont reliés par une boucle en fibre optique. Quant au site de secours, il est situé
dans un autre pays de l'Union et relié au site principal par une liaison de télécommunication de
type VSAT avec un débit nominal de 20 Mo.
Chaque site de la Banque (au nombre de 25 au total) est doté d'un réseau local de type
Ethernet 10/100/1000 pour la connexion de l'ensemble des équipements. Les réseaux locaux
sont interconnectés à l'aide d'un réseau de télécommunication de type VSAT.
Le système CAFIS sera centralisé au Siège de la Banque Centrale. Il sera hébergé par des
machines virtuelles tournant en environnement VMWare ESXi 5.0.0. et sur les dernières
distributions Redhat en architecture 64 bits.
b - Supervision des systèmes
La supervision centralisée des systèmes sera assurée à l'aide de la solution ZABBIX.
Néanmoins, des composants et outils nécessaires à l'administration et à la supervision
technique des systèmes de base (scripts, outils de monitoring des échanges, des
performances du système) doivent être mis en œuvre dans le cadre du projet.
c - Poste de travail
Les systèmes d'exploitation disponibles sur les postes de travail de la Banque sont pour
l’essentiel Microsoft Windows 7, 64 bits, SP 1 avec 4Go RAM.
Les postes de travail disposent également du logiciel de bureautique OpenOffice ainsi que des
navigateurs web Mozilla et Internet Explorer.
d - Performances
La nouvelle architecture du système CAFIS devra intégrer les problématiques liées à la
gestion des performances et de la disponibilité requises par les métiers. En termes de niveau
de service :
•
la disponibilité du système doit être totale 24h/24 et 7j/7 ;
•
le temps de réponse moyen aux requêtes des utilisateurs à partir des sites distants doit
être de 30 secondes ;
•
le nombre d'utilisateurs potentiels de CAFIS est estimé à 500 personnes ;
•
l'espace disque occupé actuellement par les données du système CAFIS est de
125 Go.
Les soumissionnaires devront proposer une architecture technique et préciser les
caractéristiques des infrastructures nécessaires pour garantir ces niveaux de services.
Ils devront également préciser dans leurs offres, les évolutions à apporter aux infrastructures
techniques, notamment en termes de processeurs et de mémoire serveur, en fonction de
l'accroissement du nombre d'utilisateurs et du volume de données.
12
V - DISPOSITIONS GENERALES
Toute offre qui ne répondra pas explicitement aux exigences du cahier des charges pourrait
être rejetée pour non conformité.
1. Découpage des lots
Les soumissionnaires sont invités à présenter une offre forfaitaire et globale en un lot unique
et indivisible. Cependant, la BCEAO se réserve le droit de modifier la composition et les
quantités de ce lot sans toutefois que les variations à la baisse n'excèdent 15% de la
composition d'origine.
2. Démarche de mise en œuvre
Les soumissionnaires devront présenter dans leur offre une démarche méthodologique
prenant en compte toutes les phases de ré-implémentation du système CAFIS. Cette
démarche devra être accompagnée d’un planning global du projet faisant ressortir les
différents jalons ainsi que les ressources utilisées.
Ils devront également fournir une démarche pour la reprise des données ainsi qu’un plan de
bascule lors de la mise en production.
Les soumissionnaires doivent par ailleurs fournir les prérequis nécessaires à l’exécution du
plan de projet ainsi que les phases durant lesquelles ces prérequis doivent être disponibles.
Le planning, le plan de reprise et le plan de bascule proposés pourront faire l’objet d’un
réajustement lors de la mise en œuvre du projet conformément au Cadre méthodologique de
conduite de projet de la Banque Centrale.
3. Profil du Consultant
Cette mission sera confiée à un prestataire qualifié et expérimenté, disposant de compétences
avérées sur les technologies Oracle Applications, en l'occurrence sur les versions utilisées par
la BCEAO ainsi que les versions cibles.
Ce faisant, l’équipe du prestataire devra être composée d'experts (Architecte, DBA,
Développeur, Fonctionnel) maîtrisant la Release 11.5.8 de Oracle Applications et Oracle EBS
R12 ainsi que les bases de données Oracle v8i Enterprise Edition et Oracle Database 11g, et
ayant déjà réalisé des migrations réussies de Oracle Applications vers Oracle EBS R12,
notamment sur les modules GL, AP et PO.
La distribution Redhat du système d'exploitation Linux doit être familière aux membres de
cette équipe.
4. Preuves et agréments
Les soumissionnaires doivent produire dans leur offre les certificats et curriculum vitae
attestant que les personnes de leur équipe affectée au projet de migration du système CAFIS
et à la formation des agents de la Banque, ont les qualifications requises pour réaliser de telles
prestations.
5. Références similaires
Les soumissionnaires doivent justifier d'une expérience avérée dans la conduite et la
réalisation de projets similaires dans des institutions financières similaires à la BCEAO et
présenter les références y afférentes.
6. Chronogramme de réalisation
Les soumissionnaires doivent préciser dans leur offre la durée de réalisation des prestations, à
compter de la date de signature du contrat. Ils doivent en outre proposer un planning détaillé
des tâches à réaliser et le budget temps d'intervention des membres de leur équipe ainsi que
les livrables à produire.
13
Par ailleurs, ils doivent préciser les tâches qui seront dévolues aux équipes internes de
la Banque avec la charge prévisionnelle requise en jour homme.
Les membres de l'équipe de la Banque Centrale pressentis pour participer au projet répondent
aux profils ci-après :
Profil
Nombre
Chef de projet
Fonctionnel
(informatique
et métiers)
Développeur
DBA
Maîtrise des solutions Oracle
PL/SQL
Oracle DB 8i
Oracle eBS 11i
Developper 6i
1
Non
Non
Non
Non
1
Oui
Non
Oui
Oui
8
Non
Non
Oui
Non
1
Oui
Non
Oui
Oui
2
Non
Non
Non
Non
1
Oui
Oui
Non
Oui
2
Oui
Oui
Non
Non
Une préférence sera accordée aux offres qui seront bâties sur une forte implication des
équipes internes de la Banque dans la mise en œuvre du projet.
7. Période de validité des offres
La validité des offres devra être d'au moins cent-vingt (120) jours à compter de la date de
dépôt.
8. Langue de soumission
L'offre, ainsi que toutes les correspondances et tous les documents concernant la soumission,
échangés entre le soumissionnaire et la Banque Centrale, seront rédigés en langue française.
9. Monnaie de soumission et de paiement
La monnaie utilisée est le Franc CFA. Toutefois, l'Euro est accepté pour les fournisseurs
établis hors de la zone CFA.
10. Présentation des offres
Les offres, établies en trois (03) exemplaires (un original et deux copies), devront être
présentées sous double enveloppe fermée, l'enveloppe externe portant la mention
« Appel d'offres pour la sélection d'un prestataire pour l'accompagnement des équipes
informatiques de la BCEAO pour la migration technique de son système de gestion
administrative et comptable dénommé CAFIS ».
Les enveloppes intérieure et extérieure doivent être adressées à Monsieur le Directeur du
Budget et des Approvisionnements.
Les enveloppes intérieures comportent en outre le nom et l'adresse du soumissionnaire.
Chaque exemplaire des offres sera présenté en trois (3) parties distinctes comme suit :
1. présentation de la société ;
2. offre technique ;
3. offre financière.
14
10.1. Présentation de la société et/ou des sous-traitants
Les soumissionnaires doivent fournir les informations ci-après :
•
présentation de la société,
•
principales références similaires (Déploiement d'Oracle EBS R12, notamment sur les
modules GL, AP et PO) ,
•
références financières (chiffres d'affaires et résultats des trois (3) derniers exercices).
10.2. Offre technique
Les offres techniques doivent être présentées conformément aux dispositions ci-après :
1. Présentation synthétique de l’offre ;
2. Stratégie de migration ;
3. Plan de formation ;
4. Plan de reprise des données existantes ;
5. Plan de déploiement et de basculement ;
6. Méthodologie et approche de mise en œuvre du projet ;
7. Chronogramme détaillé de réalisation et durée de la prestation ;
8. Descriptif des tâches et des livrables ;
9. Organisation de l’équipe d’intervention et les curriculum vitae des intervenants ;
10. Prérequis et budget temps des intervenants (en jours/homme), par profil ;
11. Tout autre document que le prestataire juge nécessaire à la bonne compréhension et à
la qualité de son offre.
10.3 Offre financière
10.3.1. L'offre financière doit être exprimée hors taxes et hors douane en francs CFA ou en
euros. Elle devra inclure tous les frais de déplacement et de séjour. La Banque Centrale ne
s'occupera pas de l'organisation des déplacements et du séjour du prestataire qui devra
évaluer les frais y afférents et les inclure dans son offre financière.
Les conditions devront être détaillées (en nombre ou volume horaire et prix) en faisant ressortir
notamment les éléments ci-après :
•
honoraires ;
•
frais de déplacement ;
•
frais de séjour ;
•
frais de logistique (secrétariat, télécommunication, etc.).
10.3.2. Toute prestation ou tout service proposé par le prestataire dans son offre et pour lequel
aucun prix n’est fourni, sera considéré comme inclus dans l’offre principale et ne donnera pas
lieu à aucune facturation supplémentaire.
11. Lettre type de soumission
Le soumissionnaire présentera son offre en remplissant le formulaire joint en annexe I
(Formulaire de soumission).
15
12. Date et lieu de dépôt des offres
Les offres devront être déposées au Siège de la BCEAO, à l'Avenue Abdoulaye FADIGA –
BP 3108 DAKAR - Sénégal, au bureau 509 du 5e étage de la Tour le vendredi 21 novembre
2014 à 17 heures TU au plus tard, délai de rigueur.
En ce qui concerne les offres transmises par courrier, le cachet de l'expéditeur (Poste, DHL,
CHRONOPOST, EMS...) indiqué sur le pli fera foi.
13. Confidentialité
Dans le cadre de la mission, chaque partie s'engage à préserver le caractère confidentiel de
toute information communiquée comme telle. Ainsi, le prestataire est tenu notamment, de :
✔ garder confidentiels tous documents et informations de quelque nature qu'ils soient,
qui lui ont été communiqués par la BCEAO ou dont il a eu connaissance, quels qu'en
soient la forme, le support et le contenu, dans le cadre de l'exécution de ses
prestations ;
✔ n'utiliser ces documents et informations qu'aux seules fins d'exécuter le marché. En
conséquence, même après la cessation du contrat, le prestataire ne peut les
communiquer à des tiers ou les exploiter dans ses relations avec ceux-ci, sans avoir
obtenu, au préalable, l'autorisation écrite de la BCEAO ;
✔ prendre toutes les dispositions nécessaires, notamment auprès des membres de son
personnel appelés à prendre connaissance de ces documents ou à connaître ces
informations, et dont le prestataire répond entièrement en la matière, pour prévenir et
éviter leur divulgation à des tiers, de quelque manière que ce soit ;
✔ restituer sans délai à la BCEAO, à sa demande, au terme de l'exécution de la
présente mission ou à la date de sa prise d'effet, les documents, rapports et données
et autres informations qu'elle juge confidentiels.
14. Ouverture de plis et évaluation des offres
Une Commission des Marchés procédera à l'ouverture des plis, à la vérification de la
conformité, à l'évaluation et au classement des offres reçues.
Il n'est pas exigé de garantie de soumission. Les pièces administratives et financières attestant
de la régularité de l'entreprise soumissionnaire ainsi que de sa capacité financière pourraient
être exigées avant la passation du marché.
Pour l'évaluation des offres, la Banque Centrale prendra en compte les ajustements apportés
au prix, le cas échéant, pour rectifier les erreurs arithmétiques. S'il y a contradiction entre le
prix indiqué en lettres et en chiffres, le montant en lettres fera foi.
L’évaluation des offres de services sera conduite en une phase. Elle consistera en l’évaluation
des propositions techniques et à la comparaison des propositions financières.
Les critères de jugement des offres se présentent comme ci-après par ordre de priorité :
•
la qualité et la pertinence de la stratégie de migration ;
la qualité et la pertinence du plan de reprise des données existantes ;
la qualité et la pertinence du plan de déploiement, de formation et de basculement ;
la qualification et l'expérience des intervenants ;
la méthodologie et l'approche de mise en œuvre ;
le niveau d'implication des équipes internes de la Banque dans la réalisation du projet ;
le coût de la solution proposée ;
le chronogramme de réalisation et la durée de la prestation ;
•
l'organisation de l’équipe d’intervention.
•
•
•
•
•
•
•
16
Les prestataires ayant les meilleures offres pourraient être conviés aux négociations de leurs
offres financières selon des modalités qui seront communiquées ultérieurement.
15. Attribution du marché
Le marché sera attribué au soumissionnaire dont l'offre technique est jugée conforme au
dossier d'appel d'offres et l'offre financière ressort la moins-disante.
La BCEAO se réserve le droit d'accepter ou de rejeter toute offre, et d'annuler l'appel d'offres
en rejetant toutes les offres, à tout moment, avant l'adjudication du marché.
Aucune réclamation ne pourra être faite à la BCEAO quant à la justification de ses choix lors
de l'attribution. Par ailleurs, la Banque pourra exiger du fournisseur de prouver l'origine ainsi
que l'état neuf des équipements à livrer.
Chaque soumissionnaire dont l'offre n'a pas été retenue en sera informé par écrit.
16. Notification
Le marché sera notifié au soumissionnaire retenu et un contrat de marché lui sera soumis pour
signature. La date de signature du contrat par les deux parties constitue le point de départ des
délais contractuels d'exécution du marché.
17. Lieu de réalisation des prestations
Les prestations se dérouleront principalement au Siège de la Banque Centrale. Le prestataire
retenu y travaillera essentiellement avec la Direction des Systèmes d'Information, la Direction
de la Comptabilité et la Direction du Budget et des Approvisionnements.
18. Délai de livraison
18.1. Le délai de livraison doit être indiqué dans la soumission et commencera à courir à
compter de la date de signature du marché.
18.2. Ce délai doit être scrupuleusement respecté sous peine d'application d'une pénalité
égale à 1/1000e du montant de la commande, par jour calendaire de retard. Toutefois, le
montant de ces pénalités ne peut excéder trois pour cent (3%) du prix du marché.
19. Réception
Dans le cadre de la réception de la solution, des tests pour la vérification de bon
fonctionnement seront réalisés.
–
réception provisoire, constatant la conformité au descriptif de la proposition après la
mise en service de la solution ;
–
réception définitive après la réception provisoire et la constatation du bon
fonctionnement pendant un exercice comptable (12 mois) de la solution installée et
configurée dans les locaux de la Banque, sans que ce délai ne puisse excéder quinze
(15) mois à compter de la date de livraison.
Chaque réception fera l'objet d'un procès-verbal signé par les deux (2) parties.
20. Régime fiscal
En vertu des dispositions des articles 28 du Traité de l’Union Monétaire Ouest Africaine
(UMOA), en date du 20 janvier 2007, 7 des Statuts de la BCEAO, 10, paragraphe 10-1 du
Protocole relatif aux privilèges et immunités de la BCEAO, annexé audit Traité et 8 de l'Accord
de Siège conclu le 21 mars 1977 entre le Gouvernement de la République du Sénégal et la
BCEAO, la Banque Centrale bénéficie, dans le cadre du présent marché, du régime de
l’exonération de tous impôts, droits, taxes et prélèvements d'effet équivalent dus dans les
Etats membres de l’UMOA. A cet égard, les formalités d'obtention du titre d'exonération des
droits de douane seront accomplies par la Banque Centrale.
17
21. Modalités de paiement
Les soumissionnaires proposeront leurs meilleures conditions en tenant compte des éléments
ci-après :
✔
versement d'un acompte de 30% au plus au démarrage, à la signature du contrat de
marché et sur constitution d'une caution bancaire de restitution d'acompte ;
✔
35% après la livraison de la solution ;
✔
30% à la signature de la recette provisoire constatant la conformité au descriptif de la
proposition après la mise en service de la solution ;
✔
5% libérable après la réception définitive.
22. Assurance
Les fournisseurs et/ou leurs sous-contractants devront, à leur charge, souscrire des polices
d'assurance valables pendant toute la durée du contrat et couvrant au moins les risques de
transport, d'installation et de responsabilité vis-à-vis des tiers.
23. Litiges et contestations
23.1. Tout litige sera réglé à l'amiable. A défaut de règlement à l'amiable, tout différend sera,
de convention expresse, soumis à l'arbitrage selon le Règlement d'arbitrage de la Cour
Commune de Justice et d'Arbitrage (CCJA) de l'Organisation pour l'Harmonisation en Afrique
du Droit des Affaires (OHADA) et tranché par un (1) arbitre ad hoc désigné par la CCJA.
23.2. L'arbitrage se déroulera en langue française, à Dakar au Sénégal, et selon le droit
sénégalais.
23.3. Les frais de l'arbitrage sont à la charge de la partie succombante.
24. Informations complémentaires
24.1. Pour toute demande d'éclaircissement, les soumissionnaires pourront prendre l'attache
de la Direction du Budget et des Approvisionnements, par courriel au moins dix (10) jours
avant la date limite de remise des offres à l'adresse : [email protected]. Toute
demande de renseignements parvenue au-delà du délai précité ne sera pas prise en compte.
24.2. Les questions formulées ainsi que les réponses apportées seront systématiquement
mises en ligne sur le site internet de la BCEAO à l'adresse www.bceao.int.
A ce titre, les candidats sont invités à visiter régulièrement le site.
18
ANNEXE I : Formulaire de soumission
(indiquer le lieu et la date)
A l' attention de :
MONSIEUR LE DIRECTEUR DU BUDGET ET DES APPROVISIONNEMENTS
BP 3108 DAKAR
BCEAO/SIEGE
Objet : Sélection d'un prestataire pour l'accompagnement des équipes informatiques de la
BCEAO pour la migration technique du sytème CAFIS
Nous, soussignés.......................................................soumettons par la présente, une offre de
prix pour la sélection d'un prestataire pour l'accompagnement des équipes informatiques de la
BCEAO pour la migration technique du sytème CAFIS pour un montant total HT/HD
de ............................ FCFA.
Nous déclarons par la présente que toutes les informations et affirmations faites dans cette
offre sont authentiques et acceptons que toute déclaration erronée puisse conduire à notre
disqualification.
Notre proposition engage notre responsabilité et, sous réserve des modifications résultant des
négociations du marché, nous nous engageons, si notre proposition est retenue, à commencer
la prestation, au plus tard à la date convenue lors des négociations.
Signataire mandaté
Nom et titre du signataire
19
ANNEXE II : LISTE DES DÉVELOPPEMENTS SPÉCIFIQUES DE CAFIS
Code Description
Module
Nature
Commentaires
GL
FORM
Spécifiques
TRV
001
Restreindre l’accès aux pièces par service. Ainsi, tout utilisateur
concerné par la restriction ne pourra consulter que les pièces
saisies par lui-même ou par un autre agent de son service
d’affectation.
TRV
002
Restreindre l’accès aux pièces par site. Ainsi tout utilisateur
concerné par la restriction ne pourra consulter que les pièces
appartenant à un service de son site.
GL
FORM
Jeux d'accès aux
données pour les
lignes et Spécifiques
pour les entêtes
TRV
003
Restreindre l’accès aux pièces par service et autoriser
uniquement la saisie des pièces inter-sites. Ainsi, tout utilisateur
concerné par la restriction ne pourra consulter que les pièces de
son service, aussi toute pièce saisie doit mouvementer
forcément au moins un compte de son site et au moins un
compte d’un site différent.
GL
FORM
Jeux d’accès aux
données pour les
lignes et Spécifiques
pour les entêtes
TRV
004
Générer automatiquement le nom de la pièce à la création. Ce
nom a la composition suivante :
<Code SITE>/<Code Service>/<Code Utilisateur>/<Date du
jour>/ <Numéro d’ordre>
GL
FORM
Spécifiques
TRV
005
Restreindre la fonctionnalité « Chercher pièce » aux pièces du
service de l’utilisateur connecté.
FORM
Jeux d'acces aux
données pour les
lignes et Spécifiques
pour les entêtes
TRV
006
Restreindre la fonctionnalité « Chercher pièce » aux pièces de
tous les services du site de l’utilisateur.
GL
FORM
Jeux d'acces aux
données pour les
lignes et Spécifiques
pour les entêtes
TRV
007
Permettre la saisie des écritures avec date de valeur en
modifiant le champs flexible descriptif « Saisir des pièces : TVA »
GL
FORM
Spécifiques
TRV
008
Importer dans GL les informations contenues dans les champs
flexibles descriptifs depuis GL_INTERFACE. Ces informations
proviennent d’autres sources et sont chargées à l’aide de «
EasyLink » dans GL. Elles concernent : le code site et le code
service, le code de lettrage et la date de valeur.
GL
PKG
Standard, securiser
l'option d'import sur
le easylink
TRV
009
Faire en sorte que la consultation des comptes puisse prendre
en compte les restrictions déjà appliquées aux pièces. Ainsi, le
détail d’un solde pourra être consulté par tous mais chacun ne
pourra voir que le détail des pièces auxquelles il a droit.
GL
FORM
Jeux d'acces aux
données pour les
lignes et Spécifiques
pour les entêtes
TRV
010
Importer et/ou imputer automatiquement les écritures depuis
GL_INTERFACE à l’aide d’un traitement simultané. Ainsi, le
chargement des écritures provenant des applications en amont
est automatisé.
GL
PKG
Standard, vérification
SLA, imputation, etc.
TRV
011
Augmenter à chaque écriture générée par AP, les informations
de sécurité (Code site et Code service) puis le code de lettrage.
Cette opération est effectuée dans GL_interface avant
l'importation de ces écritures dans Oracle GL.
Solution :Ajouter un trigger « Avant Insert » à la table
GL.GL_INTERFACE (Annexe)
Impact :
Ces informations seront utilisées au niveau de GL pour filtrer les
différentes vues des utilisateurs.
AP
PKG
Spécifiques
TRV
012
Restreindre l’accès aux factures par service. Ainsi, tout utilisateur
concerné par la restriction ne pourra consulter que les factures
saisies par lui-même ou par un autre agent de son service
d’affectation ;
Réduire la liste des sites fournisseurs en fonction du code site de
l’utilisateur.
AP
FORM
Standard
GL
20
Code Description
Module
Nature
Commentaires
TRV
013
Restreindre l’accès aux règlements par service. Ainsi, tout
utilisateur concerné par la restriction ne pourra consulter que les
règlements saisis par lui-même ou par un autre agent de son
service d’affectation.
Restreindre la liste des sites fournisseurs en fonction du code
site de l’utilisateur
AP
FORM
Standard
TRV
014
Mettre la restriction de la consultation par service sur l’écran
d’aperçu des factures
AP
FORM
Standard
TRV
015
Mettre la restriction de la consultation par service sur l’écran
d’aperçu des règlements
AP
FORM
Standard
TRV
016
Mettre la restriction par service sur l’écran de saisie/consultation
des notes de frais. Ainsi après transformation de ces notes de
fais en facture, l’information de sécurité est automatiquement
positionnée.
NB : l'option d'utilisation du panneau « Notes de frais » a été
abandonnée avant le démarrage. Elles sont saisies directement
dans le panneau de saisie des factures avec le type
correspondant.
AP
FORM
Standard
TRV
017
Pouvoir générer les écritures depuis AP vers Gl_interface en
rendant obligatoire l'option « Détail »
AP
PKG
Standard
TRV
020
Ajouter deux champs à l’écran de saisie des factures (Activation
du champ flexible descriptif) pour recevoir éventuellement la
devise et le montant de la facture dans cette devise.
Module PO
PO
FORM
Spécifique sous
réserve de revoir la
gestion des devises
TRV
021
Rendre obligatoire l’égalité entre l’organisation saisie par
l’utilisateur et son organisation d’affectation lors de la saisie du
lieu de livraison d’une commande. Ainsi, cette restriction sera
appliquée à la responsabilité BCEAO-PO-<Nomsite>;
Module HR
PO
FORM
Spécifique
TRV
022
Mise en place d’un traitement simultané en vue de générer les
écritures comptables de la paie et de les déverser dans la
comptabilité.
GL
PKG
Base HR
TRV
023
Mise en place d’un traitement simultané en vue de générer les
écritures comptables des prêts et avances et de les déverser
dans la comptabilité.
GL
PKG
Base HR
TRV
024
Mise en place d’un traitement simultané en vue de générer les
écritures comptables acomptes congés.
GL
Base HR
TRV
025
Paramétrer les rubriques utilisées dans la paie en vue de
permettre la génération automatique des écritures comptables.
HR
Base HR
TRV
026
Empêcher la saisie de mouvements sur les comptes déclarés «
Centralisateur »
GL
FORM
Standard
TRV
027
Faire en sorte que les pièces AP puissent être consultées par
site ; en d’autres termes, filtrer les mouvements uniquement
quand il s’agit des pièces AP pour que chaque site ne consulte
que ses propres mouvements dans la pièce globale
GL
FORM
Standard, A vérifier
si l'écran ne réserve
pas de surprise
TRV
028
Règlement Inter-site : faire en sorte que l’opérateur ne puisse
saisir que son propre code site. Effectuer la mise à jour des
menus en vue de prendre en compte la saisie inter-site des
règlements
AP
FORM
Spécifique
TRV
029
Modifier , à l'aide de Worlflow Builder 2.0, le circuit de génération
des comptes des commandes « Générateur de compte
purchasing » / « Générer compte de provision par défaut » puis
rediriger la flèche entre « Commande liée au projet » et « compte
de provision pour poste de dépense » à « Compte de provision à
partir de l'organisation »
PO
WF
Standard
21
Code Description
Module
Nature
Commentaires
TRV
030
Effectuer la mise à jour du Panneau de saisie des factures en
vue d'appeler le bon panneau d'aperçu des factures.
AP
FORM
Spécifique
TRV
031
Décentraliser la saisie des utilisateurs pour que chaque site
puisse lui même gérer dans CAFIS, les mises à jour des
habilitations et la réinitialisation des mots de passe des
utilisateurs de son propre site.
FND
FORM
Spécifique
TRV
032
Décentraliser la saisie des CDP / CCO pour que chaque site
puisse lui générer ces propres comptes CDP / CCO de
l'application CAFIS (mise en place non effective pour éviter la
saisie non contrôlée par la Direction de la Comptabilité).
FND
FORM
Spécifique
TRV
033
Décentraliser la saisie des fournisseurs. Ainsi, l'administrateur
local de chaque site saisit les fournisseurs de son propre site et
les utilisateurs ne peuvent accéder qu'aux fournisseurs créés
avec leur code site.
AP
FORM
Spécifique
TRV
034
Effectuer la gestion de la position dans le module d'oracle
application GL.
GL
FORM
Spécifique
AP
PKG
Spécifique
Génération des écritures issues des factures d'inventaires.
TRV
035
Lors du traitement de la génération des écritures issues des
factures d'inventaire, modifier la période de comptabilisation.
Enregistrer pour la période « DEC-XX » au lieu de « DEC-A-XX »
(20XX étant l'exercice à clôturer).
Le reste sera sans changement : date GL des écritures = 31DEC-20XX et type de pièce = BCEAO Ecritures d'inventaires.
Ces factures concernent les fournisseurs :
X-FOURN. FACT NON PARVENUES
X-PE CONGES A PAYER
X-PNC CONGES A PAYER
X-AUTRES CHARGES A PAYER
TRV
036
DATE LIMITE DE SAISIE DES COMMANDES DE L'EXERCICE :
fixation de la date limite de saisie de nouvelles commandes. Au
delà de cette date, aucune commande ne pourra être créée dans
le système. Seules les opérations de mise à jour pourront être
effectuées (modification, annulation, suppression, approbation ou
rejet).
Programme : GLP_MAJ_DATE_LIMITE_SAI_CMD
PO
Spécifique
TRV
037
Lors de la saisie des lignes de ventilation des factures ou des
comptes d'imputation des livraisons de commande :
déterminer le cumul des crédits (crédits totaux) ;
renvoyer un message d'erreur bloquant si le résultat est égal à 0.
*** Crédits totaux = Crédits accordés + Crédits supplémentaires
+ Crédits reportés
Ce contrôle doit être rendu obligatoire pour empêcher
l'enregistrement d'opérations (commandes ou factures) sur des
combinaisons n'ayant pas de dotation budgétaire prévue sur
l'exercice en cours.
Détails technique de mise en oeuvre
Message renvoyé : « Pas de dotation budgétaire pour cette
combinaison »
AP
Spécifique
TRV
038
1)Facture de type « Acompte »
Renvoyer un message d'erreur bloquant si :
le fournisseur sélectionné est un fournisseur de factures
d'inventaire (X-FOURN. FACT NON PARVENUES, X-PE
CONGES A PAYER, X-PNC CONGES A PAYER ou X-AUTRES
CHARGES A PAYER, K-DSC-DN-GVT CONGES A PAYER )
AP
Spécifique
22
Code Description
Module
Nature
Commentaires
TRV
039
le type de ligne de ventilation est différent de «Article»
Détails technique de mise en oeuvre
Type de facture : INV_SUM_FOLDER.INVOICE_TYPE
Type
ligne de ventilation : D_SUM_FOLDER.LINE_TYPE
Conditions :
{INV_SUM_FOLDER.INVOICE_TYPE='Acompte'}
et
{ D_SUM_FOLDER.LINE_TYPE <> 'Article'}
Message renvoyé : « Type ligne de l'article obligatoire »
AP
FORM
Spécifique
TRV
040
Contrôle de cohérence lors de la saisie : le type de ligne de
ventilation est différent de «Article»
Message renvoyé : « Type ligne de l'article obligatoire »
AP
FORM
Spécifique
AP
FORM
Spécifique
TRV
042
Facture de type «Standard»
Renvoyer un message d'erreur bloquant si :
la facture concerne un fournisseur de factures d'inventaire (XFOURN. FACT NON PARVENUES, X-PE CONGES A PAYER, XPNC CONGES A PAYER ou X-AUTRES CHARGES A PAYER ou
K-DSC-DN-GVT CONGES A PAYER) et que la date GL différente
de XX-DEC de l'exercice à clôturer
Message renvoyé :
AP
FORM
Spécifique
TRV
043
Contrôle de cohérence : la facture est rapprochée à une
commande et que la date de saisie de la commande est
antérieure à «XX-JAN-2006» (les commandes saisies avant
2006 qui font l'objet de règlement hors exercice doivent être
rapprochées conformément à l'ancienne procédure ; seules les
commandes hors exercice de 2006 et au delà, ainsi que les
commandes de l'exercice en cours peuvent être rapprochées à
une facture)
Détails technique de mise en oeuvre
Type de facture : INV_SUM_FOLDER.INVOICE_TYPE
Nom fournisseur : INV_SUM_FOLDER.VENDOR_NAME
Type ligne de ventilation
:D_SUM_FOLDER.LINE_TYPE
Conditions :
Message renvoyé : « Utiliser l'ancienne procédure pour le
rapprochement de cette commande »
PO
FORM
Spécifique
TRV
044
Contrôle de cohérence : le type de ligne de ventilation est
différent de «Article», «Taxe» et «Acompte» (les types de ligne
«Transport» et «Divers» doivent être rejetés)
Détails technique de mise en oeuvre
Type de facture : INV_SUM_FOLDER.INVOICE_TYPE
Nom fournisseur : INV_SUM_FOLDER.VENDOR_NAME
Type ligne de ventilation
:D_SUM_FOLDER.LINE_TYPE
Message renvoyé : « Le type de ligne de ventilation doit être
Article ou Taxe ou Acompte »
AP
FORM
Spécifique
TRV
041
Contrôle de cohérence : la facture concerne un fournisseur
externe et que le compte comptable de la combinaisons de
comptes de ventilation est différent d'un compte d'acomptes et
avances versés (Comptes 3332100, 441xxxx, 442xxxx )
Détails technique de mise en oeuvre
Message renvoyé : « Code comptable incompatible avec le type
fournisseur »
23
Code Description
TRV
045
TRV
046
Le type ligne est égal à «Taxe» et le compte comptable de la
combinaison de compte de ventilation est différent d'un compte
de taxe (332xxxx)
Détails technique de mise en œuvre
Type de facture : INV_SUM_FOLDER.INVOICE_TYPE
Type ligne de ventilation
:D_SUM_FOLDER.LINE_TYPE
Conditions :
{:
INV_SUM_FOLDER.INVOICE_TYPE
='Standard'}
et
{:D_SUM_FOLDER.LINE_TYPE
= «'Taxe'} et {Compte de
ventilation différent de compte de taxe (332xxxx) }
Message renvoyé : « Type de ligne et compte comptable
incompatibles »
Facture de type « Avoir »
Renvoyer un message d'erreur bloquant si le fournisseur
sélectionné est un fournisseur de factures d'inventaire (XFOURN. FACT NON PARVENUES, X-PE CONGES A PAYER, XPNC CONGES A PAYER ou X-AUTRES CHARGES A PAYER).
Détails technique de mise en oeuvre
Type de facture INV_SUM_FOLDER.INVOICE_TYPE
Nom fournisseur : INV_SUM_FOLDER.VENDOR_NAME
Conditions :
{:INV_SUM_FOLDER.INVOICE_TYPE ='Avoir'} et
{ :INV_SUM_FOLDER.VENDOR_NAME ressemble à ('%FOURN.
FACT NON PARVENUES' ou '%-PE CONGES A PAYER ou '%PNC CONGES A PAYER' ou '%-AUTRES CHARGES A PAYER')}
Module
Nature
Commentaires
AP
FORM
Spécifique
AP
Spécifique
TRV
047
Lors de la saisie de la facture, si le fournisseur est égal à "KDSC-DN-GVT CONGES A PAYER" :
date GL comprise entre le 1er et le 31 du mois de décembre de
l'exercice
dans les ventilations, seuls les comptes 6413400 et 3413500
pourront être impactés avec le segment projet = HBUDG
après approbation, génération des écritures sur la période DECAA au 31-DEC-AA avec type de pièce = BCEAO Ecritures
d'inventaire
AP
Spécifique
TRV
048
Renvoyer un message d'erreur bloquant si le fournisseur
sélectionné est un fournisseur de factures d'inventaire (XFOURN. FACT NON PARVENUES, X-PE CONGES A PAYER, XPNC CONGES A PAYER ou X-AUTRES CHARGES A PAYER) et
que la date GL est différente de XX-DEC de l'exercice à clôturer.
AP
Spécifique
TRV
049
Lors de la saisie du règlement de cette facture, sélectionner :
type de règlement "MANUEL"
compte bancaire = "Z00-Ch. congés à payer DSC-DN-GVT"
En fait, lors de la saisie d'un règlement, pour éviter l'utilisation de
ce type de compte bancaire avec n'importe quel fournisseur,
ajouter les tests suivants :
si compte bancaire = "Z00-Ch. congés à payer DSC-DN-GVT"
alors fournisseur = "K-DSC-DN-GVT CONGES A PAYER"
si fournisseur = "K-DSC-DN-GVT CONGES A PAYER" alors
compte bancaire = "Z00-Ch. congés à payer DSC-DN-GVT"
Les mêmes tests doivent être effectués pour tous les règlements
portant sur des factures d'inventaire.
Dans la saisie des commandes, l'utilisation de ces fournisseurs
de factures d'inventaire doit être formellement interdite.
AP
Spécifique
Message renvoyé : « Ce fournisseur ne peut être utilisé pour une
facture d'avoir »
24
Code Description
Module
Nature
Commentaires
TRV
050
Lors de la saisie des lignes de ventilation des factures ou des
comptes d'imputation des livraisons de commande :
déterminer le cumul des crédits (crédits totaux) ;
renvoyer un message d'erreur bloquant si le résultat est égal à 0.
*** Crédits totaux = Crédits accordés + Crédits supplémentaires
+ Crédits reportés
Ce contrôle doit être rendu obligatoire pour empêcher
l'enregistrement d'opérations (commandes ou factures) sur des
combinaisons n'ayant pas de dotation budgétaire prévue sur
l'exercice en cours.
Détails technique de mise en oeuvre
Combinaison
de
segment
:D_SUM_FOLDER.DIST_CODE_COMBINATION_DISP
fonctions renvoyant les crédits:
glf_calc_credit_ouv : crédit d'ouverture
glf_calc_credit_suppl : crédit supplémentaire
glf_calc_credit_rep : crédit reporté
NB: paramètres d'appel (site_compte,compte ,exercice,gl_date ,
Segment ='BUDG' ,centre de coût = NULL)
Conditions :
{Segment
projet
de
:D_SUM_FOLDER.DIST_CODE_COMBINATION_DISP
=
'BUDG'} et
{total crédit (glf_calc_credit_ouv +glf_calc_credit_suppl+
glf_calc_credit_rep ) =0}
Message renvoyé : « Pas de dotation budgétaire pour cette
combinaison »
AP
Spécifique
TRV
052
Vérifier que la date de saisie (date du jour) est inférieure ou
égale à la date limite de saisie des commandes enregistrée dans
le panneau de mise à jour des lieux (voir champ flexible créé
pour traiter les ouvertures de journées comptables d'un site)
Détails techniques
NB: Un segment a été rajouté sur le champ flexible crée pour
traiter les ouvertures de journées comptable. Ce champ est
paramétrable par site.
Segment du champ flexible mappé sur ATTRIBUTE4 de la table
HR_LOCATIONS_V.
Sélection de la date limite de saisie pour le site de l'utilisateur
(Code site = ATTRIBUTE1 de la table HR_LOCATIONS_V).
Cette date est comparée à la date du jour.
NB : ce test ne sera réalisé qu'à partir du 25 décembre de
l'année en cours pour éviter un contrôle inutile.
Conditions
SI date de saisie (date du jour) > 25
Si {date de saisie (date du jour) >= date limite de saisie }
Message renvoyé : « Date limite de saisie des commandes
expirée »
PO
Spécifique
TRV
053
Si la commande doit être transformée en hors exercice
(dotations hors exercice déjà générées) :
vérifier que la commande concerne une commande de l'exercice
N-1 (tester la date de saisie de la commande par rapport à
l'exercice en cours)
vérifier que toutes lignes BUDG sont fermées et que les
dotations HEXE correspondantes ont été effectivement
constituées
vérifier que la date GL des lignes HEXE est comprise entre le 2
et le 31 janvier de l'exercice N (exercice en cours).
Message renvoyé : «Veuillez saisir une date GL comprise entre
le 1 et les 31 janvier»
PO
Spécifique
25
Code Description
Module
Nature
Commentaires
TRV
054
TRES IMPORTANT
Décocher par défaut la case à cocher « Annulation réservation
de fonds » pour empêcher par erreur l'annulation de la
réservation de fonds des commandes déjà approuvées.
Il arrive que l'émetteur confirme par erreur, l'annulation de la
réservation de fonds d'une commande déjà approuvée, ce qui
remet le statut de la commande à « Nouvelle approbation
requise » sans modifier les engagements de dépenses générés
par la commande.
Si la période concernée est ouverte, l'émetteur peut soumettre à
nouveau la commande sans qu'il y ait un impact sur les
engagements de dépenses : le système modifie à nouveau le
statut et le remet à « Approuvée » sans refaire le circuit
d'approbation.
Par contre, si la période est fermée, il faut nécessairement
rouvrir la période pour pouvoir soumettre à nouveau la
commande en vue de rétablir le statut.
Cette ouverture de période n'est pas toujours possible surtout
quand il s'agit d'un exercice déjà clôturé et dans ce cas, il est
impossible de soumettre à nouveau la commande pour en
changer le statut. Un message bloquant relatif à la date GL est
renvoyé par le système qui ne peut soumettre en nouvelle
approbation, une commande dont la date GL est comprise dans
une période fermée.
En conséquence, la commande figure toujours sur l'état des
commandes en attente d'approbation alors que le statut a été par
erreur et qu'il n'y a aucune approbation de ligne de commande à
effectuer,
PO
Spécifique
TRV
055
Exclure la possibilité de saisir une commande en sélectionnant
les fournisseurs de factures d'inventaire X-FOURN. FACT NON
PARVENUES, K-DSC-DN-GVT CONGES A PAYER, X-PE
CONGES A PAYER, X-PNC CONGES A PAYER ou X-AUTRES
CHARGES A PAYER
AP
Spécifique
TRV
056
Réalisation de la clôture décentralisée : Attente d'un document
sur la clôture
GL
Spécifique
TRV
057
lors de la saisie des pièces de caisse, empêcher la création dans
les cas suivants :
1 - La pièce de 'BCEAO Caisse' ne contenant pas de compte
d'encaisse
2 - La piece dont le type est autre que 'BCEAO Caisse' contenant
un compte d'encaisse.
GL
FORM
Spécifique
TRV
058
Générer un message lorsque la devise de la pièce n'est pas
compatible avec les lignes d'écriture.
GL
FORM
Spécifique
TRV
059
Procédure de Génération des écritures pour virer les SOLDES
DES COMPTES D'INVESTISSEMENTS A CLASSER DANS LES
COMPTES D'IMMOBILISATIONS (Ecritures de clôture) */
GL
PKG
Traitement de la
Clôture
TRV
060
Procédure de Génération des écritures de fin d'exercice. Les
soldes des comptes avec comme attribut Finexercice ='Y' seront
versés dans la même combinaison en remplaçant le site par Z09
et le segment 3 par le site d'origine
GL
PKG
Traitement de la
Clôture
TRV
061
Procédure de Génération des écritures de fin d'exercice. Les
soldes
des
comptes
'3321100',
'3321200'
(Z09.3321100.X00.NS.NS.NS et Z09.3321200.X00.NS.NS.NS)
seront versés respectivement dans '2125100' et '2125200' les
Agences Auxiliaires sont virés au niveau des Agences
Principales
GL
PKG
Traitement de la
Clôture
TRV
063
Procédure de calcul des dotations hors exercice. Pièce de type B
: Prise en compte dans le budget des DED HEXE
GL
PKG
Spécifique
26
Code Description
Module
Nature
Commentaires
GL
PKG
Traitement de la
Clôture
PKG
Spécifique
TRV
064
Procédure de calcul et d'affectation du résultat sur le site Z09
TRV
065
Traitement automatique des opérations de nivellement des
comptes du trésor : Saisie des règles de calcul et des comptes
bénéficiaires
TRV
066
Traitement automatique des opérations de Nivellement quotidien
Payeur de France
GL
PKG
Spécifique
TRV
067
Traitement automatique des opérations de Nivellement décadaire
Payeur de France
GL
PKG
Spécifique
TRV
068
Traitement automatique des opérations de Nivellement décadaire
CCP
TRV
069
Décompter et calculer des intérêts sur certains comptes de dépôt
à la Banque
GL
PKG
Spécifique
TRV
070
Calcul des Intérêts sur les comptes autres que ceux du trésor
GL
PKG
Spécifique
TRV
071
Traitement automatique de la réévaluation des comptes position
d’échange
GL
PKG
Spécifique
TRV
072
Empêcher l'accès aux panneaux de saisie lorsque l'utilisateur
n'est pas affecté à un service dans son dossier RH
GL
FORM
Spécifique
TRV
073
Exiger l'égalité entre la date GL de la ventilation et celle de
l'entête de la facture
AP
FORM
Spécifique
TRV
074
Empêcher que les comptes d'encaisse
sélectionnés dans la ventilation des factures
AP
FORM
Spécifique
TRV0 Empêcher l'utilisation des comptes en devise dans la ventilation
75
des factures
AP
FORM
Spécifique
TRV
076
Exiger la saisie d'une date GL inférieure à la date de référence
comptable du site de l'utilisateur
AP
FORM
Spécifique
TRV
077
Restreindre la liste de valeurs des codes taxes pour que chaque
utilisateur ne puisse sélectionner que les taxes définies pour le
compte de son pays
AP
FORM
Spécifique
TRV
078
Vérifier si le code site du fournisseur est égal à celui du site de
l'utilisateur pour les responsabilités autres que AP-INTER
AP
FORM
Spécifique
TRV
079
Lors de la génération des écritures de comptabilisation, prendre
le compte fournisseur au niveau du Site Fournisseur
AP
FORM
Spécifique
TRV
080
Refuser la saisie et la suppression pour les responsabilités
d'approbation
AP
FORM
Spécifique
TRV
081
Le fournisseur doit être du site de l'utilisateur sauf dans le cas ou
c'est un fournisseur de type employé et que la responsabilité soit
'AP-INTER'
AP
FORM
Spécifique
TRV
082
Bloquer la saisie des commandes dans PO à partir du 27
décembre pour les besoins de la clôture de l'exercice en cours
PO
FORM
Spécifique
TRV
083
Contrôle de cohérence lors de la saisie des dotations hors
exercice : identification, Prix Unitaire, quantité, numéro de ligne
AP
FORM
Spécifique
TRV
084
Contrôle de cohérence lors de la saisie des dotations hors
exercice:
GL
PKG
Spécifique
TRV
085
La quantité saisie est différente de la quantité passée en Hors
Exercice
GL
PKG
Spécifique
TRV
086
Le numéro de ligne sélectionné n'est pas valide
puissent
être
Spécifique
Spécifique
27
Code Description
Module
Nature
Commentaires
TRV
087
Contrôle de cohérence : Une ligne de commande avec le
segment PROJET égal à HEXE doit avoir une date GL
appartenant au mois de janvier de l''exercice suivant'
PO
FORM
Spécifique
TRV
088
Saisie d'une facture rapprochée à une DED HEXE : fournir
obligatoirement HEXE au niveau du segment Projet
AP
FORM
Spécifique
TRV
089
Contrôle de cohérence DED HEXE : Incompatibilité entre la
combinaison budgétaire et celle de la ligne sélectionnée
GL
PKG
Spécifique
TRV
090
Chargement des DED hors exercice dans une table temporaire
PO
PKG
Spécifique
TRV
091
Générer les pièces budgétaires correspondant aux DED Hexe
GL
PKG
Spécifique
TRV
093
Fermer toutes les lignes dont le segment PROJET est égal à
BUDG
PO
PKG
Spécifique
TRV
094
Lors de la saisie, exiger la valeur HEXE au niveau du segment
Projet
PO
FORM
Spécifique
TRV
095
Empêcher la saisie directe dans GL sur un compte défini
centralisateur
GL
FORM
Spécifique
TRV
096
Exiger la saisie du code de lettrage lorsque l'attribut du compte
est positionné "Lettrable"
GL
FORM
Spécifique
TRV
097
Contrôle de cohérence entre type de pièce et ligne d'écriture
GL
FORM
Spécifique
TRV
099
Exiger la valeur du segment 1 égale au code de site de
l'utilisateur lorsque l'attribut du compte est positionné "à utiliser
qu'avec votre code site"
GL
FORM
Spécifique
TRV
100
Contrôle du code site égale au code de l'utilisateur pour la
responsabilité de saisie des pièces FMI
GL
FORM
Spécifique
TRV
101
Impossible d'imputer un lot lorsqu'il contient des pièces dont la
date de validité est inférieure à la date de référence comptable
du
site
de
l'utilisateur'
||
to_char(:WORLD.DATECOMPTABLE,'DD-MON-YYYY')
GL
FORM
Spécifique
TRV
102
Refuser l'imputation d'un lot contenant d'une pièce de BCEAOCaisse si l'agent n'est pas affecté à un service de Caisse
GL
FORM
Spécifique
TRV
103
Ecran de validation des Paiements AP avant envoi à l'interface
de paiement :
AP
FORM
Spécifique
TRV
104
Synchronisation des données entre AP et schéma d'aiguillage
des paiements
AP
PKG
Spécifique
TRV
105
Exclure la possibilité de saisir une commande en sélectionnant
les fournisseurs de factures d'inventaire X-FOURN. FACT NON
PARVENUES, K-DSC-DN-GVT CONGES A PAYER, X-PE
CONGES A PAYER, X-PNC CONGES A PAYER ou X-AUTRES
CHARGES A PAYER
PO
FORM
Spécifique
TRV
106
Réalisation de la clôture décentralisée
GL
PKG
Spécifique
TRV
107
Réalisation de vue pour l'interfaçage avec MIMOSA
GL
PKG
Spécifique
TRV
108
Réalisation de programme réévaluation des devises
GL
PKG
Spécifique