Fakturowanie offline w Verifactu: tryb incydentu a założenie łączności TicketBAI
Dwa hiszpańskie systemy fiskalne traktują łączność inaczej. Verifactu pozwala fakturować przez awarię i synchronizować później. Projekt TicketBAI zakłada, że jesteś online. Co to znaczy dla POS, pracy w terenie i operacji multi-regionalnych.
Fakturowanie offline w Verifactu: tryb incydentu a założenie łączności TicketBAI
Łączność pada. Restauracje tracą internet w środku serwisu, technicy pracują w piwnicach, lokalizacje wiejskie działają na słabych łączach. Jak twój system fiskalny zachowuje się podczas awarii, to nie techniczna przypinka; to decyduje, czy możesz legalnie wystawiać faktury dalej. Dwa hiszpańskie reżimy odpowiadają na to pytanie inaczej.
Verifactu: sformalizowany tryb incydentu
Verifactu zawiera ustrukturyzowany tryb incydentu (modo de incidencia). Gdy połączenie z AEAT pada, zgodny SIF może:
- Wystawiać faktury normalnie dalej, każdą z jej niezmiennym zapisem fakturowania, hashowanym lokalnie w łańcuch
- Kolejkować oczekujące zapisy lokalnie
- Synchronizować zakolejkowane zapisy, gdy łączność wróci, w wymaganych oknach
Właściwości antyfraudowe przetrwują awarię, bo są lokalne: łańcuch, hash i kod QR nie zależą od kontaktu w czasie rzeczywistym z administracją podatkową. W trybie Verifactu (z wysyłką) przesyłka nadrabia po przywróceniu połączenia. W trybie tylko zapisu nic nie było wysyłane; zapisy siedzą w lokalnym archiwum, dostępne na żądanie.
Czego tryb incydentu nie pozwala: wystawiać faktury poza zgodnym SIF "bo internet padł". Notatnik i długopis podczas awarii to nie tryb incydentu. To niezarejestrowane fakturowanie.
TicketBAI: założenie łączności
Projekt TicketBAI zakłada stałą łączność internetową. Każda faktura generuje swój podpisany XML i przesyła go do prowincyjnego urzędu skarbowego w czasie rzeczywistym lub bliskim rzeczywistemu. Nie ma równoważnego sformalizowanego mechanizmu awaryjnego w projekcie systemu.
Dla firm w Alavie, Bizkaii i Gipuzkoi zmienia to pytanie infrastrukturalne z "co robimy podczas awarii" na "jak czynimy awarie rzadkimi i krótkimi":
- Redundantna łączność w lokalizacjach stałych: łącze główne i awaryjne w punktach o dużym natężeniu POS
- Kolejki z jasnym statusem operatora: oprogramowanie musi obsługiwać awarie przesyłki płynnie, pokazywać operatorowi dokładnie, które faktury oczekują na przesyłkę, i ponawiać automatycznie
- Wyraźne procedury dla pracy o dużym udziale offline: targi, food trucki, instalacje wiejskie potrzebują ustaleń spójnych z oczekiwaniami organu prowincjalnego, nie improwizowanych obejść
Porównanie, które ma znaczenie
| Verifactu | TicketBAI | |
|---|---|---|
| Zależność kluczowa | Lokalna integralność (łańcuch hasha) | Przesyłka w czasie rzeczywistym |
| Zachowanie przy awarii | Sformalizowany tryb incydentu: wystawiaj offline, synchronizuj później | Brak sformalizowanego awaryjnego; łączność założona |
| QR na fakturze | Tak, weryfikacja AEAT | Tak, weryfikacja TBAI |
| Zasięg regionalny | Krajowe wspólne terytorium | Alava, Bizkaia, Gipuzkoa (Batuz w Bizkaii) |
Planowanie według typu firmy
Gastronomia i handel (POS)
POS to miejsce, gdzie awarie bolą najbardziej: serwis nie może się zatrzymać. Pod Verifactu potwierdź, że twoje oprogramowanie kasowe implementuje tryb incydentu naprawdę, z lokalnym łańcuchem i automatyczną synchronizacją, nie tylko przyciskiem ponów. Pod TicketBAI redundancja łączności to kontrola podstawowa; drugie łącze awaryjne na SIM to tanie ubezpieczenie przy kasie z kartą i gotówką.
Usługi terenowe i rzemiosła
Faktury wystawiane na miejscu z telefonu lub tabletu. Pod Verifactu tryb incydentu pokrywa scenariusz piwnicy-bez-zasięgu, jeśli aplikacja rejestruje i kolejkuje lokalnie. Pod TicketBAI projekt zakłada, że faktura czeka na zasięg. Zbuduj przepływ tak, by faktura była szkicowana na miejscu i wystawiana po powrocie łączności, z jasnym rozumieniem operatora, kiedy prawnie istnieje.
Operatorzy multi-regionalni
Grupa z podmiotami w Madrycie (Verifactu), Bilbao (TicketBAI plus Batuz) i Pampelunie (NaTicket) prowadzi trzy zachowania fiskalne z jednego stacka operacyjnego. Decyzja oprogramowania to nie "czy obsługuje Hiszpanię", lecz "czy implementuje zachowanie przy awarii, łańcuch i raportowanie każdego reżimu per podmiot". Konfiguracja na poziomie podmiotu, nie kraju.
Testowanie twojego zachowania przy awarii
Raz, zanim będzie potrzebne:
- Wyciągnij kabel sieciowy. Wystaw dziesięć faktur. Sprawdź, że każda ma swój zapis, swoją pozycję w łańcuchu i swój QR.
- Połącz ponownie. Zweryfikuj, że kolejka synchronizuje się w pełni, po kolei, bez luk i bez duplikatów.
- Sprawdź dziennik zdarzeń. Awaria i ponowna synchronizacja powinny być widocznymi zdarzeniami. Kontroler może zapytać.
- Dla podmiotów TicketBAI: zweryfikuj status zwrócony do operatora. Które faktury oczekują na przesyłkę, musi być jednoznaczne na ekranie.
- Udokumentuj test w twojej dokumentacji procesów. Zachowanie przy awarii jest częścią opisu systemu.
Typowe błędne odczytania
"Tryb incydentu Verifactu oznacza, że papierowy zapas jest w porządku." Nie. Tryb incydentu działa wewnątrz zgodnego SIF. Papierowe faktury podczas awarii są poza łańcuchem.
"TicketBAI ma taki sam awaryjny jak Verifactu." Nie ma. Projekt zakłada łączność. Planuj infrastrukturę, nie wyjątki.
"Jeden hiszpański stack oprogramowania pokrywa wszystkie regiony automatycznie." Reżimy regionalne mają różne schematy, punkty końcowe i zachowania przy awarii. Weryfikuj per podmiot, per prowincja.
"Awarie to szczegół IT." W sfiskalizowanym systemie zachowanie przy awarii definiuje, kiedy faktura prawnie istnieje. To decyzja operacyjna z konsekwencjami zgodności.
Ten materiał ma charakter ogólnej informacji i nie stanowi porady prawnej ani podatkowej. W konkretnej sytuacji zweryfikuj aktualne przepisy lub skonsultuj się z wykwalifikowanym doradcą.