Po wprowadzeniu InvoiceInvoker w stadium pre-pre-beta, zająłem się dodawaniem kolejnych modeli, widoków i kontrolerów. Jak na razie projekt uzupełniłem o stronę klientów (bazującą na tabeli RegisteredCustomers bazy danych i analogiczną to strony produktów, więc niestanowiącą wyzwania). Strony faktur i ich szablonów wymagać będą przemyślenia, dlatego zostawiam je na deser. Dziś natomiast przybliżę sposób wyłuskiwania interesujących użytkownika pozycji z nieprzebranego mrowia produktów i niezliczonych szeregów klientów – w skrócie: filtrowania danych.
Author: manisero
Exodus
Na początek zapowiedzniane w poprzednim wpisie kilka linijek o rozwiązaniu problemu z automatyczną walidacją danych – a właściwie jej brakiem. Rozwiązaniem okazała się być zmiana nagłówka metody kontrolera z takiego:
Na chleb – “pep”, a na ASP – “a-ef-e”, czyli raczkowanie w ASP.NET MVC
Mój tort jest już prawie gotowy: spodni biszkopt równomiernie nasiąknął danymi, a środkowa masa osiągnęła spójną konsystencję. Pozostało jeszcze tylko przygotować ostatnią warstwę, dzięki której całość będzie prezentować się iście smakowicie.
Ale dość naśladowania mistrza – przedmiot dzisiejszego wpisu wymaga klarownego języka.
Continue reading “Na chleb – “pep”, a na ASP – “a-ef-e”, czyli raczkowanie w ASP.NET MVC”
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:
Żółwie tempo rozszerzania się rtęci
Jako że udało mi się już napisać solidny kęs kodu, postanowiłem wreszcie opublikować projekt na CodePlex i stworzyć lokalne repozytorium. Ale zanim o tym…
Spojrzenie w DAL
Po stworzeniu bazy danych, nadszedł wreszcie czas na pierwsze linie kodu. Na początek – generowanego automatycznie.
Księga pierwsza: projektowanie bazy danych
Zacznę od pytania: co chcę przechowywać w bazie? I natychmiast odpowiem: na pewno faktury. Zerknięcie na założenia projektowe (pkt. 1) pozwala rozszerzyć odpowiedź. Potrzebował będę również takich tabel jak: klienci, produkty, szablony faktur. Przydałoby się również miejsce na przechowanie danych o użytkownikach programu – tabela sprzedawcy.
Continue reading “Księga pierwsza: projektowanie bazy danych”