ExKSeF na telefonie

Mobilny ExKSeF startuje od konfiguracji adresu instancji, sprawdza połączenie z API i dopiero potem pozwala na logowanie. Dzięki temu telefon może pracować z właściwą instalacją klienta, bez wpisywania technicznych adresów w kodzie aplikacji.

Po zalogowaniu aplikacja pobiera profil użytkownika, firmę, aktywne uprawnienia i środowisko KSeF. Dashboard pokazuje nazwę firmy, wersję aplikacji i kafelki pogrupowane tak samo jak web: Zakupowe, Płatności, Sprzedaż i Słowniki. Nie ma tu oddzielnej logiki dostępu: kafelek pojawia się tylko wtedy, gdy użytkownik ma odpowiednie uprawnienie.

To ważne przy wdrożeniach z wieloma rolami. Pracownik, który ma obsługiwać tylko płatności, nie dostaje na telefonie skrótu do faktur sprzedażowych. Osoba pracująca z kontrahentami nie widzi operacji bankowych. Router mobilny dodatkowo pilnuje bezpośredniego wejścia w adres ekranu i zawraca użytkownika do pulpitu, jeżeli rola nie obejmuje danego modułu.

Telefon obsługuje najważniejsze ekrany operacyjne, ale nie udaje pełnego desktopu. Wybór funkcji jest podporządkowany pracy w ruchu: szybkie sprawdzenie faktury, przeniesienie pozycji do płatności, import historii bankowej, kontrola statusu i podgląd kontrahenta.

Zakupowe

Ekran Przychodzące pokazuje nowe faktury do decyzji. Operator może pobrać faktury z KSeF, potwierdzać zaufanie sprzedawcy, uzupełnić formę płatności, wskazać rachunek bankowy, obsłużyć kolejkę nowych kontrahentów i przenieść wybrane faktury do płatności. Wariant daty płatności działa jako mobilna opcja trybu pracy, a nie przypadkowy przełącznik na liście.

Ekran Faktury zakupowe daje pełniejszy widok archiwalny: wyszukiwanie po numerze, kontrahencie, NIP i numerze KSeF, sumy, doczytywanie poprzednich miesięcy oraz markery korekt, MPP, załączników, faktur zerowych i automatycznie opłaconych.

Płatności

Nadchodzące grupują pozycje po statusie, domyślnie eksponując płatności gotowe do eksportu. Użytkownik może zaznaczać tylko pozycje dopuszczone do pliku, wygenerować przelew, zapisać go przez systemowe okno Androida, odświeżyć statusy w banku i wczytać historię bankową, jeżeli rola mu na to pozwala.

Opłacone działają jako szybki rejestr zrealizowanych płatności, z zakresem pobierania ustawianym w administracji. Spodziewane pokazują płatności wynikające z historii i cykliczności, bez mieszania ich z przelewami gotowymi do banku.

Sprzedaż i słowniki

W sprzedaży telefon rozdziela faktury robocze od faktur przyjętych przez KSeF. Na liście roboczej dostępna jest selekcja i wysyłka do KSeF, a na liście przyjętych widać status płatności, korekty, przeterminowanie oraz szczegóły dokumentu. Słownik kontrahentów pozwala szybko sprawdzić dane, rachunki i adresy bez przechodzenia do weba.

W aplikacji mobilnej role wpływają na trzy poziomy zachowania.

1. Pulpit ukrywa całe kafelki modułów, do których użytkownik nie ma dostępu.

2. Router blokuje bezpośrednie wejście w ekran bez wymaganego uprawnienia i odsyła użytkownika do dashboardu.

3. Akcje na ekranach pojawiają się tylko wtedy, gdy rola obejmuje daną operację, na przykład eksport płatności, import historii bankowej, odświeżenie statusów albo wysyłkę faktur do KSeF.

Dzięki temu aplikacja mobilna nie generuje serii błędów 403 jako normalnego sposobu pracy. Brak prawa do funkcji jest widoczny wcześniej: użytkownik po prostu nie dostaje kafelka, przycisku lub pozycji menu.

Dystrybucja aplikacji jest wpisana w system. Administrator wgrywa plik APK w narzędziach webowych, podaje numer wersji, a serwer zapisuje aktualny pakiet w katalogu danych instalacji. Ten sam pakiet jest potem dostępny do pobrania z administracji oraz przez endpoint używany przez telefon.

Po wejściu na dashboard aplikacja sprawdza raz dziennie, czy serwer ma nowszą wersję. Jeżeli tak, pokazuje dialog aktualizacji, pobiera APK z postępem i przekazuje plik do systemowego instalatora Androida. Ręczne sprawdzenie jest dostępne w mobilnej administracji, więc użytkownik nie musi czekać na kolejny automatyczny cykl.

Po zalogowaniu telefon rejestruje token push, a przy wylogowaniu próbuje go wyrejestrować jeszcze na aktywnej sesji. Po wgraniu nowej wersji administrator może wysłać powiadomienie do zarejestrowanych urządzeń. To zamyka praktyczny obieg utrzymania: build, publikacja, komunikat do użytkowników i instalacja po stronie telefonu.

Zębatka na telefonie prowadzi do krótkiej administracji dobranej do mobilnego scenariusza. Administrator może ustawić domyślne zakresy pobierania dla faktur zakupowych, opłaconych płatności i faktur sprzedażowych, określić domyślne zwinięcie grup na liście przychodzących, sprawdzić status usług oraz pobrać wyciągi bankowe, jeżeli rola obejmuje O→M.

Konfiguracja, która powinna być centralna, zostaje w webie. Mobile korzysta z ustawień i wywołuje operacje, ale nie tworzy drugiego źródła prawdy dla odbiorców maili, parametrów banku czy ról. To świadoma granica: telefon jest wygodnym klientem operacyjnym, a nie równoległym panelem konfiguracyjnym.

Mobilna aplikacja łączy kilka elementów, które często rozjeżdżają się w projektach biznesowych: sesję cookie z API webowego, role i uprawnienia współdzielone z desktopem, lokalne preferencje widoków, Androidowe zapisywanie plików, instalację APK, push tokeny oraz integracje bankowe.

Najważniejsze decyzje projektowe są praktyczne:

• jeden model uprawnień dla weba i mobile, zamiast osobnych list funkcji,

• miękkie błędy przy aktualizacji i push, żeby problemy sieciowe nie blokowały pracy,

• oddzielenie widoków operacyjnych od centralnej konfiguracji administracyjnej,

• widoki list zoptymalizowane pod telefon: wyszukiwanie, sumy, grupowanie, markery i doczytywanie miesięcy,

• integracja z systemowymi mechanizmami Androida: biometria, zapis pliku, instalator APK i powiadomienia.

Dla osoby oceniającej projekt to dobry fragment kodu do przejrzenia, bo pokazuje nie tylko UI, ale też konsekwencję w przeniesieniu reguł biznesowych na drugi klient systemu.