Transakcje

Transakcje to środkowa warstwa księgowości w Numify — pomiędzy dokumentami (surowe dowody) a dziennikiem (chronologiczny rejestr zapisów). Każda transakcja to jedna operacja gospodarcza: przychód, koszt albo przelew.

Po co to w Numify

UoR, art. 20 ust. 1 wymaga, aby każde zdarzenie gospodarcze zostało wprowadzone do ksiąg jako zapis. Samo zapisanie dowodu (faktury) to jednak jeszcze nie zapis księgowy. Transakcja to pośredni byt:

1. Materializuje dane z dokumentu w postaci kwot, dat i stron operacji.
2. Przechowuje weryfikację (pole isVerified) — zabezpieczenie przed zaksięgowaniem niesprawdzonych danych.
3. Jest źródłem zapisu w dzienniku — po zweryfikowaniu Numify automatycznie tworzy proste i przejrzyste zapisy podwójne.

Typy transakcji

Typy mapują się na konkretne konta zespołów 4/7/2 według planu kont seedowanego w Numify (seed-accounts.ts).

Weryfikacja (isVerified)

Transakcje mają dwie fazy:

1. Utworzone, niezweryfikowane — pochodzą z AI-parsowanego dokumentu lub z formularza ręcznego. W UI pokazywane z badgem „niezweryfikowane". Nie trafiają jeszcze do dziennika.
2. Zweryfikowane — po kliknięciu „Zweryfikuj" (lub masowej weryfikacji z tabeli) transakcja:
   • jest oznaczona isVerified = true,
   • zostaje automatycznie zaksięgowana w dzienniku (zapis podwójny),
   • nie można już edytować jej kwot bez korekty (→ storno).

To rozbicie realizuje human-in-the-loop: AI proponuje, człowiek akceptuje, dopiero wtedy liczby są „prawdziwe" — i zgodne z wymogiem UoR, art. 23 ust. 2 pkt 5 („oznaczenie kont, których dotyczy" — świadomie wskazane przez użytkownika).

Automatyczne tworzenie zapisu w dzienniku

Po weryfikacji transakcji Numify buduje wielowierszowy zapis spełniający UoR, art. 23 ust. 2:

• data operacji gospodarczej,
• rodzaj i numer dowodu (z powiązanej faktury / dokumentu),
• opis,
• kwota i data zapisu,
• oznaczenie kont (wielo-wierszowe).

auto-journal.ts15 ✓

Zapis podwójny

Każdy zapis zaczyna się i kończy zerem — suma kwot debet = suma kwot kredyt. Numify zawsze generuje wszystkie niezbędne wiersze:

Faktura sprzedaży (przychód z VAT 23 %)

Faktura kosztowa (usługi obce, VAT 23 %)

Obsługa walut obcych

Transakcje w EUR / USD mają trzy reprezentacje kwoty:

• amountGross — w walucie oryginalnej (np. 100 EUR = 10 000 centów).
• amountGrossPln — przeliczone po kursie NBP z dnia poprzedzającego obowiązek podatkowy (zgodnie z UoR, art. 30 ust. 2).
• exchangeRate — użyty kurs, zapisany na transakcji dla audytu.

Różnice kursowe powstają dopiero przy zapłacie — obsługuje je moduł Konta bankowe.

Tabela i filtry

Tabela transakcji pozwala filtrować po:

• Typie (przychód / koszt / przelew),
• Statusie weryfikacji (zweryfikowane / niezweryfikowane),
• Statusie zapłaty (opłacone / nieopłacone),
• Zakresie dat,
• Wyszukiwarce (po opisie / kontrahencie).

Karty sumaryczne w górnej części ekranu pokazują przychody, koszty i saldo netto wyłącznie dla transakcji zweryfikowanych — niezweryfikowane liczone są osobno (zabezpieczenie przed pokazywaniem niespójnych agregatów przy niezweryfikowanych walutach).

Korekty (storno)

UoR, art. 25 ust. 1 pkt 2 zabrania usuwania zapisów w księgach po zamknięciu miesiąca. Dla korekty kwoty, konta lub daty transakcji zweryfikowanej nie edytuje się oryginału — zamiast tego:

1. Tworzy się transakcję korygującą (storno) o przeciwnym znaku kwot.
2. Oryginał pozostaje w historii; ma widoczny link do storna.
3. Efekt netto w księdze głównej się zeruje, a poprawna wartość dodaje się przez nową transakcję.

To główny mechanizm śladu rewizyjnego (→ art. 25 UoR).

Ograniczenia

1. Transakcja = jedno zdarzenie — nie modelujemy dziś skomplikowanych operacji wielostronnych (np. kompensaty trójstronnej) jako pojedynczej transakcji. Takie operacje wymagają kilku transakcji lub zapisu bezpośrednio w dzienniku.
2. Auto-journal pokrywa typowe przypadki — faktury VAT 23 / 8 / 5 / 0, WNT / WDT, odwrotne obciążenie, MPP. Nietypowe (np. import z kraju trzeciego z cłem, zakup środka trwałego z kosztami transportu) wymagają ręcznej korekty dekretacji.
3. Brak edycji zweryfikowanej transakcji — to cecha (zgodność z UoR, art. 25), nie bug. Jeśli pomyliłaś coś w zweryfikowanej transakcji, stwórz korektę.
4. Połączenie z kontami bankowymi — transakcja staje się „opłacona" dopiero po dopasowaniu wiersza wyciągu bankowego do niej (lub przez ręczną flagę w UI).

Rekomendowany workflow

1. Z przychodzącego dokumentu (parsing AI) → Numify tworzy niezweryfikowaną transakcję.
2. Otwórz ją, sprawdź kwoty, stawki VAT, kontrahenta i kategorię kosztu.
3. Popraw, jeśli AI pomyliło się w dekretacji — np. faktura za usługi obce klasyfikowana jako „zużycie materiałów".
4. Zweryfikuj — Numify tworzy zapis w dzienniku i aktualizuje księgę główną.
5. Przed wysłaniem JPK_V7M — użyj tabeli z filtrem „niezweryfikowane" i domknij pozostałe; JPK nie powinno obejmować niepełnych danych.
6. Dla korekt — zawsze przez storno, nigdy przez edycję oryginału.

Powiązane

• dokumenty — źródło transakcji przychodzących.
• faktury — źródło transakcji sprzedaży.
• konta bankowe — dopasowanie płatności do transakcji → status „opłacona".
• kontrahenci — każda transakcja ma przypisanego kontrahenta.
• UoR — dziennik.
• UoR — księga główna.
• UoR — ślad rewizyjny.