EDI-Fehlersuche

Diese Anleitung behandelt häufige Fehler und Probleme bei der Verwendung von Jitterbit EDI. Beginnen Sie mit den Diagnoseschritten unten und finden 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. ein Vorgang, der den EDI for Cloud v2-Connector verwendet), siehe Fehlerbehebung für Vorgänge 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 damit verbundenen Fehlermeldungen für die Transaktion sind die primären Indikatoren dafür, was schief gelaufen ist.

Nachrichten-Seite überprüfen

Die Seite Nachrichten zeigt EDI-Systemprotokollmeldungen. Um Meldungen zu einer fehlgeschlagenen Übertragung oder einem Dokument zu finden, filtern Sie nach Fehlerstatus, Handelspartner, Schweregrad (Hoch, Mittel, Niedrig oder Info) und Nachrichtenkategorie. Bei Übertragungsproblemen filtern Sie nach der Kategorie Kommunikation (AS2- und FTP-Kanäle); bei Dokumentverarbeitungsproblemen filtern Sie nach der Kategorie Transaktion.

Archivseite überprüfen

Die Seite Archiv enthält die rohen 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üfung der Vorgangs- und Agent-Protokolle

Falls die Integration den Connector EDI für Cloud v2 in einem Studio-Vorgang verwendet, überprüfen Sie zunächst die Vorgangsprotokolle auf Fehler aus dem Vorgangslauf. Falls der Vorgang auf einem privaten Agent ausgeführt wird und Sie niedrigere Details 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 vertraut.
  • 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 fehlerhaft.
  • Eine Firewall- oder Netzwerkbeschränkung blockiert ausgehenden AS2-Verkehr auf Port 443 oder dem konfigurierten AS2-Port.
• Lösung:
  • Überprüfen Sie die AS2-Verbindungseinstellungen 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 Verkehr zum AS2-Endpunkt des Handelspartners durch Ihre Netzwerk-Firewall zugelassen ist.

AS2: Die Firewall des Handelspartners muss Jitterbit-IP-Adressen auf die Allowlist 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 Allowlist für eingehenden Verkehr 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-Verkehr auf die Allowlist zu setzen:

    • Nordamerika: 40.71.22.62
    • EMEA und APAC: 20.166.31.85

  • Für Ihre eingehende AS2-Empfangs-URL und die entsprechende IP-Adresse, die Sie an Handelspartner weitergeben, siehe die Seite AS2-Verbindungseinstellungen für Ihre Region.

FTP- oder SFTP-Verbindungsfehler

• Symptom: FTP- oder SFTP-Übertragungen zu oder von einem Handelspartner schlagen fehl oder Dateiübertragungen bleiben stehen und sind zeitüberschritten.
• Mögliche Ursachen:
  • Die Serveradresse, der Port, die Anmeldedaten oder die Authentifizierungsmethode (Kennwort vs. SSH-Schlüssel) sind fehlerhaft 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 hat sich auf dem SFTP-Server geändert, was zu einem Konflikt führt.
• Lösung:
  • Überprüfen Sie die FTP-Verbindungseinstellungen für den betroffenen Handelspartner und bestätigen Sie alle Verbindungsparameter.
  • Bestätigen Sie, dass Konnektivität zur FTP-/SFTP-Serveradresse und zum Port durch die relevanten Firewalls zugelassen ist.
  • Überprüfen Sie, dass das Dienstkonto die erforderlichen Berechtigungen im Zielverzeichnis hat.
  • Falls Sie SSH-Schlüssel-Authentifizierung verwenden, bestätigen Sie, dass der Schlüssel aktuell ist und vom Server akzeptiert wird. Falls der Host-Schlüssel geändert hat, aktualisieren Sie den Eintrag „Known Hosts".

Duplikat-Transaktionsprüfung gilt nicht für EDIXml- oder XCBL-Format

• Symptom: Doppelte eingehende Dokumente werden mehrmals verarbeitet, obwohl die Einstellung Duplicate transaction check für die AS2-Verbindung des Handelspartners aktiviert ist AS2-Verbindung.
• Mögliche Ursache: Die Funktion Duplicate transaction check gilt nur für Dokumente im EDI-Format. Sie filtert keine Duplikate für EDIXml- oder XCBL-Austauschformate.
• Lösung: Falls Duplikatfilterung für EDIXml- oder XCBL-Workflows erforderlich ist, implementiere Deduplizierungslogik in der Studio-Operation, die die eingehenden Dokumente verarbeitet (zum Beispiel durch Abgleich einer Transaktions-ID mit einem Datenbank- oder Cloud-Datastore-Datensatz vor der Verarbeitung).

VAN-Konnektivitätsprobleme

• Symptom: EDI-Dokumente werden über ein Value Added Network (VAN) nicht zugestellt oder empfangen.
• Mögliche Ursache: Eine VAN-Verbindung ist eine verwaltete Verbindung, die Jitterbit einrichtet; du kannst sie nicht selbst erstellen oder konfigurieren. Zustellfehler betreffen typischerweise die VAN-Verbindung, das Mailbox-Routing oder die Handelspartner-Konfiguration auf der Seite des Anbieters, nicht eine Self-Service-Einstellung in Jitterbit EDI.
• Lösung:
  • Bestätige, dass die richtige VAN-Verbindung dem betroffenen Handelspartner zugewiesen ist.
  • Da die VAN-Verbindung nicht direkt aus Jitterbit EDI konfiguriert werden kann, wende dich an 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 (zum Beispiel 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 (zum Beispiel unter *.transactionapi.eicloudservice.com), um Daten abzurufen. Wird dieser blockiert, schlägt die Aktivität fehl. Cloud-Agenten sind nicht betroffen.
• Lösung:
  1. Whitelist eicloudservice.com und seine Subdomains für den ausgehenden Zugriff in Firewall und Proxy des privaten Agents. Informationen zu den anderen 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, bestätige, dass dieser 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 mit folgendem Fehler fehl:

  Error opening connection. Exception is: Error code: INVALID_TOKEN
  

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

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

Dokument-Verarbeitungsfehler

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, sodass der Handelspartner das Dokument ablehnt.
  • 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 in der Fehlermeldung 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 von dem Handelspartner gesendetes eingehendes Dokument teilen Sie den Validierungsfehler mit diesem, damit dieser das ausgehende Format korrigieren kann.

EDI-Zuordnung oder Schemafehler

• Symptom: EDI-Dokumente werden mit falschen Inhalten, fehlenden Feldern oder einer unerwarteten Struktur erzeugt, oder eingehende Dokumente verarbeiten nicht korrekt.
• Mögliche Ursachen:
  • Die EDI-Zuordnung oder das Schema ist veraltet und entspricht nicht dem aktuellen Implementierungsleitfaden oder den Anforderungen des Handelspartners.
  • Quelldatenfelder sind falsch zugeordnet, was zu falschen Werten im Ausgabedokument führt.
  • Datentypunterschiede, 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 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önnen, und fügen Sie bei Bedarf Datenbereinigungs-Schritte hinzu.
  4. Testen Sie mit einem repräsentativen Beispieldokument und verwenden Sie das Archiv, um die erzeugte Ausgabe mit der erwarteten Struktur zu vergleichen.

Transformationsfehler: Nicht erkanntes Feld in EDI for Cloud v2 Activity

• Symptom: Eine Transformation mit einer EDI for Cloud v2 Activity (z. B. List Transactions) schlägt fehl mit einem JSON-Parsing-Fehler, 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, sodass der Connector die Antwort nicht parsen kann.

• Lösung: Aktualisieren Sie den EDI for Cloud v2 Connector auf dem Agent auf die neueste Version, gemäß Connector-Verfügbarkeit bestätigen und aktuell halten im Connector-Troubleshooting-Leitfaden. Ein Klick auf Test Connection auf der Seite EDI for Cloud v2-Verbindung lädt die neueste Connector-Version auf den Agent herunter. Wenn die Organisationsrichtlinie Disable Auto Connector Update 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 ordnen nur die letzte Iteration zu

• Symptom: Bei 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 zugeordnet (frühere Iterationen werden verworfen), da die Kardinalität des Knotens im Aktivitätsschema des Connectors eine Einzelvorkommen ist (z. B. (0,1)) statt wiederholte ((1,many)). Dies betrifft sowohl X12 (z. B. ein in einer LX-Schleife verschachteltes N9-Segment in einem 945) als auch EDIFACT (z. B. eine wiederholte CNI-Gruppe in einem 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-Transactions-Speicher enthält alle Iterationen, und ein manuell aus diesem Raw-XML erstelltes Schema ordnet sie korrekt zu. Dies bestätigt das Connector-Antwortschemata (nicht die Daten) als Ursache.
• 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. Falls die Kardinalität nach der Aktualisierung immer noch falsch ist, exportieren Sie das Schema, aktualisieren Sie manuell das maxOccurs-Attribut für das betroffene Segment in einem externen XML-Editor und importieren Sie es als benutzerdefiniertes XSD erneut.

Hinzufügen von verschachtelten hierarchischen Loop-Ebenen (HL) zu einer EDI-Transformation

• Symptom: Beim Erstellen einer Studio-Transformation für einen EDI-Transaktionssatz, der hierarchische Schleifen verwendet (z. B. X12 870 4010VICS, das ähnlich wie der 856 strukturiert ist), zeigt das Schema 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. Das Schema des Connectors stellt daher eine einzelne HL-Ebene bereit, die Sie in der Transformation replizieren, um die zusätzlichen Ebenen zu erstellen, die Ihr Dokument erfordert.
• 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 aus, 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 in der Ausgabe nur unter bestimmten Umständen erstellt werden soll.

Handelspartnerkonfiguration

Falsche Handelspartner-Identifikatoren

• Symptom: Dokumente werden falsch weitergeleitet, auf Umschlagebene abgelehnt oder nicht vom Handelspartner erkannt.
• Mögliche Ursachen:
  • Die EDI-ID des Absenders oder Empfängers, der Qualifier-Code oder andere Identifikatoren auf Umschlagebene entsprechen nicht dem, was der Handelspartner erwartet.
  • Die Konfiguration des Handelspartners wurde vor Kurzem aktualisiert, die Änderung wurde aber in Jitterbit EDI nicht übernommen.
• Lösung:
  1. Überprüfen Sie die Konfiguration des Handelspartners und bestätigen Sie, dass die EDI-ID und die Qualifier-Codes den Werten entsprechen, die in der Konfigurationsdokumentation des Handelspartners angegeben sind.
  2. Vergleichen Sie die Umschlagidentifikatoren in einem abgelehnten Dokument (sichtbar im Archiv) mit den erwarteten Werten.
  3. Aktualisieren Sie die Handelspartner-Einstellungen, falls Identifikatoren falsch sind, und verarbeiten oder versenden Sie die betroffenen Dokumente erneut.

EDI ID-Override-Werte werden nicht auf ausgehende Transaktionen angewendet

• Symptom: Ausgehende Transaktionen verwenden die Standard-Sender- oder Empfänger-EDI-IDs aus der Trading-Partner-Konfiguration anstelle der bevorzugten Override-IDs, die in den EDI ID-Einstellungen konfiguriert sind.
• Mögliche Ursache: EDI ID-Overrides werden nicht automatisch angewendet. Die bevorzugten IDs müssen explizit in der Request-Transformation der Studio-Operation zugeordnet werden, die das ausgehende Dokument mithilfe des EDI for Cloud v2-Connectors sendet.
• Lösung: Ordnen Sie in dieser Request-Transformation Werte diesen Feldern zu, um die bevorzugten IDs anzuwenden (auf der Seite EDI ID-Einstellungen finden Sie die genauen zu verwendenden Werte):
  • ISA05_ID_Qualifier: Sender-ID-Qualifier
  • ISA06_Sender_ID: Sender-EDI-ID
  • ISA07_ID_Qualifier: Empfänger-ID-Qualifier
  • ISA08_Receiver_ID: Empfänger-EDI-ID

Bestätigungen nicht konfiguriert oder nicht empfangen

• Symptom: Erwartete funktionale Bestätigungen des Typs 997 (X12) oder CONTRL (EDIFACT) 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 Trading Partners deaktiviert.
  • Der Bestätigungsdokumenttyp ist nicht in der Workflow-Konfiguration des Trading Partners enthalten.
  • Der Trading Partner sendet keine Bestätigungen, oder seine Bestätigungen werden falsch weitergeleitet.
• Lösung:
  • Überprüfen Sie in den EDI-Einstellungen des Trading Partners, dass die Bestätigungsgenerierung und -verarbeitung für die relevanten Dokumenttypen aktiviert sind.
  • Überprüfen Sie die Workflow-Verwaltung, um sicherzustellen, dass der Bestätigungsdokumenttyp im Workflow enthalten ist.
  • Prüfen Sie das Archiv, um festzustellen, ob Bestätigungen vom Trading Partner empfangen werden, aber nicht verarbeitet werden, oder überhaupt nicht eintreffen.
  • Falls Bestätigungen nicht eintreffen, stimmen Sie sich mit dem Trading Partner ab, um zu bestätigen, dass diese zum richtigen Endpunkt gesendet werden.

FTP "Nächste Ausführung" aktualisiert sich nicht ohne Seite zu aktualisieren

• Symptom: Das Feld Nächste Ausführung, das in den Einstellungen einer FTP-Verbindung angezeigt wird, bleibt veraltet, nachdem der geplante FTP-Job ausgeführt wurde, obwohl der Zeitplan korrekt funktioniert.
• Mögliche Ursache: Dieses Feld zeigt den Status des Zeitplans nur an, wenn die Seite geladen wird oder eine manuelle Aktion ein Neuaufladen der Daten auslöst. Es fragt die Engine nicht in Echtzeit ab.
• Lösung:
  • Laden Sie die Browserseite neu, um die Anzeige der Nächsten Ausführung zu aktualisieren.
  • Alternativ können Sie weg von den FTP-Einstellungen navigieren und dann zurücknavigieren, um ein Neuaufladen zu erzwingen.

EDI ID oder bevorzugte ID hinzufügen schlägt fehl: ID wird bereits verwendet

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

  Cannot add EDI ID [ID] as it is currently in use; please confirm and provide a unique ID.
  

  Cannot add Preferred ID [ID] as it is currently in use; please confirm and provide a unique ID.
  

• Mögliche Ursachen:

  • Jede EDI ID muss eindeutig in allen Harmony-Umgebungen sein, in denen Jitterbit EDI aktiviert ist. Wenn die gleiche ID bereits einem Trading Partner in einer anderen Umgebung zugewiesen ist, schlägt das Hinzufügen fehl.
  • Eine bevorzugte ID muss innerhalb der Umgebung eindeutig sein. Sie wird abgelehnt, wenn sie bereits dem gleichen Trading Partner oder einem anderen Trading Partner in der gleichen Umgebung zugewiesen ist.

• Lösung:

  • Bei einer doppelten EDI-ID solltest du alle anderen Harmony-Umgebungen überprüfen, in denen EDI aktiviert ist, um zu bestätigen, ob die ID bereits dort zugewiesen ist. Arbeite mit deinem Handelspartner zusammen, um eine eindeutige EDI-ID für jede Umgebung festzulegen, in der ihr Dokumente austauscht, und verwende eine unterschiedliche ID für Nicht-Produktionsumgebungen, die sich von deiner Produktions-EDI-ID unterscheidet.
  • Bei einer doppelten Preferred ID überprüfst du die Liste Preferred ID (ISA ID's) für den aktuellen Handelspartner und für andere Handelspartner in derselben Umgebung, dann wählst du eine eindeutige ID.

Workflow-Konfiguration

Ausgehende Dokumente bestehen die lokale Validierung, scheitern aber bei Tests durch Handelspartner

• Symptom: Ausgehende EDI-Dokumente bestehen die lokale Validierungsprüfung in Jitterbit EDI, werden aber während Tests oder Zertifizierung durch den Handelspartner abgelehnt, oft mit Fehlern bezüglich fehlender oder nicht konformer Elemente.
• Mögliche Ursachen:
  • Die ausgehende Validierung ist in der Workflow-Konfiguration deaktiviert. Jitterbit EDI ermöglicht es, Dokumente ohne Validierung zu generieren, aber ohne diese können Dokumenten Elemente fehlen, die der Implementierungsleitfaden des Handelspartners verlangt.
  • Die EDI-Einstellungen decken die wesentlichen Elemente des Standards ab, aber der Implementierungsleitfaden des Handelspartners kann zusätzliche Pflichtelemente verlangen, die durch Standard-Einstellungen nicht erzwungen werden.
• Lösung:
  • Aktiviere in der Konfiguration Workflows verwalten die Validierung für den ausgehenden Workflow.
  • Überprüfe den Implementierungsleitfaden des Handelspartners auf Pflichtelemente, die über die Standard-EDI-Einstellungen hinausgehen, und füge sie dem Mapping hinzu.
  • Aktiviere immer die Validierung vor Tests mit einem Handelspartner, sofern du nicht ein gründliches Verständnis der spezifischen EDI-Transaktion und der Anforderungen des Handelspartners hast.

Archiv und Transaktionen

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

• Symptom: Eine Transaktion wird vor Ablauf der erwarteten Aufbewahrungsfrist archiviert, oder sie bleibt länger verfügbar als erwartet.
• 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üfe bei der Untersuchung unerwarteter Archivierungszeitpunkte sowohl das Transaktionsdatum als auch das Dokumentdatum für die betroffene Transaktion.
  • Überprüfe die Aufbewahrungsfristen-Einstellungen, um die konfigurierte Anzahl der Tage zu bestätigen (30, 60 oder 90).

Berechtigungen und Zugriff

Kein Zugriff auf EDI-Funktionen möglich

• Symptom: Ein Benutzer kann EDI-Seiten nicht anzeigen oder damit interagieren, oder bestimmte EDI-Aktionen sind nicht verfügbar.
• Mögliche Ursachen:
  • Für den EDI-Zugriff sind sowohl eine EDI-spezifische Rollenberechtigung (Admin, EDI User oder EDI Viewer) als auch eine Umgebungszugriffrolle auf Write-Ebene erforderlich. Das Fehlen einer der beiden Berechtigungen verhindert den Zugriff.
  • Die Rollen EDI User und EDI Viewer unterscheiden sich in ihren Funktionen. EDI Viewer kann Transaktionen erneut verarbeiten, Bestätigungen erneut senden und Seiten lesen, kann aber keine Konfigurationen erstellen oder aktualisieren und keine Dateien hochladen. Das Erstellen oder Aktualisieren von Konfigurationen und das Hochladen von Dateien zur Verarbeitung erfordern die Rolle EDI User. Verwaltungsaktionen wie das Archivieren von Transaktionen, Aktivieren von PII und Ändern von Löscheinstellungen erfordern die Rolle Admin.
• Lösung:
  • Überprüfe in der Management Console, dass der Benutzer eine Rolle hat, die die Berechtigung Admin, EDI User oder EDI Viewer umfasst.
  • Bestätige, dass die Umgebungszugriffsstufe des Benutzers Write-Zugriff für die Umgebung umfasst, in der EDI konfiguriert ist.
  • Wenn der Benutzer Schreibvorgänge ausführen muss (z. B. Handelspartner erstellen oder Dokumente hochladen), weise die Rolle EDI User statt EDI Viewer zu. Weitere Informationen findest du unter EDI-Berechtigungen in der vollständigen Berechtigungsmatrix.

PII-Einstellungen können nicht aktiviert werden

• Symptom: Die Option zum Aktivieren von PII-Einstellungen (personenbezogene Daten) 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 können 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.