| Next revision | Previous revision |
| abap:user-exits [2013/06/28 15:18] – created ginko | abap:user-exits [2014/10/01 18:01] (current) – [Trucs & Astuces] ginko |
|---|
| ====== User et Screen Exits ====== | ====== User et Screen Exits ====== |
| | ===== Généralités ===== |
| | [[http://help.sap.com/saphelp_46c/helpdata/en/4c/d52fe48435d111950d0060b03c6b76/content.htm|On SAP Help.]] |
| | ==== Trucs & Astuces ==== |
| | * Lorsqu'un nouvel user-exit est implémenté, il faut : |
| | * L'activer dans ''cmod'' ou ''smod''. |
| | * Relancer le programme (sortir - rerentrer) |
| | * Il peut être également nécessaire de se délogger puis de se relogger. |
| | * Un message d'erreur peut cacher un user-exit. En utilisant ''OCHS'', on peut changer le type d'un message (par ex., le passer à ''E''). Pour déterminer si c'est utile, rechercher le nom du message et le composant utilisé ou le user-exit concerné (ex. : LB031 BAPI_GOODSMVT_CREATE / MBCFC010 remonte la note 526850). |
| | * Pour déterminer si on passe dans un user-exit sans l'implémenter, il suffit de se rendre sur l'extension (''SMOD'', passer sur le composant désiré, remonter sur le module fonction ''EXIT_SAP*'', faire un cas d'emploi dessus et placer des points d'arrêts sur chaque appel). |
| | * Le sous-écran s'exécute dans un programme différent du programme standard et les données transférées sont souvent trop limitées. Pour récupérer une variable globale du programme standard, passer par un [[abap:coding_tips#recuperer_une_variable_d_un_autre_programme|field symbol]]. |
| | |
| | ==== Transport & activation ==== |
| | En principe si le transport s'est bien passé, l'activation est automatique. [[http://www.stechno.net/sap-notes.html?view=sapnote&id=25276|Quelques points à vérifier en cas de non-activation]]. |
| ===== Screen-exits ===== | ===== Screen-exits ===== |
| {{:abap:comment_implementer_un_user-exit_rf.odt|}} | {{:abap:comment_implementer_un_user-exit_rf.odt|}} |
| |
| <div class="MobileSubScreen"></code> | <div class="MobileSubScreen"></code> |
| | ===== Développement RF ===== |
| | ==== Données internes ==== |
| | |
| | Dans le cadre de la customisation d'écran de transaction RF, les éléments à manipuler sont : |
| | * la table interne ''tap_ltap'' qui contient l'état de la transaction (champs de confirmation : emplacement, article, etc) pour chaque poste d'OT |
| | * la table interne ''applic_tab'' qui contient les postes à confirmer : dans l'écran ''source'', ceux qui vont être à revalider dans l'écran ''destination'' ; dans l'écran ''destination'', ceux qui vont être confirmés dans le système (''to_confirm'') |
| | * la table interne ''verification_type'' qui contient les conditions de validation (elle peut être remplie à l'aide du FM ''SET_VERIFICATION_FIELD'') |
| | |
| | |
| | __**ATTENTION**__: Comme les screen exits résident dans le groupe de fonctions ''XLRF'' (contrairement aux programmes RF contenus dans ''LMOB''), il faut re-remplir au moins certaines variables et tables lors du premier appel de sous-écran, puis faire attention qu'au fil des appels, ces données restent globalement synchronisées avec les données du programme standard ! |
| | |
| | |
| | ==== Actions à reproduire/adapter ==== |
| | En cas d'ajout/suppression d'un champs de validation (ex. : le lot), tout le workflow des écrans est à adapter : |
| | * Unordered List Item |
| | |
