BR-DE-2: Die Gruppe „SELLER CONTACT“ fehlt

Was die Regel prüft

BR-DE-2 prüft nur, ob der Kontaktblock als Ganzes vorhanden ist. In der EN 16931 ist BG-6 optional, die XRechnung-Spezifikation setzt die Anzahl auf 1.

• UBL: Kontext cac:AccountingSupplierParty, Test cac:Party/cac:Contact. Es muss also ein cac:Contact direkt im cac:Party des Verkäufers stehen.
• CII: Kontext ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty, Test ram:DefinedTradeContact.

Der Inhalt des Blocks wird von drei eigenen Regeln geprüft: BR-DE-5 für die Kontaktstelle, BR-DE-6 für die Telefonnummer und BR-DE-7 für die E-Mail-Adresse. Diese Regeln haben den Kontaktblock als Kontext. Solange er fehlt, tauchen sie im Prüfbericht nicht auf. Sobald Sie einen leeren oder halb gefüllten Block einfügen, verschwindet BR-DE-2, und die Einzelregeln melden sich. Wer nur das Element anlegt, tauscht also eine Meldung gegen bis zu drei neue.

Typische Ursachen

• Kontakt kommt aus dem Benutzerprofil. Manche Programme füllen BG-6 mit den Daten des angemeldeten Bearbeiters. Läuft die Rechnungserstellung als Stapel oder Hintergrundjob ohne Benutzer, bleibt der Block leer und wird weggelassen.
• Kontakt beim falschen Beteiligten. Der Generator schreibt die Kontaktdaten in den Käufer (cac:AccountingCustomerParty bzw. ram:BuyerTradeParty) oder in den Zahlungsempfänger. Der Verkäufer hat dann formal keinen Kontakt.
• Export für EN 16931 mit XRechnung-Kennung. Die Datei wurde mit einem Exportmodul für die europäische Norm erzeugt, in der BG-6 optional ist, trägt aber in BT-24 die Kennung urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0.
• Alles-oder-nichts-Logik im Code. Der Generator legt den Block nur an, wenn alle drei Felder Werte haben. Fehlt eines, entfällt der gesamte Block, und die Meldung zeigt nicht, welches Feld der Auslöser war.

Beispiel aus der KoSIT-Testsuite

Testdatei 01.21 zeigt einen vollständigen Kontaktblock. In UBL steht cac:Contact am Ende von cac:Party, nach cac:PartyLegalEntity.

  <cac:PartyLegalEntity>
    <cbc:RegistrationName>Mustermann GmbH</cbc:RegistrationName>
  </cac:PartyLegalEntity>
  <cac:Contact>
    <cbc:Name>Wolfgang Muster</cbc:Name>
    <cbc:Telephone>069-12335</cbc:Telephone>
    <cbc:ElectronicMail>[email protected]</cbc:ElectronicMail>
  </cac:Contact>
</cac:Party>

In CII heißt der Block ram:DefinedTradeContact und steht in ram:SellerTradeParty nach Name und Kennung, vor der Postanschrift.

<ram:SellerTradeParty>
  <ram:ID>116078</ram:ID>
  <ram:Name>Mustermann GmbH</ram:Name>
  <ram:DefinedTradeContact>
    <ram:PersonName>Wolfgang Muster</ram:PersonName>
    <ram:TelephoneUniversalCommunication>
      <ram:CompleteNumber>069-12335</ram:CompleteNumber>
    </ram:TelephoneUniversalCommunication>
    <ram:EmailURIUniversalCommunication>
      <ram:URIID>[email protected]</ram:URIID>
    </ram:EmailURIUniversalCommunication>
  </ram:DefinedTradeContact>

Bei der fehlerhaften Datei endet cac:Party direkt nach </cac:PartyLegalEntity>, und in CII folgt auf ram:Name sofort ram:PostalTradeAddress.

Lösung

In der Rechnungssoftware

1. Legen Sie einen festen Rechnungskontakt in den Firmendaten an, nicht nur im Benutzerprofil. Das sichert auch automatisch erzeugte Rechnungen ab.
2. Tragen Sie dort alle drei Angaben ein. Als Kontaktstelle genügt laut Spezifikation eine Abteilungs- oder Bürobezeichnung, etwa „Buchhaltung“.

Im XML

1. UBL: Ergänzen Sie in cac:AccountingSupplierParty/cac:Party nach cac:PartyLegalEntity ein cac:Contact mit cbc:Name, cbc:Telephone und cbc:ElectronicMail in dieser Reihenfolge.
2. CII: Ergänzen Sie in ram:SellerTradeParty vor ram:PostalTradeAddress ein ram:DefinedTradeContact mit ram:PersonName (oder ram:DepartmentName), ram:TelephoneUniversalCommunication/ram:CompleteNumber und ram:EmailURIUniversalCommunication/ram:URIID.
3. Validieren Sie die Datei erneut mit XRechnung prüfen und achten Sie im Bericht auf BR-DE-5 bis BR-DE-7 sowie die Warnungen BR-DE-27 und BR-DE-28 zum Format von Telefon und E-Mail.

XRechnung prüfen