projet sap edi stg -...

ISATIS CONSULTING

alias

Françoise Richeboeuf, Catherine Bernabé, Mhamed Mamouni, Mohamed Abbassi

RAPPORT DE CADRAGE

PROJET SAP EDI STG

Mastère Spécialisé Chef de Projet ERP 2012/2013 Août 2013

ISATIS

CONSULTING Projet SAP EDI STG Client : STG

Rapport de cadrage EDI STG AIRBUS V3 26/08/2013

Page 1 sur 107 Isatis Consulting

Equipe projet

Françoise Richeboeuf CP Catherine Bernabé CF Mhamed Mamouni CT Mohamed Abbassi CT

Date de lancement : 15/05/2013

Date de livraison : 26/08/2013

RAPPORT DE CADRAGE EDI STG AIRBUS

Destinataires

Jury SAP MSERP12/13

CESI Toulouse

Mickaël Quesnot Intervenant SAP

Nicolas Antini Pilote Mastère

Historique des évolutions

Version Date Auteur(s) Statut

0 - Plan cible 28/07/2013 FRi clos

1 - Assemblage parties 18 – 21/08/2013 FRi ok

2 - Relecture correction 22 – 24/8/2013 Tous ok

3 - Validation 27/08/2013 FRi PDF ok

ISATIS




Table des matières

GLOSSAIRE .............................................................................................................................................................................................. 4

PREAMBULE ............................................................................................................................................................................................ 5

1. RAPPEL DU CONTEXTE ET DES DONNEES DE L’ENTREPRISE ETUDIEE ........................................................................ 6

1.1. LA SOCIETE STG : ......................................................................................................................................................................................... 6

Profil ................................................................................................................................................................................................................................. 6 1.1.1.

Structure ........................................................................................................................................................................................................................ 6 1.1.2.

Schéma de flux de l’entreprise............................................................................................................................................................................. 6 1.1.3.

Système d’information ............................................................................................................................................................................................ 8 1.1.4.

1.2. BESOINS STG ............................................................................................................................................................................................... 8

Enjeux et bénéfices .................................................................................................................................................................................................... 8 1.2.1.

Périmètre ....................................................................................................................................................................................................................... 9 1.2.2.

Séquençage du projet ........................................................................................................................................................................................... 10 1.2.3.

Equipe projet client STG (KU, CPU, CPI) .................................................................................................................................................... 10 1.2.4.

2. ETUDE DE CADRAGE / EQUIPE PROJET................................................................................................................................ 11

2.1. PRESENTATION EQUIPE PROJET ................................................................................................................................................................ 11

2.2. ROLES ET ATTRIBUTIONS .......................................................................................................................................................................... 12

3. ETUDE DE CADRAGE / ANALYSE PREALABLE ET CONCEPTION FONCTIONNELLE ................................................... 13

3.1. ENCHAINEMENT DES PROCESSUS CIBLES SOUS PERIMETRE .................................................................................................................... 13

3.2. STRUCTURE ORGANISATIONNELLES ET MASTER DATA............................................................................................................................ 14

Structure organisationnelle .............................................................................................................................................................................. 14 3.2.1.

Master data................................................................................................................................................................................................................ 15 3.2.2.

3.3. DETAILS DES PROCESSUS STG-AIRBUS ................................................................................................................................................. 24

Considérations générales.................................................................................................................................................................................... 24 3.3.1.

Lot 1 : Commande/Confirmation de commande .................................................................................................................................... 25 3.3.2.

Simulation de la production.............................................................................................................................................................................. 34 3.3.3.

Lot 2 : Bon de livraison / Avis de réception ............................................................................................................................................... 35 3.3.4.

3.4. ETATS ......................................................................................................................................................................................................... 42

Besoin Etats d’activité sous EDI ...................................................................................................................................................................... 42 3.4.1.

Spécifications pour création query pour états ET04 ............................................................................................................................ 43 3.4.2.

4. ETUDE DE CADRAGE / PARAMETRAGE DE LA SOLUTION SAP ...................................................................................... 45

4.1. PRESENTATION GENERALE DU PARAMETRAGE ........................................................................................................................................ 45

4.2. CONNEXION EDI ........................................................................................................................................................................................ 47

Synthèse des paramétrages de la Connexion EDI .................................................................................................................................. 47 4.2.1.

4.3. GENERATION D’IDOC VIA UNE CORRESPONDANCE (GESTION DES MESSAGES) ..................................................................................... 67

Synthèse des paramétrages d’une correspondance (message) ........................................................................................... 67 4.3.1.

ISATIS




4.4. PILOTAGE DES TEXTES ............................................................................................................................................................................. 71

Synthèse des paramétrages du pilotage des textes ............................................................................................................................... 71 4.4.1.

4.5. GESTION DES IDOC REÇUS EN STATUT D’ERREUR (WORKFLOW) ..................................................................................................... 79

Synthèse des paramétrages du Workflow .................................................................................................................................................. 79 4.5.1.

4.6. CONTROLE DU STATUT DE L’IDOC DANS LE SYSTEME EXTERNE ......................................................................................................... 86

Synthèse des paramétrages ............................................................................................................................................................................... 86 4.6.1.

5. TESTS ET JEU D’ESSAI ............................................................................................................................................................... 92

5.1. LES TESTS UNITAIRES ................................................................................................................................................................................ 92

5.2. LES TESTS D’INTEGRATION........................................................................................................................................................................ 94

5.3. LA RECETTE CLIENT ................................................................................................................................................................................... 94

Recette flux achat vente sous EDI - PREREC-01-A ................................................................................................................................. 94 5.3.1.

Recette états d’activité sous EDI - PREREC-02-A ................................................................................................................................... 95 5.3.2.

6. FORMATION ................................................................................................................................................................................. 97

6.1. FORMATION EQUIPE PROJET ..................................................................................................................................................................... 97

6.2. FORMATION CLIENT STG .......................................................................................................................................................................... 98

7. GESTION DE PROJET .................................................................................................................................................................. 99

7.1. METHODOLOGIE ET OUTILS ....................................................................................................................................................................... 99

La méthode ASAP .................................................................................................................................................................................................... 99 7.1.1.

Infrastructures et environnements techniques ..................................................................................................................................... 100 7.1.2.

Outils et supports .................................................................................................................................................................................................. 100 7.1.3.

7.2. PLANNING DE MISE EN OEUVRE .............................................................................................................................................................. 101

7.3. BUDGET .................................................................................................................................................................................................... 101

7.4. GESTION DES RISQUES ............................................................................................................................................................................. 102

8. BILAN ET RETOUR D’EXPERIENCE ..................................................................................................................................... 104

8.1. COMPETENCES ACQUISES ........................................................................................................................................................................ 104

8.2. RETOUR D’EXPERIENCE ........................................................................................................................................................................... 104

8.3. CONCLUSION............................................................................................................................................................................................. 105

ARBORESCENCE DES ANNEXES SUR LE REPERTOIRE « 99 ESPACE JURY »....................................................................... 106

ISATIS




Glossaire

Terme Définition

A400M Avion militaire Airbus. L'armée de l'air française a réceptionné le premier Airbus A400M en Août 2013

Accords

d’intechange

Les accords d’interchange permettent de définir les paramètres de réception et d’émission.

ALE ALE est la technologie middleware fournie par SAP dans R/3 pour intégrer des processus mettant en cause

plusieurs systèmes. Le principe de base est qu’un événement va générer un processus consistant à extraire des

informations de R/3 et à les envoyer à un autre système.

ALEAUD Type de message pour envoyer au système expéditeur les statuts des IDocs reçus par le système récepteur.

ASAP Accelerated SAP : méthode recommandée pour implémenter (ou faire évoluer) SAP efficacement. Structurée

autour d’une Roadmap (5 phases) et mettant à disposition une panoplie d’outils (tools) et de modèles

(accelerators) rassemblée dans un « implementation assistant ».

BADI Il permet au developpeur de creer un user-exit dans le code, d'implémenter un exemple ou un comportement par

défaut de maniere objet et autorise ou non une implémentation cliente.

Central pedestal

ou cabine

pedestal

Partie centrale du cockpit de l'avion militaire A400M. Cest la pièce qui sépare les deux pilotes.

DESADV Type de message Idoc pour une Livraison

Destination RFC La destination RFC (Remote Function Call) définit la communication physique à la destination distante. Les

destinations RFC sont uniquement utilisées pour des communications sortantes de SAP.

EDI Echange de Données Informatisées ou Electronic Data Interchange. Outil au service de l’échange d’informations

consistant à transporter automatiquement des données de l’application informatique d’une entreprise vers

l’application informatique d’une autre entreprise, par des moyens de télécommunication (par exemple internet)

et selon des messages préétablis et normalisés.

IDOC Un IDoc est un document intermédiaire (Intermediate DOCument). C’est un conteneur, utilisé pour échanger des

données entre deux processus.

IMG Contient toutes les fonctionnalités de tous les réglages et paramètrages possibles sur tous les composants de

l'application SAP

Isatis Renard polaire à la fourrure blanche et douce. Il peut résister à des températures de -70 °C. Cet animal très

robuste ne connaît que peu de prédateurs (Wikipedia)

Mandant Un mandant désigne dans la terminologie SAP des unités logiques au sein du système SAP. Ces unités, au contenu

indépendant, contiennent des données propres à chaque mandant (données générales, données de configuration)

et certaines données communes entre mandants (messages d’erreurs par exemple).

Modèle de

Distribution

Un modèle de distribution renferme les spécifications identifiant les messages (type de messages) circulant vers

un système logique. Un modèle de distribution désigne le type de données à échanger.

ORDCHG Type de message pour une modification d’une commande d’achat

ORDERS Type de message Idoc pour une Commande d'Achat

ORDRSP Type de message Idoc pour la Confirmation d'une Commande de Vente

Port Port d'entrée ou de sortie. Cette donnée indique le chemin d'acheminement des IDOC vers le système situé en

aval. C’est le lien de communication entre les deux systèmes logiques.

SPRO SAP Project Reference Object : Il est utilisé pour réaliser des parametrages selon les besoins du client en utilisant

les réglages standards présents dans le système.

STTPOD ARL: Type de message Idoc pour Accusé de Réception d'une Livraison

Système logique Pour chaque mandant SAP utilisé, un système logique de base (LS) doit être associé au client SAP. Chaque

système logique devient l’expéditeur de message sortant et le récepteur de messages entrants.

Type de Message Les types de messages sont utilisés dans un modèle de distribution pour représenter le type de données échangées

en EDI entre deux systèmes SAP.

Type d'Idoc Contient tous les champs standards qui sont nécessaires pour réaliser une transaction commerciale. Par exemple,

ORDERS, DESADV….

ISATIS




Préambule

Welcome on board !

Bienvenue à bord de cet A400M pour le vol N° SAP EDI STG opéré par la compagnie Isatis Consulting.

Ce vol, aller-retour et sans escale, reliera la Société STG de Labège à la Société Airbus de Toulouse-Blagnac grâce

à la technologie de l’EDI. Atterrissage prévu le 30 septembre 2013 à 9h00 environ, heure locale.

The dream crew :

Françoise Richeboeuf Catherine Bernabé Mhamed Mamouni Mohamed Abbassi

Un grand merci à Mickaël Quesnot qui, telle une vigie dans sa tour de contrôle, a su nous aiguiller, même par

temps de brouillard, avec beaucoup de disponibilité et de gentillesse.

Merci aussi à Isabelle de la Société STG qui a pris sur son précieux temps pour nous donner les clés de l’A400M,

prétexte à l’aventure.

Nous vous souhaitons un agréable vol en notre compagnie et restons à votre disposition.

Remarque (sérieuse !) sur le traitement du client Airbus dans le projet :

L’objectif de ce projet étant de faire réellement échanger des données de flux achat/vente entre STG et son

client Airbus, nous avons dû nous appuyer sur un client Airbus bien réel. Pour ce faire, nous avons utilisé un

2ème mandant dans lequel nous avons paramétré (comme pour STG) une structure Airbus, des données de

base, des flux et des paramétrages EDI. Pour toutes ces données Airbus, faute d’information, nous avons fait le

choix de reproduire les éléments STG (sauf exception) ou tout au moins ceux qui en découlent logiquement.

ISATIS




1. Rappel du contexte et des données de l’entreprise étudiée

1.1. La société STG :

Profil 1.1.1.

STG est une jeune PME de l’agglomération toulousaine, créée en 2004 et toujours dirigée par son créateur. Elle

réalise un chiffre d’affaire de 10 millions € et emploie une centaine de personnes. Cette entreprise a toujours

connue une croissance soutenue et affiche de belles perspectives, portée par la dynamique du marché

aéronautique et aérospatial (90% de son activité).

Fournisseur de rang 1 de clients comme Airbus et contrainte de répondre aux contraintes et exigences de son

environnement, STG s’est bâti sur une solide culture qualité, recherche, innovation et service client.

Structure 1.1.2.

Au gré de sa croissance et de son ouverture vers de nouvelles activités, STG s’est structurée en une holding

possédant trois filiales :

Les trois fliliales du groupe STG interviennent de façon coordonnée et complémentaire afin de proposer une

offre de sous-traitance globale ou partielle pour tout type de projet portant sur des pièces composites pour

l’industrie.

Schéma de flux 1.1.3. de l’entreprise

ISATIS




Pour avoir une vision globale du fonctionnement de STG, nous reprenons ci-dessous le schéma des flux,

élaboré par l’entreprise STG.

Les informations clés à extraire de ce tableau sont :

- Les 3 entités sont entièrement lissées dans l’activité quotidienne

- STG vend à des clients des pièces spécifiques à un client

- Celles-ci sont soit fabriquées par STG à partir de composants et matières premières achetés, soit sous-

traitées partiellement

- La fabrication de produits finis est déclenchée par une commande client. STG ne possède pas de stock

de produits finis.

ISATIS




Système d’information 1.1.4.

Toutes les données et tous les processus des 4 entités sont gérés via un ERP transversal. En effet, l’entreprise

vient d’intégrer une solution SAP R/3 sur un périmètre équivalent à SD, PP et MM, la partie finance et RH

restant gérée par SAGE. Les 2 solutions sont interfacées.

1.2. Besoins STG

Suite à la demande de son principal client Airbus, STG a missionné Isatis Consulting pour la mise en place d’un

Echange de Données Informatisées (EDI) sur la fonction vente. L’échange des données se fera en temps réel et

sans passer par un hub prestataire.

Enjeux et bénéfices 1.2.1.

La capacité à communiquer en EDI est une nécessité pour les entreprises qui veulent rester des fournisseurs

de rang 1 dans le secteur aéronautique. Tel est le cas de STG qui doit se soumettre rapidement aux exigences

de son client Airbus. STG pressent que d’autres clients comparables, à date au nombre de 2, formuleront la

même exigence sous peu. STG souhaite être proactif à leur égard. Ces 3 clients pèsent près de 50% du chiffre

d’affaire de l’activité production de STG

Pour cette évolution majeure, à mettre certes à l’initiative d’un client, comme c’est souvent le cas dans les

PME, STG s’inscrit dans une démarche tout à fait positive, consciente des enjeux immédiats et des bénéfices

internes à court et moyen terme.

ISATIS




Périmètre 1.2.2.

L’objectif donné à Isatis est de passer sous EDI direct dans SAP l’échange des données achat/vente entre STG

et Airbus, et à terme d’autres de ses clients.

Le schéma de flux ci-dessous fait ressortir les 4 grands processus de vente existant chez STG, (et qui ont leur

pendant côté client.)

1. La réponse à la demande d’offre du client : création d’un devis ou proposition

2. Le traitement de la commande client et notamment sa confirmation

3. La livraison de la marchandise

4. La facturation

L’EDI est à mettre en place sur ses 4 processus. 1 processus = 1 lot

Sous-traitantClient STG Fournisseur

Demande: Devis ou contrat cadre

Offre: devis ou contrat cadre

Commande ou plan d’approvisionnement

Commande confirmée

Facture

CommandeMatière première

CommandeSous-traitance

Bon de livraison

Avis de réception

Etudier demande

Produire

Lvrer

Facturer

Accepter commande proposée

Sous-traiter

Acheter matière

Modifier commande

Oui

Non

Oui

Non

Oui

Confirmer commande

Non

3

4

1

2

ISATIS




Séquençage du projet 1.2.3.

STG a souhaité mettre en place l’EDI sur ces processus et clients par étapes selon le planning ci-dessous :

1ère étape : Mise en place du flux EDI avec AIRBUS

- Lots 1 & 2 : Livraison septembre 2013

- Flux réception de commande standard client /confirmation de commande

- Flux avis d’expédition / bon de livraison / accusé de réception de livraison

- Lots 3 & 4 : Livraison janvier 2014

- Flux demande/offre

- Flux programme de livraison et appel

- Flux facture

2ième étape : Extension de l’EDI vers les autres clients (à date 2 candidats)

- Livraison Mars 2014.

Equipe projet client STG (KU, CPU, CPI) 1.2.4.

- Isabelle, Responsable Logistique et Qualité, chef de projet utilisateur

- Lionel, Directeur Administratif et Financier, chef de projet informatique

- Raymond, Resp Entrepôt, KU

- Corinne, Collaboratrice ADV, KU

ISATIS




2. Etude de cadrage / Equipe projet

2.1. Présentation équipe projet

L’équipe projet Isatis est constituée de 4 personnes :

- Francoise Richeboeuf (FRI) : Chef de Projet

- Catherine Bernabé (CBE) : Consultant fonctionnelle

- Mhamed Mamouni (MMI) : Consultant technique, interface client STG

- Mohamed Abbassi (ABM) : Consultant technique

Une équipe composée de profils complémentaires tant sur le plan du cursus que des apports sur les

projets qui leur sont confiés.

Une équipe certes junior sur SAP mais qui compense par une capacité d’autoformation

(communicative !) et une implication difficile à contenir.

Topic Françoise Richeboeuf Catherine Bernabé Mhamed Mamouni Mohamed Abbassi

Cursus -Ecole Supéreure de

Commerce de Pau

-Mastère spécialisé Chef

de Projet ERP

- Ecole Supérieure de

commerce de Paris

- Master II Audit Contrôle

de Gestion

- Mastère spécialisé Chef

de projet ERP

- Ecole Supérieure des

Technologies Industrielles

Avancées

- Master II Systèmes de

production industriels

automatisés


de projet ERP

- Master Mathématiques &

Informatique Graphique

- Master Statistique et

Econométrie


de Projet ERP

Expériences /

compétences

- 18 ans d'expérience en

PME dans des fonctions

marketing, commercial,

ADV, logistique

- Mise en place des

modules achat/vente de 2

ERP typés PME

- 10 ans d'expérience en

contrôle de gestion

- Analyse, modélisation et

amélioration de processus

- Assistante de projet mise

en place d'un outil BI

- 8 ans d'expérience :

Responsable de

production

- Mise en place d'un Erp :

Achat, vente et

production.

- 4 ans de recherche,

développement et analyse

économétrique

- Compétences et

expériences dans l'analyse

et le developpement: R,

SAS, Microsoft .NET,

BI/BW

Compétences

SAP

- 6 mois de pratique

fonctionnelle sur MM et

SD

- 6 mois de pratique

fonctionnelle et

paramétrages standards

sur MM et SD

- 1 an de pratique

fonctionnelle sur SD et

MM

- Attestation de

préparation à la

certification SD MM

- Paramétrage SAP SCM

- Paramétrage PP

- Connaissance WM et PS

- 6 mois de pratique sur

MM, SD et paramétrage

EDI

Apport sur le

projet

-Recul fonctionnel sur les

problématiques du projet

-Pilotage du projet

- Analyse et conception

fonctionnelle

- Paramétrages standards

- Paramétrages avancés

SD MM

- Paramétrages EDI SD-

MM

- Analyse fonctionnelle

-Paramétrages EDI SD-

MM

-Paramétrages SAP

standards et évolués

ISATIS




2.2. Rôles et attributions

Du fait des profils complémentaires, le positionnement de chacun sur le projet s’est fait de manière assez

naturelle. On peut le schématiser ainsi : un cœur de fonction doublé d’une capacité à intervenir sur le projet

avec un spectre plus large.

Au-delà de ces fonctions cœur et compte tenu du projet et de la taille de l’équipe, chaque membre a fait

preuve de polyvalence. Ainsi, certaines tâches clés sont pilotées par un porteur (pilote), associé à un binôme

(voire 2).

Ce principe de binôme offre 2 autres vertus :

- Il permet de maintenir pour chacun, une charge de travail constante et équitable tout au long du

projet

- Il permet de décupler les connaissances et compétences par un effet de rebond sur les apports de

l’équipier (et réciproquement)

- Il limite l’impact d’éventuelles défaillances humaines ou baisses de régime sur un projet.

Porteur

Binôme FRI CBE MMI ABM

F Richeboeuf Pilotage projet X

Livrables & soutenance X X X

Plans de formation X

C Bernabé Synthèse Entretien X X

Concept° fonctionnelle X X

Tests X X X

M Mamouni Interface client, atelier X

Conception technique X X

Paramétrage X X

M Abbassi Formation équipe EDI X X

Paramétrage EDI X

ISATIS




3. Etude de cadrage / Analyse préalable et conception fonctionnelle

L’objectif de ce paragraphe est double. Il doit permettre :

- D’une part, de décrire l’impact de la mise en place des flux EDI sur les processus STG, aussi bien d’un

point de vue fonctionnel qu’en ce qui concerne la gestion de ces processus dans l’ERP ;

- D’autre part, de proposer une mise en adéquation des besoins* d’STG dans SAP non seulement par

rapport à la problématique de l’EDI mais également par rapport aux spécificités fonctionnelles de

l’activité d’STG. (* Les besoins d’STG sont exprimés dans la synthèse des entretiens de recueil des

besoins et affinés lors des ateliers utilisateurs. Cf annexe)

Les processus et les données existants sont considérés comme en adéquation avec les besoins de STG d’un

point de vue fonctionnel : ils ne seront modifiés que si la mise en place d’un flux EDI l’impose.

NB : du fait qu’un flux EDI n’a de sens qu’entre deux systèmes, nous décrirons les processus existants aussi

bien chez Airbus (le client, mandant 150) que chez STG (le fournisseur, mandant 731)

3.1. Enchainement des processus cibles sous périmètre

Afin de faciliter les échanges avec ses fournisseurs et établir des relations plus efficaces avec un nombre

restreint d’entre eux, la société Airbus souhaite gérer sa relation commerciale avec son fournisseur STG via

EDI.

Les différents processus des partenaires de la relation commerciale vont donc s’articuler de la façon suivante :

1. Airbus souhaite envoyer ses commandes d’achat à STG via EDI : elles seront donc créées et

enregistrées dans le système de STG en temps réel.

2. STG souhaite pouvoir les confirmer à Airbus immédiatement de manière électronique (la

confirmation sera donc enregistrée en temps réel dans le système d’Airbus)

3. STG doit envoyer à son client, toujours via EDI, un avis de livraison dès lors que la marchandise est

expédiée.

4. Airbus trouvera la confirmation de la livraison dans la commande d’achat concernée, et une livraison

entrante aura été créée automatiquement lors de la réception par EDI de l’avis de livraison émis par

STG.

5. Enfin, dès qu’il aura réceptionné la marchandise, Airbus transmettra via EDI un accusé de réception

de livraison qui déclenchera chez STG le processus de facturation.

La mise en place d’un flux EDI, s’il a des impacts aussi bien en termes de processus métiers

qu’organisationnels, ne doit pas remettre en cause le fonctionnement de fond de la relation commerciale entre

STG et son client.

De la même façon, en ce qui concerne la solution SAP, il s’agit d’un processus « technique » qui ne doit pas en

bouleverser l’utilisation ou la logique, que ce soit en termes de master data ou de flux de gestion.

ISATIS




3.2. Structure organisationnelles et master data

Structure organisationnelle 3.2.1.

Comme nous l’avons précisé dans le paragraphe 1 .1.2.1 Structure, malgré la présence de quatre entités

légales, les différentes structures fonctionnent comme les différents services d’une entité unique.

Nous avons donc fait le choix, par souci de simplification, mais également car cela n’avait aucun intérêt

particulier pour la mise en place d’un flux EDI (ce qui reste le cœur de notre intervention), de ne créer qu’une

seule structure au sein du système SAP.

Nous avons donc créé une structure organisationnelle simple où chaque élément organisationnel devant être

créée dans SAP l’a été en un exemplaire unique. Si dans le futur les exigences d’STG devaient requérir la

création d’autres structures, il suffirait de dupliquer les éléments nécessaires selon la même la logique que

celle que nous avons suivie et qui est présentée dans les schémas ci-après.

La structure organisationnelle créée dans les deux mandants est identique aussi bien dans la conception que

dans la codification. Les codes ne diffèrent que par la première lettre qui est Z pour STG et Y pour Airbus.

3.2.1.1. La société STG, mandant 731

ISATIS




3.2.1.2. La société AIRBUS, mandant 150

Master data 3.2.2.

On peut distinguer deux types de Master data (données statiques, données de base) : celles qui interviennent

dans le flux fonctionnel en tant que telles (article, client, fournisseur, …), et les données statiques de base ,

(enregistrées dans des tables spécifiques), nécessaires pour renseigner les premières (la devise, la forme

juridique, le groupe de marchandises, …).

Nous ne nous occuperons ici que des données intervenant dans le flux (les données de base sont pour la

plupart déjà renseignées en standard ; dans le cas contraire, il suffit d’ajouter la donnée nécessaire dans les

tables).

Les données statiques impliquées dans le flux achat –vente sont au nombre de 5.

Sur le mandant 731, celui du fournisseur, nous trouverons :

- L’article

- Le client

- La fiche client - article

Sur le mandant 150, celui du client, il y aura :

- L’article

- Le fournisseur

ISATIS




- La fiche info – achat.

En ce qui concerne les données qui doivent être renseignées dans SAP, nous sommes partis des indications et

documents qui nous ont été fournis lors des ateliers de recueil des besoins, et nous avons identifié dans SAP

les champs à utiliser pour les renseigner ; ceci a été fait dans les 2 mandants.

3.2.2.1. Système STG, mandant 731

3.2.2.1.1. L’article

Les données concernant l’article qu’STG souhaite renseigner dans le système d’information sont toutes

transposables en standard dans SAP. Nous reportons ci-après les champs identifiés comme correspondants

aux données cible.

Afin de regrouper selon le souhait d’STG les articles qu’il fabrique, nous avons prévu de créer un groupe de

marchandise (ZCOM) et un groupe de marchandises externes (ZA400M) spécifiques.

Enfin, deux champs méritent une mention particulière car ils répondent à une spécificité de l’activité d’STG : le

profil numéro de série et la gestion par lot. Ceux-ci doivent être transmis au client par EDI dans le bon de

livraison.

Le lot correspond à un lot de fabrication qu’STG attribue aux pièces qu’il fabrique par souci de traçabilité. De

plus, toujours pour les mêmes raisons, STG attribue un numéro de série à chaque pièce produite.

Le profil de numéro de série choisi signifie que pour tout mouvement de stock est requis le numéro de série

des articles mouvementés.

Cible STG Référent S.A.P. Couverture

Do

nn

ées

On

glet

fic

he

arti

cle

Ch

amp

s

*:

don

née

s sp

écif

iqu

es S

TG

à

ajo

ute

r d

an

s u

ne

tab

le

Ob

liga

toir

e F

acu

ltat

if

Au

tom

ati

qu

e

Val

eur

du

ch

amp

Stan

dar

d

No

n S

tan

dar

d

Rq

Ecran initial Branche O

Aerospatial & Espace

Ecran initial Type article O Produit commercialisable

Code article DdeB1 Article O Manuelle S

Désignation article DdeB1 Désignation O Manuelle S

Unité de mesure DdeB1 Unité de quantité de base* O PC Pièce S

Poids brut DdeB1 Poids brut F S

Poids net DdeB1 Poids net F S

DdeB1 Groupe de marchandise * F ZCOM S

Programme DdeB1 Groupe de march externe* F ZA400M S

DdeB1 Unité de poids* O KG S

DdeB1 Gpe GénTypPoste O NORM (défaut) S

DdeB1 Secteur d'activité F S

ISATIS




DdeB2 Vue non gérée. Hors périmètre S

Classification Vue non gérée. Hors périmètre S

Org. Comm 1 Données taxes O 1 S

Org. Comm 2

Valeur par défaut si existantes S

Données Gén/Div GpeTransp O 0001

Données Gén/Div Gpe.charg. O 0003

Données Gén/Div Profil Num de série F

003: Gestion des stocks S

Comm. Ext (Imp/Exp) Vue non gérée. Hors périmètre S

Programme Texte ADV Description F S

Achats Vue non gérée. Hors périmètre S

Texte commande d'achat

Vue non gérée. Hors périmètre S

Planif des besoins 1 a 4


Previsions Vue non gérée. Hors périmètre S

Stock 1 Gestion par lot F X S

Stock 2


Emplac. Mag 1 -2


Manag. Qualité Vue non gérée. Hors périmètre S

Comptabilité 1 Code Prix O S (Standard) S

Comptabilité 1 Prix Standard O

S

Comptabilité 2


CCR 1 -2 Vue non gérée. Hors périmètre S

3.2.2.1.2. Le client

Comme pour l’article, toutes les données qu’STG souhaite renseigner sont disponibles en standard dans SAP.

Afin d’avoir une correspondance parfaite, nous avons simplement prévu de:

- créer un groupe de compte donneur d’ordre qui accepte une codification alphanumérique afin que

STG puisse transposer sa codification dans SAP (ZDO)

- paramétrer un nouveau type de forme juridique inexistant dans les tables de base existantes (« s.a.s. »

pour « Société par Actions Simplifiée » qui est la forme juridique d’Airbus)

- paramétrer un code branche qui corresponde à la classification selon laquelle STG souhaite pouvoir

regrouper ses clients, en l’occurrence la classification APE,

- Paramétrer une branche d’activité de la classification APE afin qu’il puisse y rattacher son client.

Deux données importantes la fiche client pour gérer l’accusé de réception de livraison via EDI :

La première, « Significatif pour ARL », est une case à cocher qui indique que la réception de l’accusé de

réception de la livraison est attendue et qu’elle déclenche la facturation automatique, la deuxième « Intervalle

ISATIS




ARL » est le nombre de jours accordés au client pour accuser réception de la livraison : passé ce délai, les

livraisons sortantes sont considérées comme réceptionnées par le client et par conséquence automatiquement

facturées. (Cette deuxième donnée étant ici hors périmètre, elle n’est pas renseignée.)


Do

nn

ées

Vu

e f

ich

e C

Lie

nt

O

ngl

et

Ch

amp

s

*:

don

née

s sp

écif

iqu

es S

TG

à

ajo

ute

r d

ans

un

e ta

ble

Ob

liga

toir

e F

acu

ltat

if

Au

tom

ati

qu

e

Val

eur

du

ch

amp

Stan

dar

d

No

n S

tan

dar

d

Rq

Ecran intial Groupe de comptes

O ZDO Donneur d'ordre STG

S

Ecran intial Client O libre S Ecran intial Société F ZSTG S Ecran intial Organisation

commerciale F ZOC1 S

Ecran intial Canal distribution F Z1 S Ecran intial Secteur d'activité F Z2 S Données

exportation S

Données Générales

adresse Titre de civilité F Entreprise S

Raison sociale


adresse Raison sociale O S

Forme juridique


Marketing *Forme juridique F S


adresse Critère de recherche

O STG S

Adresse complète


adresse Groupe "Adresse postale"

O S

Tel: Données Générales

adresse Tel F S

Fax Données Générales

adresse Fax F S

Site web Données Générales

Adresse - Autre communication - URI

adresse site web F S


adresse Pays O FR S


adresse Région O Département du client

S


adresse Zone de transport O Région du client S

N° Siret Données Générales

Données de pilotage

N° SIRET F S



TVA sur CA F cocher S

Code APE Données Générales


*Branche F AIR S

Code APE Données Générales

Marketing *Code Branche 1 F APE S

ISATIS




CONTACTS Données Générales

S

Nom Contact Données Générales

Contact Nom Contact F S


Contact Prénom Contact F S

Fonction contact


Contact Fonction contact F S


Contact Tel: F S


Contact - adresse privée

Fax F S

E-mail Données Générales


E-mail F S

Nom autre contact


Contact Nom autre contact

F S

Fonction autre contact


Contact Fonction autre contact

F S


Contact Tel: F S



Fax F S

E-mail Données Générales


E-mail F S

LIVRAISON/FACTURATION

S

Données dom. Comm.

Expédition Cdtion Expédition O 02 Standard S

Données dom. Comm.

Expédition Divsion F ZDV1 S

Données dom. Comm.

Expédition Significatif pour ARL

F X S

Données dom. Comm.

Expédition Intervalle ARL F S

Données dom. Comm.

Vente Agence Commerciale

F ZAC1 S

Données dom. Comm.

Vente Groupe vendeur F ZGV S

DONNEES REGLEMENT

Données Société

Tenue de compte

Groupe collectif O 411100 S

Données Société

Opér. De paiement

Coordonnées bancaires, autor prélèvement

F S

Condtions de livraison (incoterms)

Données dom. Comm.

Facture Incoterms F EXW S

Données dom. Comm.

Facture Lieu Incoterm F Labège S

Conditions de paiement

Données dom. Comm.

Facture Condition Paiement

F 001 S

Données dom. Facture Classification O 1 Imposable S

ISATIS




Comm. taxes

Données dom. Comm.

Rôles partenaires

DO: Donneur d'ordre

O STG-AIRBUS S

Adresse de facturation

Données dom. Comm.

Rôles partenaires

CF: Client facturé O STG-AIRBUS S

Données dom. Comm.

Rôles partenaires

PY: Client Payeur O STG-AIRBUS S

Adresse de livraison

Données dom. Comm.

Rôles partenaires

CL: Client livré O YDV1 S

3.2.2.1.3. La fiche client-article

STG n’a exprimé aucun besoin particulier qui viendrait se répercuter sur la fiche client-article : elle sera donc

utilisée de façon standard.

Une donnée est importante pour le flux EDI, « Article client » : ce champ renseigne la codification de l’article

STG objet de la fiche client-article dans le système du client. C’est grâce à ce champ que l’on pourra faire

correspondre dans le système d’STG le bon article STG à celui commandé par Airbus et transmis par EDI.

Cible STG Référent S.A.P.

Do

nn

ées

Vu

e f

ich

e C

lien

t ar

ticl

e

Ch

amp

s

*:

don

née

s sp

écif

iqu

es

STG

à

ajo

ute

r

da

ns

un

e ta

ble

Ob

liga

toir

e F

acu

ltat

if

Au

tom

atiq

ue

Val

eur

du

ch

amp

Client O Organ Comm O ZOC1 Canal distr O Z1 Code article Synthèse Numéro article O Désignation

article Synthèse Désignation A

Code Client Synthèse Article client O Désignation

Client Détail Info Désignation art client F Désignation

Client Détail Info Division F ZDV1 Désignation

Client Détail Info Critère de recherche F

3.2.2.2. Système AIRBUS, mandant 150

3.2.2.2.1. L’article

Les données concernant l’article sont identiques à celles du mandant 731 (en particulier la gestion par lot et

numéro de série), à une exception près.

Dans le système du client, la vue « Achats » est gérée, alors qu’elle ne l’est pas dans le système du fournisseur

(car le fournisseur n’achètera jamais ce produit à son client).

On relève une spécificité : l’article doit être enregistré en stock qualité lors de l’entrée de marchandise car il

est soumis à un contrôle qualité libératoire pour le fournisseur : il ne sera transféré en stock à utilisation libre

qu’après avoir passé ce contrôle qualité.

Nous ne reportons ci-après que les informations renseignées dans la vue achat.

ISATIS




Référent S.A.P. Couverture

Vu

e O

ngl

et

fich

e ar

ticl

e

Ch

amp

s

*:

don

née

s sp

écif

iqu

es S

TG

à

ajo

ute

r d

ans

un

e ta

ble

Ob

liga

toir

e F

acu

ltat

if

Au

tom

ati

qu

e

Val

eur

du

ch

amp

Stan

dar

d

No

n S

tan

dar

d

Rq

Achats Groupe d'achteur O YGA S S Achats Enr. Dans stock qualité F X S S

3.2.2.2.2. Le fournisseur

Aucun des besoins exprimés ne reste sans correspondance en standard.

On notera le désir de connaître l’appartenance de ses fournisseurs à une branche d’activité comme STG le fait

pour ses clients : le code branche correspondra donc à la classification APE souhaitée et le code utilisé (AIR)

sera paramétré ad hoc puisqu’il n’existe pas par défaut.


Do

nn

ées

Ecr

an f

ich

e F

ou

rnis

seu

r

N

om

Ecr

an

Ch

amp

s

*:

don

née

s sp

écif

iqu

es S

TG

à

ajo

ute

r d

ans

un

e ta

ble

Ob

liga

toir

e F

acu

ltat

if

Au

tom

atiq

ue

Val

eur

du

ch

amp

Stan

dar

d

No

n S

tan

dar

d

Rq

Fournisseur 0 Ecran de sélection

Numero O S

0 Ecran de sélection

Groupe de compte O 0001 (Fournisseurs)

S


Société F S


Organisation d'achat F S

DONNEES ADMINISTRATIVES

1 Adresse Titre de civilité F Entreprise S Raison sociale 1 adresse Nom O S 1 adresse Critère de recherche O STG S Adresse complète 1 adresse Groupe "Adresse

postale" O S

Tel: 1 adresse Tel F S Fax 1 adresse Fax F S N° Siret 2 Pilotage N° SIRET F S 2 Pilotage TVA sur CA F cocher S Code APE 2 Pilotage Branche F AIR S N° TVA intracomm. 2 Pilotage N. Ident TVA F S 4 Comptabilité Gpe prév trésorerie O A1 (Fourn

national) S

4 Comptabilité cpte collectif O 160000 (dettes fourn domest)

S

CONTACTS S Nom Contact 6 Données achat Vendeur/vendeuse F S

ISATIS




Fonction contact S Tel: 6 Données achat Tel: F S LIVRAISON/FACTURATION

S

Condtions de livraison (incoterms)

6 Données achat Incoterms F S

DONNEES REGLEMENT

S

Mode de paiement 5 Opér paiement/compta

Modes paiement F S

Conditions de paiement

5 Opér paiement/compta

Condition Paiement F S

3 Opér. De paiement (1)

Coordonnées bancaires, autor prélèvement

F S

6 Données achat Devise de la commande

O EUR S

DONNEES TECHNIQUES

S

Agrément qualité 2 Pilotage Système QM réel F S 2 Pilotage Système QM jusqu'à F S 7 Rôles

partenaires Rôle O S

7 Rôles partenaires

Numéro O S

3.2.2.2.3. La fiche info – achat

La fiche info-achat telle qu’elle est prévue en standard répond parfaitement au besoin d’STG en la matière.

Une donnée est importante pour le flux EDI, « No article fournisseur » : elle renseigne comment est codifié

dans le système du fournisseur l’article Airbus objet de la fiche info achat. Elle est le pendant du champ

« Article client » de la fiche client- article.

Deux autres champs revêtent également leur importance pour le flux EDI : la case à cocher « ConfOblig » qui

rend obligatoire la confirmation de la commande d’achat par le fournisseur et le « CodConf », à savoir le code

de confirmation obligatoire, qui indique quel(s) type(s) de confirmation est (sont) demandés (confirmation

commande et/ou confirmation livraison).

Au vu des exigences d’Airbus, qui demande une confirmation de la commande et une confirmation de la

livraison (les informations transmises par EDI à ce propos iront alimenter les données renseignées dans la

commande d’achat), nous avons prévu de paramétrer un code de confirmation spécifique (ZRSP) qui rend

obligatoire ces deux confirmations.

ISATIS




Référent S.A.P. Couverture

Do

nn

ées

Vu

e f

ich

e in

fo -

ach

at

Ch

amp

s

*:

don

née

s sp

écif

iqu

es S

TG

à

ajo

ute

r d

ans

un

e ta

ble

Ob

liga

toir

e F

acu

ltat

if

Au

tom

ati

qu

e

Val

eur

du

ch

amp

Fournisseur O Code article Article O Organ Achat F Division F

type fiche info achat O Standard Désignation article A

Code fournisseur No Article fournisseur F Désignation fournisseur F Données générales unité d'achat O Données générales Conversion O Données générales Conversion O Données organ achats 1 Delai liv prévu O Données organ achats 1 Groupe d'acheteurs O Données organ achats 1 Qté standard O Prix d'achat Données organ achats 1 Prix Net O Données organ achats 1 Qté Prix net O Données organ achats 1 Conv Qté O Données organ achats 1 Conv Qté O Données organ achats 1 ConfOblig. F coché Données organ achats 1 PilConf F ZRSP Données organ achats 2 défaut Conditions défaut

ISATIS




3.3. Détails des processus STG-AIRBUS

La condition sine qua non de la mise en place d’un flux EDI est bien sûr l’existence d’une connexion entre les

systèmes des partenaires.

Nous ne traiterons pas sa mise en place de façon détaillée dans ce paragraphe car il s’agit de paramétrages

techniques, en marge de l’aspect fonctionnel dont nous nous occupons ici.

Deux choses sont importantes d’un point de vue fonctionnel :

1. le client souhaite que la transmission des messages EDI se soit JAMAIS effectuée automatiquement

lors de la sauvegarde des différents documents crées ou modifiées dans SAP, mais qu’elle résulte

TOUJOURS d’une action manuelle, fruit d’une décision prise par l’utilisateur.

Il est impératif en effet de toujours tenir sous contrôle les échanges de données avec le partenaire et

de ne pas se laisser piloter, voire entraîner, par le système.

2. En parallèle de la mise en place du flux EDI, l’édition des différents documents en version PDF ou

papier est également prévue pour tous les processus afin de gérer la relation commerciale avec les

clients non connectés par EDI. D’ailleurs, ceci permettrait de continuer à fonctionner, en mode

dégradé, avec Airbus, dans le cas où l’EDI serait défaillant.

CREATION D'UNE CONNEXION EDI ENTRE LES MANDANTS 150 ET 731

Activité/Règles de gestion

Sta

nd

ard

A

da

pta

tio

n

Fonctionalité SAP Paramétrage

Cette connexion est un prérequis pour pouvoir échanger les données entre les deux systèmes

S

- Paramétrage global et spécifique dans les deux mandants. - Paramétrages applicatifs dans le mandant du fournisseur (table de correspondance, type de document de vente à générer…)

- Création des systèmes logiques - Création du modèle de distribution - Création des accords d'interchange entre les systèmes logiques - Création des partenaires (client et fournisseur) - Création des accords d'interchange entre les deux partenaires

Considérations générales 3.3.1.

Comme nous l’avons précisé en introduction, la mise en place d’un flux EDI ne doit venir bouleverser ni la

relation commerciale entre STG et son client, ni l’utilisation de son outil de gestion, SAP.

En particulier, la mise en place d’un flux EDI ne signifie pas que les contacts fréquents entre les partenaires

disparaîtront. Au contraire, toute modification des données dans l’ERP (date de livraison par exemple) fera

l’objet d’un accord téléphonique préalable que le flux EDI ne fera qu’entériner.

ISATIS




Cependant, même si aucune des tâches faisant partie du processus de négociation n’est impactée en tant que

telle, il n’en demeure pas moins que certaines tâches, en particulier certaines tâches de support effectués

aujourd’hui par l’ADV, vont évoluer, voire disparaître.

Les schémas suivant mettent en évidence les impacts métiers de la mise en place de l’EDI; les impacts

organisationnels en découlent.

Nous reportons ci-après les processus d’STG tels qu’ils nous ont été décrits en mettant en évidence l’impact de

de la mise en place de l’EDI de la façon suivante :

Tâches qui disparaissent

Tâches qui ne disparaissent pas mais sont effectuées différemment

Nouvel enchaînement des tâches

Tâche effectuée automatiquement par le flux EDI

Nouvelle tâche à effectuer du fait de la mise en place du flux EDI

Tâches effectuées automatiquement par EDI, mais HORS PERIMETRE (ces tâches sont

indiquées à titre d’information seulement)

Lot 1 : Commande/Confirmation de commande 3.3.2.

Ce lot comprend les processus suivants :

- Emission de commande d’achat/ réception de commande d’achat / Création de commande de vente /

confirmation de commande de vente (en l’état ou après l’avoir modifiée) / confirmation de

commande d’achat

- Emission de commande d’achat modifiée / réception de commande d’achat modifiée /modification et

confirmation de commande de vente modifiée en l’état / confirmation de commande d’achat modifiée.

Ces deux flux sont traités simultanément car d’un point de vue fonctionnel par rapport aux flux de

données ils sont identiques même si le type de support EDI est différent.

Le flux décrit est un flux de passation et de confirmation de commande classique: on ne relève aucune

spécificité particulière dans le flux lui-même.

Il existe par contre quelques spécificités liées au type de données échangées, comme les numéros de lots, que

nous expliciterons dans le paragraphe 3.3.2.2. car elles nécessitent un traitement particulier pour les inclure

dans le flux EDI.

3.3.2.1. Impact de la mise en place de l’EDI sur le processus

Le schéma suivant met en évidence les évolutions de tâches découlant de la mise en place des flux EDI.

tâche

tâche

tâche

ISATIS




Commande/Confirmation de commande

STG – Administration des ventesClient – Service achat STG – Responsable logistique

Ph

ase

Créer la commande d’achat dans l’ERP

Transmettre la commande pdf par mail

Contrôler la faisabilité de la commande

Accepter la commande

Créer la commande de vente dans l’ERP

Renégocier les éléments de la commande

Mail Commande d’achat

Trouver un accord

Annuler la commande dans l’ERP

Valider la commande dans l’ERP

Transmettre la confirmation de commande pdf par mail

Mail confirmation de commande

Non

Non

Modifier la commande dans l’ERP

Oui

Confirmer la commande dans le système

Transmettre la commande modifiée pdf par mail

Editer la commande

Annuler la commande dans l’ERP

Non


Oui

Editer la commande modifiée

Mail d’alerte dans l’ERP

Mail d’alerte de validation de commande modifiée dans l’ERP

Contrôler la cohérence des données

Oui

Mail d’alerte de validation de commande dans l’ERP

Mail commande modifiée

Editer la confirmation de commande

Contrôler la cohérence des données

Valider la commande modifiée dans l’ERP

Il ressort clairement que :

1. Côté fournisseur (pour nous mandant 731, STG)

- les tâches liées la création de la commande ou à sa modification et celles concernant l’envoi de la

confirmation au client ont disparu car elles sont effectuées automatiquement par le flux EDI ;

Générer la commande dans

l’ERP d’STG


d’STG

Générer la confirmation de commande dans l’ERP du client

Contrôler les éléments de la commande qui ont été confirmés

ISATIS




- la confirmation de commande doit générer un flux EDI afin qu’elle soit répercutée dans le système du

client.

2. Côté client (pour nous mandant 150, AIRBUS)

- la création ou la modification de commande doit générer un flux EDI afin qu’elle soit renseignée dans

le système du fournisseur

- La confirmation de la commande de la part du fournisseur ne doit plus être renseignée car elle est

générée automatiquement par le flux EDI

3.3.2.2. Solution proposée dans SAP

La solution proposée a été conçue dans le but de mettre en place un flux EDI qui tienne compte des spécificités

de l’activité d’STG. Dans cette optique :

1. Airbus demande que le numéro de lot* qu’il affectera à la pièce qu’il commande suive la pièce fabriquée

par STG, car les caractéristiques peuvent varier d’une pièce à l’autre, s’agissant souvent de pièces

configurables en fonction des options choisies par les compagnies aériennes.

Il est donc impératif que ce numéro de lot soit transmis à STG dans la commande d’achat au niveau poste.

Or les types messages EDI standards liés aux commandes d’achat (messages de type ORDERS basé sur le

type de base ORDERS05) ne transmettent pas le numéro de lot.

Dans l’attente de pouvoir modifier un type de message existant pour y intégrer un segment transportant

le numéro de lot ou en créer un ex novo (développement nécessaire), nous avons donc décidé, de

commun accord avec le client, d’utiliser de façon détournée un champ de type texte (donc sans

contraintes quant au contenu) de niveau poste (chaque article a un numéro de lot qui lui est propre) qui

soit transporté en standard dans le type de message ORDERS : le champ incoterms 2 qui devrait accueillir

normalement le lieu auquel se réfère l’incorterms répond à ces caractéristiques et sera utilisé dans ce

sens.

Cette même problématique se pose au niveau des modifications de commande que pourrait faire AIRBUS,

car le type de message EDI correspondant (ORDCHG) est basé sur le même type de base (ORDERS05) que

le type de message ORDERS. Elle sera résolue de la même façon.

(*Le numéro de lot est la concaténation du « programme » (soit le type d’avion) et du numéro d’avion

(numéro progressif de fabrication attribué à chaque avion dès son entrée dans la planification de

production) sur lequel la pièce commandée sera montée : un lot correspond donc à une seule pièce.)

2. Airbus demande une double confirmation de ses commandes d’achat :

- une confirmation de la commande elle-même quant aux dates de livraison (les quantités sont

indiquées comme non modifiables dans les accords cadres) dans un délai de 2 jours ouvrés de la

passation de la commande

- une confirmation de la livraison lorsque la marchandise est en passe d’être expédiée (cf lot livraison)

ISATIS




3.3.2.2.1. Le processus commande achat, Airbus

CREATION D'UNE COMMANDE D'ACHAT PAR AIRBUS / MANDANT 150


Sta

nd

ard

A

da

pta

tio

n

Fonctionnalité SAP Paramétrage

Création d'une commande d'achat avec numérotation automatique:

S ME21N Création d'un document d'achat YNB1 par copie de NB avec tranche de numérotation interne et poste standard " ":

ASPECT FONCTIONNEL S -type de commande proposée par défaut

Paramétrage au niveau du poste utilisateur

- lot obligatoire niveau poste S - Renseignement du lot niveau poste obligatoire (sinon mess d'erreur bloquant)

- un article par poste car un lot correspond à un article

S

- confirmation obligatoire S - confirmation obligatoire cochée par défaut

-double confirmation (AB et LA)

S - création de la clé de confirmation ZRSP - champ "PilotConf"= ZRSP par défaut

- type de stock "contrôle qualité"

S Paramétrage dans la fiche article

- édition commande en pdf non automatique lors de la sauvegarde

S - création d'une catégorie mess d'en-tête ZSTG. type de support imprimante et moyen de communication PDF - statut 3 pour maîtriser le moment de l'édition

- Données organisationnelles renseignées automatiquement

S Paramétrage au niveau du poste utilisateur

-Délai de 2 jours accordés au fournisseur pour confirmer

Choix de ne pas paramétrer cette règle de gestion, mais sert comme critère d'évaluation du fournisseur

ASPECT EDI A

- Transmission en EDI en temps réel de la commande créée. Génération manuelle de l'IDOC lors de l'enregistrement de la commande d'achat.

S - Création d'une catégorie mess d'en-tête ZORD type de support 6 EDI (génère un type de mess EDI ORDERS) - statut 3 pour maîtriser le moment de l'envoi - Paramétrer la catégorie de message ZORD dans les accords d'interchange. - Configurer le type de message ORDERS dans les paramètres

ISATIS




d’émission des accords d'interchange. - Transmission du numéro de lot

A

utilisation du champ incoterms 2 au niveau poste car : - champ inclus dans le type de mess ORDERS - champ de type texte, donc sans contraintes

champ à rendre obligatoire dans le type de document YNB1 (sinon message d'erreur bloquant)

Vérification du succès de l'émission du message de type ORDERS.

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les ORDERS sortants - Vérifier le statut (03)

S

ASPECT EDI S

- Paramétrer l'émission de messages de type ORDERS

3.3.2.2.2. Le processus Confirmation commande de vente, STG / Airbus

RECEPTION ET CONFIRMATION D'UNE COMMANDE DE VENTE


Sta

nd

ard

A

da

pta

tio

n


MANDANT 731 Vérification que le message de type ORDERS a été traité avec succès et Identification du numéro de la commande de vente générée

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les ORDERS entrants - Vérifier le statut (53) - Identifier le numéro de la commande générée

S

ASPECT EDI S - Configurer le type de message

ORDERS dans les paramètres de réception des accords d'interchange.

car le type de mess ORDERS ne transmet pas l'information du lot

ISATIS




MANDANT 731 Confirmation d'une commande de vente générée automatiquement par le système

S VA02 Création d'un document de vente (CSTG) par copie de CDCL avec poste

ZSTG créé par copie de TAN.

ASPECT FONCTIONNEL S - Visualisation de la commande de vente de type CSTG générée par EDI grâce à son numéro

Commande de type CSTG générée pour tous les ORDERS entrants

- Toutes les données provenant de la commande d'achat sont renseignées

- Prix calculé automatiquement en fonction de l'article et du client

Paramétrage d'une détermination de prix pour la combinaison article / client

- Texte ADV "précisant que "le client est traité par EDI" repris de la fiche client

Paramétrage du pilotage de texte: copie de du texte ADV de la fiche client vers l'en-tête de la commande client.

- Modification éventuelle des données commande d'achat: -quantité non modifiable - échéance modifiable dans les limites de tolérance négociées avec le client NB: Si hors tolérance, l'ORDRSP sera rejeté dans le mandant 150 TOUTE MODIFICATION EST LE RESULTAT D'UN ACCORD TELEPHONIQUE AVEC LE CLIENT

- Paramétrage des tolérances de dates de livraison au niveau de la clé de pilotage de confirmation ZRSP

- édition confirmation de commande en pdf non automatique lors de la sauvegarde

S - création d'une catégorie de mess d'en-tête ZBO5 type de support imprimante et moyen de communication PDF - statut 3 pour maîtriser le moment de l'édition

- Données organisationnelles renseignées automatiquement

S Paramétrage au niveau du poste utilisateur pour celles qui ne remontent pas de la fiche article - client, client ou article)

ASPECT EDI S - Transmission de la confirmation de commande non automatique lors de la sauvegarde

S - Création d'une catégorie de mess d'en-tête ZBO3 type de support 6 EDI (génère un type de mess EDI ORDRSP) - statut 3 pour maîtriser le moment de l'envoi

- Données transmises standard pour un type de mess ORDRSP

S

ISATIS




MANDANT 731 Vérification du statut d'émission de l'IDOC ORDRSP

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les ORDSRP sortants - Vérifier le statut (03)

S


ORDRSP dans les paramètres d'émission des accords d'interchange.

MANDANT 150 Vérification que le message de type ORDRSP a été traité avec succès et Identification du numéro de la commande d'achat concernée

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les ORDRSP entrants - Vérifier le statut (53) - Identifier le numéro de la commande d'achat concernée Si confirmation hors tolérances négociées, ORDRSP en erreur (statut….)

S

ASPECT EDI S

- Configurer le type de message ORDRSP dans les paramètres de réception des accords d'interchange.

MANDANT 150 Visualisation des données confirmées d'une commande d'achat

S ME22N

ASPECT FONCTIONNEL S - Visualisation de la commande d'achat confirmée par EDI grâce à son numéro

S

- Consulter l'onglet Confirmations et visualiser les données avec le statut AB

S

ISATIS




3.3.2.2.3. Le processus Modification d’une commande d’achat, Airbus

MODIFICATION D'UNE COMMANDE D'ACHAT PAR AIRBUS / MANDANT 150


Sta

nd

ard

A

da

pta

tio

n


Modification d'une commande d'achat

ASPECT FONCTIONNEL S Même processus que pour la création de commande

S ME22N

ASPECT EDI A - Transmission en EDI en temps réel de la commande modifiée. Génération manuelle de l'IDOC lors de la modification et sauvegarde de la commande.

S - Création de la catégorie de mess d'en-tête ZORD type de support 6 EDI (génère ici un type de mess EDI ORDCHG) - statut 3 pour maîtriser le moment de l'envoi - Configurer le type de message ORDCHG dans les paramètres d'émission des accords d'interchange.

- Transmission du numéro de lot

A

utilisation du champ incoterms 2 au niveau poste car : - champ inclus dans le type de mess ORDCHG - champ de type texte, donc sans contraintes

Vérification du statut d'émission de l'IDOC ORDCHG

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les ORDCHG sortants - Vérifier le statut (03)

S


ORDCHG dans les paramètres de d'émission des accords d'interchange.

car le type de mess ORDCHG ne transmet pas l'information du lot

ISATIS




3.3.2.2.4. Le processus Confirmation d’une commande de vente modifiée STG

/Airbus

CONFIRMATION D'UNE COMMANDE DE VENTE MODIFIEE


Sta

nd

ard

A

da

pta

tio

n


MANDANT 731 Vérification que le message de type ORDCHG a été traité avec succès et Identification du numéro de la commande de vente générée

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les ORDCHG entrants - Vérifier le statut (53) - Identifier le numéro de la commande générée

S


ORDCHG dans les paramètres de réception des accords d'interchange.

MANDANT 731 Confirmation d'une commande de vente modifiée automatiquement par le système

S VA02 Création d'un document de vente (CSTG) par copie de CDCL avec poste ZSTG créé par copie de TAN

Idem confirmation commande de vente non modifiée

MANDANT 731 Vérification du succès de l'émission du message de type ORDRSP

S WE02


MANDANT 150 Vérification que le message de type ORDRSP a été traité avec succès et Identification du numéro de la commande d'achat modifiée concernée

S WE02

ISATIS





MANDANT 150 Visualisation des données confirmées d'une commande d'achat modifiée

S ME22N


Simulation de la production 3.3.3.

La production n’ayant aucun impact sur la mise en place d’un flux EDI et vice versa, nous ne traiterons pas la

production ici. Cependant, pour les besoins du flux fonctionnel, nous l’avons simulée par une « Entrée de

marchandise sur commande client sans ordre de fabrication en stock qualité », ce qui nous permet de

reproduire ce qui se passe à la fin du processus de fabrication :

- Les pièces sont fabriquées sont par rapport à une commande client

- Elles font partie d’un lot de fabrication et entrent en stock qualité (un dernier contrôle qualité est

effectué juste avant l’expédition) avec un numéro de série qui leur est affecté à ce moment-là.

L’utilisation du numéro de lot Airbus comme numéro de série ne garantirait pas son unicité au sein d’STG

(deux pièces différentes devant être montées sur le même avion porteraient dans ce cas le même numéro de

série). Afin d’y remédier, il a été décidé, d’un commun accord avec le client, que le numéro de série serait

constitué du numéro article STG et du numéro de lot Airbus.

SIMULATION DE LA PRODUCTION MANDANT 731


Sta

nd

ard

A

da

pta

tio

n


Enregistrement du mouvement de stock simulant la fin de la production nécessaire à honorer la commande client

S MIGO A1: Entrée de marchandise

R10 Autres Code: 321 E: entrée en stock

qualité pour commande client sans ordre de

fabrication

ASPECT FONCTIONNEL S Enregistrement du mouvement de stock simulant la fin de la production nécessaire à honorer la commande client

S

- quantité totale égale à celle de la commande - 1 article par poste

car article géré par lot et un lot = une pièce

Pour chaque poste: - numéro de commande

car code 321 Si non renseignés, message d'erreur bloquant

ISATIS




obligatoire - numéro de poste de la commande obligatoire - numéro de lot obligatoire automatique

car article géré par lot. Num de lot = numéro de lot de fabrication généré par le système

Si non renseignés, message d'erreur bloquant

- numéro de série obligatoire manuel

car profil de numéro de série dans la fiche article est 003: mouvement de stock. Numéro de série =Num article- Numéro de lot AIRBUS (renseigné dans le champ incoterms2 niveau poste de la commande de vente)

Si non renseignés, message d'erreur bloquant

ASPECT EDI N/A

Lot 2 : Bon de livraison / Avis de réception 3.3.4.

Ce lot comprend les processus suivants :

Création de la livraison sortante et Emission du bon de livraison / création de la livraison entrante et Emission

de l’accusé de réception des marchandises.

On constate une utilisation particulière du bon de livraison : outre sa fonction classique, sa version papier sert

également comme attestation de la conformité des marchandises livrées de la part de STG d’une part, et

comme attestation de la conformité des marchandises reçues de la part d’Airbus d’autre part.

Pour ce faire, il reporte au niveau poste un texte particulier composé de deux parties : la première, signée par

le reponsable qualité et le responsable technique d’STG, atteste la conformité des pièces livrées au cahier des

charges du client, la deuxième, signée par le responsable qualité d’Airbus, libère STG de toute obligation car

elle atteste que la marchandise réceptionnée a passé le contrôle qualité d’Airbus avec succès.

L’exemplaire contresigné et scanné est adressé à STG par mail et l’original lui est envoyé par la poste.

La mise en place de l’EDI n’aura aucun impact sur cette partie du flux :

- le bon de livraison édition papier continuera à être utilisé comme attestation de conformité par les

deux partenaires.

- l’avis de livraison EDI (le DESADV) ne transmet pas le texte imprimé sur le bon de livraison papier

car son rôle est simplement de confirmer à Airbus la livraison imminente de la marchandise.

- l’avis de réception de livraison (le STPPOD) est simplement un accusé de réception physique de la

marchandise : il n’entre en aucun cas dans le processus de contrôle qualité.

3.3.4.1. Impact de la mise en place de l’EDI sur le processus

Le schéma suivant met en évidence les évolutions des tâches découlant de la mise en place des flux EDI.

ISATIS




Bon de livraison/Avis de réception

STG - Magasinier Client – Magasinier Client – Service qualitéSTG - Service qualité

Réc

epti

on

de

la m

arch

and

ise

par

le c

lien

tEx

péd

itio

n d

e la

mar

chan

dis

e p

ar le

fo

urn

isse

ur

Conditionner la marchandise

Créer la livraison sortante de la commande à livrer dans

l’ERP

Contrôler les colis pour réceptionner la

marchandise

Archiver un bon de livraison

Transmettre l’original par courrier

Enregistrer l’entrée de marchandise en attente de contrôle qualité dans l’ERP

Avis de réception original: Bon de livraison original

contresigné

Editer le bon de livraison en 2 exemplaires

Bons de livraison

Identifier la commande à réceptionner dans l’ERP

Signer les bons de livraison pour conformité

Bons de livraison signés

Enregistrer la sortie de marchandises

Recevoir les bons de livraison

Bons de livraison

Contresigner les bons de livraison pour conformité

Bons de livraison contresignés

Scanner l’autre bon de livraison et l’envoyer par

mail

Avis de réception pdf: Bon de livraison contresigné pdf

Contrôler pour accepter la marchandise

Contrôler pour libérer la marchandise

Modifier le statut de la marchandise de « en attente

de contrôle » en « disponible » dans l’ERP

Créer la livraison entrante dans l’ERP

Remettre la marchandise et les bons de livraison au

transporteur

Il ressort clairement que l’impact est ici mineur : une seule tâche est impactée côté fournisseur, à savoir la

création de la livraison sortante qui doit générer un flux EDI afin de créer la livraison entrante dans le système

du client, celle-ci étant la seule tâche disparaissant.

Générer la livraison

entrante dans l’ERP du client

Générer la facturation dans

l’ERP du fournisseur

ISATIS




Il est à noter également la génération automatique de la facture dans le système du fournisseur suite à l’accusé

de réception de livraison émis par le système du client. Cette tâche nous intéressera lors de la mise en place

du flux EDI pour le lot facturation (lot 3) mais elle est ici hors périmètre.

3.3.4.2. Solution proposée dans SAP

Dans cette partie du flux, les fonctionnalités standards d’SAP répondent parfaitement aux nécessités d’STG :

en particulier, les numéros de lots et de série sont des informations transmises par les types de messages EDI

standards liés à la livraison (DESADV) et à la réception (STPPOD) de marchandises.

Cependant, l’utilisation détournée du champ incoterms 2 niveau poste dans la commande d’achat dans le

système du client implique que ce champ a été renseigné de façon détournée dans la commande de vente

lorsqu’elle a été générée dans le système du client. Il faut donc le corriger avant de créer la livraison sortante

afin d’éviter des données erronées pour la gestion de la livraison.

3.3.4.2.1. Le Processus Livraison, STG

CREATION D'UNE LIVRAISON SORTANTE PAR STG / MANDANT 731


Sta

nd

ard

A

da

pta

tio

n


Création d'une livraison sortante

S VL01 N ou VA02 /livrer Création d'un type de livraison (ZLF1) par copie de LF avec poste ZSTG créé par copie du poste TAN Ce type de livraison est la livraison par défaut pour le document de vente CSTG

ASPECT FONCTIONNEL A - AVANT de créer la livraison, dans la commande de vente, modification de l'incoterms2 niveau poste en remplaçant le numéro de lot par l'incoterm2 renseigné au niveau en-tête

A

Dans la livraison, niveau poste: - quantité = 1

S

- triptyque Lot/No de série/commande obligatoire

S

choisir dans ceux proposés pour le stock de cet article les triptyques correspondant à la commande en cours de livraison

si non renseigné, message d'erreur bloquant

-Sortie de marchandise bloquée S

car article en stock contrôle qualité

si effectuée, message d'erreur bloquant

nécessaire du fait de l'utilisation détournée du champ pour permettre la transmission du No de lot client au fournisseur afin d’éviter un lieu de livraison différent pour chaque poste ce qui pourrait prêter à confusion pour la gestion du transport

ISATIS




- édition bon de livraison en pdf non automatique lors de la sauvegarde - reporte automatiquement au niveau poste le texte contrôle qualité STG et AIRBUS provenant de la fiche client - article

S - création du type de mess d'en-tête ZLD type de support imprimante et moyen de communication PDF - création d'un type de texte "visa contrôle libératoire" affectée à la fiche article-client - création d'un smartform et visualisation du texte "Visa contrôle libératoire" dans le Bon de livraison niveau poste. - statut 3 pour maîtriser le moment de l'édition

ASPECT EDI N/A Le message EDI ne sera édité que lors de la sortie de marchandise

LIBERATION DE LA MARCHANDISE APRES CONTRÔLE QUALITE / MANDANT 731


Sta

nd

ard

A

da

pta

tio

n



S MIGO A8: Transfert R10: Autres

Code: 321 E: transfert stock qualité commande client à

stock à utilisation libre.

Idem simulation de la production

ENREGISTREMENT DE LA SORTIE DE MARCHANDISES


Sta

nd

ard

A

da

pta

tio

n


MANDANT 731 Enregistrement de la sortie de marchandise

S VL02N

ASPECT FONCTIONNEL S Effectuer la sortie de marchandise

ASPECT EDI S

ISATIS




- Transmission en EDI en temps réel du bon de livraison non automatique lors de la sauvegarde - Texte "Visa contrôle libératoire" non présent

S - Création de la catégorie de mess d'en-tête ZALV type de support 6 EDI (génère un type de mess EDI DESADV) - statut 3 pour maîtriser le moment de l'envoi - Configurer le type de message DESADV dans les paramètres d'émission des accords d'interchange.

- Transmission du numéro de lot et des numéros de série

S car données transmises en standard dans le type de mess DESADV

MANDANT 731 Vérification du succès de l'émission du message de type DESADV

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les DESADV sortants - Vérifier le statut (03)

S


DESADV dans les paramètres d'émission des accords d'interchange.

3.3.4.2.2. Le processus Réception, Airbus / STG

ENREGISTREMENT DE L'ENTREE DE MARCHANDISES


Sta

nd

ard

A

da

pta

tio

n


MANDANT 150 Vérification que le message de type DESADV a été traité avec succès et Identification du numéro de la commande de vente générée

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les DESADV entrants - Vérifier le statut (53) - Identifier le numéro de la commande d'achat modifiée - Identifier le numéro de la livraison entrante créée

S

ISATIS





DESADV dans les paramètres de réception des accords d'interchange.

MANDANT 150 Visualisation des données de livraison confirmées d'une commande d'achat

S ME22N

ASPECT FONCTIONNEL S - Visualisation de la commande d'achat dont la livraison est confirmée par EDI grâce à son numéro

S

- Consulter l'onglet Confirmations et visualiser les données avec le statut LA

S

MANDANT 150 Enregistrement de l'entrée de marchandises

S VL32N

ASPECT FONCTIONNEL S - Visualisation de la livraison entrante générée par EDI grâce à son numéro - Enregistrement de l'entrée de marchandise

S

- Marchandise en stock bloqué

S

car paramétré dans la fiche article et mis par défaut dans la commande et donc dans la livraison entrante.

ASPECT EDI S - Transmission en EDI en temps réel de l'accusé de réception de la livraison non automatique lors de la sauvegarde

S - Création de la catégorie de mess d'en-tête ZOPD type de support 6 EDI (génère un type de mess EDI STPPOD) - statut 3 pour maîtriser le moment de l'envoi - Configurer le type de message STPPOD dans les paramètres d'émission des accords d'interchange.

MANDANT 150 Vérification du succès de l'émission du message de type STPPOD

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les STPPOD sortants - Vérifier le statut (03)

S


STPPOD dans les paramètres d'émission des accords d'interchange.

ISATIS




MANDANT 731 Vérification que le message de type STPPOD a été traité avec succès

S WE02

ASPECT FONCTIONNEL S - Filtrer sur la date du jour - Rechercher dans les STPPOD entrants - Vérifier le statut (53)

S


STPPOD dans les paramètres d'émission des accords d'interchange.

LIBERATION DE LA MARCHANDISE APRES CONTRÔLE QUALITE / MANDANT 150


Sta

nd

ard

A

da

pta

tio

n



S MIGO A8: Transfert R10: Autres

Code: 321 E: transfert stock qualité comande client à stock à utilisation libre.

Idem libération de la marchandise après contrôle qualité mandant 731

ISATIS




3.4. Etats

Dans cette partie nous ne traiterons que les états demandés par STG dans le cadre des flux achat-vente sous

EDI. Les états indépendants de l’EDI, déjà en place chez STG, ne seront pas évoqués.

Besoin Etats d’activité sous EDI 3.4.1.

Besoin client Convergence SAP

N°

état

Th

ème

Man

dan

t

Ob

ject

if,

Des

crip

tif

Pri

mo

rdia

l 1

Néc

essa

ire

2

Acc

esso

ire

3

Stan

dar

d /

tr

ansa

ctio

n

Par

amé

trag

e /

ad

apta

tio

n

Po

ssib

le v

ia

qu

ery.

Co

mm

enta

ires

ET01 Liste des Idoc (in/out)

150- 731

Doit permettre d'identifier les nouveaux IDoc ou faire des recherches spécifiques selon besoin

1 WE02 ou WE05

Filtrer et dérouler selon besoin

ET02 Liste des Idoc en erreur (in/out)

150 731

Etat dynamique à un instant T qui doit permettre de visualiser les Idoc en anomalie dans son propre mandant

1 WE07

Workflow sur IDoc entrant en erreur

WE07 en sélectionnant "historique des erreurs" et "Actuel dans statut erreur ou Mail interne SAP d'alerte lorsque IDOC entrant en erreur, mais un seul destinataire

ET03 Liste des commandes achat en attente de confirmation

150 Permet d'identifier les retards de confirmation

2 A priori ME92F ou ME2A (AB ou LA)

ME92F: affiche les commandes en retard de confirmation à une date donnée Possibilité d'entrée dans le détail

ET04 Liste des commandes vente à confirmer au client

731 Permet d'identifier ce qui doit être confirmé et sous quel délai. = le tableau de bord EDI au service de la Resp logistique et de l’ADV

1 VA05 Créer query après bascule. Cf. onglet spécifications fonctionnelles ET04

VA05 avec filtre sur statut A (non livré) et quantité confirmée = 0

ET05 Liste des commandes achat confirmées par fournisseur, avec modification sur date

150 A priori les modif° sont traitées au préalable par téléphone, mais pour éviter les impairs …

3 A traiter via query après bascule

les modifications ne sont autorisées que sur la date de livraison (+/-2j)

ET06 Liste des commandes vente modifiées par client

731 A priori les modif° sont traitées au préalable par téléphone, mais pour éviter les impairs …

3 WE02 filtrer sur ORDCHG

ISATIS




ET07 Liste des commandes d'achat avec avis de liv reçus

150 Utilise en prépa de réception pour s'organiser ou réagir si une commande n'arrive pas comme prévu

3 ME2A Filtrer traitement LA, pour lister les commandes dont l'avis de livraison a été reçu

ET08 Liste des commandes d'achat en retard de livraison

150 doublon avec ET07 2

ET09 Liste des commandes de vente en retard de départ

731 ne pas être en retard 3 A livrer après bascule

ET10 Liste des commandes achat avec mode d'envoi (EDI ou autre)

150 confort 3 Liste cdes avec un champ visible type de message

A livrer après bascule

ET11 Liste des accords interchange

150/731

En cas d'intervention en masse. Demande DSI

3 OK avec WE20

ET12 Liste des partenaires en échanges EDI

150/731

En cas d'intervention en masse. Demande DSI

3 faire avec WE20

ET13 Liste des IDOC envoyés en erreur de réception

731 Afin de s'assurer de la bonne réception et traitement des IDOC par le client. Améliore service client, réactivité et fournit une référence en cas de litige

2 BDM7 Paramétrage + job

Paramétrage et job. Nécessite accord du mandant 150. Idéalement à faire aussi du 731 vers le 150 après bascule

Spécifications pour création query pour états ET04 3.4.2.

Afin de la réaliser après bascule, voici ci-dessous les spécifications d’un tableau de bord clé, non standard, qui

sera réalisé après bascule via un query.

Document Détail spécifications fonctionnelles

Objet Création d'un query pour suivre les commandes de vente EDI (150) à confirmer

Code ET04

Demandeur Resp Log STG

Date de demande 17/07/2013

Rédacteur Isatis Fri

Date de rédaction 10/08/2013

Porteur Isatis ABM

Livraison Nov 2013

Contexte Mise en place d'un flux achat vente en EDI direct avec le client Airbus. Ce pilote a pour vocation à être étendu à d'autres clients en 2014

Objectif fonctionnel Airbus exige de ses fournisseurs qu'ils confirment sous 2 jours les commandes d'achat émises par EDI. Cette ponctualité est d'ailleurs un critère de l'évaluation des fournisseurs. STG souhaite mettre en place un tableau de bord à usage quotidien afin de suivre les 'postes de commande de vente Airbus à confirmer et ce dès leur réception.

ISATIS




Type de document Tableau de bord de type query SAP avec mise à jour en temps réel.

Définition Est considéré comme confirmé un poste : -dont les dates de livraison et quantité ont été confirmées -qui a été édité avec succès (i.e. le type de message EDI ZB03 a été envoyé) -dont l'ORDRSP a été émis avec succès

Filtre permanent Commandes de vente reçues par EDI, postes de commande non confirmés

Informations attendues Date du document, à confirmer pour le, alerte si délai dépassé, N° client, libellé client, N° document, N° commande achat, poste, article, désignation articles, quantité commandée, date de livraison souhaité, quantité confirmée, date livraison confirmée, Statuts d'émission message ZB03 du poste de la commande de vente, statut de l'ORDRSP,

Filtres paramétrables par utilisateurs

client, date du document, statut du message ZB03, statut de l'ORDRSP

Accès utilisateurs ADV, direction, Resp logistique

ISATIS




4. Etude de cadrage / Paramétrage de la solution SAP

4.1. Présentation générale du paramétrage

L’objet de cette partie est de présenter les différents points de paramétrage nécessaires pour la mise en œuvre

d’un flux achat-vente sous EDI entre la société Airbus (mandant 150) et son fournisseur STG (mandant 731).

Les deux sociétés possèdent un SAP R/3.

Comme le montre le schéma ci-dessous, le paramétrage s’est déroulé parallèlement en deux parties, et ce, sur

les 2 mandants STG et Airbus :

1. Le paramétrage fonctionnel qui structure les organisations et les flux fonctionnels achat-vente

2. Le paramétrage EDI qui permet de faire communiquer les deux partenaires au gré des étapes du flux

fonctionnel.

Pour construire la solution flux achat-vente sous EDI, nous avons effectué plus de 200 points de paramétrage.

Inutile de préciser qu’il n’est pas envisageable (ni enrichissant du reste) de présenter les 300 pages de

paramétrages dans ce document.

Compte tenu du cœur de notre problématique - l’EDI -, nous avons fait le choix de ne présenter que les points

de paramétrages liés à l’EDI. Par ailleurs, étant donné les similitudes des paramétrages sur les 2 mandants,

nous ne détaillerons que les paramétrages effectués dans le mandant 150 et les paramétrages applicatifs dans

le mandant 731.

Voici donc la façon dont nous allons procéder quant à la cinquantaine de points de paramétrage de ce

document :

PARAMETRAGE PROJET SAP EDI

Paramétrage Fonctionnel

Structure organisationnelle Données de base Groupe de compte Groupe de marchandise Type de document Type de poste Type d’échéance Détermination des messages Pilotage des textes …….

Paramétrage EDI

Paramétrage Global (Nécessaire pour toutes les

interfaces IDoc)

Système logique Affectation système logique au mandant Connexion RFC Modèle de distribution

Paramétrage Spécifique

(Nécessaire pour chaque interface IDoc)

Accords d’interchange : partenaires et messages échangés entre eux Table de correspondance

ISATIS




Nous décrirons les points de paramétrage nécessaires pour la mise en place de la connexion EDI entre les

deux systèmes (150 et 731) ainsi que les deux partenaires (YSTG alias STG et STG-AIRBUS alias Airbus).

Nous détaillerons ensuite les points de paramétrage nécessaires pour la gestion des IDocs reçus en statut

d’erreur, et montrerons comment l’agent responsable désigné dans les accords d’interchange est informé si

une erreur se produit au cours du traitement de l’IDoc chez son partenaire. Nous décrirons également les

points de paramétrage nécessaires pour le contrôle du statut de l’IDoc dans le système externe, afin que le

système émetteur soit informé de l’état des IDoc qui ont été envoyé.

Nous enchaînerons avec la description d’une partie des points de paramétrage concernant la détermination

des messages et expliquerons le lien entre cette dernière et l’EDI.

Enfin, nous terminerons par le détail des points de paramétrage nécessaires pour le pilotage des textes.

Les 150 points de paramétrage restants (structures organisationnelles, données de base, types de documents…),

sont documentés et consultables dans leur intégralité en annexe. La liste des paramétrages est synthétisée dans

un index placé également en annexe. En justifiant et décrivant comme ci-dessous chaque point de paramétrage,

cet index est une bonne clé d’entrée.

N°

du

pa

ram

étr

ag

e

Ra

cin

e d

e l

a h

iéra

rch

ie d

an

s le

d

ocu

me

nt

cib

le

Ca

tég

ori

e

Niveaux de hiérarchie dans le document source

Ma

nd

an

t

Ma

nd

an

t

Just

ific

ati

on

fo

nct

ion

ne

lle

De

scri

pti

on

Ty

pe

de

pa

ram

étr

ag

e

Dif

fusi

on

Référence existante dans le document source

15

0 A

irb

us

73

1 S

TG

1 :

Liv

rab

le

2 :

An

ne

xe

Niveau

2 3 4 5

1.3

.19

.. Structure organisationnelle

Affectation des différents éléments

Affectation société à périmètre analytique

150 731 Avoir notre propre société et notre propre structure organisationnelle de façon à: - ne pas risquer d'impacter les autres en paramétrant certaines choses - ne pas être impactés par des points de paramétrages effectués par les autres groupes qui se révéleraient en conflit avec les nôtres

Ce point de paramétrage sert à créer l'un des liens nécessaires entre les différents éléments de la structure organisationnelle de notre entreprise.

IMG 2

2.2

.2.. Master

data Paramétrages effectués pour répondre à des besoins divers

Définition d'un groupe de marchandises externes

Répondre à des besoins client divers (à des fins statistiques)

Création d'un groupe de marchandises externes (à des fins statistiques)

IMG 2

ISATIS




2.2

.3.. Master

data Paramétrages effectués pour répondre à des besoins divers

Définition d'un code branche

Répondre à des besoins client divers

Création d'un code branche (créer une typologie de classification des clients; ex: APE)

IMG 2

4.2. Connexion EDI

Le paramétrage d’une connexion EDI consiste en :

- Un paramétrage global nécessaire pour toutes les interfaces IDoc.

Création des Systèmes Logiques

Affectation des Systèmes Logiques aux mandants

Création des Connexions RFC

Création d’un Modèle de Distribution

- Un paramétrage spécifique à chaque interface.

Création des Accords d’Interchange : définition des partenaires et des types de messages échangés qu’ils échangent

Gestion des tables de correspondance des clients et des articles dans le système SAP du fournisseur.

Synthèse des paramétrages de la Connexion EDI 4.2.1.

Voici les 15 étapes à suivre pour mettre en place une connexion EDI :

Etape 1 : Mandant 150 – Transaction BD54

Création de deux Systèmes Logiques P09CLNT150 et P07CLNT731

Etape 2 : Mandant 150 – Transaction SCC4

Affectation du Système Logique P09CLNT150 au Mandant 150

Etape 3 : Mandant 150 – Transaction SM59

Création de la Destination RFC P07CLNT731 du même nom que le Système Logique du Mandant de

destination 731


Création de deux Systèmes Logiques P09CLNT150 et P07CLNT731

Etape 5 : Mandant 731 – Transaction SCC4

Affectation du Système Logique P07CLNT731 au Mandant 731

Etape 6 : Mandant 731 – Transaction SM59

ISATIS




Création de la Destination RFC P09CLNT150 du même nom que le Système Logique du Mandant de

destination 150


- Création du Modèle de Distribution AIRBUS_STG

- Détermination des Types de Messages en Emission (Outbound) : ORDERS – ORDCHG – STPPOD

- Détermination des Types de Messages en Réception (Inbound) : ORDRSP – DESADV


- Génération automatique des Accords d’Interchange

- Création automatique des partenaires de type Système Logique : P09CLNT150 et P07CLNT731

- Création automatique d’un Port d’Emission vers le mandant 731. Le nom du port est généré

automatiquement (A000000XX). Pour simplifier l’identification de ce port nous lui avons donné le

nom P07CLNT731.

- Ajout automatique des paramètres d’émission (Outbond) : ORDERS – ORDCHG – STPPOD

- Ajout automatique des paramètres de réception (Inbound) : ORDRSP – DESADV


- Répartition du Modèle de Distribution AIRBUS_STG dans le Mandant 731.


- Génération automatique des Accords d’Interchanges :

- Création automatique des partenaires de type Système Logique : P09CLNT150 et P07CLNT731

- Création automatique d’un Port d’Emission vers le mandant 150. Le nom du port est généré

automatiquement (A000000XX). Pour simplifier l’indentification de ce port nous lui avons donné le

nom P09CLNT150.

- Ajout automatique des paramètres d’émission (Outbond) : ORDRSP – DESADV

- Ajout automatique des paramètres de réception (Inbound) : ORDERS – ORDCHG – STPPOD

Etape 11 : Mandant 150 – Transaction WE20

- Création du Partenaire YSTG avec les paramètres suivants :

LI: Fournisseur

YSTG

Paramètres d'émissions

Type de message

Options Pilotage Messages

Type d'IDoc

Port de réception

Mode de sortie

Application Catégorie

de Message

Code de Traitement

ORDERS ORDERS05 P07CLNT731 Transfert

Immédiat EF: Achat commande

ZORD ME10: Commande

ORDCHG ORDERS05 P07CLNT731 Transfert Immédiat

EF: Achat commande

ZORD ME11: Modification d'une commande

STPPOD DELIVRY03 P07CLNT731 Transfert Immédiat

E1: Livraison entrante

ZOPD OPOD: Accusé de réception: sortie

Paramètres des réceptions Type de

message

Options de réception

Code traitement Mode d'entrée

ORDRSP ORDR Lancement immédiat

DESADV DELS Lancement immédiat

ISATIS




Etape 12 : Mandant 731 – Transaction WE20

- Création du Partenaire STG – AIRBUS avec les paramètres suivants :

KU: Client STG-AIRBUS (DO: Donneur d'Ordre)


Type de message


Type d'IDoc Port de

réception Mode de sortie Application

Catégorie de

Message Code du Traitement

ORDRSP ORDERS05 P09CLNT150 Transfert Immédiat V1: Vente ZB03 SD10: Accusé de réception pour commande achat

DESADV DELIVRY05 P09CLNT150 Transfert Immédiat V2: Expédition ZARL DELV: Livraison


message



ORDERS ORDE Lancement immédiat

ORDCHG ORDC Lancement immédiat

STPPOD DPOD Lancement immédiat

- Création du Partenaire YDV1 avec les paramètres suivants :

KU: Client YDV1 (CL: Client Livré)

Paramètres d'émissions Type de

message


Type d'IDoc Port de réception

Mode de sortie


de Message Code du

Traitement ORDRSP ORDERS05 P09CLNT150 Transfert

Immédiat V1: Vente

ZB03 SD10: Accusé de réception pour commande d'Achat

DESADV DELIVRY05 P09CLNT150 Transfert Immédiat

V2: Expédition

ZARL DELV: Livraison


message



ORDERS ORDE Lancement immédiat

ORDCHG ORDC Lancement immédiat

STPPOD DPOD Lancement immédiat

Etape 13 : Mandant 731 – Transaction VOE4

Cette transaction permet d’associer la codification externe (à savoir celle sous laquelle ils sont identifiés dans

les Idoc) du client donneur d’ordre (STG-AIRBUS) et du client livré (YDV1) au numéro interne (à savoir celui

sous lequel ils sont identifiés dans le système du fournisseur).

La définition de STG – AIRBUS et YDV1 dans la table EDPAR du mandant 731 est comme suit :

Client Rôle Désignation Partenaire externe N° interne

STG – AIRBUS DO Donneur d’ordre P09CLNT150 STG - AIRBUS STG – AIRBUS CL Client livré YDV1 YDV1

ISATIS




Etape 14 : Mandant 731 – Transaction VOE2

Cette transaction sert à la détermination automatique du type de document de vente à générer dans le

système du fournisseur, et ce en fonction du donneur d’ordre, du numéro de fournisseur dans le système du

client (mandant 150), de l’organisation commerciale, du canal de distribution et du secteur d’activité.

Client N°

Fournisseur Organisation Commerciale

Canal de Distribution

Division Type de

doc. vente Désignation

STG - AIRBUS YSTG ZOC1 Z1 Z2 CSTG Commande Client

Etape 15 : Mandant 731 – Transaction VD51

Cette transaction permet, pour chaque combinaison client-article, de créer une fiche info client-article.

Elle permet de faire la correspondance entre le nom de l’article dans le système du client et le nom cet article

dans le système du fournisseur.

4.2.1.1. Mandant 150 : Création de deux Systèmes Logiques P09CLNT150 et

P07CLNT731

Ce paramétrage permet d’identifier de manière univoque chaque système (qu’il soit émetteur ou récepteur)

en tant que système logique au sein d’un réseau. La définition des systèmes logiques doit être faite dans tous

les systèmes SAP impliqués dans le scénario EDI.

Nous avons donc créé dans chaque mandant deux systèmes logiques. Le premier système logique

(P07CLNT731) représente le pilote et joue le rôle du système récepteur (mandant 731). L’autre

(P09CLNT150) joue le rôle du système expéditeur (mandant 150).

Dans 150

Systems Logiques P09CLNT150, P07CLNT731

Transaction BD54

Chemin (Transaction SALE)/Système de base / Répartition (ALE) / Préparer systèmes

émetteur et récepteur / Configurer systèmes logiques / Nommer le système

logique.

Objectif Créer deux systèmes logiques, un pour le mandant 150 et l’autre pour le mandant

731.

- Dans SAP, exécuter la transaction BD54 et cliquer sur Nouvelles entrées pour ajouter les deux

systèmes logiques.

- Entrer le nom et la description du système logique qui représente le mandant 150 (P07CLNT150).

ISATIS




- Entrer le nom et la description du système logique qui représente le système récepteur externe c'est-

à-dire le mandant 731 (P09CLNT731) et enregistrer les entrées.

- Vérifier que les deux systèmes logiques ont bien été créés.

4.2.1.2. Mandant 150 : Affectation du Système Logique P09CLNT150 au Mandant

150

Dans 150 System Logique P09CLNT150 Transaction SCC4 Chemin (Transaction SALE)/Système de base / Répartition (ALE) / Préparer systèmes

émetteur et récepteur / Configurer systèmes logiques / Affecter système logique au mandant.

Objectif Associer le mandant 150 au système logique P09CLNT150. - Dans SAP, exécuter la transaction SCC4 et sélectionner la ligne qui représente le mandant 150, puis

cliquer sur détail pour afficher le détail de ce mandant.

- Cliquer sur modifier pour pouvoir changer le nom du système logique.

- Dans le champ Système Logique, sélectionner le système logique expéditeur (P09CLNT150) à

assigner au mandant 150 et enregistrer vos entrées.

ISATIS




4.2.1.3. Mandant 150 : Création de la Destination RFC P07CLNT731

Dans 150 Destination P07CLNT731 (le même nom que le LS du mandant 731) Transaction SM59 Objectif Création de la destination RFC P07CLNT731

- Dans SAP, exécuter la transaction SM59 et cliquer sur l’icône Créer

- Nommer la destination RFC. Pour générer automatiquement les accords d’interchange et les ports, le

nom de la destination RFC doit être le même que le nom du système logique de destination. Pour cette

raison, nous avons nommé la destination RFC : P07CLNT731.

- Sélectionner le type de connexion 3 (connexion ABAP).

- Ajouter une description de la destination et entrer les options techniques suivantes qui permettent

d’identifier le serveur cible (mandant 731) : Serveur cible : mshsapecc7 ; Hôte : mshsapecc7 ; N° du

système : 00.

- Entrer les paramètres de connexion ci-dessous et cliquer sur « test de connexion » pour vérifier la

connexion RFC :

Langue FR Mandant 731 Utilisateur XXXXXXXX Mot de passe **********

ISATIS




L’utilisateur doit posséder des autorisations relativement étendues pour paramétrer les transferts RFC.

- Sauvegarder.

4.2.1.4. Mandant 150 : Création du Modèle de Distribution AIRBUS_STG

Le modèle de distribution est ce qui définit logiquement les flux entre les systèmes logiques. C’est lors de cette

étape que l’on définit les types de message échangés ainsi que les filtres sur certains segments de l’IDoc

transporté.

Le modèle de distribution est entièrement paramétré dans un environnement de référence, puis distribué vers

les autres mandants.

Dans 150 Nom du Modèle STG_150_731 Transaction BD64

- Exécuter la transaction BD64 et cliquer sur Modifier.

ISATIS




- Cliquer sur Créer vue du modèle.

- Saisir une description, un nom technique du modèle de distribution et une durée de validité, puis

valider.

4.2.1.5. Mandant 150 : Détermination des Types de Messages en Emission

Dans cette étape nous allons ajouter les types de message à envoyer du mandant 150 vers le mandant 731.

Nous nous limitons dans ce document au type de message ORDERS. Cf. annexes pour les autres

- Sélectionner le modèle de distribution AIRBUS_STG et cliquer sur Insérer type de message.

- Dans le champ Emetteur, saisir le nom du système logique expéditeur (P09CLNT150).

- Dans le champ Destinataire, saisir le nom du système logique récepteur (P07CLNT731).

- Entrer le nom du type de message à envoyer (ORDERS) et valider.

4.2.1.6. Mandant 150 : Détermination des Types de Messages en Réception

Dans cette étape nous allons ajouter les types de message à recevoir dans le mandant 150 provenant du

mandant 731. Nous nous limitons dans ce document au type de message ORDRSP. Cf. annexes pour les autres

- Dans le champ Emetteur, saisir le nom du système logique expéditeur (P07CLNT731).

- Dans le champ Destinataire, saisir le nom du système logique récepteur (P09CLNT150)

- Entrer le nom du type de message à envoyer (ORDRSP) et valider.

ISATIS




Une fois tous les paramétrages effectués, le modèle de répartition se présente de la façon suivante :

4.2.1.7. Mandant 150 : Génération automatique des Accords d’Interchange

Les accords d’interchange permettent de faire le lien entre le document SAP et l’IDoc : ils précisent le mode de

sortie (individuellement ou par paquets) des IDoc, le traitement à effectuer ainsi que le mode de traitement

(immédiat ou en arrière-plan). Le port doit être précisé pour la vue « Sortante » des accords d’interchange.

Les partenaires doivent être renseignés dans les accords d’interchange afin que les IDocs puissent être

transmis avec succès. Un partenaire est identifié par :

- Un numéro : numéro d’identifiant SAP

- Un type : B (banque), KU (client), LI (fournisseur), LS (système logique)

- Une fonction (ou rôle) : client livré, donneur d’ordre, …

Dans 150 Nom du Modèle AIRBUS_STG Transaction BD82 Objectif Générer automatiquement les accords d’interchange

- Exécuter la transaction BD82.

- Dans le champ Vue du modèle, entrer le nom technique du modèle de distribution créé

précédemment : AIRBUS_STG.

- Cliquer sur Exécuter pour lancer la génération automatique des accords d’interchange.

ISATIS




-

Le système créera automatiquement :

- Deux partenaires de type LS (Système Logique) : P09CLNT150 et P07CLNT731. Chaque partenaire

représente un mandant.

- Un port d’émission : P07CLNT731 associé à la destination RFC P07CLNT731. Le port RFC permet de

déterminer la destination RFC vers laquelle les fichiers IDoc sont envoyés.

- Les Types de message et les paramètres d’émission et/ou de réception pour le partenaire LS

P07CLNT731.

- Les paramètres de détermination des messages pour les IDocs en émission.

ISATIS




4.2.1.8. Mandant 150 : Création automatique des partenaires de type Système

Logique

Le système crée automatiquement des partenaires de type système logique et leur affecte, suite à la

distribution du modèle de distribution AIRBUS_STG, les types de message définis dans ce modèle.

Pour voir le détail des types de messages échangés entre les deux systèmes logiques, sélectionner un type de

message et cliquer sur détail (loupe). Nous ne présenterons pas dans ce document le détail des paramètres en

émission et en réception entre les deux systèmes logiques.

En annexe, ce fichier détaille tous les points de paramétrage de la

connexion EDI

- P07CLNT731

Mandant 150 Transaction WE20 Objectif Vérification de la création automatique du partenaire Logique

P07CLNT731

4.2.1.9. Mandant 150 : Création automatique d’un Port d’Emission vers le

mandant 731

Le système génère automatiquement des ports, auxquels l’interface IDoc affecte de manière automatique un

numéro alphanumérique. Grâce à ce numéro, ils sont identifiés de façon univoque.

Les deux partenaires

ont bien été créés

Le nom du partenaire

LS (Système Logique) créé

Les types de message

en émission générés

automatiquement

Les types de message

en réception générés

automatiquement

ISATIS




Le système ne peut générer les numéros de ports que si un intervalle de numéros est défini pour l’objet de

tranche de numéro « EDIPORT » dans la tranche de numéro « 01 ».

Le numéro du port généré automatiquement est composé d’un ‘A’ et d’un nombre de 9 chiffres (Axxxxxxxxx).

Pour simplifier l’identification de ce port nous l’appellerons P07CLNT731.

Nous allons vérifier via la transaction OYSM si une tranche de numéros de port est définie dans le système.

- Taper la transaction OYSM et saisir l’objet EDIPROT.

- Cliquer sur Tranche de numéros.

- Cliquer sur Intervalle.

La tranche de numéro 01 est bien définie dans le système.

Nous allons vérifier si le système a bien créé automatiquement le port qui est associé à la connexion RFC.

Mandant 150 Transaction WE21 Objectif Vérification de la création automatique du port d’émission P07CLNT731

associé à la connexion RFC P07CLNT731

ISATIS




4.2.1.10. Mandant150 : Génération automatique des numéros d’IDoc

Les numéros sont attribués automatiquement pour les IDoc envoyés et reçus. Les IDoc peuvent ainsi être

identifiés de façon explicite et univoque.

Pour que le système puisse générer les numéros, il est indispensable qu’une tranche de numéros soit définie

pour l'objet de tranche de numéros « EDIDOC » dans la tranche de numéros « 01 ».

Pour vérifier si une tranche de numéros des IDoc est définie dans le système, taper la transaction OYSM et

saisir EDIDOC dans le champ objet. Dans notre cas une tranche de numéros 0000000000000000-

9999999999999999 est bien définie dans le système.

4.2.1.11. Mandant 150 : Répartition du Modèle de Distribution AIRBUS_STG dans le

Mandant 731

Après la configuration du modèle de distribution, la création des accords d’interchange, des types de message

et du port d’émission dans le Mandant 150, il faut faire la même chose dans le Mandant 731. La transaction

BD64 permet de répartir le modèle de distribution du mandant 150 dans le mandant 731.

La répartition du modèle de distribution créé dans le mandant 150 permet de le reproduire automatiquement

dans le mandant 731.

Dans 150 Transaction BD64 Objectif Reproduire dans le mandant 731 le modèle de distribution créé dans le mandant 150

Pour répartir le modèle de distribution AIRBUS_STG il faut :

- Exécuter la transaction BD64 et sélectionner le modèle de distribution AIRBUS_STG

- Dans le Menu, sélectionner Traiter / Vue du modèle / Répartir

Le système crée automatiquement le

port et il lui associe la destination

RFC du système de destination.

ISATIS




- Le système sélectionne automatiquement système logique P07CLNT731

- Valider.

- Dans le 150 le système affiche que le modèle de distribution AIRBUS_STG est bien réparti dans le

système cible (731)

Le paramétrage global, nécessaire pour toutes les interfaces IDoc est terminé dans le mandant 150, il faut

procéder de la même manière dans le mandant 731. Cf. document en annexe

Nous allons procéder maintenant au paramétrage spécifique à chaque interface IDoc et détailler toutes les

actions nécessaires pour la communication entre les partenaires STG et Airbus.

ISATIS




4.2.1.12. Mandant150 : Création des Accords d’interchange pour le partenaire YSTG

La société Airbus souhaite envoyer, depuis le module MM, des commandes d’achats et des accusés de

réception de livraisons à son fournisseur STG. Elle doit donc définir YSTG en tant que partenaire pour les

messages échangés dans les accords d’interchange et lui affecter le port qui a été défini pour ce partenaire.

Le traitement des documents sortants se déroule toujours avec la gestion des messages (détermination des

messages) que nous verrons dans le paragraphe 4.6.

Nous allons configurer les accords d’interchange pour le partenaire YSTG dans le mandant 150. Le principe

est le même pour créer le partenaire STG-AIRBUS dans le mandant 731.

Créer le partenaire YSTG

- Exécuter la transaction WE20 pour ajouter un nouveau type de partenaire (le numéro de partenaire

doit exister en tant que donnée de base dans le mandant 150).

- Sélectionner le dossier « Type de partenaire LI » dans le volet de navigation des accords d’interchange

et cliquer sur créer.

ISATIS




Configuration des paramètres d’émission et de réception

Le tableau ci-dessous résume tous les paramètres utilisés pour configurer le fournisseur YSTG dans le

mandant 150

LI: Fournisseur

YSTG


Type de message


Type d'IDoc

Port de réception

Mode de sortie


de Message

Code de Traitement

ORDERS ORDERS05 P07CLNT731 Transfert

Immédiat EF: Achat commande

ZORD ME10: Commande

ORDCHG ORDERS05 P07CLNT731 Transfert Immédiat

EF: Achat commande

ZORD ME11: Modification d'une commande

STPPOD DELIVRY03 P07CLNT731 Transfert Immédiat

E1: Livraison entrante

ZOPD OPOD: Accusé de réception: sortie


message



ORDRSP ORDR Lancement immédiat

DESADV DELS Lancement immédiat

Nous nous limitons dans ce document au seul de type message en émission ORDERS et au seul type de

message en réception ORDRSP. Cf. annexe pour les autres

Paramètres d’émission : ORDERS

Pour ajouter un type de message au partenaire YSTG dans les accords d’interchange, taper la transaction

WE20 et, dans le volet de navigation « Accords d’interchange », sélectionner le partenaire YSTG dans le

dossier « Type de partenaire LI ».

- Cliquer sur « Ajouter » dans la zone paramètres d’émission.

ISATIS




- Dans l’onglet Options émission choisir ORDERS comme Type de message, ORDERS05 comme Type de

base, P07CLNT731 comme port de réception et Transfert IDoc immédiat comme mode de sortie.

- Dans l’onglet pilotage des messages sélectionner ZORD comme catégorie de message.

Paramètres de réception : ORDRSP

Le traitement des messages entrants ne nécessite que le code de traitement.

- dans la zone paramètres de réception Cliquer sur « Ajouter » et saisir les paramètres suivants :

ISATIS




ORDRSP dans le champ Type de message

ORDR dans le champ Code traitement

Choisissez le mode de traitement immédiat.

Le partenaire YSTG de type fournisseur est désormais créé et les accords d’interchange entre ce partenaire et

le client STG-AIRBUS sont gérés. Il ne reste plus qu’à faire de même dans le mandant 731 pour le partenaire

STG-AIRBUS (type client KU).

4.2.1.13. Mandant 731 : Table de correspondance code client externe – code client

interne

Mandant 731 Transaction VOE4 Chemin IMG

ISATIS




Objectif Lier le code client externe (propre à STG-AIRBUS) avec son code interne chez le fournisseur (propre à YSTG)

La transaction VOE4 permet d'associer, dans la table EDPAR, la codification externe (à savoir celle sous

laquelle ils sont identifiés dans les IDoc) du client donneur d’ordre (STG-AIRBUS) et du client livré (YDV1) au

numéro interne (à savoir celui sous lequel ils sont identifiés dans le système du fournisseur).

Client Rôle Désignation Partenaire externe N° interne

STG – AIRBUS DO Donneur d’ordre P09CLNT150 STG - AIRBUS STG – AIRBUS CL Client livré YDV1 YDV1

- Exécuter la transaction VOE4 et cliquer sur Nouvelles entrées.

- Ajouter deux entrées, une pour le donneur d’ordre et l’autre pour le client livré, et sauvegarder.

4.2.1.14. Mandant 731 : Détermination automatique du type de document de vente

Mandant 731 Transaction VOE2 Objectif Type de document de vente à générer en fonction du

fournisseur, client et domaine commerciale.

La transaction VOE2 sert à la détermination automatique du type de document de vente à générer dans le

système du fournisseur, et ce en fonction du donneur d’ordre, du numéro de fournisseur dans le système du

client (mandant 150), de l’organisation commerciale, du canal de distribution et du secteur d’activité.

- Exécuter la transaction VOE2 et cliquer sur Nouvelles entrées.

- Ajouter les informations suivantes dans la table EDSDC et sauvegarder.

ISATIS




Client N°

Fournisseur Organisation Commerciale

Canal de Distribution

Division Type de

doc. vente Désignation

STG - AIRBUS YSTG ZOC1 Z1 Z2 CSTG Commande Client

4.2.1.15. Mandant 731 : Correspondance code article client – code article

fournisseur

Mandant 731 Transaction VD51 Objectif Lier le numéro d’article client (STG-AIRBUS - 150) avec son

code dans le système SAP du fournisseur (YSTG - 731)

Pour chaque combinaison client-article, il faudra créer par la transaction VD51 les fiches info client-article.

- Exécuter la transaction VD51 et entrer les informations suivantes :

- Saisir le code article dans chaque mandant (150 et 731) et sauvegarder.

AIRBUS – Mandant 150 STG – Mandant 731

PC-0003-EDI WP.M251400.EDI

ISATIS




4.3. Génération d’IDoc via une correspondance (gestion des messages)

L’objet de ce paragraphe est de présenter les liens existant entre l’EDI et les messages de correspondance.

Par paramétrage, les messages de correspondance dans SAP permettent d’exécuter un programme (standard

ou spécifique). Dans le cadre de l’EDI, un paramétrage particulier permet la génération d’Idoc à partir d’une

correspondance (i.e. une catégorie de message).

Dans un premier temps, nous décrirons une partie du paramétrage d’une correspondance. Puis, sera présenté

le paramétrage des accords d’interchange, dans lequel est spécifiée la fonction de génération d’Idoc

En annexe sont décrits tous les points de paramétrage nécessaires pour la détermination des messages dans les

domaines fonctionnels achat et vente. Y sont détaillés les messages pour envoi en EDI et les messages pour édition

en format PDF.

Synthèse des paramétrages d’une correspondance (message) 4.3.1.

Le paramétrage d’une correspondance se fait dans chaque domaine fonctionnel et consiste à gérer les points

suivants dans le customizing (SPRO) :

Dans notre exemple nous allons voir le point de paramétrage « gérer les catégories de message ». Nous avons

créé une catégorie de message ZORD qui sera proposé automatiquement, selon des critères définis dans le

SPRO, au niveau de l’entête de la commande d’achat lors de la création d’une commande.

4.3.1.1. Catégorie de message

Mandant 150 Transaction SM36 Chemin IMG IMG/Gestion des articles/Achats/Messages/pilotage des sorties/Catégories

de message/Définir catégories de message de la commande/Gérer catégories de messages de la commande

Objectif Gérer catégorie de message

- Créer une catégorie de message ZORD par copie de la catégorie NEU.

ISATIS




Pour créer ZORD, sélectionner la catégorie de message NEU et cliquer sur copier.

Renseigner le code (ZORD) et la désignation 5OUTPUT PO EDI STG)

La séquence d’accès 0001, affectée à notre catégorie de message, indique qu’un message sera créé dans la

commande d’achat si le tryptique type de document d’achat, l’organisation d’achat et le fournisseur existent

en tant qu’enregistrement de conditions.

Affecter à la catégorie de message ZORD le support « EDI » et la date/heure d’envoi « 3 » (envoi manuel et

NON automatique) :

Pour la catégorie de message ZORD et le type de support EDI sont affectés : un programme, une routine de

traitement et des rôles partenaires.

Programme et Routine de traitement

ISATIS




A ce niveau, on peut associer à la catégorie de message une routine d’un programme spécifique (ce

programme spécifique gérant la création d’un Idoc).

Nous utilisons ici la routine EDI_PROCESSING du programme standard RSNASTED. Cette routine standard

peut être utilisée pour toute correspondance de type EDI.

Rôles partenaires

Nous allons voir comment associer à un type d’IDoc une fonction particulière qui va générer celui-ci.

4.3.1.2. Accords d’interchange

Comme nous l’avons vu dans le paragraphe 4.3.1, ce paramétrage consiste à définir les propriétés et

caractéristiques des messages EDI échangés entre deux partenaires. On accède à ce paramétrage par la

transaction WE20.

Exécuter la transaction WE20 et sélectionner le partenaire YSTG (fournisseur) et puis le type de message

ORDERS dans la zone de paramètres d’émission.

Dans le deuxième onglet « pilotage messages », on associe un « code opération » à la correspondance

(message) ZORD.

ISATIS




On retrouve ici certains éléments vus lors de la création de la correspondance (Application EF, Catégorie de

message).

Le code opération associe un type de message EDI avec un module fonction de génération d’Idoc. Ce lien se fait

via la transaction WE41 .

Le code opération ME10 est associé au module fonction IDOC_OUTPUT_ORDERS

Le type de message ORDERS est associé au code opération ME10

Pour résumer, le paramétrage présenté permet la création d’un Idoc standard à partir d’une correspondance à

laquelle est associé un code opération également standard, ce code opération étant lui-même associé à un

module fonction.

ISATIS




4.4. Pilotage des textes

L’objectif de ce paragraphe est de définir les différents points de paramétrage à mettre en œuvre pour le

pilotage des textes. Il s’agit d’enregistrer des textes dans les données de base et de paramétrer le système afin

de retrouver ces textes automatiquement dans les documents de vente.

Nous ne détaillerons ici que les points de paramétrage pour copier le texte saisi dans la fiche client vers

l’entête de la commande client et l’entête de la livraison sortante. Ce texte sert à distinguer un client qui utilise

une connexion EDI d’un client standard (qui n’utilise par l’ EDI).

En annexe sont détaillés tous les points

de paramétrage du pilotage des textes. Les points de paramétrage suivants y sont décrits :

- Copie de texte de la fiche info-client vers le poste de document de vente

- Copie de texte de la fiche info-client vers le poste de livraison sortante

- Copie de texte de la fiche client vers l’en-tête de la commande client.

- Copie du texte de la fiche client vers l’en-tête de la livraison sortante

- Copie du texte de la fiche article vers le poste de la livraison sortante

- Copie de du texte de la fiche article vers le poste de la commande client.

Le pilotage des textes consiste à gérer les activités suivantes du customizing :

Synthèse des paramétrages du pilotage des textes 4.4.1.

Nous allons détailler les points de paramétrage pour copier le texte « type client EDI » de la fiche client dans

l’en-tête de la commande client.

- Pour voir le texte de la fiche client, exécuter la transaction VD03 et saisir le client STG-AIRBUS et le

domaine commercial ZOC1, Z1,Z2.

- Pour afficher le texte de la fiche client, cliquer sur « autres fonctions »->Textes

ISATIS




4.4.1.1. Créer un type de texte pour l’objet client-ADV (fiche client)

Pour pouvoir copier le texte « type client EDI » de la fiche client dans la commande, il faut gérer un type de

texte pour l’objet « client/ADV » dans le customizing.

Mandant 731 Transaction VOTXN Chemin IMG IMG->Administration des ventes->Fonctions de base->Pilotage des textes-

>Définir les types de texte. Objectif Créer un type de texte pour l’objet client ADV

- Marquer client-ADV et cliquer sur Types de texte.

ISATIS




- Ajouter le type de texte « Type client EDI » : « nouvelles entrées » puis saisir ID et désignation.

- Enregistrer.

4.4.1.2. Affecter le type de texte au schéma de texte


>Définir les types de texte. Objectif Créer un type de texte pour l’objet client ADV

- Marquer Client-ADV et cliquer sur Modifier

- Sélectionner le schéma de texte 01 et double cliquer sur « ID de texte dans le schéma de textes ».

ISATIS




- Pour ajouter le nouveau type de texte (Type client EDI), cliquer sur « nouvelles entrées » et saisir :

N° d’accès (140)

ID de texte (10)

Designation. (Type client EDI).

4.4.1.3. Affecter le schéma de textes au groupe de compte

Nous travaillons avec le groupe de compte ZDO, nous allons donc affecter le schéma de texte 01 au groupe de

compte ZDO.

Dans l’écran de synthèse double cliquer sur « affectation schéma de textes ».

Le schéma de textes 01 est affecté au groupe de compte ZDO.

ISATIS




4.4.1.4. Créer un type de texte pour l’objet document de vente-Entête.


>Définir les types de texte. Objectif Créer un type de texte pour l’objet Document de vente-En-tête

- Marquer Document de vente-En tête et cliquer sur types de texte.

- Créer un nouveau type de texte. ID : ZEDI et désignation : Type client EDI

4.4.1.5. Affecter le type de texte au schéma de texte

Dans l’écran de synthèse, Marquer Document de vente-Entête et cliquer sur Modifier.

ISATIS




Nous allons affecter le type de texte ZEDI au schéma de texte En-tête du document de vente.

- Sélectionner le schéma de texte 01 et double cliquer sur ID de texte dans le schéma.

- Ajouter le nouveau type de texte ZEDI au schéma de texte : « nouvelles entrées » et saisir :

N° d’accès

ID texte

4.4.1.6. Affecter la séquence d’accès au type de texte.

Nous allons affecter la séquence d’accès 54 au type de texte ZEDI.

- Dans l’écran de synthèse, double cliquer sur Séquences d’accès pour ID de texte.

ISATIS




- Sélectionner la séquence 54 et double cliquer Séquence d’accès pour ID de texte.

- Ajouter une nouvelle entrée dans la séquence d’accès 54 : nouvelles entrées et saisir :

N° d’accès : 20

ID texte : 10

Rôle partenaire : DO

4.4.1.7. Affecter le type de document de vente au schéma de textes

Nous allons affecter le type de document de vente CSTG au schéma de textes 01.

- Dans l’écran de synthèse, double cliquer sur Affectation schéma de textes.

- Le document de vente CSTG est affecté au schéma de textes 01.

ISATIS




4.4.1.8. Affecter la séquence d’accès au type de texte dans le schéma de texte

Nous allons affecter la séquence d’accès 54 au type de texte ZEDI dans le schéma de textes 01.

- Dans l’écran de synthèse, sélectionner le schéma de textes 01 et double cliquer sur « ID de texte dans

le schéma de textes »

- Pour le type de texte ZEDI, saisir la séquence d’accès 54 dans la colonne Séquence d’accès.

- Enregister.

Le texte « Type client EDI » de la fiche client sera désormais édité automatiquement lors de la création d’une

commande de vente pour ce client.

ISATIS




4.5. Gestion des IDoc reçus en statut d’erreur (Workflow)

L’objet de cette partie est de présenter tous les points de paramétrage nécessaires pour gérer les IDocs reçus

avec un statut d’erreur. L’objectif principal est d’alerter en temps réel la ou les personnes responsables de

l’échec de réception ou du traitement des IDocs. L’alerte est donnée par l’envoi d’un e-mail vers la boite mail

SAP de ces personnes.

Synthèse des paramétrages du Workflow 4.5.1.

Un Type d’IDoc est associé à un code traitement et un module fonction. C’est au niveau des accords

d’interchange que l’on associe un type de message à un code traitement et un module fonction. Dès la

réception d’un Type d’IDoc, le système lance le code traitement et le module fonction associé pour générer un

document SAP à partir de cet IDoc. Toutes les erreurs qui se produisent pendant le traitement d’un IDoc sont

traitées comme suit :

- Arrêt du traitement de l’IDoc

- Déclenchement d’un événement. Cet événement lance une tâche d’erreur (work item)

- Les agents responsables trouveront cette tâche d’erreur dans leurs boîtes de réception du Workflow

- Un message d’erreur s’affiche lorsque la tâche de travail est traitée

- L’erreur est corrigée dans une autre fenêtre et l’IDoc peut alors être soumis de nouveau à la

transformation

- Si l’erreur ne peut être corrigée, l’IDoc peut être marqué pour la suppression

- Une fois que l’IDoc a été posté avec succès, un événement est déclenché qui met fin à la tâche d’erreur.

La tâche de travail disparait alors de la boite de réception

Le schéma suivant résume le principe de la gestion des IDocs reçus avec un statut d’erreur :

Type d’IDoc : ORDRSP

Code Traitement : ORDR Module Fonction : IDoc_INPUT_ORDRSP

Evénement Déclencheur : INPUTERROROCCURED

Tâche : Envoi d’un mail à un l’agent responsable

ISATIS




Le tableau suivant résume les types d’IDocs dont on souhaite gérer le statut de réception dans chaque

mandant.

AIRBUS - Mandant 150 STG - Mandant 731

ORDRSP Confirmation Commande d’Achat ORDERS Commande d’Achat

DESADV Livraison ORDCHG Modification Commande d’Achat

STPPOD Accusé de Réception Livraison

4.5.1.1. Création du lien entre le code traitement et l’événement déclencheur

Mandant 150 Transaction BD67 Objectif Création du lien entre le code de traitement et l’événement déclencheur Nous avons défini dans les accords d’interchange du fournisseur YSTG que le code traitement de l’ORDRSP est

ORDR. La transaction BD67 permet d’associer un code traitement à un événement déclencheur.

- Exécuter la transaction BD67 et sélectionner le code de traitement ORDR. Nous pouvons constater

que l’ORDR est associé au Module Fonction IDOC_INPUT_ORDRSP : ce module fonction génère un

document SAP (confirmation d’une commande d’achat) à partir de l’IDoc ORDRSP.

- Cliquer sur Détail

- Nous vérifions que le code traitement ORDR, le module fonction IDOC_INPUT_ORDSP et le type d’IDoc

ORDRSP sont liés. Dans le champ Evénement déclencheur vous pouvez choisir l’événement qui va se

déclencher lorsque le traitement de l’ORDRSP par le module fonction IDOC_INPUT_ORDSP génère

une erreur. Dans notre cas, nous avons choisi l’événement INPUTERROROCCURED, c’est-à-dire

l’événement qui se déclenche lorsque l’idoc est en erreur.

ISATIS




4.5.1.2. Association de l’événement déclencheur à une tâche

Mandant 150 Transaction SWE2 Objectif Lier l’événement INPUTERROROCCURED à une tâche d’envoi de mail

- Exécuter la transaction SWE2 et sélectionner la ligne qui contient l’Objet IDOCORDRSP, l’événement

INPUTERROROCCURED ainsi que la tâche standard TS00008075

- Cliquer sur détail

- Cocher la case Lien activé pour créer le lien entre l’événement INPUTERROROCCURED et la tâche

TS00008075

ISATIS




4.5.1.3. Lier la tâche à un agent responsable

Mandant 150 Transaction PFTC Objectif Lier la tâche TS00008075 à un agent responsable. Cet agent va recevoir un mail

dès qu’un ORDRSP génère une erreur

- Exécuter la transaction PFTC et le nom de la tâche Standard 00008075. La chercher avec le match

code, dans le champ Tâche

ISATIS




- Cliquer sur Afficher

- Sélectionner l’onglet événements déclencheurs et double cliquer sur le carré pour le rendre vert ce

qui signifie que la tâche est active

- Aller à Données supplémentaires / Affectation d’agents / Gérer et cliquer sur Créer affectation

agent…

- Choisir le type de l’agent Utilisateur (vous pouvez choisir plusieurs types d’agent) et valider

ISATIS




- Chercher le nom de l’agent responsable

- Le système a ajouté l’agent à la liste des utilisateurs qui vont recevoir un mail dès que l’ORDRSP est en

erreur de réception

4.5.1.4. Ajouter l’agent responsable dans les accords d’interchange

Mandant 150 Transaction WE20 Chemin Menu SAP / Logistique / Logistics Execution / Processus internes aux magasins /

Communication avec systèmes externes / Administration ALE / Options durée d'exécution / WE20 - Accords d'interchange

Objectif Désigner un agent responsable qui va être averti lorsque les messages d’erreurs de Type ORDRSP surviennent

- Exécuter la transaction WE20 et sélectionner le Fournisseur YSTG.

- Double cliquer sur le type de message ORDRSP dans les paramètres de réception des accords

d’interchange.

- Sélectionner l’onglet Post-traitement : agents autorisés

- Entrer le nom de l’agent autorisé à recevoir les messages d’erreurs de ce type de message

ISATIS




4.5.1.5. Vérification de la réception des messages d’erreur de type ORDSP

ISATIS




4.6. Contrôle du statut de l’IDoc dans le système externe

Si le système externe doit informer le système émetteur de la progression du traitement des IDoc qui ont été

envoyés, un message de confirmation de statut est envoyé. Le système émetteur ajoute ensuite les

enregistrements de statut qui ont été reçus à l'IDoc sortant correspondant dans la base de données. Ceci n'est

possible que via le type d'IDoc spécial ALEAUD.

Synthèse des paramétrages 4.6.1.

Pour obtenir le contrôle du statut de l’Idoc dans le système externe, il est nécessaire de :

1. ajouter dans le modèle de distribution AIRBUS_STG et dans les accords d’interchange un nouveau

type d’IDoc (ALEAUD). Ce type d’IDoc permet d’envoyer et de recevoir tous les statuts d’IDocs

échangés entre les deux mandants.

2. Créer une variante d’un programme standard (le programme RBDSTATE) qui envoie au système

émetteur les statuts des Idocs reçus

3. Créer un job qui lance automatiquement et périodiquement (toutes les heures pour la période du

30/07/2013 au 31/12/2013) la variante précédente.

Nous ne présenterons ici que les points 2 et 3 car le point 1 est identique à celui présenté dans les

paragraphes précédents.

En annexe sont détaillés tous les points de paramétrage concernant ALEAUD.

En effectuant ces paramétrages dans le mandant 731, Airbus (mandant 150) recevra toutes les heures

pendant la période paramétrée les statuts des IDocs envoyés à STG (mandant 731), c'est-à-dire les statuts des

ORDERS, ORDCHG et STPPOD.

De la même façon, en effectuant ces paramétrages dans le mandant 150, STG (mandant 731) recevra toutes

les heures et pendant la période paramétrée les statuts des IDocs envoyés à AIRBUS (mandant 150), c'est-à-

dire les statuts des ORDERSP et DESADV.

4.6.1.1. Mandant 150 : Création d’une variante du programme RBDSTATE

Mandant 150 Transaction BDM8 Chemin IMG Menu / Outils / ALE / Administration ALE / Service / Travaux périodiques /

Réception / RBDSTATE Objectif Création d’une variante CONFIR_STG du programme RBDSTATE

- Taper la transaction BDM8 et entrer le nom du programme, le nom de la variante puis cliquer sur

Créer.

ISATIS




- Entrer le nom du système à qui les statuts des IDocs vont être envoyés (P07CLNT731)

- Entrer les trois types de messages dont on souhaite recevoir le statut (ORDRSP et DESADV)

- Entrer la date de modification des IDocs puis enregistrer.

4.6.1.2. Mandant 150 : Création d’un job pour planifier l’exécution de la variante

CONFIR_STG

Mandant 150 Transaction SM36 Objectif Création d’un job pour planifier l’exécution la variante CONFIR_STG

- Exécuter la transaction SM36

- Donner un nom au job (RBDSTATE_STG)

- Choisir le statut A (haute priorité) pour la classe du job

- Cliquer sur Etape.

ISATIS




- Entrer le nom du programme ainsi que le nom de la variante à utiliser et enregistrer.

- Cliquer sur précédent

- Dans Etape du job nous remarquons un nouveau statut (1 étape définie correctement).

- Cliquer sur Condition de lancement.

ISATIS




- Cliquer sur Date / heure

- Entrer la date et l’heure de lancement prévues ainsi que la date et l’heure du dernier lancement.

- Cocher la case Exécuter job périodiquement puis sur le bouton périodicité

ISATIS




- Cliquer sur Ttes les heures comme périodicité puis Enregistrer.

- Pour vérifier que le job a bien été planifié, Exécuter la transaction SM37et chercher le nom du job

RBDSTATE_AIRBUS puis cliquer sur Détails du job.

ISATIS




ISATIS




5. Tests et jeu d’essai

Ce chapitre présente différentes séries de tests qui ont jalonné le projet. Elles sont aux nombres de 3 et

surviennent dans cet ordre :

1. Les tests unitaires pour valider les points paramètrages

2. Les tests d’intégration au moment de l’ajout de la couche EDI sur la couche fonctionnelle pour valider

des séquences de flux

3. La recette client qui valide la solution complète à déployer et marque le go/no go vers la bascule.

5.1. Les tests unitaires

Les tests unitaires ont été réalisés par les porteurs des points de paramétrages pour en valider la pertinence

fonctionnelle. Il n’est ni envisageable ni intéressant de présenter ces tests dans leur intégralité. En revanche,

les tableaux ci-dessous les listent par module. Nous vous invitons à consulter les fichiers de ces tests en

annexes.

Documentation

disponible

MM Données de base Article Création article vues:

- Données de base 1


- ADV Org Comm 1

- ADV Org Comm 2

- ADV Données générales/Div

- Texte ADV

- Div/Stockage 1

- Div/ Stockage 2

- Comptabilité 1

- Comptabilité 2

TU-150-MM-FAR001

X

MM Données de base Article Modifier fiche article TU-150-MM-FAR002 X

MM Données de base Fournisseur Création dans les achats d'un fournisseur TU-150-MM-FOU001 X

MM Données de base Fournisseur Modification dans les achats d'un fournisseur TU-150-MM-FOU002 X

MM Données de base FIA Création d'une fiche info-achat standard TU-150-MM-FIA001 X

MM Données de base FIA Modification d'une fiche info-achat TU-150-MM-FIA002

MM Données de base FIA Suppression d'une fiche info-achat TU-150-MM-FIA003

(*) Tous les tests ont été effectués et ont donné le résultat attendu, mais tous n'ont pas été documentés.

Module

SCENARIO DE TESTS UNITAIRES - DONNEES DE BASE 150

Référence test

(= préfixe du fichier)

LibelléSous-domaineDomaine

Documentation

disponible

SD Données de base Article Création article vues:



- ADV Org Comm 1

- ADV Org Comm 2

- ADV Données générales/Div

- Texte ADV

- Div/Stockage 1

- Div/ Stockage 2

- Comptabilité 1

- Comptabilité 2

TU-731-MM-FAR001 X

MM Données de base Article Modifier fiche article TU-731-MM-FAR002 X

SD Données de base Client Création d'un client TU-731-CLI01 x

SD Données de base FIV Création d'une info-vente TU-731-CLI02 x

SD Données de base Création d'une condition TU-731-CLI03 x

SCENARIO DE TESTS UNITAIRES - DONNEES DE BASE 731

Module Domaine Sous-domaine Libellé Référence test


ISATIS




Documentation

disponible

MM Gestion stocks Mvt stocks Entrée en stock qualité sur commande d'achat standard TU-150-MM-IM001

MM Gestion stocks Mvt stocks Transfert du stock qualité vers stock utilisation libre TU-150-MM-IM002

MM Appro Commande Création d'une commande d'achat TU-150-MM-AP001 x

MM Appro Commande Edition de la commande en PDF TU-150-MM-AP002 x

MM Appro Commande Edition de la commande par EDI TU-150-MM-AP003 x

MM Appro Commande Modification d'une commande d'achat TU-150-MM-AP004

MM Appro Commande Suppression d'une commande d'achat TU-150-MM-AP005

MM Etats Etats appro Liste des commandes TU-150-MM-AP006

MM Etats Etats appro Liste des commandes à confirmer par le fournisseur (Statut AB) TU-150-MM-AP007 x

MM Etats Etats appro Liste des commandes à confirmer par le fournisseur (Statut LA) TU-150-MM-AP008

MM Etats Etats EDI Liste des IDOC ORDERS émis avec statut d'émission TU-150-MM-AP009 x

MM Etats Etats EDI Liste des IDOC ALEAUD reçus pour les ORDERS émis avec statut de

réception par mandant 731

TU-150-MM-AP010

MM Etats Etats EDI Liste des IDOC ORDRSP reçus avec statut de réception TU-150-MM-AP011 x

MM Etats Etats EDI Liste des IDOC ALEAUD émis pour ORDRSP avec statut d'emission TU-150-MM-AP012

MM Etats Etats EDI Liste des IDOC ORDCHG émis avec statut d'émission TU-150-MM-AP013 x

MM Etats Etats EDI Liste des IDOC ALEAUD reçus pour les ORDCHG émis avec statut de


TU-150-MM-AP014

MM Etats Etats EDI Liste des IDOC DESADV reçus avec statut de réception TU-150-MM-AP015

MM Etats Etats EDI Liste des IDOC ALEAUD émis pour DESADV avec statut d'emission TU-150-MM-AP016

MM Appro Reception Création d'une livraison entrante sur commande TU-150-MM-AP017

MM Appro Etats Récupération du numéro d'une livraison entrante créée par EDI TU-150-MM-AP018

MM Appro Reception Consultation d'une livraison entrante créée par EDI TU-150-MM-AP019 x

MM Appro Reception Modification d'une livraison entrante sur commande TU-150-MM-AP020

MM Appro Reception Enregistrement de l'entrée de marchandise en stock qualité TU-150-MM-AP021 x

MM Etats Etats EDI Liste des IDOC STPPOD émis avec statut d'émission TU-150-MM-AP022

MM Etats Etats EDI Liste des IDOC ALEAUD reçus pour les STPPOD émis avec statut de


TU-150-MM-AP023

MM Etats Etats EDI Liste des IDOC émis récéptionnés en erreur TU-150-MM-AP024

MM Etats Etats EDI Gestion des IDocs reçus avec un statut d'erreur TU-150-MM-AP025 x


Référence test


SCENARIO DE TESTS UNITAIRES - ACTIVITE & ETAT 150

Module Domaine Sous-domaine Libellé

Documentation

disponible

SD Vente Commande Création de la commande de vente TU-731-SD001

Etats Etats EDI Récupération du numéro de commande de vente créée par EDI TU-731-SD002 x

SD Vente Commande Visualisation de la commande créée par EDI TU-731-SD003 x

SD Vente Commande Modification de la commande de vente TU-731-SD004

SD Vente Commande Impression de la confirmation de commande par pdf TU-731-SD005 x

SD Vente Flux standard Confirmation de commande par EDI TU-731-SD006 x

SD Etats Etats EDI Liste des IDOC ORDERS reçus avec statut de réception TU-731-SD007 x

SD Etats Etats EDI Liste des IDOC ALEAUD émis pour les ORDERS reçus TU-731-SD008

SD Etats Etats EDI Liste des IDOC ORDRSP émis avec statut d'émission TU-731-SD009 x

SD Etats Etats EDI Liste des IDOC ALEAUD reçus pour ORDRSP avec statut de

réception par le mandant 150

TU-731-SD010 x

SD Etats Etats EDI Liste des IDOC ORDCHG reçus avec statut de réception TU-731-SD011

SD Etats Etats EDI Liste des IDOC ALEAUD émis pour les ORDCHG reçus TU-731-SD012

SD Etats Etats EDI Liste des IDOC DESADV émis avec statut d'émission TU-731-SD013

SD Etats Etats EDI Liste des IDOC ALEAUD reçus pour les DESADV avec statut de

réception par le mandant 150

TU-731-SD014 x

SD Vente Livraison Création de la livraison sortante TU-731-SD015 x

SD Vente Livraison Edition du BL en PDF TU-731-SD016

SD Vente Livraison Edition du BL par EDI TU-731-SD017

SD Vente Livraison Modification de la livraison sortante TU-731-SD018

SD Vente Livraison Enregistrement de la sortie de marchandise TU-731-SD019 x

SD Etats Etats EDI Liste des IDOC STPPOD reçus avec statut de réception TU-731-SD020

SD Etats Etats EDI Liste des IDOC ALEAUD émis pour les STPPOD reçus TU-731-SD021

SD Etats Etats EDI Liste des IDOC émis récéptionnés en erreur TU-731-SD022

SD Etats Etats EDI Gestion des IDocs reçus avec un statut d'erreur TU-731-SD023 x

MM Gestion stocks Mvt stocks Entrée en stock qualité sans ordre de fabrication sur commande

d'achat client (pour simulation fabrication)

TU-731-MM-IM001 x

MM Gestion stocks Mvt stocks Transfert du stock qualité au stock libre TU-731-MM-IM002 x

MM Gestion stocks Mvt stocks Sortie de stock pour expédition (intégration SD) TU-731-MM-IM003


SCENARIO DE TESTS UNITAIRES - ACTIVITE & ETAT 150



ISATIS




5.2. Les tests d’intégration

Les tests d’intégration ont été piloté par le consultant fonctionnel avec en appui les deux consultants

techniques. Ils ont permis de valider les séquences des processus fonctionnels et l’enchainement de ceux-ci

lors de l’ajout de la couche EDI.

5.3. La recette client

Préparée avec le client, réalisée par les utilisateurs clés de l’équipe projet, elle se réalise sur la base d’une

solution pré testée par l’intégrateur et quasiment définitive. Lors de cette dernière étape de tests fonctionnels

sont déroulées les cas de l’activité quotidienne et des cas plus spécifiques.

Nous avons fait le choix de concentrer la recette sur le cœur du projet : mettre un flux fonctionnel sous EDI.

Ainsi, la recette porte sur :

1. le scenario complet achat vente, de la commande achat par Airbus jusqu’à la réception de l’accusé de

réception de livraison par STG, selon différents cas (PREREC-01-A)

2. les états liés à l’activité sous EDI. (PREREC-02-A)

Ci-après les grands axes de la recette, l’intégralité de la recette, étape par étape, étant disponible en annexe.

Recette flux achat vente sous EDI - PREREC-01-A 5.3.1.

Référence

du test

Application

/ module Fonction Scenarii

Décrit par

/ le

Testé par

/ le

Validé par

/ le

PREREC-

01-A MM / SD Flux EDI Flux achat vente

CBE/MMI/FRI

Isatis Consulting,

le 07/08/2013

Beta

08/08/2013

Beta

08/08/2013

Cas de tests

Criti-

cité

1/2/3

Description Commen-

taires / cas

OK

/ KO

PREMIERE PARTIE DU FLUX : COMMANDE D’ACHAT (Mandant 150) ET COMMANDE DE VENTE

(Mandant 731)

Documentation

disponible

MM Achat Flux standard Création commande d'achat TI-150-MM-AP001 x

SD/MM Achat-vente Flux EDI Modification de la date de la commande d'achat TI-MM150-SD731-001 x

SD/MM Achat-vente Flux EDI Vérification de la création automatique de la commande de vente et

confirmation

TU-SD731-MM150-002 x

SD Livraison Flux standard Création de la livraison et édition papier du BL TI-731-SD001 x

SD Livraison Flux EDI Enregistrement de la sortie de marchandise et émission de l'avis de livraison

par EDI

TI-731-SD002 x

SD Réception Flux standard Simulation production TI-731-SD003 x

SD Stock Flux standard Transfert de la marchandise conforme du stock qualité au stock libre TI-731-SD004 x



SCENARIO DE TESTS D'INTEGRATION - PROCESSUS SD & MM (150 & 731)

ISATIS




I .

1

Commande d’achat et

commande de vente

confirmée sans modification

3 Une commande d’achat génère une

commande de vente confirmée en l’état OK

I.

2


commande de vente avec

modification

2

Une commande d’achat génère une

commande de vente confirmée avec

modification dans zone de tolérance

OK

I.

3



modification

2

Idem I.2.a mais le fournisseur confirme

avec modification hors zone de

tolérance

OK

I.

4



modification

2

Idem 1.2.b mais le client renvoie une

commande modifiée qui doit être de

nouveau confirmée

OK

DEUXIEME PARTIE DU FLUX : SIMULATION DE LA PRODUCTION (Mandant 731)

II Entrée de marchandise sans

commande client, en stock

qualité

3

L’entrée de marchandise fait référence

à la commande de vente et génère les

lots et numéros de série

OK

TROISIEME PARTIE DU FLUX : EXPEDITION (Mandant 731) ET RECEPTION (Mandant 150)

II

I

Livraison sortante, envoi avis

de livraison, livraison

entrante,

3

La livraison sortante du fournisseur

(731) se fait sur une commande de

vente, se concrétise - après contrôle

libératoire - par une sortie de

marchandise et l’envoi d’un avis. Ce

dernier créé une livraison entrante côté

client (150), qui est finalisée par une

entrée de marchandise et l’envoi d’un

accusé de réception de marchandise. Le

contrôle qualité clôture le flux.

OK

Recette états d’activité sous EDI - PREREC-02-A 5.3.2.

Référence

du test

Application

/ module Fonction Scenarii

Décrit par

/ le

Testé par

/ le

Validé par

/ le

PREREC-

02-A

MM / SD Flux EDI Etats d’activité

EDI

FRI / CBE/ ABM

Le 07/08/2013

Beta

08/08/2013

Beta

08/08/2013

Cas de tests

Criti-

cité

1/2/3

Description Commen-

taires / cas

OK

/ KO

1 Liste des IDOC 1 Edition de la liste des IDOCS

entrants/sortants

NA OK

2 Identification des IDOC en 1 Edition de la liste des IDOCS NA OK

ISATIS




erreur dans son propre

mandant

entrants/sortants

3 Alerte mail pour IDOC

entrant en erreur

2 Workflow non testable hors agent

destinataire des mails

Nous fournir une liste des Key Users ou

groupes d’utilisateurs qui vont recevoir

et traiter ces messages.

OK

4 Liste des IDOC en erreur

dans l’autre mandant

2 Dans un souci d’offrir un service client

de qualité, STG peut vérifier si les IDOC

qu’il a envoyés ont été reçus et traités

dans le système d’Airbus. Dans le cas

contraire, il peut alerter son client

et/ou réagir. Utile aussi en cas de litige

NA OK

5 Liste des commandes achat

en attente de confirmation

2 Afin de réagir et contacter les

fournisseurs n’ayant pas confirmé dans

les délais (pas de relance automatique)

NA OK

6

Liste des commandes vente à

confirmer au client

1 En plus d’une consultation quotidienne

des nouveaux ORDERS entrant, cet état

permet de ne pas perdre de vue les

postes restant à confirmer (car délai de

2 jours pour confirmer). En attendant la

mise en place d’un query.

Non

satisfaisant.

Query à faire

urgemment

après bascule.

KO

ISATIS




6. Formation

6.1. Formation équipe projet

Une montée en connaissance de l’équipe projet a été réalisée (en interne) au démarrage du projet et a porté

sur les points suivants :

- EDI : approche fonctionnelle et technique, spécificités et paramétrages SAP (cf supports en annexe)

- Méthode de conduite de projet ASAP (cf support en annexe)

Th

ème

Co

de

form

atio

n

(= n

om

du

fic

hie

r)

No

m d

e la

fo

rma

tio

n

Ob

ject

if

Pu

bli

c C

ible

Pré

req

uis

Co

nte

nu

Du

rée

Sup

po

rt

con

sult

able

ED

I

ED

I IS

AT

IS

1

L'EDI pour les nuls !

Apporter une connaissance générale sur l'EDI comme mode de communication entre partenaires clients fournisseurs

Equipe projet

-NA -Introduction aux EDI -Le concept de l'EDI -Les variantes de l'EDI -EDI : cas SAP

0.5j oui

ED

I

ED

I IS

AT

IS

2

L'EDI pour les amateurs !

Présenter les concepts généraux permettant d’établir un lien de communication entre deux systèmes SAP via la technologie IDoc/ALE.

Equipe projet

SD2 & MM2

-Définitions: EDI, Idoc et ALE (suite) -Introduction aux paramétrages EDI

0.5j oui

ED

I

ED

I IS

AT

IS

3A

Les IDoc pour un consultant fonctionnel

Aider notre consultant fonctionnel à traiter les questions de soutien liées aux IDoc

Equipe projet

SD3 & MM3

-Introduction au flux EDI -Terminologies -Les accords d'interchange

0.5j oui

ED

I

ED

I IS

AT

IS 3

B Synthèse de

paramétrages EDI entre STG et AIRBUS

Apprendre à réaliser les paramétrages EDI sous SAP

Equipe projet

SD3 & MM3

-synthèse des paramétrages EDI inter mandant -les étapes de paramétrages connexion EDI inter mandant -les étapes de paramétrages des accords d'interchange - démonstration & cas pratiques

1j oui

Pro

jet

ASA

P

ISA

TIS

1 La méthode

Accelerated SAP

Comprendre la méthode ASAP et l'appliquer en mode projet

Equipe projet

Généralités sur gestion de projet

-Présentation des étapes avec leurs objectifs, travaux à mener et livrables

0.5j oui

ISATIS




6.2. Formation client STG

SAP venant d’être implanté dans la société STG, il n’y a pas lieu de faire de formations « fonctionnelles » sur les

modules SD. En revanche, des formations sur l’EDI, et sur l’impact de la couche EDI sur les processus et

activités existants feront partie de l’accompagnement au changement chez STG.

Le plan s’articule ainsi :

Th

ème

Co

de

form

atio

n

(= n

om

du

fic

hie

r)

No

m d

e la

fo

rma

tio

n

Ob

ject

if

Pu

bli

c C

ible

Pré

req

uis

Co

nte

nu

Du

rée

Sup

po

rt

con

sult

able

ED

I

ED

I ST

G 1

L'EDI, c'est quoi ?

Apporter une connaissance générale sur l'EDI comme mode de communication entre partenaires clients fournisseurs

CPU CPI KU ADV KU entrepôt --> soit 4 p

Aucun Reprise du support équipe Isatis EDI ISATIS 1 avec quelques adaptations. NB : Positionnée au moment des ateliers, cette formation donnera un vernis EDI au K Users

0.5j non

ED

I

FL

UX

ED

I ST

G 2

Utiliser l'EDI pour communiquer avec ses clients

Rendre autonomes au quotidiens les acteurs des flux ventes sous EDI

CPU CPI KU ADV KU entrepôt --> soit 4 p

Pratique des flux fonctionnels sous SD (SD2)

-Impact de l'EDI sur les processus du modules SD -Réception et confirmation commande vente -Expédition et ARL -Etats EDI -Cas pratiques NB : pour les K Users, cette formation est un préalable pour réaliser la recette

0.5j non

ED

I

FL

UX

ED

I ST

G 2

Utiliser l'EDI pour communiquer avec ses clients

Rendre autonomes au quotidiens les acteurs des flux ventes sous EDI

Equipe ADV & entrepôt hors KU --> soit 3 p

Pratique des flux fonctionnels sous SD (SD2)

-Impact de l'EDI sur les processus du modules SD -Réception et confirmation commande vente -Expédition et ARL -cas pratiques NB : Réalisée juste avant la bascule, cette formation sera assurée par les K Users pour leurs collègues

0.5j non

ED

I

PA

RA

ED

I ST

G 3

Paramétrages EDI entre STG et ses clients

Etre autonome pour effectuer les paramétrages afin de travailler en EDI avec de nouveaux partenaires

CPU CPI --> soit 2 p

Maîtrise SD (SD2). Sensibilisation aux paramétrages

Adaptation du support équipe Isatis EDI ISATIS 3b -Présentation de l'EDI sous SAP (IDOC, flux, technique…) -Les étapes de paramétrages connexion EDI inter mandant -Les étapes de paramétrages des accords d'interchange -Synthèse des paramétrages EDI inter mandant -Cas pratiques NB : cette formation sera assurée après « digestion » du changement et parfaite maîtrise des fonctionnalités EDI sous SAP

0.5j non

ISATIS




7. Gestion de projet

7.1. Méthodologie et outils

La méthode ASAP 7.1.1.

La méthodologie suivie pour mener à bien le projet SAP EDI STG est inspirée la méthode Accelerated SAP

propre au projet SAP, sans pouvoir toutefois disposer de la suite d’outils et modèles de l’assistant

d’implémentation interne à SAP. En voici les 5 principales phases telles que décrites par les supports SAP :

Voici comment nous avons adapté cette méthode à notre projet

Etape ASAP

Roadmap Questions essentielles Actions menées Livrables produits

Préparation - En quoi consiste le

projet ?

- Comment allons- nous le

mener ?

- Avons-nous les

compétences ?

- Entretien client pour une macro

identification de ces besoins

- Organiser le projet : le définir,

plannifier, affecter les ressources,

chiffrer, créer les outils….

- Début autoformation EDI et

formation equipe EDI et ASAP

- Synthèse besoins client

- Note de cadrage

- Plan de formation equipe

- 1er supports de formation

EDI et ASAP

Conception - Que doit faire

précisément la solution

à créer ?

- Comment va-t-elle le

faire ?

- Poursuite formation équipe EDI

- Identification des besoins spécifiques

(via ateliers virtuels)

- Itérations de prototype en

incrémentant pour chaque processus

: structure données de bases

processus simplifié processus

enrichi processus élaboré sous

EDI Etats

- Fichiers de conception des

Master Data

- Modélisation des processus

séquencés par actvité

- Fin supports de formation

EDI

Réalisation - Comment faire que ?

- Fait-elle correctement ?

- Comment former le

client ?

- Paramétrages de la solution

- Tests

- Préparation plan formation client

- Guide de parametrage

- Documentation des tests

unitaires et d’intégration

- Plan formation client

Préparation à

la production

- Sommes nous prêt à

baculer ?

- Constitution d’un jeu d’essai pour

recette

- Formation K Users

- Préparation assistance user bascule

- Support recette client

- Modalités et fiche

intervention assistance

Mise en

production Non opérée

ISATIS




Infrastructures et environnements techniques 7.1.2.

7.1.2.1. Infrastructures SAP

L’accès à SAP se fait via un serveur basé en Suisse. Deux mandants différents ont permis de simuler le client et

le fournisseur à mettre en connexion via l’EDI. STG, le fournisseur, est configuré sur le mandant 731 (couleur

violet). Airbus, le client, est configuré sur le mandant 150 (couleur vert).

7.1.2.2. Reconstitution des environnements techniques classiques

Dans chacun des deux mandants, un projet a été créé et les ordres de transports liés au customizing de notre

projet y sont regroupés.

Compte tenu des infrastructures réellement disponibles dans le cadre du projet SAP EDI STG, les

environnements classiques de ce type de projet (Bac à Sable, Développement, Qualification Production)

n’existent pas. En effet, un seul environnement est utilisé mais l’équipe projet s’est efforcée de respecter la

logique des 3 environnements.

Bac à sable : « expérimentations »

1. Les expérimentations EDI ont été réalisées sur les standard ou copie de standard SAP existants

(structures organisationnelles, copie d’articles, copie de partenaires….),

2. Les flux fonctionnels ont été expérimentés sur les deux structures organisationnelles STG et Airbus

mais sur un jeux de datas (articles, partenaires…) « bac à sable »,

3. Une fois les paramétrages EDI maîtrisés d’une part et les données, paramétrages et flux fonctionnels

suffisamment aboutis d’autre part, « une couche EDI » (1) a été ajoutée au fonctionnel (2). Sur cette

base ont été réalisés les ajustements, optimisations et tests unitaires.

Qualification : Pré production

1. Les tests internes sur flux fonctionnels sous EDI ont été effectués sur les deux structures

organisationnelles mais sur un nouveau jeu de données (articles, partenaires..) et paramétrages

préqualifiés en « Bac à sable ».

2. Après optimisations, la recette client a eu lieu sur un nouveau jeux de données propres.

Production :

1. Dans la même logique, un jeu de données optimisé marque le passage en production.

Outils et supports 7.1.3.

Des outils et supports utilisés pour mener à bien ce projet ont été prévus pour travailler de façon efficace et

fiable en gérant la contrainte de distance entre les membres de l’équipe projet. Les voici :

- Espace projet Dropbox : 100% des documents projets sont stockés et partagés sur un espace

collaboratif Dropbox, répertoire « projet SAP ». Arborescence des répertoires créé par FRi, à

respecter. Version obsolète (et datées) des fichiers à placer dans les répertoires « archive ». Copie de

sauvegarde hebdomadaire de Dropbox par FRi. Paramètres de configuration manuelle du serveur

proxy sur TB pour accès depuis CESI

- Tableau de bord projet (TB) : fichier Excel de référence pour le suivi des tâches, relevé des décisions,

traitement des points durs, risques, contact équipe, mini charte projet, identifiants ….

ISATIS




- Boite à outil communication : téléphone, mail, Skype pour conf call équipe, Anymeeting pour partage

d’écran

- Matrices document projet disponibles sur Dropbox

- Réunions projet Skype hebdomadaires voire bihebdomadaires si besoin pour pilotage au plus près du

projet et de l’’équipe.

7.2. Planning de mise en oeuvre

7.3. Budget

Rappelons que :

- la mise en place de l’EDI s’appuie sur une solution SAP très récemment mise en place

- les échanges de données se feront via les connexions internet déjà existantes (et suffisamment

calibrées)

- les échanges de données se feront en direct vers les clients sans passer par un tiers prestataire.

En conséquence, le budget du projet est composé exclusivement de la prestation d’intégration d’Isatis. Par

ailleurs, cette nouvelle fonctionnalité donnera lieu à un ajustement de 5% du forfait annuel « maintenance et

hotline »

ISATIS




Etapes 1, lot 1.1 Nombre de

jours homme

Coût

Préparation projet

dont entretiens besoin client

dont formation préalable équipe projet

20j 6000€

Analyse et conception

dont ateliers protypage

46j 13800€

Réalisation

Dont préparation formation client

26j 7800€

Préparation à la production

Dont formation client

8j 2400€

Production

Dont assistance rapprochée au démarrage

8j 2400€

Suivi Projet

10j 3000€

Global Projet

118j 35400€

7.4. Gestion des risques

Une évaluation des risques pouvant mettre en péril le projet a été mené au démarrage du projet. Le critère de

criticité d’un risque est un mix de la probabilité de vérification et de la gravité des conséquences s’il survient.

Nous nous sommes attachés à prévenir ces risques et anticiper d’éventuelles solutions de repli si nous devions

être confrontés au risque.

Par souci de lisibilité, certaines colonnes du tableau ci-dessous ont été masquées. (Tableau à retrouver en

annexe dans le « tableau de bord projet » dans le répertoire « best of des livrables projets »)

Evaluation des risques au 10/08/2013

Risque identifié

Description Effets, impacts

Criticité %

Mesures préventives éventuelles

Mesure correctives prévues si le risque se réalise

Statut du

risque

Equipe junior SAP

Les membres de l'équipe projet sont juniors sur SAP

Perte de temps en formation et fausses routes --> dérive temps

36% Partage de la connaissance. Echange entre les membres de l'équipe, (binômes), points réguliers pour avancement Recherche d'informations extérieures : cours, tuto, sites communautaires, ….

Si blocage, création d'un point dur. Concertation pour partage du problème, définition plan d'action, suivi actif. Dernier recours : MQT

En cours

Equipe junior EDI

Les membres de l'équipe projet sont novices sur EDI

Perte de temps en formation et fausses routes --> dérive temps

36% Une personne dédiée dès le début du projet à s'auto former sur l'EDI afin de former l’équipe ensuite


En cours

ISATIS




Faible disponibilité des membres

Les membres mènent ce projet en dehors de leur travail ou cours.

Retard ou surchauffe de l'équipe

48% Au moins un point équipe projet hebdo sur avancement. Mis en place binômes de soutien. Travail sur espace collaboratif exclusivement. Périmètre défini et à respecter. Arbitrage CP si besoin

Relais par le binôme sur les tâches en cours.

En cours

Ressources éparses

les membres ne sont pas sur le même site

Difficultés de partage d'information et documents

32% Mise en place d'outils collaboratifs sur le net : espace de partage DropBox, réunion Skype, Anymeeting pour partage d'écran

Maitrisé

Perturbation du mandant par personnes extérieures au projet

Création de paramétrages parasites ou modification des nôtres par des Tiers

Blocage ou altération

48% Regrouper les ordres de transports dans un projet? Documenter les points de paramétrages afin de pouvoir les refaire. Dans la mesure du possible, créer des données propres au projet


En cours

Sécurisation des données pilotage

Perte des fichiers projets

Perte historique et Redémarrage à 0

32% Copier-coller dans répertoire "archives" les versions antérieures des fichiers. Copie de sauvegarde hebdomadaire

Kleenex Maitrisé

Suppression connexions inter mandant et blocage accès mandant 150

Impossibilité de faire dérouler un flux achat - vente complet

Pas de recette client Pas de démo pour soutenance

60% risque avéré Batailler pour récupérer les accès même temporairement Reconstituer un PPS qui déroule un flux à partir des captures d'écrans des tests

En cours

ISATIS




8. Bilan et retour d’expérience

Les informations rapportées dans les paragraphes ci-après sont une synthèse d’un tour de table effectué avec

l’équipe projet.

8.1. Compétences acquises

De façon indéniable, nous avons tous vécu une montée en connaissances et compétences fonctionnelles sur les

modules SD et MM de SAP mais également sur l’EDI. De manière plus ciblée, le paramétrage « en vrai » fera

partie des acquis.

Des heures d'expérimentation, de création, voire d'errance et de retour au point zéro aussi, dans les

transactions et le SPRO des mandants 150 et 731, sacrément formatrices ! Des heures passées sur « Google est

mon ami » et les supports SAP à comprendre comment fonctionne l’EDI afin de transmettre la bonne parole

aux collègues.

Même si nous le pensions avant le démarrage SAP (cours et projet), nous avons touché du doigt le fait que SAP

est une machine de guerre extrêmement puissante qui nécessite des réglages d'une finesse extrême. Et cela

s’applique en particulier à l’EDI où l’automatisation des processus est poussée assez loin. Et nous l’avons

appris deux fois à nos dépends !

Ce projet a aussi été l’occasion de découvrir la démarche ASAP, même si nous n’avons pu la suivre qu’en

partie. Mais ce qui restera le plus du point de vue « projet », c’est la création et l'utilisation d'outils de pilotage

pragmatiques en mode partage qui ont été optimisés tout au long de l’aventure.

Nul doute que ces compétences et ce vécu seront exploitables et exploités dans un futur proche !

8.2. Retour d’expérience

Une des difficultés pour mener ce projet a été la nécessité qu’acquérir du savoir sur l’EDI. Au début du projet

l'EDI était un sujet complétement nouveau pour nous. Nous avons consacré une partie de notre temps à

chercher les bonnes informations et les mettre en pratique. Avec le temps, et grâce aux échanges d'idées et

d'expériences que ce soit avec les membres de notre groupe, avec Mickaël Quesnot ou pendant les pauses café

de nos stages, nous avons réussi à structurer les différentes pièces du puzzle de notre projet et à rendre

l'image floue de l'EDI de départ de plus en plus claire...

D’une façon globale, nous avons eu le sentiment de gérer plusieurs projets en un : concevoir et paramétrer une

structure organisationnelle, concevoir et paramétrer un flux fonctionnel, paramétrer les échanges et

superposer le tout. Et ce, sur deux mandants, l'un pour Airbus, l'un pour STG.

Tous d'un naturel curieux et exigeants, définir un périmètre traitable en 3 mois et laisser de côté certaines

fonctionnalités (programme de livraison, facturation…) et travaux (query…) a généré des frustrations. Et il a

fallu se faire violence pour dire "non, on ne fait pas cela" sinon cela se fera au détriment de la qualité des

livrables. Il y a fort à parier que certains reviendront se promener sur nos chers mandants après le 17 octobre

(NDLR : si on veut bien nous laisser y entrer !)

ISATIS




8.3. Conclusion

Ce projet SAP a été une vraie expérience professionnelle et humaine. Nous l’avons tous vécue avec implication

et application et ce, en faisant avec les contraintes de temps, la thèse, nos petites familles…

Au final, nous sommes fiers d'avoir livré une solution pertinente, aboutie et opérationnelle, nous sommes fiers

d’avoir appris.

En complément à la richesse des cours de Mickaël Quesnot, ce projet nous autorise à ajouter la ligne SAP à nos

CV, certes avec une étendue de compétences à affiner selon chacun. Mais nous gardons tous en tête que la

route SAP est encore longue...

Pour certains membres de l'équipe, ce projet et les compétences SAP acquises sont un jalon clé dans le

parcours professionnel ciblé : consultant SAP. Pour d'autres, ce projet, via la pratique SAP et une nouvelle

expérience projet, renforce la culture ERP et sera un vécu de plus pour accéder à terme à des fonctions de chef

de projet ERP.

ISATIS




Arborescence des annexes sur le répertoire « 99 Espace jury »

0 Rapport de cadrage

RAPPORT DE CADRAGE PROJET SAP EDI STG V3.docx

3 Parametage SAP

00 Liste points de parametrage.xlsx 3.1 SAP Organisation structurelle

01 Paramétrage structures organisationnelles.docx 3.2 SAP Master data -Codification

02 Codifications.docx 3.3 SAP Types de documents

03-a Paramétrages documents de flux - types de documents.docx 03-b Paramétrages documents de flux - Détermination des messages d'édition.docx 03-c Paramétrages documents de flux - Pilotage texte et mise en forme.docx

3.4 SAP Connexions EDI 04 Paramétrages Connexion EDI.docx

3.5 SAP Etats EDI 05 Paramétrages Etats EDI.docx

4 Tests

Scenario des tests projet SAP EDI STG.xls 4.1 Tests unitaires

TU-150-MM-AP001 Création commande d'achat X.docx TU-150-MM-AP002 Edition commande PDF.docx TU-150-MM-AP003 Edition commande EDI.docx TU-150-MM-AP009 Liste des IDOC ORDERS émis avec statut d'émission.docx TU-150-MM-AP011 Liste des IDOC ORDRSP reçus avec statut de réception.docx TU-150-MM-AP025 Gestion des IDocs reçus avec un statut d'erreur.docx TU-150-MM-FAR001 Création fiche article.docx TU-150-MM-FIA001 – Création fiche info-achat.docx TU-150-MM-FOU001 Création fournisseur.docx TU-731-CLI01 Création Client.docx TU-731-CLI02 Création Fiche info-vente.docx TU-731-CLI03 Création d’une condition de prix CE NEST PAS UN TU.docx TU-731-MM-FAR001 Création fiche article.docx TU-731-MM-IM001 Entrée en stock qualité sans ordre de fabrication sur cde d'achat.docx TU-731-MM-IM002 Transfert du stock qualité au stock libre X.docx TU-731-SD004 Modification de la commande de vente.docx TU-731-SD005 Impression de la confirmation de commande par pdf.docx TU-731-SD006 Confirmation de commande par EDI.docx TU-731-SD007 Liste des IDOC ORDERS reçus avec statut de réception.docx TU-731-SD009 Liste des IDOC ORDRSP émis avec statut d’émission.docx TU-731-SD010 - Liste IDOC ALEAUD reçus pour ORDRSP avec statut réception par 150.docx TU-731-SD014 - Liste IDOC ALEAUD reçus pour DESADV avec statut réception par 150.docx

TU-731-SD015 Création de la livraison sortante X.docx TU-731-SD016 Edition du BL en PDF.docx TU-731-SD017 Edition du BL en EDI.docx

ISATIS




TU-731-SD023 Gestion des IDocs reçus avec un statut d'erreur.docx 4.2 Test integration

TI-150-MM-AP001 Création commande d'achat.docx TI-731-SD001 Création de la livraison et édition papier du BL.docx TI-731-SD002 Enregistrement sortie de marchandise et émission avis de livraison par EDI.docx TI-731-SD003 Simulation production.docx TI-731-SD004 Transfert de la marchandise conforme du stcok qualité au stock libre.docx TI-MM150-SD731-001 Modification de la date de la commande d'achat.docx TU-SD731-MM150-002 Vérification création automatique cde vente et confirmation.docx

4.3 Scenario flux fonctionnels recette PREREC-01-A Isatis - Precette flux projet EDI STG ok.docx PREREC-02-A Isatis - precette etats projet EDI STG ok.docx

5 Plan et supports de formation

5.1 Plans de formation plan de formation.xlsx

5.2 Supports de formation ASAP ISATIS 1.pdf EDI ISATIS 1.pdf EDI ISATIS 2.pdf EDI ISATIS 3A.pdf EDI ISATIS 3B.xlsx

9 best of livrable equipe projet Isatis- synthèse entretiens recueil besoins projet SAP EDI STG v4 liv.docx Tableau de bord projet SAP EDI STG.xlsx

Planning SAP EDI STG V2.png Note de cadrage projet SAP EDI STG.docx

projet sap edi stg -...

Documents