Mam w swojej aplikacji wystawianie faktur, baza SQL tabela zlecenia plus klient gdzie id klient występuje w obydwu tabelach wiadomo z jakiego powodu czyli dane klienta w tabeli klient to numerek w zleceniach. Wystawiając paragon nie ma znaczenia zmiana danych klienta ale wystawiając fakturę nie powinno się chyba zmieniać w niej niczego (do tego jest faktura korygująca). Główna zasada w budowaniu bazy danych z tego co się nauczyłem polega na tym żeby unikać redundancji a w tym wypadku nie widzę innego wyjścia jak w kolejnej tabeli która zawiera dane faktury umieścić dane klienta co pozwoli na uniknięcie zmiany danych klienta na wystawionej fakturze. Dane klienta przecież mogą się zmienić z różnych powodów ale nie może to chyba powodować zmiany zawartości dokumentu fiskalnego. Wydaje mi się ze bez umieszczenia danych klienta w tabeli faktur się nie obędzie, nieprawdaż? Chyba że inaczej się to rozwiązuje. Byłbym wdzięczny za podpowiedzi.
Hej Mariusz,
przepraszam, gdzieś mi umknęło Twoje pytanie.
Można podejść do tego dwojako:
- Skopiować szczegółowe dane klienta (stan na dzień wystawiania faktury) do tabeli z fakturami. Wtedy masz odniesienie do ID KLIENTA, ale dane adresowe i rejestrowe są skopiowane. Nawet jeśli zmienią się w przyszłości, masz je zarchiwizowane z tamtego momentu. Zajmuje to trochę więcej miejsca niż sam klucz obcy do tabeli KLIENTÓW, ale nie ma się czym przejmować.
- Możesz trzymać tylko ID do KLIENTA, ale wtedy musisz przechowywać wszystkie zmiany w tabeli KLIENTA (czyli zrobić wersjonowanie w strukturze tabeli). Robi się to np. tak, że każdy wiersz w tabeli KLIENCI ma swoje ID (traktowane jako ID konkretnej wersji) i ID KLIENTA. Wtedy Faktury mają odniesienie do konkretnego ID z tabeli KLIENCI, więc dane zostają z tamtego momentu. Nawet jeśli pojawi się nowa wersja danych klienta (nowe ID), to odniesienie z faktury zostanie do starego ID. Tylko wtedy musisz pamiętać, że nie robisz żadnych UPDATE’ów na wierszach, tylko dodajesz nowy wiersz z kolejną wersją konkretnego klienta.
Temat jest na tyle ciekawy, że chyba zrobię o tym osobny wpis 🙂
Pozdrawiam i powodzenia,
Marcin
Może łatwiej byłoby podpiąć pod to fakturownię albo inFakt? Zawiłości księgowych jest masę, a prawo też się zmienia z roku na rok, przez co będziesz musiał cały czas rozwijać to oprogramowanie. A tak po API połączysz się z serwisem fakturującym, który ogarnie Ci resztę 🙂
Zdecydowanie dobrze Pan radzi 🙂 Dziękujemy za polecenie.
Zapraszamy do fakturownia.pl przez pierwsze 30 dni można przetestować nasz program zupełnie za darmo, a następnie przejść na pakiet MICRO za 0zł. Przekona się Pan czy może nasze rozwiązanie, spełni oczekiwania jakie są niezbędne w codziennej pracy.
Twoje rozwiązanie wydaje się poprawne, ale specjalistą nie jestem.
Dzięki za odpowiedz, pierwsza opcja bardziej mi pasuje bo jest prostsza a kilka pół więcej w bazie to żaden problem.
A’propos zrobienia osobnego wpisu na temat faktur to by była super sprawa bo się z tym namęczyłem i to nie chodzi o kodowanie a o wiedzę czysto ksiegową(gotówka a do tego obsługa kasy czyli KP i KW, karta, przelew itp.).
Teraz zacząłem robić logikę faktur korygujących i tez za bardzo nie wiem jak to ogarnąć jeśli chodzi o bazę SQL no i obsługę tego przez PHP.
Pozdrawiam