InvoiceInvoker a świat wielkiej polityki i ekonomii

Tytuł wpisu zwiastuje treść i tematykę poważną i podniosłą, jednak bez obaw – poruszana kwestia nie będzie ściśle polityczna czy ekonomiczna, ani daleko odbiegająca od problemów, z którymi zdarza się borykać programistom. Chodzi mianowicie o dostosowanie aplikacji do obowiązujących przepisów, w tym przypadku – stawek procentowych podatku VAT.
Kilka dni po mojej decyzji o starcie w konkursie Daj się poznać z projektem InvoiceInvoker, zapowiedziano zmianę wspomnianych stawek. Był to chyba pierwszy przypadek wywarcia przez urzędujące władze bezpośredniego wpływu na moje decyzje. Ściślej – decyzje projektowe. Dziś, kiedy już prace nad projektem są właściwie na ukończeniu, zaprezentuję tych decyzji konsekwencje – które, co oczywiste dla projektu programistycznego, przybrały postać linii kodu. Przyznaję jednocześnie, że tematyka tego wpisu jest podyktowana moją niechęcią do ciągłego pisania o co raz to nowych widokach i kontrolerach (choć opisanie finalnych widoków i kontrolerów, tych dotyczących wystawiania faktur, wydaje się być nieuniknione).
Przejdźmy jednak do rzeczy. Podstawową decyzją było jak największe uniezależnienie kodu programu od obowiązujących stawek VAT. Początkowo, wprowadzenie tych stawek chciałem zrzucić na użytkownika i umożliwić łatwą ich edycję (na wypadek, gdyby w przyszłości znowu zostały zmienione). Takie rozwiązanie wymagałoby jednak dodania kolejnej kolumny do tabeli sprzedawców w bazie danych, dlatego ostatecznie postanowiłem utworzyć pole VatRates w pliku konfiguracyjnym aplikacji, odpowiedzialne za przechowywanie rzeczonych stawek VAT:

<configuration>
	<appSettings>
		<add key="VatRates" value="22%, 7 %, 3 %, 0 %, n.p., z.w." />
		<add key="PaymentTypes" value="Przelew, Gotówka, Karta płatnicza" /> <!-- swoją drogą, podobnie postąpiłem w kwestii sposobów płatności -->
	</appSettings>

Dostanie się do tego pola i zwrócenie listy stawek nie jest zatem skomplikowane:

public static List<string> GetVatRates()
{
	string vatRates = ConfigurationManager.AppSettings["VatRates"];
	string[] separator = { ", ", "," };
	return vatRates.Split(separator, StringSplitOptions.RemoveEmptyEntries).ToList();
}

Wszystko to jednak tylko ciągi znaków, a przecież głównym ich przeznaczeniem jest reprezentowanie liczb, przez które nalezy pomnożyć wartość netto, by uzyskać wartość brutto produktu. Wyłuskiwaniem tychże liczb zajmuje się następująca metoda:

public static int GetVatPercentage(string vatRate)
{
	int result = 0;
	string vatPercentage = string.Empty;

	if (vatRate.EndsWith(" %")) // ciąg znaków reprezentujący stawkę procentową VAT może kończyć się tylko znakami " %" lub "%"
		vatPercentage = vatRate.Substring(0, vatRate.Length - 2);
	else if (vatRate.EndsWith("%"))
		vatPercentage = vatRate.Substring(0, vatRate.Length - 1);

	// jeśli stawka VAT nie zawiera procentów (jak np. "z.w." - produkt zwolniony od podatku), to jej wartość wynosi 0

	int.TryParse(vatPercentage, out result);

	return result;
}

Wyliczenie wartości podatku VAT odprowadzonego od produktu i warości brutto tego produtku, przy znanej warości netto, wygląda więc tak:

// przedstawione wcześniej metody znajdują się w statycznej klasie VatRatesProvider
int vatPercentage = VatRatesProvider.GetVatPercentage(product.VatRate); //właściwość VatRate jest ciągiem znaków zawierającym stawkę VAT produktu
product.VatValue = product.NetValue * (vatPercentage * 0.01M); // NetValue - wartość netto produktu, VatValue - warość podatku
product.GrossValue = product.NetValue + product.VatValue; // GrossValue - wartość brutto produktu

Metody GetVatRates natomiast używam do przekazania stawek VAT widokom tworzenia i edycji produktów.

I to wszystko w tym temacie, przedstawione rozwiązanie nie jest skomplikowane, ale chyba warte opisania.
Na koniec małe usprawiedliwienie. Wraz z nadejściem (a niedawno także odejściem) ostatnich dni wakacji, częstotliwość pojawiania się nowych notek zauważalnie spadła, czego powodem, jak łatwo się domyślić, jest natłok wszelakich zajęć różnych od kodowania. Projektowi nie grozi jednak, jeśli dobrze rozumiem regulamin i FAQ konkursu, dyskwalifikacja: jeśli dobrze rozumiem regulamin i FAQ konkursu, bardziej niż częstotliwość wpisów, liczy się ich ilość – która do piętnastego listopada powinna liczyć co najmniej dzwadzieścia.

4 myśli na temat “InvoiceInvoker a świat wielkiej polityki i ekonomii”

  1. Pingback: dotnetomaniak.pl
  2. No wszystko prawie fajnie ;-). Pamiętaj tylko, że masz w Polsce dokumenty liczone od Netto i od Brutto, są faktury VAT dla podmiotów gospodarczych liczone od Netto, prawie tak jak pokazałeś, bo brakuje zaokrągleń, chyba, że nie będzie faktur importowych z kursem walut i przeliczeniem. Są jeszcze faktury dla osób fizycznych liczone od Brutto i to liczy się inaczej. Chciałem Ci też podrzucić fajny temat – drukarki fiskalne. Bardzo popularna firma Posnet, ma kontrolkę ActiveX dla drukarek – bardzo fajnie jej użyć. Nawiasem mówiąc z pewnego źródła dowiedziałem się, że jeszcze nie wiadomo co będzie z drukarkami fiskalnymi po zmianie w przepisach. Piszę o tym bo faktury dla osób fizycznych przepuszcza się przez drukarki fiskalne ;-).

    Trzymam kciuki, bardzo podoba mi się Twój projekt ;-).

  3. A co do regulaminu konkursu – dobrze kombinujesz. 20 notek od 1 sierpnia do 15 listopada.

  4. @Piotr Sowa: Dzięki za mnogość informacji. Będę musiał zdecydować, na ile „poglądowy”, a na ile „poważny” jest mój projekt, tzn. wybrać pomiędzy stworzeniem prostego generatora PDFów (bo tym początkowo miał być, i jak na razie jest, InvoiceInvoker), a zaimplementowaniem funkcjonalności umożliwiających prowadzenie księgowości (np. właśnie obsługi drukarek fiskalnych).

    @Procent: Spoko. Wygląda więc na to, że do końca konkursu publikował będę tylko jedną notkę tygodniowo.

Możliwość komentowania jest wyłączona.

%d blogerów lubi to: