Ten artykuł to entuzjastyczny opis tego do czego musiało w końcu dojść, mimo głośnego pesymizmu wielu firm “żyjących z braku standardów”, bo koszty integracji, przy braku standaryzacji, potrafią być na prawdę wysokie.

Mamy fakturę ustrukturyzowaną!

W 2014 roku rozpoczęto prace nad standaryzacją elektronicznych faktur. Trwało to długo (podjęcie decyzji o tym w ramach Unii Europejskiej) ale też uzgodnienia takie nie są łatwe. Od roku 2014

Ministerstwo Rozwoju w partnerstwie z Instytutem Logistyki i Magazynowania realizuje projekt “Platforma pośrednicząca elektronicznego fakturowania dla sfery finansów publicznych”, którego celem jest wprowadzenie faktur elektronicznych w relacjach z administracją publiczną i przedsiębiorcami. W ramach projektu uruchomiona zostanie Platforma e-fakturowania, która umożliwi odbieranie i wysyłanie ustrukturyzowanych faktur elektronicznych.

(źr. Fakturowanie elektroniczne. MPiT. https://www.mpit.gov.pl/strony/zadania/wsparcie-przedsiebiorczosci/e?przedsiebiorczosc/e?fakturowanie/. Published March 9, 2017. Accessed December 15, 2018.)

W ramach tych prac powstał stosowny projekt ustawy:

Ustawa implementuje przepisy unijne do polskiego prawa – Dyrektywę Parlamentu Europejskiego i Rady 2014/55/UE z 16 kwietnia 2014 r. w sprawie fakturowania elektronicznego w zamówieniach publicznych. Polska była mocno zaangażowana w prace nad dokumentem, ze względu na jej pozytywne efekty. Od 18 kwietnia 2019 r. zamawiający muszą być przygotowani na odbiór faktury w postaci dokumentu elektronicznego o określonej przepisami strukturze. Zgodnie z Dyrektywą, faktury elektroniczne dla zamówień publicznych będą miały odpowiedni format, co oznacza, że będzie to faktura ustrukturyzowana. Daje to możliwość automatycznego przetwarzania przez systemy informatyczne, bez potrzeby uczestnictwa pracownika w tym procesie, w przeciwieństwie do faktur w formacie PDF czy papierowych, które wymagają ręcznego  wprowadzania danych do systemu księgowego.

(źr.: E- fakturowanie w zamówieniach publicznych. MPiT. https://www.mpit.gov.pl/strony/aktualnosci/e?fakturowanie-w-zamowieniach-publicznych/. Published October 22, 2018. Accessed December 15, 2018.)

Czym taka faktura jest dla przedsiębiorcy? Bardzo przystępnie opisuje to tekst:

Zwykła faktura elektroniczna, o której ustawa o VAT mówi ?faktura w formie elektronicznej?,  spotykana jest najczęściej w formacie PDF i polega na przedstawieniu obrazu, który można przesyłać między kontrahentami w postaci elektronicznej (czyli np. skanu lub zdjęcia). Aby odczytać co jest na takiej fakturze trzeba ją zobaczyć i wzrokowo zaczytać informacje. Oznacza to, że do odczytania danych z takiej faktury potrzebny jest najczęściej człowiek. Pojawiają się metody automatyzujące proces odczytywania danych z takiej faktury w postaci tzw. OCR czyli optycznego rozpoznawania znaków, nigdy nie są one w 100% skuteczne. Stąd ostatecznie ktoś zawsze musi zweryfikować poprawność zaczytanych danych, porównując je z faktycznym obrazem. Elektroniczna faktura ustrukturyzowana różni się tym od zwykłej faktury elektronicznej, że niesie za sobą od razu informacje o danych na fakturze bez konieczności odczytu treści na niej zamieszczonej. Oznacza to, że bez patrzenia na fakturę możemy  automatycznie przekazać i przetwarzać dane w komputerowych systemach księgowych, bez pracy człowieka czy maszyny.

Szpytko-Waszczyszyn E. Czym jest elektroniczna faktura ustrukturyzowana? Poradnik Przedsiębiorcy. https://poradnikprzedsiebiorcy.pl/-czym-jest-faktura-ustrukturyzowana. Published October 21, 2018. Accessed December 15, 2018.

Projektowanie

Implementacje tego wymogu prawa mogę być oczywiście różne, tu opiszę w zarysie metodę opartą na obiektowym podejściu i hermetyzacji jako przykład podejścia obiektowego (w przeciwieństwie do projektowania strukturalnego bazującego na funkcjach i strukturach danych).

Generalnie operujemy tu dziedzinowo pojęciem Faktura, w aplikacji zaś obiektami Doc Faktura oraz treścią tych faktur (tu Invoice):

Na diagramie pokazano: klasyfikator Doc Faktura (oznaczony stereotypem <<businessObject>>) reprezentujący obiekty niosące treść faktur i ich statusy. Odpowiedzialność obiektów tej klasy wyraża ich interfejs czyli operacje (zachowaj treść, przywołaj treść, pokaż status). Treść faktury (tu Invoice, jest to korzeń struktury agregatu pokazanego dalej) – cała jako plik XML – jest przechowywana jako wartość atrybutu “treść faktury”. Pozostałe atrybuty to dobrane odpowiednio do logiki systemu, metadane oraz statusy (służą do realizowania logiki biznesowej aplikacji). Treść samej faktury to struktura XML zobrazowana poniżej jako agregat:

Jak widać jest to drzewiasta struktura odwzorowująca strukturę treści faktury. Struktura ta jest budowana wg. ustalonych reguł, jednak konkretna faktura będzie miała konkretną strukturę wraz z wpisanymi wartościami, zależną od konkretnej transakcji i jej streści (głównie liczby produktów).

Z uwagi na fakt, jakim jest zmienność prawa, nie można założyć niezmienności reguł budowy tej struktury. Dlatego implementacja pokazana powyżej jest bardzo bezpieczna i z perspektywy kosztów utrzymana i perspektywy rozwoju aplikacji.

Implementacja oparta na relacyjnym modelu danych, zakładająca stworzenie relacyjnie powiązanych tabel z kolumnami dla każdego pola faktury, będzie kosztowna w wykonaniu i kosztowna w utrzymaniu: każda istotna modyfikacja struktury faktury spowoduje konieczność przeprojektowania struktury bazy danych i migrację historycznych danych do nowej struktury, wymagany więc będzie także redevelopment kodu odwołującego się do struktur tych tabel.

Na zakończenie

Bardzo się cieszę, że prawo zaczęło regulować takie kwestie jak standaryzacja kluczowych dokumentów biznesowych. Koszty integracji systemów biznesowych są generowane przede wszystkim brakiem standaryzacji, na której wcale nie zależy dostawcom usług informatycznych (standaryzacja nie jest w ich interesie).

Swego czasu prawo UE wymusiło standaryzacje ładowarek do telefonów komórkowych, czego korzyści szybko doceniliśmy. Nadchodzi standaryzacja kluczowych dokumentów w obiegu gospodarczym, co moim zdaniem spowoduje lawinę poprawy efektywności w tym obrocie.

Standaryzacja ta bardzo przysłuży się wdrożeniom systemów dziedzinowych. Zaletą monolitycznych systemów ERP była wbudowana integracja. Wadą jednak to, że integracja ta była realizowana metodą współdzielenia lokalnych struktur danych, co w konsekwencji czyniło te systemy zamkniętymi na rozwój i integrację (z powodów jak wyżej), były i są nadal, bardzo kosztowne we wdrożeniu i utrzymaniu.

Tworzenie systemu metodą wdrażania i integrowania dziedzinowych gotowych podsystemów (osobnych aplikacji kupowanych na rynku) jest już obecnie tańsze, wymaga jednak każdorazowego tworzenia adapterów integracyjnych (standardy wyznaczały najpopularniejsze aplikacje).

Standaryzacja struktur dokumentów spowoduje daleko idące ułatwienia: wdrożenie faktur ustrukturyzowanych to nic innego jak zintegrowanie, za jednym zamachem, systemów wszystkich przedsiębiorców. 

Jarosław Żeliński

Jarosław Żeliński: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.