ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.
PIP 0A1 — Notification de défaillance

PIP 0A1 — Notification de défaillance

Choréographie RosettaNet du cluster 0 (RosettaNet Support), couvrant l'échange XML entre Failure Notifier ↔ Failure Recipient. Maille opérationnelle pour rosettanet support sur RNIF V02.00.

Objet du PIP

Le PIP 0A1 transporte une notification de défaillance applicative ou de traitement : un partenaire signale à un autre, ou à un opérateur de confiance, qu'un PIP précédemment échangé n'a pas pu être traité (signature invalide, contenu mal formé, choréographie interrompue). Il sert de complément hors-bande au mécanisme RNIF Exception, quand le problème est détecté côté métier plutôt qu'au niveau enveloppe.

Structure du message

La choréographie 0A1 suit le modèle à une action (notification) de RosettaNet :

  • Action : Failure Notification Action
  • Signal : Receipt Acknowledgment

Chaque action est emballée dans une enveloppe RNIF V02.00 multipart MIME signée S/MIME. Voici une vue condensée de l'enveloppe :

text rnif-envelope-0A1.eml
MIME-Version: 1.0
Content-Type: multipart/related; type="application/xml";
  boundary="RN-BOUNDARY-2026"

--RN-BOUNDARY-2026
Content-Type: application/xml
Content-Location: RN-Preamble.xml

<Preamble xmlns="http://www.rosettanet.org/RNIF/V02.00">
  <standardName>RosettaNet</standardName>
  <standardVersion>V02.00</standardVersion>
</Preamble>

--RN-BOUNDARY-2026
Content-Type: application/xml
Content-Location: RN-ServiceHeader.xml

<ServiceHeader xmlns="http://www.rosettanet.org/RNIF/V02.00">
  <GlobalProcessIndicatorCode>0A1</GlobalProcessIndicatorCode>
</ServiceHeader>

--RN-BOUNDARY-2026
Content-Type: application/xml
Content-Location: Pip0A1FailureNotification.xml

<!-- payload PIP 0A1 ci-dessus -->

--RN-BOUNDARY-2026--

Exemple XML simplifié

Payload PIP 0A1 minimal, à titre didactique. Les éléments structurants (fromRole, toRole, thisDocumentGenerationDateTime, et le bloc métier propre au PIP) sont obligatoires dans toute implémentation conforme.

xml pip-0A1.xml
<?xml version="1.0" encoding="UTF-8"?>
<Pip0A1FailureNotification xmlns="http://www.rosettanet.org/PIP0A1">
  <fromRole>
    <PartnerRoleDescription>
      <GlobalPartnerRoleClassificationCode>FailureNotifier</GlobalPartnerRoleClassificationCode>
    </PartnerRoleDescription>
  </fromRole>
  <toRole>
    <PartnerRoleDescription>
      <GlobalPartnerRoleClassificationCode>FailureRecipient</GlobalPartnerRoleClassificationCode>
    </PartnerRoleDescription>
  </toRole>
  <thisDocumentGenerationDateTime>
    <DateTimeStamp>20260515T101500Z</DateTimeStamp>
  </thisDocumentGenerationDateTime>
      <FailureType>
        <GlobalFailureTypeCode>Choreography</GlobalFailureTypeCode>
      </FailureType>
      <FailureReason>
        <FreeFormText>PIP3A4 message ID PO-2026-987654 rejected: invalid SHA-256 signature</FreeFormText>
      </FailureReason>
      <ReferenceTrackingID>PO-2026-987654-RN</ReferenceTrackingID>
</Pip0A1FailureNotification>

Transport et acquittement

Transport classique RNIF V02.00 sur HTTPS (POST sur l'endpoint du partenaire) ou AS2. Le PIP 0A1 est typiquement envoyé en best-effort, sans signal de retour, pour éviter un cycle d'erreurs en cascade.

Le canal d'acheminement est typiquement AS2 ou HTTPS direct (RNIF over HTTP). Pour un référentiel des couches de sécurité utilisées, voir la page AS2 sur ediverse.

Cas d'usage

Un OSAT (Outsourced Semiconductor Assembly and Test) reçoit un PIP 3A4 de TSMC mais la signature S/MIME échoue à la vérification. L'OSAT émet un PIP 0A1 vers le service support de TSMC : message PO ciblé, type de défaillance Signature, raison détaillée, identifiant de tracking pour la corrélation.

Pour aller plus loin