EDI-Fehlerbehebung

Diese Anleitung behandelt häufige Fehler und Probleme bei der Verwendung von Jitterbit EDI. Beginnen Sie mit den Diagnoseschritten unten und suchen Sie dann Ihr spezifisches Problem im relevanten Abschnitt.

Eine einheitliche Referenz, die Integrations-, Automatisierungs-, API-Management-, EDI- und App-Entwicklungsprobleme an einem Ort abdeckt, finden Sie im Harmony-Fehlerbehebungsleitfaden.

Bei Problemen mit einem Studio-Vorgang, der sich in Jitterbit EDI integriert (z. B. einer, der den EDI for Cloud v2-Connector verwendet), siehe Vorgangsfehlerbehebung oder Fehlerbehebung für private Agenten, wenn der Vorgang auf einem privaten Agenten ausgeführt wird.

Diagnoseschritte

Transaktionsstatus überprüfen

Öffnen Sie die Seite Transaktionen und filtern Sie nach fehlgeschlagenen oder abgelehnten Transaktionen. Der Status und alle zugehörigen Fehlermeldungen für die Transaktion sind die primären Indikatoren dafür, was schief gelaufen ist.

Messaging-Seite überprüfen

Die Seite Messaging zeigt EDI-Systemprotokolle an. Um Meldungen zu einer fehlgeschlagenen Übertragung oder einem Dokument zu finden, filtern Sie nach Fehler-Status, Handelspartner, Schweregrad (Hoch, Mittel, Niedrig oder Info) und Nachrichtenkategorie. Filtern Sie bei Übertragungsproblemen nach der Kategorie Kommunikation (AS2-, FTP- und VAN-Kanäle); filtern Sie bei Dokumentverarbeitungsproblemen nach der Kategorie Transaktion (Processor und Validation).

Archive-Seite überprüfen

Die Seite Archiv enthält die unverarbeiteten ein- und ausgehenden EDI-Dokumente für archivierte Transaktionen. Die Überprüfung eines archivierten Dokuments kann bestätigen, ob ein Fehler im Dokumentinhalt selbst oder in der Verarbeitungslogik liegt.

Überprüfen Sie die Betriebs- und Agent-Protokolle

Wenn Ihre Integration den EDI for Cloud v2-Connector in einem Studio-Betrieb verwendet, überprüfen Sie zunächst die Betriebsprotokolle auf Fehler aus dem Betriebslauf. Wenn der Betrieb auf einem privaten Agent ausgeführt wird und Sie Details auf niedrigerer Ebene wie Konnektivitätsfehler benötigen, überprüfen Sie auch die Agent-Protokolle.

EDI-Kommunikationsfehler

AS2-Verbindungs- oder Zertifikatsfehler

• Symptom: Ausgehende AS2-Übertragungen schlagen fehl oder Bestätigungen des Handelspartners werden nicht empfangen.
• Mögliche Ursachen:
  • Das AS2-Zertifikat ist abgelaufen oder wird vom Handelspartner nicht mehr als vertrauenswürdig eingestuft.
  • Der Zertifikatsalgorithmus stimmt nicht mit den Anforderungen des Handelspartners überein (z. B. SHA-1 vs. SHA-256).
  • Die AS2-Endpunkt-URL, die Partner-ID oder andere Verbindungsparameter sind falsch.
  • Eine Firewall oder Netzwerkbeschränkung blockiert ausgehenden AS2-Datenverkehr auf Port 443 oder dem konfigurierten AS2-Port.
• Lösung:
  • Überprüfen Sie die AS2-Kommunikationseinstellungen für den betroffenen Handelspartner und bestätigen Sie, dass die Endpunkt-URL, Partner-IDs und Zertifikatseinstellungen korrekt sind.
  • Überprüfen Sie das Zertifikatsverfallsdatum und erneuern Sie es, falls es abgelaufen ist. Tauschen Sie das aktualisierte Zertifikat mit dem Handelspartner aus.
  • Bestätigen Sie, dass der Zertifikatsalgorithmus den Anforderungen des Handelspartners entspricht. Aktualisieren Sie den Algorithmus in den AS2-Einstellungen, falls erforderlich.
  • Überprüfen Sie, dass ausgehender Datenverkehr zum AS2-Endpunkt des Handelspartners von Ihrer Netzwerk-Firewall zugelassen wird.

AS2: Die Firewall des Handelspartners muss Jitterbit-IP-Adressen auf die Zulassungsliste setzen

• Symptom: Ein Handelspartner meldet, dass er Ihre AS2-Übertragungen nicht empfangen kann oder deren AS2-Bestätigungen kommen nie an, obwohl Ihre ausgehenden AS2-Einstellungen korrekt zu sein scheinen.
• Mögliche Ursache: Die Firewall des Handelspartners erfordert eine explizite Zulassungsliste für eingehenden Datenverkehr und hat die Jitterbit-EDI-IP-Adressen nicht hinzugefügt.

• Lösung:

  • Geben Sie die folgenden Jitterbit-EDI-IP-Adressen an Ihren Handelspartner weiter und fordern Sie ihn auf, diese für ein- und ausgehenden AS2-Datenverkehr auf die Zulassungsliste zu setzen:

    • Nordamerika: 40.71.22.62
    • EMEA und APAC: 20.166.31.85

  • Informationen zu Ihrer eingehenden AS2-Empfangs-URL und der entsprechenden IP-Adresse, die Sie an Handelspartner weitergeben können, finden Sie auf der Seite AS2-Kommunikationseinstellungen für Ihre Region.

FTP- oder SFTP-Verbindungsfehler

• Symptom: FTP- oder SFTP-Übertragungen zu oder von einem Handelspartner schlagen fehl oder Dateiübertragungen hängen fest und laufen ab.
• Mögliche Ursachen:
  • Die Serveradresse, der Port, die Anmeldedaten oder die Authentifizierungsmethode (Passwort vs. SSH-Schlüssel) sind falsch oder veraltet.
  • Eine Firewall oder Netzwerkbeschränkung blockiert den erforderlichen Port zwischen Jitterbit EDI und dem FTP-/SFTP-Server.
  • Das Zielverzeichnis existiert nicht oder das Dienstkonto hat keine Lese-/Schreibberechtigungen dafür.
  • Der Host-Schlüssel auf dem SFTP-Server hat sich geändert, was zu einem Konflikt führt.
• Lösung:
  • Überprüfen Sie die FTP-Kommunikationseinstellungen für den betroffenen Handelspartner und überprüfen Sie alle Verbindungsparameter.
  • Bestätigen Sie, dass die Konnektivität zur FTP-/SFTP-Serveradresse und zum Port durch die relevanten Firewalls zugelassen wird.
  • Überprüfen Sie, dass das Dienstkonto die erforderlichen Berechtigungen für das Zielverzeichnis hat.
  • Wenn Sie SSH-Schlüssel-Authentifizierung verwenden, bestätigen Sie, dass der Schlüssel aktuell ist und vom Server akzeptiert wird. Wenn sich der Host-Schlüssel geändert hat, aktualisieren Sie den Eintrag der bekannten Hosts.

Duplikatprüfung gilt nicht für EDIXml- oder XCBL-Format

• Symptom: Doppelte eingehende Dokumente werden mehrfach verarbeitet, obwohl die Einstellung Duplikatprüfung für die AS2-Verbindung des Handelspartners aktiviert ist.
• Mögliche Ursache: Die Duplikatprüfung gilt nur für EDI-Format-Dokumente. Sie filtert keine Duplikate für EDIXml- oder XCBL-Austauschformate.
• Lösung: Falls eine Duplikatfilterung für EDIXml- oder XCBL-Workflows erforderlich ist, implementiere eine Deduplizierungslogik in der Studio-Operation, die die eingehenden Dokumente verarbeitet (z. B. durch Überprüfung einer Transaktions-ID gegen einen Datenbank- oder Cloud-Datastore-Datensatz vor der Verarbeitung).

VAN-Konnektivitätsprobleme

• Symptom: EDI-Dokumente werden nicht über ein Value Added Network (VAN) zugestellt oder empfangen.
• Mögliche Ursache: Eine VAN-Verbindung ist eine verwaltete Verbindung, die Jitterbit einrichtet; du kannst sie nicht selbst erstellen oder konfigurieren. Zustellungsfehler betreffen typischerweise die VAN-Verbindung, das Mailbox-Routing oder die Partnereinrichtung auf der Seite des Anbieters, nicht eine Self-Service-Einstellung in Jitterbit EDI.
• Lösung:
  • Stelle sicher, dass die richtige VAN-Verbindung dem betroffenen Handelspartner zugewiesen ist.
  • Da die VAN-Verbindung nicht direkt von Jitterbit EDI aus konfiguriert werden kann, kontaktiere den Jitterbit-Support oder deinen Customer Success Manager, um die VAN-Verbindung und das Dokument-Routing zu überprüfen.
  • Koordiniere mit dem VAN-Anbieter, um zu bestätigen, dass die Mailbox-Identifikatoren und das Routing des Handelspartners auf der VAN-Seite korrekt sind.

EDI for Cloud v2-Aktivität schlägt auf einem privaten Agent hinter einer Firewall oder einem Proxy fehl

• Symptom: Auf einem privaten Agent schlägt eine EDI for Cloud v2-Aktivität wie Get Document beim Abrufen von Daten fehl (z. B. mit einem Fehler „Unable to fetch data"), obwohl der Verbindungstest erfolgreich ist und das gleiche Projekt auf einer Cloud-Agent-Gruppe funktioniert.
• Mögliche Ursache: Der private Agent befindet sich hinter einer Firewall oder einem Proxy, der den ausgehenden Zugriff auf den Jitterbit eiCloud EDI-Service unter eicloudservice.com blockiert. Der EDI for Cloud v2-Connector ruft diesen Service auf (z. B. unter *.transactionapi.eicloudservice.com), um Daten abzurufen. Das Blockieren führt zum Fehler der Aktivität. Cloud-Agents sind nicht betroffen.
• Lösung:
  1. Füge eicloudservice.com und seine Subdomänen für den ausgehenden Zugriff in die Whitelist des Netzwerks, der Firewall und des Proxys des privaten Agents ein. Weitere Jitterbit-Domänen und IP-Adressen, die ein privater Agent für den ausgehenden Zugriff benötigt, findest du unter Whitelist-Informationen.
  2. Falls ein Proxy verwendet wird, stelle sicher, dass er auf dem privaten Agent korrekt konfiguriert ist und die Verbindung nicht beeinträchtigt.

Deaktiviertes EDI-Zugriffstoken verursacht INVALID_TOKEN-Fehler

• Symptom: Operationen, die den EDI for Cloud v2-Connector verwenden, schlagen fehl mit:

  Error opening connection. Exception is: Error code: INVALID_TOKEN
  

• Mögliche Ursache: Das Zugriffstoken, das von der EDI for Cloud v2-Verbindung verwendet wird, wurde auf der Seite Access Tokens der Management Console auf Inactive gesetzt.

• Lösung: Suche auf der Seite Access Tokens das Token und setze seinen Status auf Active.

Fehler bei der Dokumentverarbeitung

Dokument abgelehnt: Ungültige oder fehlende Daten

• Symptom: Ein ausgehendes EDI-Dokument wird vom Handelspartner abgelehnt oder validiert nicht, oder ein eingehendes Dokument erzeugt eine negative Bestätigung.
• Mögliche Ursachen:
  • Ein erforderliches Segment oder Datenelement fehlt im Dokument.
  • Ein Feldwert überschreitet die zulässige Länge, verwendet einen falschen Datentyp oder enthält ungültige Zeichen.
  • Der Interchange-Nutzungsindikator (ISA15) ist auf T (Test) statt auf P (Produktion) eingestellt, daher lehnt der Handelspartner das Dokument ab.
  • Das Dokument entspricht nicht dem Implementierungsleitfaden des Handelspartners.
• Lösung: Überprüfen Sie die abgelehnte Transaktion auf der Seite Transaktionen auf das spezifische Segment oder Element, das im Fehler angegeben ist, und führen Sie dann folgende Schritte durch:
  • Für ein von Ihnen gesendetes Dokument vergleichen Sie es mit dem Implementierungsleitfaden des Handelspartners, um fehlende oder nicht konforme Felder zu identifizieren, und aktualisieren Sie dann die EDI-Zuordnung und die Einstellungen für den betroffenen Dokumenttyp, um konforme Ausgaben zu erzeugen.
  • Für ein eingehendes Dokument, das vom Handelspartner gesendet wurde, teilen Sie den Validierungsfehler mit ihm, damit er sein ausgehendes Format korrigieren kann.

EDI-Zuordnungs- oder Schemafehler

• Symptom: EDI-Dokumente werden mit falschen Inhalten, fehlenden Feldern oder einer unerwarteten Struktur generiert, oder eingehende Dokumente können nicht korrekt verarbeitet werden.
• Mögliche Ursachen:
  • Die EDI-Zuordnung oder das Schema ist veraltet und spiegelt nicht den aktuellen Implementierungsleitfaden oder die Anforderungen des Handelspartners wider.
  • Quelldatenfelder sind falsch zugeordnet und erzeugen falsche Werte im Ausgabedokument.
  • Datentypabweichungen, Sonderzeichen oder Codierungsprobleme in den Quelldaten verursachen Transformationsfehler.
• Lösung:
  1. Überprüfen Sie die EDI-Einstellungen für den betroffenen Handelspartner unter EDI-Einstellungen und stellen Sie sicher, dass die Zuordnung den aktuellen Implementierungsleitfaden genau widerspiegelt.
  2. Validieren Sie, dass Quelldatenfelder den korrekten EDI-Segmenten und -Elementen zugeordnet sind.
  3. Überprüfen Sie die Quelldaten auf Sonderzeichen, Codierungsprobleme oder unerwartete Werte, die Transformationsfehler verursachen könnten, und fügen Sie bei Bedarf Datenbereinigungs-Schritte hinzu.
  4. Testen Sie mit einem repräsentativen Beispieldokument und verwenden Sie das Archiv, um die generierte Ausgabe mit der erwarteten Struktur zu vergleichen.

Transformationsfehler: Nicht erkanntes Feld in der EDI for Cloud v2-Aktivität

• Symptom: Eine Transformation mit einer EDI for Cloud v2-Aktivität (z. B. Transaktionen auflisten) schlägt mit einem JSON-Parsing-Fehler fehl, der auf einen nicht erkannten Feldnamen verweist, z. B.:

  Unrecognized field "user_defined_field_1"
  

• Mögliche Ursache: Die Version des auf dem Agent installierten EDI for Cloud v2-Connectors ist veraltet. Der Backend-EDI-Service gibt ein Feld zurück (z. B. user_defined_field_1), das die ältere Connector-Version nicht erkennt, daher kann der Connector die Antwort nicht analysieren.

• Lösung: Aktualisieren Sie den EDI for Cloud v2-Connector auf dem Agent auf die neueste Version, indem Sie Connector-Verfügbarkeit bestätigen und aktuell halten im Connector-Troubleshooting-Leitfaden befolgen. Wenn Sie auf der EDI for Cloud v2-Verbindung auf Verbindung testen klicken, wird die neueste Connector-Version auf den Agent heruntergeladen. Wenn die Organisationsrichtlinie Automatische Connector-Aktualisierung deaktivieren aktiviert ist, aktualisieren Sie stattdessen den Connector für die Agent-Gruppe über die Seite Agents in der Management Console.

Wiederholte EDI-Segmente oder Loop-Maps bilden nur die letzte Iteration ab

• Symptom: In einer Studio-Transformation werden wiederholte Segmente oder Schleifen in einem EDI-Dokument, das über den EDI for Cloud v2-Connector verarbeitet wird, nur in ihrer letzten Iteration abgebildet (frühere Iterationen werden verworfen), da die Kardinalität des Knotens im Aktivitätsschema des Connectors einfach (z. B. (0,1)) statt wiederholend ((1,many)) ist. Dies betrifft sowohl X12 (z. B. ein N9-Segment verschachtelt in einer LX-Schleife in einer 945) als auch EDIFACT (z. B. eine wiederholte CNI-Gruppe in einer IFCSUM).
• Mögliche Ursache: Das vom EDI for Cloud v2-Connector bereitgestellte automatisch generierte Schema spiegelt nicht die korrekte Kardinalität für das betroffene Segment oder die Schleife wider. Das Rohdokument im EDI-Transaktionsspeicher enthält alle Iterationen, und ein manuell aus diesem Raw-XML erstelltes Schema bildet diese korrekt ab, was das Antwortsschema des Connectors (nicht die Daten) als Ursache bestätigt.
• Lösung:
  1. Öffnen Sie die EDI for Cloud v2-Verbindung in Studio und aktualisieren Sie die Metadaten, um zu überprüfen, ob eine Schemakorrektur veröffentlicht wurde.
  2. Wenn die Kardinalität nach der Aktualisierung immer noch falsch ist, exportieren Sie das Schema, aktualisieren Sie manuell das maxOccurs-Attribut des betroffenen Segments in einem externen XML-Editor und importieren Sie es als benutzerdefinierte XSD erneut.

Verschachtelte hierarchische Loop-Ebenen (HL) zu einer EDI-Transformation hinzufügen

• Symptom: Beim Erstellen einer Studio-Transformation für einen EDI-Transaktionssatz, der hierarchische Schleifen verwendet (z. B. X12 870 4010VICS, das ähnlich wie die 856 strukturiert ist), zeigt das Schema aus der Send Document-Aktivität des EDI for Cloud v2-Connectors eine einzelne HL-Ebene, aber das Dokument, das Sie erstellen müssen, erfordert verschachtelte HL-Ebenen (z. B. eine HL-O-Bestellebene mit einer untergeordneten HL-I-Artikelebene).
• Mögliche Ursache: Hierarchische Dokumente können HL-Ebenen in unterschiedliche Tiefen verschachteln, daher stellt das Schema des Connectors eine einzelne HL-Ebene bereit, die Sie in der Transformation replizieren, um die zusätzlichen Ebenen zu erstellen, die Ihr Dokument benötigt.
• Lösung:
  1. Klicken Sie im Zielschema-Baum der Transformation mit der rechten Maustaste auf den vorhandenen HL-Knoten und wählen Sie Knoten duplizieren, um die verschachtelte HL-Ebene hinzuzufügen (z. B. eine untergeordnete HL-I-Ebene unter HL-O).
  2. Ordnen Sie den duplizierten Knoten Ihren Quelldaten zu. Fügen Sie eine Bedingung auf dem duplizierten Knoten hinzu, wenn dieser nur unter bestimmten Umständen in der Ausgabe erstellt werden soll.

Handelspartnerkonfiguration

Falsche Handelspartner-Identifikatoren

• Symptom: Dokumente werden falsch weitergeleitet, auf Umschlagebene abgelehnt oder vom Handelspartner nicht erkannt.
• Mögliche Ursachen:
  • Die EDI-ID des Absenders oder Empfängers, der Qualifizierercode oder andere Identifikatoren auf Umschlagebene stimmen nicht mit dem überein, was der Handelspartner erwartet.
  • Die Konfiguration des Handelspartners wurde kürzlich aktualisiert, aber die Änderung wurde in Jitterbit EDI nicht angewendet.
• Lösung:
  1. Überprüfen Sie die Konfiguration des Handelspartners und bestätigen Sie, dass die EDI-ID und Qualifizierercodes mit den Werten übereinstimmen, die in der Einrichtungsdokumentation des Handelspartners angegeben sind.
  2. Vergleichen Sie die Umschlag-Identifikatoren in einem abgelehnten Dokument (sichtbar im Archiv) mit den erwarteten Werten.
  3. Aktualisieren Sie die Handelspartner-Einstellungen, wenn Identifikatoren falsch sind, und verarbeiten Sie dann die betroffenen Dokumente erneut oder senden Sie sie erneut.

EDI-ID-Überschreibungswerte werden nicht auf ausgehende Transaktionen angewendet

• Symptom: Ausgehende Transaktionen verwenden die Standard-Absender- oder Empfänger-EDI-IDs aus der Handelspartnerkonfiguration anstelle der bevorzugten Überschreibungs-IDs, die in den EDI-ID-Einstellungen konfiguriert sind.
• Mögliche Ursache: EDI-ID-Überschreibungen werden nicht automatisch angewendet. Die bevorzugten IDs müssen explizit in der Request-Transformation des Studio-Vorgangs zugeordnet werden, der das ausgehende Dokument mit dem EDI for Cloud v2-Connector sendet.
• Lösung: Ordnen Sie in dieser Request-Transformation Werte diesen Feldern zu, um die bevorzugten IDs anzuwenden (siehe EDI-ID-Einstellungen-Seite für die genauen zu verwendenden Werte):
  • ISA05_ID_Qualifier: Absender-ID-Qualifizierer
  • ISA06_Sender_ID: Absender-EDI-ID
  • ISA07_ID_Qualifier: Empfänger-ID-Qualifizierer
  • ISA08_Receiver_ID: Empfänger-EDI-ID

Bestätigungen nicht konfiguriert oder nicht empfangen

• Symptom: Erwartete 997 (X12) oder CONTRL (EDIFACT) Funktionsbestätigungen werden nicht gesendet oder empfangen, oder die Bestätigungsverarbeitung funktioniert nicht wie erwartet.
• Mögliche Ursachen:
  • Die Bestätigungsgenerierung oder -verarbeitung ist in den EDI-Einstellungen des Handelspartners deaktiviert.
  • Der Bestätigungsdokumenttyp ist nicht in der Workflow-Konfiguration des Handelspartners enthalten.
  • Der Handelspartner sendet keine Bestätigungen, oder seine Bestätigungen werden falsch weitergeleitet.
• Lösung:
  • Bestätigen Sie in den EDI-Einstellungen des Handelspartners, dass die Bestätigungsgenerierung und -verarbeitung für die relevanten Dokumenttypen aktiviert sind.
  • Überprüfen Sie die Konfiguration Workflows verwalten, um zu bestätigen, dass der Bestätigungsdokumenttyp im Workflow enthalten ist.
  • Überprüfen Sie das Archiv, um festzustellen, ob Bestätigungen vom Handelspartner empfangen, aber nicht verarbeitet werden, oder überhaupt nicht ankommen.
  • Wenn Bestätigungen nicht ankommen, koordinieren Sie mit dem Handelspartner, um zu bestätigen, dass diese an den korrekten Endpunkt gesendet werden.

Zugewiesene Kommunikationsverbindung kann nicht gelöscht werden

• Symptom: Der Versuch, eine AS2- oder FTP-Verbindung in den Kommunikationseinstellungen zu löschen, schlägt fehl oder die Löschoption ist nicht verfügbar.
• Mögliche Ursache: Zugewiesene Verbindungen können nicht gelöscht werden. Eine Verbindung, die derzeit einem Handelspartner zugewiesen ist, muss vor dem Löschen entfernt werden.
• Lösung:
  1. Wählen Sie in Kommunikationseinstellungen den Handelspartner aus, der die Verbindung nutzt, und weisen Sie diesem Partner eine andere Verbindung zu.
  2. Sobald kein Partner die Verbindung mehr nutzt, wird die Löschoption verfügbar.

FTP „Nächste Ausführungszeit" wird ohne Seitenaktualisierung nicht aktualisiert

• Symptom: Die Nächste Ausführungszeit in den FTP-Kommunikationseinstellungen eines Handelspartners bleibt veraltet, nachdem der geplante FTP-Job ausgeführt wurde, obwohl der Zeitplan korrekt funktioniert.
• Mögliche Ursache: Die Benutzeroberfläche aktualisiert den Status geplanter Aufträge nur beim Laden der Seite oder wenn eine manuelle Aktion ein Neuladen der Daten auslöst. Sie fragt die Engine nicht in Echtzeit ab.
• Lösung:
  • Aktualisieren Sie die Browserseite, um die Anzeige der Nächsten Ausführungszeit zu aktualisieren.
  • Alternativ können Sie die FTP-Einstellungen verlassen und zurückkehren, um ein Neuladen zu erzwingen.

EDI-ID oder bevorzugte ID-Hinzufügung schlägt fehl: ID wird bereits verwendet

• Symptom: Das Hinzufügen einer EDI-ID oder einer bevorzugten ID zu einem Handelspartner schlägt fehl, auch wenn die ID in der aktuellen Umgebung nicht verwendet zu werden scheint. Eine der folgenden Meldungen wird angezeigt:

EDI-ID [ID] kann nicht hinzugefügt werden, da es bereits verwendet wird. Bitte bestätigen Sie und geben Sie eine eindeutige ID an.

Preferred ID [ID] kann nicht hinzugefügt werden, da es bereits verwendet wird. Bitte bestätigen Sie und geben Sie eine eindeutige ID an.

• Mögliche Ursachen:

  • Jede EDI-ID muss in allen Harmony-Umgebungen eindeutig sein, in denen Jitterbit EDI aktiviert ist. Wenn dieselbe ID bereits einem Handelspartner in einer anderen Umgebung zugewiesen ist, schlägt das Hinzufügen fehl.
  • Eine Preferred ID muss innerhalb der Umgebung eindeutig sein. Sie wird abgelehnt, wenn sie bereits demselben Handelspartner oder einem anderen Handelspartner in derselben Umgebung zugewiesen ist.

• Lösung:

  • Bei einer doppelten EDI-ID überprüfen Sie alle anderen Harmony-Umgebungen, in denen EDI aktiviert ist, um zu bestätigen, ob die ID dort bereits zugewiesen ist. Arbeiten Sie mit Ihrem Handelspartner zusammen, um eine eindeutige EDI-ID für jede Umgebung festzulegen, in der Sie Dokumente austauschen, und verwenden Sie eine unterschiedliche ID für Nicht-Produktionsumgebungen, die sich von Ihrer Produktions-EDI-ID unterscheidet.
  • Bei einer doppelten Preferred ID überprüfen Sie die Liste Preferred ID (ISA ID's) für den aktuellen Handelspartner und für andere Handelspartner in derselben Umgebung, und wählen Sie dann eine eindeutige ID.

Workflow-Konfiguration

Ausgehende Dokumente bestehen lokale Validierung, schlagen aber bei Handelspartner-Tests fehl

• Symptom: Ausgehende EDI-Dokumente bestehen die lokale Validierungsprüfung in Jitterbit EDI, werden aber während der Handelspartner-Tests oder -Zertifizierung abgelehnt, häufig mit Fehlern zu fehlenden oder nicht konformen Elementen.
• Mögliche Ursachen:
  • Die ausgehende Validierung ist in der Workflow-Konfiguration deaktiviert. Jitterbit EDI ermöglicht die Generierung von Dokumenten ohne Validierung, aber ohne diese können Dokumente Elemente vermissen, die der Implementierungsleitfaden des Handelspartners erfordert.
  • Die EDI-Einstellungen decken die wesentlichen Elemente des Standards ab, aber der Implementierungsleitfaden des Handelspartners kann zusätzliche obligatorische Elemente erfordern, die nicht durch Standardeinstellungen erzwungen werden.
• Lösung:
  • Aktivieren Sie in der Konfiguration Workflows verwalten die Validierung für den ausgehenden Workflow.
  • Überprüfen Sie den Implementierungsleitfaden des Handelspartners auf obligatorische Elemente über die Standard-EDI-Einstellungen hinaus und fügen Sie diese der Zuordnung hinzu.
  • Aktivieren Sie die Validierung immer vor dem Testen mit einem Handelspartner, es sei denn, Sie haben ein gründliches Verständnis der spezifischen EDI-Transaktion und der Anforderungen des Handelspartners.

Archiv und Transaktionen

Transaktion wird früher oder später als erwartet archiviert

• Symptom: Eine Transaktion wird vor Ablauf der erwarteten Aufbewahrungsfrist archiviert, oder sie bleibt länger als erwartet verfügbar.
• Mögliche Ursache: Transaktionen werden basierend auf dem späteren der beiden Daten archiviert: dem Transaktionsdatum und dem Dokumentdatum. Wenn das Dokumentdatum aktueller ist als das Transaktionsdatum, wird die Archivierung vom Dokumentdatum berechnet, was die Aufbewahrungsfrist verlängern kann.
• Lösung:
  • Überprüfen Sie bei der Untersuchung unerwarteter Archivierungszeitpunkte sowohl das Transaktionsdatum als auch das Dokumentdatum für die betroffene Transaktion.
  • Überprüfen Sie die Aufbewahrungsfrist-Einstellungen, um die konfigurierte Anzahl von Tagen (30, 60 oder 90) zu bestätigen.

Berechtigungen und Zugriff

Kann nicht auf EDI-Funktionen zugreifen

• Symptom: Ein Benutzer kann EDI-Seiten nicht anzeigen oder mit ihnen interagieren, oder bestimmte EDI-Aktionen sind nicht verfügbar.
• Mögliche Ursachen:
  • Der EDI-Zugriff erfordert sowohl eine EDI-spezifische Rollenberechtigung (Admin, EDI User oder EDI Viewer) als auch eine Umgebungszugriffsrolle auf Write-Ebene. Das Fehlen einer dieser Berechtigungen verhindert den Zugriff.
  • Die Rollen EDI User und EDI Viewer unterscheiden sich in ihren Möglichkeiten. EDI Viewer kann Transaktionen erneut verarbeiten, Bestätigungen erneut senden und Seiten lesen, kann aber keine Konfigurationen erstellen oder aktualisieren oder Dateien hochladen. Das Erstellen oder Aktualisieren von Konfigurationen und das Hochladen von Dateien zur Verarbeitung erfordern die Rolle EDI User. Administrative Aktionen wie das Archivieren von Transaktionen, das Aktivieren von PII und das Ändern von Löscheinstellungen erfordern die Rolle Admin.
• Lösung:
  • Überprüfen Sie in der Management Console, dass der Benutzer eine Rolle mit der Berechtigung Admin, EDI User oder EDI Viewer hat.
  • Bestätigen Sie, dass die Umgebungszugriffsstufe des Benutzers Write-Zugriff für die Umgebung umfasst, in der EDI konfiguriert ist.
  • Wenn der Benutzer Schreibvorgänge durchführen muss (z. B. Handelspartner erstellen oder Dokumente hochladen), weisen Sie die Rolle EDI User statt EDI Viewer zu. Siehe EDI-Berechtigungen für die vollständige Berechtigungsmatrix.

PII-Einstellungen können nicht aktiviert werden

• Symptom: Die Option zum Aktivieren von PII-Einstellungen (persönlich identifizierbare Informationen) für einen Handelspartner ist nicht verfügbar oder ausgegraut.
• Mögliche Ursache: Das Aktivieren von PII-Einstellungen erfordert die Admin-Berechtigung. Weder die Rolle EDI User noch EDI Viewer kann PII-Einstellungen aktivieren.
• Lösung:
  • Bestätigen Sie, dass die Rolle des Benutzers die Admin-Berechtigung umfasst, nicht nur EDI User oder EDI Viewer.
  • Wenn der Benutzer PII-Einstellungen regelmäßig verwalten muss, aktualisieren Sie die Rollenzuweisung entsprechend.