DATEV XML-Schnittstelle - Intruder Alert

[#1]

Hallo DATEV-Community,

wir haben eine Integration mit unserer Software auf Basis der DATEV-XML-Schnittstelle entwickelt und unsere Kunden konnten erfolgreich Kassenbuchvorgänge in DATEV importieren. Leider ist bei einem unserer Kunden beim Versuch, eine ZIP-Datei über belegtransfer v.5.13 (aus dem Protokoll) zu importieren, folgender Fehler aufgetreten:

Kassenbuch passt nicht zu Schema. Ursache: Intruder Alert

Im Anhang finden Sie eine Kopie der xml-Datei.

<?xml version="1.0" encoding="utf-8"?>
<LedgerImport version="5.0" generator_info="XXX" generating_system="DIS v21.46.0" xml_data="Kopie nur zur Verbuchung berechtigt nicht zum Vorsteuerabzug" xmlns="http://xml.datev.de/bedi/tps/ledger/v050" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xml.datev.de/bedi/tps/ledger/v050 Belegverwaltung_online_ledger_import_v050.xsd">
	<consolidate consolidatedAmount="-26.70" consolidatedDate="2021-11-11" consolidatedCurrencyCode="EUR">
		<cashLedger>
			<date>2021-11-11</date>
			<amount>-26.70</amount>
			<information>Payment Top-up Wallet</information>
			<currencyCode>EUR</currencyCode>
			<bookingText>APRR NFC\36 RUE DOCTEUR SCHMITT\ST APOLLINAIR\21850     FRAF</bookingText>
		</cashLedger>
	</consolidate>
</LedgerImport>

Kennen Sie diese Fehlermeldung? Die Dateien document.xml und Transaktionsdaten werden mit dem Pruftool korrekt validiert.

Vielen Dank

[#2]

@thomash_ was war nochmal der Intruder Alert?

[#3]

@larsboehnke Wenn wir einen "Parserfehler: Intruder Alert" hatten, dann lag dies immer an Sonderzeichen. Diese werden in der XML mit einem "&#" vorangestellt. Nachdem entfernen dieser Zeichen waren die Importe immer möglich. In der XML ist mir jetzt keine derartige Zeichenstellung aufgefallen. 

Das müsste man anhand der ZIP genauer analysieren. 

[#4]

... nur eine 'technische' Verständnisfrage:

... wie kann ein Mitglied bereits am 10.12.21 getaggt werden, wenn er erst am 13.12.21 neues Mitglied wird ?

edit:

... ja, jetzt habe ich den kleinen (schüchternen) Unterstrich im TAG und im 'alten' Usernamen entdeckt 😁

[#5 · Accepted solution]

Das Problem ist, dass im Buchungstext "\" enthalten sind. Wenn du diese entfernst, dann sollte der "Intruder Alert" nicht auftauchen. 

Habe es anhand deiner Daten gerade getestet. 

[#6]

Hallo @thomash, danke für deine Antwort.

Wir validieren die XML-Daten anhand der von DATEV bereitgestellten Regex (siehe: https://developer.datev.de/portal/de/dxso/zeichensatz) und alle Dateien werden erfolgreich validiert.

^[a-zA-Z0-9§@€\\t\\r\\n\\#\\|\\`\\´\\'\\^\\°\\%\\&\\\\*\\~\\:\\;\\.\\-\\/+=_ \\?\\$\\!\\{\\}\\[\\]\\,\\(\\)\\<\\>\\p{InLatin1Supplement}\\p{InCJKUnifiedIdeographs}\\p{InHangulSyllables}\\\\]*$

Seltsam ist nur, dass von den beiden folgenden Dateien die erste von DATEV abgelehnt wird, während die andere erfolgreich importiert wird:

<?xml version="1.0" encoding="utf-8"?>
<LedgerImport version="5.0" generator_info="XXX" generating_system="DIS v21.46.0" xml_data="Kopie nur zur Verbuchung berechtigt nicht zum Vorsteuerabzug" xmlns="http://xml.datev.de/bedi/tps/ledger/v050" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xml.datev.de/bedi/tps/ledger/v050 Belegverwaltung_online_ledger_import_v050.xsd">
	<consolidate consolidatedAmount="-26.70" consolidatedDate="2021-11-11" consolidatedCurrencyCode="EUR">
		<cashLedger>
			<date>2021-11-11</date>
			<amount>-26.70</amount>
			<information>Payment Top-up Wallet</information>
			<currencyCode>EUR</currencyCode>
			<bookingText>APRR NFC\36 RUE DOCTEUR SCHMITT\ST APOLLINAIR\21850     FRAF</bookingText>
		</cashLedger>
	</consolidate>
</LedgerImport>

<?xml version="1.0" encoding="utf-8"?>
<LedgerImport version="5.0" generator_info="XXX" generating_system="DIS v21.46.0" xml_data="Kopie nur zur Verbuchung berechtigt nicht zum Vorsteuerabzug" xmlns="http://xml.datev.de/bedi/tps/ledger/v050" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xml.datev.de/bedi/tps/ledger/v050 Belegverwaltung_online_ledger_import_v050.xsd">
  <consolidate consolidatedAmount="-111.87" consolidatedDate="2021-11-11" consolidatedCurrencyCode="EUR">
    <cashLedger>
      <date>2021-11-11</date>
      <amount>-111.87</amount>
      <information>Payment Top-up Wallet</information>
      <currencyCode>EUR</currencyCode>
      <bookingText>THE OUTSIDERS STORE   \47 Brunel Avenue</bookingText>
    </cashLedger>
  </consolidate>
</LedgerImport>

Der Schrägstrich ("/") ist ein gültiges ASCII-Zeichen und sollte in XML nicht weiter kodiert werden müssen.

Auf jeden Fall bin ich für Ihren Vorschlag dankbar, ich werde ihn testen und diese Konversation aktualisieren. Kennen Sie ein anderes Sonderzeichen, das den "Intruder Alert" verursachen könnte?

[#7]

Ok, tatsächlich ist das einzige Problem die "\36". Dieser Wert in dieser Kombination ist nicht zulässig. Wieso, dass weiß ich leider nicht. 😣

[#8]

Ein Fall für @Vincent_Franke 

[#9]

@mdragoni 

... kann man die Backslashs "\" im Buchungstext nicht unterdrücken oder vermeiden ?

[#10]

Vielen Dank, Leute. Wie von @thomash vorgeschlagen, hat das Ersetzen aller Backslash-Vorkommen das Problem gelöst. Es sieht so aus, als ob, obwohl DATEV den Backslash als gültiges Zeichen ansieht, die Kombination des Backslashs mit der oktalen Darstellung eines Zeichens zu dessen Interpretation führen kann (das sieht für mich wie ein Fehler aus). Zum Beispiel:

• APRR NFC\36 RUE DOCTEUR SCHMITT\ST APOLLINAIR\21850 FRAF
  • Schlägt fehl, weil \36 als RS (Record Separator) Zeichen interpretiert wird
• THE OUTSIDERS STORE \47 Brunel Avenue
  • Schlägt nicht fehl, weil \47 als ' (Apostroph) Zeichen interpretiert wird

Siehe Tabelle der Oktal-ASCII-Zeichen auf Wikipedia: https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange#ASCII-Tabelle

@vogtsburger, unsere Integration exportiert Zahlungskartentransaktionen nach DATEV, das Feld Buchungstext enthält den Händlernamen und wird von Mastercard mit den Backslash-Zeichen gesendet

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

[#11]

Hallo @ Community,

wir ergänzen unsere Schnittstellendokumentation für XML noch um das Vermeiden oder Maskieren von Backslashes "\". Was "Vermeiden" bedeutet ist denke ich klar und ein "Maskieren" innerhalb der XML wäre ein einfaches Verdoppeln in dem Fall. Möchte man also die Zeichen "\36" per XML übertragen so müsste man "\\36" in die XML-Datei schreiben. Eine abschließende Liste aller Zeichen-Kombinationen, die zu einem "Intruder Alert" führen können wir nicht anbieten.

Viele Grüße

Vincent Franke