EDI, KSeF i bezpieczeństwo danych – jak ogarnąć to mądrze, a nie na skróty? – podcast „Prosto o cyfryzacji”

Jak firmy radzą sobie dziś z wymianą danych, integracją systemów i nadchodzącymi zmianami regulacyjnymi? W rozmowie z Adamem Świerszczem z firmy Infinite rozkładamy na czynniki pierwsze EDI – jego praktyczne zastosowanie, bezpieczeństwo danych oraz przygotowanie organizacji na KSeF i e-faktury. Rozmawiamy konkretnie, bez pustych haseł.

Jak wygląda integracja w praktyce?
Co realnie zyskuje biznes?
Dlaczego porządek w danych staje się kluczowy w cyfryzacji procesów?

Zapraszamy do odsłuchu!

O rozmówcy:

Adam Świerszcz, Business Development Manager, Infinite IT Solutions – od 21 lat pomaga firmom komunikować się szybciej i efektywniej. Ekspert w budowaniu relacji B2B, który w swojej karierze łączył światy IT, Telecom i FMCG. Nie tylko sprzedaje rozwiązania, ale projektuje procesy, które usprawniają wymianę danych i obieg informacji u klientów – od mikroprzedsiębiorstw po globalne koncerny.

Zbigniew Rusinek, menedżer ds. wdrożeń branżowych, GS1 Polska: Cześć, witam Was serdecznie. Dzisiaj o tym, jak technologia ułatwia życie w biznesie. Porozmawiamy o EDI, czyli o tym, jak firmy przesyłają między sobą tysiące dokumentów bez użycia papieru, maili. Moim gościem dzisiaj jest nasz partner GOLD z firmy Infinity – Adam. Cześć, Adamie.

Adam Świerszcz, Business Development Manager, Infinite IT Solutions: Cześć, dzień dobry.

Dzisiaj w ogóle zaczynamy taki podcast, można powiedzieć, dedykowany specjalnie dla naszych partnerów, dlatego ten temat – myślę, że – też jest na czasie. W związku na przykład z KSeF, który wyszedł ostatniego czasu, właśnie pierwszego lutego. Więc… Adamie, może zacznijmy konkretnie od pierwszego pytania, czyli wiemy o tym, że na rynku mamy bardzo dużo różnych formatów, słyszymy o jakimś XML, EDIFACT. Jak to faktycznie wygląda? Czy narzucacie jakiś jeden standard, czy staracie się dostosować?

Nie, nie narzucamy żadnego formatu. To klient mówi, co ma. Bo tak naprawdę trzeba zwrócić uwagę, że jeżeli chodzi o komunikację elektroniczną EDI, bazujemy przede wszystkim na połączeniu między systemami. Więc to system ma już jakieś predefiniowane formaty albo format i na tym bazujemy.

Trzeba powiedzieć, że jeżeli chodzi o Polskę, polskich klientów, to przeważnie są to XML, czy to ECOD, czy też nasze, albo też EDIFACT. I to jakby są podstawowe grupy formatów. Wiadomo, między sobą różnią się jakimiś szczegółami i nasza rola polega na tym, aby dostosować się do tych wariantów, które są po stronie klientów.

A jeśli chodzi o architekturę… Jak to wygląda faktycznie od strony technicznej? Łączycie może się z klientem bezpośrednio, przez chmurę na przykład? Czy może używać jakichś innych specjalnych sieci?

To wszystko zależy od potrzeb, możliwości i oczekiwań kontrahenta. Najprostszym połączeniem jest nasz konektor, czyli to jest taki klient FTP, FTPS. Mocno rozbudowany, jeżeli chodzi o bezpieczeństwo, monitoring i zakres technologii, który tam jest oferowany.

Natomiast jeżeli klienci chcą czegoś innego, również mamy rozwiązanie SOAP API, REST API, możemy połączyć je poprzez X400, możemy się połączyć przez AS2. To klient w zależności od potrzeb, możliwości i oczekiwań określa zakres tego wdrożenia.

Wspomniałeś o bezpieczeństwie. Jak to wygląda? Czy faktycznie przesyłacie mnóstwo wrażliwych danych? Jaką mamy pewność, że są bezpieczne i nikt ich tam nie będzie podglądał? Jakie zabezpieczenia faktycznie stosujecie?

Wszystko zależy od tego, jaką technologię klient wybierze. Mówiąc generalnie, tu są zaimplementowane odpowiednie mechanizmy bezpieczeństwa, kryptografii, dostępów, klucze, podpisy elektroniczne etc. Wszystko wynika z technologii, którą klient u siebie wdrożył. Każda ma swoje plusy i minusy, ale każda w zakresie bezpieczeństwa ma określone jasne zasady.

Nie rekomenduję czystych FTP-ów albo mailowej wymiany dokumentów, chociaż też mamy i obsługujemy taką technologię. Myślę, że tutaj też klientom mówimy, jakie są zagrożenia w przypadku korzystania ze starszych rozwiązań i narzędzi, które w tym momencie nie odpowiadają już aktualnym potrzebom i wymaganiom.

OK, no to wróćmy teraz może do początku. Wspominałem, że mamy świeży temat, a mianowicie KSeF. Prawo się zmienia, wchodzi ten KSeF, unijne e-faktury. Jak dbacie o to, żeby Wasi klienci zawsze byli zgodni z tymi przepisami?

Wszystko zależy od tego, jakie klienci mają potrzeby i wymagania. Biorąc pod uwagę to, że w tym momencie my jesteśmy świeżo po uruchomieniu KSeF. Dane, które są przesyłane, to są przeważnie dane handlowe. Są zabezpieczone w odpowiedni sposób technologiami, które służą właśnie do tego, aby transmitować dokumenty, ale również zabezpieczyć dostęp, czyli odpowiednie polityki haseł, odpowiednie polityki dostępów etc.

Większość firm zwraca uwagę na taką ciągłość działania tych wszystkich systemów i tak się zastanawiam: może macie jakiś radar, który wyłapuje błędy? Jak wygląda pilnowanie, żeby system działał bez przerwy?

Jeżeli chodzi o sam monitoring, to przede wszystkim bazujemy na funkcjach walidujących. Mamy określone pewne grupy danych, które są wymagane albo też opcjonalne. W zależności od tego, przed przetworzeniem dokumentu sprawdzamy te dane i jeżeli występują jakieś odchylenia albo czegoś brakuje, wysyłamy te informacje do klienta. Raportujemy na maila lub plikami systemowymi: czego brakuje czy co należy poprawić, aby dokument poprawnie przetworzył się po naszej stronie.

Pomyłek niestety nie jesteśmy w stanie uniknąć. Czasami w dokumencie czegoś brakuje albo format jest nie taki. Co się faktycznie dzieje wtedy?

Wszystko zależy od tego, jakie ustalamy warunki walidacji. Standardowym modelem jest model, w którym jeżeli zakres danych nie odpowiada wymogom tego, czego oczekuje odbiorca dokumentu, to taki dokument zostaje zatrzymany po naszej stronie. Nadawca dokumentu ma pełną listę danych, które należy poprawić, z informacją, że np. jest to pozycja numer 10 na fakturze, brakuje kodu stawki VAT albo wartość podatku VAT jest źle wyliczona.

Mamy też indywidualne warunki walidacji, gdzie klient mówi: „OK, chcę wiedzieć”, „chcę monitorować tego typu dane”, „ale ja chcę otrzymać taką informację”. Więc wtedy zamiast raportów błędów wysyłamy tak zwane warningi do klientów, gdzie jest informacja: „przetworzyliśmy dokument, został wysyłany do klienta, ale w tych danych brakuje tego i tego” albo np. „są niepoprawne dane na takiej i takiej pozycji”.

No właśnie, bo ta pomoc techniczna jest bardzo ważna, o tym właśnie wspominasz. Jak coś się wydarzy, to jaki jest najszybszy sposób, żeby to naprawić?

Pytanie jest tak naprawdę, czy to my mamy to naprawiać. Jeżeli mówimy o dokumentach przychodzących, to przeważnie piłeczka jest po stronie wysyłających dokumenty. Przeważnie my za nich nie poprawiamy tych danych. Natomiast taka informacja o błędach jest przesyłana do nich na wskazane adresy. To jest najprostsze rozwiązanie i najszybsze – mailowe poinformowanie o błędnych dokumentach.

Mamy też rozwiązanie, gdzie jesteśmy w stanie wysyłać pliki np. w formacie XML bezpośrednio do ich systemu. Ich system, odbierając takie dane, jest w stanie zaadresować do odpowiednich użytkowników bądź też wykonać automatyczną korektę takiego dokumentu.

Najczęstsze pytanie klienta to jest „jak długo i za ile?”. O pieniądzach oczywiście dzisiaj nie będziemy rozmawiać, bo to już indywidualnie. Zastanawia mnie kwestia, ile czasu faktycznie potrzebujemy, żeby taki system zaimplementować.

Wszystko zależy od zakresu. Najprostsze i najczęstsze rozwiązanie to jest model, gdzie klient mówi: „OK, mam system, który ma możliwość importu, eksportu dokumentów. Chcę się połączyć z siecią taką czy inną”. I tu jest w miarę proste rozwiązanie. Instalujemy wspólnie, czy to naszego konektora, czy też zestawiamy API i ustawiamy parametry klienta, czyli wprowadzamy numery GLN, parametry techniczne połączeń, czy to jest, powiedzmy, lista dokumentów, zamówienia, faktury, awiza, dostawy etc. No i jesteśmy gotowi do testów, bo trzeba wziąć pod uwagę jedną rzecz.

Pierwszy etap, taki najprostszy, samo skonfigurowanie tych połączeń jest dość proste, ale potem przy testach mogą się pojawić naprawdę bardzo różne rzeczy. Zakładamy, że system ma możliwość importu, eksportu tego dokumentu, ale bardzo często okazuje się, że zostało wyeksportowane albo zaimportowane, ale nie mamy ustalonej kartoteki towarowej. Dokument importuje się do systemu, ale przy próbie zaczytania do bazy pojawia się lista błędów: tego towaru nie mamy, ten towar jest na innym kodzie, ten towar jest w ogóle inaczej pakowany, cena się nie zgadza itd.

Zostaje taki element biznesowy, który bardzo często jest poza nami. My jako operator nie wchodzimy w ustalenia biznesowe i nie powiemy: „wysłaliście cenę 10 zł, a powinno być 12, my to wam zmienimy”. Nie, tego nie zrobimy. Takie biznesowe podejście, biznesowe ustalenie parametrów jest poza nami. My jesteśmy od technikaliów. Pilnujemy, aby te dane były poprawnie wysyłane, aby te połączenia były poprawnie zestawione, natomiast nie wchodzimy w merytorykę dokumentu, który został wysłany.

Czyli rozumiem, że ten czas (wdrożenia) jest mocno uzależniony od zakresu.

Tak, zakresu, ale też dostępności. Trzeba wziąć pod uwagę jedną rzecz, że czasami jest tak, że jesteśmy gotowi, klient jest gotowy, ale kontrahent mówi:„mogę to zrobić za dwa miesiące, bo jest kolejka i idziemy w kolejce”. My jesteśmy tak naprawdę pomiędzy dwoma klientami. To, że jeden klient jest gotowy, nie znaczy, że drugi też.

Rozumiem, że czasami też klient ma jakieś nietypowe wymagania. Czy możesz przytoczyć jakieś takie dziwne sytuacje?

Bardzo częstym przypadkiem jest to, że w relacjach z zagranicznymi kontrahentami na fakturach trzeba wysyłać NIP z przedrostkami PL, czy do Niemiec z DE, jednej i drugiej strony. Bardzo często jest to dla klientów problem, dlatego że w polskich relacjach NIP jest wysyłany bez tych przedrostków. No i klient ma problem, no bo nie jest w stanie wysłać za granicę dokumentu z przedrostkami, a to jest pole wymagane, struktura taka jest wymagana. Wtedy my jesteśmy w stanie powiedzieć, że mamy takie funkcjonalności, które za ciebie w dokumentach wysyłanych są w stanie coś takiego dodać.

Albo na przykład przeliczanie czy dodawanie kodów produktów. Klient może wysłać tylko swoje kody produktów, albo tylko kod kreskowy, a odbiorca dokumentu chce też, żeby wysłał moje kody produktów. Bardzo często klient mówi, że nie ma miejsca: „nie chcę tych kodów po swojej stronie trzymać i pilnować, nie ma takiej możliwości”. Wtedy udostępniamy po naszej stronie funkcję translatora kodów i jesteśmy w stanie dopisywać, albo nawet i zmieniać, kody w zależności od informacji, które otrzymujemy od kontrahenta.

Poruszyłeś ciekawą rzecz, bo jak widzę, to macie dużo klientów, każdy ma jakieś swoje inne wymagania. Powiedz mi, jak to wygląda, jeśli chodzi o zarządzanie.

To się przede wszystkim skupia na formatach danych. Nawet patrząc na najpopularniejszy format w Polsce, czyli XML ECOD, on ma różne wersje i różne systemy mają też swoje indywidualne do tego podejście. Pewne rzeczy są w stanie wysłać, a czasami nie, mimo że należy to do specyfikacji. Po naszej stronie są klienci, którzy mają tak zwany standard i od tego zawsze wychodzimy. Jeżeli klient ma XML ECOD czy EDIFACT, to podłączamy, powiedzmy, standardową wersję.

W trakcie testu wychodzi, czy możemy się posługiwać standardem, czy standard wystarcza na to, abyśmy przeprowadzili pomyślne testy, czy trzeba zrobić indywidualny mapping na przykład.

Jeżeli trzeba zrobić indywidualny mapping, to też mamy dwie możliwości. Albo my już taki mapping mamy zrobiony dla jakiegoś tam innego projektu i wiemy, że wymaganie jest takie, bo to było robione już dla innego klienta, no to mamy jakby gotowy schemat. Jeżeli się okaże, że jest to za mało, to jesteśmy w stanie zrobić indywidualną kopię parsera czy kopię formatu plików i zrobić indywidualny do tego mapping.

Trzeba zwrócić uwagę na jedną rzecz. Zwłaszcza jeżeli mówimy o relacjach z kontrahentami zagranicznymi, bardzo często tak jest, że nawet jeden odbiorca ma różne wymagania dla różnych dostawców. Wynika to z biznesowego podejścia i wymagań, i obsługi takiego klienta. Więc tu jesteśmy w stanie indywidualnie zrobić dodatkowe mapowania, rozszerzyć czy wprowadzić jakieś algorytmy, które dodatkowo pewne rzeczy są w stanie same wyliczyć.

Faktycznie coraz częściej słyszymy o tym AI. Niektórzy twierdzą, że jeśli ktoś nie wdraża u siebie AI, to będzie się cofał, będzie przegrany – nawet tak mówią. Jak to widzisz, tę przyszłość, jeśli chodzi o wykorzystanie albo AI, albo blockchaina? Jakie zmiany?

Dobrze powiedziałeś – przyszłość. Wszyscy mówią, że AI będzie już zwalniał programistów, wdrożeniowców, że będzie to robił sam. No póki co tak to nie wygląda. Jednak biorąc pod uwagę nawet tę cechę konfabulacji AI, nie wygląda to tak, że można zastąpić czynnik ludzki. To nadal jeszcze jest i będzie.

Natomiast jak najbardziej posługujemy się AI. Jeżeli rozmawiamy o kwestii analiz dużej masy danych, porównanie czy analityka. Tak, tu AI jest naprawdę niezastąpiony i jest w stanie zrobić rzeczy, które ludziom zajmują po kilka dni. Jest w stanie w ciągu kilku minut to obejść.

Natomiast na chwilę obecną, biorąc pod uwagę mechanizmy, które są w AI, nie wygląda to w ten sposób, że zastąpi ludzi i kwestie konfiguracji. Właśnie ze względu na to, że jeżeli rozmawiamy o formatach klasy EDIFACT czy XML, to różni klienci mają różne potrzeby i wymagania wynikające z wersji systemu. Taką indywidualizację niestety, ale bardzo trudno jest wprowadzić w pewien schemat AI-owy.

Jak to widzisz z API na przykład?

I to jest bardzo fajna rzecz, bo – na przykład patrząc na Polskę – najczęściej to są właśnie te konektory FTP, FTPS. Ale za granicą, zwłaszcza jeżeli rozmawiamy o rynku Bliskiego Wschodu, tam w zasadzie większość jest oparta na API REST. To też ma swoje plusy i minusy, bo REST jest fajny, jeżeli sobie to już oprogramujemy. Naprawdę bardzo wiele rzeczy można z tego wyciągnąć.

Natomiast jeżeli rozmawiamy o prostocie, szybkim dostępie do danych i sprawnym monitoringu, to konektory FTP są przyjaźniejsze – czy może prostsze w obsłudze. Oba rozwiązania mają swoje plusy i minusy, co niesie za sobą konsekwencje dla konfiguracji systemu. Myślę, że z racji tego, że Polska póki co jest w połowie technologicznego wyścigu AI-owego, to właśnie te konektory wciąż u nas dominują.

Jeżeli mówimy o rynkach nowych, jak Bliski Wschód, to są to te nowocześniejsze rozwiązania. Jeżeli spojrzymy na przykład na rynek niemiecki czy francuski, tę Europę Zachodnią, to tam X400 trzyma się dobrze jeszcze i na tym bazują. Myślę nawet, że bardzo często zdają sobie sprawę, że jest to technologia sprzed ponad 50 lat (jak nie więcej), ale jest, działa i pojawia się opór przed zmianą technologiczną. Mamy jeszcze dużo wdrożeń w Europie Zachodniej na X400, co generuje nie tylko określone koszty, ale też wpływa na późniejszą obsługę. W razie jakichś problemów trudniej się je identyfikuje.

To pewnie zbieg okoliczności, bo standardy GS1 też są z nami od 50 lat.

Jeżeli patrzymy na formaty EDIFACT, to one ulegają rozwojowi. Jest potrzeba biznesowa, jest rozwój. Bazujemy na tym. I tu jest ten rozwój i trzymanie aktualizacji. Natomiast X400 – w tej technologii się niewiele zmieniło. To nie jest tak, że ona płynnie przejdzie do AS2, AS4 czy do API. Jakieś ustalenia były programowe X lat temu i to tak jest.

OK, to może przejdźmy do strategii, bo w każdej firmie strategia jest bardzo ważna. Co taka firma w określonym czasie realnie zyska? Chodzi tylko o brak tego papieru, czy coś więcej?

W EDI mamy schemat kija i marchewki. Pamiętam, jak zaczynałem pracę w tej firmie ponad 20 lat temu i EDI dopiero raczkował, a ludzie byli bardzo przeciwni tej technologii. To było coś nowego. Internet jeszcze wtedy to bardzo często był wdzwanianym połączeniem telefonicznym i firmy nie widziały potrzeby. To był taki wymysł narzucony przez sieć, który tak naprawdę wdrażamy tylko dlatego, bo sieć nam każe, a nie chcemy stracić tego kontraktu. Ale patrząc na cały ten czas, przez te dwadzieścia kilka lat, to jednak widać, że firmy się przekonały, bo weszła jedna, druga, trzecia sieć zagraniczna. A potem ten EDI został implementowany przez polskich dystrybutorów, polskie sieci i nagle się okazało, że liczba dokumentów wysyłanych przez EDI jest procentowo o wiele większa niż wysyłanych standardowo – papierowo, faksowo, mailowo.

I bardzo często mieliśmy też informacje, że mamy rynek nowoczesny – „a co wy na to, żeby w jakiś sposób nam uprościć ten rynek tradycyjny, który nie dorasta jeszcze do tego EDI”. Mamy narzędzia, które powodują, że ta dystrybucja zamówień czy faktur jest, możemy sobie połączyć rynek, czy też tradycyjny sposób wysyłania dokumentów, z dokumentami EDI. Bardzo często jest tak, że podłączaliśmy mniejszych dystrybutorów klientowi do takiego pół-EDI, jak bym to nazwał. A po 5-10 latach ten kontraktor mówi, że wdrożył sobie już ten EDI, przejdźmy wyżej. Pula tych klientów mało świadomych z biegiem czasu maleje i coraz więcej firm wdraża EDI, bo systemy też do tego dorosły. Kiedyś był problem z tymi ważnymi systemami, bo to było nowe i były dodatkowe funkcjonalności, dodatkowo płatne. W tym momencie moduł importu, eksportu jest standardem w większości systemów ERP w Polsce.

Podoba mi się to określenie pół-EDI.

Mamy takie rozwiązanie właśnie, na przykład zamówienia. Mamy marketplace na naszej stronie, gdzie kontrahent jest w stanie na stronie internetowej takie zamówienie stworzyć na podstawie oferty, która jest wystawiona. A to zamówienie jest zapisywane w naszej bazie i do klienta idzie jako EDI. Fakturę, która jest potem przez niego wysyłana, też wysyła w EDI. Byliśmy w stanie wysłać w PDF-ie do klienta, na przykład na maila, jeżeli była taka potrzeba. Klient, klikając sobie na linka do tej faktury, automatycznie potwierdzał, że ten dokument jest pobrany. Albo odbierał z naszej aplikacji, gdzie wchodził, miał listę tych dokumentów, wydrukował sobie albo zapisał ten dokument. A wystawca faktury miał potwierdzenie, że klient odebrał, kiedy ten dokument odebrał, czyli takie potwierdzenie dokumentu.

No to prawie na koniec takie sformułowanie, bo często niektórzy twierdzą, że EDI to jest np. PDF. To jest oczywiście błędne.

Też przetwarzamy PDF-y. Mamy narzędzia, które przetwarzają PDF, sczytują dane i są w stanie np. zamówienia na PDF zmienić na pliki EDI. I w drugą stronę tak samo. Też mamy narzędzia, które powodują, że ten pseudoelektroniczny dokument jesteśmy w stanie przetworzyć na ciąg danych, który jest w stanie przetworzyć system.

Wow, to przejście powinno być dużo prostsze. No dobra, Adamie, to ostatnie pytanie. Jak wygląda przyszłość dla polskich firm? Kolejne obowiązki, kolejne prawa? Czy może to jest jakaś szansa, żeby w końcu porządnie zautomatyzować ten biznes?

Mówisz o KSeF-ie?

Tak jest.

Przypomina mi to, co było dwadzieścia kilka lat temu, jeżeli chodzi o fakturę elektroniczną taką w EDI. Tam też klienci mówili: „po co nam to, są problemy”. Faktycznie, były problemy na początku. I po tych kilkudziesięciu latach firmy dorosły do tego i dla nich było normalne, że w ten sposób dokumenty są wysyłane.

KSeF jest zupełnie nowy. Trzeba wziąć pod uwagę też, że polski invoicing jest chyba najbardziej restrykcyjny w Europie. Chociaż na razie – ten pierwszy rok – jest to delikatnie potraktowane. Dla kontrahentów jest to fajna rzecz, tylko jest jedno „ale” – dane, które są wysyłane do KSeF. Ten minimalny zakres, który jest wysyłany i który trzeba wysłać, aby dokument został zatwierdzony, to jest naprawdę niezbędne minimum, które dla odbiorcy faktury nie jest zbyt fajnym zakresem. Dlatego że klienci, którzy weszli w EDI, przez te dwadzieścia kilka lat wprowadzili sobie warunki walidacji, warunki przetwarzania tego dokumentu na bardzo szerokim spektrum danych. Ten minimalny zakres, który jest do KSeF, to jest za mało. Wyobraź sobie jedną rzecz – numer zamówienia na fakturze. W EDI to jest podstawa, żeby połączyć fakturę, dokumenty pośrednie, zamówienia, wizę potwierdzenia zamówień w jeden ciąg i w bardzo prosty sposób zrobić kontroling tego, co jest na tych dokumentach. Numer zamówienia w KSeF można wysłać, ale nie jest polem obowiązkowym. Walidacja taka merytoryczna nie istnieje, więc jeżeli dostałeś zamówienie 123, wystawiłeś do niego fakturę, ale wpiszesz na fakturze 321, to też zostanie to zatwierdzone.

Kwestie GLN-ów, na których bazuje EDI. Możesz wysłać, ale jak nie wyślesz, to też się nic nie stanie. Więc mamy rozwiązanie, które łączy ten KSeF z EDI. Polega to na tym, że wysyłasz fakturę do KSeF, rejestrujesz ją, a potem wysyłasz fakturę EDI. I odbiorca takiej faktury, taka sieć handlowa, odbiera dokument z KSeF i odbiera fakturę z EDI, która jest o wiele bogatsza i tak naprawdę strukturalnie zrobiona pod możliwość przetwarzania tych dokumentów, tak jak do tej pory. Łączymy te dokumenty, żeby sprawdzić, czy faktycznie to jest ten sam dokument, żeby nie było takiej sytuacji, że faktura w KSeF jest na 100 zł, a w EDI na 200 zł.

Wtedy, jeżeli jest zgodność tych danych podstawowych, to my taki połączony dokument wysyłamy do klienta, tak żeby on sobie przetworzył. Bo ważne jest to, żeby został ten model przetwarzania dokumentów na tej samej pozycji. Patrząc dwadzieścia kilka lat temu, sieci zatrudniały po kilkanaście, kilkadziesiąt osób, które przetwarzały dokumenty papierowe. W tym momencie raczej nie chcieliby wrócić do tego schematu, że znowu zatrudnią X ludzi, którzy będą te faktury z KSeF pobierali i wyjaśniali problemy i niezgodności na tych fakturach. No bo niestety żaden AI, póki co, nie będzie w stanie w odpowiedni sposób faktury z taką ilością danych, które można wysłać minimalnie, wysłać. Bo wyobraź sobie jedną rzecz: jednostka miary – PCS (piece), czy tam „szt.” i ustawisz sobie w EDI. Ale w fakturze do KSeF możesz sobie napisać „sztuka” przez „ó”, wyślesz ten dokument i teraz będzie dobry.

Dobra, to myślę, że tym akcentem możemy skończyć na dziś ten odcinek. Jak widać, EDI to nie tylko techniczne skróty, ale przede wszystkim taki święty spokój też dla firm, ogromne oszczędności czasu. Bardzo dziękuję Ci za wyjaśnienie tym przystępnym sposobem. Moim gościem był Adam Świerszcz, Business Development Manager. Dziękuję Ci, Adamie.

Dziękuję bardzo.

No i ja oczywiście Państwa zachęcam do śledzenia naszych kolejnych podcastów. A jeśli chcecie dowiedzieć się więcej o rozwiązaniach, o których właśnie dziś mówiliśmy, zajrzyjcie koniecznie na stronę www.infinity.pl i dowiedzcie się więcej. To były moje pytania, które przygotowałem. Myślę, że na pewno będziecie mieć dużo więcej. Bardzo dziękuję i do usłyszenia.

Odsłuchaj odcinek

Chcesz dowiedzieć się więcej o EDI?

Rozpocznij nasz kurs!

Zobacz inne odcinki podcastu „Prosto o cyfryzacji”:

Chcesz dowiedzieć się więcej o EDI?

Podobne artykuły