---
name: s23-suppliers-sans-iban
scenario: S23
description: Identifier les fournisseurs sans IBAN — pas de filtre hasIban=false, pagination complète + filtrage client-side obligatoire
tags: [suppliers, iban, bank, pagination, gap]
when_to_use: Quand on veut identifier les fournisseurs à qui on ne peut pas virer (IBAN manquant) ou suivre la complétude des données bancaires fournisseurs
risk: P2 — get_suppliers n'a pas de filtre hasIban=false. Il faut paginer toute la liste et filtrer côté client. Sur ce compte, 19/20 fournisseurs de la première page n'ont pas d'IBAN.
---

# Instructions — Fournisseurs sans IBAN

## ⚠️ Pas de filtre hasIban=false

Les filtres disponibles sur `get_suppliers` :
- `ids`, `search`, `isArchived`, `iban` (exact match), `bankCountry`, `vatNumber`
- `createdAfter/Before`, `updatedAfter/Before`, `sortBy`, `sort`

**Ce qui N'existe PAS** : `hasIban=false` ou `ibanIsNull=true`

→ Il faut récupérer **tous les fournisseurs** et filtrer côté client.

## Étape 1 — Paginer tous les fournisseurs actifs

⚠️ **Bug vérifié — ce skill peut être structurellement infaisable sur certains comptes** : `get_suppliers` peut dépasser la limite de taille de réponse même à `pageSize=1` (testé et confirmé en échec, 81 179 caractères, y compris avec `sortBy: "name"`) sur des comptes où des fournisseurs partagent un compte AP consolidé (`accountPayable.supplierIds` — voir [[s22-fournisseurs-actifs-iban]]). Ce n'est **pas** réglable en baissant `pageSize` : ce skill exige par nature de parcourir **tous** les fournisseurs, donc c'est le cas le plus exposé des 63 skills à ce problème — potentiellement impossible à exécuter en pratique sur un compte avec des fournisseurs consolidés lourds.

```json
{ "companyId": "...", "isArchived": "false", "pageSize": 1, "page": 1 }
```

Répéter avec `page=2, 3, ...` jusqu'à `hasNextPage=false`. **Avant de lancer** : prévenir l'utilisateur que (a) l'opération peut nécessiter des dizaines/centaines d'appels sur un grand référentiel, et (b) certaines pages échoueront systématiquement quel que soit le `pageSize` si elles contiennent un fournisseur à compte AP consolidé — dans ce cas, sauter la page en la signalant comme "non vérifiée" plutôt que de bloquer tout le skill. Ce comportement doit être signalé comme un bug MCP, pas présenté comme une limite normale du skill.

⚠️ Ne pas conclure sur la première page — les fournisseurs avec IBAN peuvent être sur d'autres pages.

## Étape 2 — Filtrer côté client

Sur chaque fournisseur retourné, vérifier :
```
si iban == null ET bankAccount == null → pas de données bancaires
si iban != null → IBAN disponible (peut virer)
si bankAccount != null → compte bancaire sans IBAN standard
```

Note : `bankAccount` peut contenir des données bancaires non-IBAN (ex: UK sort code, US routing number).

## Étape 3 — Afficher le rapport

Afficher deux listes :
1. **Fournisseurs sans IBAN** (iban=null) — nom + id — à qui vous ne pouvez pas virer
2. **Fournisseurs avec IBAN** — nom + IBAN tronqué — prêts pour virement

Toujours informer du scope : *"Basé sur X fournisseurs actifs. Les fournisseurs archivés ne sont pas inclus."*

## Étape 4 — Cas d'usage : relance fournisseur

Pour les fournisseurs sans IBAN, l'email est disponible dans le champ `email` de chaque supplier.
→ Extraire email + nom pour préparer une relance de demande de coordonnées bancaires.

## Exemple live (données réelles, première page)

- 20 fournisseurs retournés, `hasNextPage=true` (liste incomplète)
- 1/20 avec IBAN : +Simple.fr — `FR76151350050008004002...` (tronqué pour affichage)
- 19/20 avec iban=null — dont des fournisseurs comme 't Hotel, Oracle (id: 5lwylc0am6e0p7)...
- `bankAccount` = null pour tous les 20 de la première page

## Exemple de prompt

- "Quels fournisseurs n'ont pas d'IBAN ?" → paginer tous + filter iban=null
- "Liste les fournisseurs à qui on peut virer" → filter iban != null
- "Combien de fournisseurs actifs ont des coordonnées bancaires ?" → count iban != null sur liste complète