Wymiana danych Rekomendowane kanały

1. Opis ogólny 2. Rekomendowane kanały i formaty wymiany danych Systemy ERP Ogólnie Systemy ERP Dystrybucja Systemy ERP Produkcja Dane początkowe (wdrożenie) E-commerce. Sklepy i portale internetowe Biura rachunkowe Urzędy i instytucje państwowe Portale usługowe Programy raportujące Korespondencja 3. Zasady wymiany dokumentów z systemami zewnętrznymi 4. Tematy powiązane

1. Opis ogólny

Dane programu Trawers można wymieniać z innymi programami wykorzystując różne formaty danych: * pliki CSV (format tekstowy) Wymiana plików CSV * pliki JSON JavaScript Object Notation Format tekstowy, bazujący na podzbiorze języka JavaScript. * pliki EDI (format xml) Dokumenty EDI * funkcje SOA (API) (format xml) SOA Funkcje SOA * pliki JPK (format xml) JPK Jednolity Plik Kontrolny Formaty plikow wymiany Wysyłać dane (eksport) do innych programów można w dowolnym czasie, podczas użytkowania programu Trawers. Funkcje pobierające dane (import) przeznaczone są przede wszystkim do pobierania danych przed rozpoczęciem użytkowania, tzn. do pobierania danych początkowych. Wiele funkcji pobierających można używać także podczas użytkowania programu, np. do uzupełnienia bazy klientów, pobrania cenników dostawców, zamówień i faktur sprzedaży. Wymiana plików CSV SOA Funkcje

Ogólny model wymiany danych

Pobieranie (import)

Wysyłanie (eksport)

| | | v v v o--------o-------o------o------o Aplikacje | | | zewnętrzne | | | v v v Funkcje SOA Pliki CSV Wydruki PDF TXT (API) XML Dane dla Qlik EDI Dane dla Excel Wymiana danych z innymi programami

2. Rekomendowane kanały i formaty wymiany danych

Systemy ERP Ogólnie

* Dokumenty dla KG Księga Główna - Pobierać polecenia księgowania z pliku CSV * Polecenia przelewu - Wysyłać w formatach akceptowanych przez poszczególne banki * Wyciągi bankowe - Pobierać z pliku CSV * e-faktury, e-archiwum - Zapisywać w plikach PDF * Pliki załączników - Pobierać do katalogów wymiany \TrInOut\... * Dokumenty sprzedaży i zakupu - (w planach) Format: KSeF

Systemy ERP Dystrybucja

* Realizacja zamówień sprzedaży - Pobierać zam sprzedaży EDI [ORDER] Pobierać z plików CSV Pobierać funkcjami SOA (API) - Wysyłać potwierdzenie zam EDI [ORDRSP] - Wysyłać awizo dostawy EDI [DESADV] - Wysyłać fakturę sprzedaży EDI [INVOICE] * Realizacja zamówień zakupu - Wysyłać zam zakupu EDI [ORDER] Wysyłać funkcjami SOA (API) - Pobierać awizo dostawy EDI [DESADV] jako: [DA] Dostawa w ZO - Pobierać fakturę zakupu EDI [INVOICE] Pobierać funkcjami SOA (API) * Mobilne systemy sprzedaży - Wysyłać funkcjami SOA (API) - Pobierać funkcjami SOA (API) * Cenniki sprzedaży - Pobierać z plików CSV * Katalogi dostawców - Pobierać z plików CSV * Spis inwentaryzacyjny - Pobierać z plików CSV

Systemy ERP Produkcja

* Raportowanie operacji produkcyjnych - Pobierać funkcjami SOA (API) * Katalogi BOM i RO - Pobierać z plików CSV - Zapisywać w plikach CSV do archiwum * IoT - Pobierać funkcjami SOA (API) * ANSI/ISA-95 MES, HMI/SCADA, PLC - Pobierać funkcjami SOA (API)

Dane początkowe (wdrożenie)

* Katalogi KIM, kontrahenci, ... - Pobierać z plików CSV

E-commerce. Sklepy i portale internetowe

* Omnichannel - Pobierać funkcjami SOA (API) Pobierać pliki XML, CSV - Wysyłać funkcjami SOA (API) * B2B - Pobierać funkcjami SOA (API) Pobierać pliki XML, CSV - Wysyłać funkcjami SOA (API) * B2C - Pobierać funkcjami SOA (API) Pobierać pliki XML, CSV - Wysyłać funkcjami SOA (API) * Fulfillment, np. Amazon FBA - Pobierać funkcjami SOA (API) - Wysyłać funkcjami SOA (API) * Internetowe platformy handlowe - Pobierać funkcjami SOA (API) Pobierać pliki XML, CSV - Wysyłać funkcjami SOA (API)

Biura rachunkowe

* Dokumenty sprzedaży i zakupu - Wysyłać funkcjami SOA (API) - Wysyłać w plikach CSV - Wysyłać w plikach JPK_... - Wysyłać w plikach EDI - (w planach) Format: KSeF - Pobierać funkcjami SOA (API) - Pobierać w plikach EDI

Urzędy i instytucje państwowe

* JPK Jednolity Plik Kontrolny - Wysyłać w plikach JPK_... * PPK Pracownicze Plany Kapitałowe - Wysyłać w plikach PPK_... * e-deklaracje - Wysyłać w plikach XML

Portale usługowe

* GUS - Pobierać funkcjami usług internetowych (WebServices) * e-katalogi dostawców - Pobierać ??? TODO * NBP Kursy walut - Pobierać funkcjami usług internetowych (WebServices) * Biała lista - Pobierać funkcjami usług internetowych (WebServices)

Programy raportujące

* Wysyłać w formacie CSV - Zestawienia tabelaryczne

Korespondencja

* Poczta TrEmail - Wysyłać via serwery pocztowe - Pobierać via serwery pocztowe Komunikacja w Trawers

3. Zasady wymiany dokumentów z systemami zewnętrznymi

3.1 Uwaga ogólna

Zasada główna E-mail nie jest kanałem integracyjnym. E-mail dopuszczamy tylko jako kanał: człowiek <-> człowiek (informacyjny) a nie: system <-> system. Dozwolone kanały (w kolejności: od najlepszych) 1. API / SOA (online) - preferowane dla integracji bieżących, synchronizacji i pobierania danych/załączników. 2. SFTP/FTPS/HTTPS - preferowane, gdy partner wymaga transportu plików z potwierdzeniami i kontrolą dostępu. 3. Wymiana plikowa przez katalog wymiany Trawers (TrInOut + podkatalogi). Preferowane dla EDI/importów, gdy integrator działa 'po stronie serwera' lub przez bezpieczny udział sieciowy/VPN. 4. E-mail - tylko w wyjątkowych sytuacjach - opisanych niżej.

3.2 Rodzaje dokumentów. Kanały wymiany

A) Integracje systemowe Wymagany kanał: API/SOA lub SFTP/TrInOut. Miejsce plików w Trawers: TrInOut (opcjonalnie podkatalogi operatorów/systemów + rejestrowanie logów przetwarzania. Zakaz e-maili dla: * EDI (zamówienia, faktury, awiza, potwierdzenia), * JPK i pliki raportowe wymagające spójności wersji, * importy/eksporty masowe (CSV/XML/JSON), * dane wrażliwe/handlowe (cenniki, rabaty, listy kontrahentów, dane osobowe). B) Dokumenty 'dla człowieka' (e-mail dopuszczalny warunkowo) E-mail można dopuścić dla: * PDF-y 'do wglądu' (oferty, potwierdzenia zamówienia, zestawienia), * korespondencja obsługowa (prośby, uzgodnienia, reklamacje), * pojedyncze załączniki, które i tak będą ręcznie weryfikowane. Patrz dalej: Kiedy można wysyłać e-mailem C) Załączniki do dokumentów w Trawers * Miejsce dostarczenia pliku: TrInOut / SFTP / HTTPS. * Docelowe składowanie: katalogi xxZal (np. `mgZal`, `naZal`, `zoZal`). Zarządzane przez Trawers, nie przez użytkownika ręcznie.

3.3 Standardy folderów

1. Jeden wspólny katalog wymiany: `trtres/trInOut` 2. Wymagane podkatalogi (minimum): * `/IN` - pliki przychodzące do Trawers, * `/OUT` - pliki wychodzące z Trawers, * `/ARCH` - archiwum po przetworzeniu, * `/ERR` - pliki błędne + raport błędu. 3. Jeśli jest wielu operatorów/systemów: * albo podkatalogi operatorów, * albo podkatalogi systemów (np. NA, ZO, KB) Należy wybierać jeden model i konsekwentnie stosować.

3.4 Wymagania techniczne dla kanałów 'systemowych'

Dla API/SFTP/TrInOut: * Idempotencja: plik/komunikat musi mieć unikalny identyfikator (numer dokumentu + data + GUID). GUID Globally Unique Identifier, czyli globalnie unikatowy identyfikator. * Kontrola integralności: checksum (np. SHA-256) albo podpis (gdy wymagane). * Retry / ponawianie: automatyczne próby, ale bez dublowania (patrz idempotencja). * Logowanie i audyt: kto, kiedy, co wczytał/wysłał; statusy (OK/ERR) + przyczyna błędu. * Archiwizacja: plik źródłowy i wynik przetworzenia trzymamy min. X miesięcy (np. 12 lub wg polityki księgowej).

3.5 Kiedy e-mail jest dopuszczalny i na jakich zasadach

E-mail dopuszczamy tylko, jeśli spełnione są wszystkie warunki: 1. Dokument nie służy do automatycznego importu do Trawers. 2. Jest przeznaczony do ręcznego użycia (wgląd/akceptacja). 3. Format: PDF lub ZIP (nie treść w body). 4. Brak danych wysokiego ryzyka (np. pełne dane osobowe, numery kont, listy płac, bazy klientów) - tu preferowac szyfrowany kanał. 5. Do krytycznych załączników: dołączamy checksumę w treści maila albo w osobnym pliku `.sha256`. 6. Dla poufnych: S/MIME/PGP lub link do bezpiecznego repozytorium (HTTPS z autoryzacją), a e-mail tylko jako powiadomienie. Wprost zakazane przez e-mail: * EDI, JPK, pliki importowe, * pliki, które mają być 'źródłem prawdy' w systemie, * dane wymagające ścisłego śladu audytowego i potwierdzeń.

3.6 Procedura awaryjna

Jeżeli kanał systemowy nie działa: 1. awaryjnie: SFTP/HTTPS (jeśli API nie działa), 2. awaryjnie: TrInOut przez bezpieczny udział/VPN, 3. e-mail tylko jako ostatnia deska ratunku i wyłącznie: * jako ZIP, * z checksumą, * z ręcznym potwierdzeniem odbioru i ręcznym wczytaniem, * z późniejszym odtworzeniem 'normalnej ścieżki' i uzupełnieniem logów (notatka serwisowa). Podsumowanie Do wymiany systemowej (EDI/JPK/importy) używamy API/SOA, SFTP/HTTPS lub katalogu TrInOut. E-mail nie jest kanałem integracyjnym i nie służy do automatycznego przetwarzania dokumentów. E-mail dopuszczamy tylko dla dokumentów informacyjnych (PDF/ZIP) przeznaczonych do ręcznej obsługi, z kontrolą integralności dla ważnych plików.

4. Tematy powiązane

Wymiana plików CSV Pola plikow CSV Czytanie i zapisywanie plików CSV SOA Funkcje Dokumenty EDI Formaty plikow wymiany JPK Jednolity Plik Kontrolny Raportowanie automatyczne Komunikacja w Trawers Integracja z internetem. Rozwiązania Słowa kluczowe #Admin-WymianaDanych #Admin-Bezpieczeństwo #Admin-UrządzeniaWyjściowe (AsystentAI) Wymiana dokumentów. Wady kanału: e-mail 1. E-mail może trafić do spamu Nawet poprawnie skonfigurowane domeny potrafią mieć chwilowe problemy z komunikacją. Dla integracji to oznacza: brak pliku na czas, brak gwarancji SLA, opóźnienia, ciche odrzucenia. 2. Program pocztowy może zniekształcić treść dokumentu To zależy od formatu, ale ryzyko istnieje. * Największe problemy są przy treści wklejanej w body (formatowanie, łamanie linii, kodowanie znaków, zamiana znaków końca linii, itp.). * Przy załącznikach binarnych (PDF, ZIP, XML jako plik) jest zwykle bezpieczniej. Ale nadal zdarzają się problemy praktyczne: antywirus/antyspam potrafi 'rozpakować i przepakować', użytkownik może otworzyć i zapisać plik w innej stronie kodowej, a niektóre bramki mogą blokować określone rozszerzenia (np. `.txt`, `.xml`, `.zip`) albo modyfikować nagłówki. 3. Nie ma kontroli nad tym przez jakie serwery przechodzi korespondencja SMTP to 'store-and-forward' i po drodze mogą być serwery pośrednie (własne, odbiorcy, antyspam, relaye). Dla dokumentów wrażliwych to problem audytowy i bezpieczeństwa. 4. Serwery pośredniczące mogą szyfrować połączenia. Szyfrowanie w SMTP (STARTTLS) bywa oportunistyczne - jeśli druga strona nie wspiera TLS, wiadomość może przejść bez szyfrowania. Dodatkowe powody, dla których e-mail jest słabym kanałem integracyjnym * Brak deterministycznego potwierdzenia dostarczenia i przetworzenia (co innego 'doszło', co innego 'system wczytał i zaakceptował'). * Limity rozmiaru, kwarantanny załączników, blokady typów plików. * Trudniejsza automatyzacja i rozliczalność (wersjonowanie, powtarzalność, reprocessing, logowanie). * RODO / poufność - ryzyko błędnego adresata, forwardów, archiwizacji poza kontrolą. Co zamiast e-maila (w integracjach) Dla Trawers-owych integracji najstabilniejsze są: * wymiana plikowa przez katalog wymiany (np. TrInOut / podkatalogi) + kontrola poprawności, logi, retry, * SFTP/FTPS/HTTPS (jeśli partner technicznie może), * API/SOA (jeśli integracja ma być 'online'), * dla EDI czasem VAN/Platforma EDI. Jeśli e-mail musi zostać Jeśli z jakiegoś powodu partner upiera się przy mailu: * wysyłać zawsze jako załącznik (najlepiej ZIP), nie w treści, * dołączać checksumę (SHA-256) / kontrolną sumę i weryfikować po stronie odbiorcy, * rozważyć podpis (S/MIME/PGP) i/lub szyfrowanie E2E, * pilnować poprawnej konfiguracji domeny (SPF/DKIM/DMARC), ale to poprawia głównie dostarczalność, nie kontrolę procesu.