1. Wprowadzenie
2. Integracja Trawers ERP z KSeF i EDI
3. Wysyłanie faktur sprzedaży KSeF
4. Miejsce pośredników EDI
5. Odbiór faktury zakupu KSef i EDI
6. Synchronizacja: faktury zakupu KSeF i EDI
7. Faktury zakupu - firmy handlowe
8. Faktury zakupu - firmy produkcyjne
9. Kojarzenie: EDI DESADV i EDI INVOICE
10. Tematy powiązane
1. Wprowadzenie
Komunikaty EDI, takie jak ORDER, nie zostaną objęte obowiązkiem przesyłania
przez KSeF - system ten dotyczy wyłącznie faktur.
EDI nadal będzie funkcjonować równolegle do KSeF.
- KSeF dotyczy wyłącznie faktur sprzedaży i zakupu.
- nie obejmuje innych dokumentów handlowych, takich jak zamówienia, potwierdzenia
dostawy czy komunikaty logistyczne.
Patrz też:
KSeF. EDI INVOICE a Faktury XMLCo z dokumentami EDI?
- Komunikaty EDI typu ORDER, DESADV, INVRPT itp. nie są częścią KSeF - pozostają
w gestii systemów ERP i platform EDI.
- EDI nadal będzie wykorzystywane do wymiany danych handlowych i logistycznych,
które nie są fakturami.
- Firmy będą musiały zintegrować swoje systemy ERP/EDI z KSeF, aby faktury
były przesyłane zgodnie z nowymi przepisami, ale pozostałe komunikaty będą
nadal przesyłane jak dotychczas - np. przez AS2, FTP, API czy e-mail.
2. Integracja Trawers ERP z KSeF i EDI
Integracja Trawers ERP z KSeF i EDI
- Trawers ERP będzie musiał:
- Wystawiać faktury sprzedaży w formacie ustrukturyzowanym XML zgodnym z KSeF.
- Odbierać faktury zakupu z KSeF, zamiast jako załączniki do e-maili.
- Utrzymać istniejące kanały EDI dla komunikatów innych niż faktury.
- Możliwa będzie równoległa obsługa KSeF i EDI, np. zamówienie przez EDI, faktura przez KSeF.
Ta sama faktura nie powinna być przesyłana jednocześnie przez KSeF i jako dokument EDI -
przynajmniej nie w pełnym zakresie, który był stosowany przed wdrożeniem KSeF.
Jak to wygląda w praktyce?
Od momentu obowiązkowego stosowania KSeF (2026):
- Faktura sprzedaży musi być wystawiona i przesłana przez KSeF - to jest jedyny prawnie
obowiązujący kanał dla faktur VAT.
- Klient odbiera fakturę z KSeF, a nie przez e-mail, PDF czy EDI
(chyba że jest zwolniony z obowiązku korzystania z KSeF - np. zagraniczny kontrahent).
Czy można nadal wysłać fakturę przez EDI?
- Nie jako fakturę VAT - nie można traktować faktury przesłanej przez EDI
jako dokumentu księgowego, jeśli została już przesłana przez KSeF.
- Można przesłać dane faktury w formacie EDI jako informację handlową -
np. dla systemów ERP klienta, które potrzebują danych do automatycznego księgowania,
ale musi być jasne, że to nie jest dokument księgowy.
- W praktyce firmy mogą:
- Wystawić fakturę w KSeF (XML).
- Przesłać równolegle dane faktury w formacie EDI, ale z adnotacją,
że dokumentem księgowym jest faktura z KSeF.
Co to oznacza dla Trawers ERP?
- Trawers ERP musi:
- Wystawiać faktury zgodne z KSeF.
- Przesyłać dane faktury do klienta tylko jako kopię informacyjną, jeśli klient tego wymaga.
- Upewnić się, że nie dochodzi do podwójnego obiegu faktur, który mógłby być niezgodny z przepisami.
3. Wysyłanie faktur sprzedaży KSeF
Kolejne kroki:
1. Wystawienie faktury sprzedaży w ERP
- Trawers ERP generuje fakturę sprzedaży w formacie zgodnym z KSeF (XML ustrukturyzowany).
- Faktura zawiera dane wymagane przez KSeF: m.in. NIP, daty, wartość netto/brutto, VAT,
dane kontrahenta, pozycje towarowe.
- Nie zawiera danych rozszerzonych, takich jak numery seryjne, lokalizacja magazynowa,
dane techniczne - te nie są częścią struktury KSeF.
2. Przesłanie faktury do KSeF
- Faktura jest przesyłana do KSeF przez API.
- Po przyjęciu przez system, KSeF nadaje unikalny numer KSeF, który służy jako identyfikator dokumentu.
- System ERP otrzymuje UPO (Urzędowe Poświadczenie Odbioru) - potwierdzenie,
że faktura została zarejestrowana.
3. Przesłanie danych faktury przez EDI (opcjonalnie)
- Jeśli klient wymaga danych rozszerzonych (np. numery seryjne, kody partii, dane logistyczne),
ERP może wygenerować komunikat EDI (np. INVOICE) zawierający te informacje.
- EDI nie zastępuje faktury z KSeF, ale może ją uzupełniać - np. przez dodanie numeru KSeF
w segmencie RFF z kwalifikatorem GN.
- Taki komunikat służy do automatyzacji procesów po stronie klienta, np. przyjęcia towaru,
rozliczenia dostawy.
4. Odbiór faktury przez klienta
- Klient odbiera fakturę z KSeF - to jest jedyny obowiązujący dokument księgowy.
- Dane z komunikatu EDI mogą być używane do celów operacyjnych, ale nie mają mocy dokumentu podatkowego.
Co to oznacza dla firm?
- Konieczna jest integracja ERP z KSeF - zarówno do wysyłania, jak i odbierania faktur.
- EDI pozostaje ważnym kanałem komunikacji, ale jego rola zmienia się - staje się uzupełnieniem,
a nie głównym nośnikiem faktury.
- Warto rozważyć automatyczne powiązanie faktury z KSeF z komunikatem EDI,
np. przez wspólny identyfikator.
4. Miejsce pośredników EDI
Rola i zadania pośredników EDI, np. Infinite
Pośrednicy EDI tacy jak Infinite dostosowują swoje procedury do KSeF - integrują się z systemem KSeF
i zmieniają sposób obsługi faktur, ale nadal będą przetwarzać inne dokumenty EDI jak zamówienia czy awiza dostawy.**
Jak pośrednicy EDI (np. Infinite) dostosowują się do KSeF?
(Według informacji z bloga Infinite:)
- Integracja z KSeF: Pośrednicy tacy jak Infinite wdrażają nowe moduły, które umożliwiają
przesyłanie faktur sprzedaży do KSeF oraz odbieranie faktur zakupu z KSeF.
Oznacza to, że faktura nie będzie już przesyłana bezpośrednio do klienta przez EDI, lecz przez KSeF.
- Zmiana roli faktury EDI: Faktura EDI nie będzie już dokumentem księgowym - stanie się
kopią informacyjną, zawierającą np. numery seryjne, dane logistyczne, które nie są częścią struktury KSeF.
- Nowe identyfikatory: Faktury będą oznaczane numerem KSeF (UUID), który może być dodawany
do komunikatów EDI (np. INVOIC) jako referencja, co pozwala klientowi powiązać dane z fakturą z KSeF.
- Utrzymanie pozostałych komunikatów EDI: Komunikaty takie jak ORDER, DESADV, REMADV, INVRPT
nadal będą przesyłane przez pośredników EDI - nie są objęte KSeF.
- Automatyzacja procesów: Pośrednicy rozwijają funkcje automatycznego pobierania faktur z KSeF
i ich integracji z systemami ERP klientów.
Co to oznacza dla firm korzystających z EDI?
- Nie trzeba rezygnować z pośredników EDI - ich rola się zmienia, ale nadal są potrzebni
do obsługi komunikatów handlowych i logistycznych.
- Firmy muszą zaktualizować swoje integracje - zarówno z pośrednikiem EDI, jak i z KSeF.
- Warto sprawdzić, czy pośrednik oferuje pełną obsługę KSeF - np. wysyłkę, odbiór,
archiwizację, walidację faktur.
5. Odbiór faktury zakupu KSef i EDI
Trawers ERP jako odbiorca faktury zakupu KSeF i odbiorca komunikatu EDI
Trawers ERP jako odbiorca faktur zakupu powinien mieć funkcje umożliwiające automatyczny
odbiór faktur z KSeF oraz równoległe przetwarzanie danych z komunikatów EDI - z uwzględnieniem
ich synchronizacji i walidacji.
Zestaw funkcji:
1. Integracja z KSeF - odbiór faktur zakupu
- Automatyczne pobieranie faktur z KSeF na podstawie tokenu autoryzacyjnego lub pełnomocnictwa.
- Walidacja struktury XML faktury KSeF - sprawdzenie poprawności danych, zgodności z wymaganiami MF.
- Dekretacja faktury - przypisanie do kont księgowych, kosztowych, projektów itp.
- Powiązanie z dokumentami magazynowymi - np. PZ, zamówieniami zakupu.
- Obsługa korekt i duplikatów - rozpoznawanie faktur korygujących i ich powiązanie z fakturami pierwotnymi.
2. Obsługa komunikatów EDI od pośrednika
- Import komunikatów EDI (np. INVOICE, DESADV) - zawierających dane rozszerzone,
np. numery seryjne, kody partii, lokalizacje magazynowe.
- Mapowanie danych EDI do struktur ERP - np. przypisanie numerów seryjnych do pozycji faktury
lub dokumentu magazynowego.
- Powiązanie komunikatu EDI z fakturą z KSeF - np. przez numer faktury, NIP, datę, wartość netto/brutto.
- Walidacja spójności danych - porównanie danych z KSeF i EDI, wykrywanie rozbieżności.
3. Mechanizmy synchronizacji i kontroli
- Automatyczne łączenie dokumentów z KSeF i EDI - np. przez reguły dopasowania lub identyfikator KSeF.
- Alerty o niezgodnościach - np. różnice w wartości VAT, brak pozycji, niezgodne numery partii.
- Raporty zgodności - zestawienia faktur z KSeF i danych z EDI, do celów audytowych.
4. Integracja z magazynem i logistyką
- Powiązanie danych z EDI z przyjęciem towaru (PZ) - np. automatyczne przypisanie numerów seryjnych.
- Obsługa awiz dostawy (DESADV) - umożliwiająca wcześniejsze przygotowanie magazynu na przyjęcie towaru.
- Zgodność z dokumentami wewnętrznymi - np. zamówieniami zakupu, planami dostaw.
5. Elastyczność i konfiguracja
- Możliwość wyboru źródła danych - np. traktowanie KSeF jako źródła księgowego, EDI jako źródła operacyjnego.
- Konfigurowalne reguły dopasowania - np. tolerancje wartości, dopasowanie po numerze zamówienia.
- Obsługa wielu pośredników EDI - np. Infinite, Comarch, Editel.
6. Synchronizacja: faktury zakupu KSeF i EDI
Mechanizmy synchronizacji i kontroli w systemie ERP takim jak Trawers,
w kontekście równoległego odbioru faktur z KSeF i komunikatów EDI,
mają kluczowe znaczenie dla zapewnienia spójności danych, zgodności z przepisami
i automatyzacji procesów.
Mechanizmy synchronizacji1. Dopasowanie dokumentów z różnych źródeł
- Identyfikacja faktury z KSeF i komunikatu EDI na podstawie:
- Numeru faktury
- NIP dostawcy
- Daty wystawienia
- Kwoty netto/brutto
- Opcjonalnie: numeru KSeF (UUID) w komunikacie EDI
2. Automatyczne łączenie danych
- Po zidentyfikowaniu zgodnych dokumentów system:
- Łączy dane z faktury KSeF (księgowe) z danymi z EDI (operacyjne)
- Tworzy pełny obraz transakcji: wartości + szczegóły techniczne (np. numery seryjne,
lokalizacja magazynowa)
3. Uzupełnianie danych ERP
- Dane z EDI mogą uzupełniać:
- Pozycje magazynowe (np. przypisanie numerów partii)
- Dokumenty przyjęcia (PZ)
- Zamówienia zakupu (np. potwierdzenie ilości)
Mechanizmy kontroli1. Walidacja spójności danych
- System porównuje dane z KSeF i EDI:
- Czy wartości netto/brutto są zgodne?
- Czy liczba pozycji się zgadza?
- Czy identyfikatory towarów są spójne?
2. Alerty i wyjątki
- W przypadku rozbieżności:
- System generuje alert dla użytkownika
- Możliwe scenariusze: różnice w VAT, brak pozycji, niezgodność dat
3. Raporty zgodności
- Zestawienia faktur z KSeF i komunikatów EDI:
- Status dopasowania
- Lista rozbieżności
- Historia synchronizacji
4. Audyt i śledzenie
- Logi operacji synchronizacji:
- Kiedy dokumenty zostały połączone
- Kto zatwierdził zgodność
- Jakie dane zostały uzupełnione
Dodatkowe funkcje wspierające synchronizację
| Funkcja | Opis |
|----------------------------------|----------------------------------------------------------------------|
| Reguły dopasowania | Konfigurowalne kryteria łączenia dokumentów |
| Tolerancje wartości | Możliwość ustawienia dopuszczalnych różnic (np. +-1 zł) |
| Integracja z pośrednikami EDI | Obsługa różnych formatów i źródeł danych |
| Obsługa korekt | Powiązanie faktur korygujących z dokumentami pierwotnymi |
| Harmonogram synchronizacji | Automatyczne cykle pobierania i porównywania dokumentów |
7. Faktury zakupu - firmy handlowe
Scenariusz dla branży handlowej, która często operuje dużą liczbą faktur zakupu i dokumentów logistycznych,
mechanizmy synchronizacji i kontroli w systemie ERP (np. Trawers) muszą być szczególnie precyzyjne,
skalowalne i zautomatyzowane. Oto jak powinny wyglądać:
Mechanizmy synchronizacji - branża handlowa1. Automatyczne dopasowanie faktur z KSeF i EDI
- System identyfikuje, że faktura z KSeF i komunikat EDI dotyczą tej samej dostawy.
- Kluczowe pola do dopasowania:
- Numer faktury
- NIP dostawcy
- Data wystawienia
- Wartość netto/brutto
- Numer zamówienia (jeśli występuje)
- Numer UUID z KSeF (jeśli przekazany w EDI)
2. Łączenie danych księgowych i operacyjnych
- Faktura z KSeF zawiera dane księgowe (VAT, kwoty, daty).
- Komunikat EDI (np. INVOICE, DESADV) zawiera dane operacyjne:
- Numery seryjne
- Kody partii
- Lokalizacje magazynowe
- Informacje o opakowaniach, paletach
- System ERP łączy te dane w jeden dokument transakcyjny.
3. Powiązanie z zamówieniem zakupu
- Faktura i komunikat EDI są dopasowywane do istniejącego zamówienia zakupu.
- System sprawdza zgodność ilości, cen, jednostek miary.
Mechanizmy kontroli - branża handlowa1. Walidacja spójności danych
- Porównanie danych z KSeF i EDI:
- Czy wartości netto/brutto są zgodne?
- Czy liczba pozycji się zgadza?
- Czy identyfikatory towarów są spójne?
- Czy dane z zamówienia pokrywają się z fakturą?
2. Alerty i wyjątki
- System generuje powiadomienia w przypadku:
- Różnic w kwotach
- Braku pozycji
- Niezgodnych numerów partii
- Braku dopasowania do zamówienia
3. Raporty zgodności
- Zestawienia:
- Faktura z KSeF vs komunikat EDI
- Faktura vs zamówienie
- Faktura vs przyjęcie magazynowe (PZ)
- Status: zgodna / wymaga interwencji / odrzucona
4. Audyt i śledzenie
- Historia synchronizacji:
- Kiedy dokumenty zostały połączone
- Kto zatwierdził zgodność
- Jakie dane zostały uzupełnione
Funkcje wspierające dla handlu
| Funkcja | Opis |
|----------------------------------|---------------------------------------------------------------------|
| Reguły dopasowania | Możliwość konfiguracji kryteriów łączenia dokumentów |
| Tolerancje wartości | Dopuszczalne różnice w kwotach (np. +-1 zł) |
| Obsługa korekt | Powiązanie faktur korygujących z pierwotnymi |
| Harmonogram synchronizacji | Automatyczne cykle pobierania i porównywania dokumentów |
| Integracja z pośrednikami EDI | Obsługa różnych formatów i źródeł danych |
| Powiązanie z magazynem | Automatyczne przypisanie danych EDI do dokumentów PZ |
Dzięki takim mechanizmom, firma handlowa może zautomatyzować obieg dokumentów,
zminimalizować błędy i zapewnić zgodność z KSeF oraz wymaganiami operacyjnymi.
8. Faktury zakupu - firmy produkcyjne
Dla branży produkcyjnej, mechanizmy synchronizacji i kontroli w systemie ERP - takim jak Trawers -
muszą uwzględniać nie tylko zgodność faktur z KSeF i EDI, ale także powiązanie z procesami produkcyjnymi,
materiałowymi i magazynowymi.
Mechanizmy synchronizacji - branża produkcyjna1. Dopasowanie faktur z KSeF i komunikatów EDI
- System ERP identyfikuje, że faktura z KSeF i komunikat EDI (np. INVOICE, DESADV)
dotyczą tej samej dostawy surowców, komponentów lub usług.
- Kluczowe pola do dopasowania:
- Numer faktury
- NIP dostawcy
- Data wystawienia
- Wartość netto/brutto
- Numer zamówienia produkcyjnego lub zakupu
- Numer UUID z KSeF (jeśli przekazany w EDI)
2. Łączenie danych księgowych i technicznych
- Faktura z KSeF zawiera dane księgowe.
- Komunikat EDI może zawierać:
- Numery partii i seryjne
- Specyfikacje techniczne materiałów
- Informacje o opakowaniach, jednostkach miary
- Harmonogram dostaw
- System ERP łączy te dane w jeden dokument transakcyjny, powiązany z produkcją.
3. Powiązanie z dokumentami produkcyjnymi
- Faktura i EDI są dopasowywane do:
- Zlecenia produkcyjnego
- Zamówienia zakupu surowców
- Dokumentów przyjęcia magazynowego (PZ)
- Dane z EDI mogą zasilać BOM (strukturę materiałową) lub rejestr materiałów.
Mechanizmy kontroli - branża produkcyjna1. Walidacja spójności danych
- Porównanie danych z KSeF i EDI:
- Czy wartości netto/brutto są zgodne?
- Czy ilości i jednostki miary się zgadzają?
- Czy numery partii odpowiadają specyfikacji produkcyjnej?
- Czy dostarczone materiały są zgodne z zamówieniem?
2. Alerty i wyjątki
- System generuje powiadomienia w przypadku:
- Różnic w cenach jednostkowych
- Braku pozycji lub nadmiaru
- Niezgodnych parametrów technicznych
- Opóźnień w dostawie względem harmonogramu produkcji
3. Raporty zgodności
- Zestawienia:
- Faktura z KSeF vs komunikat EDI
- Faktura vs zamówienie produkcyjne
- Faktura vs przyjęcie magazynowe
- Faktura vs BOM
4. Audyt i śledzenie
- Historia synchronizacji:
- Kiedy dokumenty zostały połączone
- Kto zatwierdził zgodność
- Jakie dane zostały uzupełnione lub odrzucone
Funkcje wspierające dla produkcji
| Funkcja | Opis |
|----------------------------------|----------------------------------------------------------------------|
| Reguły dopasowania | Konfigurowalne kryteria łączenia dokumentów |
| Tolerancje techniczne | Dopuszczalne różnice w parametrach materiałów |
| Obsługa korekt | Powiązanie faktur korygujących z pierwotnymi |
| Harmonogram synchronizacji | Automatyczne cykle pobierania i porównywania dokumentów |
| Integracja z pośrednikami EDI | Obsługa różnych formatów i źródeł danych |
| Powiązanie z BOM i produkcją | Automatyczne przypisanie materiałów do zleceń produkcyjnych |
| Obsługa awiz dostawy (DESADV) | Przygotowanie magazynu i produkcji na dostawę |
Dzięki takim mechanizmom firma produkcyjna może zapewnić pełną zgodność dokumentów z KSeF i EDI,
zminimalizować ryzyko błędów materiałowych, oraz zautomatyzować procesy od zakupu po produkcję.
9. Kojarzenie: EDI DESADV i EDI INVOICE
(AsystentAI)
Komentarz AsystentaAI do opisu procedury kojarzenia komunikatów EDI DESADV z fakturami EDI INVOICE w systemie Trawers.
Pytanie: Co się zmienia w procedurze kojarzenia DESADV (EDI) z INVOICE, gdy faktura pochodzi
z KSeF (Krajowego Systemu e-Faktur)?
Kluczowe różnice i zmiany w procedurze:1. Źródło faktury:
* W przypadku EDI faktura [FA] przychodzi do systemu jako komunikat INVOICE.
* W przypadku KSeF, faktura [FA] jest pobierana z platformy KSeF przez integrację z Trawers.
2. Brak komunikatu INVOICE w EDI:
* Gdy faktura trafia z KSeF, nie występuje już komunikat INVOICE EDI, więc proces
automatycznego kojarzenia [FA] <--> [DA] przez funkcję [ZO_DEDI3] nie zadziała tak samo.
3. Powiązanie z DESADV - konieczne działania:
Możliwe scenariusze:
* Scenariusz 1: Faktura KSeF zawiera numer dostawy (DespatchNumber / DANumer):
* Jeśli numer dostawy [DA] został zawarty w opisie faktury w KSeF
(np. jako numer referencyjny, w polu dodatkowym, w opisie), można go użyć do
ręcznego powiązania faktury z odpowiednim dokumentem [DA] - np. przez opcję
wyboru dostawy przy rejestracji dokumentu faktury.
* Wymaga to odpowiedniego rozpoznania i interpretacji danych z faktury KSeF - np. z nagłówka XML.
* Scenariusz 2: Faktura KSeF nie zawiera jednoznacznego powiązania z dostawą DESADV:
* Wtedy operator musi ręcznie przypisać fakturę do dostawy, bazując np.
na numerze SSCC (ze skanu) lub poprzez porównanie pozycji faktury i dostawy.
4. Jak w praktyce wygląda rejestracja faktury z KSeF:
* Faktura z KSeF trafia do ewidencji dokumentów zakupowych w Trawers.
* Podczas rejestracji można wybrać opcję: dostawa była wcześniej -> i wskazać dokument
[DA] dostawy (czyli analogicznie do metody ręcznej z EDI).
* Po wskazaniu [DA], system może dopasować pozycje i zweryfikować zgodność ilości/cen
(analogicznie jak w EDI).
Podsumowanie procedury w przypadku faktury z KSeF:
| Krok | EDI INVOICE | KSeF FA |
| ------------------------- | ------------------------------------------- | ------------------------------------------------ |
| Źródło faktury | Komunikat INVOICE EDI | Pobierana z systemu KSeF |
| Powiązanie z dostawą [DA] | Automatyczne przez ZO_DEDI3 | Ręczne lub półautomatyczne |
| Warunek dopasowania | Numer dostawy (DANumer) w INVOICE | Numer dostawy musi być widoczny w opisie faktury |
| Możliwość użycia SSCC | Tak | Tak (weryfikacja fizyczna dostawy) |
| Rejestracja w Trawers | EDI INVOICE tworzy [FA] oczekującą na match | Faktura z KSeF rejestrowana w ewidencji |
Rekomendacje dla obsługi faktur z KSeF przy DESADV:
1. Weryfikować, czy w fakturach z KSeF znajduje się numer dostawy (DespatchNumber).
* Można uzgodnić ze stałymi dostawcami, by umieszczali numer [DA] w polach referencyjnych.
2. Stosować SSCC przy skanowaniu paczek - pozwala szybko odszukać dokument dostawy [DA] w systemie,
do którego można przypisać fakturę.
3. Dostosować procedurę księgowania faktur KSeF tak, by operator miał możliwość wskazania
istniejącej dostawy [DA] - tak jak przy rejestracji ręcznej (opcja: Dostawa była wcześniej).
4. Rozważyć rozszerzenie importu KSeF o wyodrębnianie numeru dostawy, jeśli taki jest dostępny -
w celu ewentualnej automatyzacji kojarzenia.
***********************************************************************************************************************
Skoro obsługa faktur z KSeF wymaga często ręcznego lub półautomatycznego powiązania
z dokumentem dostawy DESADV, warto rozbudować profil dostawcy w Trawersie
o kilka dodatkowych informacji, które pomogą operatorom w prawidłowym i sprawnym
procesowaniu dokumentów zakupowych.
Propozycje dodatkowych informacji w profilu dostawcy (dla obsługi DESADV + KSeF)
| Pole / ustawienie | Opis i zastosowanie |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------- |
| Używa KSeF (TAK/NIE) | Flaga informująca, że faktury od dostawcy trafiają przez KSeF, nie EDI-INVOICE. |
| Powiązanie KSeF z DESADV (TAK/NIE) | Czy faktury z KSeF mają być kojarzone z dostawami [DA] tworzonymi wg EDI DESADV. |
| Pozycjonowanie numeru dostawy w FA KSeF | Określa, gdzie w fakturze KSeF można znaleźć numer dostawy (np. opis, pole referencyjne, uwagi, itd.). |
| Format numeru dostawy (regex / wzorzec) | Wzorzec (np. `D[0-9]{6}`), który pozwala automatycznie wyodrębniać numer dostawy z treści faktury KSeF. |
| Domyślny sposób kojarzenia FA z DA | Ustawienie, czy system ma próbować: 1) automatycznie wg numeru dostawy, 2) wg SSCC, 3) zawsze ręcznie. |
| Domyślny magazyn docelowy | Ułatwia przypisanie przyjęcia do właściwego magazynu, gdy nie jest jednoznaczne z dokumentu. |
| Domyślny dekret dokumentu [DA] | Pozwala z góry przypisać symbol dekretacji dla dokumentów dostawy od danego dostawcy. |
| Dostawca zaufany (TAK/NIE) | Flaga używana w kontroli jakości - np. wyłączenie wyrywkowej kontroli zawartości przesyłek. |
| Priorytet dopasowania FA-DA | Czy najpierw dopasowywać wg SSCC, DespatchNumber, czy innego identyfikatora. |
| Sposób powiadamiania o błędach dopasowania | Określenie, czy operator ma być powiadamiany komunikatem, mailem, alertem w systemie. |
Korzyści z dodania tych danych:
* Automatyzacja kojarzenia dokumentów w nowym modelu hybrydowym (DESADV z EDI + FA z KSeF),
* Mniej błędów i ręcznego dopasowywania,
* Lepsza kontrola jakości danych (np. oczekiwana struktura numerów),
* Ułatwienie obsługi nowych dostawców lub onboarding nowych integracji.
Technicznie - gdzie to można zaimplementować w Trawersie?
Najlepiej w zakładce ZO > Kartoteki > Dostawcy (lub gdzie konfigurowany jest profil EDI danego kontrahenta). Część z tych informacji może być realizowana jako:
* Pola w dodatkowej tabeli konfiguracyjnej (np. `ZO_DOSTAWCY_KSEF`),
* Rozszerzenia istniejącego profilu EDI (np. w strukturze `odediFD`, `odedif`),
* Słowniki pomocnicze (np. wzorce regex lub powiązane pola z dokumentu XML z KSeF).
**************************************************************************************************
Skoro komunikaty EDI (DESADV i INVOICE) pochodzą od pośrednika (np. Infinite),
to właśnie na etapie ich transformacji i przesyłania do Trawersa można najwięcej zyskać,
aby maksymalnie zautomatyzować proces kojarzenia dokumentów FA (faktura) i DA (dostawa).
CEL: Automatyczne kojarzenie FA i DA
Aby to osiągnąć, kluczowe jest jedno: obecność spójnego identyfikatora (DespatchNumber / DANumer)
w obu komunikatach oraz odpowiednia struktura danych.
Wymagania wobec pośrednika EDI (np. Infinite)
Oto konkretne wymagania, jakie warto postawić pośrednikowi EDI, aby umożliwić lub zwiększyć
skuteczność automatycznego kojarzenia:
1. Wymóg obecności `DespatchNumber` w FA (INVOICE)Opis:
* Numer dostawy (DespatchNumber z DESADV) musi być obecny w komunikacie INVOICE najlepiej w tym samym formacie, co w DESADV.
* W Trawersie numer ten trafia do pola `DANumer` i służy jako klucz do kojarzenia FA DA w funkcji `ZO_DEDI3`.
Forma w INVOICE:
* XML: element `<DespatchNumber>` albo `<OrderReference><OrderNumber>` (jeśli spełnia tę funkcję)
* EDIFACT: segment RFF+AAJ (referencja do numeru wysyłki)
Wymaganie:
Każdy komunikat INVOICE musi zawierać pole `DespatchNumber` odpowiadające numerowi w DESADV.
2. Spójność identyfikatorów i formatów w obu komunikatachOpis:
* DespatchNumber w FA musi być identyczny z tym z DESADV bez zmian formatu, prefixów, znaków specjalnych.
Wymaganie:
Pośrednik musi zapewnić, że numer dostawy (`DespatchNumber`) jest przekazywany do obu komunikatów bez modyfikacji.
3. Przekazywanie SSCC w obu komunikatach (opcjonalnie)Opis:
* Jeśli pośrednik może zapewnić numer SSCC w fakturze INVOICE (np. w atrybutach dodatkowych), może to służyć jako alternatywne powiązanie.
Wymaganie:
W przypadku używania SSCC, numer ten musi być jednolicie przekazywany w DESADV i INVOICE.
4. Spójna struktura pozycji (ilości, indeksy)Opis:
* Pozycje w INVOICE muszą pokrywać się z tymi z DESADV umożliwia to automatyczne kojarzenie nie tylko nagłówków, ale też pozycji.
Wymaganie:
Pozycje w INVOICE powinny zawierać identyfikatory zgodne z DESADV: indeksy, kody EAN, ilości, jednostki.
5. Separacja komunikatów FA i DA (jeśli potrzebne)Opis:
* Jeśli FA i DA są przesyłane razem (np. w jednym komunikacie), a Trawers ma ustawienie `odediFD = N`, to muszą zostać rozdzielone.
Wymaganie:
FA i DESADV mają być przesyłane jako oddzielne komunikaty, jeśli odbiorca wymaga ich oddzielnego przetwarzania.
6. Konfiguracja testowa i dokumentacja mapowaniaOpis:
* Pośrednik powinien udostępnić dokumentację mapowania pól i testowe komunikaty, by potwierdzić zgodność z wymaganiami systemu Trawers.
Wymaganie:
Pośrednik dostarcza dokumentację mapowania EDI oraz przykładowe pliki INVOICE i DESADV z prawidłowo uzupełnionym DespatchNumber.
Zalecane działania uzupełniające:
* Umowa integracyjna z pośrednikiem powinna zawierać te wymagania jako formalne punkty.
* Można też wprowadzić mechanizm walidacji w Trawersie, który loguje przypadki braku `DespatchNumber` w FA, by informować o błędach z wyprzedzeniem.
* Weryfikacja testowa przed wdrożeniem produkcyjnym nowego dostawcy.
**************************************************************************************
(AsystentAI)
Na podstawie przesłanego systemu znaczników Bazy Wiedzy Trawers ERP
przygotowałem dokument, który można bezpośrednio wkleić do bazy jako artykuł.
```
Wymagania integracyjne EDI: DESADV i INVOICECel opisu
Opisuje wymagania dla pośrednika EDI (np. Infinite), które umożliwiają automatyczne
powiązanie komunikatu INVOICE z komunikatem DESADV,
co pozwala skojarzyć fakturę zakupu (FA) z dostawą (DA) w systemie Trawers ERP.
Zakres
* Integracje EDI z użyciem komunikatów: DESADV (awizo dostawy) oraz INVOICE (faktura).
* Pośrednicy EDI pośredniczący w komunikacji między dostawcą a odbiorcą.
Wymagania1. Obecność numeru dostawy w komunikacie INVOICE
Komunikat INVOICE musi zawierać numer dostawy DespatchNumber,
identyczny z numerem z komunikatu DESADV.
* XML: pole <DespatchNumber>
* EDIFACT: segment RFF+AAJ (lub równoważny)
* Numer trafia do pola DANumer w dokumencie [FA]
Dzięki temu program Trawers może skojarzyć [FA] z oczekującą dostawą [DA].
2. Spójność formatu identyfikatorów
Numer dostawy musi być przekazywany w identycznym formacie w obu komunikatach.
* Niedopuszczalne: zmiany prefiksów, dodawanie znaków typu D-, DOST-
* Wymagane: bezpośrednia zgodność ciągu znaków
3. Przekazywanie numeru SSCC (opcjonalnie)
Jeśli komunikaty zawierają numer SSCC, to warto przekazać go zarówno w DESADV,
jak i w INVOICE.
* SSCC może być użyty jako alternatywny identyfikator do kojarzenia fizycznej przesyłki z dokumentem.
* W Trawers ERP operator może zeskanować SSCC z etykiety.
4. Spójność pozycji w DESADV i INVOICE
Pozycje w INVOICE muszą być zgodne z DESADV:
* Kod towaru (np. EAN, indeks, SKU)
* Ilość i jednostka
* Cena jednostkowa
Dzięki temu program może porównać dane i zrealizować kojarzenie pozycji.
5. Osobne przesyłanie komunikatów DESADV i INVOICE
Jeżeli klient (odbiorca) wymaga oddzielnego przetwarzania DESADV i INVOICE, pośrednik musi:
* Przesyłać oba komunikaty jako osobne pliki
* Nie łączyć ich w jednym komunikacie zagnieżdżonym
6. Dokumentacja i testy
Pośrednik EDI dostarcza:
* Mapowanie pól (DESADV <-> INVOICE <-> struktura Trawers)
* Przykładowe pliki INVOICE i DESADV z poprawnie uzupełnionym numerem dostawy
* Wsparcie przy testach integracyjnych
Podsumowanie
Spełnienie powyższych wymagań umożliwia automatyczne kojarzenie dokumentów [FA] i [DA]
w systemie Trawers ERP. To z kolei:
* Przyspiesza rejestrację faktur
* Ułatwia obsługę przyjęć magazynowych
* Zmniejsza liczbę błędów operatora
* Pozwala skuteczniej monitorować kompletność dostaw
```
PS: Ten format zapisu jest zgodny z systemem znaczników Bazy Wiedzy Trawers, w tym:
* główny nagłówek
* pogrubienie
* kursywa
* odnośniki do powiązanych artykułów
* nagłówki sekcji