Sekwencyjny numer faktury restartowany z nowym rokiem

robertos7778 napisał(a):

Tak w ogóle jeśli zajmujesz się takimi rzeczami, to warto spotkać się z osobą, która obsługuje system do faktur w praktyce. Powie ci o wielu rzeczach, o których byś nawet nie pomyślał. Wydaje mi się, że próbujesz ponownie wynaleźć koło i na siłę sam kombinujesz nie znając specyfiki tematu.
Jeśli ma to być realny system, a nie jakaś wprawka programistyczna, to nie pomijaj etapu analizy - oszczędzisz sobie bólu głowy później (albo wk* klientów dzwoniących 31 grudnia, że czegoś nie mogą zrobić).

Oj, taka analiza to temat rzeka, ale z własnego doświadczenia wdrożeniowego powiem, że łatwo nie jest - nierzadko trafia się jakiś jegomość, który na etapie zbierania założeń nie wspomni o swojej nietypowej potrzebie, a potem się okazuje, że w krytycznym momencie system go blokuje i wielkie pretensje, że przypadek jest nieobsłużony. Analityk robi wielkie oczy, że pierwszy raz w życiu spotyka się z takim zapotrzebowaniem, a klient zapytany, czemu nie wspomniał o tym w założeniach, odpowiada, że przecież potrzeba była oczywista i w Excelu się to dało prosto zrobić :)

Ciekawy wątek. Ale nikt nie wspomniał, że skoro to aplikacja w PHP (bo tak zrozumiałem szybko przeglądajac) na jakimś hostingu to wystarczy wywołać zadanie CRON-a o północy i zmienić numer na zgodny z nowym rokiem, ja bym to nazwał PREFIX_numeru_faktury i zapisywał do oddzielnej tabeli, nawet jakiejś tylko 3 pozycyjnej.
Np.

CREATE TABLE `prefix_numeru_faktury`(
  `id` int(11) NOT NULL,
  `year` varchar(4)  DEFAULT NULL,
  `status` tinyint(1) NOT NULL DEFAULT 1 COMMENT '1=Active | 0=Inactive'
) ENGINE=InnoDB;

Wtedy można pobrać ostatni rekord w ten sposób i dodawać do numeru faktury do innej tabeli.

SELECT * FROM prefix_numeru_faktury ORDER BY id DESC LIMIT 1

Temat trochę ostygnął to ja Wam napiszę jak ja to robię w systemie e-commerce gdzie generuje się miesięcznie średnio po kilkadziesiąt tysięcy faktur.

Jest tabela na fakturę gdzie jest kolumna na numer kolejny faktury w danym miesiącu, oraz kolumna oznaczająca dany rok, oraz kolumna na dany miesiąc - czyli trzy kolumny: nr, miesiąc, rok - na które jest nałożony unikalny indeks, tak że nie może być na poziomie bazy danych dwóch faktur o tym samym numerze w tym samym miesiącu danego roku.

W momencie tworzenia nowej faktury wygląda to tak:

1. Start transakcji
2. Pobranie faktury z danego miesiąca z ostatnim numerem, z klauzulą FOR UPDATE - czyli ekskluzywny lock, żaden inny proces nie może pobrać tego rekordu
3. Jeżeli w pkt 2) znaleziono fakturę, generujemy kolejną fakturę z numerem faktury z pkt 2) + 1
4. Jeżeli w pkt 2) nie znaleziono faktury (brak faktury w tym miesiącu), generujemy fakturę o numerze 1, jednocześnie przechwytując błąd/wyjątek polegający na tym, że faktura z nr 1 już istnieje - bo ta procedura zawsze może być wywoływana przez inny wątek / proces. W przypadku wystąpienia takiego błędu indeksu, wracamy do pkt 2).
5. Koniec transakcji

To jest o tyle lepsze od różnych generatorów kolejnych liczb (jak chociażby typ SERIAL w PostgreSQL), że praktycznie gwarantuje, że w numeracji nie będzie dziur, a z tego co pamiętam, w przypadku faktur jest to prawnie wymagane.