Korekty faktur VAT - jak przechowywać?

0

Mam tablice:
tabFakturyVat
tabPozycjeFakturyVat

Jak przechowywać w bazie danych Korekty do faktur vat? Do każdej pozycji w fakturze VAT musi być jakoś przypisana dana poprawka z korekty?

Jak to najlepiej rozwiązać?

1

Ja bym dał dodatkową relację, która by przechowywała naszą FakturyKorygujące. Byśmy tam mieli klucz obcy do tabeli z FakturamiVAT. Dzięki temu byśmy mieli informacje do jakiej faktury VAT jest ta faktura korygująca. Oczywiście niezbędne są tam atrybuty typowe dla faktury korygującej takiej jak data i przyczyna. W relacji pozycjeFaktury dodałbym klucz obcy do relacji FakturKorygujacych. Dzięki temu miałbym pozycje w tej fakturze. Oczywiście można to rozwiązać inaczej, jak przechowywać w jednej tabeli wszystkie faktury korygujące i te normalne z informacją, która jest która. Głównie moja propozycja rozdzielenia tego wynika, że w fakturze korygującej muszą się znaleźć specyficzne dla niej atrybuty.

Mała uwaga - nie tablice, a tabele/relacje. Dwa - jeżeli nazewnictwo 'tab' w Twojej bazie wynika tylko z tego, że to są 'tablice' dla Ciebie to nie lepiej nazwać je po prostu 'FakturaVAT', zamiast 'tabFakturaVat' ?.

0
mariano901229 napisał(a):

Oczywiście można to rozwiązać inaczej, jak przechowywać w jednej tabeli wszystkie faktury korygujące i te normalne z informacją, która jest która. Głównie moja propozycja rozdzielenia tego wynika, że w fakturze korygującej muszą się znaleźć specyficzne dla niej atrybuty.
I takie rozwiązanie jest o niebo lepsze. Trzymając korekty w oddzielnej tabeli utrudnia się robienie zestawień, czy nawet pobieranie wykazu faktur. Chyba nie zrobisz w programie oddzielnego okna do edycji korekty? Tak samo jak będziesz miał wykaz w programie faktur, to wypadałoby aby korekty też tam były. A tych dodatkowych rzeczy jest na tyle mało, że nie opłaca się tworzyć nowej tabeli.

Rozróżnienie warto zrobić poprzez typ faktury. Bo przecież są i inne typy faktur:

  • faktury krajowe
  • paragony
  • korekty
  • zaliczki
  • faktury dewizowe (w tym zaliczki, korekty)
  • faktury eksportowe (tu też zaliczki, korekty, dodatkowo rozróżnia się eksport wewnątrzunijny oraz zewnątrzunijny)
  • faktury marża
  • faktura wewnętrzna

I każda z nich ma nieco inny zestaw danych. Chyba nie będziesz tworzyć dla każdej z nich nowej tabeli?
Po prostu trzeba w tabeli faktur dodać pole FakturaTyp i już. Warto trzymać również ID faktury korygowanej.

A wiązanie pozycji raczej nie ma sensu. Trzeba w fakturze korygującej mieć pozycje przed korektą i po korekcie. Przed korektą oczywiście nie można zmieniać (musi być taka sama jak w fakturze korygowanej) natomiast edycja tyczy się pozycji po korekcie. Więc potrzeba mieć jeszcze znacznik na pozycjach czy to przed czy po korekcie. Takie podejście też szalenie upraszcza robienie zestawień sprzedaży np. danego towaru.

0

Rozwiązanie zależy od potrzeb użytkownika i aplikacji, jednakże masz rację w tym konkretnym przypadku.

Mr.YaHooo napisał(a):

Rozróżnienie warto zrobić poprzez typ faktury. Bo przecież są i inne typy faktur:

  • faktury krajowe
  • paragony
  • korekty
  • zaliczki
  • faktury dewizowe (w tym zaliczki, korekty)
  • faktury eksportowe (tu też zaliczki, korekty, dodatkowo rozróżnia się eksport wewnątrzunijny oraz zewnątrzunijny)
  • faktury marża
  • faktura wewnętrzna

Problem różnych atrybutów dla tych faktur można rozwiązać też w taki sposób, że mamy osobną tabelę z kategoriami faktur i do kategorii są przyporządkowane konkretne typy atrybutów. Podobny problem został opisany tutaj - http://stackoverflow.com/questions/221584/what-is-best-practice-for-this-problem-different-properties-for-different-categ - nie tyczy się faktur, ale produktów i kategorii (każda kategoria ma swoje atrybuty).

3
Mr.YaHooo napisał(a):

I każda z nich ma nieco inny zestaw danych. Chyba nie będziesz tworzyć dla każdej z nich nowej tabeli?

Ale czemu nie? Są trzy sposoby implementacji dziedziczenia w bazach danych, każdy z nich jest dobry do czegoś innego. Ty proponujesz Table Per Hierarchy, które skutkuje tabelą z milionem kolumn i w 2/3 wypełnioną nullami, moim zdaniem to nie jest fajne. Table Per Class nie ma tej wady.
A zestawienia to nie problem - od zestawień są widoki, nie tabele.

0
mariano901229 napisał(a):

Problem różnych atrybutów dla tych faktur można rozwiązać też w taki sposób, że mamy osobną tabelę z kategoriami faktur i do kategorii są przyporządkowane konkretne typy atrybutów. Podobny problem został opisany tutaj - http://stackoverflow.com/questions/221584/what-is-best-practice-for-this-problem-different-properties-for-different-categ - nie tyczy się faktur, ale produktów i kategorii (każda kategoria ma swoje atrybuty).
Też ciekawe rozwiązanie. Generalnie należałoby przemyśleć co kto woli :)

somekind napisał(a):

Ty proponujesz Table Per Hierarchy, które skutkuje tabelą z milionem kolumn i w 2/3 wypełnioną nullami, moim zdaniem to nie jest fajne. Table Per Class nie ma tej wady.
To prawda. Jest natomiast pewna przewaga takiego rozwiązania. Otóż jeśli damy do edycji usera słownik typów faktur (akurat u mnie w pracy tak jest) gdzie może on sobie dodawać wedle własnej woli typy faktur sprzedaży (w słowniku może sobie zaznaczyć czy to korekta, dewiza, wybrać typ faktury korygującej jaką automatycznie wystawi system i jeszcze masę innych rzeczy) to trzeba będzie tworzyć/usuwać/zmieniać tabele po każdej edycji w słowniku. Widziałem kiedyś takie rozwiązanie i było nieco toporne. Tak przy okazji to klient rekordzista ma ponad 75 typów faktur, nie pytaj mnie tylko dlaczego. Jakoś średnio by mi się podobało tworzenie tylu tabel w bazie dla samych faktur, o wiele prościej dla mnie trzymać w 1 tabeli i mieć tych nulli nieco.

somekind napisał(a):

A zestawienia to nie problem - od zestawień są widoki, nie tabele.
Tu się zgodzę. Jednak i tak jestem zwolennikiem aby zapytania były bardziej proste, szczególnie dla danych które user chce widzieć na bieżąco.

0
Mr.YaHooo napisał(a):

To prawda. Jest natomiast pewna przewaga takiego rozwiązania. Otóż jeśli damy do edycji usera słownik typów faktur (akurat u mnie w pracy tak jest) gdzie może on sobie dodawać wedle własnej woli typy faktur sprzedaży (w słowniku może sobie zaznaczyć czy to korekta, dewiza, wybrać typ faktury korygującej jaką automatycznie wystawi system i jeszcze masę innych rzeczy) to trzeba będzie tworzyć/usuwać/zmieniać tabele po każdej edycji w słowniku. Widziałem kiedyś takie rozwiązanie i było nieco toporne. Tak przy okazji to klient rekordzista ma ponad 75 typów faktur, nie pytaj mnie tylko dlaczego. Jakoś średnio by mi się podobało tworzenie tylu tabel w bazie dla samych faktur, o wiele prościej dla mnie trzymać w 1 tabeli i mieć tych nulli nieco.

Ale czym się te typy od siebie różnią? Mają jakieś dodatkowe atrybuty? Bo przecież lista typów dokumentów fakturowych jest ustalona przez władze i to, jakie dane mają zawierać - również. Nie bardzo rozumiem jak niby zwykły człowiek ma sobie swoje własne typy faktur wymyślać?

0
somekind napisał(a):

Ale czym się te typy od siebie różnią? Mają jakieś dodatkowe atrybuty?
Generalnie to zależy.

somekind napisał(a):

Bo przecież lista typów dokumentów fakturowych jest ustalona przez władze i to, jakie dane mają zawierać - również.
Tak i tych typów jest tak:

  • faktura,
  • korekta,
  • zaliczka,
  • rozliczenie zaliczki.

Z drugiej strony mamy również taki zestaw atrybutów:

  • faktura krajowa,
  • faktura dewizowa,
  • eksport wewnątrzunijny
  • eksport zewnątrzunijny.

Czyli mamy 4x4 to daje nam 16 różnych kombinacji atrybutów. Do tego dochodzą jeszcze paragony fiskalne, faktury uproszczone, faktura marża, faktura wewnętrzna, faktura małego podatnika. A to tylko sprzedaż. Do tego jeszcze dojdzie Ci zakup. W zakupie też jest tego masę.

somekind napisał(a):

Nie bardzo rozumiem jak niby zwykły człowiek ma sobie swoje własne typy faktur wymyślać?
A no dlatego, że chociażby chce mieć niezależną numerację sprzedaży np. usług oraz tych z magazynu, czy nawet w zależności od osoby wystawiającej fakturę. Możesz mi wierzyć lubi nie. Ale w Polsce mamy takie molochy które wymagają od dostawców tego, aby wystawiane dla nich faktury za towary które kupują miały kolejną numerację bez dziur i to na dodatek z własnym układem faktury zawierającym jakieś dodatkowe informacje zupełnie bzdurne z punktu widzenia innych klientów (sic!). Jak się tego nie spełni nie chcą kupować towarów. A żeby nie było nie są to jakieś regionalne firemki, ale ogólnopolskie czy też nawet ogólnoświatowe firmy. Wtedy dokłada się nowy typ faktury i numeracja idzie w ramach tego typu i już.

To naprawdę nie jest nic dziwnego, że ktoś tworzy nowe typy dokumentów. Dla uproszczenia zakładamy, że sprzedaje tylko w kraju:

  • faktura sprzedaży dział usług
  • faktura sprzedaży dział magazynu
  • faktura sprzedaży pozostałe
  • paragony
  • korekty
  • zaliczki
    Oczywiście w słowniku się ustala, ze pierwsze 3 typy są tożsame (zwykła faktura krajowa), ale może sobie ustalić inny rodzaj wydruku, ma oddzielną numerację.
1

Tak myślałem.
To nie są żadne "typy faktur" tylko szablony. Inny układ pól czy algorytm numeracji to nie jest zmiana danych przechowywanych w obiekcie faktury. A zatem, przy podejściu Table Per Class nie potrzeba 75 tabel na oddzielne "typy" faktur, jedynie kilka tabel na prawdziwe typy, a w nich referencje do szablonów.

0

Tak, fajne rozwiązanie podałeś. Tylko niestety nie widziałem jeszcze takiego rozwiązania na żywo. Widziałem już dużo różnych baz w tym dużą część komercyjnych systemów do wystawiania faktur dostępnych w Polsce i nie pamiętam aby ktoś tak zrobił. Zawsze to był słownik typów/szablonów a tabela faktur zawierała wszystkie pola. Większość oczywiście była nullami. Nie mniej jednak wydaje mi się, że takie rozwiązanie jak ja proponuję to pójście po prostu po linii najmniejszego oporu i stąd to wynika.

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