Wymiana danych EDI – UN/EDIFACT

ediEDI to w skrócie „Electronic Data Interchange”, czyli elektroniczna wymiana danych. To transfer informacji biznesowych ze źródłowego systemu informatycznego do innego z wykorzystaniem standardowych, zaakceptowanych formatów komunikatów. Najczęściej występującymi przykładami dokumentów biorących udział w wymianie danych są: zamówienia, potwierdzenia zamówień, awiza wysyłki, faktury, faktury korygujące, itp.

Głównymi celami i korzyściami jakie można uzyskać wdrażając EDI to:

  • zmniejszenie pracochłonności procesu poprzez wyeliminowanie wielokrotnego wprowadzania danych przez pracowników przedsiębiorstwa
  • zmniejszenie ilości błędów w przepływie informacji między sprzedawcami i nabywcami
  • przyspieszenie wymiany informacji między przedsiębiorstwami

Wdrożenie EDI wymaga bezpośredniej komunikacji między systemami komputerowymi, zarówno nabywców jak i sprzedawców produktu.

Automatyzacja

Z pewnością znasz kogoś kto pracuje w jakimś przedsiębiorstwie jako tzw. specjalista ds. marketingu. W praktyce taka praca polega na odbieraniu telefonów i e-maili, przyjmowaniu zamówień, wprowadzaniu ich do systemu informatycznego, poinformowaniu klienta, że wszystkie towary są na stanie (lub nie) i wystawieniu faktury. Później należy wydrukować dokumenty, a nierzadko jeszcze w XXI wieku własnoręcznie je zaadresować i odstawić na odbiór przez pocztę lub kuriera. To ciężka praca, bo taki pracownik znajduje się na pierwszej linii ognia – klient przy najbliższej okazji wyżyje się na nim i wygarnie że np. przesyłka dojechała dzień później, czy że nie mamy czegoś na stanie. Można oberwać dosłownie za wszystko, włącznie z tym że wybory wygrało PIS 🙂 (sorry, taka powyborcza dygresja 02.2016).

Nie unikniemy tego całkowicie, jeśli rodzaj prowadzonego przedsiębiorstwa nastawiona jest na sprzedaż produktów dla konsumentów detalicznych. Tak będzie w przypadku sprzedaży, ale czy proces zakupów nie można byłoby usprawnić między dwoma przedsiębiorstwami?

Zobaczmy ilu ludzi jest zaangażowanych do procesu złożenia zamówienia od jednego przedsiębiorcy do drugiego:

  1. Kupujący – pracownik działu handlowego
  2. Sprzedający – pracownik działu handlowego
  3. Po drodze kurier, sortownia, transport do najbliższej centrali odbiorcy, znowu sortownia, kurier, uff..

Czyli mamy dwa przedsiębiorstwa i dwa etaty które trzeba opłacić. Jak podaje goldenline, na dzień dzisiejszy mediana zarobków w marketingu to ok. 3400 zł brutto. 3400 brutto dla pracownika znaczy tyle, że dostając na rękę ok. 2500 zł kosztuje pracodawcę już ponad 4100 zł. Do tego obaj pracodawcy ponoszą koszta utrzymania stanowiska (biurko, komputer, telefony, media, itp.), ale to już pomińmy.

4100 zł x 12 miesięcy x 2 przedsiębiorstwa = prawie 100 tys. zł! Taki jest koszt pracy dwóch pracowników działu handlowego w ciągu roku. Co prawda każdy z nich będzie obsługiwał kilkanaście innych klientów, ale i tak ta kwota jest dosyć spora, jak za proces który można zautomatyzować.

W idealnych warunkach można byłoby się pozbyć tych dwóch etatów wprowadzając właśnie wymianę danych EDI. Świat nie jest idealny i tego też nie da się zrobić, ale z pewnością ilość etatów można zminimalizować.

Formaty dokumentów elektronicznych

Podstawowym formatem dla wymiany danych jest EDIFACT przyjęty przez Międzynarodową Organizację Normalizacyjną (ISO) w 1987 roku jako norma ISO 9735. Na rynku polskim kilka firm wprowadziło możliwość obsługi plików XML, jednak światowym standardem jest właśnie EDIFACT.

Oprócz samego formatu pliku wprowadzone są na świecie dwa standardy składni:

  1. American ANSI X12 standard,
  2. European EDIFACT standard.

Są jeszcze starsze jak UNGTDI, czy VDA używany w Niemczech.

EDIFACT

No właśnie – mamy EDIFACT z 1987 roku, kiedy świat jeszcze nie znał formatu XML. Poniżej przykład komunikatu wykorzystywanego jako odpowiedź na zapytanie o dostępność biletu lotniczego (FRA-JFK-MIA):

Czytelnie? No nie bardzo, a z pewnością nie tak jak jesteśmy do tego przyzwyczajeni pracując z XMLami. Każdy typ komunikatu posiada swoją dokumentację z którą należy się zaznajomić, a jest z czym – specyfikacja dla faktur liczy zaledwie 121 stron 🙂

invoice

W skrócie: plik w formacie EDIFACT może zawierać wiele komunikatów, a te z kolei składają się z segmentów zawierających elementy. Nazwy segmentów oraz ilości elementów określone są w dokumentacji dla każdego z typów dokumentów. Poszczególne segmenty rozdzielane są apostrofem, poszczególne elementy znakiem +, a parametry dwukropkiem. Jednak ogólna struktura jest następująca:

Podstawowe obowiązkowe segmenty:

  • UNB – nagłówek pliku wymiany danych, zawiera m.in. identyfikatory nadawcy i odbiory, ilość komunikatów (UNH) oraz unikalny identyfikator samej wiadomości
    Np. UNB+UNOA:2+5900000000000:14+F1:F2+160206:1416+61997++IFTSTA’ oznacza transakcję o id=61779 składającą się z dwóch wiadomości wysłaną od firmy 5900000000000 do firmy F1 dnia 16.02.2016.
  • UNZ – zawsze ostatni segment pliku również zawierający dla potwierdzenia ilość komunikatów w transakcji identyfikator transakcji (tak jak w segmencie UNB).
    Np. UNZ+2+61997 oznacza że w pliku znajdują się dwa typy dokumentów z transakcji o id=61997.
  • UNH – segment komunikatu, może ich być wiele (np. kilka faktur, czy zleceń transportowych). Ilość segmentów powinna być zgodna z określonymi w segmentach UNB i UNZ.
    Np. UNH+1+IFTSTA:D:96A:UN:SHIP’ oznacza pierwsze zlecenie transportowe, a UNH+2+IFTSTA:D:96A:UN:SHIP’ drugie w obrębie jednej transakcji.
  • UNT – segment zakończenia komunikatu, zawiera informacje o ilości wszystkich segmentów pomiędzy UNH i UNT włącznie z nimi.
    Np. UNT+18+2′ oznacza koniec drugiego komunikatu (UNH) z ilością segmentów równą 18.

EDI w Polsce

Od 2001 roku prace nad uzgadnianiem formatów komunikatów EDI prowadzi Grupa ds. EDI, która powstała z inicjatywy ECR Polska. Aktualną listę uzgodnionych typów dokumentów znajdziemy tutaj. A na dzień dzisiejszy są nimi:

W Polsce usługi EDI oferują następujące firmy:

Sposoby przesyłania komunikatów

EDI nie określa sposobu przesyłania komunikatów – mogą one być przesyłane przez dowolne medium, którym posługują się obie strony transmisji. Może to być transmisja modemowa, poprzez FTP, HTTP, AS1, AS2. My jako programiści musimy wykonać transformację obiektów pochodzących z naszych systemów na pliki w formacie EDIFACT i w drugą stronę. Pozostaje tylko zlecenie wysyłki tych plików, ich odbiór i import. Do samej wymiany komunikatów wykorzystywany jest protokół AS2, do obsługi którego można wykorzystać open source’owy program Mendelson AS2 napisany w Javie. Zajmie się on wysyłaniem jak i odbieraniem komunikatów:

mendelson

Pomocne odnośniki

Podsumowanie

Sam miałem okazję pracować nad integracją komunikatów: iftmin, iftsta, invoice, correcting invoice, orders, ordrsp. Korzystałem również z rozwiązań INFINITE i programu do procesowania dokumentów EDInet Connector. INFINITE umożliwia wymianę danych za pomocą plików XML, do których dostaniemy pliki z XML Schema. Na podstawie schem można np. w Javie wygenerować klasy je mapujące.

Myślę, że warto automatyzować procesy. Zatrudnianie pracownika w dużej hurtowni, którego jedynym celem będzie przyjmowanie zamówień, wysyłka potwierdzeń i faktur jest według mnie marnowaniem zasobów ludzkich.

Świetnym anty przykładem marnowania takich zasobów jest wprowadzenie przedwyborczej obietnicy PIS w sprawie 500+. Według wyszukanych w internecie wyliczeń świadczenia otrzymają rodzice blisko 4 milionów dzieci. Nie wiem ile będzie takich rodzin, ale zakładając że tylko 2 miliony, to znaczy że 2 miliony osób będzie przynajmniej raz na rok wypisywać wnioski, składać je w gminie, gdzie tam znowu będą musiały być wprowadzone przez klawiaturę (w najlepszym przypadku). 2 miliony osób x 1 godzina na wypisanie wniosku, dojazd do gminy, itp. daje 2 miliony roboczogodzin na coś zupełnie bezsensownego. To tak jakby 10 osób musiało ciągle pracować przez 68 lat – bez żadnej przerwy. A do tego dochodzą koszta zatrudnienia 7 000 urzędników. Czy to wszystko nie mogłoby się dziać automatycznie np. poprzez rozliczenia PIT?

Bez sensu…

 

To również może Cię zainteresować:

  • PHP i podobieństwo dwóch wyrazówPHP i podobieństwo dwóch wyrazów Trafiłem ostatnio na ciekawą sytuację. Blisko dziewięć lat temu napisałem system dla zarządzania awizacjami kierowców w magazynach dla największego w Polsce producenta wody. System do dziś […]
  • Mapowanie XML obiektów Java – JAXBMapowanie XML obiektów Java – JAXB Podczas tworzenia oprogramowania na każdym kroku mamy kontakt z danymi w formacie XML. Opiszę tutaj jeden ze sposobów konwersji danych w obie strony Java <-> XML. Ale na […]
  • Czat z socket.io i JavaCzat z socket.io i Java Cel: Oprogramowanie w javie chatu działającego w czasie rzeczywistym bez komunikacji asynchronicznej. Biblioteki: socket.io netty-socketio Efekt […]
  • Arduino – czujnik odległości HC-SR04 i wykresy w czasie rzeczywistymArduino – czujnik odległości HC-SR04 i wykresy w czasie rzeczywistym Zaopatrzyłem się ostatnio w ultradźwiękowy czujnik odległości HC-SR04. Jest tani, bo kosztuje poniżej 10 zł., podłącza się go bezpośrednio do Arduino czterema przewodami żeńsko-męskimi i […]
  • Programowanie funkcyjne w Javie.Programowanie funkcyjne w Javie. Co nieco o programowaniu funkcyjnym. Czy możliwe jest całkowite usunięcie ze swojego kodu wyrażeń typu if / else, for, while, do while? Wydaje się to niemożliwe, bo wielu programistów […]
  • Arduino – flagi bitoweArduino – flagi bitowe Pamiętacie jak miesiąc temu wspominałem o flagach bitowych w javie? Arduino jest właśnie świetnym przykładem możliwości ich wykorzystania. Mamy tutaj ograniczoną pamięć, dlatego w prosty […]

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *