1. Pole memo. Kronika obiegu
2. Przykładowe zdarzenia (czynności)
3. Skrzynki - przykłady
4. Przykładowe obiegi w formie kroniki
5. Propozycja 'minimalnego zestawu skrzynek'
6. Tematy powiązane
7. Możliwości rozbudowy WorkFlow (AsystentAI)
1. Pole memo. Kronika obiegu
1.1 Wprowadzenie
Skrótowo. Pole memo
Pole memo to dziennik zdarzeń faktury KSeF. Zawiera:
- komentarze operatorów,
- automatyczne wpisy systemowe - powiązanie z kontrahentem,
utworzenie nagłówka, przeniesienia między skrzynkami itp.
Każdy wpis jest dopisywany przyrostowo i ma oznaczenie:
- sygnatura autora (wg parametru 0307),
Param ogólne 01xx 02xx ... Wg numerów
- data i czas.
Ekran składa się z:
- górnej części - historia dotychczasowych wpisów (F5 - czytaj),
- dolnej części - dopisywanie nowego opisu (F6 - dopisz).
Funkcja pola memo w fakturze KSeF
Pole memo pełni rolę kroniki obiegu faktury KSeF.
Gromadzi wszystkie informacje dotyczące przetwarzania dokumentu, zarówno wpisy operatorów,
jak i automatyczne komunikaty systemowe.
Dzięki temu stanowi pełny, chronologiczny zapis historii faktury - od momentu pobrania z KSeF,
przez dekretację, aż po przekazywanie do kolejnych skrzynek lub działów.
1.2 Rodzaje wpisów
Wpisy operatorów
Operator może dopisywać własne komentarze, uwagi i notatki, np.
- dekretacja i MPK,
- miejsca powstawania kosztów,
- wyjaśnienia merytoryczne,
- informacja dla kolejnych osób w obiegu.
Każdy wpis operatora ma automatyczne oznaczenie:
- sygnatura autora (nazwa lub symbol operatora - zgodnie z parametrem 0307),
- data i czas dodania.
Wpisy automatyczne
System rejestruje kluczowe operacje wykonane na fakturze, m.in.:
- powiązanie z kontrahentem,
- utworzenie nagłówka,
- zapisanie zmian,
- przeniesienie faktury do innej skrzynki,
- inne czynności istotne dla śledzenia obiegu.
Wpisy automatyczne również zawierają sygnaturę i znacznik czasu.
Zasada przyrostowego dopisywania
Wszystkie wpisy są dopisywane przyrostowo, bez możliwości nadpisania wcześniejszych treści.
Pole memo stanowi więc pełną historię dokumentu, a nie tylko jego aktualny stan.
1.3 Układ ekranu
Ekran składa się z dwóch części:
1. Historia zdarzeń - górna część ekranu
Wyświetla wszystkie dotychczasowe wpisy.
Wpisy można przeglądać (`F5 - czytaj`).
2. Dopisywanie nowego wpisu - dolna część ekranu
Służy do wprowadzenia kolejnego opisu (`F6 - dopisz`).
Po zatwierdzeniu wpis trafia do historii wraz z sygnaturą i datą.
Przykład:
o-- Opis faktury 1111111111-20251211-0200A0BB5449-DA -----------------------[X]o
o------------------------------------------------------------------------------o
|**** Powiązał AA dnia 2026.01.19 Po o godz. 15:00 **** | <--- sygnatura autora wpisu
| Kontrahent: (ZO) 000001 Dostawca 1 PHU Wielobranżowy |
| |
|**** Utworzył nagłówek AA dnia 2026.01.19 Po o godz. 15:00**** | <--- sygnatura autora wpisu
1. | Nasz numer: FA FA0006/01/26 |
| |
|**** Zapisał AA dnia 2026.01.19 Po o godz. 15:00 **** | <--- sygnatura autora wpisu
| Faktura z delegacji do Warszawy, koszty paliwa. |
| |
|**** Przeniósł do [Księgowość] [Pobrane] AA dnia 2026.01.21 Śr o 12:28 | <--- sygnatura autora wpisu
| |
o------------------------------------------------------------------------------o
| |
2. | |
| |
o------------------------------------------------------------------------------o
| F4-drukuj, F5-czytaj, F6-dopisz |
o------------------------------------------------------------------------------o
2. Przykładowe zdarzenia (czynności)
2.1 Przykłady zapisów
----------------------------------------------------------------------------------
**** Przeniósł do [DH -WERYFIKACJA-] [Pobrane] Natalia Koach 2026.02.26 08:31:00
**** Przeniósł do [DH WARNO -REJESTR.-] [Pobrane] Anna Narach 2026.02.26 08:57:01
**** Powiązał Iwona Kuc 2026.02.26 09:46 ****
Kontrahent: (ZO) M20056 SONAKOL SP.J. NALDA
**** Utworzył nagłówek Iwona Kuc 2026.02.26 09:46 ****
Nasz numer: FA FA0040/02/26
**** Zapisał Iwona Kuc 2026.02.26 09:54 ****
Towar zgodny z zamówieniem
Towar mag 10 okres rozliczeniowy 2/2026
Bernia Michał/Marcek Marcin ID 12763
**** Przeniósł do [DH KSIĘGOWOŚĆ] [Pobrane] Iwona Kuc 2026.02.26 09:56 ****
**** Zapisał Natalia Koach 2026.02.26 10:59 ****
Sprawdzono pod wzgędem formalnym i rachunkowym
**** Przeniósł do [Zapisane] Natalia Koach 2026.02.26 11:04 ****
--------------------------------------------------------------------------------
Zapisy spełniają rolę 'kroniki obiegu' faktury: widać kolejne etapy,
kto wykonał czynność i kiedy, a także krótkie dopiski merytoryczne.
2.2 Interpretacja - krok po kroku
Przeniósł do [DH -WERYFIKACJA-] [Pobrane] (Natalia Koach, 08:31)
Faktura po pobraniu trafia do etapu weryfikacji.
Przeniósł do [DH WARNO -REJESTR.-] [Pobrane] (Anna Narach, 08:57)
Zmiana 'koszyka/etapu' na rejestrację (zachowany status 'Pobrane').
Powiązał (Iwona Kuc, 09:46)
Najpewniej powiązanie faktury z rekordem w systemie
(kontrahentem / dokumentem / zamówieniem)
Zaraz potem w logu pojawia się wskazanie kontrahenta.
Kontrahent: (ZO) M20056 SONAKOL SP.J. NALDA
Kontrahent w systemie ZO Zakupy, tu: Dostawca
Utworzył nagłówek (Iwona Kuc, 09:46)
Założenie dokumentu w Trawersie (nagłówek faktury).
Nasz numer: FA FA0040/02/26 Numer wewnętrzny nadany w systemie.
Zapisał (Iwona Kuc, 09:54)
Zapis:
Towar zgodny z zamówieniem
Towar mag 10 okres rozliczeniowy 2/2026
Bernia Michał/Marcek Marcin ID 12763
To są komentarze merytoryczne - zrozumiałe jako notatki/ustalenia
(magazyn, okres, osoby, identyfikator).
Przeniósł do [DH KSIĘGOWOŚĆ] [Pobrane] (Iwona Kuc, 09:56)
Przekazanie do księgowości.
Zapisał (Natalia Koach, 10:59) + komentarz
Sprawdzono pod względem formalnym i rachunkowym.
Czytelny krok kontroli.
Przeniósł do [Zapisane] (Natalia Koach, 11:04)
Zakończenie obiegu/ustawienie stanu końcowego.
2.3 Przydatność kroniki w polu: memo
Audyt i odpowiedzialność: widać kto i kiedy wykonał ruch/akcję (przeniesienie, zapis, powiązanie).
To ułatwia rozliczanie etapów i wyjaśnianie 'dlaczego faktura utknęła'.
Diagnostyka błędów i sporów: przy reklamacjach/rozbieżnościach (np. 'kto zatwierdził',
'czy była weryfikacja formalna') jest twardy ślad.
Zastępowalność pracowników: osoba przejmująca dokument szybko widzi, co już zrobiono i czego brakuje.
Kontrola terminów: łatwo policzyć czasy między etapami
(pobranie -> weryfikacja -> księgowość -> zapisane).
Spójność procesu: jeśli wpisy są standaryzowane, można wyłapać odstępstwa
(np. faktury idą do księgowości bez weryfikacji).
Podstawa pod automatyzację: ustandaryzowane wpisy można później wybierać
(raporty, alerty: '> 24h w weryfikacji', itp.).
2.4 Układ tabelaryczny
(użyć programów przetwarzających ciągi znaków, np. awk lub sed)
Przykład:
2026-02-26 08:31 | Natalia Koach | Przeniesienie | Skrzynka: DH - WERYFIKACJA | Folder: Pobrane
2026-02-26 08:57 | Anna Narach | Przeniesienie | Skrzynka: DH WARNO - REJESTR. | Folder: Pobrane
2026-02-26 09:46 | Iwona Kuc | Powiązanie | Moduł: ZO (zakupy) | Kontrahent/dostawca: M20056 SONAKOL SP.J. NALDA
2026-02-26 09:46 | Iwona Kuc | Utworzenie | ZO | Utworzono nagłówek faktury zakupu
2026-02-26 09:54 | Iwona Kuc | Zapis | ZO | Nr wew.: FA FA0040/02/26
2026-02-26 09:54 | Iwona Kuc | Notatka | - | Towar zgodny z zamówieniem.
2026-02-26 09:54 | Iwona Kuc | Notatka | - | MAG: 10, okres rozliczeniowy: 02/2026
2026-02-26 09:54 | Iwona Kuc | Notatka | - | Osoby: Bernia Michał / Marcek Marcin, ID: 12763
2026-02-26 09:56 | Iwona Kuc | Przeniesienie | Skrzynka: DH KSIĘGOWOŚĆ | Folder: Pobrane
2026-02-26 10:59 | Natalia Koach | Zapis | - | Sprawdzono formalnie i rachunkowo.
2026-02-26 11:04 | Natalia Koach | Przeniesienie | Folder: Zapisane | Zakończono obieg
Ocena przydatności kroniki w Panelu KSeF (ZO)
Na bazie tego obiegu (Pobrane -> weryfikacja -> rejestracja -> księgowość -> zapisane)
kronika daje szczególnie:
* dowód obiegu i kontroli: jest wpis 'Sprawdzono formalnie i rachunkowo' + kto i kiedy;
* ciąg zdarzeń: przeniesienia między skrzynkami/folderami działają jak 'routing' dokumentu;
* minimalizacja pytań 'kto to ma?': jedno spojrzenie mówi, gdzie faktura była i gdzie trafiła;
* łatwiejsze wyjaśnianie różnic w JPK: widać moment powiązania z kontrahentem i
(jeśli użyjecie funkcji g) powiązanie z fakturą ZO + zapis numeru KSeF;
* bezpieczeństwo operacyjne: widać kto wykonał 'Usuń' (jeśli dopiszecie to do kroniki)
i można szybciej wyłapać pomyłki.
Funkcje menu F2 - zapisy do kroniki
Na podstawie listy funkcji w zakładce (F2-menu) można dopisać 'mapę':
* Przenieś do innej skrzynki / Pobrane -> generuje wpisy typu:
Przeniósł do [skrzynka] [folder Pobrane]
* Przenieś do innego folderu -> wpisy typu: Przeniósł do [folder Zapisane]
* Opis (memo) faktury KSeF -> wpisy Notatka/Opis
System automatycznie dopisuje autora+czas
* Pobierz faktury z KSeF Odśwież
* Powiąż z fakturą ZO
3. Skrzynki - przykłady
Skrzynki KSEF to są miejsca wystawiania, odbierania i przechowywania faktur.
Poniżej przedstawiono przykłady skrzynek w firmach handlowych i serwisowych.
A. Skrzynki - Rdzeń procesu
* SER KSeF - NOWE
* SER KOORDYNATOR - WERYFIKACJA (czy dotyczy zlecenia serwisowego, czy właściwy oddział)
* SER TECHNICZNY - POTWIERDZENIE WYKONANIA (czy usługa wykonana, protokół)
* SER CZĘŚCI / MAGAZYN - WERYFIKACJA (części, zużycia, RW)
* SER KOSZTY - OPIS MPK / ZLECENIE (zlecenie serwisowe, klient, projekt)
* SER AKCEPTACJA - KIEROWNIK SERWISU
* SER KSIĘGOWOŚĆ - DEKRETACJA
* SER DO ZAPŁATY
* SER ZAMKNIĘTEB. Skrzynki - Wyjątki
* SER WYJAŚNIENIA -DOSTAWCA
* SER SPORNE - GWARANCJA (czy koszty gwarancyjne/niegwarancyjne)
* SER WSTRZYMANE (brak protokołu / spór z wykonaniem)
* SER BŁĘDY - DUPLIKATY
Można rozbudować w kierunku 'prawie-WorkFlow', ale trzeba rozdzielić dwie rzeczy:
1. Pole memo (kronika) jest dziś rejestrem zdarzeń - operator dopisuje komentarze,
a system dopisuje automatyczne wpisy (powiązanie kontrahenta, utworzenie nagłówka,
przeniesienia między skrzynkami itd.).
Każdy wpis ma autora oraz datę/czas i jest dopisywany przyrostowo .
2. WorkFlow to już: reguły przejść, przypisania, terminy (SLA), eskalacje, powiadomienia.
Poniżej najpraktyczniejsze kierunki rozbudowy (od najłatwiejszych do 'pełnego WF').
1) Ustandaryzować zdarzenia i 'etapy' na skrzynkach
W praktyce skrzynki (koszyki/etapy) już budują obieg, bo przeniesienia są widoczne w kronice.
Żeby to nadawało się do automatyzacji:
* Ustal minimalny zestaw skrzynek (np. Pobrane -> Weryfikacja -> Rejestracja -> Księgowość -> Zapisane).
* Wprowadź standard wpisów operatora (np. 'ZWERYFIKOWANO FORMALNIE', 'OK MERYTORYCZNIE',
'BRAK ZAMÓWIENIA - DO WYJAŚNIENIA'), najlepiej z krótkimi kodami.
* Efekt: masz dane, które da się filtrować/raportować i na nich budować alerty.
To jest fundament pod wszystko dalej.
2) Terminy/SLA: liczenie czasu 'ile leży w etapie'
W kronice masz dokładne znaczniki czasu przy przeniesieniach i zapisach, więc można policzyć:
* czas od pobrania do weryfikacji,
* czas w weryfikacji,
* czas w księgowości,
* 'utknięte > X godzin/dni'.
Najczęstsza implementacja:
* raport / zestawienie 'faktury przeterminowane w etapie',
* progi SLA per skrzynka (np. Weryfikacja 24h, Księgowość 48h),
* statusy typu: OK / zbliża się termin / po terminie.
3) Powiadomienia i eskalacje (mail/Teams/SMS)
Tu są dwa warianty:
A) 'Wbudowane' - jeśli macie mechanizmy wiadomości/zadań w Trawersie
Jeżeli w Waszej instalacji jest moduł/rozwiązanie do wysyłek/komunikatów
(różnie bywa we wdrożeniach), to triggerem jest:
* przeniesienie do skrzynki (nowy właściciel/rola),
* przekroczenie SLA (alert + eskalacja),
* określony wpis operatora (np. 'BRAK ...', 'PILNE').
B) Integracja zewnętrzna (najbardziej elastyczna)
Jeżeli chcecie pewne i rozwojowe WF, to zwykle robi się to integracyjnie:
* Trawers udostępnia usługi SOA (OutBound/InBound) do pobierania i dopisywania danych .
* Zewnętrzny 'silnik workflow' albo prosty serwis (scheduler) może:
* cyklicznie pobierać listę dokumentów/stanów,
* wykrywać przekroczenia SLA,
* wysyłać powiadomienia,
* a potem dopisywać do memo automatyczny wpis:
'ALERT SLA 24h - wysłano powiadomienie do ...' (czyli memo zostaje 'czarną skrzynką audytu').
W tym wariancie kronika dalej jest źródłem prawdy (audyt), a workflow żyje obok.
4) 'Prawdziwy' WorkFlow: reguły przejść + role + blokady
Jeśli celem jest nie tylko informowanie, ale wymuszanie procesu, to zwykle dochodzą:
* dozwolone przejścia między skrzynkami (np. nie wolno do Księgowości bez 'weryfikacja formalna'),
* przypisania do ról (dział/MPK/projekt),
* wymagane pola/załączniki przed kolejnym etapem,
* ścieżki wyjątków (reklamacja, faktura sporna, korekta).
To jest już projekt wdrożeniowy (analiza procesów + konfiguracja + ewentualnie custom).
Co polecam jako 'bezpieczny' plan wdrożenia (krótko)
1. Skrzynki jako etapy + standard wpisów (żeby dane były jednoznaczne).
2. Raport SLA 'utknięte w etapie > X'.
3. Powiadomienia: najpierw e-mail/Teams dla etapu, potem eskalacja.
4. Dopiero na końcu: blokady/reguły przejść (jeśli naprawdę potrzebne).
Jeśli podasz mi:
* jakie macie skrzynki/etapy dziś,
* jakie SLA chcecie (np. 24h/48h),
* i jakie kanały powiadomień (mail, Teams, SMS),
to zaproponuję konkretną mapę: etap -> odpowiedzialny -> termin -> reguła alarmu-> treść wpisu do memo (tak, żeby wszystko było audytowalne w kronice).
8. RZ Projekty/Zadania. Szkielet dla WorkFlow
JD: W module RZ Projekty Zadania zastosowano podobny mechanizm zapisywania zdarzeń w polu memo.
Dodatkowo są funkcje delegowania, powiadamiania itp.
Wgrywam opis. Jakie ew. sugestie wykorzystania ew. Wokflow dot. kroniki obiegu faktur zakupu.
AsystentAI:
To, co macie w RZ Projekty/Zadania, jest w praktyce gotowym 'szkieletem workflow':
kronika (memo) + delegowanie + powiadomienia + terminy (DueDate) + statusy.
Da się to bardzo sensownie przenieść na kronikę obiegu faktur zakupu KSeF,
nawet jeśli sama faktura nie ma dziś 'pól workflow' poza skrzynkami i memo.
Poniżej konkretne sugestie 'jak wykorzystać RZ jako workflow' dla obiegu faktur.
1) Zrobić z faktury 'sprawę' (Task) w RZ
A memo faktury zostawić jako audyt
W RZ zadanie ma naturalne pola workflow: Czyje/Owner, Od/Sender, delegowanie, statusy [ ][P][Z],
planowana data zakończenia (DueDate), priorytet, powiadomienia.
JD: DueDate jest w zbiorze, ale czytanie jest w .prg z pierwotnej wersji RZ
Ew. dostosowac do nowej wersji i włączyć do RZ
A jednocześnie w RZ memo działa identycznie: wpisy operatorów + automatyczne wpisy obiegu,
z pieczątką kto/kiedy.
Propozycja architektury:
* Dla każdej faktury (lub dla wyjątków) tworzysz w RZ zadanie typu: Obieg faktury zakupu KSeF.
* W zadaniu trzymasz *workflow* (kto ma zrobić, do kiedy, eskalacje, delegowanie).
* W memo faktury dalej zapisujesz kronikę dokumentu (nie musi dźwigać całej logiki).
Łączenie:
przez RefNo / identyfikator faktury (analogicznie jak w RZ wiąże się dokumenty via RefNo).
2) Delegowanie = przekazywanie odpowiedzialności za etap faktury
W fakturach macie dziś przeniesienia między skrzynkami i komentarze (kronika).
W RZ delegowanie jest jawne: *kto przekazał komu* i zapisuje się ścieżka delegowania,
a adresat może dostać 'dymek'/powiadomienie (param. 1101) .
Jak to przełożyć na KSeF:
* Ustal mapę: skrzynka/etap -> rola/wykonawca (Owner w RZ).
* Każde 'przeniesienie do skrzynki X' może automatycznie powodować:
* delegowanie zadania RZ do właściwej osoby/zespołu,
* dopisek do memo faktury: 'Delegowano do: ... / etap: ...'.
To daje Wam:
* odpowiedzialność (kto ma piłkę),
* historię przekazań (ścieżka),
* powiadomienie bez ręcznego pisania maila.
3) Terminy/SLA: użyć DueDate z RZ zamiast liczyć 'z memo'
W RZ macie wprost planowaną datę zakończenia zadania (DueDate)
i można robić zestawienia po DueDate.
To jest idealne miejsce na SLA obiegu faktury:
* dla etapu 'Weryfikacja' ustawiasz DueDate = dziś + 1 dzień,
* dla 'Księgowość' DueDate = dziś + 2 dni,
* dla 'Wyjaśnienia' DueDate zależnie od typu problemu.
A memo faktury zostaje czyste: opis merytoryczny i zdarzenia.
4) Powiadomienia: przenieść mechanikę
'zadanie -> dymek/hint' na obieg faktur
W RZ jest gotowy wzorzec: delegowanie + powiadomienie o otrzymaniu zadania
oraz 'wysłanie wiadomości do wykonawcy / zespołu / wszystkich' .
W obiegu faktur najczęstsze powiadomienia:
* Masz nową fakturę w etapie X
* SLA mija za 4h
* SLA przekroczone eskalacja do przełożonego
* Wymagane wyjaśnienie: brak zamówienia / brak MPK / rozbieżność
Wszystko to da się realizować przez:
* powiadomienia RZ (dymki) jako kanał podstawowy,
* (opcjonalnie) dodatkowe kanały, jeśli macie integracje (mail/Teams).
5) Statusy i wyjątki: faktura nie zawsze potrzebuje 'zadania RZ'
Żeby nie zalać RZ tysiącami rutynowych faktur, działa dobrze model:
* Standardowy obieg tylko na skrzynkach + memo faktury.
* RZ zadanie tworzone:
* gdy faktura trafia do skrzynki 'WYJAŚNIENIA / SPORNE',
* gdy przekracza SLA w danym etapie,
* gdy wymaga akceptacji kosztowej (np. kierownik MPK),
* gdy jest 'nietypowa' (zaliczka, import, WNT, korekta, itp.).
To jest dokładnie podejście 'ticketowe' z RZ (zadanie jako sprawa/incident).
6) Standaryzacja wpisów memo
(żeby dało się to raportować i automatyzować)
Skoro memo jest przyrostowe i z pieczątką czasu/autora zarówno w KSeF, jak i RZ,
to warto narzucić krótkie kody zdarzeń w dopiskach operatorów, np.:
* `[OK_FORM]`, `[OK_MERYT]`, `[BRAK_ZAM]`, `[BRAK_MPK]`, `[SPORNE]`, `[PILNE]`
Wtedy:
* łatwo budować raport 'ile faktur z [BRAK_ZAM] w miesiącu',
* łatwo automatycznie tworzyć zadanie RZ, gdy pojawi się kod wyjątku.
Minimalny 'workflow' do wdrożenia w 3 krokach (sprawdza się w praktyce)
1. Mapowanie skrzynek faktur wykonawcy/zespoły RZ + delegowanie.
2. DueDate/SLA na zadaniu RZ + powiadomienia (dymek) o nowym zadaniu i o terminie.
3. Zadania RZ tylko dla wyjątków i przekroczeń SLA (żeby nie tworzyć szumu).
Jeśli chcesz, mogę zaproponować gotowy szablon procesu
(etapy/skrzynki -> kto -> SLA -> kiedy tworzyć zadanie RZ -> kiedy eskalować)
Tylko napisz jakie macie realnie skrzynki w obiegu KSeF
(np. Pobrane / Weryfikacja / Rejestracja / Księgowość / Zapisane / Wyjaśnienia / Akceptacja).
9. Skrzynki w obiegu KSeF
Skrzynki: Pobrane / Weryfikacja / Rejestracja / Księgowość / Zapisane / Wyjaśnienia / Akceptacja
AsystentAI:
Przy tych skrzynkach da się złożyć czytelny 'workflow hybrydowy':
skrzynki robią etap procesu, a RZ Zadanie daje *właściciela, terminy,
delegowanie, powiadomienia i eskalacje*. Poniżej gotowa propozycja.
1) Mapa skrzynek -> Owner/rola + SLA + reguła powiadomień
| Skrzynka | Sens etapu | Owner (RZ) | SLA (przykład) | Powiadomienia |
| ----------- | ----------------------------------------- | ------------------------------------------- | -------------------- | ------------------------------------------------------------- |
| Pobrane | start / bufor po imporcie | automatycznie do 'Weryfikacja' (bez ownera) | 2h | brak / tylko monitoring |
| Weryfikacja | formalna/rachunkowa, kompletność | Dział weryfikacji / rejestracja wstępna | 24h | od razu 'Nowa faktura, alarm 4h przed, eskalacja po terminie |
| Rejestracja | opis, MPK, powiązania, wstępna dekretacja | Rejestracja / zakupowcy | 24-48h | jak wyżej |
| Księgowość | dekretacja, VAT, księgowanie | Księgowość | 48h | jak wyżej + eskalacja do głównej księgowej |
| Akceptacja | merytoryczna (kierownik MPK/projekt) | Akceptant z reguły (MPK/projekt) | 48-72h | 'Do akceptacji' + przypomnienia co 24h |
| Wyjaśnienia | wyjątek/spór/braki | osoba zgłaszająca + adresat wyjaśnień | 7 dni (albo wg typu) | inne: cykliczne przypomnienia + eskalacja po X dniach |
| Zapisane | koniec | - | - | zamknięcie zadania RZ |
To jest dokładnie wzorzec z RZ: zadanie ma Czyje (Owner), delegowanie, status, DueDate
i można dać powiadomienia o przyjęciu zadania .
2) Kiedy tworzyć zadanie RZ (żeby nie robić 'szumu')
Działają dwa modele - polecam B:
A) Zadanie RZ dla każdej faktury
Plus: pełne WF zawsze. Minus: dużo rekordów.
B) Zadanie RZ tylko gdy 'jest praca do wykonania' (rekomendacja)
Twórz zadanie RZ gdy:
1. faktura trafi do Weryfikacja (czyli realnie start obiegu), albo
2. faktura trafi do Akceptacja lub Wyjaśnienia (wyjątek), albo
3. przekroczone SLA w dowolnym etapie.
Wtedy standardowe, proste faktury przejdą skrzynkami bez 'ticketów',
a trudne/ryzykowne dostaną WF.
3) Reguły delegowania (czyli 'kto ma piłkę')
W RZ delegowanie zapamiętuje ścieżkę przekazań i może dawać powiadomienie
adresatowi (dymek). Przekład na skrzynki:
* Przeniesienie faktury do skrzynki X -> deleguj zadanie RZ do Ownera etapu X.
* Owner może:
* przyjąć (status [P]),
* przekazać dalej (delegowanie),
* odesłać (np. do Rejestracji / Wyjaśnień) - też jako delegowanie.
Ważne: skrzynka mówi 'gdzie jest dokument', a RZ mówi 'kto jest odpowiedzialny'.
4) Terminy i eskalacje - proste i skuteczne
Każde wejście faktury w etap ustala:
* DueDate = teraz + SLA etapu
* przypomnienia: np. T-4h, T-1h
* po terminie: eskalacja do przełożonego / grupy
Tu najlepiej użyć DueDate z RZ (naturalne pole do alarmowania i zestawień).
5) Wyjaśnienia: typy spraw i automatyczne ścieżki
'Wyjaśnienia' warto podzielić na typy (kod w tytule zadania RZ i w memo faktury),
np.:
* WYJ: brak zamówienia
* WYJ: rozbieżność kwot/VAT
* WYJ: brak MPK
* WYJ: sporna merytorycznie
Każdy typ ma:
* domyślnego adresata (np. kupiec / kierownik MPK),
* inne SLA (np. brak MPK 3 dni, spór 7 dni),
* inną eskalację.
6) Akceptacja: reguły kto akceptuje
Najczęściej:
* wg MPK / projektu / działu -> przypisany akceptant,
* wg progu kwoty -> drugi poziom (kierownik + dyrektor),
* wg typów kosztu -> inna ścieżka.
W praktyce: wejście do Akceptacja deleguje zadanie RZ do właściwego
akceptanta, a po akceptacji automatycznie wraca do Księgowość
lub Rejestracja (jeśli akceptant zgłosi braki).
7) Memo faktury
Co warto dopisywać automatycznie (żeby była 'kronika audytu')
Tak jak w RZ, memo zapisuje automatyczne komunikaty obiegu i dopiski
operatorów, w fakturze KSeF dopisuj automatycznie np.:
* 'Utworzono zadanie RZ #... / Owner: ... / DueDate: ...'
* 'Delegowano do ... (etap: Akceptacja)'
* 'SLA przekroczone w etapie ... - eskalacja do ...'
To daje audyt bez szukania w RZ.
Gotowy 'minimalny workflow'
Do wdrożenia (najmniej pracy, duży efekt)
1. Zadanie RZ tworzone przy wejściu do Weryfikacja (albo tylko przy Wyjaśnienia/Akceptacja).
2. Delegowanie RZ = zgodnie ze skrzynką (Owner etapu).
3. DueDate/SLA + przypomnienia + eskalacja dla: Weryfikacja, Rejestracja, Akceptacja, Księgowość.
4. Zapisane zamyka zadanie RZ.
Jeśli chcesz, przygotuję Ci konkretną tabelę konfiguracyjną
'etap -> właściciel -> SLA -> eskalacja -> szablon tytułu zadania RZ',
ale potrzebuję tylko jednego: kto jest Ownerem każdej skrzynki
(role lub konkretne zespoły/osoby) i czy akceptacja jest jedno- czy dwuetapowa (progi kwotowe).
10. Domyślne role
AsystentAI:
Poniżej masz domyślny zestaw ról (bez wchodzenia w strukturę konkretnej firmy)
+ przypisanie do Twoich skrzynek.
Założenie: Akceptacja jedno-etapowa.
1) Domyślne role (słownik)
1. KSeF_Operator - techniczny operator obsługi pobrania/monitoringu (może być grupa, nie osoba).
2. AP_Weryfikator - weryfikacja formalno-rachunkowa (Accounts Payable - weryfikacja).
3. AP_Rejestrator - rejestracja/Opis kosztu/MPK/projekt/kompletacja danych (pre-dekretacja).
4. AP_Ksiegowy - księgowość zobowiązań / dekretacja VAT / księgowanie (AP accounting).
5. AKCEPTANT_Merytoryczny - właściciel kosztu (kierownik MPK/projektu/działu).
6. AP_Wyjasnienia - rola koordynator wyjaśnień (pilotuje sporne/braki);
często to ta sama grupa co Rejestracja, ale warto wydzielić logicznie.
7. AP_Nadzorca - eskalacje (główna księgowa / kierownik finansów / team leader AP).
2) Mapa skrzynek -> rola wiodąca (Owner) + typowe SLA
To jest gotowiec 'na start':
* Pobrane -> `KSeF_Operator` (SLA: 2h bufor/monitoring)
Cel: szybkie 'przepchnięcie' do Weryfikacja, kontrola błędów importu.
* Weryfikacja -> `AP_Weryfikator` (SLA: 24h)
Formalno-rachunkowe: kompletność, podstawowe kontrole, czy wymaga Wyjaśnień/Akceptacji.
* Rejestracja -> `AP_Rejestrator` (SLA: 2448h)
Opis merytoryczny w systemie: MPK/projekt/rodzaj kosztu, powiązania, przygotowanie do księgowania.
* Akceptacja (1 etap) -> `AKCEPTANT_Merytoryczny` (SLA: 4872h)
Zatwierdza koszt merytorycznie. Po akceptacji: do Księgowość.
* Wyjaśnienia -> `AP_Wyjasnienia` (SLA: 7 dni domyślnie)
Pilotuje brak MPK, spór, brak zamówienia, rozbieżności; deleguje do właściwych osób.
* Księgowość -> `AP_Ksiegowy` (SLA: 48h)
Dekretacja, VAT, księgowanie, kontrola końcowa.
* Zapisane -> brak Ownera (zamknięcie sprawy)
Tu zamykasz ewentualne zadanie RZ.
3) Eskalacje (prosto i działa)
* Jeśli zbliża się termin (np. 4h przed SLA): powiadom Ownera etapu.
* Jeśli SLA przekroczone: powiadom Ownera + `AP_Nadzorca`.
* Jeśli Wyjaśnienia > 7 dni: eskalacja do `AP_Nadzorca` + (opcjonalnie) do `AKCEPTANT_Merytoryczny`,
jeśli dotyczy kosztu.
4) Jednoetapowa Akceptacja
Jak dobrać akceptanta domyślnie
Domyślny algorytm (od najlepszej reguły do 'awaryjnej'):
1. wg MPK/projektu (przypisany kierownik),
2. jeśli brak MPK/projektu -> wg działu kosztu (np. IT/Administracja/Produkcja),
3. jeśli dalej nie wiadomo -> `AP_Nadzorca` jako akceptant zastępczy.
5) Minimalne statusy w RZ
Jeśli używacie 'tasków' jako workflow
* `[ ] Otwarte` - faktura w toku, Owner ma wykonać krok
* `[P] Przydzielone` - przyjęte do realizacji (wzięte na siebie)
* `[Z] Zamknięte` - Zapisane / zakończone
Jeśli chcesz, mogę od razu rozpisać szablony tytułów zadań RZ
(np. `FV KSeF: [WERYF] Dostawca / kwota / termin`) i krótkie kody do memo,
żeby automatycznie dało się wykrywać wyjątki
(WYJ:BRAK_MPK, WYJ:BRAK_ZAM, itp.).
11. Tytuły zadań w RZ (szablony)
Poniżej gotowe szablony tytułów zadań RZ + szablony wpisów do memo
(faktury i zadania).
Są tak ułożone, żeby:
(1) łatwo się filtrowało/listowało,
(2) dało się robić automatyczne reguły po prefiksach/kodach,
(3) dało się szybko zrozumieć 'co to jest i kto ma zrobić'.
1) Szablon nazwy zadania RZ (uniwersalny)`KSEF/AP | {ETAP} | {DOSTAWCA} | {KWOTA}{WAL} | {DATA_FV} | {ID_KSEF_SHORT} | {PILNOSC}`
Przykład:
`KSEF/AP | WERYF | SONAKOL SP.J. | 12 340.00 PLN | 2026-05-28 | 5449-DA | P2`
Pola:
* `{ETAP}`: POBR / WERYF / REJ / AKC / WYJ / KSI / (opcjonalnie) SLA
* `{ID_KSEF_SHORT}`: ostatnie 6-10 znaków identyfikatora (żeby nie było kilometrów)
* `{PILNOSC}`: P1..P4 albo puste
2) Szablony tytułów per skrzynka
(praktyczne prefiksy)
Pobrane`KSEF/AP | POBR | {DOSTAWCA} | {KWOTA}{WAL} | {DATA_FV} | {ID_KSEF_SHORT}`
Opis zadania (pierwsza linia): Kontrola techniczna / kompletność pobrania, przekazać do WERYF.
Weryfikacja`KSEF/AP | WERYF | {DOSTAWCA} | {KWOTA}{WAL} | {DATA_FV} | {ID_KSEF_SHORT}`
Opcjonalny dopisek gdy wyjątek:
`... | WYJ:{KOD}` np. `WYJ:BRAK_ZAM`
Rejestracja`KSEF/AP | REJ | {DOSTAWCA} | {KWOTA}{WAL} | {DATA_FV} | {ID_KSEF_SHORT}`
Dopisek gdy braki: `| BRAK:{KOD}` np. `BRAK:MPK`
Akceptacja (1 etap)`KSEF/AP | AKC | {DOSTAWCA} | {KWOTA}{WAL} | {MPK/PROJ} | {DATA_FV} | {ID_KSEF_SHORT}`
Przykład:
`KSEF/AP | AKC | Budex | 8 900 PLN | MPK:410-IT | 2026-05-28 | 5449-DA`
Wyjaśnienia`KSEF/AP | WYJ:{KOD} | {DOSTAWCA} | {KWOTA}{WAL} | {DATA_FV} | {ID_KSEF_SHORT}`
Przykład:
`KSEF/AP | WYJ:BRAK_ZAM | Budex | 1 240 PLN | 2026-05-28 | 5449-DA`
Księgowość`KSEF/AP | KSI | {DOSTAWCA} | {KWOTA}{WAL} | {OKRES} | {DATA_FV} | {ID_KSEF_SHORT}`
Przykład:
`KSEF/AP | KSI | SONAKOL | 12 340 PLN | 2026-05 | 2026-05-28 | 5449-DA`
Zapisane (zamknięcie)`KSEF/AP | ZAMK | {DOSTAWCA} | {KWOTA}{WAL} | {DATA_FV} | {ID_KSEF_SHORT}`3) Kody (żeby automatyzować i filtrować)
Polecam trzymać krótką listę kodów, które pojawiają się w tytule i w memo:
Wyjaśnienia (WYJ):
* `BRAK_ZAM` - brak zamówienia / brak powiązania
* `BRAK_MPK` - brak MPK / projektu
* `ROZB_KW` - rozbieżność kwot
* `ROZB_VAT` - rozbieżność VAT/stawki
* `SPORNA` - sporna merytorycznie
* `DUPLIKAT` - podejrzenie duplikatu
* `NIE_CZYT` - nieczytelne / brak danych
Akceptacja/obieg:
* `OK_FORM`, `OK_RACH`, `OK_MERYT`
* `ODRZ` (odrzucone), `DO_POPR` (do poprawy), `PILNE`
4) Szablony treści
(pierwszy wpis w memo zadania RZ)
Wklejane jako 'checklista' dla wykonawcy:
WERYF - treść startowaTemat: Weryfikacja formalno-rachunkowa
Sprawdź: dane dostawcy, NIP, daty, kwoty, VAT, kompletność, duplikat
Wynik:
* OK -> przenieś do REJ
* Braki/spór -> przenieś do WYJ:{KOD} (i dopisz co brakuje)
REJ - treść startowaUzupełnij: MPK/Projekt, opis kosztu, powiązanie (zamówienie/umowa), propozycja dekretu
Wynik:
* wymaga akceptacji -> AKC
* kompletne -> KSI
* braki -> WYJ:{KOD}
AKC - treść startowa (1 etap)Prośba o akceptację merytoryczną kosztu
MPK/Projekt: {...}
Opis: {...}
Wynik:
* AKCEPTUJ -> do KSI
* ODRZUĆ / DO_POPR -> do WYJ lub REJ (z komentarzem)
WYJ - treść startowaPowód: {KOD}
Co potrzebne: {lista}
Adresat: {osoba/dział}
Wynik: po wyjaśnieniu -> wróć do REJ albo AKC
KSI - treść startowaZaksięgować / zadekretować
Okres: {...} VAT: {...}
Wynik:
* OK -> Zapisane
* błąd -> WYJ:{KOD}
5) Szablony wpisów do memo faktury
(automatyczne, audytowe)
Żeby kronika faktury była 'czytelna jak log' i spójna z RZ:
* `**** WF: Utworzono zadanie RZ #{TASKNR} | ETAP={ETAP} | OWNER={OWNER} | DUE={YYYY-MM-DD HH:MM} ****`
* `**** WF: Delegowano | ETAP={ETAP} | z={OD} do={DO} | powód={KOD} ****`
* `**** WF: SLA-ALERT | ETAP={ETAP} | T-{H}h | OWNER={OWNER} ****`
* `**** WF: SLA-OVERDUE | ETAP={ETAP} | +{H}h | eskalacja={AP_NADZORCA} ****`
* `**** WF: ZAMKNIĘTO | wynik={ZAPISANE/ODRZ/ANUL} | #{TASKNR} ****`