# CII-SR-465 Contact vendeur : nom de la personne ou du service, pas les deux

En CII, le point de contact du vendeur (BT-41) correspond soit à ram:PersonName, soit à ram:DepartmentName dans ram:SellerTradeParty/ram:DefinedTradeContact. CII-SR-465 (« Only one BT-41 element is allowed on an invoice ») échoue quand les deux éléments sont présents. Les artefacts de validation du CEN la signalent comme avertissement ; la configuration KoSIT pour XRechnung 3.0.2 du 31/08/2026 l’élève au rang d’erreur pour XRechnung en syntaxe CII.

## Description du problème

> **ERREUR**: Règle de syntaxe EN 16931 pour CII (CEN, CII-SR)

> **Où CII-SR-465 est contrôlée**
>
> Un validateur contrôle une facture électronique par étapes. D’abord, le fichier doit être un XML bien formé conforme au schéma UBL ou CII (XSD). Viennent ensuite les règles métier de l’EN 16931 : règles de base BR, calculs BR-CO, listes de codes BR-CL, décimales BR-DEC et règles par catégorie de TVA comme BR-S. Puis les règles nationales ou de réseau sélectionnées par BT-24 : BR-DE pour XRechnung, PEPPOL-EN16931 pour Peppol BIS Billing. Le rapport liste chaque règle en échec : une erreur signifie rejet, des avertissements seuls signifient toujours acceptation. CII-SR-465 : règle syntaxique EN 16931 pour UBL ou CII, étape « Règles EN 16931 ».

## Contexte et importance

Des fichiers acceptés par une configuration KoSIT antérieure peuvent échouer depuis la version du 31/08/2026, car la règle n’était auparavant qu’un avertissement. Les exports d’ERP écrivent souvent la personne et le service côte à côte, car les deux figurent sur le PDF.

## Solution

Gardez une seule valeur pour BT-41 : ram:PersonName pour une personne nommée, ou ram:DepartmentName s’il n’y a qu’un service, puis supprimez l’autre élément. L’UBL n’est pas concerné : BT-41 y est l’élément unique cac:Contact/cbc:Name.

- [Valider le XML](/fr/xrechnung-validator?source=resource&rule=CII-SR-465)
- [Convertir la facture](/fr/pdf-to-xrechnung?source=resource&rule=CII-SR-465)

## Exemples valides

- ram:PersonName = « Anna Schmidt »
- ram:DepartmentName = « Comptabilité » (sans PersonName)

## Exemples invalides

- ram:PersonName = « Anna Schmidt » et ram:DepartmentName = « Comptabilité »

## Exemples de code

### XML valide
```
<ram:DefinedTradeContact>
  <ram:PersonName>Anna Schmidt</ram:PersonName>
  <ram:TelephoneUniversalCommunication>
    <ram:CompleteNumber>+49 30 1234567</ram:CompleteNumber>
  </ram:TelephoneUniversalCommunication>
  <ram:EmailURIUniversalCommunication>
    <ram:URIID>billing@example.com</ram:URIID>
  </ram:EmailURIUniversalCommunication>
</ram:DefinedTradeContact>
```

### XML invalide
```
<ram:DefinedTradeContact>
  <ram:PersonName>Anna Schmidt</ram:PersonName>
  <ram:DepartmentName>Accounts receivable</ram:DepartmentName>
</ram:DefinedTradeContact>
```

## Champs concernés

- [BT-41 Point de contact du vendeur](/resources/xrechnung/bt-41-seller-contact-point)
- [BG-6 Contact du vendeur](/resources/xrechnung/bt-41-seller-contact-point)

## Règles associées

- [BR-DE-2](/resources/kosit-validator-errors/br-de-2-seller-contact-required)
- [BR-DE-5](/resources/kosit-validator-errors/br-de-5-seller-contact-point-required)
- [CII-SR-466](/resources/kosit-validator-errors/cii-sr-466-buyer-contact-person-or-department-name)

## Outils de validation

- [Validateur KoSIT officiel](https://github.com/itplr-kosit/validator): Exécutez le validateur officiel du KoSIT avec la configuration XRechnung pour contrôler les règles EN 16931 et XRechnung.
- [Convertir un PDF en XRechnung](/pdf-to-xrechnung): Repérez les erreurs de validation pendant la conversion et vérifiez chaque correction.

## Ressources associées

- [Spécification officielle](https://github.com/ConnectingEurope/eInvoicing-EN16931)
- [Suite de tests](https://github.com/itplr-kosit/xrechnung-testsuite)
- [Toutes les erreurs de validation](/resources/kosit-validator-errors): Vue d’ensemble des règles de validation EN 16931, XRechnung et Peppol expliquées ici.
