Opublikowano propozycję modelu zdarzeń biznesowych i synchronizacji zmian dla e-faktur, stanowiącą kolejny krok w rozwoju API KSeF 2.0. Wskazano przy tym, że na tym etapie celem jest zebranie opinii od rynku. Po analizie zgłoszonych uwag zostanie zaproponowany ostateczny kierunek dalszych prac oraz zakres implementacji. Plany obejmują wypracowanie mechanizmu wymiany informacji o zmianach, tj. sposobu synchronizacji dokumentów oraz powiązanych z nimi zdarzeń biznesowych.
Model ten mógłby obejmować zarówno zdarzenia generowane w wyniku operacji wykonywanych na fakturze przez podmiot działający w dopuszczalnym kontekście, jak i inne zdarzenia biznesowe powiązane z fakturą.
Przykładowe scenariusze obejmują m.in. kwalifikację faktury, rejestrowanie zdarzeń płatniczych, dodawanie notatek i atrybutów biznesowych, oznaczanie pozycji faktury, zgłaszanie nadużyć, a także inne zdarzenia związane z obiegiem i obsługą faktury.
Na etapie koncepcji wyróżniono trzy podstawowe grupy zdarzeń:
- Zdarzenia widoczne dla wszystkich podmiotów powiązanych z fakturą, np.:
- utworzenie faktury.
- Zdarzenia widoczne wyłącznie dla podmiotu, który je wprowadził, np.:
- kwalifikację faktury wraz z opisem, np.:
- do zaksięgowania,
- wymaga wyjaśnienia,
- wyłączona z księgowania;
- opis faktury,
- zdarzenia dotyczące pozycji faktury wraz z opisem, np.:
- do zaksięgowania,
- wymaga wyjaśnienia,
- wyłączona z księgowania;
- opis pozycji,
- zgłoszenia dotyczące nadużycia, np.:
- próba wyłudzenia nienależnej zapłaty,
- faktura zawiera wyłącznie niechciane treści reklamowe,
- faktura zawiera podejrzane linki,
- masowa wysyłka faktur,
- podszywanie się pod zaufaną instytucję,
- inny powód.
- własne dane w postaci atrybutów, np. w modelu klucz–wartość.
- Zdarzenia widoczne dla podmiotów, który je wprowadził, oraz dla innego wskazanego podmiotu, np.:
- powiązanie faktury z identyfikatorem wewnętrznym nabywcy – zdarzenie opisujące przypisanie do faktury własnego identyfikatora wewnętrznego przez nabywcę.
Zapowiedziano, że każda zmiana dotycząca danych biznesowych faktury byłaby zapisywana jako osobne zdarzenie. Oznacza to, że zamiast nadpisywać jeden stan, system rejestrowałby kolejne zdarzenia opisujące dalszą obsługę faktury.
Każde zdarzenie powinno posiadać unikalny identyfikator oraz podstawowe metadane (np. datę utworzenia, autora), co umożliwia jego śledzenie oraz audyt.
Takie podejście umożliwiałoby aktualizowanie danych biznesowych faktury z zachowaniem historii zmian, zgodnie z rzeczywistym przebiegiem procesów biznesowych a aktualny stan faktury wynikałby z sekwencji zdarzeń – argumentuje Resort Finansów.
Link do propozycji zmian.
© Grafika jest własnością Kancelarii
Jeżeli ten problem Państwa dotyczy, zachęcamy do kontaktu z Kancelarią. Przesyłając wypełniony formularz akceptują Państwo naszą Politykę Prywatności.
