Generator faktur PDF w PHP

Hej,

pracuje aktualnie nad jednym projektem i jest w nim kawałek CRM w związku z tym potrzebowałem czegoś do masowego generowania faktur dla klientów.
Pomyślałem, że pewnie nie jestem pierwszy, który ma ten problem więc można by zrobić z tego osobną bibliotekę do używania w różnych projektach.

I tak oto jest:
https://github.com/loskoderos/faktura-php

Przykładowa faktura:
https://github.com/loskoderos/faktura-php/blob/master/examples/simple_invoice_pl.pdf

Używanie jest dość proste:

use Faktura\Faktura;
 
$faktura = new Faktura();
 
$invoice = $faktura->newInvoice();
$invoice->setInvoiceReference('INV/123/2018');
 
//...
 
$invoice->newItem()
    ->setDescription('Some item on the invoice')
    ->setUnitNetPrice(123)
    ;
 
//...
 
$faktura->setTemplate('path_to_your_invoice_template.phtml');
$faktura->export($invoice, 'invoice.pdf');

Tutaj jest pełny przykład:
https://github.com/loskoderos/faktura-php/blob/master/examples/simple_invoice_pl.php

Projekt aktualnie bazuje na Xvfb i Wkhtmltopdf, które muszą być zainstalowane w systemie aby działało. Ponieważ, buduję aplikacje w Symfony to pewnie opakuje to w bundle i dodam support dla Twig'a, ale póki co to jest pierwsza beta.

Wrzucam tutaj, fajnie jakbyście zajrzeli w kod i ocenili co warto by zmienić. W założeniu to musi być w stanie generować fakture dla dowolnego projektu i wspierać model faktury z dowolnego kraju.

Z góry dzięki za feedback.

1. Dlaczego główna klasa i namespace to Faktura, a nie Invoice? :)
2. Czy coś stało na przeszkodzie żeby nie używać PHP 7 + w samej bibliotece?
3. Moim zdaniem interfejsy które stworzyłeś dla encji nie są potrzebne, jakoś tak interfejs dla geterów mi nie pasuje.
4. Te encje można by przerobić na value objecty, usunąć settery i całą konstrukcje przenieść do konstruktora i tam dodać walidacje, wtedy teoretycznie nie można by stworzyć faktury z niepoprawnymi danymi ( w sensie walidacyjnym ).
5. Trochę mało testów, w sumie jest tylko jeden end to end, można by dodać jednostkowe do Exportera i Renderera.
6. Nie stosujesz wzorca IoC i tworzysz instancje zależności przez new np. w konstruktorze PhtmlRenderer, lepiej byłoby dodać je jako parametry w konstruktorze i zrobić jakąś fabrykę która tworzy ten obiekt, potem można na potrzeby testów ładnie zamokować zależności.

gaUa69 napisał(a):

1. Dlaczego główna klasa i namespace to Faktura, a nie Invoice? :)

Troche z przekory, Faktura to fabryka albo interfejs do biblioteki, dla obcojęzycznych i tak nie brzmi jak invoice ;)

2. Czy coś stało na przeszkodzie żeby nie używać PHP 7 + w samej bibliotece?

Przyznaje, composer pisany na pałe, ALE nadal wiele projektów jest wstecznie kompabytilne z poprzednimi wersjami pehapa.

3. Moim zdaniem interfejsy które stworzyłeś dla encji nie są potrzebne, jakoś tak interfejs dla geterów mi nie pasuje.

Są potrzebne, ta biblioteka wystawia abstrakcje faktury (Faktura\Entity), jeżeli chciałbyś trzymać te encje np w bazie czy innym persistence wtedy możesz użyć samych interfejsów na swoich encjach np: w Doctrine, które mają dodatkowe mapowanie.

4. Te encje można by przerobić na value objecty, usunąć settery i całą konstrukcje przenieść do konstruktora i tam dodać walidacje, wtedy teoretycznie nie można by stworzyć faktury z niepoprawnymi danymi ( w sensie walidacyjnym ).

Technicznie to są value objecty, ale co by usprawniło to że po usunięciu setterów encje były by immutable, imho bez sensu bo ogranicza potencjalne przypadku użycia. Swoją drogą wszystkie encje dziedziczą po Generic\Object, który ma konstruktor do populacji properties danymi.

5. Trochę mało testów, w sumie jest tylko jeden end to end, można by dodać jednostkowe do Exportera i Renderera.

Ale jest w pełni pokryta testami, pisanie testów dla pisania testów jest fajne ale nie bardzo mam na to czas ;)

6. Nie stosujesz wzorca IoC i tworzysz instancje zależności przez new np. w konstruktorze PhtmlRenderer, lepiej byłoby dodać je jako parametry w konstruktorze i zrobić jakąś fabrykę która tworzy ten obiekt, potem można na potrzeby testów ładnie zamokować zależności.

Tu się zgodzę, można całkowicie pozbyc się klasy Faktura i ręcznie budować obiekty, ale pomyślałem, że w ten sposób można użyć bibliotekę od kopa bo ma domyślny renderer (phtml) i exporter (wkhtmltopdf), natomiast można wrzucić własne implementacje bo są do tego settery i interfejsy lub po prostu nie używac klasy Faktura.

Oliver Russell napisał(a):

Jy kan Symfony gebruik om PDF te genereer. Dit het 'n bondel daarvoor, dink ek knpsnappybundle.

Yes, there is a symfony bundle for generating PDFs which is, similarly, a wrapper arond wkhtmltopdf, but:
1st - This lib does not depend on Symfony, it is a standalone code, although I'll integrate it with Twig and likely bundle it for sake for my parent project where I use this Faktura lib.
2nd - Faktura is not just about converting HTML to PDF, most of the code is an abstraction of an Invoice that should support various accounting cases across the globe, it is already compatible with European (EU) and American invoicing standards.

Analizując te kody, raczej wygląda mi to na jakąś sztukę dla sztuki. No ale rozumiem że to wymóg w nowoczesnych kodach PHP :-) Rozbijanie na podklasy i interfejsy, alternatywnie (i prościej), wszystkie informacje można by umieścić w zwykłej tablicy asocjacyjnej albo w obiekcie typu stdClass. A potem podstawić do renderowanego widoku i przekonwertować to jakimś vendorem. Dodatkowo method chaining, pytanie czy to celowe podejście w przypadku parametrów wymaganych. Do tego warto by było dodać sprawdzanie poprawności wszystkich danych, w tym także NRB, NIP i REGON.

Ale spoko. Nie tu jest problem. Lepiej sobie dobrze poczytaj w temacie jak się liczy podatki na tej fakturze, zwłaszcza mając na uwadze różne stawki VAT, żeby się czasem nie okazało, że przedsiębiorca używający takiego oprogramowania będzie miał poważne problemy z Urzędem Skarbowym :-)

http://itpomocni.pl/przeliczenia-na-fakturach-vat/

drorat1 napisał(a):

Ale spoko. Nie tu jest problem. Lepiej sobie dobrze poczytaj w temacie jak się liczy podatki na tej fakturze, zwłaszcza mając na uwadze różne stawki VAT, żeby się czasem nie okazało, że przedsiębiorca używający takiego oprogramowania będzie miał poważne problemy z Urzędem Skarbowym :-)

Kod liczy wartości dokładnie tak jak jest pokazane w tym artykule, składnik faktury ma ilość, cenę netto i własny podatek, całość faktury jest liczna z tych elementów składowych.
Co do zaokrąglania, nie jest to problem, VAT i tak rozliczasz z dokładnością do 1zł, a jeżeli prowadzisz firme to przyglądnij się fakturom od kontrachentów, gwarantuje, że znajdziesz właśnie różnice 1gr wynikające z zaokrąglania w różnych systemach.

Interfejsy itd, no tak się przyjeło pisać encje, nie tylko w pehapie.