Table des matières

SECTION I : CAHIER DES CLAUSES TECHNIQUES......................................................................3

I.1 OBJET DE L’APPEL D’OFFRE............................................................................................................3

I.2 CONSISTANCE DU MARCHE.............................................................................................................3
I.3 OBJECTIFS ATTENDUS.......................................................................................................................4
I.4 PERIMETRE DE REFONTE DE LA SOLUTION.............................................................................5
I.5 PERIMETRE FONCTIONNEL...............................................................................................................6
5.1. ATTENTES FONCTIONNELLES.....................................................................................................6
5.2. STRUCTURE ORGANISATIONNELLE...........................................................................................6
5.3. MODULE GL : COMPTABILITE BUDGETAIRE, GENERALE AUXILIAIRE ET
ENGAGEMENT...........................................................................................................................................8
5.3.1. Cycle comptable cible :.............................................................................................................................8
5.3.2. Exigences cibles..........................................................................................................................................9
5.3.3. Structure comptable existante...............................................................................................................9
5.3.4. Clé comptable existante..........................................................................................................................10
5.3.5. Gestion budgétaire...................................................................................................................................10
5.3.6. Gestion des engagements :....................................................................................................................11
5.4. MODULE AP : COMPTABILITE FOURNISSEUR.....................................................................12
5.4.1. Processus cible..........................................................................................................................................12
5.4.2. Exigences cibles........................................................................................................................................12
5.4.3. Statistiques relatives aux factures AP................................................................................................13
5.4.4. Statistiques relatives aux de règlements...........................................................................................13
5.4.5. Statistiques relatives aux comptes bancaires AP............................................................................13
5.5. MODULE AR : COMPTABILITE CLIENTS.................................................................................14
5.5.1. Processus cible..........................................................................................................................................14
5.5.2. Exigences de la solution cible :............................................................................................................14
5.5.3. Aperçu sur les Types de mouvement..................................................................................................15
5.5.4. Aperçu sur les origines de mouvements............................................................................................16
5.5.5. Aperçu sur les Lignes Standards.........................................................................................................17
5.5.6. Aperçu sur les classes de règlements.................................................................................................18
5.5.7. Aperçu sur les modes de règlements..................................................................................................19
5.6. MODULE FA : GESTION DES IMMOBILISATIONS................................................................20
5.6.1. Processus cible..........................................................................................................................................20
5.6.2. Exigences de la solution cible :............................................................................................................21
5.6.3. Immobilisations.........................................................................................................................................22
5.6.4. Les livres d'amortissement....................................................................................................................23
5.6.5. Paramétrage de la clé immobilisation.................................................................................................24
5.6.6. Paramétrage de la clé catégorie............................................................................................................24
5.6.7. Paramétrage de la clé lieu......................................................................................................................25
5.7. MODULE PO : GESTION DES COMMANDES..........................................................................25
5.8. NOUVELLES FONCTIONNALITES R12 :..................................................................................26
5.8.1. Contrôle d’accès Multi-Org....................................................................................................................27
5.8.2. Les Ledger et Ledger Sets.......................................................................................................................28
5.8.3. SubLedger Accounting............................................................................................................................28
5.8.4. Utilisation de XML Publisher au niveau reporting.........................................................................29
5.8.5. Autres fonctionnalités améliorant l’exploitabilité du système.....................................................29
5.9. AMELIORATIONS & ADAPTATIONS FONCTIONNELLES......................................................30
I.6 PERIMETRE TECHNIQUE.................................................................................................................30
6.1. ETATS SPECIFIQUES & TRAITEMENTS SPECIFIQUES.......................................................30
6.2. DEVELOPPEMENT SPECIFIQUE.................................................................................................33
 6.3. EXIGENCES TECHNIQUES DE LA SOLUTION CIBLE...........................................................33
6.4. Caractéristiques techniques du système Oracle actuel........................................................35
6.5. PLATEFORME MATERIELLE........................................................................................................36
6.6. SAUVEGARDE.................................................................................................................................37
6.7. ACCES ET SECURITE....................................................................................................................37
6.8. VOLUMETRIE ET PERFORMANCE.............................................................................................37
I.7 EXIGENCES D’INTEGRATION AVEC LE SI DE SNTL...............................................................38
7.1. CARTOGRAPHIE APPLICATIVE..................................................................................................38
7.2. INTERFACES AVEC LE SYSTEME D’INFORMATION SNTL.................................................39
7.3. INTERFACES ENTRE LES DIFFERENTS MODULES DE L’ERP CIBLE..............................40
I.8 EXIGENCES EN MATIÈRE DE REPRISE DES DONNÉES.......................................................40
8.1. PERIMETRE DE LA REPRISE DES DONNEES.........................................................................40
8.2. VOLUMETRIE DES DONNEES.....................................................................................................41
8.3. MECANISMES DE REPRISE DES DONNEES...........................................................................41
I.9 PRESTATIONS DEMANDEES...........................................................................................................42
9.1. PRESTATIONS DE REFONTE.......................................................................................................42
9.2. PRESTATIONS DE FORMATION..................................................................................................42
9.3. PRESTATIONS DE TRANSFERT DE COMPETENCES............................................................43
9.4. PRESTATIONS DE MAINTENANCE EN PERIODE DE GARANTIE.......................................43
I.10 METHODOLOGIE..............................................................................................................................44
10.1. DESCRIPTION DE LA METHODOLOGIE DE MISE EN ŒUVRE PRECONISEE PAR
SNTL :.......................................................................................................................................................44
10.1.1. Étape I – Initialisation & Cadrage.....................................................................................................45
10.1.2. Étape II – Formations équipe projet et équipe technique...........................................................47
10.1.3. Étape III – Analyse de l’existant et Étude.......................................................................................48
10.1.4. Étape IV -Refonte...................................................................................................................................49
10.1.5. Étape V - Tests unitaires et Tests d’intégration............................................................................51
10.1.6. Étape VI – Recette utilisateurs...........................................................................................................53
10.1.7. Étape VII – Préparation à la bascule................................................................................................54
10.1.8. Étape VIII - Mise en production.........................................................................................................55
I.11 LIVRABLES DU PROJET.................................................................................................................56
I.12 EQUIPE PROJET................................................................................................................................58
I.13 CONDUITE DE CHANGEMENT.....................................................................................................59
 Section I : Cahier des Clauses techniques

I.1 OBJET DE L’APPEL D’OFFRE

Le présent Appel d'Offres a pour objet la refonte et montée en version de
l’ERP Oracle E-Business suite dénommé par la suite « Oracle EBS » du
groupe SNTL vers la version R12. Il s’agit d’un projet de ré-implémentation.

I.2 CONSISTANCE DU MARCHE

La consistance du marché découlant du présent appel d’offres, concerne la
refonte et la réalisation d’une montée en version de l’ERP existant Oracle
EBS en passant de la version 11i vers la dernière version certifiée R12 en
assurant une ré-implémentation de bout en bout.

Ceci englobe l’installation, l’intégration, la mise en place de la version cible,

la formation et la documentation, les tests et la mise en production au siège
de SNTL et dans tous les sites du périmètre du projet, présentés dans la
partie « I.4 PERIMETRE DE REFONTE DE LA SOLUTION » ci-dessous.

Le soumissionnaire devra prendre en charge la ré-implémentation des

modules existants suivants :

Module Fonctionnalité

General Ledger dénommé « GL » Pour la gestion des comptabilités, réelle,

d’engagement et budgétaire. Et ceux pour la
gestion de la comptabilité générale et
analytique

Oracle Payables dénommé « AP » Pour la gestion des factures et règlements

fournisseurs

Oracle Receivables dénommé « AR » Pour la gestion de des mouvements clients et

des encaissements correspondants

Oracle Fixed assets dénommé « FA » Pour la gestion des immobilisations

Aussi, le soumissionnaire devra :

 Mettre en place le nouveau module Oracle Purchasing dénommé « PO »

relatif à la gestion des Achats ainsi que la prise en charge des
interfaces entrantes et sortantes couvrant tous les événements de
gestion effectués au niveau des systèmes métiers Achats exploités par
le groupe SNTL
 Prendre en charge le remplacement du Module AX par le module SLA
et ce pour la traduction comptable des mouvements AP, AR, FA et PO
 Prendre en charge la mise à niveau du paramétrage ainsi que
l’augmentation de la couverture fonctionnelle des modules
susmentionnés. Aussi, le soumissionnaire devra analyser et mettre en
service toutes les fonctionnalités non encore exploitées pour chaque
module et unité et ce en assurant une cohérence des meilleurs
pratiques à l’échelle groupe

De plus, l’ensemble des états de reporting, traitements standards et

workflows standards élaborés au niveau de la partie « I.6 PERIMETRE
TECHNIQUE » devront aussi être réimplémentés dans la version cible. Le
soumissionnaire est amené également à présenter les nouveaux états de
reporting et traitements standards introduits entre la version actuelle et la
version cible.

I.3 OBJECTIFS ATTENDUS

Le groupe SNTL, utilisant actuellement pour sa gestion backoffice l'ERP
Oracle E-Business dénommé « Oracle EBS », envisage de réaliser une montée
de version en passant de la version 11i vers la dernière version certifiée R12.

Il s’agit d’un projet de refonte dont les objectifs desservis sont cités ci-après :

 Réaliser une ré-implémentation iso fonctionnelle vers la version R12 ;

 Assurer l’augmentation de la couverture fonctionnelle des modules en
production en profitant des évolutions fonctionnelles et techniques
apportées par les différentes évolutions de la solution ;
 Intégration du nouveau module PO et digitalisation de bout en bout du
macro processus « procure to pay »
 Assurer certaines améliorations et adaptations fonctionnelles et
techniques de la solution e-BS ;

Les actions de conduite du changement, de formations et de montée en

compétence sont à conduire tout au long du projet.
 I.4 PERIMETRE DE REFONTE DE LA SOLUTION
Le périmètre du projet couvre toutes les sociétés du groupe SNTL qui sont de
l’ordre de 6 sociétés. La liste des sociétés ainsi que leurs activités sont
données dans le tableau qui suit :

Société Activités couvertes

Activité de la direction des transports

SNTL Activité de la direction des services aux administrations

SNTL ASSURANCES Activité d’assurance

LOGDEV Infrastructures Logistiques & Mobilité Urbaine

SNTL SUPPLY CHAIN Transport et logistique de distribution

INTERNATIONAL Activité de services internationaux de logistique

LOGISTICS SERVICES

LOGDEV AFRICA Infrastructures Logistiques & Mobilité Urbaine

I.5 PERIMETRE FONCTIONNEL

 5.1. ATTENTES FONCTIONNELLES

La montée en version de la solution E-Business Suite pour le groupe TMSA

est venue pour répondre aux attentes Fonctionnelles dont les principaux
objectifs sont :

- Exploitation iso des processus existants sous la version cible de la

R12 ;

- Exploitation optimale de la nouvelle configuration comptable apportée

par la R12 ;

- Optimisation des processus existants via les nouveautés apportées par

la version R12 ;

- La mise en place des améliorations et adaptations telles que listées au

niveau de la partie « 5.8. Améliorations & adaptations fonctionnelles ».

5.2. STRUCTURE ORGANISATIONNELLE

Pour répondre aux différentes attentes fonctionnelles susmentionnées dans

la partie « 5.1. Attentes fonctionnelles », le paramétrage organisationnel
du groupe SNTL, qui est structuré autour des fondations de la E-Business
Suite en matière de définition des organisations, devra être revu et
implémentés sous l’ossature de la R12. Ceci afin de refléter fidèlement la
structure groupe qui a évolué au fil des années.

Le tableau du mapping entre les 6 sociétés du groupe et les entités

existantes au niveau de la version actuelle 11i est donné dans le tableau qui
suit :
 Tableau de mapping

Société Activité Entité système

Activité de la direction des transports DT

SNTL Activité de la direction des services DSA

aux administrations

SNTL ASSURANCES Activité d’assurance ASS

LOGDEV Infrastructures Logistiques & Mobilité IMMO

Urbaine

SNTL SUPPLY CHAIN Transport et logistique de distribution -

INTERNATIONAL Activité de services internationaux de ILS

LOGISTICS logistique
SERVICES

LOGDEV AFRICA - -

La structure organisationnelle cible devra donner lieu à la mise à niveau et

création de nouveaux objets organisationnels suivants :

1. Entité professionnelle
2. Entité Juridique
3. Entité Comptable
4. Unités Opérationnelles
5. Organisations Logistiques
Pour se faire, le soumissionnaire est amené à analyser profondément la
structure du groupe SNTL et de proposer la structure organisationnelle cible
R12 à même de refléter fidèlement et la structure en vigueur du groupe et les
attentes fonctionnelles du projet objet de cet appel d’offres.

N.B : Il convient d’ajouter qu’une nouvelle entité est en cours d’intégration

dans la version 11i à savoir « SNTL SUPPLY CHAIN » et devra faire partie
aussi des entités à prendre en charge dans la version cible R12.
 5.3. MODULE GL : COMPTABILITE BUDGETAIRE, GENERALE
AUXILIAIRE ET ENGAGEMENT

Le groupe SNTL a opté pour la solution progicielle Oracle E-Business Suite

11i afin de gérer tous ses besoins en termes de comptabilité générale,
auxiliaire, engagement et budgétaire.

Le module GL est le réceptacle comptable de l’ensemble des flux de gestion

déversés depuis les modules auxiliaires Oracle : Module AP, Module AR,
Module FA (en plus du nouveau module PO à intégrer dans la version cible
R12), les applications métiers externes et la solution de la paie

Le module GL de la version cible devra disposer d’un Reporting en ligne

permettant entre autres :

 Un accès en temps réel à l’information,

 Un audit complet des écritures avec une analyse ascendante,
descendante et multidimensionnelle de cette information,
 Une optimisation du cycle de comptabilisation et une amélioration
du cycle de clôture comptable,
 Edition des états de gestion et des états financiers,
 Une centralisation des écritures validées,
 Une gestion de la comptabilité budgétaire et des engagements

5.3.1. Cycle comptable cible :

La solution cible devra prendre en charge le cycle comptable cible du groupe

SNTL et ses sociétés à travers entre autres les étapes suivantes :

1. L’ouverture de période comptable dans Oracle GL,

2. L’ouverture de périodes de gestion dans les différents
modules de la e-Business Suite,
3. La comptabilisation des mouvements des modules amont
vers Oracle GL en transitant via la couche SLA permettant de
comptabiliser en provisoire afin de simuler avant de
comptabiliser en définitif vers SLA et vers GL,
4. Centralisation des pièces comptables auxiliaires à partir
de SLA,
5. L’imputation des comptes dans Oracle GL depuis SLA ou
depuis GL,
6. L’analyse des comptes,
7. Les régularisations et les provisions dans SLA ou dans
Oracle GL,
8. La fermeture des périodes comptables des modules
amont,
 9. La fermeture de la période comptable d’Oracle GL.

5.3.2. Exigences cibles

Le soumissionnaire est tenu de revoir et mettre en place la structure

comptable au niveau du Module GL. En principe, chaque société devra
posséder son propre livre comptable, et posséder son propre plan comptable
et sa propre configuration comptable.
Aussi, le soumissionnaire est amené à paramétrer le module SLA et les
méthodes de comptabilisation par société et ce afin de remplir des attentes et
exigences de chaque société du groupe SNTL. En effet, chaque société devra
pouvoir gérer de façon autonome sa comptabilité. Aussi, le lancement de la
comptabilisation devra être assuré séparément par société et par « business
unit ».
La définition de la configuration comptable cible et sa mise en place sous
l’ossature de la version R12 seront assurées par le soumissionnaire.

5.3.3. Structure comptable existante

La synthèse des entités comptables existants au niveau de la version

actuelle 11i est donné dans le tableau suivant :

Unité Description Livre comptable Clé comptable Segment

d’équilibrage
ASS STE D'ASSURANCE SNTL ENTITE STRUCTURE ASS
COMPTABLE SNTL COMPTABLE ONT

DSA ACTIVITE DE LA DIRECTION ENTITE STRUCTURE DSA

DES SERVICES AUX COMPTABLE SNTL COMPTABLE ONT
ADMINISTRATIONS
DT ACTIVITE DE LA DIRECTION ENTITE STRUCTURE DT
DES TRANSPORTS COMPTABLE SNTL COMPTABLE ONT

IMMO SNTL IMMO ENTITE STRUCTURE IMM

COMPTABLE SNTL COMPTABLE ONT

IMMO SNTL IMMO MED ENTITE STRUCTURE MED

MED COMPTABLE SNTL COMPTABLE ONT

ILS INTERNATIONAL LOGISTICS ENTITE STRUCTURE ILS

SERVICES COMPTABLE SNTL COMPTABLE ONT

Le soumissionnaire est amené à revoir la structure comptable et proposer et

mettre en place celle cible
 5.3.4. Clé comptable existante

Aussi, la clé comptable flexible actuellement exploitée par les sociétés du

groupe SNTL est composée de 10 segments tel qu’illustré dans le tableau :

Numéro du segment Nom du segment

SEGMENT1 Activité

SEGMENT2 Compte Général

SEGMENT3 Centre de Responsabilité

SEGMENT4 Type de Budget

SEGMENT5 Prestation

SEGMENT6 Projet

SEGMENT7 Nature

SEGMENT8 Réserve 1

SEGMENT9 Réserve 2

SEGMENT10 Réserve 3

Le soumissionnaire est amené à revoir la structure de la clé comptable et de

proposer et mettre en place celle cible

5.3.5. Gestion budgétaire

La version cible devra assurer les exigences suivantes :

 Prendre en charge de bout en bout le cycle budgétaire R12 :
 Tenir séparément la comptabilité du budget de fonctionnement
et celui d’investissement ;
 Garantir une intégration avec la comptabilité générale et
analytique.
 Fonctionner en multi établissements et permettre des
consolidations.
 Être paramétrable et évolutive de manière à s’adapter facilement
à l’évolution du groupe SNTL.
  Permettre l’édition d’états budgétaires, généraux et analytique et
d’engagement.

5.3.6. Gestion des engagements :

La comptabilité d’engagement devra être prise en charge par la version cible

de la R12.
L’ensemble des évènements auxiliaires impactant la comptabilité
d’engagement devront être prises en charge depuis le nouveau module PO à
intégrer jusqu’à le module GL passant par le module AP.
En termes de suivi d’engagements ou de contrôle budgétaire, le
fonctionnement cible envisagé correspond à mettre en place un contrôle
bloquant pour certaines fourchettes de comptes de fonctionnement et
d’investissement. Ce contrôle devra être assuré sur un niveau agrégé :
 Par rubrique de compte pour le budget de fonctionnement
 Par code Projet pour le budget d’investissement
Le système devra permettre le suivi d’exécution des engagements du :
 Budget d’investissement
 Budget de fonctionnement
Un ensemble d’états de suivi est à réimplémenter au niveau de la version
cible de la R12 à savoir :
 Etat de suivi du budget de fonctionnement
 Etat de suivi du budget d’investissement
 Etats d’analyse des comptes
 5.4. MODULE AP : COMPTABILITE FOURNISSEUR

5.4.1. Processus cible

Le module ORACLE AP exploité actuellement intègre toutes les étapes du

processus de traitement des opérations liées à l’enregistrement et au suivi de
la Comptabilité des Fournisseurs.
Dans la version cible R12, ce module AP assurera aussi le complément
naturel des processus du Module ORACLE PO, qui peut être décrit par entre
autres les étapes suivantes :

• La gestion des fournisseurs (communément avec le module PO),

• La saisie et le suivi des factures fournisseurs,

• la saisie et le suivi des factures de commission des distributeurs,

• Le rapprochement entre les factures et le dossier Achat

• La gestion des règlements fournisseurs,

• L’analyse des données : soldes fournisseurs,

• La comptabilisation des données AP vers GL selon l’ossature apportée

par SLA.

Le soumissionnaire est amené à mettre en place l’ensemble des

fonctionnalités susmentionnées ainsi que celles exploitées par les entités du
groupe.

5.4.2. Exigences cibles

Les acquis de AP de la version actuelle 11i devront être réimplémentées par

le soumissionnaire dans la version cible R12.

Aussi, le soumissionnaire est amené à renforcer par d’autres

fonctionnalités :

 La maîtrise de la génération comptable des opérations de règlements :

soit lors de paiement, soit lors d’apurement ou rapprochement soit les
deux
 Comptabilité auxiliaire SLA pour traduire les événements en
comptabilité auxiliaire avant leur transfert vers GL
  L’architecture bancaire qui devient basée sous TCA (Trading
Community Architecture) permettant d’avoir plus de performance
fonctionnelle en matière de gestion des flux de trésorerie

5.4.3. Statistiques relatives aux factures AP

Les statistiques de nombre de factures par organisation et par devise :

Organisation Devise Nombre de factures
DT MAD 1 880 053

DSA MAD 162 568

ASS MAD 5 186

IMMO MAD 2 380

ILS MAD 83

ILS EUR 32

IMMO MED MAD 2

5.4.4. Statistiques relatives aux de règlements

Les statistiques du nombre de règlements par organisation et par devise :

Organisation Devise Nombre
DT MAD 274 555

DSA MAD 146 300

ASS MAD 5 188

IMMO MAD 2 224

ILS EUR 10

5.4.5. Statistiques relatives aux comptes

bancaires AP

Les statistiques des comptes bancaires paramétrés par organisation sont

données dans le tableau ci-après :

Organisation Type Nombre de comptes

DT Interne 51
DSA Interne 26
 ASS Interne 10
IMMO Interne 5
Setup Business Group Interne 3
ILS Interne 2
IMMO MED Interne 1

5.5. MODULE AR : COMPTABILITE CLIENTS

5.5.1. Processus cible

Au niveau de SNTL, Le module Oracle AR est le module de la comptabilité

client. Il s’agit d’une couche de gestion des clients intégrée avec d’autres
modules de la E-Business suite. Cette couche est structurée par entité
comptable et par unité opérationnelle.

Les fonctionnalités composantes de cette solution sont :

1. La fiche client dont la partie comptable est cloisonnée par unité

opérationnelle et par site ;
2. La partie facturation qui peut être générée par interfaçage ; ou saisie
manuellement (tous les types de factures sont prévus par AR :
standard, avoir, note de débit, reliquat, ajustement ;
3. La partie encaissement et lettrage pouvant fonctionner en parfaite
intégration avec le module de rapprochement bancaire et celui de la
trésorerie ;
4. La comptabilisation vers GL, le module réceptacle qui reçoit tous les
déversements des modules auxiliaires.

A l’instar de l’ensemble des modules mis en production à SNTL, la

comptabilité client est gérée sous le plan comptable national PCN qu’il faut
préserver et le système comptable financier qu’il faut maintenir.

5.5.2. Exigences de la solution cible :

Le soumissionnaire est amené à mettre en place l’ensemble des

fonctionnalités exploitées au niveau de la version cible R12 ainsi que
renforcer par d’autres fonctionnalités :

 Comptabilité auxiliaire SLA

 L’architecture bancaire qui devient basée sous la nouvelle couche
fonctionnelle TCA (Trading Community Architecture) permettant
 d’avoir plus de performance fonctionnelle en matière de gestion des
tiers

5.5.3. Aperçu sur les Types de mouvement

Les types de mouvement permettent de définir entre autres :

 Les types de transaction à saisir ou à importer dans AR (Facture,

Avoir...etc.)
 Les comptes comptables principaux de toute transaction AR (Compte
Produit, Compte TVA et Compte Client)
 Si toute transaction utilisant ce type de mouvement est centralisable
vers GL ou pas.

Tous les types de mouvement devront reconduits fidèlement par le

soumissionnaire dans la version cible R12.

Exemple de types de mouvements

Unité Type de Mouvement Description Classe

DT OD_FACT_AG_TIR Avoir Agences Transport TIR Avoir

DT OD_FACT_CLE_NORM Avoir Centrale du transport Normal Avoir

DT OD_FACT_CLE_TOR Avoir Centrale du transport TOR Avoir

DT OD_FACT_INTER_NORM AVOIR_INTER_NORM Avoir

DT DTAXE_TR_BET Détaxes Agences Transport Bettrave Avoir

DT DTAXE_TR_NORM Détaxes Agences Transport Normal Avoir

DT FAC GRV KENITRA FAC GRV KENITRA Facture

DT FAC GRV KHOURIBGUA FAC GRV KHOURIBGUA Facture

DT FAC GRV MEKNES FAC GRV MEKNES Facture

DT FACT_EAU_ELECT FACT_EAU_ELECT_CENTRE_LOGISTIQUE Facture

DT FACT_INTER_NORM FACT_INTER_NORM Facture

DT FACT_LOYER_LOGIST FACT_LOYER CENTRE LOGISTIQUE Facture

DT GAZ_TR_NORM Gazoil Agences Transport Normal Avoir

 DT OD_FAC_GRV_KENITRA OD FAC GRV KENITRA Avoir

DT OD_FAC_GRV_MEKNES OD FAC GRV MEKNES Avoir

DT OD_CONS_DT_VCARB OD_CONS_DT_VCARB Avoir

DT OD_FACT_LOYER_LOGIST OD_FACT_LOYER CENTRE LOGISTIQUE Avoir

DT OD_FACT_AG_ENTREP OD_FACTURATION ENTREPOSAGE Avoir

5.5.4. Aperçu sur les origines de mouvements

Les origines contrôlent les sources des types de mouvement et la

numérotation des mouvements saisis manuellement ou importés à partir des
systèmes amont. Deux catégories d’origines sont exploitées par SNTL :

 Manuelles : Utilisées pour toutes les transactions saisies

manuellement

 Importées : Utilisées pour gérer l'importation des mouvements

dans Oracle Receivables par l'intermédiaire de l'interface
facture. Il s’agit de toute origine déversant des transactions de
manière automatique à partir d’un système amont, Oracle ou
non Oracle

Toutes les origines devront être reconduites dans la version cible et ce pour
l’ensemble des sociétés du groupe.

Exemple des origines de mouvements

Unité Nom Description Type
DSA Reliquat Lot de reliquats Manuelle
DSA Annulation/note débit Lot d'annulations par notes de Manuelle
débit
DSA MANUAL-OTHER Manuelle Oracle OE Manuelle
DSA SERVICE Avoirs service importés Importé
DSA PROJECTS INVOICES Factures d'Oracle Projects Importé
DSA Intersociété Factures inter sociétés Importé
DSA Factures internes PA Factures internes Oracle Project Importé
Accounting
DSA Origine du lot d'Oracle Property Manager Factures d'Oracle Property Manager Importé
DSA Manuel Origine manuelle Manuelle
DSA Interface DSA Interface Factures DSA Importé
DSA ONT_REPRISE_DSA Reprise Factures DSA Importé
DSA SICARTE SICARTE Importé
 5.5.5. Aperçu sur les Lignes Standards

Les lignes standards déterminent les rubriques et les ventilations qui

composent les factures, elles sont utilisées pour les origines manuelles ou
importées.

Oracle AR affiche ces lignes sous forme de liste de valeurs lors de la saisie
des lignes de facturation permettant ainsi de récupérer toutes les
informations nécessaires pour générer les ventilations comptables,
notamment les imputations comptables relatives au produit.

Toutes les lignes standards devront être reconduites fidèlement vers la

nouvelle version cible de la R12.

Exemple des lignes standards

Unité Ligne Standard Description

ASS COMM/ASSCL Commission/Assurance CL
DSA Commissions/Remorquage Commissions / Remorquage
DSA Commissions et Pdts Sur Achats de Véhicules Commissions et Pdts Sur Achats de Véhicules
DSA Commissions/VMR Commissions/ VMR
DT COMPTE A ANALYSER COMPTE A ANALYSER
DSA CL_ADM Compte de Liaison AP/AR
DSA CL_VCARB Compte de Liaison AP/AR
DSA CL_VISITE_TECHNIQUE Compte de Liaison AP/AR
DSA CL_VREP Compte de Liaison AP/AR
DSA CL_VTA Compte de Liaison AP/AR
DSA CL_VTM Compte de Liaison AP/AR
DSA CL_VTT Compte de Liaison AP/AR
DSA CL_CARBUCARTE Compte Transitoire ou d'Attente-Créditeur
DSA Coût Impression Coût Impression
DSA CPTE_LIAISON_AP/AR CPTE_LIAISON_AP/AR
DSA CPTE_LIAISON_AP/AR_PRET_LOG CPTE_LIAISON_AP/AR_PRET_LOG
DSA DEBIT_MAT_REF DEBIT_MAT_REF
DSA Dédits Reçus Dédits Reçues
DT DETAXE_TR_BETT DETAXE_TR_BETT
DT DETAXE_TR_NORM DETAXE_TR_NORM
IMMO ENERGIE ENERGIE
IMMO COMMISSION LOCATION DE CELLULE FACILITY MANAGEMENT SNTL IMMO
IMMO FACILITY MANAGEMENT FACILITY MANAGEMENT SNTL IMMO
DSA FACT_CCMS FACT_CCMS
 5.5.6. Aperçu sur les classes de règlements

Les classes de règlements déterminent le processus des encaissements dans

AR. Ces classes associent les modes de règlement aux comptes bancaires
appropriés.

Toutes les classes de règlement devront être reconduites fidèlement vers la

nouvelle version cible de la R12

Exemple des classes de règlements

Classe de Règlement Méthode de création Avec Rapprochement Avec Remise Statut

EFFETS_AGENCES Manuelle Non Oui Confirmé

ESPECES_AGENCES Manuelle Non Oui Confirmé
GESTIONNAIRE_CHEQUES Manuelle Non Oui Confirmé
GESTIONNAIRE_VIREMENTS Manuelle Non Non Rapproché
GESTIONNAIRE_APP_VIGNETTE Manuelle Non Non Rapproché
S
GESTIONNAIRE_APP_CAISSE Manuelle Non Oui Confirmé
TRESORIER_VIREMENTS Manuelle Non Non Rapproché
VIREMENTS_AGENCES Manuelle Non Non Rapproché
CHEQUES SNTL ASSURANCE Manuelle Non Non Rapproché
REGULARISATION Manuelle Non Non Rapproché
CHEQUES_AGENCES Manuelle Non Oui Confirmé
AVANCE_GASOIL Manuelle Non Oui Confirmé
VIGNETTES_AGENCES Manuelle Non Oui Confirmé
GESTIONNAIRE_ASS_CAISSE Manuelle Non Non Rapproché
INDEMNISATION_SINISTRE Manuelle Non Oui Confirmé
CHEQUES SNTL IMMO Manuelle Non Oui Confirmé
VIREMENT SNTL IMMO Manuelle Non Non Rapproché
GESTIONNAIRE_VIGNETTES_NS Manuelle Non Non Rapproché
GESTIONNAIRE_CHEQUES_NS Manuelle Non Oui Confirmé
ESPECE GRV Manuelle Non Non Rapproché
REDRESSEMENT Manuelle Non Non Rapproché
ESP_GRV_DAKHLA Manuelle Non Non Rapproché
VIREMENTS_CMS Manuelle Non Non Rapproché
GESTIONNAIRE_VIREMENTS_NS Manuelle Non Non Rapproché
 5.5.7. Aperçu sur les modes de règlements

Les modes de règlements sont rattachés aux différentes classes définies

auparavant. Ils sont utilisés dans Oracle AR pour associer les comptes
bancaires d’encaissement et les différents comptes comptables de trésorerie,
de remise en banque ou de lettrage.

Plusieurs comptes bancaires peuvent être affectés au même mode de

règlement mais dans ce cas, un seul est désigné comme compte principal.

Pour toutes les sociétés du groupe SNTL, tous les modes de règlement seront
tous reconduits dans la version cible de la R12.

Exemple des modes de règlements

Mode de Règlement Classe de Règlement Nom Imprimé

CHQ_AG_KENITRA CHEQUES_AGENCES CHQ_AG_KENITRA
CHQ_AG_NADOR CHEQUES_AGENCES CHQ_AG_NADOR
CHQ_AG_LARACHE CHEQUES_AGENCES CHQ_AG_LARACHE
CHQ_AG_EL JADIDA CHEQUES_AGENCES CHQ_AG_EL JADIDA
CHQ_AG_MARRAKECH CHEQUES_AGENCES CHQ_AG_MARRAKECH
CHQ_AG_K LEKBIR CHEQUES_AGENCES CHQ_AG_K LEKBIR
CHQ_AG_FES VN CHEQUES_AGENCES CHQ_AG_FES VN
CHQ_AG_MEKNES VN CHEQUES_AGENCES CHQ_AG_MEKNES VN
CHQ_AG_OUJDA CHEQUES_AGENCES CHQ_AG_OUJDA
CHQ_AG_RABAT CHEQUES_AGENCES CHQ_AG_RABAT
CHQ_AG_SAFI CHEQUES_AGENCES CHQ_AG_SAFI
CHQ_AG_SETTAT CHEQUES_AGENCES CHQ_AG_SETTAT
CHQ_AG_SIDI KACEM CHEQUES_AGENCES CHQ_AG_SIDI KACEM
CHQ_AG_TANGER CHEQUES_AGENCES CHQ_AG_TANGER
CHQ_AG_TAZA CHEQUES_AGENCES CHQ_AG_TAZA
CHQ_AG_TETOUAN CHEQUES_AGENCES CHQ_AG_TETOUAN
VIRT_CLE_NORM VIREMENTS_AGENCES VIRT_CLE_NORM
VIRT_CLE_TOR VIREMENTS_AGENCES VIRT_CLE_TOR
VIRT_AG_NORM VIREMENTS_AGENCES VIRT_AG_NORM
VIR_CENTRE_LOGISTIQUE VIREMENTS_AGENCES VIR_CENTRE_LOGISTIQUE
VIRT_AG_NORM_BMCE VIREMENTS_AGENCES VIRT_AG_NORM_BMCE
VIRT_AG_NORM_ATJ_DT VIREMENTS_AGENCES VIRT_AG_NORM_ATJ_DT
VIRT_AG_NORM_ATJ_DSA VIREMENTS_AGENCES VIRT_AG_NORM_ATJ_DSA
VIRT_CLE_NORM_BMCE VIREMENTS_AGENCES VIRT_CLE_NORM_BMCE
VIRT_CLE_NORM_ATJ_DT VIREMENTS_AGENCES VIRT_CLE_NORM_ATJ_DT
VIRT_CLE_NORM_ATJ_DSA VIREMENTS_AGENCES VIRT_CLE_NORM_ATJ_DSA
VIRT_TOR_ATJ_DSA VIREMENTS_AGENCES VIRT_TOR_ATJ_DSA
VIR_CENTRE_LOGISTIQUE_ATTAJ VIREMENTS_AGENCES VIR_CENTRE_LOGISTIQUE_BMCE
VIRT_AG_NORM_BMCE_ONT VIREMENTS_AGENCES VIRT_AG_NORM_BMCE_ONT
 5.6. MODULE FA : GESTION DES IMMOBILISATIONS

5.6.1. Processus cible

Oracle FA est une solution complète de gestion des immobilisations qui tient
à jour les biens et les équipements avec précision pour vous aider à
sélectionner les meilleures stratégies comptables. La solution cible devra
permettre :

• d’ajouter, transférer et céder des immobilisations ;

• d’ajuster une seule immobilisation, des groupes d'immobilisations ou des

informations financières ;

Oracle FA s'adapte aux lois comptables et aux règles fiscales de divers pays
afin de répondre aux fluctuations de l'économie, aux dépréciations
imprévues et à toute autre circonstance imprévisible ;

Oracle FA fournit des états qui permettent d'informer le gestionnaire des

immobilisations des acquisitions, transferts et cessions d'immobilisations ou
de toute autre modification non enregistrée, et qui garantissent l'exactitude
du contrôle des immobilisations ;

La solution cible devra permettre d’imprimer ces états à tout moment, de

même que vous pouvez consulter des informations descriptives ou
financières en ligne concernant les immobilisations.

Oracle FA s'intègre avec les produits Oracle Payables, Oracle Projects et

Oracle General Ledger pour fournir des informations de gestion des
immobilisations.

Il utilise les informations sur les fournisseurs d'Oracle Purchasing, les

informations sur les unités de mesure et les articles et les informations. Il
permet également une interface directe avec Application Desktop Integrator
(ADI).

La solution cible devra prendre en charge le processus d'acquisition

d'immobilisations en haut volume pour charger dans Oracle FA des
informations sur les factures et les immobilisations provenant d'un système
d'alimentation, tel qu'Oracle Payables ou tout autre système de comptabilité.

Aussi la solution cible devra prendre en charge l’intégration d’Oracle FA

dans avec le Grand Livre en créant automatiquement des pièces comptables
des immobilisations pour le système de comptabilité générale.
 5.6.2. Exigences de la solution cible :

Dans la version cible R12, Il faudra intégrer et mettre en service l’ensemble

des fonctionnalités standards du Module FA dont on cite entre autres :

o Création des immobilisations :

 Saisie manuelle
 Intégration de factures AP
 WebADI
 Capitalisation
o Traitement des acquisitions en Haut Volume
o Amortissements
 Amortissements réels
 Prévisions d’amortissements
 Simulations d’amortissements
o Comptabilisation
o Cessions
o Inventaires
o Transactions en Haut volume
 Reclassements
 Transferts
 Cessions
o Consultations en lignes
o Historique des immobilisations
o Etats
 5.6.3. Immobilisations

Les statistiques du nombre des immobilisations par livre sont données dans
le tableau qui suit :

Livre Nombre d’immobilisations

DT 11992

DSA 3081

ASS 476

IMMO 107

Ces immobilisations FA sont soient :

o Saisies manuelles au niveau du module FA

o Provenant du Module Oracle Payables Factures AP
o Chargés en masse via Web ADI
N.B : Il sera demandé lors de la ré-implémentation de la version R12
d’assurer un travail d’assainissement et de prendre en charge entre autres
les cas suivants :

o Immobilisations saisies en doubles

o Factures AP non transférées vers FA
o Lignes d’acquisitions en haut volumes non traités
o Immobilisations non saisies
 5.6.4. Les livres d'amortissement

Les livres d'amortissement permettent de stocker les informations

financières relatives à un groupe d'immobilisations ;

Toutes les immobilisations doivent être ajoutées à un livre comptable ;

Des calendriers des immobilisations sont affectés aux livres d'amortissement

à des fins de calcul et de répartition de la dotation aux amortissements ;

Des catégories d'immobilisation sont affectées à des fins d'utilisation avec les
livres d'amortissement. Toutes les immobilisations sont affectées à une
catégorie d'immobilisation, qui détermine les informations comptables et les
règles d'amortissement par défaut des immobilisations. Des méthodes
d'amortissement sont affectées aux catégories d'immobilisation.

Les livres opérationnels pour le groupe SNTL sont de l’ordre de 4 livres :

Livre FA Opérationnel Inclus dans le champ d’analyse des données post refonte

ASS Oui Oui

DSA Oui Oui

IMMO Oui Oui

DT Oui Oui

Le soumissionnaire est amené à revoir le paramétrage pour refléter la

structure organisationnelle cible. Pour se faire, le soumissionnaire devra :

 Analyser la structure d’immobilisation existante

 Reconduire et mettre à niveau les livres actuelles
 Créer et paramétrer de nouveaux livres d’amortissements
 5.6.5. Paramétrage de la clé immobilisation

La clé immobilisation est paramétrée actuellement sous 4 segments :

Numéro de Segment Nom de segment Taille

Segment1 Famille 3 caractères

Segment2 Nature 4 caractères

Segment3 Réserve1 1 caractère

Segment4 Réserve2 1 caractère

Cette clé fera l’objet d’une révision lors de la refonte de la version cible R12.
Ainsi, le soumissionnaire est amené analyser et proposer la décomposition
de la clé immobilisation cible.

5.6.6. Paramétrage de la clé catégorie

La clé catégorie est paramétrée actuellement sous 3 segments :

Numéro de Segment Nom de segment Taille

Segment1 Catégorie 3 caractères

Segment2 Sous - Catégorie 6 caractères

Segment3 Mode d’amortissement 3 caractères

Cette clé fera l’objet d’une révision lors de la ré-implémentation de la version

cible R12. Ainsi, le soumissionnaire est amené analyser et proposer la
décomposition de la clé immobilisation cible.
 5.6.7. Paramétrage de la clé lieu

La clé lieu est paramétrée actuellement sous 5 segments :

Numéro de Segment Nom de segment Taille

Segment1 Ville 2 caractères

Segment2 Direction 2 caractères

Segment3 Entité 2 caractères

Segment4 Sous entité 3 caractères

Segment5 Bureaux 3 caractères

De même, cette clé fera l’objet d’une révision lors de la ré-implémentation de

la version cible R12. Ainsi, le soumissionnaire est amené analyser et
proposer la décomposition de la clé immobilisation cible.

5.7. MODULE PO : GESTION DES COMMANDES

Le nouveau module PO devra être totalement intégré y compris :

 La gestion des demandes d’achats

 Workflow d’approbation des demandes d’achats
 La gestion des commandes
 Le workflow d’approbation des commandes
 La gestion des réceptions
 Rapprochement factures fournisseurs / réceptions
 Contrôle budgétaire depuis la DA
 La comptabilité d’engagements

Un certain nombre de réplications (interfaces en temps réel) devront être

réalisées avec le système Achats SNTL actuelles qui gère la parte sourcing et
suivi d’exécution des commandes.
Ces interfaces incluent entre autres :

 Envoi de la DA depuis Oracle vers système Achats SNTL

 Réplication des commandes entre Oracle EBS PO et système Achats
SNTL
 Envoi du résultat de contrôle budgétaire depuis Oracle EBS vers
système Achats SNTL
 Réplications des réceptions entre le système achats SNTL et Oracle
EBS
 Mise à niveau de l’interface facture existante pour assurer le
rapprochement automatique via interface des factures par réceptions
 Partage des référentiels fournisseurs et Articles

Le soumissionnaire est amené à intégrer l’ensemble des fonctionnalités

standards du module PO en plus des interfaces avec le système Achats
actuel.

Le soumissionnaire est amené aussi à émettre les recommandations pour

assurer une cohabitation judicieuse entre le nouveau module PO d’Oracle
EBS et le système actuelle achats.

5.8. NOUVELLES FONCTIONNALITES R12 :

La version R12 d’oracle applications est une version majeure qui intègre, en
plus des nombreuses nouveautés technologiques, de nouvelles
fonctionnalités qui portent principalement sur :

 Le contrôle d’accès Multi-Org

 Les Ledgers et Ledger Sets
 Le SubLedger Accounting
 Le Taxe-Engine
 L’Inter-company
 Le Bank Model

Son architecture se présente comme suit :

 Avec cette nouvelle Architecture il est désormais possible de tirer profit des
possibilités suivantes (Nous présentons celles en relation avec les modules
utilisés actuellement par SNTL).

5.8.1. Contrôle d’accès Multi-Org

Permet de donner l’accès à une responsabilité à un ensemble d’unités

opérationnelles. Ainsi la même responsabilité permettra par exemple à un
utilisateur AR d’accéder aux entités DSA, ASS et DT avec une vue consolidée
de leurs données. Les états de sortie standards englobent également les
données des Unités Opérationnelles concernées. Pareil pour un utilisateur
AP qui peut par exemple accéder via la même responsabilité aux données de
DSA, ASS et AP.

Ceci s’applique aussi bien sur la mise à jour des données que sur l’édition
des rapports et états standards.

Cette fonctionnalité est importante dans le contexte SNTL, puisque certaines

fonctions supports sont partagées par plusieurs entités. De nombreux
utilisateurs travaillent sur les données de plusieurs Unités opérationnelles.

Ci-après, à titre d’exemple, quelques Utilisateurs intervenant sur plusieurs

unités :

Responsabilité Module Unité Utilisateur

AR_DSA Receivables DSA 1785

AR_ASS Receivables ASS 1785

AR_DT Receivables DT 1785

AP_DSA Payables DSA CHAKIR

AP_ASS Payables ASS CHAKIR

AP_DT Payables DT CHAKIR

GL_ENGAGEMENT_ASS General Ledger ASS 2433

GL_ENGAGEMENT_DSA General Ledger DSA 2433

GL_ENGAGEMENT_DT General Ledger DT 2433

GL_ENGAGEMENT_IMM General Ledger IMMO 2433

O

FA - Responsable DT Fixed Assets DT 1957

FA - Responsable IMMO Fixed Assets IMMO 1957

FA - Responsable ASS Fixed Assets ASS 1957

FA - Responsable DSA Fixed Assets DSA 1957

5.8.2. Les Ledger et Ledger Sets

Donne la possibilité de générer et de suivre plusieurs comptabilités en

parallèle à partir des mêmes mouvements ou évènements de gestion
auxiliaires.

Par exemple à partir de la facture saisie et validée dans AP, le système peut
générer des écritures dans le système de comptabilité principal (légale) et
dans d’autres Ledgers secondaire tels que le système corporate ou encore
IFRS. Aucune ressaisie n’est nécessaire.

En plus et contrairement à la consolidation d’entités comptables qui ne

garde pas de piste d’audit vers les transactions d’origine, cette fonctionnalité
permet de disposer d’un drill-down vers les modules auxiliaires.

5.8.3. SubLedger Accounting

Le module AX (Global Accounting Engine) est remplacé dans la R12 par le

module SubLedger Accounting (SLA) qui fonctionne avec le module FA en
plus des modules AP et AR déjà couverts par AX dans la version 11i.
Ce module offre également la possibilité de personnaliser les règles de
généralisation des écritures à partir des transactions de base. A ce titre il
s’appuie sur les notions de classes d’évènements (Facture Fournisseur,
acompte fournisseur, paiement fournisseur, etc.) et validation facture
fournisseur, ajustement facture, annulation facture, etc.).

5.8.4. Utilisation de XML Publisher au niveau

reporting

La version R12 propose quelques 835 Modèles XML PUPLISHER pouvant

être personnalisées. 98 rapports globaux de la 11i ont remplacés par 19
extractions et 86 modèles.

5.8.5. Autres fonctionnalités améliorant

l’exploitabilité du système

D’autres fonctionnalités ou possibilités permettent également de faciliter

l’utilisation du système telles que la possibilité de copier un lot de pièce GL,
l’utilisation de la notion de ligne facture dans AP ou encore la possibilité de
lettrer un encaissement à une ligne facture client.
 5.9. AMELIORATIONS & ADAPTATIONS FONCTIONNELLES

Les améliorations fonctionnelles doivent couvrir :

 Mise à niveau des fonctionnalités en cours d’exploitation

 L’ensemble des nouvelles fonctionnalités R12 par module
 L’intégration du nouveau module PO
 Contrôle budgétaire et suivi des engagements
 L’ensemble des améliorations qui seront notées lors des ateliers de
cadrage des processus cibles par module dont on cite entre autres les
retenues fiscales et la gestion des arrêts

I.6 PERIMETRE TECHNIQUE

6.1. ETATS SPECIFIQUES & TRAITEMENTS SPECIFIQUES

L’ensemble des états de reporting spécifiques et traitements spécifiques

devront être réimplémentés ou adaptés au niveau de la version cible R12.

Le total est de l’ordre d’environ de 66 traitements développés sous plusieurs

technologies.

Prière de trouver ci-après la réparation d’un échantillon représentatif par

technologie :

Module Nombre de traitements

General Ledger 13
Payables 20
Receivables 33
Total général 66

Pour se faire, le soumissionnaire devra prendre en charge le reverse

engineering et l’adaptation et de l’ensemble des états de reporting et
traitements spécifiques listés dans le tableau qui suit :
 La liste des traitements et états spécifiques

Module Programme Type annoncé

General Ledger XXSNTL Contrepassation Engagement en Procédure stockée PL/SQL
masse
General Ledger XXSNTL Contrepassation Engagement Procédure stockée PL/SQL
General Ledger XXSNTL Budget Investissement Procédure stockée PL/SQL
General Ledger XXSNTL Budget Fonctionnement Procédure stockée PL/SQL
General Ledger XXSNTL Annulation Contrepassation Procédure stockée PL/SQL
Engagement en masse
General Ledger XXSNTL Annulation Contrepassation Procédure stockée PL/SQL
Engagement
General Ledger SNTL_GLCLIENT_AUX Procédure stockée PL/SQL
General Ledger SNTL_DETTES Procédure stockée PL/SQL
General Ledger SNTL_BALANCES Procédure stockée PL/SQL
General Ledger SNTL - Lancer Interface dettes Procédure stockée PL/SQL
General Ledger SNTL - Etat des créances Procédure stockée PL/SQL
General Ledger Programme - Ajouter/supprimer Sous-traité
combinaisons de synthèse par incréments
General Ledger Program - GL Euro as Functional Currency: Sous-traité
Convert Budget Amounts
Payables SNTL_VIEL_L Procédure stockée PL/SQL
Payables SNTL_VIEL Procédure stockée PL/SQL
Payables SNTL Génération Fichier Règlement Procédure stockée PL/SQL
Fournisseurs
Payables SNTL Création automatique des Lots Procédure stockée PL/SQL
factures AP DSA
Payables SNTL Commandes GTL Oracle Reports
Payables SNTL : Chargement des RIB DSA Procédure stockée PL/SQL
Payables SNTL - TRESORERIE - REGLEMENT PAR Procédure stockée PL/SQL
LOT
Payables SNTL - Lancer Interface Factures AP Procédure stockée PL/SQL
Payables SNTL - Import AP SQL/Loader Lines SQL*Loader
Payables SNTL - Import AP SQL/Loader Entête SQL*Loader
Payables SNTL - Archivage des factures d'interface AP Hôte
Payables Programme de génération des fichiers de Procédure stockée PL/SQL
virement en masse
Payables ONT Etat des mouvements non Oracle Reports
comptabilisés
Payables ONT - Ordre de virement (WORD) Oracle Reports
Payables ONT - Ordre de virement (PDF) Oracle Reports
Payables ONT - ORDRE DE PAYEMENT HORS Oracle Reports
METIER PLURI FACTURES
Payables ONT - Mise à disposition Oracle Reports
Payables ONT - Lettre d'information OV Oracle Reports
Payables ONT - Lettre d'information MAD Oracle Reports
Payables ONT - Lettre d'information CHQ Oracle Reports
Receivables Voir le journal du moteur d'encaissement SQL*Plus
Receivables TA vers DMS : traitement du transfert des Procédure stockée PL/SQL
déductions
Receivables SNTL_LETTRAGE Procédure stockée PL/SQL
Receivables SNTL situation des charges exploitation par Oracle Reports
agence
Receivables SNTL état situation marge nette park Oracle Reports
Receivables SNTL état situation marge nette agences1 Oracle Reports
Receivables SNTL état situation marge nette agences Oracle Reports
Receivables SNTL état facturation encaiss mensuel Oracle Reports
Receivables SNTL état facturation encaiss annuel Oracle Reports
Receivables SNTL BALANCE AGEE AX/AR ******* Oracle Reports
Receivables SNTL - ONICL2 : Etat de contrôle Oracle Reports
Receivables SNTL - Nouvelle Interface AR Procédure stockée PL/SQL
Receivables SNTL - Lancer Interface dettes GTL Procédure stockée PL/SQL
Receivables SNTL - INTERFACE DES ENCAISSEMENTS Procédure stockée PL/SQL
Receivables SNTL - Import Encaissement SQL/Loader SQL*Loader
Receivables SNTL - GTL : Annulation Règlement AR Procédure stockée PL/SQL
Receivables SNTL - GTL : Annulation LETTRAGE AR Procédure stockée PL/SQL
Receivables SNTL - Archivage fichiers encaissements Hôte
Receivables SNTL - AR Interface Facture - Chargement Hôte
Fichier sur table temporaire
Receivables Règlements du lot Procédure stockée PL/SQL
Receivables Rafraîchir manuellement la vue matérialisée Procédure stockée PL/SQL
HZ_RA_CONTACTS_MV
Receivables Programme de rapprochement automatique Procédure stockée PL/SQL
Receivables ONT Etat des mouvements non Oracle Reports
Comptabilisés
Receivables Moteur de traitement des encaissements en Procédure stockée PL/SQL
masse 1
Receivables Liste des déductions transférées depuis TA Oracle Reports
Receivables Liste déductions transférées depuis DMS Oracle Reports
Receivables Interface Facture AR ASS Procédure stockée PL/SQL
Receivables Insérer un enregistrement de contrôle Procédure stockée PL/SQL
Receivables Imprimer les relevés CPG Oracle Reports
Receivables Etat de rapprochement automatique Oracle Reports
Receivables DMS vers TA : traitement du transfert des Procédure stockée PL/SQL
déductions
Receivables Chargement des règlements ASS Procédure stockée PL/SQL
Receivables Balance chronologique - 7 intervalles - Par Oracle Reports
ligne d'activité
 6.2. DEVELOPPEMENT SPECIFIQUE

Le soumissionnaire est tenu de reconduire tous les développements

spécifiques opérationnels chez le groupe SNTL de l’environnement 11i vers
l’environnement cible de la R12 dont on cite entre autres :

 Toutes les personnalisations sur les panneaux de la solution

 Les jeux de valeurs basés sur des tables,

 Les triggers, procédures stockées, packages et fonctions

créées par le groupe SNTL,

 Les personnalisations Workflow et les workflows spécifiques

 Les traitements spécifiques listés dans le tableau ci-avant

 Tout autre compostant non standard et exploité par le groupe

SNTL

6.3. EXIGENCES TECHNIQUES DE LA SOLUTION CIBLE

 Temps de réponse

La solution mise en place devra garantir un temps de réponse s’établissant

autour de 95% à minima équivalent à celui assuré dans la version actuel
11i.

Les exécutions de traitements devront respecter des durées compatibles avec

les contraintes d’exploitation.

 Ergonomie

L’ergonomie devra favoriser la lisibilité, l’accessibilité des informations, et

leur réutilisation. L’ensemble des navigateurs modernes et en vigueur
devront être supportés et ceci pour et les interfaces web et celles Oracle
Forms.

 Développement spécifique

Tout développement spécifique doit impérativement respecter les mêmes

normes et le même degré de qualité que le progiciel (ergonomie, convivialité,
etc…). De même, les codes sources doivent être fournis à la SNTL,
commentés, documentés et bien présentés.

 Documentation :
La documentation du progiciel sera fournie sur support papier et support
informatique. Elle devra être accessible en ligne par les utilisateurs. Elle sera
rédigée en français.

La documentation concernant les modules spécifiques sera fournie dans le

même mode et la même extension que le reste de la documentation
standard.

 Versions du progiciel

Le prestataire s’engage à fournir la version la dernière version certifiée. Les

versions successives du progiciel devront reprendre le paramétrage mis en
place. Le prestataire explicitera les techniques qui permettent de garantir
cette évolutivité ainsi que le portage de paramétrage d’un environnement à
un autre.

 Confidentialité, sécurité et habilitations

Le progiciel devra permettre de créer et d’administrer des profils et d’affecter

un ou plusieurs profils à un utilisateur. Il doit également assurer :

Contrôle d’accès des utilisateurs aux applications par nom et mot de passe
sécurisé. Le progiciel doit gérer la notion de profil utilisateur permettant de
définir les autorisations distinctes en fonction de l’appartenance à un groupe

Gestion des droits des utilisateurs sur les fonctionnalités (Possibilité de

confectionner les menus utilisateurs selon les profils)

Gestion standard et uniforme du contrôle d’accès et des droits sur les

fonctionnalités et sur les données à partir d’une interface de gestion fournie
avec la solution. Traçabilité

Le progiciel doit assurer la « traçabilité » qui fournit des informations sur le

nom de l’utilisateur, la nature de l’opération, les données saisies ou
modifiées avant et après l’opération, la date et l’heure de l’opération.

 Purge et archivage des données

La possibilité d’archiver les données ainsi que l’apurement automatique des

données archivées ;

La possibilité de la restauration automatique d’archivage.

Autres exigences techniques complémentaires

La solution proposée devra prendre en considération les critères ci-

après :

Logiciel multi-langues, multi-législation, et multi société

 Améliorer les mécanismes d’échanges d’informations avec les système
opérants internes et externes

Portabilité automatique du système à l’évolution avec les versions du

progiciel

Possibilité de personnaliser les menus

Fonctionnement multi-tâches et multi-utilisateurs concurrentiels par

fonctionnalité

Assurer la journalisation des transactions et des traitements avec des règles

de purge paramétrables

Permettre la restauration des données dans l’état où elles étaient avant le

traitement (Gestion des modes transactionnels)

Possibilité de création de tables supplémentaires.

Possibilité d’extraire et d’exporter toutes données ou résultats de requêtes

vers Excel

Possibilité de développements supplémentaires totalement intégrés avec les

applications de la solution

Existence d’un outil de chargement des données simple d’utilisation et

orienté utilisateurs pour le chargement des données de masse dans le
système. Ces chargements doivent être automatisés pour s’exécuter de
manière périodique ou à la demande.

Visualisation des éditions avant leur impression avec possibilité d’imprimer

sur un équipement prédéfini ou de choisir l’équipement au moment de la
commande d’édition

Fonctionnement en temps réel et mise à jour instantanée et en ligne des

informations

6.4. Caractéristiques techniques du système Oracle actuel

Les caractéristiques du système Oracle déployé sont les suivantes :

Composant Version

Oracle
11.5.10.2
Applications

Oracle Forms 11.5

Java 1.6.0
 RDBMS Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

6.5. PLATEFORME MATERIELLE

La solution Oracle E-business Suite est hébergée actuellement sur 3

environnements :

Environnements O-EBS (Site principal & site de secours)

Site Environnement O-EBS (APPS & BD) Qualification
Rabat EBSPROD PROD
Rabat EBSSMLT DEVELOPPEMENT/TEST
Casa HM EBSSMLT TEST RESTAURATION/SECOURS

Les caractéristiques suivantes de chaque environnement est donné en ce

qui suit :

Caractéristiques des environnement

Environnement (APPS & BD) Caractéristique
EBSPROD CPU : 4 processeurs virtuel
RAM :18 Go
SWAP : 13568 MB
Vitesse d’horloge :4157 MHz
Cartes FC :4
Cartes Ethernet :3
OS : AIX power 7
EBSSMLT (RABAT) CPU :4
RAM :18 Go
SWAP :512MB
Vitesse d'horloge 4157
Cartes FC :2
Cartes Ethernet :2
OS : AIX power 8
EBSSMLT (CASA HM) CPU :4
RAM 16384 MB
SWAP : 13568 MB
Vitesse d’horloge 4157
Cartes FC :2
Cartes Ethernet : 2
OS : AIX power 7
 6.6. SAUVEGARDE

Le soumissionnaire est tenu d’inventorier la procédure de sauvegarde et de

proposer, le cas échéant, les mécanismes de sauvegarde à mettre en place.
Ces mécanismes devront être compatibles avec les outils de sauvegarde
actuellement utilisés.

6.7. ACCES ET SECURITE

L’accès à l’environnement Oracle EBS se fait via le réseau LAN et WAN.

Le protocole d’accès en vigueur via les navigateurs web pour l’environnement

Oracle EBS est de type HTTP. Le soumissionnaire est tenu de garantir le
passage au protocole d’accès de type HTTPS après la refonte et la ré-
implémentation de la dernière version certifiée R12 dans l’environnement de
production.

Le soumissionnaire est convié à fournir les termes de la politique de sécurité

selon les standards Oracle et en adéquation avec les nouvelles
fonctionnalités de la version R12 du système Oracle EBS. Cette procédure
doit inclure, entre autres, la description des différentes étapes techniques de
gestion de sécurité et administration des comptes Oracle (Base de données,
Système, Oracle Applications). La réalisation et le test de la procédure
incombe à la charge du prestataire.

6.8. VOLUMETRIE ET PERFORMANCE

Le prestataire est tenu de prendre connaissance de la volumétrie des

transactions des batchs et traitements utilisés afin de recalculer le
dimensionnement d’espace nécessaire pour le stockage et définir les actions
d’optimisation à adopter.

Il convient de préciser que les performances à atteindre après le projet de

refonte doit au minima être équivalentes aux performances actuelles au titre
des traitements transactionnels.

Le soumissionnaire sera également convié à fournir l’approche et le mode

opératoire de configuration du serveur GTS afin de permettre une gestion
optimale des traitements consommateurs en termes de ressources.
I.7 EXIGENCES D’INTEGRATION AVEC LE SI DE SNTL
7.1. CARTOGRAPHIE APPLICATIVE

Ci-dessous la cartographie applicative du SI ainsi que les flux échangés

entre le système Oracle EBS et les autres applications connexes.

Ci-dessous la cartographie applicative du SI ainsi que les flux échangés

entre le système Oracle EBS et les autres applications connexes.

ACHA Suite FINANCE VENT

TS Oracle EBS ES
Solution métier GL Solution métier
AR
« GTL » (DT) « GTL » (DT)

FA AX
Application métier
Application métier
« DS »
« DS »
(DSA/ASS)
(DSA/ASS) PO

Application SI carte AP Application SI carte

RH/PAIE

Module Oracle EBS

HR ACCESS
en cours
d’exploitation dans la

Module Oracle EBS à

intégrer dans la
version R12 Figure 1 : Cartographie applicative du SI
SNTL
Application métiers
Spécifiques
Solution Non Oracle
 7.2. INTERFACES AVEC LE SYSTEME D’INFORMATION SNTL

La solution Oracle EBS s’interface avec d’autres composantes du SI de SNTL,

ci-dessous ces interfaces/ouvertures :

Module Interfaces

 Solution métier « GTL » (DT)

Oracle Payables  Application métier « DS » (DSA/ASS)
 Application SI carte
 Solution RH & Paie (HR ACCESS)

 Solution métier « GTL » (DT)

Oracle Receivables  Application métier « DS » (DSA/ASS)
 Application SI carte

General Ledger  Interface d’engagement avec le module AP

Le soumissionnaire est amené à assurer l’adaptation fonctionnelle et

technique, ainsi que le reverse engineering selon le cas, de l’ensemble des
interfaces. Il devra aussi homogénéiser à l’échelle groupe les technologies
utilisées et les contrats d’interface et assurer les 4 options suivantes :

 Interfaçage via web services autour d’Oracle SOA (option

recommandée)
 Interfaçage via DBLINKS
 Interfaçage via des fichiers plats
 WebADI pour l’intégration des données en masse vers les modules
auxiliaires

L’arbitrage des options à utiliser par interface sera fait lors des ateliers de
cadrage. Le soumissionnaire devra prendre en charge l’implémentation de
ces interfaces conformément aux options adoptées (y compris la mise en
place de l’architecture technique SOA).
 7.3. INTERFACES ENTRE LES DIFFERENTS MODULES DE L’ERP
CIBLE

Le soumissionnaire est responsable de toutes les interfaces nécessaires entre

les différents modules de la solution Oracle EBS sous la version cible de la
R12.

Toutes les interfaces qui viendraient à être nécessaires pour le

fonctionnement optimal de la solution compte tenu des exigences du groupe
SNTL reprises dans le présent appel d’offres sont entièrement de la
responsabilité du soumissionnaire et totalement à sa charge.

I.8 EXIGENCES EN MATIÈRE DE REPRISE DES DONNÉES

8.1. PERIMETRE DE LA REPRISE DES DONNEES

Le détail des données à reprendre se présente comme suit :

 Factures clients :
o Reprendre le détail des factures des années non prescrites (4
années sauf en cas de déficit)
o Reprendre l’ensemble des factures non encore totalement payées
quel que soit la profondeur.
 Encaissements clients :
o Reprendre le détail des encaissements clients des années non
prescrites (4 années sauf en cas de déficit)
o Reprendre l’ensemble des encaissements relatives aux factures
non encore non encore totalement.
 Lettrage AR : Reprendre le lettrage des factures à partir d’une année à
définir (en principe 2021).
Même logique s’applique pour les factures fournisseurs plus les factures non
encore payées.
 Factures fournisseurs :
o Reprendre le détail des factures des années non prescrites (4
années sauf en cas de déficit)
o Reprendre l’ensemble des factures non encore totalement payées
quel que soit la profondeur.
 Paiements fournisseurs :
o Reprendre le détail des paiements fournisseurs des années non
prescrites (4 années sauf en cas de déficit)
 o Reprendre l’ensemble des paiements relatives aux factures non
encore non encore totalement.
 Lettrage AR : Reprendre le lettrage des factures à partir d’une année à
définir lors de la phase de cadrage ( en principe 2021).
 Immobilisations : Reprendre la totalité des immobilisations actives
avec les informations financières rattachés (cumul des amortissement,
valeurs nettes comptables, méthodes d’amortissement, …)
 Comptabilité : reprendre le solde d’ouverture de l’année précédant la
première année non prescrite. Les transactions des années non
prescrites seront alimentées dans les modules auxiliaires et
comptabilisés par la suite vers le module GL.

8.2. VOLUMETRIE DES DONNEES

La volumétrie des principales opérations se présente comme suit :

 Nombre de facture clients gérées : de l’ordre de 100 000 factures
client générés par an
 Nombre de factures fournisseurs : de l’ordre de 90 000 factures
générés par an
 Nombre d’immobilisations : de l’ordre de 15 656 immobilisations
 Comptabilité auxiliaire fournisseurs et écritures immobilisations :
de l’ordre de 734 000 lignes par an

8.3. MECANISMES DE REPRISE DES DONNEES

La reprise des données devra se faire de façon automatisée. Le système doit

disposer des moulinettes de reprise et de contrôle des données.
Le titulaire communiquera les structures dument commentées des données
à reprendre. SNTL se chargera des extractions selon les spécifications
communiquées.
Pour les données qui ne sont pas gérées actuellement dans des solutions, la
reprise se fera soit par saisie directe dans le système soit par la prise en
charge de fichier Excel. La décision de choix de l’une des deux approches
reviendra à la SNTL. Le soumissionnaire doit disposer dans ce cas des
moulinettes de chargement à partir de fichier Excel.
 I.9 PRESTATIONS DEMANDEES
9.1. PRESTATIONS DE REFONTE

Dans le cadre de ce projet de refonte le soumissionnaire doit fournir

l’ensemble des prestations de mise en œuvre suivantes :

 Prestations d’installation et de configuration des différentes

composantes de la version cible R12 en environnements projet et
environnement de production de la solution
 Prestation d’architecture fonctionnelle et technique
 Prestation d’étude de convergence, de spécification, de conception
détaillée, de paramétrage, de prototypage, de réalisation, de tests et de
mise en production de la solution cible réimplémentant (ou migrant)
fidèlement l’ensemble des fonctionnalités utilisées dans la version
actuelle 11i ainsi que les nouvelles fonctionnalités de la version R12 et
les améliorations et adaptations fonctionnelles demandées
 Prestations de développement et adaptation des composantes
spécifiques, complémentaires, de reporting, d’interfaces, de reprise des
données et d’intégration globale du système cible
 Accompagnement post démarrage en période de VSR (Vérification de
Service Régulier) d’une durée d’un an.

9.2. PRESTATIONS DE FORMATION

Le soumissionnaire doit s’engager à assurer dans le cadre du projet de

refonte les formations fonctionnelles et techniques destinés aux
interlocuteurs suivantes :

Catégorie Domaine de Formation

Formation de l’équipe projet
Formation fonctionnelle sur les différents modules
de la version cible R12
Formation équipe technique sur les outils de
développement
Formation équipe technique administration
Formation équipe technique Exploitation

Formation d’ergonomie de la version cible R12

Formation fonctionnelle pour chaque profil

Formation des formateurs
d’utilisation de la solution cible
internes
Il revient au soumissionnaire de donner le détail des formations
fonctionnelles et techniques préconisées pour une prise en main complète
soit possible par les équipes SNTL y compris les supports de formation.

Aussi, le soumissionnaire doit prévoir les cycles de formation complets en

vue d’une maitrise technique totale par l’équipe technique SNTL sur le volet
administration et exploitation.

Il doit s’engager sur la réalisation des cursus complets de formation aux

formateurs sur la base de la solution finale paramétrée dans le système. Les
supports de cours ainsi que les exercices prévus doivent être adaptés dans
ce sens.

Le titulaire présentera dans son offre le détail des formations proposées pour
chaque cursus.

9.3. PRESTATIONS DE TRANSFERT DE COMPETENCES

Le soumissionnaire doit veiller à ce que les équipes fonctionnelles et

techniques du groupe SNTL assimilent et maîtrisent correctement
l’utilisation de toutes les composantes, processus et technologies
préconisées ou nécessaires au fonctionnement optimal de la version cible
R12 dans tous ses aspects fonctionnels, techniques, de paramétrage et
d’intégration.

L’équipe technique doit assumer graduellement l’administration et

l’exploitation de la solution jusqu’à atteindre un niveau d’autonomie
suffisant à partir de la phase de Recette.

Etant cela, le soumissionnaire doit apporter toute la documentation et

support nécessaire aux utilisateurs et ressources techniques du SNTL en
vue de réaliser cet objectif

9.4. PRESTATIONS DE MAINTENANCE EN PERIODE DE

GARANTIE

Le soumissionnaire doit s’engager à assurer la maintenance préventive et

curative du système pendant la durée de garantie

Il a donc la responsabilité de :

• Faire face à tout fonctionnement défectueux des éléments faisant

partie du progiciel

• Fournir des mises à jour et des nouvelles versions du progiciel ;

• Procéder au rehaussement du niveau de performance du progiciel

suite à des constats sur ses fonctionnalités
 • Résolution des incidents remontés

• Résolution des bugs ou dysfonctionnement

• Assurer une maintenance préventive périodique de façon trimestrielle

pour s’assurer du bon fonctionnement de la solution que cela soit sur les
aspects fonctionnels ou techniques (administration, exploitation, …)

• Installer les mises à jour éventuelles

• Intervenir pour la réalisation de modifications de paramétrage ou de

fonctionnement qui seraient éventuellement nécessaires pendant le délai de
garantie

I.10 METHODOLOGIE
10.1. DESCRIPTION DE LA METHODOLOGIE DE MISE EN
ŒUVRE PRECONISEE PAR SNTL :

La méthodologie préconisée par SNTL est illustrée dans le schéma qui suit :

Initiation et Analyse de Tests Recette

l’existant Refonte Unit. Utilisateurs MEP
Cadrage
/Intégration

Formations équipe
Préparation Bascule
projet/technique

Le soumissionnaire doit décliner son approche de gestion pour les différents

chantiers du projet. Il doit au minimum respecter et réaliser l’ensemble des
différentes taches décrites dans la suite de ce chapitre.
 10.1.1. Étape I – Initialisation & Cadrage

Cette phase a pour principal objectif d’identifier et de structurer l’ensemble

des préalables nécessaires pour l’organisation et le déroulement du projet et
les modalités de sa conduite

Le soumissionnaire doit assurer dans cette phase les principales étapes et

tâches suivantes :

Sous phase Intitulée Consistance

1.1 Organisation du projet  Définition de l’organisation de l’équipe projet

 Définir les instances de gouvernance du projet
 Désignation des différents membres des équipes côté
intégrateur et SNTL
 Désignation des membres des instances de
gouvernance du projet
 L’approche méthodologique et de collaboration avec
les équipes SNTL
 Préparation de la logistique du projet : mise à
disposition de salles, PC, connexions, Internet
1.2 Planification détaillée  Elaboration du plan et les modalités de refonte (étapes
de la refonte de refonte) ;
 Elaboration du planning détaillé du projet de refonte
avec description des travaux et des itérations
1.3 Elaboration du Plan  Elaboration du plan qui a pour objectif de :
de Management du o Définir l’objectif, contenu et livrables du projet
Projet o Permettre la planification, le suivi et le contrôle
de la mise en œuvre de la solution par les
instances de gestion du projet
o Constituer le référentiel méthodologique et
organisationnel du projet
o Préciser les rôles et responsabilités de chaque
partie
o Fournir aux membres de l’équipe projet
(Intégrateur et SNTL) un référentiel unique de
gestion du projet, de gestion de la
documentation, des normes de réception des
livrables, des règles de suivi de qualité et de
risques, et en général des règles de suivi de tous
les événements de la vie du projet

1.4 Définition des  Définition des caractéristiques des environnements

Prérequis techniques
de la refonte
nécessaires au déroulement du projet de refonte tels
que :
o Environnement de référence
o Environnement de refonte
o Environnement de recette
Sous phase Intitulée Consistance

o Environnement de formation
o Environnement de Pré-production
o Environnement de Production
 L’intégrateur doit définir l’ensemble des
environnements système dont il aura besoin ainsi que
les modalités de leur gestion (création, objectifs,
responsabilité, durée de vie)
 L’administration des environnements du projet doit
être sous la responsabilité de l’intégrateur avec un
support des ressources de SNTL.
 Définition des logicielles à installer

Dans cette étape, le soumissionnaire est tenu aussi de prendre connaissance

de l’ensemble des modules déployés en production, et de compléter et valider
les spécificités existantes (la liste des spécificités est fournie dans la partie
« 6.1. Etats spécifiques & traitements spécifiques »).

Durant cette étape, le prestataire a l’obligation de prendre connaissance,

également, de tout type de documentation utile au bon déroulement du
projet ; documentation de paramétrage, documentation d’accompagnement
technique, et tout autre élément pouvant impacter le déroulement de la
phase.

À l’issue de cette étape le prestataire est tenu de fournir les livrables

suivants :

Livrable Description

Note de cadrage Document décrivant l’approche

méthodologique du projet et de
collaboration avec les équipes SNTL

Plan d’assurance Qualité Document précisant les modalités

de conduite du projet afin d’assurer
la qualité du déroulement du projet

Planning détaillé Planning détaillé avec la mise en

avant des travaux et des réunions à
programmer pour la durée du
projet.
 N.B : Parmi les éléments de réponse au présent appel d’offres, le
soumissionnaire est tenu de fournir le plan de refonte envisagé en précisant
les étapes à suivre conformément aux recommandations de l’éditeur Oracle.

10.1.2. Étape II – Formations équipe projet et

équipe technique

Cette phase a pour objectif de réaliser les formations nécessaires à l’équipe

projet ainsi que l’équipe technique SNTL afin de garantir le transfert de
compétences et la bonne exploitation fonctionnelle du système Oracle EBS
dans sa version cible R12.

Le soumissionnaire est tenu à dérouler les formations comme suit :

 Le planning des formations est à proposer par le soumissionnaire et à

valider par l’équipe SNTL : le planning doit comprendre les dates de
formation, l’objet de la formation et la population cible ;

 Le soumissionnaire doit fournir une équipe de consultants qualifiés

disposant de l’expérience requise par nature de formation ;

 Les formations de l’équipe projet et celle technique doivent couvrir au

minimum les thèmes suivants :

Formation Thème

Overview et Zoom sur les nouveautés apportées par la version R12

Formation ergonomique autour de la version cible R12

Module GL

Module AP

Equipe projet Module AR

Module FA

Module PO

Module SLA (SubLedger Accounting)

E-business Tax

Formations nécessaires pour les « DBA Oracle Applications » de SNTL

pour l’administration la Solution E-Business Suite dans sa version cible
Equipe technique
R12
 Formations nécessaires pour l’équipe SI SNTL pour l’administration,
l’exploitation des modules de la R12

Le soumissionnaire est tenu à fournir un support papier et un support

électronique par formation par personne.

Il est tenu de fournir également les livrables suivants :

Livrable Description

Planning des formations Planning par objet de formation, et par population cible

Supports de formation L’ensemble des documents et supports utilisés dans la

formation

Manuels d’utilisateurs Supports de formation des utilisateurs finaux

Fiches d’évaluation Fiches d’évaluation des formations à chaud et à froid

10.1.3. Étape III – Analyse de l’existant et Étude

Cette phase vise à porter une analyse détaillée sur le volet fonctionnel et
celui technique.

L’analyse doit englober au minimum les points listés dans le tableau ci-
dessous :

Volet Consistance

Diagnostique des processus ERP existants

Fonctionnalités métiers en cours d’exploitation

Etats et traitements standards en cours d’exploitation

Volet fonctionnel Workflows standards et notifications en cours d’exploitation

Référentiels

Tout autre composant fonctionnel en cours d’exploitation

Fonctionnalités métiers non encore exploitées

Développements et états spécifiques en cours d’exploitation

L’ensemble des fonctionnalités techniques

Volet technique Configurations techniques

 Applications connexes

Toute autre composante logicielle sollicitée par la refonte

N.B : Les états recensés dans la liste des spécificités donnée dans la partie «
6.1. Etats spécifiques & traitements spécifiques », sont à compléter et valider
avant d’être reconduite dans la version R12 du système Oracle EBS.

À l’issue de cette étape le soumissionnaire doit fournir les livrables suivants :

Livrable Description

Dossier d’étude de Rapport d’analyse de l’existant et de définition du périmètre

l’existant fonctionnel et technique. Le rapport doit englober l’ensemble des
attentes et besoins fonctionnels attendus

Dossier de recette  Tests unitaires

 Tests d’intégration
 Scénarios et scripts de recette

10.1.4. Étape IV -Refonte

Cette phase a pour objectif de procéder à la refonte de la solution vers la

version cible R12 dans l’environnement dédié mis à sa disposition.

Cette refonte se fera selon la démarche initiée par le soumissionnaire et

validée par l’équipe SNTL.

Cette démarche doit garantir les conditions optimales de réalisation de la

refonte, et proposer des étapes émises par l’éditeur Oracle pour la réduction
des risques et du temps d’arrêt de la production.

L’environnement de Pré-Production sera utilisé pour tester et valider la

refonte. Pour se faire, le soumissionnaire est tenu d’assurer les prestations
suivantes :
Prestation Consistance

Outils de refonte Le Prestataire doit être muni de tous les logiciels et outils nécessaires
pour la réalisation de la refonte

La ré-implémentation iso fonctionnelle doit couvrir l’ensemble des

composants techniques et fonctionnels de l’environnement de
production actuel

L’installation de la base de données Oracle vers la dernière version

supportée par la R 12.2

L’installation de l’applicatif avec la dernière version certifiée de la R12

Paramétrage et mise en service la version cible

Ré-implémentation Intégration des modules fonctionnels du périmètre identifié

de la version cible
Intégration du nouveau Module PO

Reprise des données transactionnelles et référentiels

Mise en place des améliorations fonctionnelles et techniques demandées

Déploiement des nouvelles fonctionnalités de la R12

Adaptation et mise en place des développements spécifiques en

production sous la version cible R12

La documentation de toute intervention technique et/ou fonctionnelle

requise pour la ré-implémentation : cette documentation est à restituer
dans le dossier de paramétrage ;

N.B : Il convient de préciser que si le standard permet de prendre en charge

un développement spécifique ou un état spécifique, le soumissionnaire est
tenu proposer cette évolution à l’équipe SNTL pour prise en compte.
 À l’issue de cette étape le prestataire doit fournir les livrables suivants :

Livrable Description

Dossier de paramétrage relatif Document de paramétrage décrivant l’ensemble des

à la ré-implémentation de la étapes déroulées lors de la ré-implémentation, les
version cible R12 blocages rencontrés et les solutions apportées

Dossier de paramétrage Dossier définitif du paramétrage de l’ensemble de modules

objets de la refonte, du nouveau module PO, des
améliorations fonctionnelles et techniques demandées

Livrables des installations et L’ensemble des livrables restituant les actions

des configurations d’installation et les configurations effectuées

Registre des anomalies Rapport comprenant toutes les anomalies techniques

techniques constatées constatées et intégrant les actions entreprises par le
prestataire pour résoudre les anomalies

10.1.5. Étape V - Tests unitaires et Tests

d’intégration

Le soumissionnaire est tenu de dérouler les tests unitaires et d’intégration

dans l’environnement mis à disposition par l’équipe SNTL au minimum les
tests suivants :

Test Consistance

Tests unitaires  Déroulement des tests internes à l’équipe de

Test d’intégration
Test de montée en charge
soumissionnaire sur « l’environnement de refonte »
 Tests des moulinettes d’extraction des données
 Tests des interfaces externes SNTL
 MAJ et Validation des états et traitements spécifiques
 Déroulement par l’intégrateur des tests d’intégration
globale impliquant les processus standards et les
développements spécifiques
 Déroulement des tests de non régression
 Les tests de montée de charge et de performance sont à
dérouler dans cette étape par le soumissionnaire
 L’évaluation de la performance sera effectuée par
l’équipe SNTL
 Le dossier de recette peut subir des évolutions et des enrichissements en
cours de test, le soumissionnaire est tenu de prendre en considération les
modifications à intégrer dans le dossier de recette ;

Les résultats des tests unitaires et d’intégration doivent être consignés dans
le dossier de recette par le soumissionnaire, et ce dernier est tenu de fournir
un récapitulatif des travaux de test avec la version actualisée du dossier de
recette ;

Un PV de recette est à prévoir pour formaliser la validation des tests

unitaires et d’intégration menés et confirmer le passage à l’étape de recette
utilisateurs.

À l’issue de cette étape le soumissionnaire doit fournir les livrables suivants :

Livrable Description

Dossier de recette Version actualisée du dossier de la recette récapitulant

tous les tests déroulés et les résultats obtenus

Registre des anomalies Rapport comprenant toutes les anomalies constatées et

constatées intégrant les actions opérées par le soumissionnaire pour
résoudre les anomalies
 10.1.6. Étape VI – Recette utilisateurs

Le déroulement de la recette utilisateurs est à commencer après la validation

et l’acceptation des tests unitaires et d’intégration réalisés.

Le soumissionnaire est tenu d’assurer les formations nécessaires à l’équipe

utilisateurs qui va faire la recette par module et compte tenu du cahier de
recette.

Aussi, le soumissionnaire est tenu d’assurer dans cette étape, au minimum,

les prestations suivantes :

Prestation Consistance

Le soumissionnaire est tenu d’assister les utilisateurs clés et l’équipe

projet SNTL lors du déroulement du cahier de recette ;

Le soumissionnaire est tenu de fournir les jeux de données adéquats

Assistance recette
pour le déroulement de la recette utilisateurs
utilisateurs
Le soumissionnaire est tenu d’assister les utilisateurs clés et l’équipe
projet SNTL lors de la recette du spécifique existant inventorié, et des
échanges avec les applications connexes

Le soumissionnaire est tenu de traiter les anomalies de recette et les

bugs remontés par les utilisateurs clés et l’équipe projet SNTL
Traitement des
anomalies de Les anomalies constatées en cours de test sont à remonter aux comités
recette de suivi pour analyse et décision, le soumissionnaire est tenu de
fournir l’ensemble des éléments d’analyse pour prise de décision par
l’équipe SNTL

Le dossier de recette peut subir des évolutions et des enrichissements

en cours de recette, le soumissionnaire est tenu de prendre en
Dossier de recette
considération les modifications à intégrer dans le dossier de recette ;

Les résultats des tests de fonctionnement doivent être consignés dans

le dossier de recette par le soumissionnaire, et ce dernier est tenu de
fournir un récapitulatif des travaux de recette avec la version finale du
dossier de recette
 Un PV de recette est à prévoir pour formaliser la validation de la recette
utilisateurs et confirmer le passage à la mise en production.

À l’issue de cette étape le soumissionnaire doit fournir les livrables suivants :

Livrable Description

Dossier de recette Version finale du dossier de la recette récapitulant tous

les tests déroulés et les résultats obtenus

Registre des anomalies Rapport comprenant toutes les anomalies constatées et

constatées intégrant les actions opérées par le soumissionnaire pour
résoudre les anomalies.

10.1.7. Étape VII – Préparation à la bascule

Cette étape est à prévoir en parallèle aux étapes tests et recettes. Il s’agit
d’une étape cruciale qui conditionne le bon déroulement de la mise en
production.

Le soumissionnaire se doit d’intégrer AU minimum les spécificités suivantes

dans son plan d’actions bascule afin de préparer au mieux la mise en
production :

Prestation Consistance

Répétition générale Le prestataire est tenu de calculer le temps d’exécution des actions
(chronogramme) de mise en production dans l’environnement de
préproduction mis à sa disposition afin d’optimiser les actions de ré-
implémentation dans l’environnement de production et réduire le
temps d’arrêt de la production, qui ne doit pas excéder 2 jours ouvrés.

Les opérations de double saisie sur les deux systèmes Oracle EBS 11i
et la version migrée R12.2 sont à maintenir après la mise en
production, afin de permettre la certification des résultats comptables
obtenus sur les deux systèmes.

Double saisie sur les Le soumissionnaire est tenu de prendre en considération cette
deux systèmes condition dans l’élaboration du planning de mise en production afin de
Oracle EBS prévoir la mise en production quelques jours avant les arrêtés
comptables. Les arrêtés comptables sont programmés à la fin de
chaque mois.
 La double saisie sur les 2 systèmes est à prévoir pendant une période
de 15 jours minimum.

Site principale Installation ou (Montée de version) du système d’exploitation et du

système Oracle EBS en production dans le site principal

Site de secours Installation ou (Montée de version) du système d’exploitation et du

système Oracle EBS en production dans le site de secours

À l’issue de cette étape le soumissionnaire doit fournir les livrables suivants :

Livrable Description

Plan de bascule Plan d’action regroupant l’ensemble des actions à

entreprendre en termes de prérequis, actions de bascule
et actions Post bascule

10.1.8. Étape VIII - Mise en production

La décision de mise en production revient à l’équipe SNTL, suite à

l’évaluation de l’étape de recette et au déroulement de la recette. La mise en
production doit se dérouler selon les étapes suivantes :

Prestation Consistance

Formation Formation par module pour les utilisateurs finaux

Le soumissionnaire entamera la mise en production du système

Oracle dans sa version R12 dans l’environnement de production
après la validation de l’équipe SNTL du bon déroulement des tests
Mise en de recette utilisateurs
production
Le rapport de mise en production doit être fourni par le
soumissionnaire à l’issue de la mise en production de la solution

Le soumissionnaire est tenu de prendre en charge l’ensemble des

anomalies techniques et/ou fonctionnelles constatées par les
Stabilisation
utilisateurs jusqu’à la stabilisation définitive de la production sous
de la version
la version R12.
cible de la
solution La période de stabilisation du système est à convenir avec l’équipe
SNTL, le soumissionnaire doit durant cette période répondre à tout
type d’anomalies techniques et/ou fonctionnelles remontées par les
 utilisateurs ou par l’équipe SNTL, jusqu’à obtenir une stabilisation
définitive du système en production

La procédure et politique de sauvegarde

Procédure de clonage

Procédures Procédure de gestion des mots de passe

d’exploitation
Procédure de collecte des statistiques dans le système Oracle

Purge des Logs et données obsolètes

Politique de sécurité du système Oracle EBS R12

À l’issue de cette étape, le soumissionnaire doit fournir les livrables

suivants :

Livrable Description

Rapport de mise en Rapport détaillant la procédure de mise en production de

production la version R12 d’Oracle

Procédures d’exploitation L’ensemble des procédures objets de mise à jour et

d’enrichissement effectuées par le prestataire

Bilan Phase Document récapitulatif des étapes clés de la phase

I.11 LIVRABLES DU PROJET

Ci-après la liste des livrables à produire par le prestataire et à remettre à
l’équipe SNTL selon les étapes décrites ;

Étape Livrable

Note de cadrage

Cadrage Plan d’assurance qualité

Le planning détaillé avec description des travaux

Dossier d’étude de l’existant

Analyse de l’existant Dossier de l’étude de convergence

Dossier de recette
 Dossier de ré-implémentation de la version cible R12

Dossiers de paramétrages par module

Livrables des installations et des

Refonte
Configurations

Procédures d’assainissement des référentiels

Rapport des anomalies techniques constatées

Dossier de recette mis à jour avec récapitulatif des travaux de

Tests unitaires et recette
d’intégration
Rapport des anomalies constatées

Dossier de recette mis à jour avec récapitulatif des travaux de

Recette Utilisateur recette

Rapport des anomalies constatées

Préparation Bascule Plan de bascule

Rapport de mise en production

Mise en production Procédures d’exploitation

Bilan du projet

Planning des formations

Supports de formation

Formations Manuels d’utilisateurs

Rapport de formation

Fiches d’évaluation.
I.12 EQUIPE PROJET
L’équipe projet du soumissionnaire doit disposer des qualifications
nécessaires et des expériences confirmées autour de l’ERP Oracle EBS et
dans des projets similaires. Les profils demandés pour mener le projet sont :

Directeur de projet :

 Formation : BAC +5 ou supérieur

 Expérience : Minimum 15 années
 Ce profil doit avoir participé à un minimum de 05 projets similaires
dont deux en tant que directeur de projet.

Chef de projet :

 Formation : BAC +5 ou supérieur

 Expérience : Minimum 10 années
 Ce profil doit avoir participé à un minimum de 05 projets similaires
dont deux en tant que chef de projet.

Architecte fonctionnel métier et solutions autour des domaines Achats,

finance et comptabilité : 1 ressource permanente

 Formation : BAC + 5 ou supérieur

 Expérience : Minimum 8 années dont 05 années en tant qu’architecte
dans le domaine finance et comptabilité et autour de la solution
proposée
 Ayant participé à un minimum de 5 projets similaires.

Consultants fonctionnels seniors (qui auront la charge de mettre en œuvre

les processus arrêtés dans les solutions proposées) : Minimum 2 ressources
permanentes

 Formation : BAC + 5 ou supérieur

 Expérience : Minimum 5 années Ayant participé à un minimum de 3
projets similaires.

Expert technique :

 Formation : BAC +5 ou supérieur

 Expérience : Minimum 10 années dans l’architecture technique et
l’architecture solution autour des progiciels proposés
 Ayant participé à un minimum de 5 projets similaires.
Consultants techniques seniors : Minimum 1 ressources permanente

 Formation : BAC +5 ou supérieur

 Expérience : Minimum 5 années dans le progiciel proposé
 Le consultant technique senior doit avoir participé à un minimum de 3
projets similaires.

Administrateur système et base de données :

 Formation : BAC +5 ou supérieur.

 Expérience : Minimum 10 années.
 Ayant participé à un minimum de 5 projets similaires.

Cette liste est minimaliste, le soumissionnaire doit présenter un dispositif

complet répondant aux exigences du projet.

Un interlocuteur unique doit être désigné par le prestataire pour répondre

aux questions relatives au projet, et notamment :

• Fournir et tenir à jour le planning détaillé des travaux ;

• Participer aux réunions et comités ;

• Contribuer à la production des rapports d’avancement et comptes

rendus de réunions.

I.13 CONDUITE DE CHANGEMENT

La conduite du changement représente un facteur capital pour assurer la
réussite du projet. Le changement suite à l’évolution du système Oracle EBS
doit être maîtrisé et géré comme un processus à part entière. Ce processus
doit aboutir à une réelle appropriation par tous les utilisateurs de la
solution.

Le prestataire est tenu, à cet effet, de mettre en œuvre un plan

d’accompagnement au changement tenant compte des spécificités
suivantes :

Auprès de l’équipe SNTL

En permettant à l’équipe SNTL d’acquérir le savoir-faire nécessaire à la prise

en charge du système après son déploiement en assurant l’exploitation, la
maintenance et l’évolutivité de la solution.
Toutes les installations et les configurations sont à réaliser sur site et en
présence de l’équipe SNTL avec la garantie de transfert de compétence et de
livraison des manuels associés.

Auprès des utilisateurs finaux

En permettant aux utilisateurs finaux de disposer du savoir-faire et de la

compétence adéquate en vue d’une utilisation optimale de la solution selon
le périmètre fonctionnel défini dans le présent marché.

Le prestataire doit entretenir une communication permanente sur le projet

vis-à-vis des différentes parties prenantes (Équipe SNTL, Utilisateurs, autres
parties prenantes).