Faktury ustrukturyzowane i sygnały nadużyć: ontologia dla MŚP
Temat: Ontologia firmy
Model kontroli faktur prowadzi od dokumentu i stron transakcji do zamówienia, odbioru, płatności oraz udokumentowanego sygnału wymagającego sprawdzenia. To autorski, przykładowy model dla MŚP, a nie specyfikacja gotowa do wdrożenia w każdej firmie. Odpowiada na pytanie: Która faktura wymaga kontroli przed księgowaniem lub płatnością? Zawiera 12 encji i 13 nazwanych relacji. Przed użyciem trzeba uzgodnić definicje z właścicielami procesu i sprawdzić je na rzeczywistych rekordach.
Ten tekst należy do katalogu ontologii w filarze Ontologia firmy. Jeśli dopiero zaczynasz, przeczytaj jak odróżnić ontologię od taksonomii i modelu danych.
Zobacz model jako graf
Miniatura otwiera pełny graf, w którym można wybrać encję lub relację i odczytać jej znaczenie. Tabele poniżej zawierają tę samą informację w formie tekstowej.
Jaką decyzję pomaga podjąć ten model?
Firma otrzymuje fakturę za usługę. Numer dokumentu jest nowy, ale kwota i rachunek przypominają wcześniejszą fakturę. System oznacza potencjalny duplikat. Księgowa musi sprawdzić numer identyfikacyjny, stronę transakcji, zamówienie i dowód wykonania, zanim nada sprawie wynik.
Graf wskazuje dowody do kontroli i zachowuje decyzję wraz z uzasadnieniem; sam sygnał nie blokuje automatycznie wszystkich faktur od danego dostawcy. Granica modelu jest równie ważna jak jego zakres: Nie stwierdza oszustwa na podstawie automatycznego sygnału; decyzję o wstrzymaniu lub akceptacji podejmuje uprawniona osoba po weryfikacji.
Jakie pojęcia trzeba rozróżnić?
W tabeli każda encja ma własną definicję, klucz identyfikacyjny i przykładowe źródło. Nazwa rekordu w dwóch systemach nie dowodzi jeszcze, że chodzi o ten sam obiekt. Tożsamość trzeba potwierdzić kluczem lub świadomą regułą mapowania; status i prognozę należy datować.
| Encja | Znaczenie w tym modelu | Identyfikator | Przykładowe źródło |
|---|---|---|---|
| Faktura ustrukturyzowana | Dokument w strukturze używanej w KSeF. | numer KSeF i numer faktury | KSeF, system finansowy |
| Wystawca | Podmiot wystawiający dokument. | identyfikator podmiotu | rejestr kontrahentów |
| Nabywca | Podmiot wskazany jako kupujący. | identyfikator podmiotu | rejestr kontrahentów |
| Pozycja faktury | Przedmiot, ilość i kwota w dokumencie. | faktura i numer pozycji | system finansowy |
| Zamówienie | Potwierdzona podstawa zakupu. | numer zamówienia | system zakupowy |
| Odbiór | Potwierdzenie wykonania usługi lub przyjęcia towaru. | identyfikator odbioru | system zakupowy |
| Rachunek | Numer rachunku wskazany do płatności. | identyfikator rachunku | rejestr kontrahentów |
| Płatność | Potwierdzony przepływ środków. | identyfikator transakcji | system bankowy |
| Sygnał anomalii | Wykryta rozbieżność z regułą i czasem. | identyfikator sygnału | system kontroli |
| Reguła kontroli | Wersjonowany warunek wykrycia rozbieżności. | identyfikator i wersja | system kontroli |
| Weryfikacja | Udokumentowane sprawdzenie sygnału przez osobę. | identyfikator sprawy | system kontroli |
| Decyzja | Zatwierdzony wynik kontroli z uzasadnieniem. | identyfikator decyzji | system kontroli |
Faktura ustrukturyzowana jest dokumentem o określonej strukturze, numer KSeF identyfikatorem nadanym w systemie, a pozycja faktury elementem dokumentu. Sygnał anomalii oznacza wykrytą niespójność, weryfikacja opisuje pracę człowieka, a decyzja jej wynik. Podobna kwota nie jest dowodem duplikatu ani nadużycia.
Jak encje łączą się w graf biznesowy?
Krawędź ma kierunek, czasownik i znaczenie. Krotność w tabeli opisuje założenie tego modelu, które trzeba zweryfikować w konkretnej firmie. Gdy powiązanie ma własną kwotę, datę albo dowód, warto zachować je jako osobną encję zamiast ukrywać w atrybucie.
| Od | Relacja | Do | Krotność | Co potwierdza |
|---|---|---|---|---|
| Wystawca | wystawia | Faktura ustrukturyzowana | 1 : 0..n | Wskazuje stronę dokumentu. |
| Faktura ustrukturyzowana | jest dla | Nabywca | 0..n : 1 | Wskazuje nabywcę. |
| Faktura ustrukturyzowana | zawiera | Pozycja faktury | 1 : 1..n | Rozdziela kwoty. |
| Pozycja faktury | dotyczy | Zamówienie | 0..n : 0..n | Wskazuje podstawę zakupu. |
| Odbiór | potwierdza | Zamówienie | 0..n : 1 | Oddziela zamówienie od wykonania. |
| Wystawca | wskazuje | Rachunek | 0..n : 0..n | Wymaga potwierdzenia zmian. |
| Płatność | rozlicza | Faktura ustrukturyzowana | 0..n : 0..n | Umożliwia rozliczenia częściowe. |
| Płatność | trafia na | Rachunek | 0..n : 1 | Wskazuje rachunek docelowy. |
| Sygnał anomalii | dotyczy | Faktura ustrukturyzowana | 0..n : 1 | Nie przesądza nadużycia. |
| Sygnał anomalii | wynika z | Reguła kontroli | 0..n : 1 | Zachowuje wersję logiki. |
| Weryfikacja | sprawdza | Sygnał anomalii | 0..n : 1..n | Dokumentuje ludzką kontrolę. |
| Decyzja | kończy | Weryfikacja | 0..n : 1 | Wskazuje wynik z uzasadnieniem. |
| Decyzja | dopuszcza | Płatność | 0..n : 0..n | Wskazuje zakres zatwierdzonej wypłaty. |
Jak przejść po grafie w jednej sprawie?
Faktura F4 wskazuje wystawcę W2, nabywcę N1 i pozycję P7. Sygnał S3 powstał z porównania rachunku z rejestrem dostawcy. Zamówienie Z8 istnieje, lecz odbiór O5 ma mniejszą ilość. Weryfikacja V1 pyta właściciela zakupu o różnicę; decyzja D1 może dopuścić część płatności albo skierować sprawę do wyjaśnienia.
Przed uzyskaniem dokumentów nie wiadomo, czy rozbieżność jest błędem, zmianą umowy czy próbą nadużycia. Puste powiązanie ma pozostać widoczną luką. Model nie powinien dopowiadać relacji tylko dlatego, że rekordy mają podobne nazwy lub bliskie daty.
Jak połączyć dane i nie zgubić kontekstu?
Połącz dane faktur, zamówienia, odbiory, rejestr kontrahentów i płatności po identyfikatorach dokumentów oraz stron. Przechowuj wersję reguły wykrywania sygnału i źródło porównania. Dla każdego mapowania zapisz system źródłowy, lokalny identyfikator, czas aktualizacji i regułę, która połączyła rekordy. Sprzeczne dane powinny trafić do kolejki wyjaśnienia, a nie zostać po cichu nadpisane. Właściciel procesu zatwierdza znaczenie relacji, a właściciel systemu potwierdza sposób jej pobierania.
Dostęp do danych rachunków i sygnałów ogranicz do osób prowadzących kontrolę. Sygnałów nie publikuj jako listy winnych kontrahentów. Dostęp do połączonych danych musi odzwierciedlać cel pracy i uprawnienia. Sam fakt, że graf potrafi przejść między dwiema encjami, nie oznacza, że każda osoba może zobaczyć wszystkie atrybuty po obu stronach.
Jak sprawdzić pierwszy wycinek modelu?
Weź kilka prawdziwych, ale bezpiecznie udostępnionych spraw. Dla każdej ustal oczekiwaną ścieżkę i dokument, który potwierdza każdą krawędź. Na początek wystarczą poniższe próby:
- Podobna kwota nie wystarcza do uznania duplikatu.
- Brak odbioru wywołuje kontrolę, nie automatyczne oskarżenie.
- Zmiana rachunku dostawcy wymaga osobnego potwierdzenia.
- Decyzja zachowuje osobę, datę, dowody i wersję reguły.
Jeżeli dwie osoby inaczej interpretują ten sam węzeł lub relację, popraw definicję przed budową interfejsu. Przy niewielkiej liczbie stabilnych powiązań istniejąca baza i widok mogą wystarczyć. Graf pomaga rozmawiać o znaczeniu danych; nie naprawia automatycznie błędów w źródłach.
Co zrobić dalej?
Wybierz jedno pytanie operacyjne z początku tekstu i wskaż osobę, która potwierdzi znaczenie kluczowych pojęć. Następnie sprawdź pięć spraw w systemach źródłowych. Szerszą procedurę opisuje poradnik budowy ontologii firmy. Chronologicznie ostatni odcinek cyklu to Klient 360.
Źródła definicji zewnętrznych
- Ontologia
- Model danych
- MŚP
