Rewizor nexo i Sfera: integracja księgowa, której w większości przypadków nie powinniście budować

Program, w którym automatyzacja jest już w pudełku

To szósty przewodnik z serii o integracjach z polskimi systemami ERP i pierwszy, w którym uczciwa rada brzmi: napiszcie mniej kodu, niż planowaliście.

W poprzednich pięciu schemat był zawsze ten sam. Klient ma Subiekta nexo, enova365 albo Optimę, coś spoza ERP musi czytać albo pisać — zdobywacie połączenie, poznajecie model obiektowy, budujecie. Rewizor nexo ten schemat łamie. To, o co najczęściej prosi się w nim programistę, siedzi już w programie. Wyłączone i opisane.

Odpowiadają za to dwie rzeczy. Pierwsza stoi na liście funkcji PRO: rozbudowane schematy dekretacji, których wykonanie można warunkować od dowolnej cechy dokumentu źródłowego. Druga pojawiła się w wersji InsERT nexo 41.0.0: automat, konfigurowany w module Ewidencje dodatkowe – Automatyzacja, uruchamiany po zapisaniu obiektu i wykonujący akcję Dekretuj automatycznie.

Razem daje to silnik reguł, który księguje dokumenty w miarę ich pojawiania się, z warunkami na wejściu. Czyli dokładnie to, co dziewięć razy na dziesięć klient ma na myśli, pytając, czy da się zautomatyzować księgowanie.

Czym naprawdę jest schemat dekretacji

Tu muszę być dokładny, bo słowo dekretacja chodzi po rynku dość luźno, a programiści przychodzący z innych stacków wyobrażają sobie zwykle coś prostszego, niż to jest naprawdę.

Schemat mieszka w module Dekretacja dokumentów, na zakładce Schematy dekretacji. Dwa jego ustawienia ważą więcej niż cała reszta razem wzięta. Warunek wyboru decyduje, których dokumentów schemat dotyczy. Kolejność rozstrzyga, który schemat wygrywa, kiedy pasuje więcej niż jeden. Wszystko inne — konta, kwoty, podziały — to ta część, którą ludzie biorą za cały schemat, i akurat ona rzadko sprawia kłopoty.

Kłopot siedzi w tych dwóch polach. Schemat, który księguje bezbłędnie, ale wybiera złe dokumenty, produkuje zapisy pewne siebie, spójne i błędne — na dużą skalę, miesiącami. A ponieważ kolejność to jedna liczba na zbiorze schematów, który tylko rośnie, dwunasty dodany przez kogoś schemat bywa tym, który po cichu zmienia działanie czwartego.

Więc kiedy trafia do Was instalacja, w której „automatyczna dekretacja przestała być wiarygodna", eksportujcie najpierw warunki i kolejność. Nie mapowania kont. Ani razu nie znalazłem problemu w mapowaniach kont.

Liczba, której nikt nie mierzy

Zanim cokolwiek zaczniecie, jeden pomiar. Na tyle tani, że nie ma wymówki, żeby go pominąć — i prawie wszyscy go pomijają.

Wskaźnik automatycznej dekretacji. Weźcie jeden zamknięty miesiąc i podzielcie jego dokumenty na trzy kupki:

1. Zadekretowane schematem i już nietknięte.
2. Zadekretowane schematem, a potem poprawione ręcznie.
3. Zadekretowane od zera przez człowieka.

Zapytajcie biuro o stopień automatyzacji, a usłyszycie pierwszą liczbę. Jest z tych trzech najmniej użyteczna. O tym, czy jest tu w ogóle projekt, decyduje druga — i prawie nikt jej nie śledzi, z przyczyny strukturalnej. Poprawiony dekret leżący w księgach wygląda dokładnie tak samo jak ręczny. Poprawka nie zostawia śladu na tym, co poprawiła.

Ta środkowa kupka jest specyfikacją, której Wam brakuje. Każda poprawka w niej to człowiek stosujący regułę, która istnieje i nigdy nie została zapisana. Transport od tego dostawcy idzie na inne konto niż transport od tamtego. Faktury tego kontrahenta trzeba rozbić na MPK. Ta jedna ma inną transakcję VAT, niż sugeruje typ dokumentu. Zbierzcie trzy miesiące takich poprawek, a przestaniecie zbierać wymagania — zaczniecie je czytać.

Na portfelu czterdziestu klientów to popołudnie pracy i regularnie zmienia rozmowę. Widziałem biuro, które opisywało siebie jako „może trzydzieści procent zautomatyzowane", a po przeliczeniu okazało się, że schematy dotykają blisko siedemdziesięciu procent dokumentów i połowa z tego jest po cichu poprawiana. To są dwa zupełnie różne problemy. Tylko jeden z nich rozwiązuje się pisaniem czegokolwiek.

Naprawa jest zwykle wyżej, nie w Rewizorze

Teraz to zdanie z listy PRO, które przesądza, gdzie naprawdę wykonacie robotę. Schematy można warunkować dowolną cechą dokumentu źródłowego. Przeczytajcie je od drugiej strony: schemat może być tylko tak szczegółowy jak dokument, który czyta.

Biuro poprawia ręcznie faktury zakupu, bo transport od jednego dostawcy należy gdzie indziej? Schemat tego nie naprawi, o ile nic na dokumencie tych dwóch przypadków nie odróżnia. A zwykle nic nie odróżnia. Dokument mówi, co kupiono i od kogo — różnica siedzi w czyjejś głowie.

Robota przenosi się więc poza program księgowy, do tego, co ten dokument wyprodukowało. W instalacji InsERT-a zwykle znaczy to pola własne po stronie Subiekta albo pole słownikowe na kartotece kontrahenta, dodane wyłącznie po to, żeby schemat miał co sprawdzić. To samo odkrycie co pułapka pól własnych w enova365, tylko przychodzące z przeciwnej strony: tam pola własne były zagrożeniem, o którym nikt integratorowi nie powiedział, tutaj są brakującym wejściem, bez którego automatyzacja w ogóle nie ruszy.

Dwie konsekwencje, które trzeba klientowi powiedzieć wprost. Pierwsza: najtańszym ulepszeniem jego automatycznej dekretacji bywa pięciominutowa zmiana konfiguracji w zupełnie innym programie. Druga: jeśli dokumenty przychodzą z systemów jego klientów, a nie z jego własnego — czyli normalny przypadek biura rachunkowego, o którym pisałem przy problemie sześciu ERP-ów — cechy, której potrzebujecie, może nie dać się zdobyć za żadną cenę. Uczciwa odpowiedź brzmi wtedy: te dokumenty zostają ręczne. I lepiej powiedzieć to w pierwszym tygodniu niż odkryć w szóstym.

Wycofaj i dekretuj ponownie — najgroźniejsze ustawienie w całej linii

Automat ma opcję dla dokumentów już ujętych w księgach: Wycofaj i dekretuj ponownie.

Istnieje z dobrego powodu. Bez niej automat, który trafia na dokument już zadekretowany, albo się wywala, albo nie robi nic, a w nocnym zadaniu obie te rzeczy są gorsze, niż brzmią. Z nią automat staje się czymś bliskim idempotentności — czyli dokładnie tym, czego chce się od automatyzacji chodzącej bez nadzoru.

I ta sama opcja najłatwiej zniszczy czyjąś pracę, bo nie widzi intencji. Dekret poprawiony ręcznie przez księgową o szesnastej i dekret, którego nikt nigdy nie otworzył, to dla niej ten sam obiekt. Puśćcie ją na szerszym zakresie, niż zamierzaliście, a cofnie ludzką decyzję bez żadnego znaku, że to się stało. Bez błędu. Bez wpisu w logu, który ktokolwiek przeczyta. Zostaje jeden dekret, subtelnie inny niż ten, który ktoś uważał za naprawiony.

Reguła: automatyzacja nigdy nie dekretuje ponownie dokumentu, którego po pierwszej dekretacji dotknął człowiek. Oznaczcie takie i wykluczcie — kosztuje to jeden warunek. W otwartym okresie ceną pomyłki jest kłótnia. W zamkniętym — korekta, którą ktoś musi wytłumaczyć klientowi, czyli dokładnie to, co miałem na myśli, pisząc o tym, czego agent nie zrobi przy JPK_V7.

To także najczystsza ilustracja tezy z tekstu o odpowiedzialności: poziomy uprawnień nie są stałe dla firmy. Przy CRM-ie argumentowałem odwrotnie, niż każe ostrożność — utworzenie działania w Gestorze to najtańszy zapis w całym InsERT-cie, bo zły kasuje się w piętnaście sekund. Ten sam poziom uprawnień w księgach to zupełnie inne ryzyko. Uprawnienia szereguje się według kosztu cofnięcia pomyłki, a nie według czasownika.

OCR daje pola. Nie daje konta.

Biura pracujące na Rewizorze przyjmują dokumenty zwykle przez Portal Dokumentów. Jego OCR odczytuje numer dokumentu, datę, kontrahenta i kwoty z tabeli VAT, a potem przenosi je do dodawanego zapisu. Działa. I rozwiązuje realny koszt: przepisywanie.

Czego nie poda, to konta. Konto jest funkcją tego, co kupiono i po co, a tego na fakturze bardzo często po prostu nie ma. „Usługi doradcze" od firmy, której zapłaciliście w zeszłym roku trzy razy, mogą trafić w kilka różnych miejsc, zależnie od decyzji, których nikt nigdy nie wydrukował.

Łańcuch automatyzacji ma więc dziurę w środku. OCR robi czytanie, schematy robią księgowanie, a pomiędzy siedzi klasyfikacja, która nie jest ani jednym, ani drugim. Klasyfikacja to spojrzenie na dostawcę, na sformułowanie w opisie, na to, co biuro zdecydowało dla tego kontrahenta kwartał temu i co dostały podobne dokumenty. Osąd z kontekstu i precedensu. Czyli to, w czym modele językowe są naprawdę dobre — w przeciwieństwie do zadań rachunkowych, do których ciągle się je przystawia.

To jest miejsce dla modelu w instalacji Rewizora, a kształt narzuca koszt cofnięcia: proponuje konto i schemat, człowiek zatwierdza, a zatwierdzenie uczy następną propozycję. Nigdy nie księguje. Zła propozycja kosztuje kliknięcie. Zły zapis w zamkniętym okresie kosztuje popołudnie i telefon. Różnica między tymi dwiema liczbami jest całym projektem.

Co zbudowałbym najpierw

Przez pierwszy tydzień nic.

Policzyć wskaźnik automatycznej dekretacji i wyciągnąć trzy miesiące poprawek nanoszonych na dekrety zrobione schematem. Rozdzielić je na dwie grupy: poprawki, które mogła zrobić reguła (ten sam dostawca, to samo konto, za każdym razem), i te, które wymagały człowieka wiedzącego coś, czego dokument nie mówił. Ta proporcja mówi Wam, jakiego rodzaju to projekt. Ta sama diagnostyka, którą proponowałem przy korektach JPK_V7 — dane albo mogły to wyłapać, albo nie mogły, a reszta z tego podziału już wynika.

Potem po kolei. Poprawcie warunki schematów, które te poprawki właśnie Wam wyspecyfikowały. Dodajcie brakującą cechę wyżej, tam gdzie warunek jej potrzebuje. Dopiero na końcu zbudujcie klasyfikator do tego, co zostało, i wypuśćcie go jako kolejkę propozycji, którą człowiek przerabia — ze wskaźnikiem automatycznej dekretacji zmierzonym ponownie miesiąc później, żeby dało się udowodnić, że coś drgnęło. Jeśli nie drgnęło, dowiecie się tego z tego samego taniego pomiaru, a nie z kłótni o faktury. A jeśli patrzycie na to szerzej niż na jedną integrację, osobno opisałem, jak wyglądają agenci AI dla firm w polskich realiach ERP.

Sfera dla Rewizora przychodzi ostatnia, jeśli w ogóle, i tylko do tego, do czego naprawdę jest: własne raporty nad zaksięgowanymi danymi, punkty rozszerzeń, zasilanie systemu żyjącego całkiem poza InsERT-em. A jeśli po nią sięgniecie, reguła licencyjna z reszty tej serii obowiązuje bez zmian — licencja jest na Rewizor nexo PRO konkretnie, a Subiekt nexo PRO nie daje Wam tutaj nic. Gdzie Sfera stoi na tle alternatyw, opisuje porównanie API dla integratorów.

Zastanawiacie się, czy to schematy są ograniczeniem, czy poprawki mówią Wam coś zupełnie innego? Odezwijcie się. Jeden zamknięty miesiąc i lista poprawek wystarczą, żeby rozstrzygnąć — a to znacznie krótsza rozmowa niż pisanie specyfikacji.