Dzisiejszy wpis poświęcony będzie tematyce, którą powinienem był poruszyć już ładnych parę tygodni temu – testowaniu warstw dostępu do danych i logiki biznesowej. Zwlekałem z opisaniem tej części projektu, ponieważ planowałem zaprezentować również testy interfejsu użytkownika, których, koniec końców, wcale nie napisałem (pokusa oglądania aplikacji w akcji i sprawdzania wszystkiego własnoręcznie okazała się zbyt duża).
Tag: business logic layer
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.
Continue reading “InvoiceInvoker a świat wielkiej polityki i ekonomii”
Postać Docelowa Faktury
Po dwutygodniowym rejsie po Mazurach, czas wrócić do pracy nad projektem. Aby skończyć warstwę logiki biznesowej, muszę jeszcze tylko stworzyć klasę, która zajmie się zamianą przyczajonej w bazie danych, zdigitalizowanej do cna postaci faktury w nie mniej zdigitalizowaną, ale niepomiernie bardziej czytelną dla użytkownika programu, postać dokumentu PDF. Użyję w tym celu biblioteki PdfSharp.
Numer kolejny faktury
Punkt drugi założeń projektowych (które można znaleźć tutaj) głosi:
2. numer faktury definiowany szablonem,
Czas zająć się tą funkcjonalnością. Projektując bazę danych zdecydowałem, że zarówno numer faktury jak i jego szablon będą łańcuchami znaków. Spójrzmy na przykład: “1/08/2010” – numer pierwszej faktury w sierpniu 2010. Według reguł, które zaraz przedstawię, szablon takiego numeru wygląda następująco: “N/MM/RR”.
Słownie złotych:
Zgodnie z obowiązującym w Polsce prawem, faktura powinna zawierać przynajmniej:
(…)
– kwotę należności ogółem wraz z należnym podatkiem (brutto), wyrażoną cyframi i słownie.
Tak podaje wikipedia. Dziś zajmę się pogrubionym fragmentem cytatu: zamianą kwoty pieniędzy określonej waluty na jej słowną reprezentację. Zakładam, że wystawiając faktury na kwoty powyżej 999999,99 (czyli milion i więcej) jednostek monetarnych, użytkownik – z nieopisaną satysfakcją – wpisze kwotę słownie własnoręcznie.
Księga liczb: walidacja NIPu i REGONu
Po ukończeniu warstwy dostępu do danych, mogę zabrać się za logikę biznesową. Na początek – walidacja numerów NIP i REGON.
Czym jest NIP, wie mniej więcej każdy. Czym jest REGON, zapewne bardziej “mniej” niż “więcej”. Z kolei wiedzę o tym, co oznaczają poszczególne cyfry tych numerów, moża śmiało uznać za tajemną. Dziś, na potrzeby projektu, uchylę rąbka tajemnicy: zajmę się ich ostatnimi cyframi. Są to cyfry kontrolne, wyznaczane algorytmicznie. Aby je wyliczyć, należy: