Od kilku lat funkcjonują w Polsce przepisy regulujące sposób wystawiania i przetwarzania faktur w formie elektronicznej (tzw. e-faktur). Dzięki obowiązkowi korzystania przy wystawianiu e-faktur z bezpiecznego podpisu elektronicznego i certyfikatów kwalifikowanych, w naszym kraju z tej formy faktury korzysta obecnie (wg GUS) "aż" około 5% przedsiębiorców. Rynek powoli jednak rusza - niedawno obsługę e-faktur wprowadziła Telekomunikacja Polska, dostawcy systemów finansowo-księgowych dodają powoli niezbędne mechanizmy do swoich systemów. Jest szansa, że rynek ruszy na dobre - zwłaszcza, że rząd rozważa zniesienie wymagania opatrzenia takiej faktury bezpiecznym podpisem elektronicznym weryfikowanym kwalifikowanym certyfikatem.
W tej sytuacji należy zastanowić się, jakie formaty plików powinny być używane do wystawiania faktur. Na dzień dzisiejszy na rynku (z tego co wiem) dominują dwa główne warianty:
W przypadku formatu PDF niewątpliwą zaletą jest możliwość pełnej kontroli wyglądu faktury. Ponadto stosowany w takiej fakturze podpis może być weryfikowany przy pomocy standardowej aplikacji stosowanej do otwierania PDFów - Acrobat Readera. Nie będzie to wprawdzie weryfikacja zgodna z polskimi przepisami (do takiej wykorzystywać bowiem należy tzw. "bezpieczne urządzenie do weryfikacji"), ale moim zdaniem w niczym to nie przeszkadza. Wadą formatu PDF jest właśnie konieczność posiadania dedykowanej aplikacji do otwierania takich faktur i brak możliwości (choć tu mogę się mylić) dodania do faktury dodatkowych elementów dowodowych typu znaczniki czasu. Nie bez znaczenia jest też rozmiar takich faktur - potrafią one mieć kilkaset kilobajtów, a nawet kilka MB. Oczywiście da się zrobić faktury o rozmiarze znacznie mniejszym.
W przypadku formatu XML stajemy przed koniecznością zdefiniowania struktury logicznej danych umieszczanych w fakturze. Generalnie mamy dwa możliwe rozwiązania: albo dostosujemy strukturę dokumentów do potrzeb narzędzia wykorzystywanego do ich obsługi, albo zbudujemy tę strukturę w sposób odpowiadający prawdziwemu znaczeniu danych. Osobiście jestem zwolennikiem tego drugiego podejścia, jest ono też prezentowane w opracowanej kilka lat temu propozycji standardu faktury elektronicznej. Propozycja ta, pomimo, że została przyjęta przez wszystkie działające na rynku centra certyfikacji, nie jest, zdaje się, zbyt intensywnie promowana. Opracowany "standard" nie jest zresztą doskonały - brakuje w nim kilku przydatnych pól, niejasny jest sposób realizacji choćby faktur korygujących. Konieczne może być zatem jego dopracowanie.
Niewątpliwą zaletą korzystania z faktur w XML jest możliwość ich automatycznego przetwarzania. Zastosowanie arkusza styli XSL do wizualizacji takiej faktury umożliwia dynamiczne modyfikowanie jej wyglądu, bez ingerencji w samą jej strukturę (co może być zarówno zaletą, jak i wadą). Łatwo jest też stworzyć automaty wprowadzające nowe faktury do systemów F-K. Faktury w XML będą też zazwyczaj znacznie lżejsze niż ich pdfowe odpowiedniki.
Dla porządku należy jeszcze przywołać inne możliwości, takie, jak tworzenie faktur w formacie HTML czy też w obrazkach (tiff, jpg itp). Pierwsza z nich narażona jest na "humory" różnych przeglądarek internetowych, trudno też przetwarzać potem takie faktury w sposób automatyczny. Skomplikowane okazuje się też stworzenie specyfikacji takiej faktury. Z kolei faktury w postaci bitmap (tiff, jpg itp.) są - po pierwsze - dość duże, a ponadto zupełnie się nie nadają do automatycznego przetwarzania.
Oczywiście wybór formatu e-faktur zależy od konkretnego zastosowania. Należy jednak brać pod uwagę konieczność zachowania tam, gdzie to możliwe, w miarę jednolitych formatów danych. Dzięki temu będzie można choć pomarzyć o interoperacyjności.
Add new comment