Normes Et Standards de Développement - V3

Futura Normes et Standards
de
Finances
Développement
Normes et
standards de
développementNor
mes et standards
de développement
Normes et standards de développement - 1 / 32 -

de
Finances
Développement
Sommaire
1. ENVIRONNEMENT SAP..............................................................................................4
2. CLASSE DE DÉVELOPPEMENT...............................................................................5
3. ORGANISATION DE LA DOCUMENTATION........................................................6
3.1 NUMÉROTATION DES DÉVELOPPEMENTS........................................................................7
3.1.1 Organisation...........................................................................................................7
3.1.2 Tranches de numéros..............................................................................................7
3.2 DOSSIER D'ANALYSE......................................................................................................8
3.3 DOSSIER DE TEST...........................................................................................................8
3.4 DOSSIER DE VALIDATION.............................................................................................10
4. CODIFICATION DES OBJETS SAP........................................................................11
4.1 OBJETS DU DICTIONNAIRE............................................................................................11
4.2 PROGRAMMES ABAP...................................................................................................13
4.3 AUTRES........................................................................................................................14
5. NORMES DE DÉVELOPPEMENT...........................................................................15
5.1 DOCUMENTATION DES PROGRAMMES..........................................................................15
5.1.1 Cartouche des programmes ABAP.......................................................................15
5.1.2 Documentation du programme :..........................................................................16
5.1.3 Commentaires sur les variables...........................................................................17
5.2 STRUCTURE DU PROGRAMME.......................................................................................18
5.2.1 Organisation du programme................................................................................18
5.2.2 Déclarations des données.....................................................................................19
5.2.3 Routines................................................................................................................21
5.2.3.1 Définition..................................................................................................................................................21
5.2.3.2 Règle de nommage....................................................................................................................................21
5.2.3.3 Exemple d’appel et de déclaration.............................................................................................................21
5.3 CODIFICATION DES VARIABLES....................................................................................22
5.3.1 Paramètres...........................................................................................................22
5.3.2 Options de sélection (SELECT-OPTIONS)..........................................................22
5.3.3 Tables internes......................................................................................................22
5.3.4 Structures..............................................................................................................23
5.3.5 Variables de travail..............................................................................................23
5.3.6 Constantes............................................................................................................23
5.4 INSTRUCTIONS..............................................................................................................24
5.5 ACCÈS À LA BASE DE DONNÉES...................................................................................25
5.6 PERFORMANCES...........................................................................................................26
5.7 PRÉSENTATION DES ÉTATS...........................................................................................27
5.7.1 Couleurs...............................................................................................................27
5.8 MESSAGES....................................................................................................................27
5.8.1 Classes de messages.............................................................................................27
5.8.2 Numéros de messages...........................................................................................28

de
Finances
Développement
5.8.3 Types de messages................................................................................................28

5.8.4 Utilisation..............................................................................................................28

de
Finances
Développement
1. Environnement SAP
Chez NOZ, trois environnements distincts existent :

 Dev : développement et tests unitaires
 QAS : Recette interne et utilisateur
 Production : données réelles.
Aucun objet ne doit être modifié directement dans les environnements de production ou de
recette (QAS).
Toutes les créations, modifications ou suppressions d’objets SAP doivent avoir lieu
sur l’environnement de développement.
Lors de ces actions, les objets impactés doivent être mis dans des ordres de transport (OT).
Le lien entre les différents environnements se fera par l’intermédiaire de ces OTs lors du
transport, via les transactions SE01 et STMS.
SAP
Réplication des données
DEV QAS PROD
OT OT
Création, suppression,
ou modification
d’objets ABAPs
Dans un environnement SAP, plusieurs mandants peuvent coexister. Le mandant est une
séparation logique des bases de données à l’intérieur d’une installation du système SAP.
Ainsi, entre les mandants d’un même environnement, un certains nombre de données sont
partagées (on qualifie ces données d’ « inter-mandant »).
La plupart des objets techniques sont « inter-mandant » (programmes, écrans, …) à
l’exception des textes (y compris ceux des formulaires SAPSCRIPT).
La plupart des données des tables sont « mandant dépendant », c'est-à-dire que l’on ne
retrouvera pas les même données dans les tables, d’un mandant à l’autre (par ex : EKKO).
Ce système de mandant est surtout utilisé dans les environnements de développement ou
de recette (mandant « référence paramétrage », mandant « bac à sable », …)

de
Finances
Développement
Chez NOZ, les mandants ne sont pas ou très peu utilisés. Il y en a des différents seulement
en dèv, mais seul le mandant 300 est utilisé.
2. Classe de développement
Lors de sa création, un objet SAP (programme ou élément du DDIC) peut être rattaché
 Soit à la classe dite d'objets locaux privés (appelés $TMP : objets temporaires),
 Soit à une classe de développement.
Les objets locaux privés ne peuvent pas être transportés d'un environnement à un autre. Ils
sont donc présents uniquement dans l'environnement dans lequel ils ont été développés. Ce
sont, en général, des objets ABAPs qui sont employés pour effectuer les tests temporaires.
Les objets destinés à être livrés en recette puis en production sont à rattacher à une classe
de développement. En effet, la classe de développement possède un chemin de transport.
Donc l'affectation d'un objet à une classe de développement entraîne la création d'un ordre de
transport (voir par ailleurs) vers un environnement cible.
Sont rattachés à une même classe de développement des objets ayant tous une
caractéristique commune. Chez Futura Finances la classe de développement ZFUTURA
contient les objets spécifiques.
3. Organisation de la documentation
Actuellement, la documentation est …

de
Finances
Développement
De la sorte, il est aisé de retrouver un document, quel qu'il soit (analyse détaillée, dossier de
test, abap, document de validation …), en fonction du numéro identifiant.
De plus, l'organisation des documents est fortement dépendante du module auquel un

développement s'applique.
Voici le dossier contenant tous les documents utiles :

\\fichier_serv1\Informatique\01 - DOCUMENTS ETUDES\02 - SAP
La plupart des spécifications détaillées d’évolution se trouvent néanmoins dans le dossier

suivant: \\fichier_serv1\A_Tous\10 - Service Informatique

de
Finances
Développement
3.1 Numérotation des développements
On appelle 'développement' une réalisation informatique de nature :

- programme de reprise
- interface
- état spécifique
- formulaire
- etc…
3.1.1 Organisation
Chaque nouveau développement se voit attribuer un numéro de 6 chiffres qui l'identifie. Ce

numéro servira de référence pour les noms des analyses détaillées.
L'attribution des numéros de développement est effectuée par le chef de projet SAP, avec
l'appui de la transaction Z_NUM_DEV.
Les numéros de développement sont donc réservés dans une table SAP.
Les trois premiers chiffres correspondent au périmètre du développement.

Les trois derniers chiffres sont incrémentés pour rendre le numéro unique.
3.1.2 Tranches de numéros
Le numéro identifiant est codé sur 3 caractères, par tranche de 100. La tranche est désignée en
fonction du module auquel le développement s'applique :
Tranche Désignation
000 Achat Marcketing
001 Transport
100 Logistique
200 Administration des ventes
300 Comptabilité
400 contrôle de gestion
500 Ressousrces humaines
600 Expansion Traveux
700 Informatique
800 France invendu – HUB
900 Juridique - Qualité

de
Finances
Développement
3.2 Dossier d'analyse
Le nom de l'analyse détaillée est codifié de la sorte :
Position Code et signification

1 'D'
2-5 Numéro du développement informatique
6 '-'
7 'A'= Analyse
8 Version de l'étude détaillée
Il y a un changement de version dès lors qu'une version a été transportée dans l'environnement
de production et qu'elle fait l'objet d'une modification. Toute modification doit apparaître
clairement dans l'étude détaillée, avec les renseignements suivants :
- Qui demande la modification (utilisateurs, intégrateurs, informatique…) ?
- A quelle date?
- Sur quoi porte la modification (règle de gestion, d'exploitation, bug …)?
3.3 Dossier de test
Les dossiers de tests ont pour but de recenser les unitaires réalisés pour un développement.
Les dossiers de test doivent être effectués par chaque analyste/développeur pour tout
programme réalisé ou modifié.
Ils doivent s'assurer que le développement est conforme aux spécifications de l'étude détaillée,
et qu'il traite tous les cas anormaux.
Le dossier de test suit un modèle prédéfini (en annexe). La première page est une fiche
récapitulative des tests réalisés. Les pages suivantes contiennent un descriptif des tests réalisés
avec les éléments permettant de vérifier chaque test (extraits de fichiers, copies écrans, listes,
…). Les dossiers de test peuvent être rédigés de manière manuscrite (excepté la première
page).
Le nom de dossier de test est codifié de la sorte :

1 'D'
6 '-'
7 'T'= Test
8 Version de l'étude détaillée pour laquelle le dossier de test s'applique

de
Finances
Développement
Le numéro de version du dossier de test est identique au numéro de version de l'étude

détaillée à laquelle il se réfère. Si la version de l'étude est supérieure à 1 le dossier de test ne
doit comprendre que les tests de modification entre la version N et la version N-1 de l'étude
détaillée.

de
Finances
Développement
3.4 Dossier de validation

Le document de validation a pour but de valider un développement informatique, avant de le
transporter dans l'environnement de production.
La validation est prononcée par le chef de projet SAP, en accord avec l'utilisateur concerné ou
bien un représentant de l'équipe d'intégration. La validation doit être effectuée dans
l'environnement d'intégration avec des données de paramétrage identique à celles de
l'environnement de production.
La production d'un développement suit tous les points décrits dans l'étude détaillée.
La codification d'un document de validation est la suivante :

1 'D'

6 '_'
7 'V'= Validation
8 Version de l'étude détaillée pour laquelle la validation s'applique

de
Finances
Développement
4. Codification des objets SAP
Le but de ce chapitre est de définir les conventions de notation pour les objets SAP tels les
programmes, les éléments du dictionnaire de données, les codes transaction, …
Le but d'une codification est de conserver un environnement homogène et logique. Elle

facilite le développement d'application ou de programme.
4.1 Objets du dictionnaire

On appelle objet du dictionnaire de données tout objet pouvant être consulté par la transaction
SE12 (menu Outils/Abap 4 Workbench/Développement/Dictionnaire).
OBJET CODIFICATION
TABLES Les tables permettent de stocker des enregistrements répondant à une
certaine structure. Le premier champ d'une table créée manuellement est
toujours le mandant (élément de donnée MANDT)
Les champs d'une table doivent posséder un libellé précis. Notes : le

libellé d'un champ est rapatrié de son élément de donnée.
La codification d'une table est la suivante :

1 Z
2… Description significative
Exemple : ZCENTRE_COUT
STRUCTURE Les structures sont identiques aux tables mais aucun enregistrement ne
peut y être stocké. Elles servent principalement pour décrire des structures
complexes de fichiers. La codification des structures est identique à celles
des tables
1 Z
TABLES DE Tables de correspondance : par exemple Z001
CONTROLES
1 'Z'
2-4 ‘XXX’
VUES Une vue est une combinaison des zones d'une ou plusieurs tables .La
codification des vues est identique à celles des tables. La création de vues
n'est pas envisagée.
1 Z
ELEMENT DE Un élément de données permet de mettre en forme un domaine dans un

de
Finances
Développement
OBJET CODIFICATION
DONNEES contexte particulier (utilisation dans une table).
Il fait donc référence à un domaine .La désignation d'un champ d'une
table.
La codification d'un élément de données est la suivante :
1 'Z'
2-6 XXXXX=désignation sur cinq caractères
DOMAINE Le domaine définit les caractéristiques d'un champ d'une table.
Il est définit par un format (caractère, numérique, nombre de décimal), une
longueur et éventuellement une plage de valeurs possibles.
La codification d'un domaine est la suivante :

1 'Z'
2-6 XXXXX=désignation sur cinq caractères
MATCHCOD Les matchcodes sont des outils permettant la recherche accélérée
ES De l'enregistrement d'une table Master Data, en fonction de critères autres
que sa clé. Ils sont appliqués à certains champs des transactions et se
matérialisent par un bouton pressoir à droite du champ.
La codification d'un matchcodes est la suivante
1 'Z'
2-3 XX=nom du module auquel le matchcode
se rattache (MM, PP, SD, FI, autre)
4 N= compteur incrémenté de 1 lors de la
création d'un matchcode rattaché à un
module.
Les identifiants de matchcode sont numérotés de 0 à 9 (tranche autorisée

par SAP )
La création d'objets spécifiques doit être contrôlée et évitée dans la mesure du possible. Si des
objets standards peuvent répondre à un besoin, il est préférable de les utiliser (valable
particulièrement pour les domaines et les éléments de données).
Les tables spécifiques sont crées dans le but :
- d'établir des règles de correspondance
- de stocker des données spécifiques non géré par SAP
- de décrire des structures de fichiers…

de
Finances
Développement
4.2 Programmes ABAP
L'ABAP/4 (Advanced Business Application Programming) est le langage de programmation

du progiciel SAP R/3. C'est un langage de 4ème génération, il inclut donc des notions de
programmation évènementielle. La transaction pour créer, modifier ou afficher un Abap est
laSE38 ou la SE80.
Toutes les transactions de SAP sont développées suivant les types de traitement .
On s'efforcera donc de faire apparaître cette notion dans le nom des Abaps. On fera également
apparaître le numéro de développement auquel l'Abap fait référence.
OBJET CODIFICATION
ABAP
1 'Z'
2 Type de traitement :
'R' = Reprise
'E' = interface Entrante
'S' = interface Sortante
'L' = Liste, Liste interactive
'M' = Mise à jour
'F' = gestion de Formulaire
'I' = Include
'Y' = Utilitaire
'Z' = Programme one-shot
3-8 NNNNNN = numéro de développement
auquel l'Abap se réfère
9 '_'
10 et + Descriptif
Suffixe _TOP pour un include de déclaration de
données
_F01, _F02, … pour un include de
déclaration de routine, module, macro,
classes, …

de
Finances
Développement
4.3 Autres
OBJET CODIFICATION
FORMULAIRE Les formulaires désignent tout modèle de correspondance
édité avec l'aide des outils Sapscript. Un grand nombre de
formulaires standards existent, qui sont là en tant que modèle
de référence.
1-2 'Z'
3-16 Libellé explicatif libre
Exemple : Un formulaire ayant pour but d'éditer les
règlements fournisseurs par chèque se nommera 'Z
REGLEMENT _C', car 'C' représente le mode de paiement
'Chèque'.
CODES TRANSACTIONS Les codes transactions, auxquels sont rattachés un
programme ou un dynpro, sont codifiés de la sorte
1 'Z'
2-3 XX= nom du module auquel le code transaction
s'applique
4 Compteur incrémenté de 1
DOSSIERS DU BTCI A définir
JOBS A définir (inclure mention de périodicité)

de
Finances
Développement
5. Normes de développement
5.1 Documentation des programmes
Dans le but d'améliorer la lisibilité, la compréhension et la maintenabilité des programmes, de

nombreux commentaires seront insérés dans les Abaps.
Les commentaires doivent être systématiques et efficaces .Ils se matérialisent par une étoile '*'
au début d'une ligne de code (ou une double cote ″ en cours de ligne). Les commentaires sont
affichés en surbrillance dans un abap, ce qui les fait ressortir des lignes de code.
5.1.1 Cartouche des programmes ABAP
Le premier commentaire d'un programme est son en-tête. Elle doit faire apparaître les
informations suivantes :
- Le nom du projet
- L’objet du programme (brève description)
- La référence aux spécifications
- Le domaine SAP
- La version du programme
- L’auteur du programme
- La date de création
- La date de validation
- L’historique des modifications
L’utilisation du modèle de code « cartouche » est recommandée.

de
Finances
Développement
5.1.2 Documentation du programme :
Pour tout nouveau programme, le remplissage de la documentation SAP associée est

obligatoire.
Lorsque le programme est en modification, la documentation l’est aussi.

Lorsque le programme est en affichage, la documentation est visualisable.
Bien évidement, plus la documentation est exhaustive, plus la maintenance de ce programme
est facilitée.
Voici un exemple de documentation :

de
Finances
Développement
5.1.3 Commentaires sur les variables
Chaque paramètre, select-option, table interne, structurez ou variable doit posséder un

commentaire explicatif qui indique sa nature, son contenu, et autres renseignements si cette
zone possède un rôle déterminant dans le programme.
Exemple :
Ou :

de
Finances
Développement
5.2 Structure du programme
5.2.1 Organisation du programme
De manière générale, un programme doit être le plus structuré possible, ce qui facilite sa
maintenance. Les différents éléments d’un programme doivent donc être organisés de manière
logique. Voici une liste non exhaustive de ces éléments :
 Nom du programme : Tout programme exécutable commence par le mot clé

« REPORT » suivit du nom du programme (§4.2). Le mot clé peut être complété par
des options (« MESSAGE-ID », « LINE-SIZE », …)
 Déclaration des données : voir §5.2.2

A faire dans un include dédié (TOP)
 Ecran de sélection : voir §5.2.2

A définir dans le même include que la déclaration des données
 Déclaration des routines : voir §5.2.3

Toutes les routines doivent être déclarées dans un include dédié (F01).
 INITIALISATION (facultatif) :
Evènement permettant l’initialisation des données avant le début du
déroulement du programme
 AT SELECTION-SCREEN… (facultatif) :
Evènement permettant les traitements de l’écran de sélection.
 START-OF-SELECTION :
Les sélections dans les tables SAP sont à faire, dans la mesure du possible,
après cet évènement.
 END-OF-SELECTION :
Le traitement à partir des données sélectionnées se trouve après cet évènement.
 TOP-OF-PAGE (facultatif) :
Evènement délimitant un bloc de traitement n’intervenant qu’au moment de
l’écriture d’une liste ou d’un compte-rendu, à chaque début de page.
De manière pratique, permet, par exemple, de mettre un en-tête sur chaque
page.

de
Finances
Développement
 END-OF-PAGE (facultatif) :
Même usage que le TOP_OF_PAGE, mais en fin de page.
Voici un exemple de structure de programme :
5.2.2 Déclarations des données
Toutes les déclarations d’objets globaux doivent être faites dans un programme include (TOP)
et regroupées par types, comme suit :
 includes standards et pool de types
 Tables : Cette instruction permet de déclarer une table avec un work-area du même
type qu’une table de base de données. A utiliser le moins possible.

de
Finances
Développement
 Types
 Types de table : la déclaration de tables avec header-line est proscrite, car obsolète
(mot clé « OCCURS »).
 Tables internes
 Structures
 Variables :
Il est toujours préférable d’utiliser le mot clé « TYPE » plutôt que « LIKE », si c’est
possible. De même, Il est préférable que le type soit un élément de donnée ou un
domaine du DDIC.
 Field-symboles
 Constantes
 Ecran de sélection

de
Finances
Développement
5.2.3 Routines
5.2.3.1 Définition
Les routines sont des sous-objets de programmation d’un programme ABAP qui peuvent être
utilisées autant de fois que nécessaire. Elles n’ont pas d’existence propre, ce sont des éléments
d’un report, leur activation dépend donc de l’objet qui les contiennent (report, pool de
module, include).
Les routines répondent à une syntaxe de définition et d’appel. Elles peuvent recevoir des
arguments du programme principal pour les utiliser ou les modifier (variables, tables,
structures, …).
Attention : tous les éléments définis à l’intérieur d’une routine, n’existent que durant
l’exécution de cette routine et ne sont accessible qu’à l’intérieur de la routine.
La routine est définie entre les mots clés « FORM » et « ENDFORM » et est appelé via le mot
clé « PERFORM ».
Il existe trois types d’arguments pour une routine :

 Ceux qui sont utilisés dans la routine, mais non modifiés. Mot clé associé « USING »
 Ceux qui sont modifiés dans la routine. Mot clé associé « CHANGING »
 Les tables internes. Mot clé associé « TABLES »
5.2.3.2 Règle de nommage
Pur une meilleur maintenance des programmes ABAP, Un préfixe est apposé au nom de la
routine, suivant le niveau d’appel de cette routine.
 Si la routine est appelée dans le corps du programme (routine de premier niveau) les
préfixes suivant sont utilisés (suivant l’ordre d’appel) : f100_, f200_, f300_ …
 Si la routine est de deuxième niveau (appelée à l’intérieur d’une routine de premier
niveau) alors les préfixes suivant sont utilisés : f110_, f120_, f130_, … (ou f210_,
f220_, f230_, …)
 Si la routine est de troisième niveau, les préfixes sont : f111_, f112_, f113_, … (ou
f341_, f342_, f343, …)

de
Finances
Développement
 Enfin, si la routine est appelée dans plusieurs niveaux différents dans le programme,
alors son préfixe sera f000_.
5.2.3.3 Exemple d’appel et de déclaration

de
Finances
Développement
5.3 Codification des variables
5.3.1 Types
Les types sont utilisés pour définir d’autres données comme les structures ou les types de
tables ; elles se codifient comme suit :
POSITION CODES ET SIGNIFICATIONS
1-3 'TY_'
4--- descriptif de la table interne
5.3.2 Types de table

Les types de table sont utilisés pour définir des tables internes ; elles se codifient comme suit :
1-3 'TT_'
4--- descriptif de la table interne
5.3.3 Paramètres du programme
Les paramètres en entrée d'un programme se codifient comme suit :

1-2 'P_'
3-7 Nom explicatif sur 5 caractères .Si une zone
SAP équivalente existe, reprendre le nom de
cette zone.
Exemple : un paramètre contenant le nom d'un
pays se nommera P_LANDI
5.3.4 Options de sélection (SELECT-OPTIONS)
Le rôle d'un select-option est le même que celui des paramètres .Les select-options permettent
de saisir des fourchettes de valeurs, d'exclure des valeurs… Ils sont matérialisés par une table
interne, dont la structure dépend de la zone citée en référence du select-option. Ils se codifient
comme suit :

1-2 'S_'
3-7 Nom explicatif sur 5 caractères .Si une zone SAP équivalente existe,
reprendre le nom de cette zone.
Exemple : un select-option contenant le nom d'un fournisseur sera déclaré
comme cela :

de
Finances
Développement
SELECT-OPTION : S_LIFNR FOR LFAI-LIFNR
5.3.5 Tables internes
Les tables internes sont utilisées pour stocker des enregistrements répondant à une structure
bien définie. Elles sont codifiées comme suit :

1-3 'WT_'
4--- descriptif' de la table interne
5.3.6 Ranges
Le range est une table speciale possédant une structure fixe.

Zone Type Longueur
SIGN CHAR 1
OPTION CHAR 2
LOW <type de donnée>
HIGH <type de donnée>
Il est déclaré comme suit :

TYPES : tr_type_range TYPE RANGE OF <type de donnée>
DATA r_nom_range TYPE tr_type_range
Ils sont codifiés comme suit :

1-2 'R_'
3--- descriptif' du range
5.3.7 Structures
Une structure est une zone de travail, un ensemble cohérent d’information, un regroupement
de plusieurs zones. Elle correspond à une ligne de table.

1-3 'WS_'
4-- descriptif' de la structure. Par exemple, une structure utilisée pour transférer des
données dans un fichier en sortie se nommera STRSO.

de
Finances
Développement
5.3.8 Variables de travail
Les variables de travail sont utilisées pour stocker des valeurs susceptibles d'évoluer durant le
déroulement du programme. C'est le cas des compteurs, des variables de calcul…

1-2 'W_'
3-7 Nom explicatif sur 5 caractères .Si une zone SAP équivalente existe, reprendre
le nom de cette zone.
Exemple : une variable contenant le nom d'une société se nommera W_BURKS
5.3.9 Constantes
Les constantes sont utilisées pour définir une valeur fixe lors d'un traitement

1-2 'K_'
3-7 Nom explicatif sur 5 caractères .Si une zone SAP équivalente existe, reprendre
le nom de cette zone.
Exemple: une constante qui contient une organisation d'achats sera déclarée de
la sorte :
DATA :K_EKORG TYPE EKORG VALUE 'HA01'
5.3.10 Paramètre check-box

1-3 'CB_'
4-8 Nom explicatif sur 5 caractères .
5.3.11 Paramètre Radio-bouton

1-3 'CB_'
4-8 Nom explicatif sur 5 caractères .
5.3.12 Field-symboles de variable

1-3 '<F_'
4-- Nom explicatif
Dernière ‘>’
de
Finances
Développement
5.3.13 Field-symboles de structure

1-4 '<FS_'
5--- Nom explicatif
5.3.14 dernière ‘>’ Paramètres
de routines

de
Finances
Développement
5.4 Instructions

de
Finances
Développement
5.5 Accès à la base de données

de
Finances
Développement
5.6 Performances

de
Finances
Développement
5.7 Présentation des états
5.7.1 Couleurs
L'utilisation des couleurs dans les états est normalisée .SAP propose une palette de huit
couleurs, chacune déclinable en trois formats.
Voici une liste des couleurs disponibles, ainsi que l'utilisation que nous leur donnerons :
Identifiant Couleur Utilisation

COL_BACKGROUND Pas de couleurs Ligne d'un état
COL_HEADING Bleu En-tête de colonne
COL_NORMAL Gris -
COL_TOTAL Jaune Totaux
COL_KEY Bleu -
COL_POSITIVE Vert -
COL_NEGATIVE Rouge Liste des erreurs
COL_GROUP Violet En-tête d'un compte-rendu
5.8 Messages
Il est possible d'éditer des messages lors d'un traitement. Ces messages ont pour but
d'informer l'utilisateur du déroulement d'un programme, d'une procédure. Ils peuvent
également être utilisés pour établir des comptes-rendus de traitement.
Exemples : 'Ouverture du fichier & impossible '

'Création du dossier Batch Input & erroné '
'Pas de condition de paiement pour le délai & et échéance&'…
5.8.1 Classes de messages
Une classe de messages a pour but de regrouper un certain nombre de messages qui possèdent
un point commun, ou bien qui s'applique à un même domaine.
Il existe une classe des messages spécifiques nommée 'ZMESSAGE' créée spécialement pour
nos besoins. Chaque intervenant sur le projet pourra ajouter des messages en fonction de ses
besoins.
Les classes de messages peuvent être visualisées par la transaction SE91.

de
Finances
Développement
5.8.2 Numéros de messages
Un message est identifié par un numéro sur 3 chiffres. L'attribution des numéros se fait dans
l'ordre croissant (000, 001, 002, …).
On utilisera la fonction 'Texte Descriptif' qui permet d'afficher, si l'utilisateur le désire, une
note explicative du message ainsi que les corrections à apporter dans les cas des messages
d'erreur.
5.8.3 Types de messages
Un message peut être de cinq types différents :
Types Désignation
S Système
I Information : Les messages d'information s'affichent sous forme de petite fenêtre
E Erreur: les messages d'erreur entraînent l'arrêt d'un traitement, ou la suspension d'un
d'une transaction
W Warning : Les messages de types Warning entraînent l'arrêt momentané d'un
traitement ou d'une transaction (reprise en pressant la touche 'Entrée'
A Abend: Les messages de types 'Abend ' entraînent l'exclusion définitive d'un traitement
ou d'une transaction .La main est perdue.
5.8.4 Utilisation
L'appel à un message s'effectue de la façon suivante :
MESSAGE <Type><identifiant>(<classe>) USING variable_1 variable_2
Dans un message, les caractères '&' sont passés en paramètre de l'instruction .Quatre variables
peuvent être renseignées.
Programmation de
l'affichage du message
d'erreur 063 (Saisir un
code magasin) de la
classe ZMESSAGE
Programmation de
l'affichage du message
système 024 (La quantité
répartie est > à &) de la
classe ZMESSAGE

de
Finances
Développement

Langue

Normes Et Standards de Développement - V3

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Normes Et Standards de Développement - V3

Titre original :

Transféré par

Droits d'auteur :

Futura Normes et Standards

Normes et standards de développement - 1 / 32 -

Normes et standards de développement - 2 / 32 -

5.8.3 Types de messages................................................................................................28

Normes et standards de développement - 3 / 32 -

Chez NOZ, trois environnements distincts existent :

Réplication des données

DEV QAS PROD

Normes et standards de développement - 4 / 32 -

Actuellement, la documentation est …

Normes et standards de développement - 5 / 32 -

De plus, l'organisation des documents est fortement dépendante du module auquel un

Voici le dossier contenant tous les documents utiles :

La plupart des spécifications détaillées d’évolution se trouvent néanmoins dans le dossier

Normes et standards de développement - 6 / 32 -

3.1 Numérotation des développements

On appelle 'développement' une réalisation informatique de nature :

Chaque nouveau développement se voit attribuer un numéro de 6 chiffres qui l'identifie. Ce

Les trois premiers chiffres correspondent au périmètre du développement.

3.1.2 Tranches de numéros

Normes et standards de développement - 7 / 32 -

3.2 Dossier d'analyse

Le nom de l'analyse détaillée est codifié de la sorte :

Position Code et signification

3.3 Dossier de test

Le nom de dossier de test est codifié de la sorte :

Position Code et signification

Normes et standards de développement - 8 / 32 -

Le numéro de version du dossier de test est identique au numéro de version de l'étude

Normes et standards de développement - 9 / 32 -

3.4 Dossier de validation

La codification d'un document de validation est la suivante :

Position Code et signification

2-5 Numéro du développement informatique

Normes et standards de développement - 10 / 32 -

4. Codification des objets SAP

Le but d'une codification est de conserver un environnement homogène et logique. Elle

4.1 Objets du dictionnaire

Les champs d'une table doivent posséder un libellé précis. Notes : le

La codification d'une table est la suivante :

Normes et standards de développement - 11 / 32 -

La codification d'un domaine est la suivante :

La codification d'un matchcodes est la suivante

Les identifiants de matchcode sont numérotés de 0 à 9 (tranche autorisée

Normes et standards de développement - 12 / 32 -

4.2 Programmes ABAP

L'ABAP/4 (Advanced Business Application Programming) est le langage de programmation

Normes et standards de développement - 13 / 32 -

Normes et standards de développement - 14 / 32 -

5.1 Documentation des programmes

Dans le but d'améliorer la lisibilité, la compréhension et la maintenabilité des programmes, de

5.1.1 Cartouche des programmes ABAP

L’utilisation du modèle de code « cartouche » est recommandée.

Normes et standards de développement - 15 / 32 -

5.1.2 Documentation du programme :

Pour tout nouveau programme, le remplissage de la documentation SAP associée est

Lorsque le programme est en modification, la documentation l’est aussi.

Voici un exemple de documentation :

Normes et standards de développement - 16 / 32 -

5.1.3 Commentaires sur les variables

Chaque paramètre, select-option, table interne, structurez ou variable doit posséder un

Normes et standards de développement - 17 / 32 -

5.2 Structure du programme

5.2.1 Organisation du programme