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 :
- Il lit une table de règles de paiement personnalisée (
ZPAYMENTRULES) pour identifier la liste des fournisseurs éligibles.
- Il interroge la table standard SAP des postes ouverts fournisseurs (
BSIK) pour récupérer les factures non soldées (types RE et KR).
- 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.
- Il filtre les paiements à effectuer à la date du jour ou avant la date de sélection (
for_date).
- 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).
- Il journalise chaque opération (succès / erreur) dans la table
ZPAYMENTSLOG.
- 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
