Ten arty­kuł to entu­zja­stycz­ny opis tego do cze­go musia­ło w koń­cu dojść, mimo gło­śne­go pesy­mi­zmu wie­lu firm ​„żyją­cych z bra­ku stan­dar­dów”, bo kosz­ty inte­gra­cji, przy bra­ku stan­da­ry­za­cji, potra­fią być na praw­dę wysokie.

Mamy fakturę ustrukturyzowaną!

W 2014 roku roz­po­czę­to pra­ce nad stan­da­ry­za­cją elek­tro­nicz­nych fak­tur. Trwało to dłu­go (pod­ję­cie decy­zji o tym w ramach Unii Europejskiej) ale też uzgod­nie­nia takie nie są łatwe. Od roku 2014

Ministerstwo Rozwoju w part­ner­stwie z Instytutem Logistyki i Magazynowania reali­zu­je pro­jekt ​„Platforma pośred­ni­czą­ca elek­tro­nicz­ne­go fak­tu­ro­wa­nia dla sfe­ry finan­sów publicz­nych”, któ­re­go celem jest wpro­wa­dze­nie fak­tur elek­tro­nicz­nych w rela­cjach z admi­ni­stra­cją publicz­ną i przed­się­bior­ca­mi. W ramach pro­jek­tu uru­cho­mio­na zosta­nie Platforma e‑fakturowania, któ­ra umoż­li­wi odbie­ra­nie i wysy­ła­nie ustruk­tu­ry­zo­wa­nych fak­tur elektronicznych.

(źr. Fakturowanie elek­tro­nicz­ne. MPiT. https://​www​.mpit​.gov​.pl/​s​t​r​o​n​y​/​z​a​d​a​n​i​a​/​w​s​p​a​r​c​i​e​-​p​r​z​e​d​s​i​e​b​i​o​r​c​z​o​s​c​i​/​e​?​p​r​z​e​d​s​i​e​b​i​o​r​c​z​o​s​c​/​e​?​f​a​k​t​u​r​o​w​a​n​ie/. Published March 9, 2017. Accessed December 15, 2018.)

W ramach tych prac powstał sto­sow­ny pro­jekt ustawy:

Ustawa imple­men­tu­je prze­pi­sy unij­ne do pol­skie­go pra­wa – Dyrektywę Parlamentu Europejskiego i Rady 2014/55/UE z 16 kwiet­nia 2014 r. w spra­wie fak­tu­ro­wa­nia elek­tro­nicz­ne­go w zamó­wie­niach publicz­nych. Polska była moc­no zaan­ga­żo­wa­na w pra­ce nad doku­men­tem, ze wzglę­du na jej pozy­tyw­ne efek­ty. Od 18 kwiet­nia 2019 r. zama­wia­ją­cy muszą być przy­go­to­wa­ni na odbiór fak­tu­ry w posta­ci doku­men­tu elek­tro­nicz­ne­go o okre­ślo­nej prze­pi­sa­mi struk­tu­rze. Zgodnie z Dyrektywą, fak­tu­ry elek­tro­nicz­ne dla zamó­wień publicz­nych będą mia­ły odpo­wied­ni for­mat, co ozna­cza, że będzie to fak­tu­ra ustruk­tu­ry­zo­wa­na. Daje to moż­li­wość auto­ma­tycz­ne­go prze­twa­rza­nia przez sys­te­my infor­ma­tycz­ne, bez potrze­by uczest­nic­twa pra­cow­ni­ka w tym pro­ce­sie, w prze­ci­wień­stwie do fak­tur w for­ma­cie PDF czy papie­ro­wych, któ­re wyma­ga­ją ręcz­ne­go wpro­wa­dza­nia danych do sys­te­mu księgowego.

(źr.: E- fak­tu­ro­wa­nie w zamó­wie­niach publicz­nych. MPiT. https://​www​.mpit​.gov​.pl/​s​t​r​o​n​y​/​a​k​t​u​a​l​n​o​s​c​i​/​e​?​f​a​k​t​u​r​o​w​a​n​i​e​-​w​-​z​a​m​o​w​i​e​n​i​a​c​h​-​p​u​b​l​i​c​z​n​y​ch/. Published October 22, 2018. Accessed December 15, 2018.)

Czym taka fak­tu­ra jest dla przed­się­bior­cy? Bardzo przy­stęp­nie opi­su­je to tekst:

Zwykła fak­tu­ra elek­tro­nicz­na, o któ­rej usta­wa o VAT mówi ?fak­tu­ra w for­mie elek­tro­nicz­nej?, spo­ty­ka­na jest naj­czę­ściej w for­ma­cie PDF i pole­ga na przed­sta­wie­niu obra­zu, któ­ry moż­na prze­sy­łać mię­dzy kon­tra­hen­ta­mi w posta­ci elek­tro­nicz­nej (czy­li np. ska­nu lub zdję­cia). Aby odczy­tać co jest na takiej fak­tu­rze trze­ba ją zoba­czyć i wzro­ko­wo zaczy­tać infor­ma­cje. Oznacza to, że do odczy­ta­nia danych z takiej fak­tu­ry potrzeb­ny jest naj­czę­ściej czło­wiek. Pojawiają się meto­dy auto­ma­ty­zu­ją­ce pro­ces odczy­ty­wa­nia danych z takiej fak­tu­ry w posta­ci tzw. OCR czy­li optycz­ne­go roz­po­zna­wa­nia zna­ków, nigdy nie są one w 100% sku­tecz­ne. Stąd osta­tecz­nie ktoś zawsze musi zwe­ry­fi­ko­wać popraw­ność zaczy­ta­nych danych, porów­nu­jąc je z fak­tycz­nym obra­zem. Elektroniczna fak­tu­ra ustruk­tu­ry­zo­wa­na róż­ni się tym od zwy­kłej fak­tu­ry elek­tro­nicz­nej, że nie­sie za sobą od razu infor­ma­cje o danych na fak­tu­rze bez koniecz­no­ści odczy­tu tre­ści na niej zamiesz­czo­nej. Oznacza to, że bez patrze­nia na fak­tu­rę może­my auto­ma­tycz­nie prze­ka­zać i prze­twa­rzać dane w kom­pu­te­ro­wych sys­te­mach księ­go­wych, bez pra­cy czło­wie­ka czy maszyny.

Szpytko-Waszczyszyn E. Czym jest elek­tro­nicz­na fak­tu­ra ustruk­tu­ry­zo­wa­na? Poradnik Przedsiębiorcy. https://​porad​nik​przed​sie​bior​cy​.pl/​-​c​z​y​m​-​j​e​s​t​-​f​a​k​t​u​r​a​-​u​s​t​r​u​k​t​u​r​y​z​o​w​ana. Published October 21, 2018. Accessed December 15, 2018.

Projektowanie

Implementacje tego wymo­gu pra­wa mogę być oczy­wi­ście róż­ne, tu opi­szę w zary­sie meto­dę opar­tą na obiek­to­wym podej­ściu i her­me­ty­za­cji jako przy­kład podej­ścia obiek­to­we­go (w prze­ci­wień­stwie do pro­jek­to­wa­nia struk­tu­ral­ne­go bazu­ją­ce­go na funk­cjach i struk­tu­rach danych).

Generalnie ope­ru­je­my tu dzie­dzi­no­wo poję­ciem Faktura, w apli­ka­cji zaś obiek­ta­mi Doc Faktura oraz tre­ścią tych fak­tur (tu Invoice):

Na dia­gra­mie poka­za­no: kla­sy­fi­ka­tor Doc Faktura (ozna­czo­ny ste­reo­ty­pem «businessObject») repre­zen­tu­ją­cy obiek­ty nio­są­ce treść fak­tur i ich sta­tu­sy. Odpowiedzialność obiek­tów tej kla­sy wyra­ża ich inter­fejs czy­li ope­ra­cje (zacho­waj treść, przy­wo­łaj treść, pokaż sta­tus). Treść fak­tu­ry (tu Invoice, jest to korzeń struk­tu­ry agre­ga­tu poka­za­ne­go dalej) – cała jako plik XML – jest prze­cho­wy­wa­na jako war­tość atry­bu­tu ​„treść fak­tu­ry”. Pozostałe atry­bu­ty to dobra­ne odpo­wied­nio do logi­ki sys­te­mu, meta­da­ne oraz sta­tu­sy (słu­żą do reali­zo­wa­nia logi­ki biz­ne­so­wej apli­ka­cji). Treść samej fak­tu­ry to struk­tu­ra XML zobra­zo­wa­na poni­żej jako agregat:

Jak widać jest to drze­wia­sta struk­tu­ra odwzo­ro­wu­ją­ca struk­tu­rę tre­ści fak­tu­ry. Struktura ta jest budo­wa­na wg. usta­lo­nych reguł, jed­nak kon­kret­na fak­tu­ra będzie mia­ła kon­kret­ną struk­tu­rę wraz z wpi­sa­ny­mi war­to­ścia­mi, zależ­ną od kon­kret­nej trans­ak­cji i jej stre­ści (głów­nie licz­by produktów).

Z uwa­gi na fakt, jakim jest zmien­ność pra­wa, nie moż­na zało­żyć nie­zmien­no­ści reguł budo­wy tej struk­tu­ry. Dlatego imple­men­ta­cja poka­za­na powy­żej jest bar­dzo bez­piecz­na i z per­spek­ty­wy kosz­tów utrzy­ma­na i per­spek­ty­wy roz­wo­ju aplikacji.

Implementacja opar­ta na rela­cyj­nym mode­lu danych, zakła­da­ją­ca stwo­rze­nie rela­cyj­nie powią­za­nych tabel z kolum­na­mi dla każ­de­go pola fak­tu­ry, będzie kosz­tow­na w wyko­na­niu i kosz­tow­na w utrzy­ma­niu: każ­da istot­na mody­fi­ka­cja struk­tu­ry fak­tu­ry spo­wo­du­je koniecz­ność prze­pro­jek­to­wa­nia struk­tu­ry bazy danych i migra­cję histo­rycz­nych danych do nowej struk­tu­ry, wyma­ga­ny więc będzie tak­że rede­ve­lop­ment kodu odwo­łu­ją­ce­go się do struk­tur tych tabel.

Na zakończenie

Bardzo się cie­szę, że pra­wo zaczę­ło regu­lo­wać takie kwe­stie jak stan­da­ry­za­cja klu­czo­wych doku­men­tów biz­ne­so­wych. Koszty inte­gra­cji sys­te­mów biz­ne­so­wych są gene­ro­wa­ne przede wszyst­kim bra­kiem stan­da­ry­za­cji, na któ­rej wca­le nie zale­ży dostaw­com usług infor­ma­tycz­nych (stan­da­ry­za­cja nie jest w ich interesie).

Swego cza­su pra­wo UE wymu­si­ło stan­da­ry­za­cje łado­wa­rek do tele­fo­nów komór­ko­wych, cze­go korzy­ści szyb­ko doce­ni­li­śmy. Nadchodzi stan­da­ry­za­cja klu­czo­wych doku­men­tów w obie­gu gospo­dar­czym, co moim zda­niem spo­wo­du­je lawi­nę popra­wy efek­tyw­no­ści w tym obrocie.

Standaryzacja ta bar­dzo przy­słu­ży się wdro­że­niom sys­te­mów dzie­dzi­no­wych. Zaletą mono­li­tycz­nych sys­te­mów ERP była wbu­do­wa­na inte­gra­cja. Wadą jed­nak to, że inte­gra­cja ta była reali­zo­wa­na meto­dą współ­dzie­le­nia lokal­nych struk­tur danych, co w kon­se­kwen­cji czy­ni­ło te sys­te­my zamknię­ty­mi na roz­wój i inte­gra­cję (z powo­dów jak wyżej), były i są nadal, bar­dzo kosz­tow­ne we wdro­że­niu i utrzymaniu.

Tworzenie sys­te­mu meto­dą wdra­ża­nia i inte­gro­wa­nia dzie­dzi­no­wych goto­wych pod­sys­te­mów (osob­nych apli­ka­cji kupo­wa­nych na ryn­ku) jest już obec­nie tań­sze, wyma­ga jed­nak każ­do­ra­zo­we­go two­rze­nia adap­te­rów inte­gra­cyj­nych (stan­dar­dy wyzna­cza­ły naj­po­pu­lar­niej­sze aplikacje).

Standaryzacja struk­tur doku­men­tów spo­wo­du­je dale­ko idą­ce uła­twie­nia: wdro­że­nie fak­tur ustruk­tu­ry­zo­wa­nych to nic inne­go jak zin­te­gro­wa­nie, za jed­nym zama­chem, sys­te­mów wszyst­kich przedsiębiorców.