main program and documentation of zdpr_payments
This commit is contained in:
parent
47a01d530a
commit
e109a47666
@ -0,0 +1,76 @@
|
|||||||
|
The user wants documentation for a SAP ABAP file. Let me analyze the code provided.
|
||||||
|
|
||||||
|
# Documentation : `zfgpaymentrules.fugr.lzfgpaymentrulesf00.abap`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Algorithmie
|
||||||
|
|
||||||
|
Ce fichier est un **include de pool de sous-routines** (`Fxx`) généré automatiquement par SAP dans le cadre d'un **groupe de fonctions** (`ZFGPAYMENTRULES`). Il ne contient pas de logique applicative propre.
|
||||||
|
|
||||||
|
Son rôle est d'héberger les **FORM routines liées aux vues de maintenance** (View Maintenance). Il délègue l'intégralité de cette logique à l'include standard SAP `LSVIMFTX`, qui fournit les routines de base pour la gestion des tables/vues via la transaction SM30/SM31.
|
||||||
|
|
||||||
|
En pratique, ce fichier agit comme un **conteneur passif** : il est inclus dans le programme principal du groupe de fonctions et active les comportements standards de la View Maintenance Framework de SAP.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Objets
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `LZFGPAYMENTRULESF00` | Include ABAP (Fxx) | Include de routines FORM du groupe de fonctions `ZFGPAYMENTRULES`. Fichier courant. |
|
||||||
|
| `LSVIMFTX` | Include SAP Standard | Contient les FORM routines standard pour la maintenance de vues (View Maintenance). Fournit les traitements CRUD sur les entrées de table/vue. |
|
||||||
|
| `ZFGPAYMENTRULES` | Groupe de fonctions | Groupe de fonctions parent qui encapsule les modules fonctionnels liés aux règles de paiement (`ZDPR_PAYMENTS`). |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dépendances
|
||||||
|
|
||||||
|
### `LSVIMFTX` (Standard SAP)
|
||||||
|
- Include appartenant au **framework SAP View Maintenance** (`LSVIM*`).
|
||||||
|
- Fournit des FORM routines génériques utilisées lors des opérations de maintenance de vues (lecture, écriture, validation, etc.) via SM30/SM31.
|
||||||
|
- Dépendance **critique** : sans cet include, le groupe de fonctions ne pourrait pas supporter la maintenance de tables/vues customisées.
|
||||||
|
- Cet include est **livré par SAP** et ne doit jamais être modifié.
|
||||||
|
|
||||||
|
### Groupe de fonctions `ZFGPAYMENTRULES`
|
||||||
|
- Ce fichier fait partie d'un groupe de fonctions plus large, probablement lié à un **customizing des règles de paiement** (`ZDPR_PAYMENTS`).
|
||||||
|
- L'include `F00` est le premier include de routines FORM du groupe ; d'autres includes (`F01`, `F02`, etc.) peuvent exister et contenir des routines métier supplémentaires.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Flux de traitement
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Chargement du groupe de fonctions ZFGPAYMENTRULES
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
2. Inclusion de LZFGPAYMENTRULESF00 (fichier courant)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
3. Inclusion de LSVIMFTX (standard SAP)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
4. Mise à disposition des FORM routines standard
|
||||||
|
pour la View Maintenance (SM30/SM31)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
5. Appel des routines lors des événements utilisateur
|
||||||
|
(création, modification, suppression d'entrées de table)
|
||||||
|
```
|
||||||
|
|
||||||
|
Ce flux est **passif** : aucune logique n'est déclenchée à l'inclusion. Les routines ne sont invoquées que lorsqu'un utilisateur interagit avec la vue de maintenance associée.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Points d'attention
|
||||||
|
|
||||||
|
### ⚠️ Risques techniques
|
||||||
|
|
||||||
|
- **Dépendance à un include SAP standard (`LSVIMFTX`)** : toute mise à jour SAP (Support Package, upgrade) peut modifier le comportement de cet include. Il convient de tester les opérations de maintenance de vue après chaque transport de correctifs SAP.
|
||||||
|
- **Fichier généré automatiquement** : ce fichier est typiquement régénéré par SAP lors de modifications de la vue de maintenance. Toute modification manuelle serait écrasée sans avertissement.
|
||||||
|
- **Absence de logique custom** : si des validations ou traitements métier spécifiques aux règles de paiement étaient nécessaires, ils devraient être placés dans un autre include (ex. `F01`) ou dans les événements de la vue (events SM30), pas dans ce fichier.
|
||||||
|
|
||||||
|
### ⚠️ Risques métiers
|
||||||
|
|
||||||
|
- **Absence de contrôle d'accès visible** : la sécurité des entrées de la table de customizing dépend des autorisations SAP (objets d'autorisation standard de SM30, ex. `S_TABU_DIS`). Vérifier que les profils d'accès sont correctement définis pour les utilisateurs de la transaction de maintenance.
|
||||||
|
- **Cohérence des données de paiement** : si la table maintenue via ce groupe de fonctions contient des règles de paiement critiques (montants, délais, comptes), toute modification non contrôlée via SM30 peut avoir un impact financier direct. Un workflow de validation ou un verrou de transport devrait être envisagé.
|
||||||
@ -0,0 +1,68 @@
|
|||||||
|
The user wants documentation for an SAP ABAP file. Let me analyze the code and provide the requested documentation.
|
||||||
|
|
||||||
|
# Documentation : `zfgpaymentrules.fugr.lzfgpaymentrulesi00.abap`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Algorithmie
|
||||||
|
|
||||||
|
Ce fichier est un **include PAI (Process After Input)** généré automatiquement par SAP dans le cadre d'un **groupe de fonctions** (`ZFGPAYMENTRULES`). Il ne contient pas de logique métier propre, mais joue un rôle structurel fondamental.
|
||||||
|
|
||||||
|
Son unique responsabilité est d'**inclure le module standard SAP `LSVIMITX`**, qui centralise les modules PAI liés à la gestion des vues de tables de base (maintenance de tables via SM30/SE16). Il s'agit d'un fichier d'infrastructure, généré par le générateur de vues SAP, destiné à orchestrer le traitement des événements utilisateur (saisie, validation, navigation) dans les écrans de maintenance.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Objets
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `ZFGPAYMENTRULES` | Groupe de fonctions | Conteneur parent regroupant les modules de fonction liés aux règles de paiement |
|
||||||
|
| `LSVIMITX` | Include standard SAP | Fournit l'ensemble des modules PAI standards pour la maintenance de vues de tables (View Maintenance) |
|
||||||
|
| `lzfgpaymentrulesi00` | Include PAI | Fichier d'inclusion PAI du groupe de fonctions, point d'entrée pour les traitements post-saisie écran |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dépendances
|
||||||
|
|
||||||
|
- **`LSVIMITX`** : Include standard SAP (package `SDIC` ou `SVIEW`). Il contient les modules PAI génériques utilisés par le framework de maintenance de vues (`VIEW_MAINTENANCE_CALL`). Cette dépendance est critique et ne doit pas être modifiée manuellement.
|
||||||
|
- **Groupe de fonctions `ZFGPAYMENTRULES`** : Ce fichier est un composant interne du groupe de fonctions. Il dépend de la structure globale du groupe (données globales, includes TOP, PBO, PAI, etc.).
|
||||||
|
- **Framework SM30 / View Maintenance** : Ce fichier est typiquement généré lorsqu'une vue de maintenance est associée à une table personnalisée gérant des règles de paiement.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Flux de traitement
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Déclenchement PAI
|
||||||
|
└── L'utilisateur effectue une action sur un écran de maintenance de vue
|
||||||
|
(ex: sauvegarder, supprimer, naviguer)
|
||||||
|
|
||||||
|
2. Appel de l'include PAI (ce fichier)
|
||||||
|
└── SAP invoque lzfgpaymentrulesi00 comme point d'entrée PAI
|
||||||
|
du groupe de fonctions ZFGPAYMENTRULES
|
||||||
|
|
||||||
|
3. Délégation vers LSVIMITX
|
||||||
|
└── INCLUDE LSVIMITX est chargé
|
||||||
|
Il contient les modules PAI standards :
|
||||||
|
- Validation des données saisies
|
||||||
|
- Gestion des actions utilisateur (CREATE, MODIFY, DELETE)
|
||||||
|
- Contrôle des autorisations
|
||||||
|
- Persistance via les appels à la table de base
|
||||||
|
|
||||||
|
4. Retour au contrôleur SAP
|
||||||
|
└── Le résultat du traitement est restitué au dynpro appelant
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Points d'attention
|
||||||
|
|
||||||
|
- **Fichier généré automatiquement** : Ce fichier est produit par le générateur de vues SAP. Toute **modification manuelle directe est fortement déconseillée**, car elle serait écrasée lors d'une regénération de la vue de maintenance.
|
||||||
|
|
||||||
|
- **Dépendance au standard SAP** : `LSVIMITX` est un objet livré par SAP. En cas de **mise à jour du système (Support Package, upgrade)**, son comportement peut évoluer, ce qui peut impacter les écrans de maintenance des règles de paiement.
|
||||||
|
|
||||||
|
- **Absence de logique métier propre** : Ce fichier ne contient aucun contrôle métier spécifique aux règles de paiement. Si des validations métier sont nécessaires (ex: cohérence des règles, plages de montants), elles doivent être implémentées dans des **user-exits ou BAdIs** dédiés, ou dans d'autres includes du groupe de fonctions.
|
||||||
|
|
||||||
|
- **Portée fonctionnelle liée aux règles de paiement** : Le groupe de fonctions `ZFGPAYMENTRULES` suggère une gestion de règles métier sensibles (paiements). Toute anomalie dans ce flux PAI peut avoir un **impact direct sur la cohérence des données financières**.
|
||||||
|
|
||||||
|
- **Traçabilité** : Il est recommandé de s'assurer que les modifications sur les tables de règles de paiement maintenues via ce groupe de fonctions sont **tracées via le Change Document** ou un mécanisme d'audit équivalent.
|
||||||
@ -0,0 +1,86 @@
|
|||||||
|
The user wants me to document an SAP ABAP file. Let me analyze the code provided and create the documentation in the requested format.
|
||||||
|
|
||||||
|
The file is `zfgpaymentrules.fugr.lzfgpaymentrulest00.abap` - this is a TOP include file (T00) for the function group `ZFGPAYMENTRULES`. In SAP ABAP, the naming convention `lXXXXXt00.abap` indicates the TOP include of a function group, which contains global data declarations used across all function modules in the group.
|
||||||
|
Looking at the structure, I can see this is a View Maintenance framework file. It declares a status vector for tracking view maintenance state, defines a table control for screen 0001, and includes both the shadow table and actual database table references. The standard SAP View Maintenance include is also pulled in to provide the necessary framework infrastructure.
|
||||||
|
|
||||||
|
# Documentation : `zfgpaymentrules.fugr.lzfgpaymentrulest00.abap`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## # Algorithmie
|
||||||
|
|
||||||
|
Ce fichier est le **TOP include** (`T00`) du groupe de fonctions `ZFGPAYMENTRULES`. Dans l'architecture SAP ABAP, le TOP include est automatiquement chargé en premier lors de l'activation du groupe de fonctions. Il ne contient aucune logique métier propre : son rôle est exclusivement de **déclarer les données globales** partagées entre tous les modules de fonction du groupe.
|
||||||
|
|
||||||
|
Ce code a été **généré automatiquement** par le générateur de maintenance de vues SAP (transaction `SE54`), dans le cadre de la maintenance de la table/vue personnalisée `ZPAYMENTRULES` via la transaction `SM30`. Il suit le pattern standard du **View Maintenance Framework (VIM)** de SAP.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## # Objets
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `STATUS_ZPAYMENTRULES` | Structure (`DATA ... BEGIN OF`) | **Vecteur d'état** de la vue de maintenance. Inclut la structure standard `VIMSTATUS` qui pilote l'état courant de la session de maintenance (mode affichage, modification, insertion, etc.). |
|
||||||
|
| `VIMSTATUS` | Structure standard SAP (`INCLUDE STRUCTURE`) | Fournit les champs de contrôle du VIM : mode d'édition, indicateurs de modification, droits d'accès, etc. Gérée par le framework SAP. |
|
||||||
|
| `TCTRL_ZPAYMENTRULES` | `CONTROLS ... TYPE TABLEVIEW` | Contrôle de type **TableView** lié à l'écran `0001`. Gère l'affichage en grille (liste de lignes) de la vue de maintenance dans la dynpro. |
|
||||||
|
| `*ZPAYMENTRULES` | Table de travail (shadow table) | Copie interne utilisée par le VIM pour stocker l'état **avant modification**, permettant la gestion des annulations et des comparaisons avant/après. |
|
||||||
|
| `ZPAYMENTRULES` | Table de base de données personnalisée | Table Z cible de la maintenance. Contient les règles de paiement (`payment rules`) gérées par cette vue SM30. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## # Dépendances
|
||||||
|
|
||||||
|
### Dépendances SAP Standard
|
||||||
|
|
||||||
|
- **`VIMSTATUS`** : Structure standard du View and Table Maintenance Framework. Définie dans les objets du dictionnaire ABAP (`DDIC`). Obligatoire pour tout groupe de fonctions généré par `SE54`.
|
||||||
|
- **`LSVIMTDT`** : Include standard SAP (`L` = local, `SVIM` = View Maintenance, `DT` = Data). Déclare les variables globales additionnelles utilisées par les modules de fonction standard du VIM (buffers internes, variables de contrôle, etc.). C'est un composant clé du framework VIM.
|
||||||
|
|
||||||
|
### Dépendances sur les objets personnalisés
|
||||||
|
|
||||||
|
- **`ZPAYMENTRULES`** : Table de base de données personnalisée. Ce programme dépend fortement de l'existence et de la structure de cette table dans le DDIC. Toute modification de sa structure (ajout/suppression de champ, changement de clé) nécessite une **régénération** de ce groupe de fonctions via `SE54`.
|
||||||
|
|
||||||
|
### Dépendances sur les écrans (Dynpros)
|
||||||
|
|
||||||
|
- **Écran `0001`** : Dynpro du groupe de fonctions sur lequel est positionné le contrôle `TCTRL_ZPAYMENTRULES`. Cet écran contient le `LOOP AT ... WITH CONTROL` correspondant.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## # Flux de traitement
|
||||||
|
|
||||||
|
Ce fichier n'implémente pas de flux à proprement parler, mais il **prépare le contexte d'exécution** pour les modules de fonction du groupe. Le flux global de la maintenance de vue est le suivant :
|
||||||
|
|
||||||
|
```
|
||||||
|
1. [Utilisateur] Appel SM30 → saisie du nom de vue ZPAYMENTRULES
|
||||||
|
│
|
||||||
|
v
|
||||||
|
2. [SAP VIM] Appel du module de fonction principal du groupe ZFGPAYMENTRULES
|
||||||
|
│
|
||||||
|
v
|
||||||
|
3. [TOP Include - ce fichier] Chargement des déclarations globales :
|
||||||
|
- Initialisation du vecteur d'état STATUS_ZPAYMENTRULES
|
||||||
|
- Mise à disposition de TCTRL_ZPAYMENTRULES pour l'écran 0001
|
||||||
|
- Mise à disposition des tables ZPAYMENTRULES et *ZPAYMENTRULES
|
||||||
|
│
|
||||||
|
v
|
||||||
|
4. [Dynpro 0001] Affichage de la TableView avec TCTRL_ZPAYMENTRULES
|
||||||
|
│
|
||||||
|
v
|
||||||
|
5. [Modules de fonction] Traitement des actions utilisateur
|
||||||
|
(lecture, modification, suppression, sauvegarde)
|
||||||
|
via les données globales déclarées ici
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## # Points d'attention
|
||||||
|
|
||||||
|
### Risques techniques
|
||||||
|
|
||||||
|
- **Fichier généré automatiquement** : Ce fichier est entièrement géré par `SE54`. Toute modification manuelle sera **écrasée** lors d'une régénération. Il ne faut jamais modifier ce fichier directement.
|
||||||
|
- **Couplage fort avec `ZPAYMENTRULES`** : Si la table `ZPAYMENTRULES` est modifiée dans le DDIC sans régénérer le groupe de fonctions via `SE54`, des **incohérences de structure** peuvent survenir, entraînant des erreurs d'activation ou des dumps à l'exécution.
|
||||||
|
- **Portée globale des variables** : Les objets déclarés ici (notamment `STATUS_ZPAYMENTRULES` et les tables) sont globaux au groupe de fonctions. Dans un contexte multi-appels ou multi-sessions, les valeurs peuvent persister entre deux appels si le groupe de fonctions reste chargé en mémoire (mode `SET UPDATE TASK LOCALLY` par exemple).
|
||||||
|
|
||||||
|
### Risques métiers
|
||||||
|
|
||||||
|
- **Aucun contrôle d'autorisation visible ici** : Les contrôles d'accès (objet d'autorisation) doivent être configurés au niveau de la vue de maintenance dans `SE54` et non dans ce fichier. Un oubli de configuration des droits peut exposer la table `ZPAYMENTRULES` à des modifications non autorisées via `SM30`.
|
||||||
|
- **Données sensibles** : Le nom `ZPAYMENTRULES` suggère que cette table contient des règles de paiement potentiellement critiques. Il convient de vérifier que l'accès à la transaction `SM30` pour cette vue est correctement restreint via les profils d'autorisation (`S_TABU_DIS` ou objet dédié).
|
||||||
|
- **Pas de gestion du transport visible** : La table de Customizing ou de paramétrage doit avoir une classe de livraison adaptée (ex. `C` pour Customizing) afin d'assurer le transport correct des données entre les mandants et systèmes.
|
||||||
@ -0,0 +1,90 @@
|
|||||||
|
The user wants me to document an SAP ABAP file. Let me analyze the code provided.
|
||||||
|
|
||||||
|
The file is `zfgpaymentrules.fugr.lzfgpaymentrulestop.abap` which is the TOP include of a Function Group named `ZFGPAYMENTRULES`.
|
||||||
|
|
||||||
|
# Documentation : `zfgpaymentrules.fugr.lzfgpaymentrulestop.abap`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Algorithmie
|
||||||
|
|
||||||
|
Ce fichier est le **programme principal (TOP include)** du Function Group `ZFGPAYMENTRULES`. Il ne contient pas de logique applicative propre : son rôle est purement **déclaratif et structurant**. Il initialise l'espace de nommage du groupe de fonctions et charge les includes globaux qui définissent les données partagées entre tous les modules de fonctions du pool.
|
||||||
|
|
||||||
|
En ABAP, le TOP include est systématiquement le point d'entrée chargé en mémoire lors de toute invocation d'une fonction appartenant au groupe. Toutes les déclarations qu'il contient (ou qu'il inclut) sont visibles par l'ensemble des function modules du pool `ZFGPAYMENTRULES`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Objets
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `ZFGPAYMENTRULES` | Function Group (Pool) | Conteneur logique regroupant les modules de fonctions liés aux règles de paiement (`ZDPR_PAYMENTS`) |
|
||||||
|
| `MESSAGE-ID SV` | Classe de messages | Définit la classe de messages SAP standard `SV` utilisée pour les messages d'erreur/information du pool |
|
||||||
|
| `LSVIMDAT` | Include standard SAP | Déclarations générales de données pour les vues de maintenance générée (View Maintenance) |
|
||||||
|
| `LZFGPAYMENTRULEST00` | Include custom | Déclarations de données spécifiques aux règles de paiement (tables de travail, variables globales, types internes propres au pool) |
|
||||||
|
| `LZFGPAYMENTRULESD` (commenté) | Include (désactivé) | Réservé aux définitions de classes locales (commenté, donc non chargé actuellement) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
|
||||||
|
### Dépendances SAP standard
|
||||||
|
|
||||||
|
- **`LSVIMDAT`** : Include généré automatiquement par SAP lors de la création d'un groupe de fonctions via l'outil de maintenance de vues (View Maintenance Generator, transaction `SE54`). Il contient les déclarations standard nécessaires au framework SM30/SM31 :
|
||||||
|
- Tables de travail globales (ex. `TOTAL`, `EXTRACT`, `X_HEADER`)
|
||||||
|
- Structures de contrôle du générateur de vues
|
||||||
|
- Variables système liées à la maintenance des tables/vues
|
||||||
|
|
||||||
|
### Dépendances custom
|
||||||
|
|
||||||
|
- **`LZFGPAYMENTRULEST00`** : Include de données propre au projet. Il contient vraisemblablement :
|
||||||
|
- Les déclarations de tables de base de données (ex. `TABLES: ZDPR_...`)
|
||||||
|
- Les types et structures internes liés aux règles de paiement
|
||||||
|
- Les variables globales partagées entre les function modules du pool
|
||||||
|
|
||||||
|
### Dépendance implicite
|
||||||
|
|
||||||
|
- **`ZDPR_PAYMENTS`** (package/projet) : Le nom du répertoire source (`ZDPR_PAYMENTS_20260519_094657`) indique que ce pool appartient au périmètre fonctionnel de gestion des paiements du projet ZDPR.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Flux de traitement
|
||||||
|
|
||||||
|
Ce fichier étant un include TOP, il n'y a pas de flux d'exécution algorithmique à proprement parler. Le flux de chargement est le suivant :
|
||||||
|
|
||||||
|
```
|
||||||
|
1. Appel d'un Function Module du pool ZFGPAYMENTRULES
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
2. Chargement du TOP include (ce fichier)
|
||||||
|
│
|
||||||
|
├──► Déclaration du pool : FUNCTION-POOL ZFGPAYMENTRULES
|
||||||
|
│ Assignation de la classe de messages SV
|
||||||
|
│
|
||||||
|
├──► INCLUDE LSVIMDAT
|
||||||
|
│ Chargement des déclarations standard View Maintenance
|
||||||
|
│
|
||||||
|
└──► INCLUDE LZFGPAYMENTRULEST00
|
||||||
|
Chargement des déclarations custom (données, types, variables)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
3. Exécution du Function Module appelé
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points d'attention
|
||||||
|
|
||||||
|
### Risques techniques
|
||||||
|
|
||||||
|
- **Include `LZFGPAYMENTRULESD` commenté** : La ligne commentée indique qu'une section de définition de classes locales a été prévue mais n'est pas active. Si des classes locales ont été définies ailleurs ou si leur absence est involontaire, cela peut provoquer des erreurs de référence lors de l'activation d'autres includes du pool.
|
||||||
|
|
||||||
|
- **Classe de messages `SV`** : L'utilisation de la classe `SV` (classe SAP standard générique) est déconseillée pour des développements custom. Si des messages applicatifs spécifiques aux règles de paiement sont nécessaires, une classe de messages dédiée (ex. `ZDPR_PAYMENTS`) devrait être utilisée pour faciliter la maintenance et éviter les collisions de numéros de messages.
|
||||||
|
|
||||||
|
- **Dépendance au générateur de vues (`LSVIMDAT`)** : Ce pool est lié au framework SM30/SM31. Toute modification de la vue de maintenance associée via `SE54` peut régénérer et écraser des portions du pool, notamment les includes `T00`, `O01`, `F01`, etc.
|
||||||
|
|
||||||
|
### Risques métiers
|
||||||
|
|
||||||
|
- **Données globales partagées** : Les déclarations dans `LZFGPAYMENTRULEST00` sont partagées entre tous les function modules du pool. Une mauvaise gestion de l'état de ces variables globales entre deux appels successifs peut entraîner des comportements inattendus (données résiduelles d'un appel précédent).
|
||||||
|
|
||||||
|
- **Périmètre fonctionnel sensible** : Le pool gère des **règles de paiement** (`ZDPR_PAYMENTS`). Toute erreur dans la logique de maintenance des données peut avoir un impact direct sur les flux financiers. Une attention particulière doit être portée aux contrôles de cohérence dans les function modules associés.
|
||||||
@ -0,0 +1,112 @@
|
|||||||
|
The user wants documentation for an SAP ABAP function group main program file. Let me analyze the code and produce the requested markdown documentation.
|
||||||
|
|
||||||
|
The file `saplzfgpaymentrules.abap` is the main pool program of the function group `ZFGPAYMENTRULES`. This is a standard SAP ABAP pattern where the `SAPL` prefix indicates the main program generated for a function group.
|
||||||
|
|
||||||
|
# Documentation — `saplzfgpaymentrules.abap`
|
||||||
|
|
||||||
|
> **Fichier :** `zfgpaymentrules.fugr.saplzfgpaymentrules.abap`
|
||||||
|
> **Type :** Programme principal d'un groupe de fonctions ABAP (`FUGR`)
|
||||||
|
> **Groupe de fonctions :** `ZFGPAYMENTRULES`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Algorithmie
|
||||||
|
|
||||||
|
Ce fichier est le **programme pool principal** (`SAPL...`) du groupe de fonctions `ZFGPAYMENTRULES`. Dans l'architecture ABAP, un groupe de fonctions est un conteneur logique regroupant des modules de fonctions partageant des données globales et des sous-programmes communs.
|
||||||
|
|
||||||
|
Ce fichier n'implémente **aucune logique métier directe** : son rôle est exclusivement de **déclarer et d'assembler les includes** qui constituent le groupe de fonctions. SAP génère automatiquement ce fichier lors de la création d'un groupe de fonctions dans la SE37/SE80.
|
||||||
|
|
||||||
|
Le nom du programme pool suit la convention SAP : `SAPL` + nom du groupe de fonctions = `SAPLZFGPAYMENTRULES`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Objets
|
||||||
|
|
||||||
|
| Include | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `LZFGPAYMENTRULESTOP` | Déclarations globales | Contient les données globales du groupe de fonctions : types, variables, constantes, tables internes partagées entre tous les modules de fonctions |
|
||||||
|
| `LZFGPAYMENTRULESUXX` | Modules de fonctions | Contient les en-têtes et le code des modules de fonctions (`FUNCTION ... ENDFUNCTION`) du groupe `ZFGPAYMENTRULES` |
|
||||||
|
| `LZFGPAYMENTRULESF00` | Sous-programmes | Contient les `FORM ... ENDFORM` utilisés en interne par les modules de fonctions |
|
||||||
|
| `LZFGPAYMENTRULESI00` | Modules PAI | Contient les modules PAI (*Process After Input*) liés aux éventuels écrans du groupe de fonctions |
|
||||||
|
| `LSVIMFXX` | Sous-programmes (standard SAP) | Include standard SAP lié à la Vue de Maintenance (`SM30/SM31`) : contient des sous-programmes génériques pour la gestion des vues de maintenance |
|
||||||
|
| `LSVIMOXX` | Modules PBO (standard SAP) | Include standard SAP : modules PBO (*Process Before Output*) pour les vues de maintenance |
|
||||||
|
| `LSVIMIXX` | Modules PAI (standard SAP) | Include standard SAP : modules PAI pour les vues de maintenance |
|
||||||
|
|
||||||
|
> **Includes commentés (non actifs) :**
|
||||||
|
> Les includes `LZFGPAYMENTRULESF...`, `LZFGPAYMENTRULESO...`, `LZFGPAYMENTRULESE...`, `LZFGPAYMENTRULESP...`, `LZFGPAYMENTRULEST99` sont désactivés, ce qui indique que les fonctionnalités correspondantes (événements, classes locales, tests unitaires ABAP, modules PBO personnalisés) n'ont pas été implémentées.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
|
||||||
|
### Dépendances internes (custom)
|
||||||
|
|
||||||
|
```
|
||||||
|
ZFGPAYMENTRULES (groupe de fonctions)
|
||||||
|
├── LZFGPAYMENTRULESTOP → Données globales partagées
|
||||||
|
├── LZFGPAYMENTRULESUXX → Modules de fonctions (logique métier principale)
|
||||||
|
├── LZFGPAYMENTRULESF00 → Sous-programmes internes
|
||||||
|
└── LZFGPAYMENTRULESI00 → Modules PAI (écrans custom)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Dépendances standard SAP (Vue de Maintenance)
|
||||||
|
|
||||||
|
```
|
||||||
|
SAP Standard (LSVIM*)
|
||||||
|
├── LSVIMFXX → Sous-programmes génériques de vue de maintenance
|
||||||
|
├── LSVIMOXX → PBO modules de vue de maintenance
|
||||||
|
└── LSVIMIXX → PAI modules de vue de maintenance
|
||||||
|
```
|
||||||
|
|
||||||
|
La présence des includes `LSVIM*` est un indicateur fort que le groupe de fonctions `ZFGPAYMENTRULES` est associé à une **vue de maintenance** (`SM30`) pour une table ou une vue de customizing liée aux règles de paiement (`PAYMENT RULES`). Ces includes sont injectés automatiquement par SAP lors de la génération d'une vue de maintenance.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Flux de traitement
|
||||||
|
|
||||||
|
````
|
||||||
|
1. CHARGEMENT DU POOL
|
||||||
|
└── SAP charge SAPLZFGPAYMENTRULES en mémoire lors du premier appel
|
||||||
|
à un module de fonctions du groupe ZFGPAYMENTRULES
|
||||||
|
|
||||||
|
2. INITIALISATION DES DONNÉES GLOBALES
|
||||||
|
└── LZFGPAYMENTRULESTOP est exécuté en premier
|
||||||
|
→ Initialise les variables, types et tables globales
|
||||||
|
partagées entre tous les modules de fonctions
|
||||||
|
|
||||||
|
3. APPEL D'UN MODULE DE FONCTIONS
|
||||||
|
└── LZFGPAYMENTRULESUXX contient le code des FUNCTION
|
||||||
|
→ Le module appelé peut utiliser :
|
||||||
|
- Les données globales (LZFGPAYMENTRULESTOP)
|
||||||
|
- Les sous-programmes internes (LZFGPAYMENTRULESF00)
|
||||||
|
|
||||||
|
4. INTERACTION ÉCRAN (si applicable)
|
||||||
|
├── PBO : LSVIMOXX prépare l'affichage (vue de maintenance)
|
||||||
|
└── PAI : LZFGPAYMENTRULESI00 + LSVIMIXX traitent les actions utilisateur
|
||||||
|
|
||||||
|
5. SOUS-PROGRAMMES DE SUPPORT
|
||||||
|
└── LSVIMFXX fournit des routines de traitement
|
||||||
|
pour la logique de la vue de maintenance (validation, enregistrement)
|
||||||
|
````
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points d'attention
|
||||||
|
|
||||||
|
### Risques techniques
|
||||||
|
|
||||||
|
- **Données globales partagées (`LZFGPAYMENTRULESTOP`) :** Les variables globales d'un groupe de fonctions persistent pendant toute la session utilisateur (mode en mémoire). Un mauvais ordre d'appel des modules de fonctions ou un état non réinitialisé peut provoquer des comportements inattendus et difficiles à déboguer.
|
||||||
|
|
||||||
|
- **Includes standard SAP (`LSVIM*`) :** Ces includes ne doivent **jamais être modifiés**. Toute modification serait écrasée lors d'une mise à jour SAP (Support Package / EHP). La logique custom doit rester dans les includes `LZFG*`.
|
||||||
|
|
||||||
|
- **Includes désactivés :** L'absence des includes PBO custom (`LZFGPAYMENTRULESO...`), événements (`LZFGPAYMENTRULESE...`) et tests unitaires (`LZFGPAYMENTRULEST99`) signifie que la couverture de test automatisée est **inexistante** et que certains scénarios d'affichage écran pourraient ne pas être gérés proprement.
|
||||||
|
|
||||||
|
- **Couplage fort via données globales :** Si plusieurs modules de fonctions partagent et modifient les mêmes tables globales (déclarées dans `TOP`), des effets de bord inter-modules sont possibles, notamment en cas d'appels en chaîne.
|
||||||
|
|
||||||
|
### Risques métiers
|
||||||
|
|
||||||
|
- **Vue de maintenance liée aux règles de paiement :** La présence des `LSVIM*` suggère que ce groupe de fonctions pilote la maintenance d'une table de customizing des règles de paiement. Toute erreur dans la validation PAI (`LSVIMIXX` / `LZFGPAYMENTRULESI00`) pourrait permettre l'enregistrement de données de règles de paiement incohérentes.
|
||||||
|
|
||||||
|
- **Pas de tests unitaires activés :** L'include `LZFGPAYMENTRULEST99` (ABAP Unit) est commenté. En l'absence de tests automatisés, les régressions lors d'évolutions fonctionnelles sont plus difficiles à détecter.
|
||||||
|
|
||||||
|
- **Traçabilité limitée :** Ce fichier seul ne permet pas d'identifier les règles métiers implémentées. L'analyse des fichiers `LZFGPAYMENTRULESUXX` (modules de fonctions) et `LZFGPAYMENTRULESF00` (sous-programmes) est indispensable pour comprendre la logique de gestion des règles de paiement.
|
||||||
121
documentation/documentation_zfgpaymentrules.fugr.screen_0001.md
Normal file
121
documentation/documentation_zfgpaymentrules.fugr.screen_0001.md
Normal file
@ -0,0 +1,121 @@
|
|||||||
|
The user wants me to document an SAP ABAP screen flow file for a function group related to payment rules. Let me analyze the code and produce the documentation.
|
||||||
|
|
||||||
|
# Documentation : `zfgpaymentrules.fugr.screen_0001.abap`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Algorithmie
|
||||||
|
|
||||||
|
Ce fichier définit la **logique de flux d'un écran dynpro (screen 0001)** appartenant au groupe de fonctions `ZFGPAYMENTRULES`. Il s'agit d'un écran de type **liste View/Maintenance** (View Maintenance, généré via SM30/SE54), gérant l'affichage et la saisie des règles de paiement fournisseurs (`ZPAYMENTRULES`).
|
||||||
|
|
||||||
|
Le programme est structuré en deux blocs fondamentaux du cycle de vie d'un dynpro SAP :
|
||||||
|
|
||||||
|
- **`PROCESS BEFORE OUTPUT (PBO)`** : prépare et affiche la liste à l'écran.
|
||||||
|
- **`PROCESS AFTER INPUT (PAI)`** : traite les actions utilisateur (commandes, modifications de champs, sélections).
|
||||||
|
|
||||||
|
Le schéma général suit le pattern standard de la **View Maintenance** SAP, où les modules appelés (`LISTE_*`) sont générés automatiquement par le framework et pilotent la table interne `EXTRACT` comme tampon de données d'écran.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Objets
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `EXTRACT` | Table interne (générée VIM) | Tampon de données entre la base de données et l'écran. Contient les lignes de la vue de maintenance. |
|
||||||
|
| `TCTRL_ZPAYMENTRULES` | Table Control | Contrôle graphique de type liste scrollable, lié à la table interne `EXTRACT`. Gère la navigation ligne par ligne (`CURSOR NEXTLINE`). |
|
||||||
|
| `ZPAYMENTRULES` | Structure de travail (work area) | Représente une ligne de la table/vue `ZPAYMENTRULES` avec ses champs : `LIFNR`, `VENDORNAME`, `DAYSLATE`, `COMMENTS`. |
|
||||||
|
| `VIM_MARKED` | Champ booléen (VIM) | Case à cocher de sélection de ligne, standard du framework View Maintenance. Permet de marquer une ou plusieurs lignes pour traitement en lot. |
|
||||||
|
| `NEXTLINE` | Variable de curseur | Pointeur de ligne utilisé par le Table Control pour le défilement de la liste. |
|
||||||
|
|
||||||
|
### Champs de la structure `ZPAYMENTRULES`
|
||||||
|
|
||||||
|
| Champ | Rôle métier |
|
||||||
|
|---|---|
|
||||||
|
| `LIFNR` | Numéro de fournisseur (clé primaire) |
|
||||||
|
| `VENDORNAME` | Nom du fournisseur |
|
||||||
|
| `DAYSLATE` | Nombre de jours de retard tolérés pour le paiement |
|
||||||
|
| `COMMENTS` | Commentaire libre sur la règle de paiement |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
|
||||||
|
- **Groupe de fonctions `ZFGPAYMENTRULES`** : ce fichier est un composant de ce groupe. Les modules appelés (`LISTE_INITIALISIEREN`, `LISTE_SHOW_LISTE`, etc.) sont définis dans les includes ABAP du même groupe de fonctions.
|
||||||
|
|
||||||
|
- **Framework View Maintenance (VIM)** : l'ensemble des modules `LISTE_*` et `SET_UPDATE_FLAG` sont des modules standard générés par le framework SM30. Ce programme ne peut fonctionner qu'en contexte de maintenance de vue SAP.
|
||||||
|
|
||||||
|
- **Table/Vue de base `ZPAYMENTRULES`** : la table de personnalisation client qui stocke les règles de paiement. Toute modification du dictionnaire de données (ajout/suppression de champs) nécessite une régénération de l'écran et de ses modules.
|
||||||
|
|
||||||
|
- **Table Control `TCTRL_ZPAYMENTRULES`** : définie dans le Screen Painter (SE51), doit rester cohérente avec les champs déclarés dans la `CHAIN` du PAI.
|
||||||
|
|
||||||
|
- **Variable globale `VIM_MARKED`** : variable standard du pool VIM, partagée avec les autres includes du groupe de fonctions.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Flux de traitement
|
||||||
|
|
||||||
|
### Phase PBO (affichage)
|
||||||
|
|
||||||
|
```
|
||||||
|
1. MODULE LISTE_INITIALISIEREN
|
||||||
|
└─ Initialise les variables de contrôle, prépare le contexte d'affichage
|
||||||
|
(statuts, titres, autorisation en lecture/écriture).
|
||||||
|
|
||||||
|
2. LOOP AT EXTRACT WITH CONTROL TCTRL_ZPAYMENTRULES CURSOR NEXTLINE
|
||||||
|
└─ Pour chaque ligne visible dans le Table Control :
|
||||||
|
MODULE LISTE_SHOW_LISTE
|
||||||
|
└─ Copie les données de EXTRACT vers les champs d'écran ZPAYMENTRULES-*.
|
||||||
|
```
|
||||||
|
|
||||||
|
### Phase PAI (traitement des entrées utilisateur)
|
||||||
|
|
||||||
|
```
|
||||||
|
1. MODULE LISTE_EXIT_COMMAND AT EXIT-COMMAND
|
||||||
|
└─ Intercepte les commandes de sortie (F3, F12, annulation).
|
||||||
|
Traité EN PREMIER pour permettre une sortie propre sans validation.
|
||||||
|
|
||||||
|
2. MODULE LISTE_BEFORE_LOOP
|
||||||
|
└─ Initialise l'état avant le traitement des lignes (flags globaux, etc.).
|
||||||
|
|
||||||
|
3. LOOP AT EXTRACT (pour chaque ligne de l'écran)
|
||||||
|
│
|
||||||
|
├─ MODULE LISTE_INIT_WORKAREA
|
||||||
|
│ └─ Prépare la zone de travail pour la ligne courante.
|
||||||
|
│
|
||||||
|
├─ CHAIN (LIFNR + VENDORNAME + DAYSLATE + COMMENTS)
|
||||||
|
│ MODULE SET_UPDATE_FLAG ON CHAIN-REQUEST
|
||||||
|
│ └─ Si au moins un champ de la chaîne a été modifié,
|
||||||
|
│ positionne le flag de mise à jour (insertion/modification).
|
||||||
|
│
|
||||||
|
├─ FIELD VIM_MARKED → MODULE LISTE_MARK_CHECKBOX
|
||||||
|
│ └─ Traite la case à cocher de sélection de ligne.
|
||||||
|
│
|
||||||
|
└─ CHAIN (LIFNR)
|
||||||
|
MODULE LISTE_UPDATE_LISTE
|
||||||
|
└─ Répercute les modifications dans la table interne EXTRACT.
|
||||||
|
|
||||||
|
4. MODULE LISTE_AFTER_LOOP
|
||||||
|
└─ Finalise le traitement : sauvegarde, gestion des erreurs, mise à jour BDD.
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points d'attention
|
||||||
|
|
||||||
|
### Risques techniques
|
||||||
|
|
||||||
|
- **Cohérence écran / dictionnaire** : si des champs sont ajoutés à la table `ZPAYMENTRULES`, il faut impérativement régénérer la vue de maintenance (SM30) ET l'écran (SE51). Une désynchronisation provoque des dumps ou des données silencieusement ignorées.
|
||||||
|
|
||||||
|
- **Ordre des modules PAI** : `LISTE_EXIT_COMMAND` doit rester **en première position** dans le PAI avec la clause `AT EXIT-COMMAND`. Le déplacer entraîne une impossibilité de quitter l'écran proprement sans déclencher les validations de champs.
|
||||||
|
|
||||||
|
- **`CHAIN` sur `LIFNR` en double** : le champ `LIFNR` apparaît dans deux `CHAIN` distinctes. Cela est intentionnel dans le pattern VIM (première chaîne pour la détection de modification, seconde pour la mise à jour de liste), mais toute modification manuelle doit préserver cette logique.
|
||||||
|
|
||||||
|
- **Table Control et pagination** : le `CURSOR NEXTLINE` doit être synchronisé avec la taille du Table Control définie dans SE51. Un décalage peut provoquer des problèmes d'affichage ou des boucles infinies.
|
||||||
|
|
||||||
|
### Risques métiers
|
||||||
|
|
||||||
|
- **Absence de validation métier visible** : ce fichier ne contient pas de logique de validation des valeurs saisies (ex. : vérification que `LIFNR` existe dans LFA1, que `DAYSLATE` est positif). Ces contrôles doivent exister dans les modules inclus ou sont absents, ce qui constitue un risque de saisie de données incorrectes.
|
||||||
|
|
||||||
|
- **`VIM_MARKED` et traitements en lot** : la case à cocher permet de sélectionner plusieurs lignes. Si des traitements groupés (suppression, modification) sont disponibles via les touches de fonction, il faut s'assurer que les autorisations (`S_TABU_DIS`, objet d'autorisation personnalisé) sont correctement vérifiées dans `LISTE_EXIT_COMMAND` ou `LISTE_AFTER_LOOP`.
|
||||||
|
|
||||||
|
- **Pas de gestion du mode affichage seul** : si l'utilisateur n'a que les droits de lecture (`03`), le framework VIM doit griser les champs. Vérifier que `LISTE_INITIALISIEREN` gère correctement ce cas.
|
||||||
@ -0,0 +1,99 @@
|
|||||||
|
The user wants me to document an SAP ABAP file in Markdown format with specific sections. Let me analyze the code and provide documentation.
|
||||||
|
|
||||||
|
The file is `zfgpaymentrules.fugr.tableframe_zfgpaymentrules.abap` - it's a function module within the function group `ZFGPAYMENTRULES`. This is a standard SAP Table Maintenance Generator (TMG) function module called `TABLEFRAME_ZFGPAYMENTRULES`.
|
||||||
|
|
||||||
|
Let me analyze:
|
||||||
|
- This is a generated function module for table maintenance
|
||||||
|
- It calls the `TABLEFRAME` subroutine with specific parameters
|
||||||
|
- The parameters passed include table selections, exclusion lists, and view configuration details like the view name and action type, which are all standard inputs for the table maintenance framework function
|
||||||
|
|
||||||
|
# Documentation : `TABLEFRAME_ZFGPAYMENTRULES`
|
||||||
|
|
||||||
|
> **Fichier :** `zfgpaymentrules.fugr.tableframe_zfgpaymentrules.abap`
|
||||||
|
> **Groupe de fonctions :** `ZFGPAYMENTRULES`
|
||||||
|
> **Type :** Module fonction généré automatiquement (Table Maintenance Generator)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Algorithmie
|
||||||
|
|
||||||
|
Ce module fonction est un **module de cadre de maintenance de table** (Table Frame) généré automatiquement par le **Table Maintenance Generator (TMG)** de SAP. Il fait partie du groupe de fonctions `ZFGPAYMENTRULES`, dédié à la gestion des règles de paiement (`ZDPR_PAYMENTS`).
|
||||||
|
|
||||||
|
Son rôle est purement **délégant** : il ne contient aucune logique métier propre. Il agit comme un **point d'entrée standardisé** qui transfère immédiatement le contrôle au sous-programme générique SAP `TABLEFRAME`, lequel fournit l'infrastructure complète d'affichage et de maintenance d'une table ou d'une vue de customizing.
|
||||||
|
|
||||||
|
Ce pattern est systématiquement utilisé par SAP pour encapsuler la logique du TMG dans un module fonction spécifique à la table, tout en réutilisant le moteur générique `TABLEFRAME`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Objets
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `TABLEFRAME_ZFGPAYMENTRULES` | Module fonction | Point d'entrée spécifique à la table/vue `ZFGPAYMENTRULES` pour la maintenance via le TMG |
|
||||||
|
| `TABLEFRAME` | Sous-programme (`PERFORM`) | Routine SAP standard du TMG qui gère l'interface de maintenance (affichage, navigation, CRUD) |
|
||||||
|
| `X_HEADER` | Table interne | Contient les informations d'en-tête de la vue de maintenance (métadonnées de la table cible) |
|
||||||
|
| `X_NAMTAB` | Table interne | Contient la description des champs de la table (nom, type, longueur) utilisée pour le rendu de l'écran |
|
||||||
|
| `DBA_SELLIST` | Table interne | Liste de sélection issue de la base de données (critères de lecture des données réelles) |
|
||||||
|
| `DPL_SELLIST` | Table interne | Liste de sélection pour l'affichage (critères de filtrage à l'écran) |
|
||||||
|
| `EXCL_CUA_FUNCT` | Table interne | Liste des fonctions CUA (boutons/menus) à **exclure** de l'interface de maintenance |
|
||||||
|
| `CORR_NUMBER` | Paramètre | Numéro d'ordre de transport (Workbench Organizer) pour la traçabilité des modifications |
|
||||||
|
| `VIEW_ACTION` | Paramètre | Action déclenchée sur la vue (ex : affichage, modification, insertion) |
|
||||||
|
| `VIEW_NAME` | Paramètre | Nom de la vue ou de la table de maintenance concernée |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dépendances
|
||||||
|
|
||||||
|
- **Groupe de fonctions `ZFGPAYMENTRULES`** : Ce module fonction appartient à ce groupe et partage son contexte global (variables globales, sous-programmes, includes). Les données manipulées sont cohérentes avec les autres modules du groupe (notamment `TABLEPROC_ZFGPAYMENTRULES`, le module de traitement).
|
||||||
|
|
||||||
|
- **Routine standard SAP `TABLEFRAME`** : Dépendance critique au moteur du Table Maintenance Generator. Cette routine est fournie par SAP dans les includes standards du TMG et ne doit jamais être modifiée.
|
||||||
|
|
||||||
|
- **Table/Vue de customizing `ZFGPAYMENTRULES`** : La structure des données maintenues (champs, clés, types) est définie dans le dictionnaire ABAP (SE11) et pilote le contenu de `X_NAMTAB`.
|
||||||
|
|
||||||
|
- **Transport SAP** : La valeur de `CORR_NUMBER` lie toute modification à un ordre de transport. Une configuration incorrecte peut bloquer ou mal router les changements de customizing.
|
||||||
|
|
||||||
|
- **Customizing CUA** (`EXCL_CUA_FUNCT`) : Les boutons affichés dépendent de la configuration du statut GUI associé à la vue. Des exclusions incorrectes peuvent désactiver des actions légitimes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Flux de traitement
|
||||||
|
|
||||||
|
````
|
||||||
|
1. APPEL DU MODULE FONCTION
|
||||||
|
└── Le système SAP appelle TABLEFRAME_ZFGPAYMENTRULES
|
||||||
|
(typiquement depuis la transaction SM30 ou une transaction Z dédiée)
|
||||||
|
|
||||||
|
2. DÉLÉGATION IMMÉDIATE
|
||||||
|
└── PERFORM TABLEFRAME TABLES ... USING ...
|
||||||
|
└── Passage de tous les paramètres au sous-programme générique SAP
|
||||||
|
|
||||||
|
3. EXÉCUTION PAR TABLEFRAME (moteur TMG)
|
||||||
|
├── Lecture des métadonnées de la table via X_HEADER et X_NAMTAB
|
||||||
|
├── Application des critères de sélection (DBA_SELLIST / DPL_SELLIST)
|
||||||
|
├── Rendu de l'écran de maintenance avec les fonctions CUA actives
|
||||||
|
│ (en excluant celles listées dans EXCL_CUA_FUNCT)
|
||||||
|
├── Gestion des interactions utilisateur (VIEW_ACTION)
|
||||||
|
└── Traçabilité transport via CORR_NUMBER
|
||||||
|
|
||||||
|
4. RETOUR AU CONTEXTE APPELANT
|
||||||
|
└── Fin du module fonction
|
||||||
|
````
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Points d'attention
|
||||||
|
|
||||||
|
> ⚠️ **Code généré automatiquement**
|
||||||
|
> Ce fichier est produit par le **Table Maintenance Generator (SE54)**. Il ne doit **jamais être modifié manuellement**. Toute régénération via SE54 écrasera les modifications manuelles sans avertissement.
|
||||||
|
|
||||||
|
> ⚠️ **Aucune logique métier ici**
|
||||||
|
> Ce module ne contient aucun contrôle, aucune validation métier. Les règles métier spécifiques aux paiements (`ZDPR_PAYMENTS`) doivent être implémentées dans les **événements TMG** (ex : `01`, `02`...) ou dans le module `TABLEPROC_ZFGPAYMENTRULES`, pas ici.
|
||||||
|
|
||||||
|
> ⚠️ **Dépendance au transport (`CORR_NUMBER`)**
|
||||||
|
> Si le numéro de transport est mal renseigné ou absent, les modifications de customizing peuvent ne pas être transportées en qualité ou en production, entraînant des divergences d'environnement sur les règles de paiement.
|
||||||
|
|
||||||
|
> ⚠️ **Gestion des exclusions CUA (`EXCL_CUA_FUNCT`)**
|
||||||
|
> Une mauvaise gestion de cette liste peut rendre inaccessibles des actions critiques (ex : suppression, création) ou, à l'inverse, exposer des actions non souhaitées à certains profils utilisateurs. À vérifier en lien avec les autorisations SAP.
|
||||||
|
|
||||||
|
> ℹ️ **Pas de gestion d'erreur explicite**
|
||||||
|
> La gestion des exceptions est entièrement déléguée à `TABLEFRAME`. En cas d'anomalie, les messages d'erreur proviennent du moteur TMG standard et peuvent être peu contextualisés pour l'utilisateur métier.
|
||||||
@ -0,0 +1,76 @@
|
|||||||
|
The user wants me to document an SAP ABAP function module. Let me analyze the code and produce the requested documentation.
|
||||||
|
|
||||||
|
# Documentation : `TABLEPROC_ZFGPAYMENTRULES`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Algorithmie
|
||||||
|
|
||||||
|
Ce module fonction est un **point d'entrée de traitement de table** généré automatiquement par SAP dans le cadre d'un groupe de fonctions (`ZFGPAYMENTRULES`). Son rôle algorithmique est minimal et délégué entièrement : il se contente d'appeler la routine `TABLEPROC` via l'instruction `PERFORM`.
|
||||||
|
|
||||||
|
La logique métier réelle n'est pas contenue dans ce module fonction mais dans la sous-routine `TABLEPROC`, qui est définie ailleurs dans le groupe de fonctions (typiquement dans le programme principal du groupe de fonctions ou dans un include dédié).
|
||||||
|
|
||||||
|
Ce pattern est un **standard SAP** pour les modules fonctions de type "table maintenance" générés par le générateur de vues de maintenance (transaction `SE54`).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Objets
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `TABLEPROC_ZFGPAYMENTRULES` | Module Fonction (FUNCTION) | Point d'entrée exposé à l'extérieur du groupe de fonctions. Déclenche le traitement de la table. |
|
||||||
|
| `ZFGPAYMENTRULES` | Groupe de fonctions (FUGR) | Conteneur du module fonction. Regroupe l'ensemble des modules fonctions et sous-routines liées aux règles de paiement (`PAYMENTS`). |
|
||||||
|
| `TABLEPROC` | Sous-routine (FORM/PERFORM) | Routine centrale qui implémente la logique de traitement de la table de maintenance. Générée par SAP via `SE54`. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
|
||||||
|
- **Groupe de fonctions `ZFGPAYMENTRULES`** : Ce module fonction appartient à ce groupe. Il dépend de toutes les données globales, includes et sous-routines déclarés dans ce groupe.
|
||||||
|
- **Sous-routine `TABLEPROC`** : Dépendance directe et unique. Sans cette routine définie dans le contexte du groupe de fonctions, le module planterait à l'exécution (`PERFORM TABLEPROC` non résolu).
|
||||||
|
- **Table de maintenance associée** : Selon le contexte de génération (`SE54`), ce module fonction est lié à une table ou vue de maintenance dont le nom est probablement `ZFGPAYMENTRULES` ou une table sous-jacente du domaine paiements (`ZDPR_PAYMENTS`).
|
||||||
|
- **Vue de génération `SE54`** : L'ensemble du code (ce fichier inclus) a été généré automatiquement. Toute modification manuelle peut être écrasée en cas de re-génération via `SE54`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Flux de traitement
|
||||||
|
|
||||||
|
````
|
||||||
|
[Appel externe ou écran de maintenance de table]
|
||||||
|
|
|
||||||
|
v
|
||||||
|
FUNCTION TABLEPROC_ZFGPAYMENTRULES
|
||||||
|
|
|
||||||
|
v
|
||||||
|
PERFORM TABLEPROC (sous-routine du groupe de fonctions)
|
||||||
|
|
|
||||||
|
v
|
||||||
|
[Logique de maintenance de table : INSERT / UPDATE / DELETE / SELECT]
|
||||||
|
|
|
||||||
|
v
|
||||||
|
[Retour à l'appelant]
|
||||||
|
````
|
||||||
|
|
||||||
|
1. **Invocation** : Le module fonction est appelé par SAP, typiquement via la transaction `SM30` ou `SM31` lors de la maintenance d'une table/vue personnalisée.
|
||||||
|
2. **Délégation** : Appel immédiat et sans condition de la sous-routine `TABLEPROC`.
|
||||||
|
3. **Traitement** : La sous-routine `TABLEPROC` exécute les opérations CRUD sur la table cible, gère les événements (avant/après sauvegarde, validations, etc.).
|
||||||
|
4. **Fin** : Retour au framework SAP qui prend en charge l'affichage et la confirmation utilisateur.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points d'attention
|
||||||
|
|
||||||
|
> **Risque de régénération**
|
||||||
|
> Ce fichier est entièrement généré par SAP (`SE54`). Toute modification manuelle sera **écrasée** si la vue de maintenance est re-générée. Les évolutions métier doivent être intégrées via les événements de l'outil de génération, pas directement dans ce fichier.
|
||||||
|
|
||||||
|
> **Opacité de la logique**
|
||||||
|
> Le module fonction ne contient aucune logique propre. Le code réel est dans `TABLEPROC` : il faut analyser cette sous-routine pour comprendre les règles métier effectives sur les données de paiement.
|
||||||
|
|
||||||
|
> **Absence de gestion d'erreurs**
|
||||||
|
> Aucun mécanisme de gestion d'exception (`TRY/CATCH`, `MESSAGE`, retour de code d'erreur) n'est présent dans ce wrapper. Les erreurs éventuelles sont gérées (ou non) dans `TABLEPROC`.
|
||||||
|
|
||||||
|
> **Sensibilité des données**
|
||||||
|
> Le nom du package (`ZDPR_PAYMENTS`) indique que les données traitées concernent des **règles de paiement**. Toute anomalie dans `TABLEPROC` (validation manquante, autorisation insuffisante) peut avoir un impact financier direct.
|
||||||
|
|
||||||
|
> **Autorisations**
|
||||||
|
> L'accès à ce module fonction et à la table de maintenance sous-jacente doit être contrôlé par des objets d'autorisation SAP adéquats (typiquement `S_TABU_DIS` ou un objet personnalisé). Un manque de contrôle pourrait permettre des modifications non autorisées des règles de paiement.
|
||||||
@ -0,0 +1,60 @@
|
|||||||
|
The user wants me to document an SAP ABAP file. The file is a "TOP" include of a Function Group (FUGR) named ZFGPAYMENTS. The content is minimal - just the FUNCTION-POOL declaration with a commented-out local class definition include.
|
||||||
|
|
||||||
|
# Documentation – `zfgpayments.fugr.lzfgpaymentstop.abap`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Algorithmie
|
||||||
|
|
||||||
|
Ce fichier est le **programme principal (TOP Include)** du groupe de fonctions (`FUNCTION-POOL`) `ZFGPAYMENTS`. Dans l'architecture SAP ABAP, chaque groupe de fonctions possède un include dit "TOP" dont le rôle est **déclaratif et structurant** : il ne contient pas de logique métier propre mais définit le contexte global du pool.
|
||||||
|
|
||||||
|
Son unique instruction active est la déclaration du pool :
|
||||||
|
|
||||||
|
````abap
|
||||||
|
FUNCTION-POOL ZFGPAYMENTS.
|
||||||
|
````
|
||||||
|
|
||||||
|
Cela indique au système ABAP que tous les includes et modules de fonctions associés appartiennent à ce groupe. La ligne commentée suggère qu'une définition de classe locale (`LZFGPAYMENTSD`) était envisagée ou existait, mais a été désactivée.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Objets
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `ZFGPAYMENTS` | `FUNCTION-POOL` | Groupe de fonctions principal dédié aux paiements (`PAYMENTS`). Conteneur logique regroupant des modules de fonctions liés au domaine paiement. |
|
||||||
|
| `LZFGPAYMENTSD` *(commenté)* | Include (Local Class Definition) | Fichier d'include standard prévu pour déclarer des **classes locales** au groupe de fonctions. Non actif dans l'état actuel. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
|
||||||
|
- **Groupe de fonctions `ZFGPAYMENTS`** : Ce TOP include est le point d'entrée obligatoire. Tous les autres includes du groupe en dépendent (includes de données globales, includes des modules de fonctions, etc.), selon la convention de nommage SAP :
|
||||||
|
- `LZFGPAYMENTSF01`, `LZFGPAYMENTSF02`... (sous-routines)
|
||||||
|
- `LZFGPAYMENTSI01`... (PBO/PAI si écrans associés)
|
||||||
|
- `LZFGPAYMENTS` (données globales)
|
||||||
|
- `LZFGPAYMENTSD` (classes locales, ici commenté)
|
||||||
|
|
||||||
|
- **MESSAGE-ID** : Le commentaire `"MESSAGE-ID ..` indique qu'aucun message class n'est associé au pool pour l'instant. Si des messages SAP (`MESSAGE` statement) sont utilisés dans les fonctions du groupe, une classe de messages devrait être renseignée ici.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Flux de traitement
|
||||||
|
|
||||||
|
Ce fichier étant purement déclaratif, il n'y a pas de flux algorithmique à proprement parler. Son cycle d'exécution est le suivant :
|
||||||
|
|
||||||
|
1. **Chargement du pool** : Lors du premier appel à une fonction du groupe `ZFGPAYMENTS`, le système SAP charge en mémoire l'intégralité du groupe de fonctions, en commençant par ce TOP include.
|
||||||
|
2. **Initialisation du contexte global** : Le `FUNCTION-POOL` établit la portée de mémoire partagée entre toutes les fonctions du groupe (zone mémoire commune, persistante pendant la session utilisateur).
|
||||||
|
3. **Disponibilité des fonctions membres** : Les modules de fonctions déclarés dans les autres includes deviennent appelables par les programmes externes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points d'attention
|
||||||
|
|
||||||
|
- ⚠️ **Absence de MESSAGE-ID** : Le paramètre `MESSAGE-ID` n'est pas renseigné. Si les fonctions du groupe utilisent des instructions `MESSAGE`, cela peut provoquer des comportements inattendus ou nécessiter de spécifier explicitement la classe de messages à chaque appel.
|
||||||
|
|
||||||
|
- ⚠️ **Include `LZFGPAYMENTSD` commenté** : La ligne commentée suggère une intention de définir des classes locales qui n'a pas été concrétisée. Si des refactorisations futures veulent introduire de l'orienté objet dans ce pool, il faudra décommenter et alimenter cet include.
|
||||||
|
|
||||||
|
- ℹ️ **Fichier minimal = risque faible** : Ce TOP include ne contient aucune logique, le risque de régression direct est nul. Cependant, toute modification de ce fichier (ajout d'un `MESSAGE-ID`, décommentage de l'include) impacte **l'ensemble des fonctions du groupe**.
|
||||||
|
|
||||||
|
- ℹ️ **Convention de nommage Z*** : Le préfixe `Z` confirme qu'il s'agit d'un développement **spécifique client** (custom), non livré par SAP standard. Il est donc entièrement sous la responsabilité de l'équipe de développement pour la maintenance et les transports.
|
||||||
103
documentation/documentation_zfgpayments.fugr.saplzfgpayments.md
Normal file
103
documentation/documentation_zfgpayments.fugr.saplzfgpayments.md
Normal file
@ -0,0 +1,103 @@
|
|||||||
|
The user wants me to document an SAP ABAP file. This is the main program file for a Function Group called `ZFGPAYMENTS`. It's a standard SAP-generated wrapper file (`SAPLZFGPAYMENTS`) that includes other components. Let me analyze what's there and document it properly.
|
||||||
|
|
||||||
|
# Documentation Technique — `saplzfgpayments.abap`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Algorithmie
|
||||||
|
|
||||||
|
Ce fichier est le **programme principal généré automatiquement** par SAP pour le groupe de fonctions `ZFGPAYMENTS` (préfixe `ZFG` indiquant un développement custom lié aux paiements — `PAYMENTS`).
|
||||||
|
|
||||||
|
En ABAP, un groupe de fonctions est une bibliothèque de modules fonctionnels partageant un contexte global (données, mémoire). Le fichier `SAPLZFGPAYMENTS` est le **point d'entrée technique** : il ne contient pas de logique métier propre, mais orchestre l'assemblage des différents composants du groupe via des directives `INCLUDE`.
|
||||||
|
|
||||||
|
Son rôle se limite à **déclarer l'ordre de chargement** des sous-programmes inclus. SAP génère et maintient ce fichier automatiquement lors de l'activation du groupe de fonctions dans SE37/SE80.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Objets
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `ZFGPAYMENTS` | Groupe de fonctions (Function Group) | Conteneur logique regroupant les modules fonctionnels liés aux paiements |
|
||||||
|
| `LZFGPAYMENTSTOP` | Include ABAP | Déclarations globales du groupe : données, types, constantes, variables partagées entre tous les modules fonctionnels |
|
||||||
|
| `LZFGPAYMENTSUXX` | Include ABAP | Contient les stubs (squelettes) des **modules fonctionnels** (Function Modules) du groupe |
|
||||||
|
| `LZFGPAYMENTSF` | Include ABAP (commenté) | Sous-routines internes (`FORM...ENDFORM`) — non activé |
|
||||||
|
| `LZFGPAYMENTSO` | Include ABAP (commenté) | Modules PBO (Process Before Output) pour écrans — non activé |
|
||||||
|
| `LZFGPAYMENTSI` | Include ABAP (commenté) | Modules PAI (Process After Input) pour écrans — non activé |
|
||||||
|
| `LZFGPAYMENTSE` | Include ABAP (commenté) | Événements ABAP (ex. `AT SELECTION-SCREEN`) — non activé |
|
||||||
|
| `LZFGPAYMENTSP` | Include ABAP (commenté) | Implémentations de classes locales — non activé |
|
||||||
|
| `LZFGPAYMENTST99` | Include ABAP (commenté) | Tests unitaires ABAP Unit — non activé |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
|
||||||
|
```
|
||||||
|
SAPLZFGPAYMENTS (programme principal)
|
||||||
|
│
|
||||||
|
├── LZFGPAYMENTSTOP ← [ACTIF] Déclarations globales
|
||||||
|
│ (types, variables, constantes partagés)
|
||||||
|
│
|
||||||
|
└── LZFGPAYMENTSUXX ← [ACTIF] Modules fonctionnels
|
||||||
|
(logique métier paiements)
|
||||||
|
|
||||||
|
Includes commentés (non chargés au runtime) :
|
||||||
|
├── LZFGPAYMENTSF (sous-routines)
|
||||||
|
├── LZFGPAYMENTSO (PBO screens)
|
||||||
|
├── LZFGPAYMENTSI (PAI screens)
|
||||||
|
├── LZFGPAYMENTSE (événements)
|
||||||
|
├── LZFGPAYMENTSP (classes locales)
|
||||||
|
└── LZFGPAYMENTST99 (ABAP Unit tests)
|
||||||
|
```
|
||||||
|
|
||||||
|
**Dépendances externes potentielles** (non visibles dans ce fichier, mais à rechercher dans `LZFGPAYMENTSUXX` et `LZFGPAYMENTSTOP`) :
|
||||||
|
- Tables SAP standard liées aux paiements (ex. `REGUH`, `REGUP`, `BKPF`, `BSEG`)
|
||||||
|
- Éventuels appels à des BAPIs ou RFC de paiement SAP FI
|
||||||
|
- Objets du programme parent `ZDPR_PAYMENTS` (visible dans le chemin du package source)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Flux de traitement
|
||||||
|
|
||||||
|
````
|
||||||
|
1. CHARGEMENT DU GROUPE DE FONCTIONS
|
||||||
|
└── SAP charge SAPLZFGPAYMENTS dans la mémoire de la session utilisateur
|
||||||
|
|
||||||
|
2. INCLUDE LZFGPAYMENTSTOP
|
||||||
|
└── Initialisation du contexte global :
|
||||||
|
- Déclaration des types de données
|
||||||
|
- Déclaration des variables/tables globales
|
||||||
|
- Constantes métier (statuts paiement, codes retour, etc.)
|
||||||
|
|
||||||
|
3. INCLUDE LZFGPAYMENTSUXX
|
||||||
|
└── Enregistrement des modules fonctionnels disponibles :
|
||||||
|
- Chaque FM est défini avec ses paramètres IMPORTING / EXPORTING / TABLES / EXCEPTIONS
|
||||||
|
- La logique interne de chaque FM est exécutée à l'appel par le programme appelant
|
||||||
|
|
||||||
|
4. APPEL EXTERNE (programme client)
|
||||||
|
└── CALL FUNCTION 'ZFG_PAYMENTS_XXXXX'
|
||||||
|
- Le FM ciblé s'exécute dans le contexte mémoire du groupe
|
||||||
|
- Les données globales (TOP) sont accessibles et persistantes entre appels
|
||||||
|
````
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points d'attention
|
||||||
|
|
||||||
|
### Risques techniques
|
||||||
|
|
||||||
|
- **Fichier généré automatiquement** : Ce fichier ne doit **jamais être modifié manuellement**. Toute modification est écrasée lors de l'activation du groupe de fonctions dans SAP. La logique métier doit être placée uniquement dans les includes dédiés (`UXX`, `TOP`, etc.).
|
||||||
|
|
||||||
|
- **Includes commentés non utilisés** : Les includes `F`, `O`, `I`, `E`, `P`, `T99` sont commentés, ce qui signifie que le groupe de fonctions ne dispose pas de sous-routines organisées, ni d'écrans, ni de tests unitaires actifs. Cela peut indiquer une conception simplifiée ou une dette technique à combler.
|
||||||
|
|
||||||
|
- **Absence de tests unitaires** (`LZFGPAYMENTST99` commenté) : Aucun test automatisé n'est en place. En contexte de paiements (données financières sensibles), c'est un risque significatif de non-régression.
|
||||||
|
|
||||||
|
- **Contexte mémoire partagé** : Les variables globales déclarées dans `TOP` sont partagées entre tous les modules fonctionnels du groupe et persistent durant la session. Un état non réinitialisé entre deux appels peut provoquer des comportements inattendus.
|
||||||
|
|
||||||
|
### Risques métier
|
||||||
|
|
||||||
|
- **Domaine paiements** : Le groupe appartient au package `ZDPR_PAYMENTS`, ce qui implique des traitements financiers sensibles (virements, règlements fournisseurs/clients). Toute anomalie peut avoir un impact direct sur les flux financiers réels.
|
||||||
|
|
||||||
|
- **Traçabilité** : Sans les includes de logs ou d'événements actifs, il faut vérifier que la journalisation des traitements est bien assurée dans les modules fonctionnels (`UXX`).
|
||||||
|
|
||||||
|
- **Couplage avec l'appelant** : La robustesse du groupe dépend de la gestion des exceptions dans `LZFGPAYMENTSUXX`. Si les exceptions des FM ne sont pas exhaustivement déclarées et gérées, des erreurs silencieuses sont possibles.
|
||||||
@ -0,0 +1,203 @@
|
|||||||
|
The user wants me to document the ABAP function module `ZBDC_VENDOR_PAYMENTS_CLOUD` in markdown format with specific sections. Let me analyze the code thoroughly.
|
||||||
|
|
||||||
|
This is a BDC (Batch Data Communication) function module that automates the SAP transaction F-53 (Post Outgoing Payments) for vendor payments. It uses the Call Transaction method via `perform bdc_transaction`.
|
||||||
|
|
||||||
|
# Documentation : `ZBDC_VENDOR_PAYMENTS_CLOUD`
|
||||||
|
|
||||||
|
**Fichier :** `zfgpayments.fugr.zbdc_vendor_payments_cloud.abap`
|
||||||
|
**Groupe de fonctions :** `ZFGPAYMENTS`
|
||||||
|
**Transaction cible :** `F-53` (Saisie de paiements sortants fournisseurs)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Algorithmie
|
||||||
|
|
||||||
|
La fonction `ZBDC_VENDOR_PAYMENTS_CLOUD` est un **module BDC (Batch Data Communication)** généré automatiquement (via l'enregistrement de transaction SAP). Son rôle est de **simuler la saisie manuelle** de la transaction standard SAP **F-53** ("Post Outgoing Payments" - Paiements sortants fournisseurs) en pilotant les dynpros (écrans) de cette transaction via une séquence de champs prédéfinis.
|
||||||
|
|
||||||
|
Le principe BDC consiste à :
|
||||||
|
1. Construire une table de données écran-par-écran (via `bdc_dynpro` et `bdc_field`),
|
||||||
|
2. Puis soumettre cette table à la transaction cible via `bdc_transaction`,
|
||||||
|
3. La transaction SAP s'exécute alors comme si un utilisateur avait saisi les données manuellement.
|
||||||
|
|
||||||
|
Le mode d'exécution peut être **interactif** (avec affichage des écrans), **en arrière-plan** (batch silencieux), ou **via session de batch input** (enregistrement dans une file d'attente pour exécution différée).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Objets
|
||||||
|
|
||||||
|
## Paramètres d'interface
|
||||||
|
|
||||||
|
### Paramètres BDC de contrôle (IMPORTING)
|
||||||
|
|
||||||
|
| Paramètre | Type de référence | Défaut | Rôle |
|
||||||
|
|-----------|------------------|--------|------|
|
||||||
|
| `CTU` | `APQI-PUTACTIVE` | `'X'` | Activation de la session batch input (`X` = actif) |
|
||||||
|
| `MODE` | `APQI-PUTACTIVE` | `'N'` | Mode d'exécution : `N`=no display, `A`=affichage de tous les écrans, `E`=affichage en cas d'erreur |
|
||||||
|
| `UPDATE` | `APQI-PUTACTIVE` | `'L'` | Mode de mise à jour : `L`=local (synchrone), `A`=asynchrone, `S`=synchrone |
|
||||||
|
| `GROUP` | `APQI-GROUPID` | Optionnel | Nom du groupe de session batch input |
|
||||||
|
| `USER` | `APQI-USERID` | Optionnel | Utilisateur propriétaire de la session batch input |
|
||||||
|
| `KEEP` | `APQI-QERASE` | Optionnel | Conservation de la session après traitement (`X`=conserver) |
|
||||||
|
| `HOLDDATE` | `APQI-STARTDATE` | Optionnel | Date de départ planifiée pour la session |
|
||||||
|
| `NODATA` | `APQI-PUTACTIVE` | `'/'` | Caractère représentant un champ vide/non renseigné dans le BDC |
|
||||||
|
|
||||||
|
### Paramètres de données métier (IMPORTING)
|
||||||
|
|
||||||
|
| Paramètre | Champ SAP | Défaut | Signification métier |
|
||||||
|
|-----------|-----------|--------|----------------------|
|
||||||
|
| `BLDAT_001` | `BKPF-BLDAT` | `04/17/2017` | Date de pièce comptable |
|
||||||
|
| `BLART_002` | `BKPF-BLART` | `KZ` | Type de pièce (`KZ` = paiement fournisseur) |
|
||||||
|
| `BUKRS_003` | `BKPF-BUKRS` | `1710` | Code société |
|
||||||
|
| `BUDAT_004` | `BKPF-BUDAT` | `04/21/2017` | Date de comptabilisation |
|
||||||
|
| `MONAT_005` | `BKPF-MONAT` | `4` | Période comptable (mois) |
|
||||||
|
| `WAERS_006` | `BKPF-WAERS` | `USD` | Devise de la pièce |
|
||||||
|
| `KONTO_007` | `RF05A-KONTO` | `11001000` | Compte de contrepartie (compte bancaire) |
|
||||||
|
| `WRBTR_008` | `BSEG-WRBTR` | `204182.87` | Montant en devise de la pièce (en-tête) |
|
||||||
|
| `VALUT_009` | `BSEG-VALUT` | `04/17/2017` | Date de valeur bancaire |
|
||||||
|
| `AGKON_010` | `RF05A-AGKON` | `USSU_V8001` | Compte de compensation (numéro du fournisseur) |
|
||||||
|
| `AGKOA_011` | `RF05A-AGKOA` | `K` | Type de compte de compensation (`K` = fournisseur) |
|
||||||
|
| `XNOPS_012` | `RF05A-XNOPS` | `X` | Indicateur de non-compensation automatique |
|
||||||
|
| `XPOS1_01_013` | `RF05A-XPOS1(01)` | `` (vide) | Sélection poste ouvert ligne 1 (non coché) |
|
||||||
|
| `XPOS1_03_014` | `RF05A-XPOS1(03)` | `X` | Sélection poste ouvert ligne 3 (coché) |
|
||||||
|
| `SEL01_01_015` | `RF05A-SEL01(01)` | `5100002254` | Numéro de facture fournisseur à solder |
|
||||||
|
| `ABPOS_016` | `RF05A-ABPOS` | `1` | Numéro de poste de compensation |
|
||||||
|
| `WRBTR_017` | `BSEG-WRBTR` | `204,182.87` | Montant du poste de paiement (avec séparateur de milliers) |
|
||||||
|
| `VALUT_018` | `BSEG-VALUT` | `04/17/2017` | Date de valeur du poste |
|
||||||
|
| `FMORE_019` | `DKACB-FMORE` | `X` | Indicateur "plus de champs" (affichage des données supplémentaires) |
|
||||||
|
| `HBKID_020/022/024` | `BSEG-HBKID` | `USBK1` | Identifiant banque (répété 3 fois sur dynpro 0330) |
|
||||||
|
| `HKTID_021/023/025` | `BSEG-HKTID` | `USAC1` | Identifiant compte bancaire (répété 3 fois) |
|
||||||
|
|
||||||
|
### Paramètres de sortie (EXPORTING / TABLES)
|
||||||
|
|
||||||
|
| Paramètre | Type | Rôle |
|
||||||
|
|-----------|------|------|
|
||||||
|
| `SUBRC` | `SYST-SUBRC` | Code retour de la fonction (0 = succès) |
|
||||||
|
| `MESSTAB` | `BDCMSGCOLL` | Table des messages retournés par la transaction BDC |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Structures de données utilisées
|
||||||
|
|
||||||
|
| Objet | Nature | Description |
|
||||||
|
|-------|--------|-------------|
|
||||||
|
| `BDCDATA` | Structure | Contient les données BDC : programme, dynpro, champs et valeurs |
|
||||||
|
| `BDCMSGCOLL` | Structure | Collection des messages SAP issus de l'exécution BDC |
|
||||||
|
| `BKPF` | Table | En-tête des pièces comptables (FI) |
|
||||||
|
| `BSEG` | Table | Postes des pièces comptables (FI) |
|
||||||
|
| `APQI` | Table | File de traitement batch input |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dépendances
|
||||||
|
|
||||||
|
## Sous-routines appelées (PERFORM ... USING)
|
||||||
|
|
||||||
|
Ces routines sont définies dans l'include standard `BDCRECXY` (inclus en fin de fonction) :
|
||||||
|
|
||||||
|
| Routine | Rôle |
|
||||||
|
|---------|------|
|
||||||
|
| `bdc_nodata` | Définit le caractère "no data" pour les champs BDC vides |
|
||||||
|
| `open_group` | Ouvre une session batch input (si mode session) |
|
||||||
|
| `bdc_dynpro` | Ajoute une entrée de changement d'écran dans la table BDC interne |
|
||||||
|
| `bdc_field` | Ajoute un champ avec sa valeur dans la table BDC interne |
|
||||||
|
| `bdc_transaction` | Exécute la transaction SAP (`F-53`) avec la table BDC construite |
|
||||||
|
| `close_group` | Ferme et valide la session batch input ouverte |
|
||||||
|
|
||||||
|
## Include standard
|
||||||
|
|
||||||
|
```abap
|
||||||
|
INCLUDE BDCRECXY.
|
||||||
|
```
|
||||||
|
|
||||||
|
Cet include standard SAP fournit les sous-routines BDC génériques (`bdc_dynpro`, `bdc_field`, `bdc_transaction`, `open_group`, `close_group`, `bdc_nodata`). Il est systématiquement présent dans les fonctions générées par l'enregistrement BDC.
|
||||||
|
|
||||||
|
## Transaction SAP cible
|
||||||
|
|
||||||
|
| Transaction | Description |
|
||||||
|
|------------|-------------|
|
||||||
|
| `F-53` | Post Outgoing Payments - Saisie manuelle de paiements sortants (module FI-AP) |
|
||||||
|
|
||||||
|
## Dynpros impliqués
|
||||||
|
|
||||||
|
| Programme | N° Dynpro | Rôle dans F-53 |
|
||||||
|
|-----------|-----------|----------------|
|
||||||
|
| `SAPMF05A` | `0103` | Écran principal de saisie de l'en-tête du paiement |
|
||||||
|
| `SAPMF05A` | `0731` | Écran de sélection des postes ouverts fournisseur |
|
||||||
|
| `SAPDF05X` | `3100` | Écran de compensation des postes ouverts |
|
||||||
|
| `SAPMF05A` | `0700` | Écran de saisie des postes supplémentaires / validation |
|
||||||
|
| `SAPMF05A` | `0300` | Écran de saisie du poste de paiement (crédit banque) |
|
||||||
|
| `SAPLKACB` | `0002` | Popup de saisie des objets de coût (CO-PA) |
|
||||||
|
| `SAPMF05A` | `0330` | Écran de saisie des informations bancaires |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Flux de traitement
|
||||||
|
|
||||||
|
````
|
||||||
|
[DÉBUT]
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
1. Initialisation : SUBRC = 0
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
2. bdc_nodata(NODATA)
|
||||||
|
└─ Définit le caractère de champ vide ('/')
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
3. open_group(GROUP, USER, KEEP, HOLDDATE, CTU)
|
||||||
|
└─ Ouvre la session batch input si CTU = 'X'
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
4. DYNPRO SAPMF05A / 0103 ─── En-tête du paiement
|
||||||
|
├─ Cursor sur RF05A-XPOS1(03)
|
||||||
|
├─ OKCode = '=PA' (valider / passer à l'écran suivant)
|
||||||
|
├─ BKPF-BLDAT → Date de pièce
|
||||||
|
├─ BKPF-BLART → Type de pièce (KZ)
|
||||||
|
├─ BKPF-BUKRS → Société
|
||||||
|
├─ BKPF-BUDAT → Date comptabilisation
|
||||||
|
├─ BKPF-MONAT → Période
|
||||||
|
├─ BKPF-WAERS → Devise
|
||||||
|
├─ RF05A-KONTO → Compte bancaire
|
||||||
|
├─ BSEG-WRBTR → Montant
|
||||||
|
├─ BSEG-VALUT → Date de valeur
|
||||||
|
├─ RF05A-AGKON → Fournisseur (compte à solder)
|
||||||
|
├─ RF05A-AGKOA → Type 'K' (fournisseur)
|
||||||
|
├─ RF05A-XNOPS → Pas de compensation auto
|
||||||
|
├─ RF05A-XPOS1(01) → Ligne 1 (non sélectionnée)
|
||||||
|
└─ RF05A-XPOS1(03) → Ligne 3 (sélectionnée)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
5. DYNPRO SAPMF05A / 0731 ─── Sélection postes ouverts (1ère fois)
|
||||||
|
├─ OKCode = '/00' (Enter)
|
||||||
|
└─ RF05A-SEL01(01) → Numéro de facture à compenser
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
6. DYNPRO SAPMF05A / 0731 ─── Sélection postes ouverts (2ème fois)
|
||||||
|
└─ OKCode = '=PA' (valider la sélection)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
7. DYNPRO SAPDF05X / 3100 ─── Compensation des postes
|
||||||
|
├─ OKCode = '=AB' (affecter/compenser)
|
||||||
|
├─ Cursor sur DF05B-PSSKT(01)
|
||||||
|
└─ RF05A-ABPOS → Numéro de poste de compensation (1)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
8. DYNPRO SAPMF05A / 0700 ─── Écran de validation intermédiaire
|
||||||
|
├─ Cursor sur RF05A-AZEI1(01)
|
||||||
|
└─ OKCode = '=PI' (poste individuel / afficher poste)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
9. DYNPRO SAPMF05A / 0300 ─── Saisie du poste de paiement
|
||||||
|
├─ OKCode = '=ZK' (données de paiement)
|
||||||
|
├─ BSEG-WRBTR → Montant avec séparateur milliers
|
||||||
|
├─ BSEG-VALUT → Date de valeur
|
||||||
|
└─ DKACB-FMORE → Afficher plus de champs
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
10. DYNPRO SAPLKACB / 0002 ─── Popup objets de coût (CO)
|
||||||
|
├─ Cursor sur COBL-KOSTL (centre de coût)
|
||||||
|
└─ OKCode = '=ENTE' (valider sans saisir de centre de coût)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
11. DYNPRO SAPMF05A / 0330 ─── Saisie bancaire (passage 1)
|
||||||
|
├─ OKCode = '/00' (Enter)
|
||||||
|
|
||||||
@ -0,0 +1,181 @@
|
|||||||
|
The user wants me to document the ABAP function module `ZFI_OUT_PAYMENT_POST_CLEAR` in markdown format with specific sections.
|
||||||
|
|
||||||
|
# Documentation — `ZFI_OUT_PAYMENT_POST_CLEAR`
|
||||||
|
|
||||||
|
**Groupe de fonctions :** `ZFGPAYMENTS`
|
||||||
|
**Fichier :** `zfgpayments.fugr.zfi_out_payment_post_clear.abap`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Algorithmie
|
||||||
|
|
||||||
|
Cette fonction module réalise le **paiement et le lettrage simultané d'un poste ouvert fournisseur** dans SAP FI (Financial Accounting). Elle suit une logique en quatre temps :
|
||||||
|
|
||||||
|
1. **Sélection de postes ouverts** : elle interroge les postes ouverts fournisseurs (type de compte `K`) pour un numéro de pièce précis (`IM_BELNR`), dans la société et la devise données.
|
||||||
|
2. **Contrôle du type de pièce** : le traitement ne se poursuit que si la pièce trouvée est de type `KR` (facture fournisseur) ou `RE` (facture entrée marchandises). Cela garantit qu'on ne paie que des factures fournisseurs légitimes.
|
||||||
|
3. **Construction de la pièce comptable de paiement** : un poste G/L bancaire est construit (en-tête + ligne + devise) avec la clé de comptabilisation `50` (crédit), le compte général de banque (`IM_HKONT`), et la date de valeur (`IM_VALUT`).
|
||||||
|
4. **Comptabilisation et lettrage** : la pièce de paiement est générée et simultanément lettrée avec le poste ouvert via `FI_DOCUMENT_GENERATE_AND_CLEAR`, puis la transaction est commitée.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Objets
|
||||||
|
|
||||||
|
## Paramètres d'entrée (IMPORTING)
|
||||||
|
|
||||||
|
| Paramètre | Type SAP | Description |
|
||||||
|
|---|---|---|
|
||||||
|
| `IM_BUKRS` | `BUKRS` | Code société |
|
||||||
|
| `IM_GJAHR` | `GJAHR` | Exercice comptable |
|
||||||
|
| `IM_BELNR` | `BELNR_D` | Numéro de la pièce à lettrer |
|
||||||
|
| `IM_KONKO` | `KONKO` | Compte fournisseur (compte collectif) |
|
||||||
|
| `IM_WAERS` | `WAERS` | Devise de la transaction |
|
||||||
|
| `IM_CLR_TR` | `AUGLV` | Type de transaction de lettrage (défaut : `AUSGZAHL` = paiement sortant) |
|
||||||
|
| `IM_HKONT` | `HKONT` | Compte G/L bancaire (contrepartie) |
|
||||||
|
| `IM_KURSF` | `KURSF` | Taux de change (optionnel) |
|
||||||
|
| `IM_WRBTR` | `WRBTR` | Montant à payer en devise |
|
||||||
|
| `IM_VALUT` | `VALUT` | Date de valeur bancaire |
|
||||||
|
| `IM_HBKID` | `HBKID` | Identifiant banque maison (optionnel) |
|
||||||
|
| `IM_HKTID` | `HKTID` | Identifiant compte bancaire maison (optionnel) |
|
||||||
|
|
||||||
|
## Paramètres de sortie (EXPORTING)
|
||||||
|
|
||||||
|
| Paramètre | Type SAP | Description |
|
||||||
|
|---|---|---|
|
||||||
|
| `EX_BELNR` | `BELNR_D` | Numéro de la pièce de paiement générée |
|
||||||
|
| `EX_BUKRS` | `BUKRS` | Société de la pièce générée |
|
||||||
|
| `EX_GJAHR` | `GJAHR` | Exercice de la pièce générée |
|
||||||
|
|
||||||
|
## Variables locales
|
||||||
|
|
||||||
|
| Variable | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `lt_selection_tab` / `ls_selection_tab` | `selection_tab_t` / `selection_tab` | Critères de sélection des postes ouverts (filtre sur `BELNR`) |
|
||||||
|
| `lv_date` | `DATUM` | Date système (date du jour) |
|
||||||
|
| `lt_open_item_tab` / `ls_open_item_tab` | `postab_tab` / `rfops` | Table des postes ouverts retournés |
|
||||||
|
| `ls_acchd` / `lt_acchd` | `acchd` / `acchd_t` | En-tête de la pièce comptable |
|
||||||
|
| `ls_accit` / `lt_accit` | `accit` / `accit_tab` | Ligne(s) de la pièce comptable |
|
||||||
|
| `ls_acccr` / `lt_acccr` | `acccr` / `acccr_tab` | Données devise de la pièce comptable |
|
||||||
|
|
||||||
|
## Constantes
|
||||||
|
|
||||||
|
| Constante | Valeur | Signification |
|
||||||
|
|---|---|---|
|
||||||
|
| `lv_koart` | `'K'` | Type de compte : Fournisseurs |
|
||||||
|
| `lv_bschl` | `'50'` | Clé de comptabilisation : Crédit G/L |
|
||||||
|
| `lv_blart` | `'KZ'` | Type de pièce : Paiement fournisseur |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dépendances
|
||||||
|
|
||||||
|
## Fonctions modules SAP standard appelées
|
||||||
|
|
||||||
|
| Fonction | Rôle |
|
||||||
|
|---|---|
|
||||||
|
| `FI_OPEN_ITEMS_SELECT` | Sélectionne les postes ouverts fournisseurs selon les critères fournis. Filtre par société, compte collectif, devise, type de pièce et table de sélection (numéro de pièce). |
|
||||||
|
| `FI_POSTING_KEY_DATA` | Résout, à partir de la clé de comptabilisation (`50`), le type de compte (`KOART`) et l'indicateur débit/crédit (`SHKZG`). Permet de déterminer dynamiquement le signe du montant. |
|
||||||
|
| `FI_LINE_ITEM_CHECK` | Contrôle et enrichit les structures de la ligne comptable (en-tête, poste, devise) avant génération de la pièce. |
|
||||||
|
| `FI_DOCUMENT_GENERATE_AND_CLEAR` | Génère la pièce de paiement FI et lettrage simultané des postes ouverts sélectionnés. C'est le coeur fonctionnel de la comptabilisation. |
|
||||||
|
| `BAPI_TRANSACTION_COMMIT` | Valide définitivement la transaction en base de données. Appelé avec `WAIT = ABAP_TRUE` pour s'assurer que le commit est synchrone. |
|
||||||
|
|
||||||
|
## Appartenance
|
||||||
|
|
||||||
|
- **Groupe de fonctions :** `ZFGPAYMENTS` (développement custom Z, domaine paiements sortants)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Flux de traitement
|
||||||
|
|
||||||
|
````
|
||||||
|
┌─────────────────────────────────────────────────────────┐
|
||||||
|
│ 1. INITIALISATION │
|
||||||
|
│ - Date courante = sy-datum │
|
||||||
|
│ - Construction du critère de sélection sur BELNR │
|
||||||
|
└────────────────────────┬────────────────────────────────┘
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
┌─────────────────────────────────────────────────────────┐
|
||||||
|
│ 2. SÉLECTION DES POSTES OUVERTS │
|
||||||
|
│ FI_OPEN_ITEMS_SELECT │
|
||||||
|
│ - Filtre : société, compte K, devise, type KZ │
|
||||||
|
│ - Filtre additionnel : numéro de pièce = IM_BELNR │
|
||||||
|
└────────────────────────┬────────────────────────────────┘
|
||||||
|
│
|
||||||
|
┌──────────▼──────────┐
|
||||||
|
│ Table vide ? │
|
||||||
|
│ → Fin sans action │
|
||||||
|
└──────────┬──────────┘
|
||||||
|
│ Non vide
|
||||||
|
▼
|
||||||
|
┌─────────────────────────────────────────────────────────┐
|
||||||
|
│ 3. CONTRÔLE DU TYPE DE PIÈCE │
|
||||||
|
│ - Lecture du 1er enregistrement │
|
||||||
|
│ - BLART = 'KR' (facture fournisseur) │
|
||||||
|
│ ou = 'RE' (facture entrée marchandises) ? │
|
||||||
|
└────────────────────────┬────────────────────────────────┘
|
||||||
|
│ Oui
|
||||||
|
▼
|
||||||
|
┌─────────────────────────────────────────────────────────┐
|
||||||
|
│ 4. CONSTRUCTION DE LA PIÈCE DE PAIEMENT │
|
||||||
|
│ a) En-tête (ACCHD) : type BKPFF, procédure RFBU │
|
||||||
|
│ b) Ligne (ACCIT) : position 1, type KZ, date valeur│
|
||||||
|
│ compte G/L banque, clé 50 │
|
||||||
|
│ banque maison si renseignée │
|
||||||
|
│ c) FI_POSTING_KEY_DATA → koart + shkzg │
|
||||||
|
│ d) Devise (ACCCR) : montant, devise, taux change │
|
||||||
|
│ inversion signe si crédit (H) │
|
||||||
|
└────────────────────────┬────────────────────────────────┘
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
┌─────────────────────────────────────────────────────────┐
|
||||||
|
│ 5. CONTRÔLE DES LIGNES │
|
||||||
|
│ FI_LINE_ITEM_CHECK │
|
||||||
|
│ - Enrichissement et validation des structures │
|
||||||
|
└────────────────────────┬────────────────────────────────┘
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
┌─────────────────────────────────────────────────────────┐
|
||||||
|
│ 6. COMPTABILISATION ET LETTRAGE │
|
||||||
|
│ FI_DOCUMENT_GENERATE_AND_CLEAR │
|
||||||
|
│ - Génère la pièce KZ │
|
||||||
|
│ - Lettrage avec les postes ouverts │
|
||||||
|
│ - Retourne EX_BELNR / EX_BUKRS / EX_GJAHR │
|
||||||
|
└────────────────────────┬────────────────────────────────┘
|
||||||
|
│ EX_BELNR non vide
|
||||||
|
▼
|
||||||
|
┌─────────────────────────────────────────────────────────┐
|
||||||
|
│ 7. COMMIT │
|
||||||
|
│ BAPI_TRANSACTION_COMMIT (WAIT = X) │
|
||||||
|
│ - Validation synchrone en base │
|
||||||
|
└─────────────────────────────────────────────────────────┘
|
||||||
|
````
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Points d'attention
|
||||||
|
|
||||||
|
## Risques techniques
|
||||||
|
|
||||||
|
- **Absence de gestion d'erreurs sur `FI_OPEN_ITEMS_SELECT`** : les exceptions (`company_code_missing`, `account_missing`, etc.) sont déclarées mais aucun traitement n'est prévu en cas de déclenchement. En cas d'erreur, la fonction se termine silencieusement sans retourner d'information à l'appelant.
|
||||||
|
|
||||||
|
- **Exception `ERROR_MESSAGE` non levée** : la signature déclare une exception `ERROR_MESSAGE`, mais elle n'est jamais déclenchée dans le corps de la fonction. L'appelant ne peut donc pas être notifié d'une anomalie via le mécanisme standard.
|
||||||
|
|
||||||
|
- **Absence de vérification de `SY-SUBRC`** : après `FI_OPEN_ITEMS_SELECT` et `FI_DOCUMENT_GENERATE_AND_CLEAR`, la valeur de retour `SY-SUBRC` n'est pas vérifiée. Un échec silencieux est possible.
|
||||||
|
|
||||||
|
- **Hardcoding de `lv_bschl = '50'` et `lv_blart = 'KZ'`** : ces valeurs sont figées en constantes. Tout besoin de paiement avec un type de pièce ou une clé comptable différente nécessiterait une modification du code.
|
||||||
|
|
||||||
|
- **`MOVE-CORRESPONDING` entre structures de types différents** (`acchd` vers `accit`) : peut transférer des champs non désirés ou masquer des oublis d'alimentation explicite.
|
||||||
|
|
||||||
|
- **Commit dans la fonction** : l'appel à `BAPI_TRANSACTION_COMMIT` à l'intérieur d'une fonction module couple fortement la logique transactionnelle à cette fonction. Si elle est appelée dans une boucle ou un traitement plus large, chaque appel commitera indépendamment, rendant un rollback global impossible.
|
||||||
|
|
||||||
|
## Risques métiers
|
||||||
|
|
||||||
|
- **Filtrage post-sélection sur `BELNR`** : le `DELETE lt_open_item_tab WHERE belnr NE im_belnr` suggère que `FI_OPEN_ITEMS_SELECT` peut ramener des pièces autres que celle demandée. Ce filtre est une sécurité, mais si la table est vide après purge, aucun message n'est émis.
|
||||||
|
|
||||||
|
- **Traitement limité aux types `KR` et `RE`** : tout autre type de pièce fournisseur (ex. : `DR`, avoir) sera ignoré sans notification. Cela peut donner l'impression d'un traitement réussi alors qu'aucune action n'a eu lieu.
|
||||||
|
|
||||||
|
- **Sensibilité à la date de valeur (`IM_VALUT`)** : les dates de comptabilisation (`BLDAT`, `BUDAT`) sont toutes deux alimentées par `IM_VALUT` (date de valeur bancaire), et non par la date système. Une date incorrecte en entrée affectera directement la comptabilisation en période comptable.
|
||||||
|
|
||||||
|
- **Pas de contrôle du montant (`IM_WRBTR`)** : aucune validation n'est effectuée pour s'assurer que le montant correspond au montant du poste ouvert. Un écart générera une différence de lettrage.
|
||||||
|
|
||||||
|
- **Unicité supposée du poste ouvert** : le commentaire `"Only one record will be in Int tab"` indique une hypothèse forte. Si plusieurs postes ouverts existent pour la même pièce (cas de paiements partiels), seul le premier sera lu mais tous seront envoyés à `FI_DOCUMENT_GENERATE_AND_CLEAR`.
|
||||||
189
documentation/documentation_zpayments.prog.md
Normal file
189
documentation/documentation_zpayments.prog.md
Normal file
@ -0,0 +1,189 @@
|
|||||||
|
The user wants me to document the ABAP report ZPAYMENTS in markdown format with specific sections. Let me analyze the code carefully.
|
||||||
|
|
||||||
|
# Documentation technique : `ZPAYMENTS`
|
||||||
|
|
||||||
|
> **Rapport** : ZPAYMENTS | **Créé le** : 01.01.2016 | **Auteur** : Hifzulla.A (I065658)
|
||||||
|
> **Objectif** : Automatiser le paiement des fournisseurs (Vendor Payments) en appliquant des règles métier sur les postes ouverts comptables.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Algorithmie
|
||||||
|
|
||||||
|
Le programme implémente un moteur de paiement automatique des fournisseurs en plusieurs phases :
|
||||||
|
|
||||||
|
1. **Chargement des règles de paiement** : lecture de la table custom `ZPAYMENTRULES` qui définit la liste des fournisseurs éligibles et leurs paramètres (notamment `dayslate`).
|
||||||
|
|
||||||
|
2. **Extraction des postes ouverts** : sélection dans `BSIK` (postes fournisseurs ouverts) des documents de type `RE` (facture) et `KR` (avoir crédit) pour tous les fournisseurs présents dans les règles.
|
||||||
|
|
||||||
|
3. **Calcul de la date et du montant de paiement** : pour chaque poste ouvert, le programme détermine la date de paiement et le montant à payer selon deux logiques :
|
||||||
|
- **Sans escompte** (`zbd1p` vide ou nul) : date = date de base + délai net + jours de retard autorisés.
|
||||||
|
- **Avec escompte** : selon le nombre de niveaux d'escompte (`zbd2t`, `zbd3t`), le programme compare la date du jour à la date d'escompte :
|
||||||
|
- Si on est exactement à la date d'escompte : paiement avec déduction du taux d'escompte.
|
||||||
|
- Sinon : paiement au net.
|
||||||
|
- Si `dayslate` est renseigné : paiement forcé au net avec ajout des jours de retard sur la date nette.
|
||||||
|
|
||||||
|
4. **Filtrage des documents annulés** : élimination des paires de documents `H` (original) / `S` (contrepassation) pour ne pas payer des factures déjà annulées.
|
||||||
|
|
||||||
|
5. **Posting des paiements** : appel de la fonction `ZFI_OUT_PAYMENT_POST_CLEAR` pour chaque paiement à effectuer, avec détermination dynamique de la banque (`HBKID`/`HKTID`) selon la société (`BUKRS`).
|
||||||
|
|
||||||
|
6. **Journalisation** : chaque tentative de paiement (succès ou échec) est tracée dans la table `ZPAYMENTSLOG`.
|
||||||
|
|
||||||
|
7. **Envoi d'un email de synthèse** : un mail HTML récapitulatif est envoyé en fin d'exécution via `SO_NEW_DOCUMENT_SEND_API1`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Objets
|
||||||
|
|
||||||
|
## Tables de base de données
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `ZPAYMENTRULES` | Table custom Z | Référentiel des fournisseurs éligibles au paiement automatique, avec paramètres (`dayslate`, etc.) |
|
||||||
|
| `BSIK` | Table SAP standard | Postes comptables fournisseurs **ouverts** (source des factures à payer) |
|
||||||
|
| `ZPAYMENTSLOG` | Table custom Z | Journal des paiements exécutés (succès / erreurs) |
|
||||||
|
| `T052` | Table SAP standard | Table des conditions de paiement (déclarée mais non exploitée directement dans le code visible) |
|
||||||
|
|
||||||
|
## Structures et types locaux
|
||||||
|
|
||||||
|
| Objet | Rôle |
|
||||||
|
|---|---|
|
||||||
|
| `ty_lifnr` | Type simple pour stocker un numéro de fournisseur |
|
||||||
|
| `ty_paymentdata` | Type local de données de paiement (remplacé dans la pratique par `zpayments_data_s`) |
|
||||||
|
| `zpayments_data_s` | Structure custom principale transportant les données de paiement enrichies (`new_dateofpayment`, `new_wrbtr`, etc.) |
|
||||||
|
|
||||||
|
## Tables internes principales
|
||||||
|
|
||||||
|
| Variable | Rôle |
|
||||||
|
|---|---|
|
||||||
|
| `lt_zpaymentrules` / `ls_zpaymentrules` | Règles de paiement chargées depuis `ZPAYMENTRULES` |
|
||||||
|
| `iv_lt_bsik` / `iv_ls_bsik` | Postes ouverts bruts issus de `BSIK` |
|
||||||
|
| `lt_payment_data` / `ls_payment_data` | Postes filtrés et enrichis avec les dates/montants de paiement calculés |
|
||||||
|
| `lt_payment_reversals` / `ls_payment_reversals` | Postes de contrepassation isolés pour nettoyage |
|
||||||
|
| `lt_payment_data_temp` / `ls_payment_data_temp` | Copie de travail pour la boucle de posting |
|
||||||
|
| `lt_paymentslog` / `ls_paymentslog` | Journal des résultats de paiement |
|
||||||
|
|
||||||
|
## Variables de pilotage
|
||||||
|
|
||||||
|
| Variable | Rôle |
|
||||||
|
|---|---|
|
||||||
|
| `for_date` | Paramètre de sélection : date de traitement (défaut = date du jour) |
|
||||||
|
| `bukrs` | Paramètre de sélection : société (défaut = `1710`) |
|
||||||
|
| `no_data` | Flag indiquant l'absence de données à traiter |
|
||||||
|
| `lv_hbkid` / `lv_hktid` | Identifiants de la banque utilisée pour le paiement, déterminés par société |
|
||||||
|
|
||||||
|
## Fonction externe
|
||||||
|
|
||||||
|
| Fonction | Rôle |
|
||||||
|
|---|---|
|
||||||
|
| `ZFI_OUT_PAYMENT_POST_CLEAR` | Fonction custom Z qui comptabilise et solde le paiement fournisseur |
|
||||||
|
| `SO_NEW_DOCUMENT_SEND_API1` | Fonction SAP standard d'envoi d'email via SAPoffice/SMTP |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dépendances
|
||||||
|
|
||||||
|
## Dépendances fonctionnelles critiques
|
||||||
|
|
||||||
|
```
|
||||||
|
ZPAYMENTS
|
||||||
|
│
|
||||||
|
├── ZPAYMENTRULES (table de configuration : fournisseurs éligibles)
|
||||||
|
├── BSIK (postes ouverts fournisseurs, source de données)
|
||||||
|
├── ZPAYMENTSLOG (table de log, mise à jour via MODIFY)
|
||||||
|
├── ZPAYMENTS_DATA_S (structure de données intermédiaire)
|
||||||
|
│
|
||||||
|
├── ZFI_OUT_PAYMENT_POST_CLEAR (module fonction de posting/clearing)
|
||||||
|
│ └── Dépend de la config bancaire (HBKID/HKTID par société)
|
||||||
|
│
|
||||||
|
└── SO_NEW_DOCUMENT_SEND_API1 (envoi email SAPoffice)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Dépendances par société (mapping banque)
|
||||||
|
|
||||||
|
| `BUKRS` | `HBKID` | `HKTID` |
|
||||||
|
|---|---|---|
|
||||||
|
| `1710` | `USBK1` | `USAC1` |
|
||||||
|
| `AUC1` | `AUCBK` | `AUCAC` |
|
||||||
|
| `DEC1` | `DECBK` | `DECAC` |
|
||||||
|
| `USC1` | `USCBK` | `USCAC` |
|
||||||
|
|
||||||
|
> Toute nouvelle société nécessite un ajout dans le code source.
|
||||||
|
|
||||||
|
## Dépendances de configuration
|
||||||
|
|
||||||
|
- La table `ZPAYMENTRULES` doit être alimentée pour que le programme fonctionne.
|
||||||
|
- Le fournisseur `USSU_V8000` est **exclu en dur** du traitement.
|
||||||
|
- La fonction `ZFI_OUT_PAYMENT_POST_CLEAR` doit exister et être fonctionnelle.
|
||||||
|
- Le groupe de fonctions `ZFGPAYMENTRULES` gère la vue de maintenance de `ZPAYMENTRULES`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Flux de traitement
|
||||||
|
|
||||||
|
````
|
||||||
|
[DÉBUT]
|
||||||
|
│
|
||||||
|
├─► Affichage heure de démarrage (sy-uzeit)
|
||||||
|
│
|
||||||
|
├─► SELECT * FROM ZPAYMENTRULES → lt_zpaymentrules
|
||||||
|
│ └─► Exclusion forcée du fournisseur USSU_V8000
|
||||||
|
│
|
||||||
|
├─► [SI lt_zpaymentrules vide] → Message + RETURN
|
||||||
|
│
|
||||||
|
├─► SELECT FROM BSIK (blart = RE ou KR)
|
||||||
|
│ └─► Pour tous les fournisseurs de lt_zpaymentrules
|
||||||
|
│ └─► Filtre : zfbdt <= sy-datum (postes dont la date de base est passée)
|
||||||
|
│
|
||||||
|
├─► [SI BSIK vide] → Message "No records"
|
||||||
|
│
|
||||||
|
├─► LOOP sur iv_lt_bsik
|
||||||
|
│ ├─► Cas SANS escompte (zbd1p = 0)
|
||||||
|
│ │ └─► new_dateofpayment = zfbdt + zbd1t + dayslate
|
||||||
|
│ │ └─► new_wrbtr = wrbtr (montant plein)
|
||||||
|
│ │
|
||||||
|
│ └─► Cas AVEC escompte
|
||||||
|
│ ├─► dayslate = 0 : respect strict des termes de paiement
|
||||||
|
│ │ ├─► 1 niveau d'escompte : si date = lv_discount_date1 → paiement escompté
|
||||||
|
│ │ │ sinon → paiement net
|
||||||
|
│ │ └─► 2 niveaux d'escompte : comparaison date1 puis date2
|
||||||
|
│ │ sinon → paiement net
|
||||||
|
│ └─► dayslate > 0 : paiement net + décalage dayslate
|
||||||
|
│
|
||||||
|
├─► DELETE lt_payment_data WHERE new_dateofpayment > for_date
|
||||||
|
│
|
||||||
|
├─► Nettoyage des contrepassations (shkzg H/S)
|
||||||
|
│ └─► Suppression des paires original/contrepassation de lt_payment_data
|
||||||
|
│
|
||||||
|
├─► [SI lt_payment_data vide] → no_data = 'X'
|
||||||
|
│
|
||||||
|
├─► LOOP sur lt_payment_data_temp (= postes à payer)
|
||||||
|
│ ├─► Détermination HBKID/HKTID selon BUKRS
|
||||||
|
│ ├─► CALL FUNCTION ZFI_OUT_PAYMENT_POST_CLEAR
|
||||||
|
│ ├─► [SI ex_belnr renseigné] → log Succès
|
||||||
|
│ └─► [SINON] → log Erreur
|
||||||
|
│
|
||||||
|
├─► MODIFY ZPAYMENTSLOG FROM TABLE lt_paymentslog
|
||||||
|
│
|
||||||
|
├─► PERFORM send_mail
|
||||||
|
│ ├─► Construction du corps HTML (résumé statistiques + détails)
|
||||||
|
│ ├─► Listing des erreurs puis des succès
|
||||||
|
│ └─► CALL FUNCTION SO_NEW_DOCUMENT_SEND_API1
|
||||||
|
│
|
||||||
|
└─► Affichage heure de fin
|
||||||
|
[FIN]
|
||||||
|
````
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Points d'attention
|
||||||
|
|
||||||
|
## Risques techniques
|
||||||
|
|
||||||
|
| # | Risque | Description |
|
||||||
|
|---|---|---|
|
||||||
|
| 1 | **Exclusion fournisseur en dur** | `DELETE lt_zpaymentrules WHERE lifnr EQ 'USSU_V8000'` est codé en dur. Toute évolution de cette liste nécessite une modification du programme. |
|
||||||
|
| 2 | **Mapping banque en dur** | L'association `BUKRS` -> `HBKID`/`HKTID` est dans un `IF/ELSEIF` statique. L'ajout d'une nouvelle société impose une modification de code. |
|
||||||
|
| 3 | **Compte GL en dur** | `im_hkont = '0011001000'` est passé en dur à la fonction de clearing. Aucune paramétrage externe n'est prévu. |
|
||||||
|
| 4 | **Variable `bukrs` shadowing** | Le filtre `DELETE iv_lt_bsik WHERE bukrs NE bukrs` compare le champ `bukrs` de la table interne avec lui-même (même nom que le paramètre de sélection). Cette condition ne filtre **jamais** rien et est probablement un bug. |
|
||||||
|
| 5 | **Données locales déclarées dans une boucle** | `DATA: lv_discount_date1, lv_discount_date2, lv_net_date, lv_discount_levels` sont déclarés à l'intérieur d'un `LOOP`. En ABAP classique, cela est toléré syntaxiquement mais contraire aux bonnes pratiques et peut induire des comportements inattendus si la variable n'est pas correctement réinitialisée. |
|
||||||
|
| 6 | **Absence de gestion d'erreur sur Z
|
||||||
156
documentation/documentation_zpayments_old.prog.md
Normal file
156
documentation/documentation_zpayments_old.prog.md
Normal file
@ -0,0 +1,156 @@
|
|||||||
|
The user wants me to document an ABAP program `zpayments_old.prog.abap` in markdown format with specific sections. Let me analyze the code carefully.
|
||||||
|
|
||||||
|
# Documentation technique — `ZPAYMENTS_OLD`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Algorithmie
|
||||||
|
|
||||||
|
Le programme `ZPAYMENTS_OLD` est un report ABAP conçu pour **automatiser le traitement des paiements fournisseurs**. Son fonctionnement général est le suivant :
|
||||||
|
|
||||||
|
1. Il lit une table de règles de paiement personnalisée (`ZPAYMENTRULES`) pour identifier la liste des fournisseurs éligibles.
|
||||||
|
2. Il interroge la table standard SAP des postes ouverts fournisseurs (`BSIK`) pour récupérer les factures non soldées (types `RE` et `KR`).
|
||||||
|
3. Pour chaque poste ouvert, il calcule la **date et le montant de paiement optimaux** en appliquant les conditions de paiement (escomptes, délais, pénalités de retard) selon des règles métier paramétrables.
|
||||||
|
4. Il filtre les paiements à effectuer **à la date du jour ou avant** la date de sélection (`for_date`).
|
||||||
|
5. Pour chaque paiement retenu, il appelle le **function module BDC** `ZBDC_VENDOR_PAYMENTS_CLOUD` pour saisir automatiquement l'écriture comptable via transaction (simulation de saisie écran).
|
||||||
|
6. Il **journalise** chaque opération (succès / erreur) dans la table `ZPAYMENTSLOG`.
|
||||||
|
7. Il envoie un **e-mail de synthèse** récapitulatif à la fin du traitement via `SO_NEW_DOCUMENT_SEND_API1`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Objets
|
||||||
|
|
||||||
|
### Tables personnalisées (Z)
|
||||||
|
|
||||||
|
| Objet | Type | Rôle |
|
||||||
|
|---|---|---|
|
||||||
|
| `ZPAYMENTRULES` | Table Z | Contient les règles de paiement par fournisseur (liste blanche de `LIFNR` avec paramètre `DAYSLATE` pour décalage de paiement) |
|
||||||
|
| `ZPAYMENTS_DATA_S` | Structure Z | Structure de travail portant les données de poste ouvert enrichies (date de paiement calculée, montant net après escompte) |
|
||||||
|
| `ZPAYMENTSLOG` | Table Z | Journal des exécutions : statut (`S`/`E`), numéro de document généré, description, date |
|
||||||
|
|
||||||
|
### Tables standard SAP
|
||||||
|
|
||||||
|
| Objet | Rôle |
|
||||||
|
|---|---|
|
||||||
|
| `BSIK` | Postes ouverts fournisseurs (comptabilité auxiliaire) — source des factures à payer |
|
||||||
|
| `T052` | Table des conditions de paiement (déclarée mais non utilisée directement dans le code visible) |
|
||||||
|
|
||||||
|
### Function Modules
|
||||||
|
|
||||||
|
| Objet | Rôle |
|
||||||
|
|---|---|
|
||||||
|
| `ZBDC_VENDOR_PAYMENTS_CLOUD` | FM BDC custom : simule la saisie manuelle d'un paiement fournisseur dans SAP (vraisemblablement via FB01/F-53) |
|
||||||
|
| `FORMAT_MESSAGE` | Formate un message SAP (id + numéro) en texte lisible pour les logs et l'e-mail |
|
||||||
|
| `SO_NEW_DOCUMENT_SEND_API1` | Envoi d'un e-mail SAP Office au format HTML avec destinataires |
|
||||||
|
|
||||||
|
### Types internes
|
||||||
|
|
||||||
|
| Type | Rôle |
|
||||||
|
|---|---|
|
||||||
|
| `ty_lifnr` | Type simple pour une liste de numéros fournisseurs |
|
||||||
|
| `ty_paymentdata` | Type local de données de paiement (défini mais remplacé par `ZPAYMENTS_DATA_S` dans l'implémentation) |
|
||||||
|
|
||||||
|
### Variables clés
|
||||||
|
|
||||||
|
| Variable | Rôle |
|
||||||
|
|---|---|
|
||||||
|
| `for_date` | Paramètre de sélection : date de traitement cible |
|
||||||
|
| `bukrs` | Paramètre de sélection : code société (défaut `1710`) |
|
||||||
|
| `lt_payment_data` | Table de travail principale des paiements à traiter |
|
||||||
|
| `lt_paymentslog` | Table de journalisation collectée en mémoire avant écriture en base |
|
||||||
|
| `no_data` | Flag indiquant l'absence de données à traiter (impact sur l'e-mail) |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Dépendances
|
||||||
|
|
||||||
|
### Dépendances techniques
|
||||||
|
|
||||||
|
- **`ZBDC_VENDOR_PAYMENTS_CLOUD`** : function module critique. Le programme ne peut pas fonctionner sans lui. Il encapsule un BDC (Batch Data Communication) qui rejoue une transaction de saisie de paiement. Son bon fonctionnement dépend de la stabilité des écrans SAP sous-jacents (probablement F-53 ou FB01).
|
||||||
|
- **`ZPAYMENTRULES`** : table de paramétrage indispensable. Si elle est vide, le programme s'arrête avec un message d'information.
|
||||||
|
- **`ZPAYMENTSLOG`** : table de journalisation mise à jour via `MODIFY ... FROM TABLE` (upsert). Elle doit exister et être correctement définie.
|
||||||
|
- **`ZPAYMENTS_DATA_S`** : structure partagée entre ce programme et potentiellement d'autres objets du package `ZDPR_PAYMENTS`.
|
||||||
|
|
||||||
|
### Dépendances fonctionnelles
|
||||||
|
|
||||||
|
- La **table `ZPAYMENTRULES`** est maintenue via un groupe de fonctions dédié (`ZFGPAYMENTRULES`) exposant une vue de maintenance (`SM30`). Le champ `DAYSLATE` est le seul paramètre de personnalisation par fournisseur.
|
||||||
|
- Le programme suppose que les **conditions de paiement SAP** (`ZTERM`, `ZBD1T`, `ZBD2T`, `ZBD3T`, `ZBD1P`, `ZBD2P`) sont correctement alimentées dans `BSIK` — héritées de la facture d'origine.
|
||||||
|
- Le **compte bancaire maison** est en dur dans le code BDC (`HBKID = 'USBK1'`, `HKTID = 'USAC1'`) et le compte GL en dur (`'11001000'`).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Flux de traitement
|
||||||
|
|
||||||
|
````
|
||||||
|
┌─────────────────────────────────────────────────────┐
|
||||||
|
│ 1. INITIALISATION │
|
||||||
|
│ - Affichage heure de début │
|
||||||
|
│ - Lecture complète de ZPAYMENTRULES │
|
||||||
|
└────────────────────────┬────────────────────────────┘
|
||||||
|
│
|
||||||
|
┌────────────────────────▼────────────────────────────┐
|
||||||
|
│ 2. SÉLECTION DES POSTES OUVERTS (BSIK) │
|
||||||
|
│ - FOR ALL ENTRIES sur ZPAYMENTRULES │
|
||||||
|
│ - Filtre : BLART IN ('RE','KR') │
|
||||||
|
│ - Filtre : BUKRS = paramètre sélection │
|
||||||
|
│ - Suppression des postes futurs (ZFBDT > TODAY) │
|
||||||
|
└────────────────────────┬────────────────────────────┘
|
||||||
|
│
|
||||||
|
┌────────────────────────▼────────────────────────────┐
|
||||||
|
│ 3. CALCUL DES PAIEMENTS (LOOP sur BSIK) │
|
||||||
|
│ │
|
||||||
|
│ [Fournisseur sans escompte (ZBD1P vide)] │
|
||||||
|
│ → Date paiement = ZFBDT + ZBD1T + DAYSLATE │
|
||||||
|
│ → Montant = montant brut │
|
||||||
|
│ │
|
||||||
|
│ [Fournisseur avec escompte et DAYSLATE = 0] │
|
||||||
|
│ → Si 1 niveau d'escompte (ZBD2T renseigné) : │
|
||||||
|
│ • Date escompte1 = ZFBDT + ZBD1T │
|
||||||
|
│ • Si date escompte1 = TODAY → payer escompté │
|
||||||
|
│ • Sinon → payer NET à ZBD2T │
|
||||||
|
│ → Si 2 niveaux (ZBD3T renseigné) : │
|
||||||
|
│ • Teste escompte1, puis escompte2, puis NET │
|
||||||
|
│ │
|
||||||
|
│ [Fournisseur avec escompte et DAYSLATE > 0] │
|
||||||
|
│ → Paiement décalé sur date nette + DAYSLATE │
|
||||||
|
│ → Montant = montant brut (pas d'escompte) │
|
||||||
|
│ │
|
||||||
|
│ → Filtre final : NEW_DATEOFPAYMENT <= FOR_DATE │
|
||||||
|
└────────────────────────┬────────────────────────────┘
|
||||||
|
│
|
||||||
|
┌────────────────────────▼────────────────────────────┐
|
||||||
|
│ 4. SAISIE COMPTABLE VIA BDC │
|
||||||
|
│ LOOP sur LT_PAYMENT_DATA │
|
||||||
|
│ → Appel ZBDC_VENDOR_PAYMENTS_CLOUD │
|
||||||
|
│ (1 appel par poste ouvert) │
|
||||||
|
│ → Lecture du retour (SUBRC + MESSTAB) │
|
||||||
|
│ → Construction du log (S/E + numéro document) │
|
||||||
|
└────────────────────────┬────────────────────────────┘
|
||||||
|
│
|
||||||
|
┌────────────────────────▼────────────────────────────┐
|
||||||
|
│ 5. JOURNALISATION │
|
||||||
|
│ → MODIFY ZPAYMENTSLOG FROM TABLE LT_PAYMENTSLOG │
|
||||||
|
└────────────────────────┬────────────────────────────┘
|
||||||
|
│
|
||||||
|
┌────────────────────────▼────────────────────────────┐
|
||||||
|
│ 6. ENVOI E-MAIL (FORM SEND_MAIL) │
|
||||||
|
│ → Synthèse : postes trouvés, traités, en erreur │
|
||||||
|
│ → Destinataire : utilisateur courant (SY-UNAME) │
|
||||||
|
│ → Format HTML via SO_NEW_DOCUMENT_SEND_API1 │
|
||||||
|
│ → Affichage heure de fin │
|
||||||
|
└─────────────────────────────────────────────────────┘
|
||||||
|
````
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Points d'attention
|
||||||
|
|
||||||
|
### Risques techniques
|
||||||
|
|
||||||
|
- **Code en dur critique** : le compte bancaire maison (`USBK1` / `USAC1`), le compte GL (`11001000`) et la société par défaut (`1710`) sont codés en dur dans l'appel BDC. Tout changement d'infrastructure bancaire nécessite une modification du programme.
|
||||||
|
- **BDC fragile** : l'appel à `ZBDC_VENDOR_PAYMENTS_CLOUD` rejoue une saisie écran. Si SAP est mis à jour (nouveau screen layout, nouveau champ obligatoire), le BDC peut silencieusement échouer ou produire des données incorrectes.
|
||||||
|
- **Typage `ty_paymentdata` inutilisé** : le type local `ty_paymentdata` est déclaré mais jamais utilisé (remplacé par `ZPAYMENTS_DATA_S`). Risque de confusion lors de la maintenance.
|
||||||
|
- **`lv_rec_count` toujours à 0** : la variable `lv_rec_count` est initialisée à 0 et n'est jamais incrémentée. Les compteurs `success_rec_count` et `failed_rec_count` sont donc toujours à 0 (`+ lv_rec_count` n'apporte rien).
|
||||||
|
- **Condition `OR NE 0` redondante** : les conditions du type `IF iv_ls_bsik-zbd3t IS NOT INITIAL OR iv_ls_bsik-zbd3t NE 0` sont logiquement redondantes (les deux parties testent la même chose). La condition correcte aurait dû être `AND`.
|
||||||
|
- **Logique de discount avec `EQ sy-datum`** : la comparaison stricte à la date du jour (`EQ sy-datum`) signifie que si le programme ne tourne pas exactement à la date d'escompte, le paiement escompté sera manqué et le paiement net appliqué à la place. Pas de rattrapage automatique.
|
||||||
|
- **Déclaration de variables dans un LOOP
|
||||||
@ -1,370 +1,370 @@
|
|||||||
from xml.parsers.expat import model
|
from xml.parsers.expat import model
|
||||||
|
|
||||||
import requests
|
import requests
|
||||||
import json
|
import json
|
||||||
import os
|
import os
|
||||||
import time
|
import time
|
||||||
import tqdm
|
import tqdm
|
||||||
import re
|
import re
|
||||||
from dotenv import load_dotenv
|
from dotenv import load_dotenv
|
||||||
import chromadb
|
import chromadb
|
||||||
from sentence_transformers import SentenceTransformer
|
from sentence_transformers import SentenceTransformer
|
||||||
import uuid
|
import uuid
|
||||||
# Load variables from .env file
|
# Load variables from .env file
|
||||||
load_dotenv()
|
load_dotenv()
|
||||||
|
|
||||||
# --- Configuration ---
|
# --- Configuration ---
|
||||||
DUST_API_KEY = os.getenv("DUST_API_KEY")
|
DUST_API_KEY = os.getenv("DUST_API_KEY")
|
||||||
WORKSPACE_ID = os.getenv("DUST_WORKSPACE_ID")
|
WORKSPACE_ID = os.getenv("DUST_WORKSPACE_ID")
|
||||||
AGENT_ID = "dust" # ou l'identifiant de ton agent spécifique
|
AGENT_ID = "dust" # ou l'identifiant de ton agent spécifique
|
||||||
|
|
||||||
BASE_URL = "https://dust.tt/api/v1"
|
BASE_URL = "https://dust.tt/api/v1"
|
||||||
|
|
||||||
|
|
||||||
model = SentenceTransformer("all-MiniLM-L6-v2")
|
model = SentenceTransformer("all-MiniLM-L6-v2")
|
||||||
HEADERS = {
|
HEADERS = {
|
||||||
"Authorization": f"Bearer {DUST_API_KEY}",
|
"Authorization": f"Bearer {DUST_API_KEY}",
|
||||||
"Content-Type": "application/json",
|
"Content-Type": "application/json",
|
||||||
}
|
}
|
||||||
|
|
||||||
client = chromadb.PersistentClient(path="./chroma_db")
|
client = chromadb.PersistentClient(path="./chroma_db")
|
||||||
COLLECTION_NAME = "abap_rag"
|
COLLECTION_NAME = "abap_rag"
|
||||||
collection = client.get_or_create_collection(
|
collection = client.get_or_create_collection(
|
||||||
name=COLLECTION_NAME
|
name=COLLECTION_NAME
|
||||||
)
|
)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
def create_conversation(message: str) -> dict:
|
def create_conversation(message: str) -> dict:
|
||||||
"""Crée une nouvelle conversation et envoie un premier message."""
|
"""Crée une nouvelle conversation et envoie un premier message."""
|
||||||
url = f"{BASE_URL}/w/{WORKSPACE_ID}/assistant/conversations"
|
url = f"{BASE_URL}/w/{WORKSPACE_ID}/assistant/conversations"
|
||||||
|
|
||||||
payload = {
|
payload = {
|
||||||
"message": {
|
"message": {
|
||||||
"content": message,
|
"content": message,
|
||||||
"mentions": [{"configurationId": AGENT_ID}],
|
"mentions": [{"configurationId": AGENT_ID}],
|
||||||
"context": {
|
"context": {
|
||||||
"timezone": "Europe/Paris",
|
"timezone": "Europe/Paris",
|
||||||
"username": "python_user",
|
"username": "python_user",
|
||||||
"fullName": "Python User",
|
"fullName": "Python User",
|
||||||
"email": "python@example.com",
|
"email": "python@example.com",
|
||||||
"profilePictureUrl": None,
|
"profilePictureUrl": None,
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
"visibility": "unlisted",
|
"visibility": "unlisted",
|
||||||
"title": None,
|
"title": None,
|
||||||
}
|
}
|
||||||
|
|
||||||
response = requests.post(url, headers=HEADERS, json=payload)
|
response = requests.post(url, headers=HEADERS, json=payload)
|
||||||
response.raise_for_status()
|
response.raise_for_status()
|
||||||
return response.json()
|
return response.json()
|
||||||
|
|
||||||
|
|
||||||
def get_agent_message_events(conversation_id: str, message_id: str):
|
def get_agent_message_events(conversation_id: str, message_id: str):
|
||||||
"""Récupère la réponse de l'agent en streaming (SSE)."""
|
"""Récupère la réponse de l'agent en streaming (SSE)."""
|
||||||
url = f"{BASE_URL}/w/{WORKSPACE_ID}/assistant/conversations/{conversation_id}/messages/{message_id}/events"
|
url = f"{BASE_URL}/w/{WORKSPACE_ID}/assistant/conversations/{conversation_id}/messages/{message_id}/events"
|
||||||
|
|
||||||
with requests.get(url, headers=HEADERS, stream=True) as response:
|
with requests.get(url, headers=HEADERS, stream=True) as response:
|
||||||
response.raise_for_status()
|
response.raise_for_status()
|
||||||
full_text = ""
|
full_text = ""
|
||||||
|
|
||||||
for line in response.iter_lines():
|
for line in response.iter_lines():
|
||||||
if line:
|
if line:
|
||||||
decoded = line.decode("utf-8")
|
decoded = line.decode("utf-8")
|
||||||
if decoded.startswith("data:"):
|
if decoded.startswith("data:"):
|
||||||
data_str = decoded[len("data:"):].strip()
|
data_str = decoded[len("data:"):].strip()
|
||||||
try:
|
try:
|
||||||
event = json.loads(data_str)
|
event = json.loads(data_str)
|
||||||
event_type = event.get("data").get("type")
|
event_type = event.get("data").get("type")
|
||||||
|
|
||||||
if event_type == "generation_tokens":
|
if event_type == "generation_tokens":
|
||||||
token = event.get("data").get("text", "")
|
token = event.get("data").get("text", "")
|
||||||
print(token, end="", flush=True)
|
print(token, end="", flush=True)
|
||||||
full_text += token
|
full_text += token
|
||||||
|
|
||||||
elif event_type == "agent_message_success":
|
elif event_type == "agent_message_success":
|
||||||
print() # Saut de ligne final
|
print() # Saut de ligne final
|
||||||
break
|
break
|
||||||
|
|
||||||
elif event_type == "agent_error":
|
elif event_type == "agent_error":
|
||||||
print(f"\n[Erreur agent] {event}")
|
print(f"\n[Erreur agent] {event}")
|
||||||
break
|
break
|
||||||
|
|
||||||
except json.JSONDecodeError:
|
except json.JSONDecodeError:
|
||||||
pass
|
pass
|
||||||
|
|
||||||
return full_text
|
return full_text
|
||||||
|
|
||||||
|
|
||||||
def send_followup_message(conversation_id: str, message: str) -> dict:
|
def send_followup_message(conversation_id: str, message: str) -> dict:
|
||||||
"""Envoie un message de suivi dans une conversation existante."""
|
"""Envoie un message de suivi dans une conversation existante."""
|
||||||
url = f"{BASE_URL}/w/{WORKSPACE_ID}/assistant/conversations/{conversation_id}/messages"
|
url = f"{BASE_URL}/w/{WORKSPACE_ID}/assistant/conversations/{conversation_id}/messages"
|
||||||
|
|
||||||
payload = {
|
payload = {
|
||||||
"content": message,
|
"content": message,
|
||||||
"mentions": [{"configurationId": AGENT_ID}],
|
"mentions": [{"configurationId": AGENT_ID}],
|
||||||
"context": {
|
"context": {
|
||||||
"timezone": "Europe/Paris",
|
"timezone": "Europe/Paris",
|
||||||
"username": "python_user",
|
"username": "python_user",
|
||||||
"fullName": "Python User",
|
"fullName": "Python User",
|
||||||
"email": "python@example.com",
|
"email": "python@example.com",
|
||||||
"profilePictureUrl": None,
|
"profilePictureUrl": None,
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
|
|
||||||
response = requests.post(url, headers=HEADERS, json=payload)
|
response = requests.post(url, headers=HEADERS, json=payload)
|
||||||
response.raise_for_status()
|
response.raise_for_status()
|
||||||
return response.json()
|
return response.json()
|
||||||
|
|
||||||
|
|
||||||
def chat(message: str):
|
def chat(message: str):
|
||||||
"""Point d'entrée principal : crée une conversation et affiche la réponse."""
|
"""Point d'entrée principal : crée une conversation et affiche la réponse."""
|
||||||
print(f"\n[Vous] {message}")
|
print(f"\n[Vous] {message}")
|
||||||
print("[Agent] ", end="")
|
print("[Agent] ", end="")
|
||||||
|
|
||||||
# 1. Créer la conversation
|
# 1. Créer la conversation
|
||||||
result = create_conversation(message)
|
result = create_conversation(message)
|
||||||
conversation = result.get("conversation", {})
|
conversation = result.get("conversation", {})
|
||||||
conversation_id = conversation.get("sId")
|
conversation_id = conversation.get("sId")
|
||||||
|
|
||||||
# 2. Trouver l'ID du message agent dans la conversation
|
# 2. Trouver l'ID du message agent dans la conversation
|
||||||
agent_message = None
|
agent_message = None
|
||||||
for msg in conversation.get("content", []):
|
for msg in conversation.get("content", []):
|
||||||
for m in msg:
|
for m in msg:
|
||||||
if m.get("type") == "agent_message":
|
if m.get("type") == "agent_message":
|
||||||
agent_message = m
|
agent_message = m
|
||||||
break
|
break
|
||||||
|
|
||||||
if not agent_message:
|
if not agent_message:
|
||||||
print("Aucun message agent trouvé.")
|
print("Aucun message agent trouvé.")
|
||||||
return None
|
return None
|
||||||
|
|
||||||
agent_message_id = agent_message.get("sId")
|
agent_message_id = agent_message.get("sId")
|
||||||
|
|
||||||
# 3. Streamer la réponse
|
# 3. Streamer la réponse
|
||||||
response_text = get_agent_message_events(conversation_id, agent_message_id)
|
response_text = get_agent_message_events(conversation_id, agent_message_id)
|
||||||
|
|
||||||
return {"conversation_id": conversation_id, "response": response_text}
|
return {"conversation_id": conversation_id, "response": response_text}
|
||||||
|
|
||||||
# =========================
|
# =========================
|
||||||
# INDEX FILES
|
# INDEX FILES
|
||||||
# =========================
|
# =========================
|
||||||
|
|
||||||
def index_folder(folder_path):
|
def index_folder(folder_path):
|
||||||
|
|
||||||
all_files = []
|
all_files = []
|
||||||
|
|
||||||
for root, dirs, files in os.walk(folder_path):
|
for root, dirs, files in os.walk(folder_path):
|
||||||
for file in files:
|
for file in files:
|
||||||
|
|
||||||
if file.endswith(".abap"):
|
if file.endswith(".abap"):
|
||||||
|
|
||||||
all_files.append(
|
all_files.append(
|
||||||
os.path.join(root, file)
|
os.path.join(root, file)
|
||||||
)
|
)
|
||||||
|
|
||||||
print(f"{len(all_files)} fichiers trouvés")
|
print(f"{len(all_files)} fichiers trouvés")
|
||||||
|
|
||||||
for filepath in tqdm.tqdm(all_files):
|
for filepath in tqdm.tqdm(all_files):
|
||||||
|
|
||||||
try:
|
try:
|
||||||
|
|
||||||
with open(filepath, "r", encoding="utf-8", errors="ignore") as f:
|
with open(filepath, "r", encoding="utf-8", errors="ignore") as f:
|
||||||
content = f.read()
|
content = f.read()
|
||||||
|
|
||||||
chunks = split_abap_code(content)
|
chunks = split_abap_code(content)
|
||||||
|
|
||||||
for chunk in chunks:
|
for chunk in chunks:
|
||||||
|
|
||||||
embedding = model.encode(chunk).tolist()
|
embedding = model.encode(chunk).tolist()
|
||||||
|
|
||||||
collection.add(
|
collection.add(
|
||||||
ids=[str(uuid.uuid4())],
|
ids=[str(uuid.uuid4())],
|
||||||
documents=[chunk],
|
documents=[chunk],
|
||||||
embeddings=[embedding],
|
embeddings=[embedding],
|
||||||
metadatas=[{
|
metadatas=[{
|
||||||
"source": filepath,
|
"source": filepath,
|
||||||
"filename": os.path.basename(filepath)
|
"filename": os.path.basename(filepath)
|
||||||
}]
|
}]
|
||||||
)
|
)
|
||||||
|
|
||||||
except Exception as e:
|
except Exception as e:
|
||||||
print(f"Erreur indexation {filepath}: {e}")
|
print(f"Erreur indexation {filepath}: {e}")
|
||||||
|
|
||||||
print("Indexation terminée")
|
print("Indexation terminée")
|
||||||
# =========================
|
# =========================
|
||||||
# DOCUMENT FILE WITH RAG
|
# DOCUMENT FILE WITH RAG
|
||||||
# =========================
|
# =========================
|
||||||
|
|
||||||
def document_file(filepath):
|
def document_file(filepath):
|
||||||
|
|
||||||
with open(filepath, "r", encoding="utf-8", errors="ignore") as f:
|
with open(filepath, "r", encoding="utf-8", errors="ignore") as f:
|
||||||
content = f.read()
|
content = f.read()
|
||||||
|
|
||||||
filename = os.path.basename(filepath)
|
filename = os.path.basename(filepath)
|
||||||
|
|
||||||
# recherche RAG
|
# recherche RAG
|
||||||
rag_context = retrieve_context(content, top_k=5)
|
rag_context = retrieve_context(content, top_k=5)
|
||||||
|
|
||||||
prompt = f"""
|
prompt = f"""
|
||||||
Tu es un expert SAP ABAP.
|
Tu es un expert SAP ABAP.
|
||||||
|
|
||||||
Tu dois documenter le fichier suivant.
|
Tu dois documenter le fichier suivant.
|
||||||
|
|
||||||
FICHIER ANALYSÉ:
|
FICHIER ANALYSÉ:
|
||||||
{filename}
|
{filename}
|
||||||
|
|
||||||
CHEMIN:
|
CHEMIN:
|
||||||
{filepath}
|
{filepath}
|
||||||
|
|
||||||
CODE PRINCIPAL:
|
CODE PRINCIPAL:
|
||||||
{content}
|
{content}
|
||||||
|
|
||||||
CONTEXTE RAG:
|
CONTEXTE RAG:
|
||||||
{rag_context}
|
{rag_context}
|
||||||
|
|
||||||
Ton résultat doit être en markdown avec plusieurs sections :
|
Ton résultat doit être en markdown avec plusieurs sections :
|
||||||
|
|
||||||
# Algorithmie
|
# Algorithmie
|
||||||
Explique le fonctionnement général du programme.
|
Explique le fonctionnement général du programme.
|
||||||
|
|
||||||
# Objets
|
# Objets
|
||||||
Explique les objets utilisés et leur rôle.
|
Explique les objets utilisés et leur rôle.
|
||||||
|
|
||||||
# Dépendances
|
# Dépendances
|
||||||
Explique les dépendances importantes.
|
Explique les dépendances importantes.
|
||||||
|
|
||||||
# Flux de traitement
|
# Flux de traitement
|
||||||
Décris les principales étapes d'exécution.
|
Décris les principales étapes d'exécution.
|
||||||
|
|
||||||
# Points d'attention
|
# Points d'attention
|
||||||
Liste les risques techniques ou métiers.
|
Liste les risques techniques ou métiers.
|
||||||
"""
|
"""
|
||||||
|
|
||||||
return chat(prompt)
|
return chat(prompt)
|
||||||
# =========================
|
# =========================
|
||||||
# ABAP CHUNKER
|
# ABAP CHUNKER
|
||||||
# =========================
|
# =========================
|
||||||
|
|
||||||
def split_abap_code(content):
|
def split_abap_code(content):
|
||||||
"""
|
"""
|
||||||
Découpe :
|
Découpe :
|
||||||
- METHOD
|
- METHOD
|
||||||
- FORM
|
- FORM
|
||||||
- FUNCTION
|
- FUNCTION
|
||||||
"""
|
"""
|
||||||
|
|
||||||
patterns = [
|
patterns = [
|
||||||
r"METHOD\s+.*?ENDMETHOD\.",
|
r"METHOD\s+.*?ENDMETHOD\.",
|
||||||
r"FORM\s+.*?ENDFORM\.",
|
r"FORM\s+.*?ENDFORM\.",
|
||||||
r"FUNCTION\s+.*?ENDFUNCTION\."
|
r"FUNCTION\s+.*?ENDFUNCTION\."
|
||||||
]
|
]
|
||||||
|
|
||||||
chunks = []
|
chunks = []
|
||||||
|
|
||||||
for pattern in patterns:
|
for pattern in patterns:
|
||||||
matches = re.findall(
|
matches = re.findall(
|
||||||
pattern,
|
pattern,
|
||||||
content,
|
content,
|
||||||
re.IGNORECASE | re.DOTALL
|
re.IGNORECASE | re.DOTALL
|
||||||
)
|
)
|
||||||
|
|
||||||
chunks.extend(matches)
|
chunks.extend(matches)
|
||||||
|
|
||||||
# fallback si aucun chunk
|
# fallback si aucun chunk
|
||||||
if not chunks:
|
if not chunks:
|
||||||
chunks = [content]
|
chunks = [content]
|
||||||
|
|
||||||
return chunks
|
return chunks
|
||||||
# =========================
|
# =========================
|
||||||
# RAG SEARCH
|
# RAG SEARCH
|
||||||
# =========================
|
# =========================
|
||||||
|
|
||||||
def retrieve_context(query, top_k=5):
|
def retrieve_context(query, top_k=5):
|
||||||
|
|
||||||
query_embedding = model.encode(query).tolist()
|
query_embedding = model.encode(query).tolist()
|
||||||
|
|
||||||
results = collection.query(
|
results = collection.query(
|
||||||
query_embeddings=[query_embedding],
|
query_embeddings=[query_embedding],
|
||||||
n_results=top_k
|
n_results=top_k
|
||||||
)
|
)
|
||||||
|
|
||||||
documents = results["documents"][0]
|
documents = results["documents"][0]
|
||||||
metadatas = results["metadatas"][0]
|
metadatas = results["metadatas"][0]
|
||||||
|
|
||||||
context_parts = []
|
context_parts = []
|
||||||
|
|
||||||
for doc, meta in zip(documents, metadatas):
|
for doc, meta in zip(documents, metadatas):
|
||||||
|
|
||||||
source = meta.get("source", "unknown")
|
source = meta.get("source", "unknown")
|
||||||
|
|
||||||
context_parts.append(f"""
|
context_parts.append(f"""
|
||||||
SOURCE FILE:
|
SOURCE FILE:
|
||||||
{source}
|
{source}
|
||||||
|
|
||||||
CODE:
|
CODE:
|
||||||
{doc}
|
{doc}
|
||||||
""")
|
""")
|
||||||
|
|
||||||
return "\n\n".join(context_parts)
|
return "\n\n".join(context_parts)
|
||||||
# --- Programme principal ---
|
# --- Programme principal ---
|
||||||
if __name__ == "__main__":
|
if __name__ == "__main__":
|
||||||
folder_or_file = input("Entrez le chemin d'un dossier ou d'un fichier à analyser : ")
|
folder_or_file = input("Entrez le chemin d'un dossier ou d'un fichier à analyser : ")
|
||||||
outputdir = input("Entrez le chemin du dossier de sortie pour les documentations générées : ")
|
outputdir = input("Entrez le chemin du dossier de sortie pour les documentations générées : ")
|
||||||
if os.path.isdir(folder_or_file):
|
if os.path.isdir(folder_or_file):
|
||||||
all_files = []
|
all_files = []
|
||||||
|
|
||||||
for root, dirs, files in os.walk(folder_or_file):
|
for root, dirs, files in os.walk(folder_or_file):
|
||||||
for file in files:
|
for file in files:
|
||||||
if file.endswith(".abap"):
|
if file.endswith(".abap"):
|
||||||
all_files.append(
|
all_files.append(
|
||||||
os.path.join(root, file)
|
os.path.join(root, file)
|
||||||
)
|
)
|
||||||
print("INDEXATION RAG...")
|
print("INDEXATION RAG...")
|
||||||
index_folder(folder_or_file)
|
index_folder(folder_or_file)
|
||||||
|
|
||||||
print("GÉNÉRATION DOCUMENTATION...")
|
print("GÉNÉRATION DOCUMENTATION...")
|
||||||
|
|
||||||
for root, dirs, files in os.walk(folder_or_file):
|
for root, dirs, files in os.walk(folder_or_file):
|
||||||
|
|
||||||
for file in files:
|
for file in files:
|
||||||
|
|
||||||
if file.endswith(".abap"):
|
if file.endswith(".abap"):
|
||||||
|
|
||||||
filepath = os.path.join(root, file)
|
filepath = os.path.join(root, file)
|
||||||
|
|
||||||
print(f"\nDocumentation de {filepath}")
|
print(f"\nDocumentation de {filepath}")
|
||||||
|
|
||||||
result = document_file(filepath)
|
result = document_file(filepath)
|
||||||
|
|
||||||
if result:
|
if result:
|
||||||
|
|
||||||
documentation = result['response']
|
documentation = result['response']
|
||||||
|
|
||||||
output_name = os.path.splitext(file)[0]
|
output_name = os.path.splitext(file)[0]
|
||||||
|
|
||||||
with open(
|
with open(
|
||||||
f"{outputdir}/documentation_{output_name}.md",
|
f"{outputdir}/documentation_{output_name}.md",
|
||||||
"w",
|
"w",
|
||||||
encoding="utf-8"
|
encoding="utf-8"
|
||||||
) as f:
|
) as f:
|
||||||
|
|
||||||
f.write(documentation)
|
f.write(documentation)
|
||||||
|
|
||||||
print(f"Documentation générée : documentation_{output_name}.md")
|
print(f"Documentation générée : documentation_{output_name}.md")
|
||||||
elif os.path.isfile(folder_or_file):
|
elif os.path.isfile(folder_or_file):
|
||||||
content = open(folder_or_file, "r").read()
|
content = open(folder_or_file, "r").read()
|
||||||
result = chat(f'''peux-tu m'expliquer le fonctionnement du fichier {content} ton résultat devra être en markdown avec plusieurs sections :
|
result = chat(f'''peux-tu m'expliquer le fonctionnement du fichier {content} ton résultat devra être en markdown avec plusieurs sections :
|
||||||
une section algorithmie, où tu explique le fonctionnement général du programme
|
une section algorithmie, où tu explique le fonctionnement général du programme
|
||||||
une section objets, où tu explique les différents objets utilisés dans le programme et leur rôle.''' )
|
une section objets, où tu explique les différents objets utilisés dans le programme et leur rôle.''' )
|
||||||
|
|
||||||
if result:
|
if result:
|
||||||
print(f"\n[réponse: {result}]")
|
print(f"\n[réponse: {result}]")
|
||||||
print(f"\n[Conversation ID: {result['conversation_id']}]")
|
print(f"\n[Conversation ID: {result['conversation_id']}]")
|
||||||
documentation = result['response']
|
documentation = result['response']
|
||||||
file_name = os.path.basename(folder_or_file).split('.')[0]
|
file_name = os.path.basename(folder_or_file).split('.')[0]
|
||||||
with open(f"documentation_{file_name}.md", "w", encoding="utf-8") as f:
|
with open(f"documentation_{file_name}.md", "w", encoding="utf-8") as f:
|
||||||
f.write(documentation)
|
f.write(documentation)
|
||||||
else:
|
else:
|
||||||
print("Le chemin spécifié n'est ni un fichier ni un dossier valide.")
|
print("Le chemin spécifié n'est ni un fichier ni un dossier valide.")
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user