JPK_MAG(2) w SAP

JPK_MAG(2): zmiana zakresu, a nie wyłącznie formatu

Nowa struktura rozszerza zakres danych o elementy, których dotychczasowy JPK_MAG nie ujmował albo nie rozdzielał w sposób wymagany obecnie. Obejmuje to w szczególności odrębną sekcję przyjęć wewnętrznych (PW), rozbudowane ujęcie ruchów międzymagazynowych, dane dotyczące inwentaryzacji oraz obsługę czterech metod prowadzenia ewidencji zapasów przewidzianych w ustawie o rachunkowości. Do dokumentów związanych z fakturą dochodzi identyfikator KSeF.

Konsekwencją jest konieczność ponownej kwalifikacji zdarzeń. Ten sam typ ruchu SAP nie zawsze odpowiada jednej kategorii raportowej. Przykładowo przyjęcie może wynikać z zakupu, produkcji, przepakowania, zwrotu albo transferu. O przypisaniu do sekcji JPK powinien decydować udokumentowany zestaw reguł uwzględniający typ ruchu, referencję do dokumentu źródłowego, zakład, skład, kategorię zapasu oraz kontekst procesu.

Osobnej decyzji wymaga definicja magazynu raportowego. Magazyn w rozumieniu JPK nie musi odpowiadać jednemu budynkowi. Może być odwzorowany przez zakład, skład, kombinację tych jednostek, magazyn w drodze, zapas powierzony albo lokalizację ewidencyjną. Nadmierne rozdrobnienie zwiększy liczbę plików i ciężar obsługi kontroli; nadmierna agregacja może natomiast utrudnić wykazanie kompletności i zgodności z ewidencją źródłową.

Największe wyzwania w SAP ECC i S/4HANA

W SAP ECC dane potrzebne do JPK_MAG(2) są zwykle rozproszone między dokumentami materiałowymi, dostawami, fakturami logistycznymi i zapisami FI. W praktyce raport może wymagać odczytu danych z obszarów MM, SD i FI, a także z warstw WM lub EWM oraz rozwiązań zewnętrznych. Dokument magazynowy potwierdza ruch ilościowy, dokument SD lub zakupowy dostarcza kontekstu handlowego, a zapis FI – wartości i skutku księgowego. Brak stabilnego łańcucha referencji pomiędzy tymi obiektami prowadzi do różnic, których nie rozwiąże walidacja XSD.

Warstwy WM i EWM wymagają szczególnej uwagi, ponieważ ruch fizyczny w magazynie nie zawsze jest tożsamy z księgowaniem w Inventory Management. Transfer między miejscami składowania, zadanie magazynowe lub potwierdzenie operacji w EWM może nie tworzyć samodzielnego dokumentu materiałowego istotnego dla JPK. Projekt powinien zatem rozdzielić dane służące do wykazania zdarzenia podatkowo-księgowego od danych operacyjnych potrzebnych do jego wyjaśnienia.

Ryzyko jest wyższe w organizacjach przechodzących z ECC do S/4HANA. Konwersja techniczna, przebudowa procesów typu greenfield, zmiana struktury organizacyjnej lub równoległe utrzymywanie kilku instancji mogą przerwać historyczne powiązania. Wymagania JPK_MAG(2) powinny zostać włączone do projektu S/4HANA jako kryterium projektowe i testowe, a nie pozostawione do etapu wdrożenia lokalnego raportu.

MATDOC i ACDOCA: dwa źródła, jedno uzgodnienie

W S/4HANA centralnym źródłem dokumentów materiałowych jest MATDOC, który zastępuje klasyczny model oparty na tabelach nagłówkowych i pozycyjnych MKPF oraz MSEG. Zawiera informacje o ruchach materiałowych, w tym materiale, ilości, typie ruchu, zakładzie, składzie i danych wartościowych. Nie oznacza to jednak, że sam odczyt MATDOC zapewni kompletny JPK_MAG(2). Kontekst sprzedażowy, zakupowy, magazynowy i fakturowy nadal może wymagać połączeń z innymi obiektami aplikacyjnymi.

ACDOCA, czyli Universal Journal, skupia pozycje księgowe i controllingowe. Na potrzeby JPK pełni rolę źródła uzgodnienia wartości ruchów materiałowych z księgą główną. Kontrola powinna obejmować nie tylko zgodność sum, lecz także wyjaśnienie różnic wynikających z różnic kursowych, odchyleń cenowych, kosztów dodatkowych, Material Ledger, księgowań okresowych oraz momentu rozpoznania faktury. Uproszczenie modelu danych S/4HANA ogranicza część historycznych uzgodnień technicznych, ale nie eliminuje różnic wynikających z logiki biznesowej.

Dokumenty magazynowe a KSeF

JPK_MAG(2) zakłada wykorzystanie numeru KSeF do identyfikacji dokumentu magazynowego związanego z fakturą. Numer ten jest nadawany po przyjęciu faktury przez KSeF i nie jest tożsamy z numerem faktury nadanym przez wystawcę. W SAP może być przechowywany w standardowym rozszerzeniu, tabeli rozwiązania lokalnego, repozytorium integracyjnym albo systemie zewnętrznym. Model raportowy musi wskazywać jedno źródło referencyjne i reguły rozstrzygania konfliktów.

Powiązanie nie zawsze ma relację jeden do jednego. Jedna dostawa może być fakturowana częściowo, kilka przyjęć może zostać objętych jedną fakturą, a faktura może pojawić się po przyjęciu towaru. Dodatkowe warianty obejmują faktury zagraniczne poza KSeF, tryby offline i awaryjne, samofakturowanie, korekty oraz transakcje intercompany. Rozwiązanie powinno obsługiwać co najmniej trzy scenariusze: numer KSeF dostępny w chwili generowania, numer uzupełniony retrospektywnie oraz uzasadniony brak numeru.

Retrospektywne uzupełnienie powinno być automatyczne i audytowalne. Należy zachować datę pozyskania numeru KSeF, identyfikator dokumentu, regułę dopasowania oraz informację o źródle. Ręczne dopisywanie numerów dopiero na potrzeby kontroli zwiększa ryzyko błędnego przypisania i utrudnia wykazanie integralności danych.

Archiwizacja SAP a dostępność danych historycznych

Archiwizacja dokumentów materiałowych może uniemożliwić raportowi opartemu wyłącznie na tabelach bieżących odtworzenie żądanego okresu.

Dlatego analiza powinna obejmować sposób archiwizacji dokumentów materiałowych, dostępność danych historycznych oraz możliwość ich wykorzystania podczas generowania JPK MAG(2).

Dostępność danych w archiwum nie oznacza automatycznie, że istniejący generator JPK potrafi je odczytać i połączyć z aktywnymi dokumentami.

Analiza powinna objąć politykę retencji, obiekty archiwizacyjne, infostruktury, repozytoria zewnętrzne, harmonogramy usuwania oraz wpływ wcześniejszej migracji do S/4HANA. Trzeba również ustalić, czy możliwe jest zestawienie jednego okresu z danych aktywnych i archiwalnych bez utraty numeracji, referencji i sum kontrolnych. Test odtworzenia powinien obejmować najstarszy okres, którego organ może zażądać, a nie wyłącznie dane z roku bieżącego.

Metodyka przygotowania SAP na JPK_MAG(2)

Prace powinny rozpocząć się od koncepcji biznesowo-podatkowej, a dopiero później przejść do developmentu. Minimalny zakres projektu obejmuje:

• inwentaryzację magazynów raportowych – wskazanie zakładów, składów, magazynów wirtualnych, zapasów w drodze i lokalizacji ewidencyjnych oraz przypisanie metody prowadzenia ewidencji;
• mapping XSD – przypisanie każdego pola do źródła, reguły transformacji, właściciela danych i kontroli jakości;
• analizę luk danych – wskazanie danych nieprzechowywanych w SAP, niekompletnych, archiwalnych albo pozyskiwanych po czasie;
• mapowanie typów ruchów – kwalifikację standardowych i niestandardowych typów ruchu do PZ, PW, WZ, RW, MM i inwentaryzacji;
• uzgodnienia krzyżowe – porównanie ilości i wartości z MM, SD, FI, KSeF oraz innymi strukturami JPK;
• testy pełnowolumenowe – generowanie plików dla całego magazynu i realistycznego okresu, z uwzględnieniem archiwum i równoległego obciążenia systemu.

Macierz mapowania nie powinna ograniczać się do nazwy tabeli i pola. Dla każdego elementu XSD należy opisać warunek występowania, kardynalność, sposób obsługi wartości pustej, jednostkę miary, walutę, znak ilości lub wartości, logikę korekt oraz źródło zastępcze. Właściciel biznesowy powinien zatwierdzić znaczenie pola, a zespół IT – wykonalność i wydajność ekstrakcji.

Data gap analysis powinna rozróżniać brak techniczny od braku procesowego. Brak techniczny występuje, gdy informacja istnieje, lecz znajduje się w innym systemie lub archiwum. Brak procesowy oznacza, że organizacja nie tworzy wymaganego śladu, przykładowo prowadzi inwentaryzację w arkuszu bez trwałego powiązania z dokumentem SAP albo księguje materiały bez dokumentu magazynowego. Drugi przypadek może wymagać zmiany procedury, konfiguracji i odpowiedzialności, a nie tylko interfejsu.

Testy muszą wykraczać poza walidację techniczną XML. Plik zgodny z XSD może pozostawać niekompletny lub merytorycznie niespójny. Scenariusze powinny obejmować przyjęcia i wydania częściowe, zwroty, korekty, anulowania, ruchy intercompany, przepakowania, ujemne stany, różne jednostki miary, inwentaryzację poza SAP, opóźniony numer KSeF oraz okres obejmujący dane aktywne i zarchiwizowane.

Rekomendacje dla zespołów SAP

Zespół SAP powinien potraktować JPK_MAG(2) jako rozwiązanie przekrojowe, z jednym właścicielem architektury i uzgodnioną odpowiedzialnością konsultantów MM, SD, FI, WM/EWM, specjalistów integracyjnych, administratorów archiwizacji oraz developerów ABAP. Punkt wyjścia stanowi model danych i przepływ dokumentów, nie specyfikacja samego pliku XML.

• Utworzyć katalog źródeł i referencji – wskazać źródła dla każdej sekcji JPK, klucze łączenia dokumentów MM, SD i FI, relacje z WM/EWM, miejsce przechowywania numeru KSeF oraz źródła danych spoza SAP.
• Wydzielić reguły mapowania z kodu programu – typy ruchów, zakłady, składy, kategorie zapasu i wyjątki powinny być utrzymywane w wersjonowanej konfiguracji z datą obowiązywania i śladem zmian.
• Zaprojektować warstwę ekstrakcji dla ECC i S/4HANA – logika biznesowa raportu powinna pozostawać wspólna, natomiast adaptery źródłowe muszą uwzględniać różnice między MKPF/MSEG a MATDOC oraz sposób odczytu danych finansowych z ACDOCA.
• Objąć rozwiązaniem dane aktywne, historyczne i archiwalne – przed developmentem należy potwierdzić dostęp do obiektu MM_MATBEL, infostruktur, plików ADK, danych po migracji i ewentualnych replik. Raport powinien sygnalizować niepełny odczyt zamiast generować pozornie kompletny plik.
• Zbudować mechanizm uzupełniania numeru KSeF – proces powinien obsługiwać opóźnione pozyskanie numeru, relacje wiele-do-wielu, ponowne przetwarzanie oraz rejestr źródła i czasu aktualizacji.
• Wprowadzić kontrole techniczne i biznesowe – poza walidacją XSD potrzebne są sumy kontrolne, uzgodnienia ilości i wartości, wykrywanie brakujących referencji, duplikatów, nieobsłużonych typów ruchu i dokumentów bez kwalifikacji.
• Testować na wolumenie produkcyjnym – pomiary powinny obejmować ekstrakcję, odczyt archiwum, transformację, walidację i zapis plików dla najcięższego magazynu oraz realistycznego okresu. Należy określić limity czasu, pamięci, równoległości i bezpieczne okno uruchomienia.
• Włączyć JPK_MAG(2) do procesu zarządzania zmianą – nowe typy ruchów, rozszerzenia, interfejsy, reorganizacje zakładów i składów, projekty S/4HANA oraz zmiany retencji powinny podlegać ocenie wpływu na raportowanie przed transportem na produkcję.

Dla projektów transformacji S/4HANA wymagania JPK_MAG(2) powinny znaleźć się w backlogu rozwiązania, kryteriach akceptacji i testach regresji. W modelu brownfield należy zweryfikować zgodność istniejących mapowań po konwersji oraz dostęp do dokumentów historycznych. W modelu greenfield trzeba dodatkowo potwierdzić, że nowa struktura organizacyjna, typy ruchów, procesy inwentaryzacyjne i integracje KSeF tworzą ślad danych potrzebny do raportowania od pierwszego dnia produktywnego użycia systemu.

Zespół utrzymaniowy powinien dysponować runbookiem obejmującym uruchomienie raportu, monitorowanie błędów, ponowne przetwarzanie, kontrolę kompletności, eskalację oraz odtworzenie danych z archiwum. Próbny przebieg należy wykonywać cyklicznie, a także po zmianach konfiguracji, migracji, aktualizacji komponentów lokalizacyjnych lub modyfikacji polityki archiwizacji.

Wpływ na biznes i plan działania

Najpilniejszym zadaniem nie jest wybór generatora, lecz audyt gotowości danych i procesów. CFO lub główny księgowy powinien wyznaczyć właściciela raportowania, który połączy kompetencje podatkowe, księgowe, logistyczne i IT. Odpowiedzialność za samą konfigurację SAP nie zapewnia kompletności pliku, ponieważ decyzje dotyczące definicji magazynu, metod ewidencji, kwalifikacji ruchów i uzgodnień mają charakter biznesowy.

W pierwszej kolejności organizacja powinna: ustalić liczbę magazynów raportowych, potwierdzić źródła danych dla nowych sekcji, zweryfikować przechowywanie numerów KSeF, wykonać próbę odtworzenia okresu archiwalnego oraz przeprowadzić pełnowolumenowy przebieg raportu. Wyniki należy ująć w planie naprawczym powiązanym z harmonogramem KSeF i – jeżeli dotyczy – transformacją S/4HANA.

Gotowość operacyjna wymaga również procedury na wypadek wezwania: kanału odbioru żądania, zastępstw, sekwencji generowania i zatwierdzania plików, kontroli merytorycznych, zasad bezpiecznego przekazania oraz dokumentowania decyzji. Kontrolny przebieg należy wykonywać cyklicznie i po każdej istotnej zmianie procesów, konfiguracji, migracji lub polityki archiwizacji.

Zakres wymaganych działań zależy od architektury systemowej, sposobu prowadzenia ewidencji, modelu magazynowego oraz przebiegu procesów w danej organizacji. Każdy przypadek wymaga indywidualnej analizy prawnej, podatkowej, księgowej i technologicznej.