SWO Finops

Automatyzacja raportowania w Microsoft Dynamics 365 Business Central/Navision: KSeF, JPK CIT (RPD) i ZSMOPL - praktyczny przewodnik

4 min czytania

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:

  1. KSeF

(Krajowy System e-Faktur – sprzedaż i zakupy), 2. JPK CIT z RPD

(w tym oznaczenia S.12.1–S.12.3), 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:

  1. Rozdzielenie kont

na KUP i NKUP oraz przeksięgowanie historii, lub 2. 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

  1. Typy dokumentów oraz rodzaje podmiotów zgodne z wymaganiami Ministerstwa Zdrowia.
  2. Do raportu trafiają wyłącznie

produkty lecznicze

, z pominięciem materiałów pośrednich i opakowaniowych.

P

obieranie wierszy do wysyłki

  1. Raport pobiera dane z dokumentów źródłowych do bufora wysyłki.
  2. Dane raportowane są

na poziomie serii producenta

– każda seria stanowi osobną pozycję.

Kolejka zleceń (Job Queue)

  1. Automatyczna wysyłka danych np.

raz dziennie w nocy

. 2. Tryb

ręczny

warto zachować w fazie testów i walidacji.

Walidacja i błędy

  1. 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.

Zobacz najnowsze artykuły