Projektowanie dokumentu typu Faktura UML i Baza danych

07:13 Jakub Bauman 14 Comments

Prowadząc zajęcia często spotykam się u studentów z problemami ze zrozumieniem czym jest i jak powinno się zaprojektować w systemie informatycznym dokument taki jak Faktura.
Posłużę się przykładem faktury jednak idea jaką zaprezentuje dotyczy wszelkich dokumentów.

Budowa dokumentu Faktura

Po pierwsze należy sobie uświadomić co powinna zawierać faktura. Wymienię tu najważniejsze elementy:

W nagłówku:

• Numer
• Data wystawienia
• Data sprzedaży
• Dane kontrahenta
• Termin płatności (*)
• Kwota brutto do zapłaty (**)

(*) - W bardziej złożonych systemach możemy rozważać wiele terminów płatności
(**) - Kwota brutto faktury nie zawsze będzie tożsama z kwotą do zapłaty np. gdy występowały wcześniej zaliczki


Pozycje faktury:

• Liczba porządkowa
• Nazwa towaru/usługi
• Cena jednostkowa
• Ilość
• Jednostka miary
• Wartość

Pozostałe

• Tabela VAT
• Tabela zaliczek
• Tabela płatności 

Jedna faktura - wiele pozycji

Projektując diagram klas UML czy diagram ERD dla baz należy przede wszystkim zwrócić uwagę na to, że na jednej fakturze może wystąpić wiele pozycji. Zatem projektując musimy rozważać dwie klasy i analogicznie dwie tabele bazy danych:

• Nagłówek Faktury
• Pozycje Faktury

Jak nietrudno się domyślić klasy te (jak i tabele) powinny być w relacji 1 do n. Jedna faktura ma n pozycji.

Dane kontrahenta w fakturze

Projektując tabelę nagłówkową można założyć, że znajdzie się w niej klucz obcy wskazujący na kontrahenta. Natomiast w UML klasa nagłówka będzie posiadała atrybut typu Kontrahent.
Warto tutaj zwrócić uwagę na to, że faktura jest dokumentem, który według przepisów należy przechowywać w niezmienionej formie. Zmiana danych adresowych kontrahenta nie może pociągać za sobą zmiany danych na zapisanej w bazie fakturze. Mamy tutaj dwie możliwości.

1. Przepisać dane do dokumentu 
2. Zwielokrotnić rekordy kontrahenta

W pierwszym rozwiązaniu naruszamy oczywiście drugą postać normalną bazy danych, jednak to rozwiązanie jest znacznie częściej wybierane przez projektantów systemów ERP i dodatkowo jest bardziej wydajne obliczeniowo oraz pozwala na realizację dostępu do danych za pomocą zapytań SQL o mniejszej złożoności składniowej.
Drugie rozwiązanie jest z punktu widzenia teorii baz danych bardziej poprawne jednak powoduje większą złożoność zapytań SQL jakich należy używać aby pobierać dane, a tym samym większą złożoność obliczeniową.

Zwiększenie mocy obliczeniowej jest znacznie droższe niż zwiększenie pamięci dyskowej komputera zatem ekonomia wskazuje również na pierwsze rozwiązanie.

Towary w pozycjach faktury

Kolejnym błędem jest interpretacja polegająca na tym, że pozycje faktury to towary. Nic bardziej mylnego.Towar to jeden z elementów pozycji. Pozycja zawiera również co najmniej informacje: o sprzedawanej ilości, o cenie sprzedaży...
Projektując system informatyczny mamy na celu usprawnienie pracy poprzez wybór towarów z tzw. kartoteki zatem klasa Towar, czy tabela Towary w bazie danych jest jak najbardziej zasadna jednak nie jest ona tożsama z pozycją.
Towary pozostają w relacji 1 do n do pozycji faktury. Jeden towar może wystąpić w wielu pozycjach dokumentów.

Inne elementy dokumentu

Dokumenty typu faktura powinny zawierać również informację o płatności. W prostych systemach można to rozwiązać wprowadzając pole termin płatności do nagłówka. Nie jest to jednak rozwiązanie zbyt dobre gdyż uniemożliwia wystawianie faktur zawierających wiele płatności. Na przykład przy zakupie jakaś wpłata gotówką, a pozostała kwota przelewem w określonym terminie. Inny przykład to plan wpłat. Dlatego należałoby utworzyć tabelę płatności w relacji 1 do n do nagłówka faktury.
Tabela taka powinna zawierać informacje takie jak:
- sposób płatności
- termin płatności
- kwota

Suma kwot płatności powinna być taka sama jak wartość brutto faktury.

Inny element jaki powinien być uwzględniony przy projektowaniu dokumentu typu faktura to informacja o zasobach (pozycjach przychodowych). Gdy stosujemy na przykład algorytm FIFO to przy sprzedaży rozchodujemy towar wg kolejności w jakiej pojawił się na magazynie. Zasadę tę wyjaśnia film . Gdy stosujemy taki algorytm magazynowy może się zdarzać, że gdy sprzedajemy towar pochodzi on z różnych partii zakupowych, które mogą mieć różne ceny. Wówczas na przykład na potrzeby kalkulacji marży powinniśmy powiązać pozycje faktury z pozycjami dokumentów zakupowych. Oczywiście to powiązanie jest bardziej zasadne w dokumencie PZ. Dlaczego? To zostanie wyjaśnione w osobnym artykule.

Autor zdaje sobie sprawę, że powyższy artykuł nie wyczerpuje tematu. Żywi jednak nadzieję, że chociaż w pewnym stopniu będzie pomocny dla projektujących systemy biznesowe.