Die MDN (Message Disposition Notification) ist eine elektronische Empfangsbestätigung, die bei der Übertragung über AS2 an den Sender zurückgegeben wird. Sie ist für jede Nachricht eindeutig.
Fordert der Empfänger Ihrer Nachricht eine solche MDN an, finden Sie diese in eGate unter dem Reiter „DeliveryReport“.
Hier wird eBiss mit einer Datenbank verwendet, auf den Files bestehen aber keine Schreibrechte. Das kann in den Windows Rechte Einstellungen angepasst werden.
Stellen Sie sicher, dass sowohl der eBiss Client Benutzer als auch der eBiss Service Benutzer Schreibrechte auf die Dateien im eBiss Ordner haben.
Um Typsätze in eBiss partnerspezifisch einzustellen geht man wie folgt vor:
Bitte beachten: Die Tooltips über den Parameternamen der Jobobjekte On MouseOver geben ausführliche Hinweise
Aus Sicherheitsgründen nehmen wir keine Dokumente an, die potentiell Schadsoftware enthalten oder solche beim Öffnen aktivieren können. Folgende Inhalte werden blockiert:
– .DOC, .DOT, .DOCM, .DOTM
– .XLA, .XLS, .XLT, .XLSB, .XLSM, .XLTM, .XLAM
– .PPT, .PPTM, .POTM, .PPSM, .PPAM, .PPA
– sowie direkt ausführbare Formate, Batch und Scriptsprachen
Bitte nutzen Sie stattdessen .DOCX, .XLSX, .PPTX oder .PDF, um uns die Inhalte zukommen zu lassen.
Weiterführende Informationen erhalten Sie u.a. auch hier:
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html
Mit Hilfe der MappingFunktion „LoadDocumentByOid()“ kann man innerhalb eines Mappings ein beliebiges Dokument aus eBiss heraus laden, um beispielsweise Daten, die aus mehr als einer Quelle kommen, in ein Zieldokument zu schreiben.
Die Oid ermittelt man mit Hilfe der GetMessage() Funktion. In diesem konkreten Fall will man das Dokument das innerhalb derselben Message ist und den Typ LSB hat. Das geht mit
Am einfachsten wird das verwendet, indem man die Funktion interaktiv im Debugger ausführt.
Die Oid kann man dazu raussuchen und als Konstante mit eingeben und schon sieht man das Funktionsergebnis als Baum.
Neue Funktionalität für die DiffMappings ist eingebaut. Dazu gibt es neu die Funktion LoadStatefulDocument, mit deren Hilfe man die vorherige erfolgreich verarbeitete Version desselben Dokumentes bekommt und diese dann laden kann. In diesem Zusammenhang kann man nun nicht mehr länger einfach mit dem RemoveMessage JobStep die alten Messages löschen, sondern sollte das so machen, dass das nicht nur nach Zeit, sondern eben auch nach der letzten Dokumenteninstanz geht. Insgesamt kann es dann sein, dass man mehrere tausend Dokumente vorhalten muss.
Um in diesem Szenario qualifiziert zu löschen, gibt es nun diesen neuen JobStep StatefulDocumentMessageCollector, der Messages einsammelt. Diese kann man dann mit dem JobStep MessageDeletor verbinden und so die alten Messages löschen.
Parameter:
MessageBox auf der gesucht werden soll
StatefulEntityTypeName ist der EntityType nach dem gesucht werden soll
NumberOfDocumentInstancesToKeep gibt an, wie viele erfolgreich verarbeitete Dokumenteninstanzen noch vorgehalten werden sollen >= 1
MinStateToCollect gibt an ab welchem Status ein Dokument / Message als erfolgreich angesehen wird.
Rest wie beim MessageCollector
Die Funktion sammelt dann die Messages ein, die genau ein Dokument des EntityTypes enthalten. Dann wird festgestellt, ob es ältere Dokumente desselben Types mit derselben DokumentenNr gibt. Es wird nach EntryDate absteigend sortiert und sobald die Anzahl „zu behaltender Dokumente“ mit derselben DokumentenNr erreicht ist, werden die älteren Instanzen der Dokumente/Messages eingesammelt und in den Job als InputMessages geladen.
Von dort können diese dann beispielsweise mit dem MessageDeletor gelöscht werden, oder auch in eine andere MessageBox verschoben werden etc.
Hier handelt es sich zunächst nur um einen Hinweis, dass die Nachricht noch nicht erfolgreich übertragen werden konnte.
Der SMTP Status Code 450 4.3.2 besagt, dass der Exchange Server der Gegenseite den Empfang von Nachrichten eingefroren hat, z. B., weil dort ein Problem behoben wird.
„This notification can be ignored if you don’t receive another tracker that reports an error for the message in question.“
Das bedeutet, dass es sich hierbei nur um eine Warnung handelt; sollte die Nachricht wiederholt nicht zugestellt werden können, erhalten Sie eine Fehlermeldung.
Unternehmen müssen Sie zu diesem Zeitpunkt nichts, eGate informiert Sie an dieser Stelle lediglich, dass die Nachricht auf der Gegenseite noch nicht zur Verfügung steht.
Die Verwaltung synchronisierter Verzeichnisse ist mit eBiss 3 möglich. Man benötigt dazu jeweils einen Harddisk ChannelReceiver, den passenden ChannelSender und einen FileEventListener. Damit nur jeweils geänderte Dateien übertragen werden, prüfen die EventListener auf das ArchivFlag, nur wenn eine Datei geändert wurde, erhält sie das ArchivFlag. Die Dateien werden abgeholt, übermittelt und auf der anderen Seite wieder geschrieben.
OnlyCheckFilesWithArchiveFlag prüft auf Dateien mit Archive Flag. Anders als sonst, wird auch auch geprüft, dass keine versteckten Dateien ausgelöst werden, außerdem muss sich die Datei auch noch exclusiv öffnen lassen, sonst schlägt der EventListener nicht an. (Man kann das im LogDebug nachverfolgen).
Stellen Sie den Channel so ein, dass er exclusiv lockt:
Eine funktionierende Beispielkonfiguration ist in StandardTemplates unter DirectorySync zu finden. Zusätzlich zu den vorgestellten neuen Eigenschaften gibt es noch zwei Erweiterungen. Zum einen prüft der HarddiskChannelSender auf ein gesetztes ArchiveFlag beim Schreiben und falls er das findet (Datei wurde auch beiden Seiten geändert), wird die neue Datei mit einem Zähler daneben gelegt, damit die Benutzer die Möglichkeit haben die Änderungen zusammenzuführen. Man kann dem HarddiskReceiver nun ein MaxKB Limit mitgeben, damit nicht alle Daten sofort abgeholt werden (Im Falle grosser Verzeichnisse). Dann nimmt er so lange Dateien, bis die Grenze zum ersten mal überschritten ist, aber eben mindestens eine Datei. Zusätzlich hat man die Möglichkeit mit der neuen JobBox MEssageContentRemover, den Inhalt grosser Dateien direkt wieder aus dem MessageStore zu entfernen.
Gemäß der ZUGFeRD-Spezifikation sind EDIFACT INVOIC mit den BGM-Qualifiern 380, 84 und 389 zulässig.
Für Pranke Elektronische Rechnung (PER) werden Gutschriften vom Typ 381 in Rechnungskorrekturen vom Typ 380 umgewandelt.
891 5.1 Definierte Rechnungsarten
892 Es werden bei ZUGFeRD die folgenden Rechnungsarten unterstützt:
893 ZUGFeRD Basic
894 • Handelsrechnung (Rechnung für Waren und Dienstleistungen) mit dem Code 380
895 • Bescheide (z. B. Zahlungsaufforderung von Behörden) mit dem Code 380
896 Kaufmännische Gutschrift (z.B. Rechnungskorrektur/Storno) mit negativen Werten (Code 380)
897 In ZUGFeRD Comfort zusätzlich:
898 • Wertbelastung/Wertrechnung ohne Warenbezug (Code 84)
899 • Wertgutschrift ohne Warenbezug mit negativen Werten (Code 84)
900 In ZUGFeRD Extended zusätzlich:
901 • Selbst ausgestellte Rechnung (Steuerrechtliche Gutschrift/Gutschriftsverfahren, Code 389)
902 • Selbst ausgestellte Gutschrift mit negativen Werten (Code 389)
Quelle: https://www.ferd-net.de/downloads/zugferd-1.0/index.html
Um im UNB Segment die Testkennung zu setzen, ist in dem Feld 0035 eine ‚1‘ einzutragen.