Sekwencyjny numer faktury restartowany z nowym rokiem

0
ZrobieDobrze napisał(a):

BTW właśnie testuję myślowo swoją własną hipotezę "co, jeśli z wysokopoziomowej warstwy nie dysponujemy wiarygodnym lockiem" ... katastrofy nie ma. Na potencjalnych konfliktach wychodzi mi najwyżej zmarnowanie numeru (baza OPRÓCZ pola stringowego z formatowanym numerem, ma 3 pola z grupową unikalnością: typ, nr mies (zero dla numeracji rocznej), numer (adekwatnie: w roku / w miesiacu))

Co masz na myśli pisząc o zmarnowaniu numeru? Generalnie ustawa o rachunkowości mówi, że numeracja dokumentów musi być ciągła. To oznacza, że nie możesz pominąć żadnego numeru.

0
Fac napisał(a):
ZrobieDobrze napisał(a):

BTW właśnie testuję myślowo swoją własną hipotezę "co, jeśli z wysokopoziomowej warstwy nie dysponujemy wiarygodnym lockiem" ... katastrofy nie ma. Na potencjalnych konfliktach wychodzi mi najwyżej zmarnowanie numeru (baza OPRÓCZ pola stringowego z formatowanym numerem, ma 3 pola z grupową unikalnością: typ, nr mies (zero dla numeracji rocznej), numer (adekwatnie: w roku / w miesiacu))

Co masz na myśli pisząc o zmarnowaniu numeru? Generalnie ustawa o rachunkowości mówi, że numeracja dokumentów musi być ciągła. To oznacza, że nie możesz pominąć żadnego numeru.

A dokument który istniał, ale LUDZIE skasowali go ze względów wyższych ?

Tak, wiem, w duchu ustawy "anulowanie" by było właściwe. W realnym życiu i tak to wyłączają / porzucają procedurę anulowania. Dopóki w zakresie 1-2 dni, wiesz, ja nawet z tym nie walczę
Wniosek ? I tak frmy maja ręczne pomysły

BTW UoR mówi o numeracji dziennika
W moim scenariuszu wychodzi zmarnowanie tylko wtedy, gdy dwóch handlowców intensywnie klepie FV, i ten szybszy o milisekundy dostał wyjatek
(tu znów wraca pytanie: co odbija najważniejsze reguły walidacji czy podobne: kod SQL, czy kod warstwy, jak kod wyższy - do zmarnowania prawdopodobnie nie dojdzie)

2

A patrzyłeś na sekwencje? https://www.postgresql.org/docs/9.1/functions-sequence.html
Jak maiłby to robić to albo na sekwencjach i np. z nowym rokiem reset licznika.
Albo w odrębnej tabeli trzymać następny wolny numer a w tabeli z fakturami już sformatowany. I wtedy wraz z poprawnym insertem faktury dokonać aktualizacji tego licznika.
Pytanie co masz w warunkach biznesowych dokładnie. Czy są możliwe scenariusze kasowania faktury lub jakiegoś poprawienia numeracji?

0

Faktura, moze byc skasowana, tak.

1

Skoro faktura może być kasowana to ja poszedłbym w odrębną tabelę trzymająca aktualny licznik. Przy insert faktury odczyt obecnego licznika, stworzenie na jego podstawie dedykowanego formatu i insert wraz z pełnym numerem. To samo przy kasowaniu plus warunek, że kasować w pełni można tylko ostatnią fakturę.

0
jurek1980 napisał(a):

Skoro faktura może być kasowana to ja poszedłbym w odrębną tabelę trzymająca aktualny licznik. Przy insert faktury odczyt obecnego licznika, stworzenie na jego podstawie dedykowanego formatu i insert wraz z pełnym numerem. To samo przy kasowaniu plus warunek, że kasować w pełni można tylko ostatnią fakturę.

Jak się zgodzimy, że jest tabela wyliczająca wszystkie typy dokumentów i ich specyficzne zasady (w tym numeracji), to jest ważne. Ty nazywasz tabelą liczników (per year?), ja typów dokumentów (per year ??? nie mam pewnosci), podobne, przynajmniej na tym poziomie dochodzenia do dyskusji

Dla mnie prowadzenie licznika czy max(invoices) to już wtórne, kwesta implementacyjna.
Rzeczywiście zachowuje się odmiennie w przypadku kasowania ostatniej, zalezy jakie wymagania biznesu

1

@poniatowski: Czy ten pendig status wymaga już numeru? Czemu nie tworzycie więc jakiejś proformy z odrębnym numerem? Nie wiem dla jakiego kraju to robisz i czy tam nie ma jakichś innych zasad związanych z księgowością. Bo mam dziwne wrażenie, że wszyscy tu myślą w kontekście PL.

Edit na szybko znalazłem coś takiego https://www.codeguru.com/database/generate-complex-next-numbers-with-sql-server/

1

Nie znam się, ale się wypowiem ;)
Według mnie w bazie danych powinieneś mieć przynajmniej dwie kolumny dot. numeru. Jedną typu int - kolejny numer w miesiącu/roku oraz drugą typu string - pełny numer, który zawiera w sobie kolejny numer, miesiąc, rok ew. inne rzeczy typu jakiś symbol, serie etc.
Dodatkowo w tabeli powinieneś przechowywać schemat numeracji tj. czy to ma być NUMER/MM/RRRR czy NUMER/RRRR czy SYMBOL/NUMER/MM/RRRR itd.
Jak będziesz miał numer w postaci int to wydobycie kolejnego numeru jest banalne => musisz wybrać MAX Numer w danym miesiącu/roku w zakresie wybranej numeracji.

Dodatkowo uważam, że za nadanie kolejnego numeru w roku/miesiącu powinna odpowiadać baza danych a nie jakiś PHP (kto w ogole w tym jeszcze programuje?!).

Widzę również, że ponownie wróciła dyskusja dot. ciągłości numeracji więc zwrócę tylko uwagę, że to, że ustawa o VAT (a nie UoR) wymaga ciągłości w numeracji ale to nie znaczy, że program musi być mądrzejszy od użytkownika. Z zawodu jestem księgowym i wiem, że jest masa sytuacji, gdzie ten numer trzeba zmienić, poprawić, zastąpić, usunąć itd. Do czasu, gdy faktura nie trafi do obiegu (nie zostanie przekazana klientowi) można z nią zrobić praktycznie wszystko. A nawet jak trafi do obiegu to z praktycznego doświadczenia wiem, że firmy i tak często dokonują zmian na takich dokumentach z różnych powodów.

0
jurek1980 napisał(a):

A patrzyłeś na sekwencje? https://www.postgresql.org/docs/9.1/functions-sequence.html
Jak maiłby to robić to albo na sekwencjach i np. z nowym rokiem reset licznika.
Albo w odrębnej tabeli trzymać następny wolny numer a w tabeli z fakturami już sformatowany. I wtedy wraz z poprawnym insertem faktury dokonać aktualizacji tego licznika.
Pytanie co masz w warunkach biznesowych dokładnie. Czy są możliwe scenariusze kasowania faktury lub jakiegoś poprawienia numeracji?

Wydaje mi sie, ze dobrze podpowiadasz i pojde z sekwencja. Sama sekwecja to juz tabela z jednym wierszem. I nie musze nakladac LOCK na tabeli. Do tego usuniete faktury sa soft-delete wiec w sumie tez ok, bo na usunietych fakturach tez musze miec numer. Wiec w moim przypadku jest ok, nie wiem jak w innych.

Do tego chce przechowywac rok oraz caly, sformatowany numer w 2 oddzielnych kolumnach oraz sekwencja. Brzmi jak dobre rozwiazanie.

Teraz tylko zastanawiam sie jak restartowac ta sekwencje. Troche obawiam sie uzywania triggerow. Nie wiem czemu, ale zawsze mysle, ze ktos moze go usunac przypadkowo, bo nie bedzie rozumial poco on jest. Moge opcjonalnie z poziomu PHP sprawdzic czy last_invoice_year < current_year. Jezeli true to z PHP wywoloac zapytanie SQL i zrestartowac sekwencje. Nie wiem czy jest jakikolwiek sense umieszczania tej logiki w bazie danych.

1

Rozważ co zajmie Ci więcej czasu i będzie mniej kłopotliwe w utrzymaniu. Częste przypadki z praktyki

Klient zaczyna z system i stwierdza, że koszty będzie wprowadzał jednym rejestrem numerowanym w ramach roku. Więc luz tworzysz sekwencje i jedziesz w ramach roku od 1.
Gdzieś pod koniec roku, stwierdza, że numerowanie roczne jest bez sensu, bo faktury nie spływają na czas i często zdarza mu się że faktura z wyższym numerem jest starsza od wcześniejszych.
Postanawia, że od nowego roku zmienia numerację na miesięczną.
Teraz sytuacja się zmienia i kupuje coraz więcej z UE w eur. Więc postanawia dodać nowy symbol do wyróżnienia tych faktur.
I wspomniany tu już case z przełomem roku, idą już faktury z nowego, ale ciągle jest wprowadzany poprzedni.

Jeżeli uważasz, że sekwencja jest na tyle elastyczna, że to ogarnie to ok. IMO to się nie sprawdzi.

1 użytkowników online, w tym zalogowanych: 0, gości: 1