Operacje wielofirmowe w Optimie: biuro ma już warstwę statusów i jej nie czyta

Moduł, którego nikt nie traktuje jak danych

Siódmy przewodnik w tej serii o integracji z polskimi systemami ERP. I drugi z rzędu, w którym najciekawsze okazuje się to, co producent już dostarczył.

Wczorajszy tekst o Rewizorze nexo stawiał prostą tezę: automatyzacja dekretacji, po którą klienci przychodzą do programisty, siedzi już w pudełku — tylko wyłączona. Z modułem Optimy dla biur rachunkowych jest inaczej i trochę dziwniej. Najpierw kwestia nazwy: Biuro Rachunkowe przemianowano na Operacje wielofirmowe, więc pół internetu mówi o nim po staremu, a program po nowemu.

Tutaj funkcja nie jest wyłączona. Biura w tym module mieszkają. Otwierają go co rano, przełączają się między bazami klientów bez ponownego logowania, liczą deklaracje seryjnie, wysyłają z kilku skrzynek. Jest używany intensywnie, każdego dnia roboczego miesiąca.

Nikt natomiast nie korzysta z danych, które przy tym używaniu powstają. A to dokładnie te dane, które każdy integrator budujący dla biura rachunkowego próbuje przez pierwsze dwa tygodnie zestawić od zera.

Jedenaście grup atrybutów to tabela statusów

Konfiguracja siedzi w Start → Konfiguracja → Operacje wielofirmowe, z gałęziami Atrybuty, Grupy atrybutów, Kategorie czasu pracy i Parametry. Jest też gałąź na poziomie firmy i osobna na poziomie stanowiska. Ta druga ma znaczenie i wrócę do niej.

Moduł dostarcza jedenaście predefiniowanych grup atrybutów. Same Dane firmy trzymają szesnaście atrybutów kontaktowych i identyfikacyjnych. Dalej: Deklaracje VAT, Deklaracje CIT, Deklaracje PIT, Deklaracje Intrastat, Deklaracja ZUS DRA, JPK, Ogólne (akronimy, status zamknięcia, liczby dokumentów), Operator (kto jest opiekunem), Parametry firm (stawki podatków, składek, amortyzacji) i Urzędy (który urząd skarbowy).

Zobaczcie teraz, co jedna grupa deklaracyjna trzyma per firma i per miesiąc. Status, który przechodzi brak → w buforze → zatwierdzona → wysłano → odebrano UPO. Kwotę do zapłaty albo do zwrotu. Datę obliczenia. Liczbę naliczonych pozycji.

Przeczytajcie to jako schemat bazy, a nie jako ekran. Wychodzi tabela statusów z kluczem klient plus miesiąc, utrzymywana ponad wszystkimi bazami, jakie biuro obsługuje, i wyliczana przez ERP, a nie przez Was. Nie zbudowaliście jej. Nie utrzymujecie jej. Jest już wypełniona danymi.

Najtrudniejsze w budowaniu czegokolwiek dla biura rachunkowego jest właśnie to złączenie. O wersji tego problemu, na którą wpadacie czołowo, pisałem w tekście o sufitach wydajności Optimy: moduł daje biuru jeden panel do przełączania się między czterdziestoma bazami klientów, ale pod spodem siedzi czterdzieści logowań, czterdzieści zestawów kategorii i czterdzieści rozjeżdżających się schematów. Przy pracy na dokumentach tego nie przeskoczycie. Ale przy pytaniu, które naprawdę napędza miesiąc w biurze — kto nie jest gotowy — ktoś tę agregację już za Was zrobił.

Dlaczego integratorzy przechodzą obok

Odruch jest zrozumiały. Dostajecie brief integracyjny, pytacie, co tu jest API, i w odpowiedzi słyszycie o jednej z pięciu rzeczy, które ludzie nazywają API Optimy — poukładałem je w przewodniku po API Optimy, bo ta niejednoznaczność zjada pierwsze spotkanie w każdym projekcie. CDN.API albo SQL bezpośrednio, per baza klienta, czterdzieści razy.

Przy pozycjach faktur i dekretach ta odpowiedź jest słuszna. Przy statusach oznacza, że zaraz zaczniecie odbudowywać coś, co już istnieje i jest już wypełnione.

Dwa uczciwe zastrzeżenia, zanim ktokolwiek zacznie na tym planować.

To moduł licencjonowany, sprzedawany na stanowisko i konfigurowany częściowo na poziomie stanowiska. W żadnym biurze jego obecność nie jest pewnikiem, a odpowiedź na pytanie „macie go?" jest najpierw handlowa, a dopiero potem techniczna.

Druga rzecz: atrybuty są wyliczane przy wejściu i odświeżeniu, a nie wypychane do Was. To nocne czytanie tabeli, a nie strumień zdarzeń. Jeśli Wasz projekt musi wiedzieć w ciągu minuty, że status deklaracji się zmienił, to nie ten mechanizm. Przestańcie go tak projektować teraz, a nie w szóstym tygodniu.

„Brak" to słowo, które psuje dashboard

Tutaj najbardziej oczywiste wdrożenie idzie źle. I za każdym razem idzie źle tak samo, więc potrafię już przewidzieć harmonogram.

Zliczcie klientów, których status VAT za ten miesiąc to brak, pomalujcie ich na czerwono, wrzućcie na ekran. Popołudnie pracy i pierwsza rzecz, którą ktokolwiek proponuje. Po dwóch tygodniach nikt na ten ekran nie patrzy.

Bo brak znaczy jedno mechanicznie i cztery rzeczy w praktyce. Nie policzono deklaracji tego typu — tylko tyle stwierdza. Nie rozróżnia:

• jeszcze nie zrobione,
• nie dotyczy, bo klient składa inny formularz,
• nie dotyczy, bo w tym miesiącu nie było działalności,
• nie dotyczy, bo klienta wykreślono, a bazy nikt nie usunął.

Wasza czerwona lista jest więc mieszanką prawdziwych luk i takich, które lukami nigdy nie były. Po trzecim poranku przewijania tych samych jedenastu klientów, którzy nigdy nie złożą VAT-u, lista zdążyła już nauczyć biuro, żeby ją ignorować.

Ten sam schemat co wskaźnik fałszywych zaległości z tekstu o rozrachunkach — raport technicznie poprawny, operacyjnie bezużyteczny i groźny właśnie dlatego, że wygląda na skończony.

Warto zbudować co innego: mapę stosowalności. Dla każdego klienta — które deklaracje mają istnieć w których miesiącach. VAT miesięcznie czy kwartalnie. Zaliczki PIT czy nie. ZUS DRA w ogóle. Obowiązki JPK. Intrastat powyżej progów.

Nikt takiej mapy nie ma. Siedzi w głowie osoby z najdłuższym stażem w biurze i co miesiąc, osiemnastego, jest odtwarzana z pamięci. Zapisanie jej to jedno popołudnie z tą osobą — i właśnie to popołudnie jest prawdziwym produktem. Ten sam wniosek co w tekście o rozrachunkach, przełożony na zamknięcie miesiąca: automatyzować warto filtr, nie wysyłkę.

Na portfelu czterdziestu klientów surowa liczba braków będzie w pierwszym tygodniu miesiąca bliska czterdziestu, a na dwudziestego spadnie do dziesięciu, może piętnastu. Z czego istotna część — często jedna trzecia — po prostu nie dotyczy tych klientów. Dopóki nie potraficie tej części odjąć, nie macie raportu gotowości. Macie listę do przewijania.

Jedna wartość jest dowodem. Reszta to zamiary

Popatrzcie na sekwencję statusów jeszcze raz i przy każdej wartości zadajcie jedno pytanie: kto ją tam wstawił?

brak, w buforze, zatwierdzona, wysłano — Wasza własna instalacja, która zapisuje własne działania i własne zamiary. odebrano UPO — potwierdzenie, które wróciło z systemu spoza biura.

Dokładnie jedna z tych pięciu wartości jest dowodem. Pozostałe cztery to notatki do siebie.

To nie jest akademickie rozróżnienie, bo awaria, którą przykrywa, jest najdroższą z możliwych w biurze rachunkowym. Wysyłka, która poszła i nigdy nie wróciła potwierdzona, wygląda na każdym wewnętrznym ekranie identycznie jak ta, która doszła. Biuro pilnujące wysłano jest przekonane, że czterdziestu klientów ma złożone deklaracje. A może mieć trzydziestu ośmiu.

Stąd luka UPO. Zliczcie miesiące klienckie, w których jest wysłano, a nie ma odebrano UPO. W ciągu kilku dni od każdego terminu ta liczba powinna zbiegać do zera. Nie zbiega. Prawie zawsze zostaje niewielka stała resztka, a każda pozycja w niej jest albo wysyłką, która nie doszła, albo potwierdzeniem, którego nikt nie odebrał. Którym z dwóch — nie da się powiedzieć bez zajrzenia. I po to właśnie się zagląda.

Koszt: jedna kolumna raportu na danych, które biuro już ma. Mapa stosowalności nie jest do tego potrzebna. A w przeciwieństwie do dashboardu braków nie ma tu żadnego szumu — każdy wiersz jest prawdziwym pytaniem. Jeśli macie zbudować z tego modułu jedną rzecz, zbudujcie tę.

Seryjna konwersja to mina integratora

Wśród funkcji administracyjnych modułu są seryjne kopie bezpieczeństwa i seryjne konwersje baz — na wybranych albo na wszystkich bazach klientów. Dla biura prawdziwa wygoda. Dla wszystkiego, co te bazy czyta, strukturalne zagrożenie.

Dwa różne scenariusze awarii. Drugi przegapia się częściej.

Konwersja wszystkiego naraz: integracja czytająca SQL psuje się dla wszystkich klientów tego samego ranka. To operacyjny argument za regułą, którą powtarzam od przewodnika po API — bazę czytaj śmiało, nie zapisuj do niej nigdy — z jednym rozszerzeniem: samo czytanie też Was wiąże ze schematem, który czterdziestu klientów zmienia w tym samym momencie.

Konwersja wybiórcza, a biura tak właśnie robią, bo planują konwersje wokół terminów klientów: czytacie wtedy równocześnie bazy stojące na dwóch różnych wersjach. Przy testach tego nie zobaczycie, bo środowisko testowe ma jedną bazę. Objawi się dopiero jako integracja, która działa dla trzydziestu jeden klientów i zwraca bzdury dla dziewięciu. Wygląda to na problem z danymi, a jest problemem z wersją — i ta pomyłka w diagnozie kosztuje tydzień.

Reguła, która przechodzi oba scenariusze: wykrywajcie wersję per baza w momencie połączenia i przerywajcie głośno dla tego jednego klienta, a nie globalnie. Jedna linijka w health-checku, per klient: ta baza jest na wersji, której ten konektor nie widział. Warta więcej niż dowolna logika ponawiania, jaką napiszecie. To ten sam alarm na dryf, o którym pisałem przy polach własnych w enova365, tylko wycelowany w wersję schematu, a nie w listę pól.

Czas pracy: jedyne dane o nakładzie w całym stosie

Jeszcze jedna gałąź — i zarazem najrzadziej używana rzecz w całym module.

Kategorie czasu pracy obsługują sesje typu A (automatyczne) i typu R (ręczne), a same kategorie mają kody i stawki godzinowe. To jedyne miejsce w oprogramowaniu biura rachunkowego, w którym nakład pracy na konkretnego klienta zostaje w ogóle zapisany.

A skoro tak, to jest to mianownik każdego argumentu o automatyzacji, jaki komukolwiek przyjdzie temu biuru przedstawić. Bez niego „to oszczędza czas" nie da się ani udowodnić, ani obalić — a wolę nie stawiać tez, których potem nikt nie sprawdzi.

Zastrzeżenie jest tu na tyle poważne, że musi iść razem z rekomendacją. Sesje typu A mierzą, jak długo baza danego klienta była otwarta, a nie jak długo ktokolwiek w niej pracował. Okno zostawione na czas obiadu też się liczy. Traktujcie więc sesje automatyczne jako luźny sufit, nie jako pomiar.

Prawdziwy koszt obsługi wychodzi dopiero z kategorii ze stawkami. Tylko że wymagają one, żeby ktoś codziennie uczciwie klasyfikował swój czas — czyli dokładnie tej dyscypliny, której żadne biuro nie ma i której żadne oprogramowanie mu nie zainstaluje. Jeśli biuro ją ma, rozmowa o zwrocie z inwestycji zamienia się w arytmetykę. Jeśli nie ma, powiedzcie to wprost, zamiast cytować sumy typu A, jakby coś znaczyły.

Promień rażenia to cała różnica

Między automatyzacją wewnątrz firmy a automatyzacją wewnątrz biura rachunkowego jest różnica strukturalna. W tym module widać ją wyjątkowo wyraźnie.

W firmie błędna reguła produkuje jeden błędny wynik. W biurze ta sama reguła leci na czterdziestu bazach klientów — a funkcje seryjne są tu zbudowane właśnie po to, żeby to było łatwe. Zła mapa stosowalności nie powoduje jednej pomyłki. Powoduje czterdzieści.

Granica wypada więc w oczywistym miejscu, tym samym co w tekście o tym, kto podpisuje: czytanie warstwy statusów i odpowiadanie na pytanie kto nie jest gotowy i dlaczego jest bezpieczne, tanie i naprawdę przydatne. Seryjne liczenie i seryjna wysyłka to nie kolejny krok w tę samą stronę. To inny rodzaj czynności, leżący po drugiej stronie granicy między proponowaniem a wysyłaniem — i właśnie ten mnożnik jest powodem. Szerzej o tym, gdzie agenci AI dla firm mają sens w polskich realiach ERP, pisałem osobno.

Jedna praktyczna uwaga, jeśli w planie jest dostęp zdalny: wersja przeglądarkowa Operacji wielofirmowych jest dostępna tylko dla biur pracujących w chmurze Comarch. To fakt handlowy, który rozstrzyga architekturę, więc ustalcie go na pierwszej rozmowie, nie na trzeciej.

Od czego zacząć

Wyeksportujcie tabelę atrybutów za trzy ostatnie zamknięte miesiące. To cały zbiór danych. Jeden eksport.

Policzcie na nim lukę UPO. Jeśli nie wyjdzie zero — a nie wyjdzie — znaleźliście prawdziwe pieniądze w pierwszej godzinie, nie budując jeszcze niczego.

Potem siądźcie z osobą, która co miesiąc odtwarza mapę stosowalności z pamięci, i spiszcie ją. Ta rozmowa jest projektem. Wszystko, co w zamknięciu biura warto automatyzować, wynika właśnie z niej — to zresztą ten sam argument co w tekście o potraktowaniu własnego systemu biura poważnie w pierwszej kolejności: ograniczeniem rzadko jest ERP.

Dopiero wtedy zbudujcie tablicę gotowości. I mierzcie ją tak, jak mierzyłbym każdą rzecz z tego tekstu: udziałem klientów danego miesiąca, których deklaracje są potwierdzone do dziesiątego. To wskaźnik rozkładu z tekstu o zamknięciu miesiąca, przełożony z dokumentów na deklaracje. Albo się rusza, albo nie.

Zastanawiacie się, czy problem gotowości w Waszym biurze to problem z danymi, czy nieopisany filtr? Odezwijcie się. Trzy miesiące eksportów atrybutów to rozstrzygają — i jest to znacznie krótsza rozmowa niż pisanie specyfikacji.