Was ist EDI? EDI – Elektronischer Datenaustausch

18. September 2015 14:17 Uhr

Karina Kassis, Synerdocs

Schauen Sie sich die Vielfalt an: elektronische Berichterstattung, Handelsplattformen, EDI, elektronische Dokumentenaustauschdienste, Regierungsportale usw. Der Markt bietet Dutzende von EDF-Diensten (Electronic Document Management) an, von denen jeder seine eigene Geschichte und seinen eigenen Zweck hat.

Ausgehend von Zielgruppe, für die dieser oder jener EDI-Dienst entwickelt wird, können sie wie folgt klassifiziert werden:

In Business-to-Business-Geschäftsbeziehungen sind elektronische Dokumentenaustauschdienste, EDI, Remote-Banking-Systeme und Handelsplattformen beliebt. Jede Großunternehmen kann mit all diesen Diensten gleichzeitig verbunden werden. Im Bereich „Business for Government“ entwickeln sich elektronische Melde- und Regierungshandelsplattformen aktiv weiter. Am schnellsten entwickelten sich in letzter Zeit die elektronischen Beziehungen zwischen Staat, Wirtschaft und Bürgern. Fast jeder von uns ist bereits auf dem Behördenportal registriert und tauscht darüber digitale Informationen mit Regulierungsbehörden aus persönliche Konten, veröffentlicht auf den offiziellen Websites der Abteilungen. Der Bundessteuerdienst entwickelt sich in dieser Richtung allen anderen voraus.

Aufgrund der Vielfalt der Dienste werden uns häufig Fragen gestellt, wie sich EDI-Betreiber von EDI-Betreibern in der Nordflotte unterscheiden, ob EDI Austauschdienste ersetzen kann usw. Lassen Sie uns unser Wissen über EDI-Dienste systematisieren und einen genaueren Blick auf die elektronische Berichterstattung werfen. EDI- und elektronische Dokumentenaustauschdienste.

Elektronische Berichterstattung

Elektronische Berichterstattung – die Möglichkeit von Unternehmen, Meldungen über das Internet an Regulierungsbehörden zu senden. In Russland erschien in den 2000er Jahren die elektronische Berichterstattung. Nach 15 Jahren erlangte die Mehrwertsteuer für die meisten Steuerzahler den Status einer Pflichtumsatzsteuer.

Elektronische Berichtsdienste werden von EDI-Betreibern angeboten. Der Dienst wird auf kommerzieller Basis über ein Abonnementgebührenmodell bereitgestellt. Im Durchschnitt kostet die elektronische Berichterstattung 10 bis 12.000 Rubel pro Jahr, ohne den Kauf eines elektronischen Signaturzertifikats. In diesem Fall sollten elektronische Umsatzsteuererklärungen ausschließlich über den Betreiber eingereicht werden (Artikel 174 Absatz 5 der Abgabenordnung der Russischen Föderation). Andere Buchhaltungs- oder Steuerberichte können völlig kostenlos über die Website des Federal Tax Service gesendet werden. Die Steuerbehörde erinnerte in einem Schreiben vom 20. August 2015 N PA-3-17/3169@ daran.

Der Motor des elektronischen Meldewesens ist der Steuerdienst; er war Vorreiter beim Aufbau von Empfangssystemen und der Entwicklung der entsprechenden Software. Heute wird die elektronische Meldung auch von der Pensionskasse, der Sozialversicherungsanstalt, dem Statistischen Bundesamt und anderen Aufsichtsbehörden akzeptiert.

EDI

EDI (Electronic Data Interchange) übersetzt von auf Englisch„Elektronischer Datenaustausch“ ist eine Reihe von Standards für die Übertragung strukturierter digitaler Informationen zwischen Gegenparteien, die auf der Regulierung der Formate der übertragenen Nachrichten basieren. Die ersten EDI-Standards erschienen im Ausland Ende der 80er Jahre des letzten Jahrhunderts. EDI gelangte 2004 zusammen mit dem Lebensmitteleinzelhandel nach Russland.

EDI-Messaging-Dienste werden von EDI-Anbietern auf kommerzieller Basis angeboten. Mit Hilfe von EDI tauschen große Handelsketten große Informationsmengen in strukturierter Form aus. EDI bietet den Austausch von Dokumenten wie einem Produktkatalog, einer Warenbestellung, einer Auftragsbestätigung, einer Versandanzeige, einer Rechnung, einem Abgleichsbericht und anderen. Alle diese Dokumente werden nach bestimmten EDI-Standards formalisiert und erstellt.

Die Kosten für EDI sind ziemlich hoch: von 3 Rubel bis 1 Euro für den Versand eines Dokuments. Der Grund ist einfach: Der EDI-Markt in Russland wurde von ausländischen Anbietern und ihren russischen Partnern gebildet, und die Rolle dieser Unternehmen ist immer noch recht stark.

Elektronischer Dokumentenaustausch

Austauschdienste ermöglichen es Gegenparteien, rechtlich bedeutsame Rechnungen, primäre Buchhaltungsbelege und andere Dokumente über das Internet auszutauschen. Die Entwicklung der Dienste begann im Jahr 2012, als auf gesetzlicher Ebene die Möglichkeit geschaffen wurde, Rechnungen in elektronischer Form auszustellen. Zum Vergleich: Im Westen gibt es ähnliche Dienste bereits seit den 2000er Jahren.

Der Austausch elektronischer Dokumente wird von den EDF-Betreibern der Nordflotte auf kommerzieller Basis angeboten. Die Kosten für den Versand einer Rechnung liegen im Marktdurchschnitt zwischen 5 und 9 Rubel. Gleichzeitig können Sie oft für die Kosten eines Dokuments eine Rechnung und ein Belegdokument – einen Lieferschein oder ein Dokument – versenden. Eingehender Verkehr ist in der Regel kostenlos.

Neben der Verwendung einer erweiterten qualifizierten elektronischen Signatur wird die rechtliche Bedeutung elektronischer Dokumente durch viele weitere Faktoren erreicht. Dazu gehört die Feststellung der Rechtsfähigkeit zur Verwendung elektronischer Signaturzertifikate und die Einhaltung der Vorschriften für den Austausch elektronischer Dokumente, sofern vorhanden (z. B. der Vorschriften für den Austausch elektronischer Rechnungen, genehmigt durch Verordnung des Finanzministeriums der Russischen Föderation). Föderation N50n) und Übereinstimmung der Formate und Formen von Dokumenten mit den Anforderungen der geltenden Gesetzgebung der Russischen Föderation sowie Einhaltung anderer organisatorischer und rechtlicher Anforderungen, die sowohl durch die Gesetzgebung als auch durch zwischen den Teilnehmern der elektronischen Interaktion geschlossene Vereinbarungen auferlegt werden.

***

Jeder der EDI-Dienste löst spezifische Probleme. Services können sich ergänzen, aber nicht ersetzen. Wählen Sie einen Service basierend auf Ihren Aufgaben und Bedürfnissen.

Der EDI-Standard (Electronic Data Interchange) ist Teil altbewährter Systeme. Aber wir erleben immer wieder, dass EDI als moderner Standard präsentiert wird. Ist es so? Sollten wir EDI als Kerntechnologie für neue Projekte betrachten?
Betrachten wir EDI aus technischer Sicht und lassen wir alles andere beiseite.

Datenformat in EDI

nutzt EDI durch Trennzeichen getrenntes Textformat. Es eignet sich gut für flache Datenstrukturen wie Tabellen. Er ist nicht so gut für Präsentationen geeignet. hierarchische Strukturen Daten. Verschachtelte Objekte lassen sich mithilfe getaggter Formate wie XML und JSON besser serialisieren.
Sehr seltsam, wurde aber nie erstellt Beschreibungssprache(Dokumentdefinition) für EDI. Es sind so viele Jahre seit dem Aufkommen von EDI vergangen und es wurde so viel Mühe darauf verwendet, aber die Beschreibungssprache wurde noch nicht erstellt. Mit der Beschreibungssprache können Sie die Datenverarbeitung automatisieren, nämlich deren Generierung, Überprüfung, Transformation, Serialisierung und Deserialisierung. Zum Vergleich, um XML-Daten zu verifizieren, nehmen wir ein Datenschema (XML-Schema, xsd) und der Parser überprüft die Daten automatisch auf Übereinstimmung mit diesem Schema.
Auf ein Diagramm kann zwar verzichtet werden, dann ist aber eine Kennzeichnung des Dokuments wünschenswert. XML- und JSON-Dokumente können ohne Schema deserialisiert werden, da die Daten selbst Tags (Namen) von Datenelementen enthalten. EDI verfügt nur über Tags für Segmente und keine Tags für Elemente. Elemente werden durch ihre Position innerhalb eines Segments bestimmt. Universal Der EDI-Parser kann das Dokument nur in primitive Sammlungen analysieren, da das Dokument weder Namen noch Typen für Datenelemente enthält.

Kommen wir zu den Details.

Der EDI-Standard besteht aus zwei Hauptteilen:

Umschlagformat (Batch?) (Mischung aus Messaging-Standards)
Dokumentspezifikationen (Formate) (Mischung aus Industrie-(Domänen-)Standards)

Stapelformat

EDI definiert Pakete für Dokumentensätze, Dokumentengruppen und Dokumente/Transaktionen selbst ( Austausch, Gruppe Und Transaktion/Dokumentieren). Pakete sind auf ISA/IEA-, GS/GE- bzw. ST/SE-Segmentpaare beschränkt.
Hinweis: Zur Veranschaulichung verwende ich die EDI-X12-Variante des Standards, die in üblich ist Nordamerika. Eine andere Version des Standards, EDIFACT, ist in Europa verbreitet und unterscheidet sich nicht grundsätzlich von X12.
Hier ist ein Beispiel für die allerersten Segmente aller drei Pakete: ISA, GS und ST. Beispiel von hier:

ISA*00* *00* *ZZ*RECEIVERID *12*SENDERID *100325*1113*U*00403*000011436*0*T*>~
GS*FA*RECEIVERID*SENDERID*20100325*1113*24712*X*004030~
ST*997*1136~

Was sehen wir im ersten Segment?
Die letzten drei Zeichen des ISA-Segments sind Trennzeichen: „*>~“: ‚~‘ – Segmenttrennungssymbol; „*“ – Symbol zum Trennen von Elementen innerhalb eines Segments; „>“ ist ein Symbol zum Trennen von Unterelementen innerhalb eines Elements. Durch die Änderung dieser Zeichen ändern wir im Wesentlichen die Formate von Paketen und Dokumenten. In XML und JSON sind Trennzeichen im Standard festgelegt und können nicht geändert werden. Veränderliche Trennzeichen sind Relikte aus einer Zeit vor der Einführung von Unicode. Aber schon damals war es keine gute Idee, Trennzeichen veränderbar zu machen. Trennzeichen sind sehr wichtige Zeichen. Wenn wir es gebrauchen können beliebig Wenn Sie Zeichen als Trennzeichen verwenden, ändert sich dadurch nicht nur die Logik zum Parsen von Paketen in ihre Bestandteile, sondern es wird auch die Logik zum Parsen von Text innerhalb der Elemente selbst erheblich verkompliziert.
Sogar im ISA-Segment sehen wir Elemente, die definieren Zeit- und Datumsformate. Sie helfen uns, benutzerdefinierte Datums- und Uhrzeitformate in Dokumenten zu verwenden. Dies machte in den Siebzigern Sinn, als wir beim Kodieren von Datum und Uhrzeit ein paar Bytes einsparen mussten. Sind diese Elemente jetzt notwendig, nachdem wir das Y2K-Problem überwunden haben, nachdem spezielle und sehr detaillierte Standards für die Zeitdarstellung erstellt wurden?
Wir sehen im ISA-Segment Elemente, die definieren Absender Und Adressat. Im Wesentlichen ist dies - Adresse(Routenführung) Information. Das heißt, der Verpackungsstandard wird mit dem Adressierungsstandard kombiniert. Bei EDI müssen wir in unseren Daten den Absender und das Ziel angeben. Im ISA-Segment gibt es auch Berechtigungselemente. Die ganze Idee, diese Autorisierungsinformationen in den Nachrichten selbst zu platzieren, war einst recht fortschrittlich, aber jetzt sieht sie zumindest naiv, wenn nicht sogar gefährlich aus. Jetzt verstehen wir, dass Autorisierungsinformationen viel, viel komplexer sind als ein Wertepaar. Das Gleiche gilt für Adressinformationen. Der EDI-Standard drängt uns, diese Elemente zu verwenden.
Wir sehen auch das Element Bitte um Bestätigung (Bestätigungsanfrage). Das heißt, der Ersteller des Dokuments legt die Strategie für die Verwendung von Bestätigungen direkt im Dokument fest. Ist das eine gute Idee? Wir können Dokumente in verschiedenen Szenarien verwenden. Einige von ihnen verwenden Bestätigungen auf Anwendungsebene, andere verwenden andere Protokolle, um die Zuverlässigkeit zu verbessern. Die Zuverlässigkeitsrichtlinie wird nicht in den Daten selbst festgelegt, da die Zuverlässigkeit ziemlich hoch ist komplexes Thema in der Datenübertragung, bestimmt durch viele Kommunikationsteilnehmer.
Sogar innerhalb der Paketsegmente sehen wir Kontrollnummern (Kontrollnummern). Sie werden in Szenarien benötigt, in denen wir einen Satz Dokumente erhalten, ein Teil des Satzes jedoch unterwegs verloren geht oder beschädigt wird und wir versuchen, so viele Daten wie möglich wiederherzustellen. Dieses Skript wurde seitdem lange nicht mehr verwendet ähnliches Problem Die Zuverlässigkeit wird normalerweise auf den unteren Ebenen der Kommunikationsprotokolle entschieden. Wir bauen keine zuverlässige Kommunikation in die Anwendungsschicht ein, oder?
Ein weiteres Element des ISA-Segments ist EDI-Version(Standard-ID). Dies ähnelt der Versionsunterstützung, die wir von Serialisierungsstandards kennen.
Das GS-Segment enthält ein Element, das definiert Art des Dokuments (Art des Dokuments). Dabei handelt es sich beispielsweise um eine Bestellung oder eine Rechnung. Daran ist nichts auszusetzen, obwohl es einfacher ist, den Dokumenttyp im Dokument selbst festzulegen.

Wie wir sehen, sind fast alle Elemente in Paketsegmenten entweder nutzlos oder darüber hinaus gefährlich, wenn wir sie gemäß der Norm verwenden.
Bitte versuchen Sie nicht, Daten aus Paketsegmenten zur Authentifizierung und Adressierung zu verwenden.
EDI wurde zu einer Zeit entwickelt, als die Paketierung dieser Informationen die einzige Option war. Wir übertragen jetzt Dokumente über das Internet und verwenden eine Vielzahl von Standards und Protokollen für Verpackung, Adressierung, Authentifizierung, Autorisierung, Zuverlässigkeit, Kodierung, Serialisierung, Segmentierung usw. usw. Im gesamten Datenpfad werden protokollspezifische Informationen hinzugefügt und entfernt, und diese Informationen sind unabhängig von den Daten selbst.

Ist EDI ein Datenformatstandard oder ein Protokoll?

EDI versucht, ein Protokoll zu sein, weshalb wir diese Adressierungs-, Autorisierungs- und Bestätigungsanforderungselemente sehen. Ich weiß nicht, wie diese Informationen mit dem OSI-Protokollschichtmodell verglichen werden können.
Dennoch ist der größte Teil des EDI-Standards den Datenformaten gewidmet.

Dokumentformate

In den Paketen sehen wir die Dokumente selbst. Aber wir werden keinen Standard für ein universelles, verallgemeinertes Dokument finden. Der Standard definiert zahlreiche Formate für alle Arten von Dokumenten: für Bestellungen, für Rechnungen, für Inventarlisten von Anlagen ... Sie finden hier einen kleinen Ausschnitt aus der riesigen Liste standardisierter Dokumente.
EDI folgt einem bekannten Mythos: „Irgendwo da draußen gibt es ein ideales Format, das jedes Szenario beschreibt.“ Wir werden dieses Format auf jeden Fall finden. Wir müssen nur neue Szenarien hinzufügen und alte optimieren.“
Als Ergebnis von EDI Standarddokumente(Spezifikationen) zu komplex.
Nehmen wir ein Beispiel: Wir benötigen eine Rechnung für eine kleine örtliche Buchhandlung. Wir haben eine passende Standardspezifikation gefunden, EDI 850, Purchase Order. Auf den ersten Blick sieht es zu detailliert aus. Wir kaufen keine Lebensmittel, Kohle, Getreide, flüssige Produkte, gefährliche Produkte oder Medikamente. Wir benötigen keine internationalen Adressen. Wir werden keine Eillieferdienste in Anspruch nehmen. Die EDI-Spezifikation beschreibt alle diese möglichen Optionen, aber es sind zu viele Felder darin, die wir niemals verwenden werden. Es ist zu komplex für unser einfaches Dokument.
Es gibt viele industrielle (Domänen-)Standards, die als eine Art Wissensspeicher dienen. Diese Standards werden jedoch nicht als Datenübertragungsstandards verwendet. (Siehe , wo das Problem der Industriestandards beschrieben wird.)

Schleifen innerhalb von Dokumenten

Struktur einzelne Dokumente ziemlich einfach. Dokumente bestehen aus einer Reihe von Segmenten, in denen sich Dokumentdaten befinden.
Es stellt sich jedoch heraus, dass Segmente zu sogenannten Gruppen oder sich wiederholenden Gruppen zusammengefasst werden können Fahrräder(Schleifen). Das Pikante daran ist, dass diese Zyklen im Dokument in keiner Weise hervorgehoben werden. Über das Vorhandensein eines Zyklus können wir in der Spezifikation dieses speziellen Dokuments lesen. Segmente desselben Typs (mit denselben Tags) können entweder unabhängig voneinander oder innerhalb von Zyklen lokalisiert werden. Einen Parser zu erstellen, der Zyklen erkennt (die, ich wiederhole, in dem Dokument in keiner Weise erwähnt werden), ist eine eher nicht triviale Aufgabe.
In XML und JSON gibt es kein solches Problem; hierarchische Objekte oder Objektsammlungen beliebiger Verschachtelungsebene werden ganz einfach mithilfe öffnender und schließender Tags definiert, mit oder ohne Namen.
EDI versuchte, auf zwei Stühlen zu sitzen. Einerseits ähnelt das Dokumentformat dem CSV-Format und eignet sich zur Darstellung tabellarischer Daten. Andererseits versuchte er, hierarchische Objekte zu beschreiben, und dieser Versuch endete sehr wenig überzeugend. Natürlich verstehen wir das jetzt, da wir JSON vor uns haben. Aber bedenken wir, dass EDI nicht für die Übertragung tabellarischer Daten gedacht ist, sondern für die Übertragung von Dokumenten, deren Struktur hierarchisch ist.

Eine nichttechnische Sicht auf EDI

Der Vollständigkeit halber liste ich noch einige nichttechnische Features von EDI auf:

EDI-Standard nicht frei. Das sieht im Vergleich zu anderen Standards ziemlich seltsam aus.
Die EDI-Standardspezifikationen sind übertrieben detailliert. EDI-Spezifikationen sind so komplex, dass Unternehmen Spezialisten einstellen müssen, die mit der spezifischen Spezifikation vertraut sind. Diese Spezialisten kommunizieren mit speziellen EDI-Begriffen; es handelt sich quasi um eine EDI-Sprache, die nichts mit dem Geschäft zu tun hat. Schauen Sie sich EDI-Vereinbarungen zwischen Unternehmen an. Diese Vereinbarungen sind voll von spezifischen Anforderungen, die durch den EDI-Standard definiert werden, sind jedoch weit von Geschäftsanforderungen entfernt.
EDI-Standard nicht stabil. Ein Sonderausschuss erlässt alle sechs Monate Änderungen am EDI-Standard. Jede dieser Versionen bringt neue Klarstellungen. Die Entwicklung eines Standards folgt nicht den Wünschen der Nutzer, sondern folgt einfach diesen Kalenderplan. Vermutlich liegt das nicht daran, dass der Standard sehr hoch ist, sondern daran, dass das Gremium die Ergebnisse seiner Arbeit vorlegen muss.
EDI wurde geschaffen, um Bits sparen und Dokumente so kompakt wie möglich gestalten. Diese Anforderung besteht weiterhin, wird jedoch kaum noch für die Übertragung von Dokumenten genutzt. Jedes Kind besitzt mittlerweile ein Telefon, das Gigabyte an Videos pumpt. Dies ist nicht mehr die Ära der Großrechner und Fernschreiber. Und es ist ziemlich seltsam, Berichte zu lesen, in denen ernsthaft über Ressourceneinsparungen durch den Übergang von der Verwaltung von Papierdokumenten zur Verwendung von EDI gesprochen wird.
Um Speicherplatz zu sparen, verwendet EDI Codes Daten wo immer möglich darzustellen. Dadurch erscheinen Dokumente verschlüsselt, was das zusätzliche Problem des Austauschs von Codetabellen mit sich bringt.
Zur Übermittlung wurde der EDI-Standard geschaffen Stapel von Dokumenten aufgrund der Tatsache, dass Kommunikation und Computer teuer und langsam waren. Seitdem hat sich viel verändert, Kommunikation und Computer sind schnell und günstig geworden. Daten werden heute in kleinen Nachrichten oder Streams übertragen, und diese kleinen Nachrichten sind die Grundlage verteilter Systeme. Dokumentensätze werden immer noch verwendet, aber nicht wegen langsamer Hardware, sondern weil Geschäftsprozesse dies erfordern.
Existiert nicht Standard für die EDI-Beschreibungssprache. Das bedeutet, dass wir nicht erschaffen können Universal- Parser zur Verarbeitung von EDI-Dokumenten. Parser müssen Beschreibungen Tausender vorhandener EDI-Spezifikationen mit einer großen Detailtiefe enthalten. (Zum Beispiel stellt Microsoft als Teil von BizTalk Server etwa 7.000 XML-Schemas für EDI-Dokumente bereit.) Verfügbare EDI-Parser sind teuer. Um mit EDI-Dokumenten zu arbeiten, müssen wir höchstwahrscheinlich EDI-Dokumente in das XML-Format konvertieren und XML Schema zusammen mit einem XML-Parser verwenden, um EDI-Dokumente zu verarbeiten: zur Überprüfung, Transformation, Serialisierung, Deserialisierung und Erstellung. Dies geschieht in BizTalk Server.
Aufgrund des Fehlens einer Standard-EDI-Beschreibungssprache werden Dokumente mithilfe von ... mehrseitigen Anweisungen beschrieben. EDI-Parser-Entwickler interpretieren diese Anweisungen unterschiedlich und aus diesem Grund unterschiedlich EDI-Parser sind nicht kompatibel.
Der EDI-Standard entstand zu einer Zeit, als die Entwicklung von Programmen, Protokollen und Datenformaten extrem teuer war und sehr viel Zeit in Anspruch nahm. Die Schaffung eines Standards für ein universelles Dokumentenformat wurde gerechtfertigt. Heutzutage werden Datenformate spontan generiert und unsere Programme verwenden in der Regel keine universellen Standards, sondern erstellen unterschiedliche Formate für bestimmte Fälle. Zu den EDI-Spezifikationen gehören: größtmögliche Anzahl an Details um alle Benutzer zufrieden zu stellen. Moderne Programme beziehen in die Spezifikationen der übertragenen Daten nur die Daten ein, die notwendig sind. Die Anzahl der Elemente in der EDI-Spezifikation, die in Ihrem speziellen Fall unnötig sind, wird immer sehr groß sein.
EDI mischt zwei Arten von Standards: Standards für die Kommunikation und Standards für die Formatierung von Geschäftsdaten. Moderne Tendenzen direktes Gegenteil: Standards müssen unabhängig voneinander (orthogonal) sein, was eine beliebige Kombination ermöglicht.

Wie wir sehen, ist der EDI-Standard aus technischer Sicht in fast jeder Hinsicht veraltet. Es ist unwahrscheinlich, dass es derzeit rationale technische Gründe für seinen Einsatz gibt. Dennoch ist EDI immer noch weit verbreitet.
Im nächsten Teil werden wir versuchen, die Gründe dafür zu finden. Höchstwahrscheinlich werden sie nicht technischer Natur sein.

Komplexe Kombinationen aus Marktbeziehungen, bestehender Infrastruktur und strategischem Management sowie Gestaltung der Richtung der Entwicklung der Informationstechnologie. Bedeutung, Rolle und Perspektiven für den Einsatz der Informationstechnologie in der Logistik.

Das Senden Ihrer guten Arbeit an die Wissensdatenbank ist ganz einfach. Nutzen Sie das untenstehende Formular

Studierende, Doktoranden und junge Wissenschaftler, die die Wissensbasis in ihrem Studium und ihrer Arbeit nutzen, werden Ihnen sehr dankbar sein.

Sorge um „Russische Kälte“

V. A. Stoyko, IT-Direktor der russischen Holod-Unternehmensgruppe

Ich möchte mich bei der Firma ZAO PF SKB Kontur für die zeitnahe Einführung von EDI.Kontur in den Filialen unseres Unternehmens bedanken. Ich möchte besonders darauf hinweisen professionelles Niveau Vorbereitung des Teams und ausdrücklicher Dank an den Manager Wladimir Wladimirowitsch Porochonko, der immer auf Anfragen reagiert und alle unsere Probleme erfolgreich löst.

Warenzeichen „Kuban Milkman“ (JSC „Trust Southern Sugar“)

A. A. Prokopyev, Leiter der IT-Abteilung

Im November 2013 begannen wir mit der SKB Kontur im Rahmen des elektronischen Dokumentenmanagements zu interagieren.

Hervorheben möchte ich auch die qualifizierte Arbeit des Projektteams und die schnelle Reaktion auf aufgetretene Probleme.

Wir unsererseits hoffen auf eine weiterhin für beide Seiten vorteilhafte und effektive Zusammenarbeit mit SKB Kontur.

Svetlana Egorova, Projektkoordinatorin der Kundendienstabteilung

Wir haben dieses Projekt am Vorabend der Legalisierung elektronischer Rechnungen gestartet – wir wollten die technischen und organisatorischen Nuancen im Voraus erarbeiten, um in dem Moment, in dem elektronische Rechnungen als rechtsgültig anerkannt werden, vollständig vorbereitet zu sein und mit der Nutzung elektronischer Rechnungen von rechtlicher Bedeutung zu beginnen Rechnungen auszustellen, sobald sich die Gelegenheit dazu bietet.

Medvedeva Anastasia, Leiterin der Kundendienstabteilung

Nach der Umstellung auf EDI.Kontour haben wir ein Netzwerk nach dem anderen angebunden. Und wir sind mit der Leistungsfähigkeit dieser Lösung zufrieden. Was das Serviceniveau des Unternehmens SKB Kontur angeht, bin ich damit zufrieden und übertrage es daher systematisch an unsere wichtigsten Kunden zur Unterstützung.
Wenn wir über Vorteile sprechen, ist einer der ersten, dass Kontur die Integration in unserem 1C schneller als die Konkurrenz eingerichtet hat. Zweitens, nicht weniger wichtig, ist die Effizienz bei der Lösung unserer Probleme. Der dritte Punkt ist die Kundenorientierung von Kontur. Während unserer Zusammenarbeit hat der Anbieter Funktionen in seinem Modul implementiert, die nur für uns notwendig waren. Viertens - Unabhängigkeit. Großer Teil Anpassungen werden von Konturov-Mitarbeitern mit minimaler Beteiligung unserer IT-Abteilung vorgenommen.

Daher bewerte ich die Arbeit mit Contour mit 5 von 5!

OJSC „PuragroUK“

Sergey Burko, Systemadministrator

Das Leistungsniveau dieser Lösung ist ebenfalls auf höchstem Niveau, natürlich nicht ohne Mängel, aber es gibt einiges, nach dem man streben kann. Als Hauptvorteile sehe ich die Einfachheit der Schnittstelle und die Notwendigkeit eines Minimums an Vorgängen zur Lösung unserer Probleme.

Ich muss sagen, wir hatten unsere eigenen „Wünsche“, die nicht in der Standardversion enthalten waren. Die Mitarbeiter von SKB Kontur kamen uns auf halbem Weg entgegen und setzten alles um, was wir zur Arbeitserleichterung verlangten. Darüber hinaus wurden diese Verbesserungen meines Wissens später in die Standardlösung übernommen, sodass sie nicht nur für uns von Nutzen waren. Ich möchte anmerken, dass die Implementierungsspezialisten recht schnell auf meine Anfragen reagiert haben.

Sowohl die finanziellen als auch die zeitlichen Ergebnisse haben uns im Vergleich zur Zusammenarbeit mit einem anderen Anbieter gefallen. All dies führte zu der Entscheidung, zu SKB Kontur zu wechseln.

Einzelhandelskette „Red & White“

Yana Kokorina, Leiterin der Abteilung für automatisierte Informationssysteme

Seit März 2015 arbeitet Krasnoe i Beloe mit dem Anbieter SKB Kontur zusammen, der Dienstleistungen im Bereich der elektronischen Dokumentenverwaltung anbietet.

Zu sagen, dass der Dokumentenfluss groß ist, ist wahrscheinlich eine Untertreibung. Und angesichts des Arbeitsumfangs wäre ein Verzicht auf die elektronische Dokumentenverwaltung nicht nur finanziell unrentabel, sondern auch unter dem Gesichtspunkt der Arbeitszeitersparnis nicht ratsam.

Hervorheben möchte ich auch die Effizienz bei der Lösung von Anfragen, sowohl organisatorischer als auch technischer Natur.

Café-Bäckerei „Paul Bakery“

Stanislav Baryshev, Regisseur

Von SKB Kontur bis elektronisches Dokumentenmanagement Wir arbeiten seit Dezember 2013. Obwohl bisher nur wenige Netzwerke verbunden sind, bewerten Sie die Ergebnisse des Wechsels zu elektronische Dokumente Wir haben es bereits geschafft. Um alle Geschäftsprozesse möglichst vollständig zu automatisieren, boten uns Vertreter des Anbieters Unterstützung bei der Umsetzung der Integration mit der Warenbuchhaltung an SAP-Systeme. Wir danken SKB Kontur und seinen Mitarbeitern für die fruchtbare Zusammenarbeit und die hohe Qualität der erbrachten Dienstleistungen!

OJSC „Brotbackwerk Rezhevsk“

Raisa Rakhimyanova, Hauptbuchhalterin

Seit März 2014 nutzen wir das System EDI.Kontour. Die vollständige Implementierung des Systems war für uns sehr wichtig, da das Liefervolumen im Jahr 2013 11.714 Tonnen betrug, was eine große Arbeitsbelastung der Spezialisten und einen beeindruckenden Dokumentenfluss bedeutet. Der Empfang von Bestellungen per EDI erleichterte die Arbeit erheblich. Die Mädchen spürten dies besonders, wenn es aus irgendeinem Grund zu einem Ausfall kam (einmal kam es in einer Einzelhandelskette zu einem Ausfall).

Vor der Zusammenarbeit mit Kontur haben wir mit einem anderen Anbieter zusammengearbeitet, sind nun aber mit dem Service und den Tarifen rundum zufrieden. Der Implementierungsprozess hat etwas Zeit in Anspruch genommen, obwohl immer noch Verbesserungen vorgenommen werden, die angesichts der Besonderheiten unseres Unternehmens notwendig sind.

Mit technischer Unterstützung ( Hotline) Wir hatten noch keine große Begegnung, aber die Jungs von der Umsetzung und unser Manager sind einfach großartig!

LLC TD „Syrobogatov“

Kupriyanov Konstantin, 1C-Programmierer

Die Kosten für die von Kontur bereitgestellten Dienstleistungen sind im Vergleich zu anderen Anbietern niedriger und flexibel Tarifplan ermöglicht Ihnen die Auswahl des passenden Tarifs für jede Einzelhandelskette, basierend auf dem Volumen des Dokumentenflusses. Bei dieser Zusammenarbeit spüren wir ein Gleichgewicht zwischen der Vielseitigkeit, Geschwindigkeit und Stabilität des Integrationsmoduls mit dem Warenbuchhaltungssystem auf Basis der 1C Enterprise 7.7-Plattform. Eventuell auftretende Fragen, sowohl bei der Umsetzung als auch im Betrieb, werden von den SKB Kontur-Mitarbeitern schnellstmöglich geklärt; keine einzige Frage bleibt unbeantwortet.

Ich wünsche mir, dass SKB Kontur alle Handelsketten abdeckt, die über EDI mit Lieferanten interagieren möchten!

Maxim Korzhavin, Leiter der IT-Abteilung

Unser Übergang zu EDI war nicht von einigen Vorteilen bestimmt, sondern von einer lebenswichtigen Notwendigkeit: Bundesnetze interpretieren ihre Spielregeln. Erst im Arbeitsprozess entsteht das Verständnis dafür, was EDI ist guter Helfer in einem Geschäftsprozess. Um die Schönheit und Leistungsfähigkeit dieses Tools wirklich zu erleben, müssen Sie Ihr Buchhaltungssystem mit EDI integrieren. In unserer Organisation ist dies aufgrund der Umstellung auf das neue 1C-Buchhaltungssystem noch nicht möglich. Daher sind wir mit der Webplattform zufrieden. Da EDI in Russland ein neuer Bereich ist, können wir uns an der Verbesserung und Fertigstellung der Plattform beteiligen. Aber es entsteht bereits ein praktisches Tool für die Kommunikation mit unseren Partnern. Bevor wir zu Kontur kamen, führte unser Weg über andere EDI-Anbieter. Sagen wir nichts über sie. Nehmen wir an, unsere letzte Station ist EDI von SKB Kontur. Und wir sind zufrieden damit. Seit Mitte 2013 arbeiten wir aktiv mit SKB Kontur im EDI-Bereich zusammen. Bis Ende des Jahres haben wir alle unsere Partner (Handelsketten) von anderen Anbietern auf EDI.Kontur umgestellt. Und dann begannen sie, neue Fahrzeuge anzuschließen. Wir müssen noch mit 1C integrieren. Deshalb: Arbeit und Arbeit. Und Kontur versteht es mit Hilfe seiner Spezialisten, diese Arbeit sehr angenehm und komfortabel zu gestalten (wofür wir ihnen danken).

Gleich zu Beginn wurde ein Arbeitsplan erstellt, an den wir uns während der gesamten Zeit strikt gehalten haben. Alle Probleme wurden im Handumdrehen und schnell gelöst. All dies macht SKB Kontur zum unangefochtenen Spitzenreiter unter anderen Anbietern. Die Spezialisten von SKB Kontur sind mehr als wir daran interessiert, dass bei uns alles wie am Schnürchen läuft. Und natürlich sind die Preise für die Dienstleistungen von Kontur am niedrigsten (um ein Vielfaches).
Der Parcours wird Ihnen beibringen, keine Angst vor Innovationen zu haben! Daher sind wir mit großem Interesse bereit, weiterhin erfolgreich mit ihnen zusammenzuarbeiten und die ersten zu sein, die ihre neuen Produkte nutzen.

MPZ „Dobrogost“

Konstantin Starikov, Systemadministrator

Im EDI-System arbeiten wir mit den Einzelhandelsketten „Monetka“, „X5 Retail Group“, „Kirovsky“, „Megamart“, „Lenta“ zusammen.

Vor Vertragsabschluss mit Kontur haben wir mit einem anderen Anbieter zusammengearbeitet. Diese Zusammenarbeit war für uns äußerst kostspielig. Aber das ist nicht so schlimm. Das Wichtigste ist, dass wir ernsthafte Schwierigkeiten bei der Arbeit mit dem Modul unseres Anbieters hatten. Unsererseits war ein enormer manueller Arbeitsaufwand erforderlich, um das „automatische“ Laden von Dokumenten in 1C durchzuführen. Auch mit dem technischen Support waren wir völlig unzufrieden. Oft hörten wir statt Antworten nur Pieptöne am Telefon. Nun sind wir mit dem Service unseres Anbieters zufrieden. Probleme werden schnell gelöst; in extremen Fällen können einige Probleme durch unseren Manager gelöst werden. Die Funktionsweise des Moduls funktioniert wirklich gut. Endlich konnten wir den Prozess der Dateneingabe in unser Buchhaltungssystem automatisieren. Als Wunsch können wir sagen, dass es in Zukunft bequem wäre, mit allen Einzelhandelsketten zu einem unbegrenzten Tarif zusammenzuarbeiten.

Handelsunternehmen „Credos“

Evgeniy Petrenko, stellvertretender Direktor für Entwicklung von Managementsystemen und -technologien

Heute ist der EDI-Austausch vollständig implementiert. Für unterschiedliche Netzwerke werden unterschiedliche Ketten der Dokumentenübertragung implementiert.
Ein wesentlicher Vorteil von SKB Kontur ist die Effizienz bei der Lösung sowohl organisatorischer als auch technischer Probleme bei der Anbindung neuer Dokumente oder neuer Gegenparteien. Glauben Sie mir, ich habe etwas zum Vergleich. Umsetzungsspezialisten, technische Spezialisten und Manager reagieren schnell, klar und informativ auf unsere Anfragen.

Die wichtigsten Aufgaben, die EDI.Kontur für uns löst, sind der Empfang von Bewerbungen von Handelsketten und der Versand von Antwortdokumenten. Und jetzt kommen wir zum Austausch rechtlich bedeutsamer Dokumente.

Insgesamt bin ich mit der Zusammenarbeit mit SKB Kontur und den Ergebnissen des Projekts zum Anbieterwechsel zufrieden.
Dmitry Mamontov, Leiter der Abteilung für die Implementierung von Geschäftssystemen

Als wir mit der Implementierung von EDI in Castorama begannen, planten wir, uns auf die Zusammenarbeit mit zwei unabhängigen EDI-Anbietern zu beschränken. Im Laufe des Projekts haben wir uns jedoch entschieden, die Anzahl der EDI-Partner zu erhöhen, vor allem um die Anbindung der Lieferanten an EDI zu beschleunigen. Die Wahl fiel auf SKB Kontur, das in diesem Bereich zu den Marktführern gehört und bereits mit den meisten unserer Lieferanten und anderen Handelsketten zusammenarbeitet.

Jetzt arbeitet SKB Kontur aktiv mit Lieferanten zusammen – in nur wenigen Monaten haben sich mehr als 10 % der bisher nicht angebundenen Lieferanten dem EDI-Austausch angeschlossen. Unter Beibehaltung dieses Tempos planen wir, in naher Zukunft alle Bestellungen aus den Castorama-Filialen vollständig an EDI zu übertragen.