Data sprzedaży na fakturze: jak ustalić ją w sklepie internetowym

Data wystawienia opisuje moment wystawienia dokumentu, a data sprzedaży na fakturze odnosi się do dostawy towaru, wykonania usługi albo określonej sytuacji dotyczącej otrzymania zapłaty. Ministerstwo Finansów wskazuje, że faktura zawiera datę wystawienia oraz, jeśli jest określona i różni się od daty wystawienia, datę dokonania lub zakończenia dostawy albo wykonania usługi; w opisanym przypadku uwzględnia się również datę otrzymania zapłaty przed dokonaniem czynności.

Daty mogą być identyczne, jeśli dostawa lub usługa i wystawienie dokumentu przypadają tego samego dnia. Mogą się różnić, gdy faktura jest wystawiana później albo gdy zdarzenie mające znaczenie dla konkretnej transakcji wystąpiło wcześniej. Szczególne rodzaje dostaw, usług, zaliczek i rozliczeń okresowych mogą podlegać odrębnym regułom, dlatego moment podatkowy potwierdź z księgowością.

W KSeF struktura faktury rozdziela datę wystawienia od daty dostawy lub wykonania usługi. Ministerstwo Finansów opisuje w strukturze FA element P_6 dla wspólnej daty oraz P_6A, gdy pozycje mają różne daty. Zasady daty wystawienia faktury ustrukturyzowanej zależą też od trybu jej przesłania do KSeF, więc przy wdrożeniu KSeF w Subiekcie GT nie należy wyprowadzać tej daty z czasu utworzenia zamówienia w sklepie.

Wybór daty wymaga ustalenia, co rzeczywiście sprzedano i które zdarzenie ma znaczenie dla danego dokumentu. Poniższa tabela porządkuje pytania do weryfikacji, ale nie zastępuje kwalifikacji księgowej transakcji.

Nie ustawiaj automatycznie daty sprzedaży na dzień wysyłki tylko dlatego, że sklep zmienia wtedy status na Zrealizowane. Status może oznaczać wydruk etykiety, przekazanie paczki przewoźnikowi lub samo zamknięcie zadania magazynowego. Zdefiniuj, jakie potwierdzenie zdarzenia zapisuje system, i uzgodnij jego znaczenie z księgowością.

Jeśli sklep obsługuje kilka modeli dostawy, utwórz oddzielne scenariusze testowe dla kuriera, punktu odbioru i odbioru osobistego. Dla każdej ścieżki ustal, czy źródłem zdarzenia jest potwierdzenie przewoźnika, zmiana statusu w panelu czy ręczne potwierdzenie pracownika.

Data złożenia zamówienia jest zapisem intencji zakupu, a nie automatycznym dowodem dostawy lub wykonania usługi. Data autoryzacji płatności może też różnić się od daty pobrania środków, rozliczenia przez operatora i faktycznego wpływu pieniędzy.

W raportowaniu sklepu warto zachować osobne pola dla `date_created`, daty płatności, daty wysyłki, daty dostawy i daty dokumentu. Nazwy techniczne zależą od wersji WooCommerce, wtyczek i integracji, dlatego dla każdego pola zapisz opis biznesowy oraz źródłowy system. W ten sposób można odtworzyć, czy różnica wynika z przebiegu transakcji czy z błędnego mapowania.

Najpierw ustal źródło prawdy dla każdego zdarzenia, a dopiero później przypisz je do pól ERP i fakturowania. WooCommerce dokumentuje ustawienia ogólne w panelu WooCommerce > Ustawienia > Ogólne; strefę czasu witryny sprawdzisz w WordPress > Ustawienia > Ogólne > Strefa czasowa. Przy imporcie zamówień dokumentacja WooCommerce wskazuje, że daty `created_at` powinny odpowiadać strefie czasowej witryny docelowej.

Ustaw jedną strefę czasu operacyjną dla witryny, a przesyłane znaczniki czasu serializuj z informacją o strefie lub offsetem. W raporcie porównuj daty w tej samej strefie. Błąd może ujawnić się przy zamówieniu blisko północy, zmianie czasu albo imporcie z witryny skonfigurowanej inaczej.

W mapowaniu integracji dodaj osobne pola źródłowe zamiast nadpisywać jedną datę kolejnymi zdarzeniami. Zapisz też identyfikator zdarzenia z systemu magazynowego lub operatora płatności, aby można było odtworzyć drogę wartości podczas diagnozy.

Przepływ powinien przenosić uzgodnione zdarzenie do właściwego pola dokumentu bez zamiany go na datę utworzenia zamówienia. Typowy łańcuch wygląda tak: zamówienie w WooCommerce, potwierdzone zdarzenia płatności i realizacji, reguła mapowania w integracji, dokument w ERP lub programie fakturowym, a następnie eksport do KSeF.

W fakturze ustrukturyzowanej FA(3) pole P_1 dotyczy daty wystawienia. Pole P_6 opisuje wspólną dla faktury datę dokonania lub zakończenia dostawy albo wykonania usługi, o ile jest określona i różni się od daty wystawienia. Oficjalny opis struktury wskazuje także P_6A dla różnych dat dotyczących poszczególnych pozycji; właściwy wariant zależy od struktury faktury i sytuacji.

KSeF nadaje fakturze numer identyfikujący, który nie jest tym samym co numer faktury nadany przez sprzedawcę. Sprawdź, czy integracja zachowuje oba identyfikatory oraz zapisuje wynik walidacji i odpowiedź systemu. Sama poprawna walidacja techniczna pliku nie potwierdza, że wybrana data odpowiada właściwemu zdarzeniu gospodarczemu.

Przed uruchomieniem przepływu zatwierdź z księgowością tabelę: scenariusz sprzedaży, źródłowe zdarzenie, pole w systemie fakturowym i pole struktury KSeF. Wdrożenie KSeF w sklepie internetowym powinno uwzględniać próbne dokumenty oraz obsługę wyjątków, a faktury w sklepie internetowym omawiamy szerzej w kontekście obiegu dokumentów.

Diagnozę zacznij od dokumentu i przejdź wstecz do źródłowego zdarzenia, zamiast od razu poprawiać datę ręcznie. Zapisz numer faktury, identyfikator zamówienia, czas utworzenia dokumentu, identyfikator przebiegu integracji i odpowiedź systemu fakturowego.

Następnie odtwórz przepływ na kopii zamówienia testowego. Porównaj datę i strefę czasu w źródle, log integracji oraz dokument w ERP. Jeśli wszystkie wartości po drodze są zgodne z konfiguracją, problem może dotyczyć samej reguły biznesowej; jej interpretację uzgodnij z księgowością, a nie przez zmianę techniczną pola.

Testy powinny obejmować zmiany stanu zamówienia po wystawieniu dokumentu, ponowienia integracji i zdarzenia częściowe. Każdy scenariusz opisz oczekiwanym polem, wartością źródłową i zachowaniem dokumentu.

• Wysyłka częściowa: sprawdź, czy integracja nie przypisuje jednej daty do wszystkich pozycji, jeśli realizacja odbywa się etapami.
• Zwrot lub anulowanie: potwierdź, czy system tworzy właściwy proces dokumentowy i nie nadpisuje historii pierwotnego zamówienia.
• Ponowienie zadania: wyślij ponownie ten sam identyfikator zdarzenia i sprawdź, czy nie powstaje drugi dokument ani nowa data bez przyczyny.
• Zmiana strefy czasu: przetestuj zdarzenie tuż przed północą oraz po zmianie ustawienia witryny na środowisku testowym.
• Zmiana statusu: zmień status ręcznie i automatycznie, a następnie porównaj zapisane czasy oraz logi.

Korektę wystawionego dokumentu uzgadnia się z księgowością. Nie poprawiaj historii zamówienia po to, by uzyskać oczekiwaną datę na dokumencie, bo można utracić informację o tym, kiedy faktycznie zaszły poszczególne zdarzenia.

Przed uruchomieniem sprawdź, czy zespół potrafi prześledzić datę od dokumentu do zdarzenia źródłowego. Akceptację oprzyj na przypadkach testowych, a nie tylko na tym, że faktura została wygenerowana.

Zapisz właściciela reguły, wersję mapowania, datę akceptacji i sposób zgłaszania wyjątków. Dla wdrożeń obejmujących sklep i fakturowanie przydatne są też materiały o konfiguracji faktur w WooCommerce oraz kosztach integracji faktur dla sklepu online.

• Integracja API KSeF: jak zaplanować połączenie i testy
• Porównanie cen Sellasist i Apilo w Excelu: policz koszt dla swojego sklepu
• IFIRMA i KSeF: cennik, dostępne funkcje i koszty
• Jak przygotować personalizację produktów w Excelu do importu do sklepu