Firmy zazwyczaj mają różne wewnętrzne struktury danych. Wynika to z faktu, że istnieje niezliczona ilość różnych systemów IT i ERP i że nie wszystkie z nich kierują się tą samą logiką. W odniesieniu do świata elektronicznej wymiany danych (EDI) można powiedzieć, że mówią różnymi językami. Może to brzmieć jak wyzwanie, ponieważ wraz ze wzrostem liczby partnerów EDI trzeba będzie „mówić różnymi językami”. W tym miejscu z pomocą przychodzą dostawcy usług EDI. W tym kontekście ważną rolę odgrywa proces zwany mapowaniem. W tym poście na blogu wyjaśnię, jak to się dzieje i dlaczego standardy są kluczowe.
Na początek pamiętajmy: ujednolicone formaty danych mają ogromne znaczenie w transmisji komunikatów EDI, ponieważ ostatecznie zapewniają, że procesy biznesowe mogą odbywać się automatycznie. Główne standardy EDI obejmują EDIFACT, ANSI, ODETTE i VDA. Są one stosowane w określonych branżach lub w kilku branżach. Standardy te opisują strukturę komunikatów i, jak sama nazwa wskazuje, sposób ich standaryzacji. Dlatego bardzo ważna jest standaryzowana struktura.
Różne terminy dla tego samego pola danych
Jeśli jednak przyjrzymy się istniejącym systemom informatycznym w firmach, które chciałyby dokonywać między sobą elektronicznej wymiany danych, zobaczymy, że często istnieją duże różnice. Wyposażenie techniczne i istniejące materiały danych są zwykle dostosowywane do specyficznych potrzeb i praktyk przedsiębiorstwa. Podczas gdy jedna firma może korzystać z systemu ERP firmy SAP, inna może korzystać z systemu ERP firmy Microsoft, Sage, IFS lub dowolnego innego producenta. Firma A może nazwać pole danych „datą”, podczas gdy inna może użyć niemieckiego słowa do określenia tego samego pola. Ponadto daty te mogą mieć różne formaty w zależności od systemu ERP. To samo może dotyczyć opisu kolorystycznego produktu. Jedna firma może wypełnić pole danych kodami kolorów, a inna może po prostu wpisać „zielony” lub „niebieski”. Oba mają na myśli to samo, ale wyrażają tę ideę inaczej. Może to stanowić problem podczas próby przesyłania i automatycznego przetwarzania danych. W związku z tym należy podjąć środki ostrożności.
Mapowanie EDI jest czymś w rodzaju „drogowskazu” dla danych
Kiedy dwie lub więcej firm o różnych strukturach lub bazach danych chcą wymieniać informacje, muszą skoordynować swoje struktury i treści, aby proces przebiegał sprawnie. W praktyce odbywa się to za pomocą tabeli tłumaczeń, która przekształca dane z wewnętrznej struktury systemu ERP danej firmy na format wymagany przez drugą stronę. Proces ten nazywany jest mapowaniem. Dzięki mapowaniu, na przykład, pole z datą faktury musi odpowiadać regułom i definicji struktury docelowej. To samo dotyczy numerów faktur, łącznej kwoty i innych ustandaryzowanych pól, które obie strony muszą wypełnić tymi samymi danymi w ramach Elektronicznej Wymiany Danych (EDI). Podczas mapowania EDI oprogramowanie konwertujące otrzymuje wszystkie niezbędne informacje, umożliwiając prawidłową transformację danych.
Aby uniknąć konieczności rozumienia i mówienia w niezliczonych językach (lub formatach danych), transformacja danych odbywa się w „standardzie pośrednim” (np. EDIFACT), zrozumiałym dla obu stron. Inaczej mówiąc: firma A mówi po niemiecku, a firma B po francusku. Wspólnym mianownikiem będzie język angielski, który obie strony rozumieją i mówią nim. Jest to ogromna zaleta, jeśli zaangażowanych jest kilku partnerów biznesowych, ponieważ wystarczy opanować JEDEN język, którym w naszym przypadku jest standard EDI. Idąc dalej tą analogią: mapowanie dotyczy wszystkich zasad gramatyki, składni, a ostatecznie także słownictwa.
Doświadczeni dostawcy usług EDI posiadają wszechstronną wiedzę specjalistyczną
Producenci towarów lub pośrednicy zaopatrujący kilku partnerów biznesowych zazwyczaj otrzymują wytyczne EDI już na początku swojej relacji biznesowej. Mogą się one znacznie różnić w zależności od firmy, co również wymaga koordynacji poprzez mapowanie. Aby sprostać konkretnym potrzebom, można utworzyć mapowania specyficzne dla klienta. Na przykład EDITEL chętnie pomaga we wdrażaniu różnych typów komunikatów EDI, w tym ORDERS, ORDRSP, DESADV, RECADV, INVOIC, PRICAT itp. To samo dotyczy przeglądów jakości danych w celu wykrycia błędów w danych (np. przegląd GLN i GTIN, wiarygodność i kompletność danych itp.). Pozwala to uniknąć przesyłania lub importowania niedokładnych danych do systemów informatycznych.
Jeśli masz jakiekolwiek pytania dotyczące powyższych informacji, chętnie z Tobą porozmawiamy. Nie wahaj się skontaktować z moimi kolegami lub ze mną.
