0

Jak numerować faktury offline żeby potem nie było kolizji?

PodatkowyNinja15 lut0 wyświetleń

Cześć,

Mam problem z implementacją numeracji faktur na wypadek awarii KSeF. Wiem że w trybie offline numerujemy wg swojego schematu, ale co dalej?

Moje pytania:

1. Jak zapewnić że numery offline nie skollizują z normalnymi numerami online?

2. Czy mogę użyć prefiksu typu `OFF/` dla faktur offline?

3. Jak wy to rozwiązujecie w swoich systemach?

Na razie myślę nad czymś takim:

```python

def generate_offline_number(base_number):

return f"OFF/{datetime.now().year}/{base_number:04d}"

```

Ale nie jestem pewien czy to dobry pomysł. Teoretycznie po powrocie do trybu online te faktury i tak lądują w KSeF z ich oryginalnymi numerami offline, więc nie powinno być problemu?

Jak wy to macie ogarnięte? Może ktoś ma działające rozwiązanie które mógłby wrzucić?

Z góry dzięki!

4 odpowiedzi

0
Cześć! Ja dopiero zaczynam ogarniać ten cały KSeF, ale też się nad tym zastanawiałam. Z tego co czytałam, to faktury offline mają swoje numery i potem jak je wysyłasz do KSeF to system przydziela im numer KSeF osobno, ale ten oryginalny numer offline zostaje. To znaczy ten prefiks OFF/ powinien działać, bo to nadal Twój wewnętrzny schemat numeracji. Ważne żeby był unikalny w obrębie Twojej firmy. Mam pytanie - a co jak awaria będzie długa i zrobisz dużo faktur offline? Jak potem je wszystkie wysyłasz do systemu, to w jakiej kolejności? Bo jak rozumiem muszą być w KSeF w kolejności chronologicznej, tak? Może ktoś kto już to testował na demo mógłby potwierdzić jak to działa w praktyce? Dzięki!
0
Dokładnie tak jak mówi Danuta - numery offline zostają, a KSeF przydziela swoje. My w startupie poszliśmy podobnie jak proponujesz, tylko z małą modyfikacją: ```python def generate_offline_number(base_number): timestamp = int(datetime.now().timestamp()) return f"OFFLINE/{datetime.now().year}/{timestamp}-{base_number:04d}" ``` Dodałem timestamp żeby mieć pewność unikalności nawet jak ktoś zresetuje licznik. Może przesada, ale lepiej dmuchać na zimne. Co do kolejności wysyłania - testowałem to na demo i KSeF przyjmuje faktury w dowolnej kolejności, ale **data wystawienia** musi być logiczna. Czyli jak masz faktuę z 15.01 i 20.01, to nie możesz wysłać tej z 20.01 przed tą z 15.01. System to waliduje. Jedna rzecz na którą warto uważać - jak długo trzymasz faktury offline, to lepiej mieć jakiś mechanizm do batch'owego wysyłania. Bo jak się nazbiera 50+ faktur, to pojedyncze POST'y zajmą wieki. My robimy paczkami po 10 i działa spoko. A jeszcze jedno - sprawdź czy Twój system księgowy nie ma jakichś ograniczeń na format numerów. Niektóre starsze systemy potrafią się wykłócić z długimi prefiksami.
0
Wdrozeniowiec3 dni temu
Zgadzam się z podejściem z prefiksem `OFF/` - to bezpieczne rozwiązanie które używaliśmy w kilku projektach. Tylko bym dodał jezcze jedną warstwę zabezpieczenia na poziomie architektury. W dużych systemach które projektowałem mieliśmy osobne sequence'y dla numeracji onlnie i offline. Coś w stylu: ```python # Online: FV/2024/01, FV/2024/002... # Offline: OFF/2024/001, OFF/2024/002... ``` Ale kluczowa rzecz to **synchronizacja po powrocie do trybu online**. My zaimplementowaliśmy queue z priorytetami gdzie faktury offline mają wyższy priorytet niż nowe faktury online. Dzięki temu jak system wróci do żżycia to najpierw wyślę wszystkie zaległe faktury offline w odpowiedniej kolejności chronologicznej, a dopiero potem nowe. Co do batch'owania - FakturyBezStresu ma rację, ale uwaga na rate limiting. KSeF ma limity na poziomie 100 requestów/minutę dla jednego tokena. Jak masz dużo faktur offline to lepiej zaimplementować exponential backoff i moitoring response headers żeby nie dostać 429. Jeszcze jedna rzecz - pamiętaj o UPO dla faktur offline. System musi być przygotowany na to że fakury wysłane z opóźnieniem mogą dostać błędy walidacji których online by nie było (np. zmiana stawek VAT, nowe kody GTU). Warto mieć mechanizm do ręcznej weryfikacji takich przypadków. Testowałeś już swoje rozwiązanie na demo z symulowaną awarią? Bo teoria to jedno, a praktyka potrafi zaskoczyć.
0
VATreturns_PL3 dni temu
Twoje podejście z prefiksem `OFF/` jest w porządku i faktycznie nie będzie kolizji bo numery offline zostają w systemie jako oryginalne numery faktur. Jednak bym zmienił jedną rzecz w Twoim kodzie: ```python def generate_offline_number(base_number): return f"OFF/{datetime.now().year}/{datetime.now().month:02d}/{base_number:04d}" ``` Dodałem miesiąc żeby uniknąć problemów jak będziesz miał długą awarię na przełomie lat. Plus ułatwia to potem wyszukiwanie faktur offline w systemie księgowym. Z praktyki - tstowałem to na demo i rzeczywiście KSeF przyjmuje faktury offline z opóźnieniem bez problemu. Ważne żeby **data wystawienia** była wcześniejsza niż data wysłania, ale to oczywiste. Jedna rzecz o której koledzy nie wspominali - pamiętaj o **UPO dla faktur offlin*e*. Jak wysyłasz z opóźnieniem to UPO generuje się normalnie, ale klient może się dziwić czemu dostaje potwierdzenie po tygodniu od wystawienia faktury. Warto to jakoś komunikować. Co do batch'owania - zgoda z FakturyBezStresu, ale uwaga na **kolejność dat wystawienia**. Jak masz faktury offline z różnych dni to KSeF wymaga żeby były wysłane chronologicznie. Inaczej dostaniesz błąd walidacji. Testowałeś już swoje rozwiązanie na demo z większą liczbą faktur offline? Bo teoria to jedno, a jak się nazbiera 20+ faktur to mogą być niuanse któryhc nie przewidzisz.

Twoja odpowiedź

Zaloguj się, aby odpowiedzieć w tej dyskusji.