Question

Sorry, this entry is only available in Deutsch.

EDI auf Diät

Weniger Volumen an die richtigen Stellen!

Mit der Artikelverwaltung (aka SupplierArticlePool) ihres EDI-Konverters eBiss bieten wir ein erprobtes Modul an, mit dem Lieferanten ihre Kosten senken können. Damit werden EDIFACT-Pricat Nachrichten adressatengerecht individualisiert, auf qualitativ hohem Niveau angeboten, und im Volumen minimiert.

Optimiert

Von allen EDIFACT-Nachrichten eines Lieferanten an seine Händler verursacht der Preiskatalog die höchsten Übertragungskosten, vergrößert doch jeder Artikeln darin, womöglich mehrsprachig bezeichnet, samt Preisen, EAN und anderen Artikelinformationen das Datenvolumen einer PRICAT-Nachricht. Bei allen Änderungen wie Sortimentsänderungen, Saisonzeiträumen oder Preisanpassungen für einzelne Händler ist aber nicht mehr die Übermittlung des kompletten PRICAT nötig, sondern die gezielte Auswahl relevanter Informationen der bessere Weg. Nutzer des EDI-Konverters eBiss können sich von dessen SupplierArticlePool-Modul einen individualisierten PRICAT maßschneidern lassen.

Selektiv

In der Artikelverwaltung werden gezielt Informationen für den jeweiligen Kunden selektiert. Die sogenannten begleitenden PRICATs haben ein deutlich reduziertes Datenvolumen im Vergleich zum üblichen kompletten PRICAT und können durch jede Bewegungsnachricht (wie Orderbestätigung ORDRSP oder Lieferavis DESADV) automatisch von eBiss erzeugt und versendet werden.

Sicher

Die Artikelverwaltung erhöht zudem die Qualität der übertragenen Daten, etwa durch Überprüfung von EDI-Pflichtfeldern wie der EAN/GLN. Das Lieferanten-ERP dient als Quelle für den Stammdaten-Import, bleibt aber in seiner Logik unangetastet. Der SupplierArticlePool kann nahtlos – und bei laufendem Betrieb – in die bestehende eBiss-Installation integriert werden.

Das Konzept

1
2
3
4
Artikel Verwaltung Konzept
1

eBiss ohne integrierte Artikelverwaltung.

Full Pricats aus Ihrem WWS an alle Ihre Kunden ohne Ausnahmen.

2

eBiss mit integrierter Artikelverwaltung.

Bedarfsgerechter, kundenspezifisch- selektiver Versand von begleitenden Pricats bei veränderten Stammdaten.

3

Individuelle Artikelabonnemente pro Handelspartner.

4

Begleitende PRICATs passend zur Hautnachricht.

Download “(Deutsch) SupplierArticlePool Flyer DE” Pranke_eBiss_SupplierArticlePool_Flyer_DE.pdf – 385.17 KB

Diese Produkte könnten Sie auch interessieren

The WWS profile, the common EDI profile of Pranke’s partners – both Retail Management Systems and ERP Systems, is available for download in both English and German.

The changes compared to Version 2.2, which has been used since 2008, are minimal: In addition to the well-known “day-specific ” sales report, a documentation for the receipt-specific variant has been added. Furthermore, the inventory stock report has been adjusted to reflect the best-pracice approach for stock amount qualifierts (QTY segment)

Go to the updated WWS profile

All changes can be found in the Release Notes document (Chapter IV, Appendix).

About the WWS profile:

Beginning with version 2.0 of the WWS EDI profile, several hundred actual and several thousands of potential installations can be reached, both on retail and supplier side. By this it has an equal importance as the profiles of the big cooperations or retail chains.

This profile can be used free of charge by enterprises in retail and production industry. The detailed conditions can be found in the Copyright / Contact document (Chapter IV, Appendix).

The use of the profile is open to new partners at any time.

Question

The technical implementation of partner or concept specific processes and data formats finally allows a “targeted” communication always geared towards the receiving end. This principle also works the other way around in the direction of your systems that accurately obtain the data that are important and necessary for the process, regardless of potentially inconsistent source formats.

Since eBiss can be fully integrated into your systems, even non-EDI employees without technical knowledge can directly see whether messages or errors are present. They can additionally control whether, for example, a complete accounting process has started for a particular trading partner.

Question

Naturally, eBiss covers all formats: Preconfigured interfaces for all versions of EDIFACT, for example D.96A or D.01B.

Furthermore, eBiss as a professional EDI software comes with support for ANSI X.12, XML formats, iDOC, JSON, TRADACOMS and of course any text and CSV formats. All data interfaces of our software partners are preconfigured and can be made available within minutes. With the addition of the EXCEL-Importer module, eBiss can also read Excel files.

All data formats which have not yet been developed as eBiss interface (inhouse or partner-specific) can be created by any developer.

Question

The challange of every EDI converter: The world of EDI and business process integration is full of standards, profiles and formats. Nevertheless – or perhaps because of it – in reality each partner can have different requirements. As a consequence, data structures – and thus the actual business processes! – can either not be mapped at all, or one needs complex special configurations, that no one understands later on.

one needs complex special configurations, that noone understands later on.

The EDI converter eBiss simply flips the conventional way of thinking: Instead of stating “My EDI converter can only output/read xyz“, eBiss asks “What is to come out towards the internal system or what is received/sent by the partner?”

Question

The description of the functions in eGate can be found in eGate in the menu Information/User Information or can be opened here as PDF:

eGate Anwenderinformationen

Please note the following when sending messages via eGate.

server: egate.pranke.com

  • Encrypted transmission:
    • Send via TLS (SMTP): Port 25 or Port 8025
    • Receive via TLS (POP3): Port 995
  • Unencrypted transmission:
    • Send (SMTP): Port 25 or Port 8025
    • Receive (POP3): Port 110 or Port 8110

If you want to make sure that the communication with eGate works over the selected ports, please proceed as follows:

  • By establishing a Telnet connection (via a terminal cmd.exe) you can determine whether the eGate service is accessible from the internal network.
  • telnet request via port 25 (SMTP)
    • Request: telnet egate.pranke.com 25
    • Response: 220 egate4 ESMTP-Server
    • The connection could be successfully established via the above port (25) if the server returns the response listed above.
  • Alternative telnet request via port 110 (POP)
    • Request: telnet egate.pranke.com 110
    • Response: +OK eGate-POP Server (IV) at egate.pranke.com READY
    • The connection could be successfully established via the above port (110) if the server returns the response listed above.
  • If you receive a negative response, please check the rules in your firewall.
Pranke Elektronische Rechnung

Sorry, this entry is only available in Deutsch.

Ein “einheitliches Rechnungsdatenformat für den elektronischen Rechnungsaustausch”, das in einer PDF/A3-Datei eingebettet die menschenlesbare Rechnung und den dazugehörigen maschinen-lesbaren Datensatz vereint. Das jedoch setzt voraus, dass der Rechnungssender ZUGFeRD-PDFs erstellen kann bzw. der Empfänger diese verarbeiten kann. Es ist gedacht für alle Anwendungsbereiche oder Branchen, in denen EDI nicht etabliert ist, z.B. Verwaltung oder Kleinstbetriebe.

In der Konsumgüter-Branche ist der Standard für den Austausch von strukturierten = maschinen-lesbaren Daten ist seit langem schon EDIFACT, das quasi von jedem “EDI-fähigen” Handelspartner gesendet bzw. empfangen und verarbeitet werden kann.

Pranke bietet die Technologie, um ZUGFeRD in EDIFACT zu konvertieren und/oder umgekehrt aus EDIFACT-Daten das ZUGFeRD-Format zu erstellen, um alle Handelspartner zu bedienen. So ergänzt ZUGFeRD den bewährten EDI-Austausch für die Elektronische Rechnung.

 

Read more

Pranke Elektronische Rechnung

Sorry, this entry is only available in Deutsch.

Auf der Basis von EDI

In einem Umfeld, in dem per EDI schon Stammdaten, Lieferscheine und Bestellungen ausgetauscht werden, liegt er nahe: der papierlose Versand bzw. Empfang von Rechnungen per EDI. Eine (zusätzliche) PDF-Version dieser Rechnung dient nicht Versand oder Austausch, sondern einzig dazu, die Rechnungsdaten für die Archivierung bzw. Prüfung menschenlesbar zu machen.

Aufbereitung & Validierung während des Versands

Über die eGate-Server läuft aller EDI-Datenverkehr der Pranke-Kunden: Hierüber gehen INVOIC-Nachrichten vom Sender zum Empfänger. Weiterhin werden diese INVOIC-Nachrichten nach Versand bzw. vor Empfang zunächst auf Vollständigkeit validiert und dann als „menschenlesbares“, langzeitarchivierbares PDF aufbereitet – inklusive der darin eingebetteten EDIFACT-Originaldatei.

Die Details zur Technik

  • Ein ZUGFeRD-PDF/A3-Container mit Comfort-Profil-Validierung...

    Der erzeugte “Archiv-Container” ist standardmäßig eine PDF/A3-Datei. Diese enthält eingebettet das EDIFACT-INVOIC-Original und weiterhin die Index-Informationen nach dem ZUGFeRD-XML-Datenmodell. PDF/A3 ist der PDF-Standard für die Langzeit-Archivierung (ausführliche Beschreibung bei Wikipedia in neuem Fenster öffnen) und technisch so konzipiert, dass nicht nur Dateien, sondern auch z.B. Schriftarten eingebettet werden. Weiterhin ist ein solches PDF nach der Erstellung standardmäßig schreibgeschützt. All diese Maßnahmen gewährleisten, dass der PDF-Inhalt auch in zehn Jahren wie am ersten Tag aussieht und nicht verändert werden konnte. Die ZUGFeRD-Informationen stellen dabei Index und Nutzdaten zugleich für das archivierende Dokumenten-Management-System dar, welches somit jede Information aus der Rechnung verwenden kann. Damit das Archivsystem nur gültige Rechnungen erhält, wird jedes Dokument bei Pranke gegen die Regeln des ZUGFeRD-Comfort-Profil validiert. Bei unvollständigen Rechnungen wird der Service-Nutzer benachrichtigt, um je nach Fall die Rechnung neu anzufordern bzw. korrigiert zu versenden. Mit jedem gängigen, aktuellen Dokumenten-Management-System (offline oder in der Cloud) erfüllt der Service-Nutzer somit ohne weitere Konfiguration die steuerrechtliche Anforderung, sowohl das Rechnungsoriginal (INVOIC) sowie die dazugehörige menschenlesbare Version revisionssicher zu archivieren.

  • Pflichtangaben-Prüfung nach § 14 Abs. 4 UStG

    Jegliche gültige Rechnung – ob Papier oder elektronisch – muss Pflichtangaben enthalten. Vor der Aufbereitung der Archiv-PDF/A3-Daten werden diese Angaben geprüft. Sollten Angaben fehlen und die Rechnung damit nicht zum Vorsteuerabzug berechtigen, wird diese daher angehalten und der Service-Nutzer per Mail benachrichtigt

  • Fehlerfall und Benachrichtung

    Zusammengefasst: Schlägt die ZUGFeRD-Comfort-Validierung fehl oder fehlen UStG-Pflichtangaben in der INVOIC, wird daraus kein Archiv-Paket erstellt. Der Service-Nutzer erhält eine detaillierte Fehlermeldung mit Angaben zum Dokument und zum Fehler selbst, um daraufhin Kontakt mit dem Handelspartner aufzunehmen. Die INVOIC innerhalb des gewohnten EDI-Nachrichtenstroms an den Empfänger bleibt unbeeinflusst, da diese vor der obigen Validierung & Prüfung abgezweigt wird: Dies entspricht übrigens dem Vorgehen wie beim “Papieroriginal mit INVOIC”, wenn z.B. im Gegensatz zu den EDI-Daten der Brief nicht ankam, oder wenn eine neue Rechnung nach einer manuellen Prüfung nötig wäre.

  • Entworfen für beide Rechnungs-Beteiligten

    Eine Umstellung weg von Papier auf eine elektronische Rechnungsabwicklung ist nur sinnvoll und rechtlich einwandfrei, wenn beide Seiten das jetzt zum Original erhobene EDIFACT-Dokument archivieren. Hat ein Handelspartner des Service-Nutzers selbst noch nicht die Möglichkeit, das EDI-Rechnungsoriginal direkt zu archivieren (oder müsste hierfür erst interne Entwicklung betrieben werden), können die “Archiv-Container” = PDF/A3-DAteien auch jener Gegenseite zugestellt werden. Archiviert die jeweilige Gegenseite bereits selbst und bestätigt das idealerweise schriftlich, muss dort nichts weiter unternommen werden. Der Gegenüber sendet/empfängt wie (bisher) gewohnt die INVOIC-Nachrichten.

  • Versand über den bekannten SMTP-Kanal

    Rechnungssender und -empfänger müssen keinen separaten Übertragungsweg wie z.B. FTP einrichten, um überhaupt INVOIC-Nachrichten verschicken zu können. Die Rechnung wird als EDIFACT-INVOIC wie gewohnt nur einmal über den etablierten EDI-Weg versandt, zusätzlich zu PRICAT, DESADV etc… Rechnungssteller, die den Service nutzen, müssen somit keine neuen Workflows oder Abzweige z.B. im ERP-System oder im Konverter einrichten.

  • Bereitstellung in zweitem eGate-Mailkonto für POP3-Abholung

    Zusätzlich zum für EDI-Nachrichten genutzten eGate-Account (z.B. 2800001946@egate.pranke.com) erhält jeder Service-Nutzer eine zweite Adresse in Form eines Unter-Accounts (z.B. 2800001946.111@egate.pranke.com). An jene Adresse werden die Archiv-Container = PDF/A3-Dateien gesendet. Egal ob auf Sender- und/oder Empfängerseite: Das Archivsystem ruft diese Adresse des Unter-Accounts regelmäßig über einen normalen POP3-Zugriff ab und erhält so unkompliziert die Daten. Es muss kein FTP-Empfang z.B. auf der Firewall konfiguriert werden. Die normalen EDI-Nachrichten inklusive der INVOIC werden weiterhin über die Haupt-Accounts des Senders an den Empfänger zugestellt, parallel zu PRICAT, DESADV usw.

  • Abrechnung gewohnt volumenbasiert

    Das Gesamtvolumen für die Abrechnung ergibt sich beim Service-Nutzer aus bestehendem Haupt-Account (EDI-Nachrichten) und Archiv-Unteraccount (Archiv-Pakete). Alle Details zu Preisen inklusive Rechenbeispielen finden Sie unter der Frage “Was kostet die Elektronische Rechnung?

Pranke Elektronische Rechnung

Sorry, this entry is only available in Deutsch.

Fallstudien im Modehandel

Die vermeintlich Kleinsten zeigen eindrucksvoll, mit welchen durchaus unterschiedlichen Zielen die Elektronische Rechnung eingeführt wurde und wie es sich gelohnt hat:

Pranke Elektronische Rechnung