Rozmowa o KSeF w sklepie internetowym prawie zawsze zaczyna się od pytania „którą wtyczkę zainstalować”. Pytanie o narzędzie, zadane w momencie, gdy nikt nie odpowiedział jeszcze na pytania o proces. Z mojej perspektywy, jako kogoś, kto od lat spina sklepy z systemami finansowymi, wtyczka jest ostatnim klockiem w tej układance. Nie pierwszym. A rzeczy, które później kosztują najwięcej, biorą się z decyzji podjętych na długo przed tym, zanim ktokolwiek dotknął kodu integracji.
Spis treści
Wtyczka to interfejs, nie proces fakturowania
Rozszerzenie do sklepu zbuduje dokument i wyśle go do bramki. Spoko. Tylko nie rozstrzyga, kiedy ten dokument ma w ogóle powstać, a to jest cały sens wdrożenia. W e-commerce złożenie zamówienia, zaksięgowanie płatności i wydanie towaru to trzy osobne zdarzenia, rozsunięte w czasie i obarczone zupełnie różnym ryzykiem.
Najczęstszy błąd? Sklep wystawia fakturę w chwili złożenia zamówienia, przelew nigdy nie przychodzi, a w rejestrze siedzi już dokument do korekty. Druga skrajność, czyli fakturowanie dopiero po wysyłce, potrafi rozjechać okresy rozliczeniowe przy zamówieniach z przełomu miesiąca.
Sensowna decyzja polega na zdefiniowaniu wyzwalacza fakturowania w warstwie logiki biznesowej, po stronie serwera, z wypisanymi wprost wyjątkami: przedpłata, pobranie, płatność odroczona, zamówienie częściowo zrealizowane. Ustawienia wtyczki mają wtedy tę decyzję odwzorować, a nie ją za nas podjąć. Dopiero na tym etapie integracja sklepu z KSeF przestaje być kwestią konfiguracji, a staje się kwestią projektu.
Dane kontrahenta: skąd sklep ma wiedzieć, komu wystawia
Rejestr obsługuje obrót między firmami, a sprzedaż konsumencka rządzi się inną logiką. Sklep musi rozdzielić te ścieżki już na poziomie koszyka, zanim klient kliknie „zamawiam”. Doklejanie identyfikatora podatkowego do zamkniętego zamówienia to prosta droga do błędów i korekt.
Samo pole NIP w formularzu? Za mało. Potrzebna jest walidacja formatu i sumy kontrolnej, sprawdzenie kraju, no i spójność z resztą danych adresowych, bo klient wpisujący numer firmy przy prywatnym adresie dostawy to codzienność. Do tego klienci zagraniczni, numery VAT UE, procedura OSS i sprzedaż przez marketplace. Każde z tych mapowań dokłada swoje.
Osobny temat, zwykle mocno niedoszacowany: konta założone lata temu, z niepełnymi albo nieaktualnymi danymi. Przy migracji trzeba je uzupełnić, oznaczyć albo świadomie wyrzucić z automatycznego fakturowania. Inaczej automat wygeneruje stos dokumentów, których nikt później nie obroni.
KSeF w e-commerce a systemy, które już masz
Sklep rzadko jest jedynym miejscem, gdzie powstaje faktura. Obok działa magazyn, ERP, program do fakturowania i biuro rachunkowe, a każdy z tych systemów historycznie miał prawo wystawić dokument. Po podłączeniu rejestru ta wielotorowość przestaje być drobną niewygodą i robi się realnym ryzykiem.
Klasyczna awaria wdrożeniowa to podwójna wysyłka. Ten sam dokument leci do bramki ze sklepu i z systemu magazynowego, bo nikt nie ustalił, kto jest źródłem prawdy. Wychodzi to zwykle po fakcie, przy uzgadnianiu sprzedaży za okres. Tego samego pytania nie da się ominąć przy takich wdrożeniach jak integracja z Subiektem i Optimą, gdzie numeracja dokumentów musi mieć jednego właściciela.
Decyzja architektoniczna brzmi banalnie, a organizacyjnie boli: jeden punkt emisji dokumentów, reszta systemów wyłącznie konsumuje numer i status. Integrację warto oprzeć na kolejce zdarzeń, nie na synchronicznym wywołaniu, bo finalizacja zamówienia nie może czekać na odpowiedź zewnętrznej bramki. Klient ma zobaczyć potwierdzenie zakupu niezależnie od tego, co dzieje się dalej w tle.
Awarie, limity i bezpieczeństwo po stronie serwera
Bramka bywa niedostępna, a sklep nie może z tego powodu wstrzymać sprzedaży. Potrzebna jest trwała kolejka dokumentów, ponowienia z rosnącym odstępem i wyraźny stan „czeka na wysyłkę”, widoczny dla obsługi, a nie tylko w logu technicznym gdzieś na serwerze.
Co realnie trzeba monitorować
- dokumenty zalegające w kolejce dłużej niż ustalony próg,
- dokumenty odrzucone przy walidacji struktury, z zapisaną treścią błędu,
- zbliżające się wygaśnięcie tokenów, certyfikatów i sesji,
- opóźnienie między utworzeniem faktury a nadaniem jej numeru w rejestrze,
- rozjazd liczby dokumentów między sklepem a systemem finansowym za ten sam okres.
Bez alertów każdy z tych problemów wychodzi dopiero przy zamknięciu miesiąca. Czyli wtedy, gdy poprawki są najdroższe i robi się je pod presją czasu.
Poświadczenia w publicznie dostępnej aplikacji
Dostęp do rejestru to realne uprawnienia do dokumentów firmy. Trzymanie go w tabeli opcji, jawnym tekstem, jest bombą z opóźnionym zapłonem. Sklep to aplikacja wystawiona na świat i skanowana codziennie, zupełnie inny profil ryzyka niż wewnętrzny ERP schowany za firewallem.
Rozsądny wzorzec przenosi obsługę poświadczeń do warstwy pośredniej, w zaufanym środowisku. Sklep publikuje wtedy samo zdarzenie biznesowe i nie zna żadnych sekretów. Przy większym ruchu i rozbudowanej logice bywa, że kończy się to decyzją o migracji na dedykowany backend. Osobno projektuje się retencję logów i archiwizację dokumentów, bo to wymagania, których żadna wtyczka za nikogo nie załatwi.
Korekty, zwroty i reklamacje, czyli codzienność sklepu
Zwrot towaru w sprzedaży internetowej to norma, nie incydent. Skoro tak, korygowanie musi być zautomatyzowane dokładnie w tym samym stopniu co wystawianie. Inaczej cała oszczędność z automatyzacji ląduje na biurku księgowości.
Korekta odwołuje się do numeru dokumentu pierwotnego, więc ten numer musi być trwale powiązany z zamówieniem w bazie sklepu. Nie w logu integracji, który po miesiącu zostanie zrotowany. Widziałem to kilka razy – brak ujawnia się dopiero przy pierwszym poważnym zwrocie i wtedy jest już nieprzyjemnie.
Zwroty częściowe, wymiany towaru i rabaty przyznane po sprzedaży wymagają odwzorowania pozycji zamówienia, nie samej kwoty zbiorczej. Nieudane wdrożenie poznaję po jednym objawie: korekty robi się ręcznie w innym programie i nigdy nie wracają do sklepu. Dane w obu miejscach zaczynają wtedy żyć własnym życiem.
Struktura kosztu wdrożenia i utrzymania
Licencja wtyczki to tu najmniejsza pozycja i zarazem najgłośniej dyskutowana. Budżet napędzają trzy inne rzeczy: liczba systemów do spięcia, jakość danych historycznych oraz liczba wyjątków w procesie sprzedaży, czyli wszystko, co odbiega od zwykłego zamówienia opłaconego z góry.
Utrzymanie kosztuje w rytmie zmian, nie równomiernie. Aktualizacje schematu dokumentu, modyfikacje interfejsu bramki, migracje sklepu, podmiany bramek płatności, aktualizacje samych wtyczek – każda z tych rzeczy potrafi naruszyć integrację dokładnie wtedy, gdy nikt się tego nie spodziewa.
Dlatego środowisko testowe i powtarzalny, odtwarzalny deployment to nie luksus, tylko sposób na to, żeby jedna zmiana nie zatrzymała sprzedaży na kilka godzin. A największym ukrytym kosztem i tak zostaje ręczna praca księgowości w sytuacji, gdy automat obsługuje wyłącznie ścieżkę szczęśliwą, a wszystkie odstępstwa spadają na ludzi.
Podsumowanie: wtyczka na koniec, nie na początku
Kolejność, która się sprawdza, jest odwrotna do intuicyjnej. Najpierw mapa procesu sprzedaży i wskazanie źródła prawdy dla dokumentów, potem projekt integracji i obsługi błędów, a konkretne narzędzie wybieramy na końcu, gdy już wiadomo, co ma robić.
Sygnały, że projekt zmierza w złą stronę, widać wcześnie: nikt nie jest właścicielem procesu po stronie biznesu, nie ma monitoringu ani alertów, korekty powstają poza systemem. Każdy z tych objawów da się naprawić. Tylko taniej jest zrobić to przed startem niż po pierwszym zamknięciu miesiąca.
W Web Systems od 2006 roku projektujemy integracje, automatyzacje i systemy B2B wokół sklepów internetowych. Jeśli planujesz wdrożenie sklepu internetowego, porządkujesz obieg dokumentów albo myślisz o modernizacji sklepu i systemów wokół niego, napisz do nas i porozmawiajmy o zakresie.
