Automatyzacja raportowania w Microsoft Dynamics 365 Business Central/Navision: KSeF, JPK CIT (RPD) i ZSMOPL - praktyczny przewodnik
Czytasz:
Automatyzacja raportowania w Microsoft Dynamics 365 BC/Navision: KSeF, JPK CIT (RPD) i ZSMOPL – praktyczny przewodnik
Na co dzień wdrażamy i konfigurujemy procesy raportowe oraz integracje w Microsoft Dynamics 365 Business Central (BC) i starszych wersjach Navision. Systemy te łączymy z aplikacją Hogart, co rozszerza możliwości raportowania i automatyzacji danych finansowych. W tym artykule pokazujemy, jak przy takiej integracji można przygotować i zautomatyzować trzy kluczowe obszary raportowe:
- KSeF (Krajowy System e-Faktur – sprzedaż i zakupy),
- JPK CIT z RPD (w tym oznaczenia S.12.1–S.12.3),
- ZSMOPL (Zintegrowany System Monitorowania Obrotu Produktami Leczniczymi).
Skupimy się na praktycznej konfiguracji, automatyzacji i najlepszych praktykach wdrożeniowych.
KSeF w Business Central/Navision - sprzedaż i zakupy end-to-end
Sprzedaż
Po zaksięgowaniu faktury sprzedaży w BC/Navision system może:
– automatycznie wysyłać dokument do KSeF i cyklicznie sprawdzać jego status,
– lub działać w trybie półautomatycznym, gdzie użytkownik ręcznie wywołuje aktualizację statusu.
Numer KSeF (KSeF ID) warto zapisywać w dodatkowym polu faktury i prezentować go również na liście dokumentów – znacznie ułatwia to kontrolę.
Zakupy
– Faktury zakupowe można importować z KSeF jako niezaksięgowane dokumenty.
– Reguły automatycznie przypisują wymiary (np. MPK lub dział kosztowy).
– Dla wyjątków można ustawić workflow, a do dokumentów dołączać PDF-y spoza KSeF.
Dobre praktyki:
- Dopasuj częstotliwość odpytywania o status faktur w KSeF do skali operacji.
- Zdefiniuj jasne reguły wymiarów i obsługi wyjątków.
- Włącz dziennik zmian i ogranicz edycję RPD do wybranych ról.
JPK CIT (RPD) - znaczniki S.12.1–S.12.3 i wirtualne konta
Plan kont i słowniki
Każde konto powinno mieć przypisane odpowiednie oznaczenie:
S.12.1, S.12.2, S.12.3, zgodnie z wytycznymi Ministerstwa Finansów.
Dodatkowo należy utrzymywać słowniki rachunku wyników i kategorii w zgodzie z aktualnymi strukturami MF.
Największe wyzwanie: S.12.3 (KUP/NKUP)
Niektóre konta, np. „reprezentacja i reklama”, obejmują zarówno KUP, jak i NKUP. Ponieważ MF wymaga jednoznacznego przypisania, można wybrać jedną z dwóch ścieżek:
- Rozdzielenie kont na KUP i NKUP oraz przeksięgowanie historii, lub
- Wirtualne konta – oparte na koncie syntetycznym i wymiarze (np. końcówka K dla KUP i NK dla NKUP).
W tym drugim przypadku przygotowuję raport obrotów po wirtualnych kontach, który sumuje transakcje wg wymiaru i dostarcza odpowiednie pozycje do JPK.
RPD - ręcznie czy automatycznie?
System może działać w dwóch trybach:
– ręcznym – dane wprowadzane i weryfikowane przez użytkownika,
– automatycznym – dane pobierane z ewidencji księgowej, z możliwością korekt przez osoby uprawnione.
W drugim wariancie kluczowe są rejestr zmian i kontrola uprawnień (np. edycja tylko dla głównej księgowej).
Eksport i archiwizacja
Po walidacji generowany jest plik XML JPK CIT/RPD, podpisywany certyfikatem i wysyłany do MF.
System powinien archiwizować statusy, pliki XML oraz historię wysyłek i obsługiwać wersjonowanie struktur XSD.
Dobre praktyki:
- Zacznij od oznaczeń S.12.1–S.12.2, a równolegle zaplanuj wdrożenie S.12.3.
- Jeśli nie chcesz cofać historii, zastosuj wirtualne konta i raport po wymiarach.
- Włącz dziennik zmian i ogranicz edycję RPD do wybranych ról.
ZSMOPL w Business Central/Navision - konfiguracja i automatyzacja
Obsługę ZSMOPL można oprzeć w całości na standardowym BC/Navision, bez konieczności stosowania dodatków branżowych. Kluczem jest właściwe odwzorowanie wymagań resortowych i poprawne mapowanie danych.
Co warto skonfigurować?
Słowniki i mapowania
- Typy dokumentów oraz rodzaje podmiotów zgodne z wymaganiami Ministerstwa Zdrowia.
- Do raportu trafiają wyłącznie produkty lecznicze, z pominięciem materiałów pośrednich i opakowaniowych.
Pobieranie wierszy do wysyłki
- Raport pobiera dane z dokumentów źródłowych do bufora wysyłki.
- Dane raportowane są na poziomie serii producenta – każda seria stanowi osobną pozycję.
Kolejka zleceń (Job Queue)
- Automatyczna wysyłka danych np. raz dziennie w nocy.
- Tryb ręczny warto zachować w fazie testów i walidacji.
Walidacja i błędy
- Testy na przykładach braków (np. brak daty ważności serii) pozwalają upewnić się, że system reaguje prawidłowo i wychwytuje błędy danych.
Dobre praktyki
- Zacznij od ręcznego eksportu próbki danych, zanim włączysz automatyzację.
- Włącz precyzyjne filtry, by raport obejmował wyłącznie produkty lecznicze.
- Testuj dokumenty z wieloma seriami i różnymi typami podmiotów.
Cheklista wdrożeniowa
KSeF
- Automatyczna wysyłka faktur sprzedaży i odpytywanie o status
- Import faktur zakupowych z przypisaniem wymiarów
- Pola KSeF w UI (lista i nagłówek)
- Workflow wyjątków i archiwizacja
JPK CIT/RPD
- Pola S.12.1–S.12.3 w planie kont + słowniki MF
- Decyzja: przeksięgowania czy wirtualne konta
- Raport obrotów po wirtualnych kontach
- Uprawnienia i rejestr zmian
- Eksport XML, podpis, archiwum, wersjonowanie XSD
ZSMOPL
- Słowniki i mapowania (dokumenty, podmioty, serie)
- Bufor wysyłki i Job Queue
- Scenariusze walidacji i błędów
- Testy i harmonogram automatyzacji
Podsumowanie
Dzięki integracji Business Central/Navision z aplikacją Hogart można skutecznie zautomatyzować procesy raportowe: od KSeF i JPK CIT po ZSMOPL. Najważniejsze jest konsekwentne utrzymanie słowników, mapowań i struktury danych oraz zaplanowanie automatyzacji krok po kroku: od testów ręcznych po harmonogramy w Job Queue.
Największym wyzwaniem pozostaje S.12.3 (KUP/NKUP) w JPK CIT, ale dobrze zaprojektowane wirtualne konta i raportowanie po wymiarach pozwalają zachować pełną zgodność z wymogami Ministerstwa Finansów.