Fakturowanie i KSeF w sklepie internetowym

Dla sklepu, który sprzedaje jednocześnie firmom i konsumentom, to znaczy jedno: dokument trzeba wystawić i dodatkowo wysłać, przy czym tylko część dokumentów podlega wysyłce. Robienie tego ręcznie przy kilku zamówieniach dziennie jest do przeżycia. Przy kilkudziesięciu przestaje być, a pomyłka w tym miejscu nie kosztuje reklamacji, tylko korekty i tłumaczenia.

Domyślny tryb wysyłki odwzorowuje dokładnie tę granicę. Faktura dla nabywcy z numerem NIP idzie do KSeF, faktura dla konsumenta nie. Istnieje też tryb, który nie wysyła nigdy, ale należy on do środowiska deweloperskiego i testów, nie do żywego sklepu.

Dlatego proces dzieli zamówienia na trzy grupy zamiast dwóch. Te, które bez wątpliwości podlegają fakturowaniu, dostają fakturę. Te, które bez wątpliwości nie podlegają, są pomijane z zapisanym powodem. Reszta czeka na człowieka, a odłożenie sprawy jest tu normalnym wynikiem, nie awarią.

Powody pominięcia to zamknięta i konkretna lista: zamówienie już zafakturowane, sprzed ustawionej daty startu, w walucie spoza konfiguracji, anulowane albo nie w pełni opłacone. Żaden z nich nie generuje błędu, bo żaden błędem nie jest.

Numer szukany jest więc kolejno w metadanych zamówienia, w metadanych adresu rozliczeniowego i wreszcie w polu nazwy firmy przy tym adresie. Kluczowe jest jednak to, co dzieje się dalej: znaleziony ciąg przechodzi walidację sumy kontrolnej. Jeżeli nie jest poprawnym polskim NIP-em, zamówienie zostaje sprzedażą konsumencką i nie trafia do KSeF.

Zagraniczny numer VAT dostaje własną ścieżkę. Wygląda podobnie na tyle, że łatwo o pomyłkę, a potraktowanie go jak NIP oznaczałoby wysłanie do KSeF dokumentu, który nie powinien tam trafić.

Jedynym źródłem jest inFakt i żaden stary system nie jest czytany. O tym, czy dokument należy do zamówienia, decydują trzy twarde warunki. Data faktury musi mieścić się w tolerancji wokół warszawskiego dnia kalendarzowego zamówienia, domyślnie siedem dni, najwyżej trzydzieści jeden. Nabywca musi zgadzać się dokładnie: znormalizowany NIP przy zamówieniu firmowym, a przy konsumenckim dokładny adres e-mail albo dokładne znormalizowane imię i nazwisko. Kwota brutto musi zgadzać się co do grosza, bez tolerancji.

Nazwy pozycji nie są sygnałem w ogóle, bo opisy produktów bywają na fakturach poprawiane, a dopasowywanie po zbliżonej nazwie to najprostsza droga do przypisania jednego dokumentu do dwóch różnych zamówień. Odczyt zawsze jest próbny, a zapis pozostaje próbny, dopóki nie dostanie wyraźnego polecenia zastosowania zmian.

Samo przypisanie jedynie odnotowuje dokument, który już istnieje. Nie powstaje żadna faktura, nic nie leci do KSeF i nie jest emitowane zdarzenie o wystawieniu, więc nic dalej w systemie nie zachowa się tak, jakby właśnie pojawił się nowy dokument.

Warto też wiedzieć, jak wtyczka zachowuje się, zanim cokolwiek zdecydujesz. Bez skonfigurowanego klucza API nie robi nic. Po skonfigurowaniu fakturowanie nadal startuje wstrzymane. Ponad tym jest jeszcze osobny wyłącznik w zmiennych środowiskowych. Ta bezczynność jest celowa: najgorszy możliwy scenariusz dla systemu fakturowego to paczka dokumentów wystawionych w dniu instalacji, których nikt nie chciał wystawić.

Rozwijamy ją otwarcie i opisujemy w dokumentacji medusa-infakt, więc powyższe reguły możesz sprawdzić, zamiast brać je na słowo.