Dziennik

Dziennik to chronologiczny rejestr wszystkich zapisów księgowych spółki. Każda faktura, każda operacja bankowa i każda korekta trafia tutaj — z numerem pozycji, datą, opisem oraz co najmniej dwiema liniami po stronach Wn/Ma, które muszą się sumować do zera.

Po co to w Numify

Dziennik jest jednym z pięciu obowiązkowych elementów ksiąg rachunkowych (UoR, art. 13 ust. 1). Zawiera chronologiczne ujęcie zdarzeń w danym okresie sprawozdawczym — każdą operację gospodarczą spółki, niezależnie od tego, czy pochodzi z faktury zakupu, wpłaty na rachunku bankowym, czy z ręcznego zapisu polecenia księgowania (PK).

Dwa twarde wymagania UoR, które Numify egzekwuje automatycznie:

• Numeracja ciągła (UoR, art. 14 ust. 2) — każdy zapis dostaje automatycznie nadany entryNumber, unikalny w obrębie roku obrotowego. Numery nie mogą mieć luk.
• Podwójny zapis (UoR, art. 15 ust. 1) — suma debetów musi równać się sumie kredytów (Wn = Ma). Numify blokuje zapisanie niezbilansowanego zapisu.

Model danych

journal_entries (nagłówek zapisu) — kluczowe pola:

journal_lines (linie zapisu) — każda linia wskazuje konto i stronę:

Trzy źródła zapisów

1. Automatyczny z faktur (source = "auto_invoice")

Gdy użytkownik zweryfikuje transakcję pochodzącą z dokumentu (faktury zakupu, faktury sprzedaży), src/lib/services/auto-journal.ts15 ✓ tworzy zapis automatycznie na podstawie mapowania kategorii na konta (categoryAccountMappings).

Przykład — faktura zakupu materiałów biurowych 100,00 zł netto + 23 zł VAT = 123 zł brutto, kategoria office_supplies, mapowanie: Wn 400, Ma 202, VAT 221:

Suma Wn = 123,00, suma Ma = 123,00. Zapis powstaje z isPosted: true — faktura już przeszła weryfikację, więc trafia od razu do ksiąg.

Idempotencja: jeśli zapis dla danej transakcji już istnieje, funkcja zwraca null i nie tworzy duplikatu. To samo dotyczy transakcji nieuznanych (isRejected) oraz usuniętych (deletedAt != null).

2. Automatyczny z banku (source = "auto_bank")

Gdy wiersz wyciągu bankowego zostanie dopasowany (automatycznie lub ręcznie) do faktury, src/lib/services/payment-journal.ts tworzy zapis rozliczający rozrachunek — przykład dla zapłaty faktury sprzedaży 123,00 zł:

Szczegółowo opisane w kontach bankowych, łącznie z obsługą różnic kursowych i częściowych płatności.

3. Ręczny (source = "manual")

Niektóre zdarzenia nie mają dowodu w postaci faktury ani wiersza wyciągu i wymagają ręcznego zapisu PK (polecenie księgowania) — amortyzacja środków trwałych, korekty międzyokresowe, przeksięgowania na koniec miesiąca, rozliczenie wyniku finansowego.

Ekran /journal → przycisk „Nowy zapis" otwiera dialog, w którym wybierasz:

1. Datę operacji i opis (co najmniej 3 znaki).
2. Jedną lub więcej par linii Wn/Ma z wyborem konta z planu kont i kwotą w PLN.
3. Opcjonalnie — powiązanie z dokumentem lub transakcją (jeśli istnieje dowód).

Numify waliduje podwójny zapis przed zapisaniem: sum(debit) === sum(credit), w przeciwnym razie zapis nie zostanie utworzony. Zapis powstaje w stanie isPosted: false — musisz potwierdzić go przyciskiem „Zaksięguj", co ustawia postedAt i postedBy.

4. Bilans otwarcia (source = "opening_balance")

Zapis tworzony raz, podczas konfiguracji firmy — zob. bilans otwarcia.

Cykl życia zapisu: isPosted

Zapis przechodzi przez dwa stany:

1. Szkic (isPosted: false) — widoczny w /journal z badge'em „Szkic", ale nie wchodzi do obrotów księgi głównej, nie wpływa na zestawienie obrotów i sald ani na bilans/RZiS. Można go edytować lub usunąć.
2. Zaksięgowany (isPosted: true) — trafia do księgi głównej i wszystkich raportów. Od tej chwili obowiązuje zakaz modyfikacji z UoR, art. 23 ust. 1 — zmian dokonuje się wyłącznie przez zapis korygujący (storno).

Auto-zapisy z faktur i z banku powstają od razu jako isPosted: true, bo pochodzą z już zweryfikowanych dowodów. Zapisy ręczne wymagają wyraźnego „Zaksięguj".

Numeracja i ciągłość

entryNumber jest unikalny w parze (companyId, fiscalYear) — baza wymusza to przez uniqueIndex("journal_entries_number_idx"). Numery są przydzielane sekwencyjnie, bez luk.

Zestawienie obrotów dziennika za okres musi się zgadzać z obrotami zestawienia obrotów i sald kont księgi głównej (UoR, art. 14 ust. 1). Numify uzgadnia to automatycznie — obie liczby wynikają z tych samych journal_lines.

Storno (zapis korygujący)

Jeśli zaksięgowany zapis zawiera błąd, nie usuwa się go — wprowadza się zapis korygujący (storno czarne lub storno czerwone), który odwraca skutek oryginału. Pierwotny zapis pozostaje w dzienniku jako ślad rewizyjny.

Numify nie ma jeszcze dedykowanego przycisku „Storno" — rekomendowany workflow ręczny: utwórz nowy zapis ręczny z odwrotnymi stronami Wn/Ma, w opisie podaj numer korygowanego zapisu (np. „Storno PK nr 42 — błędna kategoria").

Szczegóły koncepcyjne — zob. koncepcje → storno (strona w przygotowaniu). Podstawa prawna: UoR, art. 25 ust. 1.

Filtry i wyszukiwanie

Górny pasek /journal pozwala filtrować:

• Rok obrotowy — zakres wynika z daty rejestracji spółki (registrationDate z KRS).
• Miesiąc — opcjonalnie; puste = cały rok.

Lista pokazuje maksymalnie 200 ostatnich zapisów. Klik w zapis otwiera szczegóły — wszystkie linie Wn/Ma z kwotami, powiązanie z dokumentem lub transakcją, oraz historię zmian stanu.

Gwarancje techniczne (z testów)

src/lib/services/auto-journal.ts15 ✓ pokrywa m.in. te scenariusze (plik auto-journal.test.ts):

• Wydatek netto + VAT → 3 linie (koszt Wn, VAT Wn, zobowiązanie Ma), suma Wn = suma Ma.
• Wydatek bez VAT → 2 linie (koszt Wn, zobowiązanie Ma) na kwotę netto.
• Przychód netto + VAT → 3 linie (należność Wn gross, przychód Ma net, VAT Ma).
• Reverse charge (WNT, usługi unijne) → dodatkowa para VAT należny/naliczony w tej samej kwocie.
• Idempotencja — powtórne wywołanie dla tej samej transakcji zwraca null, bez duplikatu.
• Transakcje nieuznane (isRejected) i usunięte (deletedAt) są pomijane.

Walidacja validateJournalBalance() jest wołana przed każdym zapisem — zapis niezbilansowany nie powstanie.

Ograniczenia

• Brak przycisku storno — korekta wymaga ręcznego zapisu (zob. sekcja powyżej). Zaplanowane jako osobna funkcja.
• Brak wielu dzienników częściowych — Numify prowadzi jeden dziennik chronologiczny; dzienniki częściowe (sprzedaży, zakupu, kasowy) z UoR, art. 14 ust. 3 nie są obecnie wymagane dla spółek o typowej skali działalności.
• Brak eksportu do CSV/PDF z poziomu /journal — dane są dostępne przez raporty i JPK_KR_PD (zob. eksporty, strona w przygotowaniu).

Powiązane ekrany

• Księga główna — ten sam zestaw zapisów, ale pogrupowany po kontach syntetycznych (ujęcie systematyczne z UoR, art. 15 ust. 1).
• Zestawienie obrotów i sald — podsumowanie, które musi uzgodnić się z obrotami dziennika.
• Dokumenty i transakcje — źródła zapisów automatycznych.
• Konta bankowe — źródło zapisów auto_bank.

Dowód z ksiąg w postępowaniu podatkowym

Zgodnie z Ord. Pod., art. 193 § 1, księgi podatkowe prowadzone rzetelnie i w sposób niewadliwy stanowią dowód tego, co z nich wynika. Wymagania UoR wobec dziennika (numeracja ciągła, podwójny zapis, ślad rewizyjny, osoba odpowiedzialna za zapis) to warunki „niewadliwości" z § 3 tego artykułu. Przestrzeganie ich — co Numify egzekwuje automatycznie — jest podstawą, na której dziennik zachowuje moc dowodową w razie kontroli.