---
name: s51-supplier-onboarding-audit
description: Audit complet d'onboarding fournisseur — vérification des données manquantes (IBAN, contact, adresse) et activité récente
tags: [fournisseurs, onboarding, audit, ap-manager, iban, donnees]
when_to_use: Pour auditer la complétude du référentiel fournisseurs, identifier les fournisseurs avec données incomplètes bloquant les paiements, ou lors d'un onboarding de nouveau fournisseur
personas: [ap-manager, procurement]
use_cases: [gestion-fournisseurs, conformite]
frequency: weekly
complexity: beginner
score: 85
tools_used: [get_suppliers, get_payables]
---

# Audit onboarding fournisseur

## But
Vérifier la complétude des données de chaque fournisseur actif : coordonnées bancaires (IBAN, BIC), contact, adresse, et cohérence avec l'activité réelle. Permet d'identifier les fournisseurs bloquants avant le prochain run de paiement.

## Instructions

### Étape 1 — Récupérer tous les fournisseurs actifs

⚠️ **Bug vérifié** : `get_suppliers` n'a **pas** de paramètre `status`. Le paramètre correct est `isArchived`, une **string** (pas un boolean) : `isArchived: "false"`.

⚠️ **Bug vérifié — aucun `pageSize` n'est fiable, y compris `pageSize=1`** : les fournisseurs partageant un compte AP consolidé (`accountPayable.supplierIds`) peuvent faire exploser la taille de la réponse — testé et confirmé en échec même à `pageSize=1`. Ce skill nécessitant par nature un audit complet du référentiel, il est structurellement exposé : prévenir l'utilisateur que certaines pages échoueront systématiquement (pas juste "à réessayer avec un pageSize plus petit") et les signaler comme non auditées plutôt que de bloquer tout le rapport.

```
Appelle get_suppliers avec isArchived: "false" et pageSize: 1, en paginant (meta.pagination.hasNextPage) et en sautant les pages qui échouent.
Pour chaque fournisseur : noter id, name, iban, bic, bankCountry, email, 
address, createdAt, updatedAt.
```

### Étape 2 — Contrôle de complétude des données
```
Pour chaque fournisseur, vérifier :
  IBAN : présent et non vide → ✅ / ❌ "IBAN manquant"
  BIC : présent et non vide → ✅ / ❌ "BIC manquant"
  Email ou contact : présent → ✅ / ⚠️ "Pas de contact"
  Adresse : présente → ✅ / ⚠️ "Adresse manquante"

Créer une scorecard par fournisseur : 0 à 4 champs remplis.
```

### Étape 3 — Croisement avec l'activité de paiement
```
Pour les fournisseurs avec IBAN manquant :
  Appelle get_payables avec supplierId pour les 90 derniers jours
  Si des payables pending existent → BLOQUANT (paiement impossible sans IBAN)
  Si aucun payable récent → fournisseur inactif (à archiver?)

Pour les fournisseurs créés dans les 30 derniers jours :
  Vérifier s'ils ont déjà des payables (activité normale) ou aucune (onboarding en cours)
```

### Étape 4 — Identification des fournisseurs suspects
```
Signaler comme "À vérifier" :
  - Fournisseur créé < 7 jours avec une grosse facture déjà soumise (risque fraude)
  - IBAN d'un pays différent du pays du fournisseur (vérification recommandée)
  - Fournisseur mis à jour très récemment (changement de RIB — protocole de validation?)
```

### Étape 5 — Rapport d'onboarding
```
Présenter :
🔴 BLOQUANTS (IBAN manquant avec payables pending) — X fournisseurs, X€ bloqués
🟡 INCOMPLETS (données manquantes, pas de payable urgent) — X fournisseurs
🟢 NOUVEAUX À VÉRIFIER (créés < 30j) — X fournisseurs
⚠️ CHANGEMENTS RIB RÉCENTS (updatedAt < 7j avec changement bancaire) — X fournisseurs

Action recommandée par catégorie.
```

## Points d'attention
- Ne jamais modifier un IBAN sans confirmation écrite du fournisseur (fraude au virement)
- Les fournisseurs archivés n'apparaissent pas avec `isArchived: "false"` — utiliser `isArchived: "true"` séparément si besoin
- Faire tourner ce skill chaque semaine avant le run de paiement

## Exemples de prompts
- "Quels fournisseurs ont des données incomplètes qui bloquent les paiements ?"
- "Audit complet de mon référentiel fournisseurs"
- "Y a-t-il des changements de RIB récents que je dois valider ?"