Uprawnienia do API KSeF - jakie konkretnie są wymagane dla systemu ERP?

Z uprawnieniami to rzeczywiście może być pokręcone. Ja w swojej aplikacji do KSeF robiłem to tak: Administrator firmy w panelu KSeF tworzy **użytkownika uprawnionego** (nie pełnomocnika) i nadaje mu konkretnie: - `invoice.write` - do wysyłania faktur - `invoice.read` - do pobierania UPO i sprawdzania statusów - `session.init` - do logowania przez API Pełnomocnik to overkill dla integracji ERP - ma za dużo uprawnień. Użytkownik uprawniony wystarczy i jets bezpieczniejszy. Co do certyfikatów - **dostawca ERP ma rację**. Toen z KSeF to wystarczy, nie trzeba dodatkowego podpisu kwalifikowanego. System sam podpisuje faktury po stronie MF gdy używasz `InitToken`. Ja testowałem to dokładnie i działa bez problemów. ```python # Przykład jak sprawdzić uprawnienia po zalogowaniu session_info = requestsget( f"{base_url}/api/online/Session/Status", headers={"SessionToken": session_token} ) print(session_info.json()["authorisationChallenge"]["challenge"]) ``` Jedno konto techniczne dla kilku księgowych to OK, ale lepiej zrobić osobne dla audytu. Ja polecam jedno knto per system/aplikacja, a nie per osoba. Btw, jakie konkretnie błędy dostajesz na produkcji? Bo czasem to kwestia rate limitów albo źle skonfigurowanego środowiska.

Wiktor ma rację co do struktury uprawnień, ale pozwolę sobie doprecyzować kilka kwestii z perspektywy prawnej. Zgodnie z **art. 106n ust. 3 ustawy o VAT** oraz rozporządzeniem w sprawie KSeF, rzeczywiście wystarczający jest status "użytkownika uprawnionego" z odpowiednimi uprawnieniami. Kluczowe jest tutaj poprawne skonfigurowanie uprawnień w zakresie: - `InvoiceWrite` - wysyłanie faktur strukturalnych - `InvoiceRead` - pobieranie UPO oraz weryfikacja statusów - `CredentialsManage` - jeśli planujecie rotację tokenów **Certyfikaty kwalifikowane nie są wymagane** dla integracji API - to potwierdza § 8 ust. 2 rozporządzenia w sprawie KSeF. System używa mechanizmu InitToken, który zapewnia odpowiedni poziom bezpieczeństwa zgodny z wymogami rozporządzenia eIDAS. Co do konta technicznego - z praktyki polecam utworzenie dedykowanego użytkownika dla integracji ERP, niezależnie od liczby księgowych. Ułatwia to audyt i zarządzanie dostępami. Pamiętajcie tylko o odpowiednim zabezpieczeniu tokenów (najlepiej w HSM lub przynajmniej zaszyfrowane w bazie). Jakie konkretnie kody błędów otrzymujecie na produkcji? Bo różnica między demo a prod często wynika z limitów czasowych zapytań lub niewłaściwej konfiguracji certyfikatów TLS dla środowiska produkcyjnego.

Kolega Wiktor i Anna bardzo dobrze opisali kwestię uprawnień, ale pozwolę sobie dodać kilka uwag z perspektywy praktycznej implementacji w kancelarii. Rzeczywiście, **użytkownik uprawniony** to optymalne rozwiązanie dla integracji ERP. Zgodnie z § 12 ust. 2 rozporządzenia w sprawie KSeF, taki użytkownik może wykonywać czynności w imieniu podatnika w zakresie nadanych uprawnień. Pełnomocnik ma zbyt szerokie uprawnienia i może stanowić niepotrzebne ryzyko bezpieczeństwa. Ważna kwestia, o której nie wspomnieliście - **rotacja tokenów**. W środowisku produkcyjnym tokeny mają ograniczoną ważność (zgodnie z wymogami bezpieczeństwa z art. 106o ustawy o VAT). Upewnijcie się, że wasz ERP obsługuje automatyczne odnawianie sesji, bo inaczej integracja będzie się "zacinać" co kilka godin. Co do błędów na produkcji - często spotykam się z problemem **rate limitów**. Środowisko demo jest znacznie bardziej "wyrozumiałe" niż produkcja. System może blokować zbyt częste zapytania lub zbyt duże pakiety faktur wysyłane jednocześnie. Sprawdźcie czy nie wysyłacie faktur zbyt agresywnie. Jeszcze jedna praktyczna uwaga - jeśli macie kilku księgowych, zdecydowanie polecam osobne konta dla każdego, ale z jednym wspólnym kontem technicznym dla ERP. Ułatwia to późniejszy audyt i kontrolę, kto co robił w systemie. Pamiętajcie też o odpowiednim logowaniu po stronie ERP - MF może żądać szczegółowych logów w przypadku kontroli. Jakie konkretnie kody błędów otrzymujecie? To pomoże zdiagnozować problem.