Beiträge

In letzter Zeit kommt es leider immer wieder vor, dass Plugins, sonstige Anpassungen und/oder Erweiterungen unserer Software von externen Dienstleistern vorgenommen werden. Diese Unternehmen kommen nicht von PRANKE®. Ihr Vorgehen ist mit uns nicht abgestimmt und dadurch entstehen Komplikationen.

Neben den rechtlichen Unsicherheiten, ob durch solche Leistungen und Eingriffe gegen unsere Rechte als Urheber verstoßen wird, z.B. weil damit eine unzulässige Bearbeitung unserer Software verbunden ist, entstehen hierdurch vor allem immer wieder technische Probleme.

Das reibungslose Funktionieren von Konfigurationsänderungen und Erweiterungen, die über eine API mit unserer Software verbunden werden und mit dieser kommunizieren, setzt die Kenntnis des aktuellen Pranke Quellcodes der Anwendungen voraus. Über dieses Wissen verfügen jedoch nur wir selbst und die autorisierten Softwarepartner.
Bei Änderungen an der PRANKE® Software, z.B. im Zuge von Updates, kann es ferner dazu kommen, dass angebundene Entwicklungsleistungen von Dritten in der Peripherie zu unserer Software nicht mehr kompatibel und lauffähig sind. Insbesondere Erweiterungen, die nicht die dokumentierte PRANKE®.eBiss API verwenden oder die nicht mit dem TypeEditor erstellt wurden, sehen wir kritisch.
Pranke kann an dieser Stelle keine Verantwortung für die korrekte Funktionsweise übernehmen. Wir haben keinen Einfluss auf etwaige Schwachstellen und Sicherheitsrisiken, die durch das beschriebene Vorgehen ggf. entstehen können.
Wir möchten Ihnen daher dringend empfehlen, bei der Inanspruchnahme von Leistungen durch Dritte vorsichtig zu sein und sich bei Zweifeln an uns zu halten.
Gerne überprüfen wir mit Ihnen Ihr System und beratschlagen das weitere Vorgehen.

Bebilderung GTS

Kürzlich demonstrierten über sechzig namhafte Textilhersteller ihr Interesse am neuen Global Textile Scheme (GTS), das seit knapp einem Jahr von einer Gruppe von ERP-Systemherstellern, Verbandsfachleuten und Markenherstellern entwickelt wird. In einem gut einstündigen Webinar klärten Mitglieder der GTS-Initiative über die Standardisierung von Produktdatenübermittlung in verschiedenen Anwendungsfällen auf. Ziel ist es, den automatisierten Datenaustausch mittels einer standardisierten Sprache entlang der gesamten textilen Lieferkette zu etablieren.

Während der elektronische Datenaustausch (EDI) seit bald vierzig Jahren Händlern und Lieferanten durch Vereinheitlichung der Informationen und Automatisierung des Geschäftspapierversands viel Zeit und Geld spart, waren die vorgelagerten Abschnitte der Lieferkette bislang von diesen Segnungen völlig ausgenommen. Zu vielfältig und individuell definiert erschienen die feinen Unterschiede in Materialien wie Stoffen, Garn, Knöpfen und Schnallen. Dabei liegt gerade in dieser Vielfalt enormes Effizienz-Potential. Je größer der manuelle Aufwand für eine exakte Beschreibung, desto größer die Fehleranfälligkeit, die in schlimmster Konsequenz dazu führt, dass der Konsument das fragliche Produkt nicht findet.

Hohe Datenqualität entlang der gesamten textilen Kette

GTS führt nun vor, dass es geht. Mit jahrzehntelanger Expertise in der Textilbranche und entsprechender Vernetzung im Rücken entwickelte der Initiator Andreas Schneider gemeinsam mit vorausschauenden Textilherstellern, Fashion Brands und wesentlichen IT-Herstellern die GTS Language. Dieser kodierte Katalog erlaubt den Nutzern die Kommunikation in ihrer jeweiligen Muttersprache. Um diesen Katalog zu digitalisieren und damit die Voraussetzung für die Automatisierung zu schaffen, bat Schneider die Pranke GmbH um den Aufbau einer technischen Infrastruktur. Pranke ist seit Jahrzehnten als EDI-Experte in der Branche etabliert. Binnen weniger Monate entstand eine hoch performante Plattform.

Lieferanten können dort den Bedarf an ihren Produkten sozusagen live verfolgen, besser planen und näher am Bedarf produzieren. Der Kunde erspart sich Mindermengenzuschläge und Lieferzeit. Er profitiert von einer ungekannten Datenqualität, weil er alle produktbeschreibenden Stammdaten in sein System einlesen kann – wenn denn sein Lieferant an GTS angeschlossen ist.

Damit konnten Schneider und seine Mitstreiter den Webinarteilnehmern nicht nur demonstrieren, dass GTS der Vorstufe der textilen Lieferkette nach Einbindung in die vorhandenen EDI-Prozesse den sicheren, schnellen, korrekten und kostensparenden Baustein liefert, um die Kette von Anfang bis Ende zu digitalisieren und zu automatisieren. Vielmehr bietet GTS damit schon jetzt die Möglichkeit zur Dokumentation verwendeter Materialien, wie sie von der Politik mit Blick auf die Nachhaltigkeit und den ethischen Ressourceneinsatz immer lauter gefordert und absehbar per Gesetz unumgänglich gemacht werden wird.

Derweil legen die Schöpfer des GTS ihre Hände nicht in den Schoß. Andreas Schneider und die anderen Veranstalter des Webinars, die Intex EDV-Software GmbH, Impuls AG, Pohl Softwear GmbH und textdata software gmbh, laden interessierte Unternehmen ein, sich in der Initiative einzubringen und an der weiteren Entwicklung mitzuwirken.

Erleben Sie das Webinar Webinar „GTS“ auf You Tube
und lesen Sie die Peter Büdel USER STORY von übererfüllten Erwartungen im GTS-eBiss-Projekt.

FAQs

Question

eGate ist generell als Closed-Community Netzwerk zu betrachten. Deshalb wollen wir beim Abholen von Nachrichten mit einem SMTP Channel in eBiss die Absendererkennung verpflichtend verwenden. Das bedeutet, dass alle möglichen Absender-eGate-Emailadressen meiner Handelspartner in meinem eBiss System bekannt sein müssen. Das gilt auch für (Dritt-)Povider, welche im Auftrag Ihrer Kunden EDI Nachrichten weiterleiten. Falls also ein eGate Teilnehmer in der Teilnehmersuche nicht nur mit einem CUSTOMER.INI File sondern auch mit einem SENDER .INI FILE angeboten wird muss ich sicherzustellen, dass der eGate Teilnehmer des Providers (bzw. SENDER) als Tradingpartner in meinem eBiss existiert. Falls nicht, dann brauche ich das SENDER .INI File importieren.

Beispiel eines eGate Teilnehmers mit Provider Zugehörigkeit:

Name Tnr GLN/UNB-ID Customer .ini File Sender .ini File
Muster GmbH, München (DE) 1234567890 1234567890123 Download Provider

Falls also Nachrichten in Ihrer INBOX unverarbeitet und mit unbekanntem Partner liegen bleiben, dann kann es genau daran liegen das die Validierung im Empfangskanal nicht erfolgreich war.

Question
  1. Verfügen Sie über ein eGate Kunden Konto? Wenn ja prüfen Sie die Zugangsinformationen per Anmeldung an egate.pranke.com.
  2. Ist Ihr Konto noch gültig oder wurde es ggfs. gekündigt? Im Zweifelsfall fragen sie den Kundensupport.
  3. Falls sie seit langer Zeit keine Nachrichten mehr abgeholt haben kann es sein, dass diverse alte Nachrichten schon in die Archivierung geraten sind. D.h. Nachrichten können nicht mehr abgerufen werden. Loggen Sie sich in ihr eGate Konto ein und identifizieren sie die archivierten Nachrichten(erkennbar an den ausgegrauten Nachrichten IDs) und löschen diese erst aus der Inbox. Danach soll das Abholen per Kommunikationskanal wieder funktionieren.
Question

I.d.R. übernimmt der Kontainerisierer die Erzeugung des UNB Segmentes. Wenn das UNB Segment aber in einem Edifact Dokument beeinflusst werden soll, dann muss in dem entsprechenden Mapping das UNB Segment mit einem Regelsatz getriggert und das gewünschte Datenelement mit einer Mapping-Regel bedient werden. Die verbleibenden UNB Datenelemente werden dann noch vom Kontainerisierer erzeugt/bedient.

Achtung

Die Default Einstellung des  Syntax Versionsnummer ist 3. Der EDIFACT Kontainerisierer prüft aber die Syntax Versionsnummer. Ist diese > 3 wird zusätzlich auch das Jahresformat im Datum des UNB Segments angepasst. Außerdem wird im UNA Segment ein * anstatt Leerzeichen gesetzt. In letzter Instanz müssen Sie sicherstellen, dass das ausgehende Edifact Dokument der Syntax Version gem. ISO 9735:1998 entspricht.

Im angefragten Fall brauch es also eine Mapping Regel wie in diesem Snapshot:

UNB Segment im Mapping

UNB Segment im Mapping

 

Situation: Eine gesuchte Nachricht habe ich zwar auf eGate in den „fetched messages“ gesehen, diese Nachricht ist aber nicht in meinem WWS.

Vorgehen / Abhilfe

Bitte sehen Sie in den Messageboxes des Konverters nach, ob auf der Eingangsseite (Messagebox „from Partner“ o.ä.) Nachrichten von unbekannten Partnern zu sehen sind (gelb gefärbt).

Besonders bei neuen Handelspartnern können am Anfang Nachrichten hängen bleiben wegen unterschiedlichster Fehlerquellen.

Eine wichtige Hilfe bei der Fehlereingrenzung ist die Untersuchung eines Tasks bei der hängenden Nachricht. Der Task kann auch den Support unterstützen bei der Fehlerbehebung.

Doppelklicken Sie auf den Anfangsbereich der Zeile mit der gelben Nachricht und öffnen Sie das Register „Tasks“. Die Info -Zeile kann man markieren und mit Copy und Paste in einen beliebigen Text einfügen und versenden

task_auslesen

 

 

Fallstudien

EDI Outsourcing-Dienstleister CPA setzt auf Pranke

Neue Kundenanforderungen erfordern optimierte Lösungen. Daher hat die CPA SoftwareConsult GmbH, der führende ERP-Dienstleister für die Schuhbranche aus Langenfeld, auf den EDI-Konverter eBiss der Karlsruher Pranke GmbH umgesattelt. Nach erfolgreicher Migration steht nun ein modulares und flexibles System zur Verfügung, für das CPA selbst Strukturen programmieren und individuelle Anpassungen vornehmen kann.

Vorteile für CPA und seine Partner

Der EDI-Konverter eBiss wird bei CPA SoftwareConsult für die EDI-Kommunikation der Partner aus der Schuhbranche mit dem CPA-eigenen ERP-System cpa.ShoeFactory eingesetzt. Daneben nutzt auch ein bekannter Werkzeughersteller diese Lösung für die Anbindung an sein SAP®-System.

Die Erfahrung bei CPA zeigt, dass das leistungsstarke eBiss-System zuverlässig eine Nachrichtenanzahl im mittleren fünfstelligen Bereich pro Monat bewältigen kann.

Die modulare Struktur des eBiss-Systems erlaubt eine perfekte Anpassung des Nachrichten-Workflows. Neue Kunden und Lieferanten der Partner von CPA können durch den objektorientierten Konfigurationsansatz deutlich schneller und einfacher an das System angebunden werden als dies im zuvor genutzten System möglich war. Ebenso ist es möglich, neue Nachrichtenformate quasi auf Knopfdruck zu generieren und einzubinden. Dabei ist es unerheblich, ob es sich um bekannte Standardformate, wie beispielsweise EDIFACT oder IDoc, handelt oder um CPA-eigene Strukturen. Darüber hinaus können Mappings besser vereinheitlicht und zusammengefasst werden.

Integration von eBiss als Middleware

Den Transferzustand und den Inhalt ihrer Nachrichten können die CPA-Partner mit dem standardmäßig vorhandenen Web-Frontend auch selbst recherchieren. „Dadurch hat sich der Support-Aufwand bereits deutlich reduziert. Aber auch unsere Partner profitieren, da sie ihre Recherche durchführen können, wann immer sie wollen“ stellt Jörg Spiegelhoff, Geschäftsführer von CPA SoftwareConsult, erfreut fest.

Unter dem Strich werden sich die Vorteile der Migration für CPA und seine Partner sowohl in den Betriebsabläufen als auch in der deutlich schnelleren und kostengünstigeren Einrichtung und Wartung sowie in zukünftigen EDI-Projekten positiv auswirken.

Vorteile im Überblick

  • Neuanbindungen weniger aufwändig
  • Email-Benachrichtigung bei Fehlern
  • Modularer, flexibler Aufbau
  • Einfache Handhabung
  • Stabiles System
  • Schnelle Fehlersuche
  • Optimierte Prozesse
  • Direkte Datenbankanbindung
  • Individuelles Programmieren und Einbinden von Funktionalitäten und Strukturen
  • Web-Frontend für die Partner von CPA

Migrations-Fakten

  • 100 Mappings konvertiert
  • 40 Datenformate/Typenkombinationen erstellt
  • 200 Kunden/Lieferanten angebunden